Bastien Nocera wrote:
On Wed, 2007-06-13 at 14:34 -0400, Jonathan Blandford wrote:
> On Mon, 2007-06-11 at 15:44 -0800, Jeff Spaleta wrote:
>> Hmm... to show evince? If you want to show evince in bigboard...why
>> wouldn't you want to show it in the normal menus as well? I honestly
>> can't think of a rationale where you'd want it to show up in one
>> interface and not the other. Either evince should be treated like a
>> normal callable end user application or its treated as a helper and is
>> thus hidden from selection interfaces... pick a pov and stick with it.
> It was a conscious design decision for evince to not appear in the
> menus. There seems to be no advantage to starting evince on its own, as
> it is very much a viewer and not a creator. We can perhaps finesse the
> NoDisplay issue with a white list or black list. A better approach
> might be to categorize that kind of application by mime-type.
Huh. Should we put Totem NoDisplay as well then?
I repent! We had good reasons at the time to do this, we wanted to
experiment and see if it's really better this way. However I've
realized now that the undiscovered issue was actually in the display of
the application menu as much as it was showing or hiding them. Much of
the issues in the XChat thread  are actually due to how we display
and allow access to the desktop entries / applications as much as the
information we hold in the file. And with Big Board we've been able to
change things to create much more interesting system for users that
avoids the previous problem.
Big Board shows the application (project) name and it's generic name at
the same time allowing people who don't recognize the Open Source names
of applications to recognize the one that handles "Email". But it also
supports searching both those names, meaning a search for "evolution" or
"email" will return the same thing. Hopefully in the future we'll have
support for things like tags and such that could also be searched or
used for showing related applications. I digress.
> While it has a terrible name, something like this might be an
> interesting add-on to mugshot:
> The design is pretty bad, but the overall idea is good. The mugshot
> server would be a great basis to do this right.
I don't even think you would need mugshot to do that. We already
have /usr/share/applications/defaults.list which contains the mime-type
<-> application link.
So for example, trying to open a RAR file:
yum -y install /usr/share/applications/gnome-file-roller.desktop
Voila! You just need integration into nautilus, and a nice front-end to
What the Big Board applications system gives you is not just a list of
applications, but the list of applications that are being used most.
Let me just give an example of how it would improve the defaults.list.
Right now the defaults is a static list of applications that map to mime
types, the mugshot / big board improvement on that would be offering the
user a list of many applications that handle that mime type, sorted by
their popularity through actual desktop usage. Because in reality there
are a million programs out there that might handle RAR files, how does
one choose the best of bread app? You'd have to read an article written
specifically on the topic  to figure out which one might work for
you; where mugshot could provide the list of apps that everyone else is