On Thursday 16 August 2012 23:12:16 Kevin Krammer wrote: > On Thursday, 2012-08-16, Milian Wolff wrote: > > Hey there, > > > > see for context: http://git.reviewboard.kde.org/r/105917/#review17551 > > > > tl;dr; I need to construct the DBus identifier of the currently running > > app, e.g. "org.kdevelop.kdevelop-$pid" - from inside a library. > > > > I found KAboutData, which could be obtained via KCmdLineArgs::aboutData(). > > There, I have organizationDomain() and appName(), which I could > > concatenate > > to the DBUS identifier like: > > > > id = "%1.%2-%3".arg(orgDomain, appName, pid) > > > > Does that sound OK or is there a better, more direct approach, to find the > > DBus identifier for the currently running app? > > A D-Bus connection, which means also the Default connection to the session > bus, can have any number of "nice" names (it will always have a unique name, > e.g. :1.90). > > What do you want to achieve, i.e. what do you need that KDE application name > for?
See the reviewboard code for an example. In KDevelop we have sessions, which can only be opened in one kdevelop instance. If the user opens an existing session, we thus first have to make sure that no other KDevelop instance is currently opened for that session. That is achieved via a KLockFile. Now, that is not optimal, if KDevelop crashes, the power dies, or something similar, the lock file will stick around. Now when you restart KDevelop, it could happen that another app was created with the $pid stored in the lock file. To gracefully handle this case, we query the kdevelop instance for that pid via DBUS. If the DBUS call doesn't work, we can quite safely assume that the lock file is stale and offer the user a way to remove the stale lock file. If the DBUS call works we can bring the existing KDevelop instance to focus and cancel the opening of another instance for that session. Now, the above is nice and shiny, but only works as long as the DBUS-query lives in kdevelop. Now we want to make it resuable by putting it into kdevplatform, but there I can no longer hard code the DBUS path to e.g. org.kdevelop.kdevelop. This could also be quanta, or anything else. Note: Sessions are not shared between different kdevplatform users, so it would be OK to just build the query based on the current app's KAboutData as explained in my first email. I merely wanted to ask whether that sounds OK or whether there is a better, more direct getter for the DBUS name of the currently running application (minus pid). Cheers -- Milian Wolff m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
