On Friday, 2013-06-14, Thomas Lübking wrote: > On Freitag, 14. Juni 2013 16:30:16 CEST, Jan Kundrát wrote: > > I'm not sure whether DBUS is what we want here. > > The traditional way for POSIX systems (including mac, but not windows) was > to have a PID lockfile and SIGHUP the running process to make it > raise/activate itself. It's also poosible to "::kill(<PID>, 0)" to test > whether the process is actually still alive (though afaik it's not > possible to test whether it's actually trojita in a POSIX conformant way)
Just some context on why D-Bus was probably suggested and why it is basically *the* single app mechanism in FOSS environments now: it does not require any runtime checking. I'll expand on this a bit. Traditional approaches like PID files often have the problem that there is no guarantee that the PID file is removed. If the application exits cleanly then it is most likely removed, if the application crashes it is most likely not. This can not happen with D-Bus, if a D-Bus client vanishes (exits, crashes, ...) the name on the bus vanishes as well. There are no races. If two applications try to register the name, only one will get it and the other one will be notified about failure. Interesting factoid: some single instance applications are even moving away from direct launching, i.e. their actual application is never launched directly. The executable with the application name always just sends its arguments to a D-Bus object. The actual application is D-Bus activatable, so it gets started by D-Bus if it is the target of a D-Bus call but not running yet. Neither "launcher" nor "service" have to check anything. The "service" always gets its arguments via D-Bus, the "launcher" never keeps running. Obviously not nicely portable, but a neat concept nevertheless :) > > the single-instance support is required for acting as the > > mailto: URL hander in a system, and implementing the > > That's a bit trickier than. Trojitá would have to read from stdin (either > in a second thread or on sighup trigger) what will require a reliable and > securing parser ;-) > > However, i assume this will work on top of QProcess on Windows as well > then. You can also use QLocalSocket across all Qt platforms. The main application would use QLocalServer, the mailto handler would connect to it using QLocalSocket and send its findings through it. > > My first reaction to this is that the plugin should probably be > > chosen based on what environemnt the application is running in, > > but perhaps it's wrong (it would certainly be a bit weird if the > > user suddenly "loses" her addresbook when switching from KDE to > > something else, for example). > > That's the crap part about a hundred little addresbooks in Linux :-( As far as I know there are only two contact data services: Evolution Data Server (EDS) and Akonadi. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
