[Portland] The Code

[Kevin Krammer]

On Thursday 16 February 2006 09:30, Lubos Lunak wrote:
> 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.

Just as an information: QDS has a fallback implementation for its "Launcher", 
i.e. what your OpenURL/ExecuteURL services do.
For http URLs it respected $BROWSER and generally uses mailcap for application 
mapping (and mime.types files for MIME type "detection")

The code is currently licenced under 2-clause BSD, but I am willing to 
relicence if necessary.

I also have GNOME-VFS based Launcher code, although wrapped in Qt application 
code :)
A native GNOME developer can surely do better, but it might be sufficient for 
quick testing.

> > 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.

Good point. I currently "solve" this by allowing my API "libqds" to be 
statically linked and it in turn loads the DBus acccessor as a plugin.

> > 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

I think Bryce also wants to be able to lookup which application would be 
started without actually starting it right away. For example to populate an 
"Open With..." submenu or those browser dialogs that offer the choice to open 
or save to disk.

>  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.

Which mean it can be released as a version working with KDE3 and does not 
require waiting for KDE4

Cheers,
Kevin

-- 
Kevin Krammer <kevin.krammer at gmx.at>
Qt/KDE Developer, Debian User
Moderator: www.mrunix.de (German), www.qtcentre.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/portland/attachments/20060216/625cd1c9/attachment.pgp