[Portland] The Code

[Lubos Lunak]

On Wednesday 15 February 2006 23:55, Bryce Harrington wrote:
> On Wed, Feb 15, 2006 at 07:25:53PM +0100, Lubos Lunak wrote:
> >  At http://ktown.kde.org/~seli/dapi/dapi.tar.bz2 is a tarball
> > implementing some basic desktop API. To build there's the usual
> > "configure && make" combo, don't bother with installing for just testing.
> > You need KDE devel packages for building it.
>
> Okay cool, your latest version compiles and runs properly (gentoo/KDE).
> It builds without issue using:
>
>     ./configure && make -C lib && make
>
> I tried out each of the test scripts.  The mailto and runasuser tests
> failed, but the others seemed to give sensible output.

 They should fail only with the generic implementation, the mailto service 
probably needs a list of hardcoded apps like the openurl one and I have no 
idea how to do generic X su. I expect that some of the services will not be 
implemented as generic and apps will have to fall back to their own code if 
they detect a failure.

> One comment on the screensaver code, though.  The API here includes
> commands to turn it on and off, but I've been thinking perhaps a
> delaying mechanism might be better?  I could imagine a situation where
> my presentation program might crash or get locked up, so if we're
> depending on it to restart the screensaver, that might not always
> happen.  Instead, if when the program requests to turn off the
> screensaver, if it could give a timeout period (i.e., "turn it off for 1
> hour or until I send a turn on signal, whichever comes first") that may
> better match what the user would expect.

 The screensaver call is actually not "turn screensaver on/off", but "I want 
the screensaver suspended". Which means that a) if apps A and B both suspend 
it, the screensaver will be re-enabled only after they both allow it, b) if 
any of the apps disconnects, there's cleanup done. KDE service has this 
implemented, the generic one has it marked as TODO.

> > - lib/ is a library that should be everything apps need to care about
> > (note that some of the stuff is autogenerated in gen/ so that's where the
> > .h file with the C functions is). Just in case it's not absolutely
> > obvious, the library doesn't depend on KDE at all of course.
> > - test/ has a couple of simple C apps that use the various calls, e.g.
> > test_mailto should be self-explaining.
> > - daemon_generic/ and daemon_kde/ have implementations of the calls,
> > generic being unrelated to any desktop (and as such simple, stupid and
> > not having some functionality), kde implements the functionality using
> > KDE
>
> If I'm understanding correctly, the one dependent lib that an app would
> need to add would be libdapi.a?

 Right. Given that I expect at least some apps will want to link statically 
(which prevents changes without rebuilding the app), even the wire format 
could be proclaimed to be the API.

> > - What more should be needed? As I've already mentioned before I find the
> > Portland pages at fd.o too vague. "Query the address book" doesn't mean
> > much from the developer's point of view and there are even worse. But
> > note the "certain order" thingy from the previous paragraph first.
>
> Perhaps, but there's a number of items on that list that look fairly
> clear, and that I imagine would be straightforward to add to your code,
> assuming this approach is acceptable to Gnome/Xfce/Kde folks...
>
> * Given a URL, open it in the preferred web browser
> * Set the preferred web browser
> * Lookup handler for a particular mimetype
>   (Which program should I use for 'editing' a '*.doc' file?)
> * Enable/disable power management for the display
>   (This goes hand in hand with the screensaver, and should have a
>   similar API).

 Done, not done, done, done. There's OpenUrl for #1, it IMHO doesn't make 
sense to let apps set the default browser as that's a desktop service, 
ExecuteUrl is #3 and SuspendScreensaving is #4 (screensaver and DPMS is 
exactly the same from the apps' point of view, in fact the generic 
implementation which just disables DPMS should work with any sensible 
screensaver, as they should suspend if they detect DPMS turned off - this way 
KDE screensaver automatically suspends e.g. with MPlayer).

> I can't speak for anyone else of course, but this looks like a pretty
> workable solution, and if the KDE/Gnome/Xfce/etc. folks think it's
> something they might be willing to consider, I'd be open to experiment
> with hooking it into Inkscape.

 Hmm, I think my signature says I could be considered KDE folks here ;) , and 
I'd expect other KDE people would like this too. Besides, the KDE daemon 
isn't actually special in any way, it could be simply a standalone add-on 
package.

 Moreover I think the acception actually depends more on 3rd party developers 
than on desktop developers, because this strictly speaking doesn't actually 
depend on desktop developers. If you all 3rd party developers complaining 
(rightly) that there's no generic desktop API even for basic things decide on 
concentrating on one common solution instead of everybody rolling their own, 
I don't see what there could be to stop you. Creating a GNOME/Xfce/Foo 
implementation is just a matter of copying the generic implementation and 
using GNOME/Xfce/Foo API there.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/