another proposal for MIME: with actions, implementators, and scores
- From: Lee Braiden <jel ntlworld com>
- To: GNOME Desktop Devel <desktop-devel-list gnome org>
- Subject: another proposal for MIME: with actions, implementators, and scores
- Date: Mon, 8 Dec 2003 22:04:54 +0000
Hi Jonathan et al,
Apologies if this shows up again later. I just joined the list, and posted
earlier before joining, so there's a copy stuck awaiting moderation. I
wanted to get in on this discussion while it's still living, so...
I have a slightly different idea of how this mime stuff could work. Doubtless
some compromise would be best (especially if KDE come in on a freedesktop
solution, which would be ideal :), but I'll spell out just how I imagine it,
anyway:
Files would have a prioritised list of mimetypes; not just primary and
others. This would allow better fallback and probably some other nice
features, simply by virtue of providing more information to the desktop
itself.
Mimetypes should have multiple actions associated with them. 'Open' should be
one of many possible actions for a file. Print, Extract, etc, should all be
possible too. Ideally, these actions would be a global list, which can be
given 'implementors' for each mimetype. The list should be extensible, too.
Applications should provide a list of actions and mimetypes for which those
actions are implemented.
Some way to prioritise applications is needed, too. Perhaps giving each
application's implementation a 'rating' would do here: a scale of (less
than?) -100 to (more than?) +100, with certain known milestones on the scale,
like -100 is NOT_IMPLEMENTED, -50 is POOR_IMPLEMENTATION, 0 is average and
+100 is IDEAL_IMPLEMENTATION, for example.
To go cross-desktop neatly, those values might be scaled for applications
which use different desktops. So, for example, a GOOD_IMPLEMENTATION for the
GNOME might outrank an IDEAL_IMPLEMENTATION for KDE, if GNOME is the desktop
in use. Other preferences could be factored in by penalising the user's
least favorite apps or rewarding more favored apps, for example.
Doing this allows you to automagically present a 'Top 10' of favorite
applications to perform any available action on a file.
An 'advanced view' of the 'Open With...' dialog could be rolled-down (I'm not
sure of terminology here -- the triangle widget like in OS X) allowing
selection of more complex options, like handling this file as a more
fundamental mimetype (XML, etc).
Alternatively, you could present the 'Top 1' of 10 different action
implementors for a mimetype. That would give you a list, for an XHTML file,
of Edit with Bluefish, Edit with Conglomerate, Edit with GEdit, Edit with Hex
Editor, etc. Equally, a print list might look like Print with Mozilla, Print
with Pretty HTML Printer, Print with GEdit, etc. Actually, there's an issue
here, where we might want two print actions: Print as Webpage and Print as
Sourcecode. But this system allows for that problem, unlike current
approaches.
GNOME would probably prefer those apps to be listed by generic name, but
that's possible, too, except in cases where very similar applications need to
be distinguised.
I'll summarise, in an attempt to make more sense of all this:
I'd like to have a context menu with 'Open with <default app>' and 'Open with
>'. 'Open With >' should resemble the current system, with 'App 2, App 3,
----, Other...'. The difference is that it would choose each app VERY
smartly. When you choose 'Other...', it should give more SMART options for
both the top-level mimetype and a SMART selection of other mimetypes' Open
actions, perhaps.
In advanced mode, it should give access to the Mimetypes capplet, which gives
another nice, usable interface to the hierarchy of mimetypes and associated
actions. From there, it should be possible to define new actions.
Globally, you need mimetypes, actions, implementations, and some new common
dialog to handle handle smart display of available implementations of a given
action for a given mimetype.
--
Lee.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]