[Portland] The Code
l.lunak at suse.cz
Wed Feb 15 20:25:53 EET 2006
so much discussion and now not a single mail for a month and also no
resulting functionality AFAIK (or have I missed something?). So, how about
trying it the other way around now and first having some code and only then
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.
- doc/ with a description of the implemented calls. There's only some basic
stuff like "open url", "send mail", "turn on/off screensaver",
"download/upload remote file" that came first to my mind, but it should be
enough for testing (well, and it's also probably the stuff that's needed the
- 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
So the short demo:
- make sure you have KDE devel packages
- untar somewhere and cd
- ./configure && make
- "cd daemon_generic && ./dapi_generic" for the generic functionality or "cd
daemon_kde && ./dapi_kde" for the KDE functionality
- ./test/test_mailto or any other in test/ to see (or not see) it in action
Some technical details:
It is the out-of-process solution of sending command using IPC, where in this
case the IPC is simply unix domain socket. When an app calls a function in
the library, it converts the data and feeds it into the socket, a server on
the other side decodes it, does whatever it can do about it and sends back an
answer. The plan is that apps use the lib, desktops provide their own daemon
and the generic daemon can be a separate package that apps may require to be
installed in case they don't find any desktop running. As simple as that.
It's currently just a demo and as such I didn't bother with some things
before knowing it makes sense to try, but it shouldn't need that much work to
get it to the point of being really usable. The two important things missing
from the technical point of view I'm aware of are not requiring the strict
ordering on the wire and transferring&caching data instead of doing separate
call for each of them like the button order call does now. A lot of the stuff
is autogenerated in lib/gen/, so adding new calls or even doing things like
changing the transport mechanism shouldn't be that difficult. I believe it
could provide reasonably sufficient/functional/whatever desktop API within a
reasonable time. Hmm, what to say more?
So, onto questions:
- Should I bother further? I.e. would there be people interested in using it?
And helping with it (I for obvious reasons can't do e.g. the
- Technical comments? Note that this requires certain order, I'm not
interested in a discussion about a bool argument somewhere as long as I don't
know if this all is worth bothering. I'm also not interested in discussing
some theories, this list has seen enough of that already. And, finally, I'm
not interested in comments about anything related to the code generator ;).
- 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.
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/
More information about the Portland