Re: Designing "Finding and Reminding"

[Elia Cogodi <elia cogodi gmail com>]

It sure would be confusing if the shown item was just the resource.
But is that what the reminding part is about, pure resources?

I could see some good points in actually exposing the whole "action",
both in history/journal ("opened file X with editor Y") and in a
favourites/ current work section. Visually the action would show both
the resource icon and a smaller app icon (in the corner?) and
explicitly mention the application used in textual descriptions.
Possible exception, not show icon nor text if the app is the default
handler.

This way, I could keep "open movie with viewer" and "open movie with
editor" as separate favourite actions - to trigger them with one
click, drag them to a workspace and so on. The default handler would
just be, well, the default app used to build an action if I open a
file from a file manager or a simple search interface.

Nothing keeps me from easily overriding it by just using the resource
information when needed: drag a "open movie X with Totem" action from
the journal/reminder thing into PiTiVi and movie X is opened with
PiTiVi (and a new "open movie X with PiTiVi" is born in current
activites)

The way i see it, the "pure resource" view would be a grouped view of
these actions, by resource, and it could be the best for a quick
summary... but for a chronological view and some organizing tasks
dealing with specific actions (and tagging them into activities) makes
more sense.

On Thu, May 5, 2011 at 11:29 AM, Milan Bouchet-Valat <nalimilan club fr> wrote:
> Le jeudi 05 mai 2011 à 10:20 +0100, Emmanuele Bassi a écrit :
>> the fact that everyone uses the MIME instead of one of
>> the applications that registered a URI in the list is just that nobody
>> has done it because it's easier to use the default handler for the
>> MIME type;
> In fact, the Shell originally did so, and it was very confusing that
> you'd never be sure what application the file would open in. So it was
> reverted to the default handler, which is more reliable.
>
> Of course, it doesn't invalidate your point that the registered app can
> be used when no default handler is available.
>
>
> Regards
>
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-shell-list
>



-- 
    Elia