Re: An obvious problem with BigBoards application selection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



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

--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list

[Index of Archives]     [Fedora Users]     [Fedora KDE]     [Fedora Announce]     [Fedora Docs]     [Fedora Config]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux