On Friday 17 August 2012 00:25:16 Kevin Krammer wrote: > On Thursday, 2012-08-16, Milian Wolff wrote: > > 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. > > You could consider using a D-Bus "lock" instead of a lock file. > > Basically when opening a session you register a D-Bus name which includes > the session identifier. > Only one process can have that name registered and the registration is > undone no matter how the process exits. > > The name can also be used to send the other KDevelop instance the request to > regain focus.
Btw, thanks for the suggestion. We'll use that in KDevelop. 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 <<