Refactor Connect and Disconnect functionality out to CClient #3372

ann0see · 2024-09-13T20:53:05Z

This is an extract from #2550

Short description of changes

Refactor Connect() and disconnect functionality.
Introduces a new Connect() method for quick connection and adds signals to Start() and Stop() of client.

CHANGELOG: Refactoring: Move Connect() functionality to CClient.

Context: Fixes an issue?

Fixes: #3367

Does this change need documentation? What needs to be documented and how?

No

Status of this Pull Request

Ready for review. Start for refactoring. Most likely overlaps and to a large extent relates somehow to #3364

What is missing until this pull request can be merged?

Review, clarification, probably documentation and refactoring.

Checklist

I've verified that this Pull Request follows the general code principles
I tested my code and it does what I want
My code follows the style guide
I waited some time after this Pull Request was opened and all GitHub checks completed without errors.
I've filled all the content above

src/client.cpp

src/clientdlg.cpp

src/client.cpp

pljones · 2024-09-14T08:53:17Z

src/client.cpp

+    if ( !IsRunning() )
+    {
+        // Set server address and connect if valid address was supplied
+        if ( SetServerAddr ( strServerAddress ) )


I don't like this style at all. If there's some validation to happen, it should have happened before we get this far. We shouldn't try to connect to an address that's not invalid.

Perhaps this whole routine is redundant and SetServerAddr should be called Connect and do the emits?

SetServerAddr

Should just do exactly what the name implies IMO - Otherwise we could introduce mixing of functionality.
Connect() would then emit the signals. That's cleaner and closer to what we do now.

I think that nevertheless Connect(serverAddress) should exist. It simplifies needing to set and then start the client.

src/client.cpp

src/clientdlg.cpp

pljones · 2024-09-14T09:29:04Z

src/clientdlg.cpp

@@ -1193,65 +1193,36 @@ void CClientDlg::OnCLPingTimeWithNumClientsReceived ( CHostAddress InetAddr, int
    ConnectDlg.SetPingTimeAndNumClientsResult ( InetAddr, iPingTime, iNumClients );
 }

-void CClientDlg::Connect ( const QString& strSelectedAddress, const QString& strMixerBoardLabel )
+void CClientDlg::OnConnect ( const QString& strMixerBoardLabel )


Ideally, this signal would get issued only on successful connection.

As we're going cross-thread here, we need Client to supply any listener -- ClientDlg or the Client JSON-RPC -- with full details of the newly established connection.

We should follow this rule for all state changes in the Client -- that should be the only way for ClientDlg and the Client JSON-RPC to acquire knowledge of Client state, no calls to functions across threads.

(The same is true on the server side, too.)

Similarly, to change the state of the Client, the Client should expose slots and ClientDlg or Client JSON-RPC should signal those slots to effect the change in state. Not call methods across threads.

This does demand a major restructure but I think this could be a good place to start. Set out what state changes when the Client successfully establishes a connection to a server, create an object instance containing that information, and issue a signal passing that object. This gives a clearly defined API to that change in state.

Either the message on the signal could be minimal, covering only the state that changes on any connect, or extensive, supplying the whole Client state. In the latter case, every signal from the Client would pass a new state instance with the full current Client state, making the listener's job much easier. (I don't like it as much as the minimal approach but it's likely much easier to explain and maintain. It smacks of "global variables" a bit too much, though...)

The global approach could also be wasteful while the small approach could be more difficult. If we restructure correctly, we should aim at the small approach.

src/clientdlg.cpp

src/client.cpp

src/clientdlg.cpp

src/client.h

ann0see · 2024-09-15T10:20:43Z

channel.cpp emits Disconnected() in GetData --> may need some refactoring

src/clientdlg.h

src/clientdlg.cpp

src/channel.cpp

src/client.cpp

src/clientdlg.cpp

src/client.cpp

src/clientdlg.cpp

ann0see · 2024-09-22T15:57:05Z

Now the coding style check seems to work. Not so sure about the style change in main.cpp:
https://github.com/jamulussoftware/jamulus/actions/runs/10982471650/job/30490757878?pr=3372#step:4:54

ann0see · 2024-10-08T19:12:35Z

Please recheck if the important parts are in the two issues I opened and comment there.

pljones · 2024-10-08T19:21:44Z

src/client.cpp

+            {
+                throw CGenErr ( tr ( "Received invalid server address. Please check for typos in the provided server address." ) );
+            }
+        }


Should this throw some indication it ignored the request?

It emits the error message further down

8e48c03#diff-7bc46552432fa03e009f9f455e4729312853d92775935ef20849797f24ac0c60R941

ann0see · 2024-10-08T19:25:04Z

