Hi,<br><br>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).&nbsp; 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.&nbsp; If I remember correctly, there&#39;s a project to create an API on top of D-Bus to solve this problem.&nbsp; In my humble opinion, though, that&#39;s going about it the wrong way.&nbsp; It just adds yet another daemon and yet another abstraction layer, which is something we definitely don&#39;t need any more of.&nbsp; The way I see it, it would be much better to come up with a standard API to replace the GNOME and KDE APIs.&nbsp; I definitely _don&#39;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&#39;s implementation of the library.&nbsp; That way, a program that used a standard call for opening the default web browser, for example, would call KDE&#39;s &quot;open default browser&quot; code when run in KDE, GNOME&#39;s &quot;open default browser&quot; code when run in GNOME, etc.
<br><br>Maybe this wouldn&#39;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.&nbsp; The GNOME VFS does the same thing as the kioslaves, for example, and they both have ways of opening default programs.&nbsp; It would just mean updating the actual interface and possibly some of the core code, instead of rewriting the entire thing.&nbsp; 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.
<br><br>Here&#39;s some ideas for what it could contain:<br><br>External programs<br>---------------------------<br><br>Open URL with default browser<br>Write e-mail with default e-mail client<br>Show program&#39;s registered help files
<br>Get list of application entries<br>Show application list, let user select one<br>&nbsp;&nbsp;&nbsp; (takes list of app handles as arg, so result of<br>&nbsp;&nbsp;&nbsp; app entry search can be used, to pick an app out<br>&nbsp;&nbsp;&nbsp; of all the ones that can open a certain mimetype,
<br>&nbsp;&nbsp;&nbsp; for example)<br><br>VFS<br>-------<br><br>Open connection to resource<br>&nbsp;&nbsp;&nbsp; (integrate with PAM for network shares which<br>&nbsp;&nbsp;&nbsp; need authentication?)<br>Close connection to resource<br>Open file (returns FILE*, so normal fread, fwrite, etc. can be used)
<br>Open directory (returns DIR*, same reason)<br>Find mimetype of file<br>Copy file<br>Move file<br>Delete file<br>Create file<br>Create directory<br>Open file with default handler<br>Get basic file properties<br>Show file properties (with file manager&#39;s property window)
<br>Open path in file manager (optionally with file selected)<br><br>Multimedia<br>-----------------<br><br>GStreamer for audio/video?<br>Images<br>&nbsp;&nbsp;&nbsp; Load image<br>&nbsp;&nbsp;&nbsp; Get image info (as key-value list)<br>&nbsp;&nbsp;&nbsp; Process image (use functions from imlib2?)
<br>&nbsp;&nbsp;&nbsp; Save image<br>&nbsp;&nbsp;&nbsp; Get image from scanner/camera? (integrate with SANE and libgphoto2)<br><br><br><br>Any ideas? Thoughts? Flames for a bad suggestion?<br><br>Donald Straney<br>