Standard desktop API
Donald Straney
burntfuse at gmail.com
Thu Dec 28 02:13:37 EET 2006
Hi,
First, I apologize if this is the wrong place to post or if this has been
discussed already (I searched the mailing list archives already, though). I
think a lot of people agree that we need a way to write a single app that
will work natively on KDE, GNOME, XFCE, or whatever desktop happens to be
running at the time. If I remember correctly, there's a project to create
an API on top of D-Bus to solve this problem. In my humble opinion, though,
that's going about it the wrong way. It just adds yet another daemon and
yet another abstraction layer, which is something we definitely don't need
any more of. The way I see it, it would be much better to come up with a
standard API to replace the GNOME and KDE APIs. I definitely _don't_ mean
that the actual code would be the same, just the API calls - the program
would be linked at compile time to libdesktop.so (or whatever the library
would be called), and through an environment variable or some messing around
with symbolic links, when it was run it would be linked to the desktop
environment's implementation of the library. That way, a program that used
a standard call for opening the default web browser, for example, would call
KDE's "open default browser" code when run in KDE, GNOME's "open default
browser" code when run in GNOME, etc.
Maybe this wouldn't be easy, but it should at least be possible, since the
two big desktop APIs (for KDE and GNOME) already have many of the same
features. The GNOME VFS does the same thing as the kioslaves, for example,
and they both have ways of opening default programs. It would just mean
updating the actual interface and possibly some of the core code, instead of
rewriting the entire thing. Some parts of the API have already become
standard (like D-Bus), and in the mailing list archives I saw discussions on
standardizing settings, search, and help APIs, so it would be nice to
finally pull it all together into one spec.
Here's some ideas for what it could contain:
External programs
---------------------------
Open URL with default browser
Write e-mail with default e-mail client
Show program's registered help files
Get list of application entries
Show application list, let user select one
(takes list of app handles as arg, so result of
app entry search can be used, to pick an app out
of all the ones that can open a certain mimetype,
for example)
VFS
-------
Open connection to resource
(integrate with PAM for network shares which
need authentication?)
Close connection to resource
Open file (returns FILE*, so normal fread, fwrite, etc. can be used)
Open directory (returns DIR*, same reason)
Find mimetype of file
Copy file
Move file
Delete file
Create file
Create directory
Open file with default handler
Get basic file properties
Show file properties (with file manager's property window)
Open path in file manager (optionally with file selected)
Multimedia
-----------------
GStreamer for audio/video?
Images
Load image
Get image info (as key-value list)
Process image (use functions from imlib2?)
Save image
Get image from scanner/camera? (integrate with SANE and libgphoto2)
Any ideas? Thoughts? Flames for a bad suggestion?
Donald Straney
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freedesktop.org/archives/xdg/attachments/20061227/9a082e26/attachment.htm
More information about the xdg
mailing list