I do not understand why clang format complains about the list style here.

https://github.com/jamulussoftware/jamulus/actions/runs/11242233032/job/31255455777?pr=3372#step:4:18

src/clientdlg.cpp

softins · 2024-10-29T18:08:03Z

src/clientdlg.cpp

-        // first check if we are already connected, if this is the case we have to
-        // disconnect the old server first
-        if ( pClient->IsRunning() )
-        {
-            Disconnect();
-        }
-


I don't think this code should be removed. Or else equivalent code should be added somewhere according to the new structure (which I don't yet fully understand).

It is possible, while connected to a server, to go File->Connection Setup..., or Ctrl-C, to bring up the connect dialog, and then select a new server to connect to. In existing versions of Jamulus, this disconnects from the connected server, and then immediately connects to the new server. This was used to great effect during WorldJam to quickly move between rooms.

In the version built from this PR, this doesn't work. The existing connection continues instead of connecting to the new server.

We could probably call something like pClient->Disconnect()/Stop() and then pClient->Connect().
The main idea of this PR is to:

Emit signals if the client disconnects or connects

Introduce convenient methods for programmatic (JSON-RPC) disconnection and connection.

Ok. Fixed. Not sure if we need the if is running then stop.
I'd like to have this if in the client then.

src/clientdlg.cpp

This is an extract from jamulussoftware#2550 Co-authored-by: ann0see <[email protected]>

ann0see · 2024-11-04T20:32:39Z

src/client.cpp

+/// @method
+/// @brief Stops the client if the client is running
+/// @emit Disconnected
+void CClient::Disconnect()


Introduced again. Mainly an alias. But now also with the check

pljones · 2024-11-05T18:48:52Z

src/client.cpp

