[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: How to construct the DBus identifier for current app?
From:       Milian Wolff <mail () milianw ! de>
Date:       2012-08-18 10:53:56
Message-ID: 3845914.xpRv4mFXPg () minime
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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
mail@milianw.de
http://milianw.de
["signature.asc" (application/pgp-signature)]

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<


[prev in list] [next in list] [prev in thread] [next in thread]