Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor Connect and Disconnect functionality out to CClient #3372

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

ann0see
Copy link
Member

@ann0see ann0see commented Sep 13, 2024

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 Outdated Show resolved Hide resolved
src/clientdlg.cpp Outdated Show resolved Hide resolved
src/client.cpp Outdated Show resolved Hide resolved
src/client.cpp Outdated Show resolved Hide resolved
src/client.cpp Outdated Show resolved Hide resolved
src/client.cpp Outdated Show resolved Hide resolved
src/client.cpp Outdated
if ( !IsRunning() )
{
// Set server address and connect if valid address was supplied
if ( SetServerAddr ( strServerAddress ) )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

src/clientdlg.cpp Outdated Show resolved Hide resolved
src/clientdlg.cpp Outdated Show resolved Hide resolved
@@ -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 )
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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/client.cpp Outdated Show resolved Hide resolved
src/client.h Show resolved Hide resolved
@ann0see
Copy link
Member Author

ann0see commented Sep 15, 2024

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

@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch from 8bacce4 to 4ec9c68 Compare September 15, 2024 10:56
src/clientdlg.cpp Outdated Show resolved Hide resolved
@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch from 4ec9c68 to a1d98aa Compare September 15, 2024 10:58
src/channel.cpp Outdated Show resolved Hide resolved
@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from 69246f5 to 57825bf Compare September 15, 2024 20:44
src/client.cpp Outdated Show resolved Hide resolved
src/client.cpp Outdated Show resolved Hide resolved
@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch from 57825bf to 8bc81d7 Compare September 16, 2024 19:30
@ann0see
Copy link
Member Author

ann0see commented Sep 22, 2024

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 ann0see force-pushed the refactoring/moveConnectDisconnect branch from 65622ee to 1957532 Compare September 22, 2024 16:08
@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from e27569f to ae31a65 Compare October 8, 2024 18:43
@ann0see ann0see added this to the Release 3.12.0 milestone Oct 8, 2024
@ann0see ann0see requested a review from pljones October 8, 2024 19:09
@ann0see
Copy link
Member Author

ann0see commented Oct 8, 2024

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

@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from 8b0b44d to 8e48c03 Compare October 8, 2024 19:17
{
throw CGenErr ( tr ( "Received invalid server address. Please check for typos in the provided server address." ) );
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this throw some indication it ignored the request?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It emits the error message further down

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ann0see
Copy link
Member Author

ann0see commented Oct 8, 2024

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

@ann0see ann0see marked this pull request as ready for review October 8, 2024 19:27
@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch from 8e48c03 to 9f93619 Compare October 8, 2024 19:30
Comment on lines 733 to 749
// first check if we are already connected, if this is the case we have to
// disconnect the old server first
if ( pClient->IsRunning() )
{
Disconnect();
}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

  1. Emit signals if the client disconnects or connects
  2. Introduce convenient methods for programmatic (JSON-RPC) disconnection and connection.

Copy link
Member Author

@ann0see ann0see Nov 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch 2 times, most recently from 4642e40 to b996df2 Compare November 3, 2024 21:30
src/clientdlg.cpp Show resolved Hide resolved
{
pClient->Stop();
}
void CClientDlg::OnConnectingFailed ( const QString& strError ) { QMessageBox::critical ( this, APP_NAME, strError, "Close", nullptr ); }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't "Close" be translatable?


// initiate connection
Connect ( strSelectedAddress, strMixerBoardLabel );

Copy link
Collaborator

@pljones pljones Nov 4, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(minor...) Unneeded (and inconsistent) blank line.

@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch from b996df2 to 7b420ff Compare November 4, 2024 20:27
This is an extract from jamulussoftware#2550
Co-authored-by: ann0see <20726856+ann0see@users.noreply.github.com>
@ann0see ann0see force-pushed the refactoring/moveConnectDisconnect branch from 7b420ff to a77dcfe Compare November 4, 2024 20:30
/// @method
/// @brief Stops the client if the client is running
/// @emit Disconnected
void CClient::Disconnect()
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@@ -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 );
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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...).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Waiting externally
Development

Successfully merging this pull request may close these issues.

Refactor Connect() and Disconnect() functions in GUI to allow JSON RPC to update UI
4 participants