@@ -122,7 +121,7 @@ CClient::CClient ( const quint16  iPortNumber,
    QObject::connect ( &Channel, &CChannel::ConClientListMesReceived, this, &CClient::OnConClientListMesReceived );
    QObject::connect ( &Channel, &CChannel::ConClientListMesReceived, this, &CClient::ConClientListMesReceived );

-    QObject::connect ( &Channel, &CChannel::Disconnected, this, &CClient::Disconnected );
+    QObject::connect ( &Channel, &CChannel::Disconnected, this, &CClient::Stop );


I'm not happy with Stop as a name. What does it do? It doesn't exit the application...

It's used (at least) here and in the SIGINT/SIGTERM handler. The latter makes me wonder if it's also used in the OnAboutToQuit handling (which should be invoked by the SIGINT/SIGTERM handler...).

Stop() means it stops the client.
But this concept is not well defined IMO.

I guess I want to know what "Stop" stops the client doing. About the only thing I can think is it should trigger emitting a signal that stops audio processing. If that is all it's doing, this would be better as a lambda.

I think I'd like SIGINT/SIGTERM to simply exit the application and have the AboutToQuit handling clean up, if that's a sane approach. Currently it feels like there's random paths through the code for no real reason.

ann0see commented Sep 13, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

ann0see commented Sep 13, 2024

View reviewed changes

src/clientdlg.cpp Outdated Show resolved Hide resolved

ann0see commented Sep 13, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

ann0see mentioned this pull request Sep 13, 2024

Fix connection status issue (#2519) #3364

Draft

5 tasks

ann0see requested review from softins and pljones September 13, 2024 21:44

pljones reviewed Sep 14, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

pljones reviewed Sep 14, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

pljones reviewed Sep 14, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

pljones reviewed Sep 14, 2024

View reviewed changes

src/client.cpp Show resolved Hide resolved

pljones reviewed Sep 14, 2024

View reviewed changes

src/clientdlg.cpp Outdated Show resolved Hide resolved

pljones reviewed Sep 14, 2024

View reviewed changes

src/clientdlg.cpp Outdated Show resolved Hide resolved

pljones reviewed Sep 14, 2024

View reviewed changes

src/clientdlg.cpp Show resolved Hide resolved

pljones reviewed Sep 14, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

ann0see commented Sep 14, 2024

View reviewed changes

src/clientdlg.cpp Show resolved Hide resolved

ann0see commented Sep 15, 2024

View reviewed changes

src/client.h Show resolved Hide resolved

ann0see commented Sep 15, 2024

View reviewed changes

src/clientdlg.h Show resolved Hide resolved

ann0see force-pushed the refactoring/moveConnectDisconnect branch from 8bacce4 to 4ec9c68 Compare September 15, 2024 10:56

ann0see commented Sep 15, 2024

View reviewed changes

src/clientdlg.cpp Outdated Show resolved Hide resolved

ann0see force-pushed the refactoring/moveConnectDisconnect branch from 4ec9c68 to a1d98aa Compare September 15, 2024 10:58

ann0see commented Sep 15, 2024

View reviewed changes

src/channel.cpp Outdated Show resolved Hide resolved

ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from 69246f5 to 57825bf Compare September 15, 2024 20:44

ann0see commented Sep 15, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

pljones reviewed Sep 16, 2024

View reviewed changes

src/clientdlg.cpp Show resolved Hide resolved

pljones reviewed Sep 16, 2024

View reviewed changes

src/client.cpp Outdated Show resolved Hide resolved

ann0see force-pushed the refactoring/moveConnectDisconnect branch from 57825bf to 8bc81d7 Compare September 16, 2024 19:30

pljones reviewed Sep 17, 2024

View reviewed changes

src/clientdlg.cpp Show resolved Hide resolved

ann0see mentioned this pull request Sep 22, 2024

Do not fail silently if IP in connection window is invalid #1945

Open

ann0see force-pushed the refactoring/moveConnectDisconnect branch from 596e42b to 65622ee Compare September 22, 2024 15:50

ann0see force-pushed the refactoring/moveConnectDisconnect branch from 65622ee to 1957532 Compare September 22, 2024 16:08

ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from e27569f to ae31a65 Compare October 8, 2024 18:43

This was referenced Oct 8, 2024

Refactor CClientDlgOnConnectDisconnectBut() #3401

Open

Rewrite cclientdlg closeEvent, onAboutToQuit, ... #3402

Open

ann0see added this to the Release 3.12.0 milestone Oct 8, 2024

ann0see requested a review from pljones October 8, 2024 19:09

ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from 8b0b44d to 8e48c03 Compare October 8, 2024 19:17

pljones reviewed Oct 8, 2024

View reviewed changes

ann0see marked this pull request as ready for review October 8, 2024 19:27

pljones reviewed Oct 8, 2024

View reviewed changes

src/clientdlg.cpp Show resolved Hide resolved

ann0see force-pushed the refactoring/moveConnectDisconnect branch from 8e48c03 to 9f93619 Compare October 8, 2024 19:30

softins requested changes Oct 29, 2024

View reviewed changes

ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from 4642e40 to b996df2 Compare November 3, 2024 21:30

pljones requested changes Nov 4, 2024

View reviewed changes

src/clientdlg.cpp Show resolved Hide resolved

src/clientdlg.cpp Outdated Show resolved Hide resolved

src/clientdlg.cpp Outdated Show resolved Hide resolved

ann0see force-pushed the refactoring/moveConnectDisconnect branch from b996df2 to 7b420ff Compare November 4, 2024 20:27

Refactor Connect out to CClient

a77dcfe

This is an extract from jamulussoftware#2550 Co-authored-by: ann0see <[email protected]>

ann0see force-pushed the refactoring/moveConnectDisconnect branch from 7b420ff to a77dcfe Compare November 4, 2024 20:30

ann0see requested review from pljones and softins November 4, 2024 20:31

ann0see commented Nov 4, 2024

View reviewed changes

pljones reviewed Nov 5, 2024

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor Connect and Disconnect functionality out to CClient #3372

Refactor Connect and Disconnect functionality out to CClient #3372

ann0see commented Sep 13, 2024 •

edited

Loading

pljones Sep 14, 2024

ann0see Sep 14, 2024

ann0see Sep 16, 2024

pljones Sep 14, 2024

ann0see Sep 14, 2024

ann0see commented Sep 15, 2024

ann0see commented Sep 22, 2024

ann0see commented Oct 8, 2024 •

edited

Loading

pljones Oct 8, 2024

ann0see Oct 8, 2024

ann0see Oct 8, 2024

ann0see commented Oct 8, 2024 •

edited

Loading

softins Oct 29, 2024

ann0see Nov 3, 2024

ann0see Nov 3, 2024 •

edited

Loading

ann0see Nov 4, 2024

pljones Nov 5, 2024

ann0see Nov 7, 2024

pljones Nov 7, 2024

Refactor Connect and Disconnect functionality out to CClient #3372

Are you sure you want to change the base?

Refactor Connect and Disconnect functionality out to CClient #3372

Conversation

ann0see commented Sep 13, 2024 • edited Loading

Checklist

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ann0see commented Sep 15, 2024

ann0see commented Sep 22, 2024

ann0see commented Oct 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ann0see commented Oct 8, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ann0see Nov 3, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ann0see commented Sep 13, 2024 •

edited

Loading

ann0see commented Oct 8, 2024 •

edited

Loading

ann0see commented Oct 8, 2024 •

edited

Loading

ann0see Nov 3, 2024 •

edited

Loading