What happened to QtSingleApplication?
-
You can do it using QLocalSocket and QLocalServer. when you start the application use a QLocalSocket and try to connect to an existing server if returns an error of type
QLocalSocket::ServerNotFoundErrorthen start the server.
If another instance of application will start it will try and succeed in the connection, you can then use the socket to transmit data between the two applications and, once done, make the second application quit -
Just clone the QtSolutions repository, you have everything there. The documentation will be same as the one you can find online but you can also build it when you build the module.
It's a module provided by The Qt Company.
-
You can do it using QLocalSocket and QLocalServer. when you start the application use a QLocalSocket and try to connect to an existing server if returns an error of type
QLocalSocket::ServerNotFoundErrorthen start the server.
If another instance of application will start it will try and succeed in the connection, you can then use the socket to transmit data between the two applications and, once done, make the second application quit@VRonin Not an ideal solution since it's on you to reinvent appropriate scoping.
For example, for a desktop Linux/BSD application, the proper solution would be to claim a static name on the session bus via QtDBus (Something like
com.you.YourApplication), which has the added benefit of giving you a ready-made place to offer automation RPC to the rest of the desktop, such asraise(). (Not to mention the pre-defined namespaces, like MPRIS.)At the very least, I'd incorporate the username or user ID into the server name when using
QLocalSocketandQLocalServer. -
@VRonin Not an ideal solution since it's on you to reinvent appropriate scoping.
For example, for a desktop Linux/BSD application, the proper solution would be to claim a static name on the session bus via QtDBus (Something like
com.you.YourApplication), which has the added benefit of giving you a ready-made place to offer automation RPC to the rest of the desktop, such asraise(). (Not to mention the pre-defined namespaces, like MPRIS.)At the very least, I'd incorporate the username or user ID into the server name when using
QLocalSocketandQLocalServer.@ssokolow said in What happened to QtSingleApplication?:
@VRonin Not an ideal solution since it's on you to reinvent appropriate scoping.
Perhaps, but rather simple and I'm pretty sure
QtSingleApplicationdoes it this way, too.Read and abide by the Qt Code of Conduct
-
@ssokolow said in What happened to QtSingleApplication?:
@VRonin Not an ideal solution since it's on you to reinvent appropriate scoping.
Perhaps, but rather simple and I'm pretty sure
QtSingleApplicationdoes it this way, too.Actually, I took at quick look at the source code and it looked like it was using a lockfile in the user profile, which means that it would be user-scoped rather than session-scoped.
(ie. Two separate sessions under the same account would interfere with each other.)
-
Actually, I took at quick look at the source code and it looked like it was using a lockfile in the user profile, which means that it would be user-scoped rather than session-scoped.
(ie. Two separate sessions under the same account would interfere with each other.)
@ssokolow said in What happened to QtSingleApplication?:
Actually, I took at quick look at the source code and it looked like it was using a lockfile in the user profile, which means that it would be user-scoped rather than session-scoped.
I believe this is correct, yes.
-
Quote from the old days:
Trolltech provides platform- and industry-specific components and tools, as well as cutting-edge components too new to include directly in Qt.That's what the Qt Solutions were originally.
