An obvious problem with BigBoards application selection

[Bryan Clark]

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 [0] 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:
>>
>> https://wiki.ubuntu.com/UbuntuCommonHooker
>>
>> 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:
> application/x-rar=gnome-file-roller.desktop
> Gives you:
> yum -y install /usr/share/applications/gnome-file-roller.desktop
>
> Voila! You just need integration into nautilus, and a nice front-end to
> yum.
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 [1] to figure out which one might work for 
you; where mugshot could provide the list of apps that everyone else is 
already using.

Cheers,
~ Bryan

[0] 
http://www.redhat.com/archives/fedora-devel-list/2004-April/msg00714.html
[1] http://www.linux.com/article.pl?sid=07/01/29/2031237