Cross-desktop helpers

[Shaun McCance]

Putting it back onto xdg-list.  Doesn't look private, so I'm assuming
you sent it just to me by accident.

On Fri, 2004-12-10 at 15:42, Chas wrote:
> Shaun McCance wrote:
> 
> >Off the top of my head, there's the terminal, character map, calculator,
> >and sound recorder.  Most desktops provide these utilities.  While most
> >applications don't need these as much as, say, the user's web browser, I
> >do know of at least one largeish cross-platform application that's able
> >to call the sound recorder to record and import a sound file on Windows
> >on Mac, but doesn't have this functionality on X because there's no way
> >to get a "standard" sound recorder.
> >  
> >
> The sound recorder can be found by its mime association -- either by 
> default file extension or mime type. 

No, I don't think so.  People aren't going to have the sound recorder
set as the default handler for WAV files.  And even if they did, the
order or operations is all wrong.  You don't open a WAV file with the
sound recorder.  You call the sound recorder, and get a WAV file back
from it.  (Well, all right, if you're calling it from an application,
you probably need to give it a location under /tmp or something, so you
can read the file back into your program.)

> Do the terminal, character map, and calculator have standard mime 
> associations?  Should they?

The four examples I gave were chosen particularly because they don't
operate on files or any sort of URIs.  At least for the calculator and
sound recorder, it would be useful to have a standard way of getting
data back.

You could make up non-file-associated not-quite-mime-types for things
like this.  Like x-service/sound-recorder.  I don't think that's a very
nice solution though.

> One convention that is not specified by xdg is a standard place to put 
> protocol associations.  There was a small discussion in either kde or 
> gnome about saving protocol associations in the mime type database as 
> url-protocol/<protocol>. eg. url-protocol/https, url-protocol/mailto, ...

The way I see it, launching user-preferred applications falls into three
categories: launching on a file, launching on a URI type, and launching
some general service.  The difference between when you use files and
when you use URI types is pretty hazy, and I don't pretend to have any
great guidelines.

But non-file, non-URI services are distinct.  (Well, mailto: falls into
this category, but that scheme is pretty entrenched.)  For this class, I
think it would be best to add categorized -Exec fields to desktop files.
For instance, a sound recorder could have this:

RecorderExec=foo-recorder --save-to="%f"

We'd have a well-defined set of utility apps, and for each of them, we'd
have a set of defined parameters.  Any program that has RecorderExec set
can be considered to be a sound recorder.  A desktop preference tool for
preferred apps could present all the with-RecorderExec programs for the
"Preferred Sound Recorder" setting, if it wants to.

But then, none of the things Alex wanted in his original email are in
this non-file, non-URI service category.  So this email is pretty much
orthogonal to that.

--
Shaun