I've been playing with Bigboard for a while now and for this stage in development it's both fairly solid and useful, however one thing makes it work rather badly - the way it selects applications.
My background is on the QA team which means I tend to favor crashing applications, reproducing crashes over and over. This leads to bug-buddy being launched quite a bit, in fact so much that's now the 6th most used application on my desktop, which means it's now listed in my application list. The thing is Bug-buddy is no use for me as a separately started application so it shouldn't be listed there in the first place.
I do realise this is one of those corner cases which on a real desktop will (hopefully) never happen.
- David Nielsen
On Mon, 2007-06-11 at 12:05 +0200, David Nielsen wrote:
I've been playing with Bigboard for a while now and for this stage in development it's both fairly solid and useful, however one thing makes it work rather badly - the way it selects applications.
My background is on the QA team which means I tend to favor crashing applications, reproducing crashes over and over. This leads to bug-buddy being launched quite a bit, in fact so much that's now the 6th most used application on my desktop, which means it's now listed in my application list. The thing is Bug-buddy is no use for me as a separately started application so it shouldn't be listed there in the first place.
Right - there are two issues here.
The first is that bug buddy shouldn't be listed as an application.
The second is we need to implement the design for updating your preferred apps list: http://bugzilla.mugshot.org/show_bug.cgi?id=1254
On Mon, 2007-06-11 at 16:44 -0400, Colin Walters wrote:
On Mon, 2007-06-11 at 12:05 +0200, David Nielsen wrote:
I've been playing with Bigboard for a while now and for this stage in development it's both fairly solid and useful, however one thing makes it work rather badly - the way it selects applications.
My background is on the QA team which means I tend to favor crashing applications, reproducing crashes over and over. This leads to bug-buddy being launched quite a bit, in fact so much that's now the 6th most used application on my desktop, which means it's now listed in my application list. The thing is Bug-buddy is no use for me as a separately started application so it shouldn't be listed there in the first place.
Right - there are two issues here.
The first is that bug buddy shouldn't be listed as an application.
Bug-buddy does not show up in the classic menus; even though it does have a desktop file. Maybe bigboard should pay attention to the NoDisplay field.
On Mon, 2007-06-11 at 17:41 -0400, Matthias Clasen wrote:
Bug-buddy does not show up in the classic menus; even though it does have a desktop file. Maybe bigboard should pay attention to the NoDisplay field.
We did originally honor NoDisplay; I think it got lost in some code shuffling, or maybe because we wanted to show Evince?
I just committed a fix (r5830).
On 6/11/07, Colin Walters walters@redhat.com wrote:
We did originally honor NoDisplay; I think it got lost in some code shuffling, or maybe because we wanted to show Evince?
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.
-jef
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.
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.
Thanks, -Jonathan
On 6/13/07, Jonathan Blandford jrb@redhat.com wrote:
It was a conscious design decision for evince to not appear in the menus.
I realize.... but my point is if its not going to appear in the menus... it shouldn't appear in bigboards dynamic 'popular' application list that the user sees either. Don't complicate this by wrapping another layer of catergorization over NoDisplay. NoDisplay as a tag in the desktop file does exact the job its suppose to do. BigBoard needs to honor the design choices the same way the static menus do. Either an app should be displayed to the user as a stand alone applicarion.. or it shouldn't... it doesn't matter if its bigboards dynamic interface or the menu's static listing. Bending over backwards to get evince displayed in bigboard as a special exception to the NoDisplay rule but not in the static menus makes no sense what-so-ever. If it was a design choice to hide it... hide it...and stand up behind that original design choice.
-jef"This is only a hypothetical argument, since Colin only suggested that showing evince in bigboard's listing was a goal and there's been no affirmation that this was indeed a goal. If this were an actual argument, oxygen masks would drop from the ceiling in front of you and emergency lighting would lead you to the nearest bottle of tequila."spaleta
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?
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.
On Thu, 2007-06-14 at 01:11 +0100, Bastien Nocera wrote:
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
Should be pretty easy to have pirut's single package installer[1] do that if we want it to. Say the word and it'll be in the next build :)
Jeremy
[1] The thing that comes up when you double click on a package. And is also used with mugshot/bigboard for installing apps. So this would be consistent with everything else
On Thu, Jun 14, 2007 at 01:11:23AM +0100, 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?
Indeed. I don't think making Evince (or Totem) NoDisplay makes sense. Here's why:
There are basically two ways a user might choose to "view" (or play or whatever) a file. One is to find the file and then open it via a process that knows what application should be used. The other is to start the application first, and use that to locate and open the file.
Now, users who don't know that Evince opens PDFs, or that Totem opens videos are certainly only going to do the former. However, once they've made the connection, there are actually good reasons to use the application to open the file. Here are three:
1) The application might maintain a recently-used documents list, and so I don't waste time navigating to the right folder to open it. Personally, I do this all the time in OpenOffice as I rarely create new documents, but frequently update a small number of existing ones. (Evince has such a feature.)
2) The application knows what type of file it can open and so can automatically filter the list of files in an open file dialog - so it's also easy to find the right thing to open. (Evince can also do this, though the default on this machine is "All documents" for some reason.)
3) I want to view the file in something which is not the default applicaiton.
I certainly don't see why it hurts to have Evince in the menu. So let's not proscribe behaviour?
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
Jeremy Katz wrote:
On Thu, 2007-06-14 at 01:11 +0100, Bastien Nocera wrote:
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
Should be pretty easy to have pirut's single package installer[1] do that if we want it to. Say the word and it'll be in the next build :)
Have you done this? I think it's a useful feature regardless of whether big board is going to use it.
Rahul
On Thu, 2007-06-21 at 00:58 +0530, Rahul Sundaram wrote:
Jeremy Katz wrote:
On Thu, 2007-06-14 at 01:11 +0100, Bastien Nocera wrote:
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
Should be pretty easy to have pirut's single package installer[1] do that if we want it to. Say the word and it'll be in the next build :)
Have you done this? I think it's a useful feature regardless of whether big board is going to use it.
Nope -- file it in bugzilla (so it doesn't get lost) and I'll try to get to it tonight or tomorrow
Jeremy
desktop@lists.fedoraproject.org