James has asked me to write something about the desktop-related release criteria in the light of bug https://bugzilla.redhat.com/show_bug.cgi?id=697834
Starting with the bug itself, I'll state that I don't think it is a blocker that we should fix for F15. It has made it to the blocker list because it seems to violate the release criterion that there shall be no 'Other' menu in the panel menus.
Why did we put this in the release criteria ? Selecting from a long menu is difficult, you can't actually see the content hidden behind the menuitem until you perform a reasonably hard fine-motor-control task, and it is hard to back out of submenu should it not contain what you are looking for.
In fact, these difficulties with hierarchical menus were one of the main underlying motivations for the design of the shell overview. Not surprisingly, the shell overview does not have these problems, mostly. The primary mode of interaction with the overview is search; you just start typing.
The presence of the unsorted 'Other' grab-bag category is still an annoyance, but since categories are much less prominent, it is just a minor annoyance.
Looking at the rest of the 'Menu sanity' bullet points in https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria some of these codify the GNOME2 user experience and are not really adequate for GNOME3:
All Applications listed in the desktop menus must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry
No problem with this one, although it should really be a bit more concrete: the shell overview works best if the application icon is available as a 256x256 png.
All applications listed under the Applications menu or category must start successfully
No doubt still relevant.
All applications listed under the Applications menu or category must withstand a basic functionality test and not crash after a few minutes of normal use.
Of course.
They must also have working Help and Help -> About menu items
This one needs revision or clarification, I think. First of all, talking about menu items only makes sense if one assumes a classical menubar-toolbar-content-statusbar application layout. The developing GNOME3 HIG will de-emphasize this pattern in favor of menubar-less designs. And even if an application does have a menubar, maybe it does not need help because it is very obvious ?
Wrt. to 'About', one thing we are aiming for in GNOME3 is to have 'unbranded utilities' which are part of the core desktop. 'About' dialogs mostly make sense for applications which have a 'personality' and are not just part of the desktop. In short: applications can have an about dialog, but the shell overview also shows things which are not applications in that sense.
Last question on this criterion is: What is the consequence ? If an application does not have an about dialog, do we really expect to hold the release until the packager has patched one in, collected the necessary translations, written a manual, hooked it up, etc ? This really feels more like a criterion to consult when choosing the applications to include on the spin.
There must be no Other menu or category
I've already talked about this. I really don't see us block a release for this, but having meaningful classifications for all applications is certainly a useful thing to keep in mind somehow. In fact, I think that would be a more useful criterion.
No application may unintentionally appear twice in the menus. In particular, items under System must not appear under Applications
This basically does not apply to the shell overview. It does not have the Applications vs System dichotomy, and I think allowing overlapping classifications would actually be a very useful thing in the overview; if not for the fact that the desktop entry spec codifies mutual exclusion for primary categories, IIRC.
Matthias
On Mon, 2011-05-09 at 13:20 -0400, Matthias Clasen wrote:
James has asked me to write something about the desktop-related release criteria in the light of bug https://bugzilla.redhat.com/show_bug.cgi?id=697834
Starting with the bug itself, I'll state that I don't think it is a blocker that we should fix for F15. It has made it to the blocker list because it seems to violate the release criterion that there shall be no 'Other' menu in the panel menus.
Why did we put this in the release criteria ? Selecting from a long menu is difficult, you can't actually see the content hidden behind the menuitem until you perform a reasonably hard fine-motor-control task, and it is hard to back out of submenu should it not contain what you are looking for.
I believe this was kind of the reason: the idea was that categories were used to keep things properly ordered, and the only way we could guarantee people *didn't* wind up with giant lists to scroll through was to categorize everything properly. Something winding up in Other was proof that it wasn't correctly categorized, hence, problem!
In fact, these difficulties with hierarchical menus were one of the main underlying motivations for the design of the shell overview. Not surprisingly, the shell overview does not have these problems, mostly. The primary mode of interaction with the overview is search; you just start typing.
The presence of the unsorted 'Other' grab-bag category is still an annoyance, but since categories are much less prominent, it is just a minor annoyance.
That's reasonable to me: personally I'm happy with dropping the criterion on that basis, though obviously we should still make a best effort to categorize stuff right.
Looking at the rest of the 'Menu sanity' bullet points in https://fedoraproject.org/wiki/Fedora_15_Final_Release_Criteria some of these codify the GNOME2 user experience and are not really adequate for GNOME3:
Indeed. Remember, however, that we try to write the criteria as generically as possible - one goal I have for the desktop criteria is to try and make sure they're written in such a way that they apply to all desktops, as long as this is possible without too much compromise.
All Applications listed in the desktop menus must have icons which have a consistent appearance and sufficiently high resolution to avoid appearing blurry
No problem with this one, although it should really be a bit more concrete: the shell overview works best if the application icon is available as a 256x256 png.
The idea with writing it in this way was to be future-proof. The Shell case is actually a good illustration of this: if we'd written it to be 'concrete' as of 2009, it probably would have specified 64x64 or so - there was no reasonable case for requiring 256x256 at that time. But since it's generically written, we can claim that now Shell exists, it requires 256x256 icons without any rewriting :)
They must also have working Help and Help -> About menu items
This one needs revision or clarification, I think. First of all, talking about menu items only makes sense if one assumes a classical menubar-toolbar-content-statusbar application layout. The developing GNOME3 HIG will de-emphasize this pattern in favor of menubar-less designs. And even if an application does have a menubar, maybe it does not need help because it is very obvious ?
I think this was a GNOME 2 design goal, yeah. Suggested changes would be welcome indeed.
Wrt. to 'About', one thing we are aiming for in GNOME3 is to have 'unbranded utilities' which are part of the core desktop. 'About' dialogs mostly make sense for applications which have a 'personality' and are not just part of the desktop. In short: applications can have an about dialog, but the shell overview also shows things which are not applications in that sense.
I think this is the cause of the 'Applications menu' restriction in the criterion (that's still in force from two criteria earlier, remember). But again, if this doesn't make sense in a GNOME 3 world, we can change it by all means. (It's also something I thought the other desktops wouldn't be happy with, but remember I sent out multiple requests for them to review the criteria and no-one complained, so, hey.)
Last question on this criterion is: What is the consequence ? If an application does not have an about dialog, do we really expect to hold the release until the packager has patched one in, collected the necessary translations, written a manual, hooked it up, etc ? This really feels more like a criterion to consult when choosing the applications to include on the spin.
Well, whenever there's a bug which involves an application breaching any of these criteria, 'drop the application' is always an acceptable resolution. It's often possible to resolve release blocker issues without _fixing the bug_, exactly. But this is definitely one that I thought was quite a high bar, and was only included in the first place because you folks (desktop team) asked for it :) So if you think it should be revised, again, that's fine.
No application may unintentionally appear twice in the menus. In particular, items under System must not appear under Applications
This basically does not apply to the shell overview. It does not have the Applications vs System dichotomy, and I think allowing overlapping classifications would actually be a very useful thing in the overview; if not for the fact that the desktop entry spec codifies mutual exclusion for primary categories, IIRC.
This may be something the other desktops would want to keep, so we should probably check with them about it, and see if there's a way we can word it that makes everyone happy.
On Mon, May 9, 2011 at 8:20 PM, Matthias Clasen mclasen@redhat.com wrote:
No application may unintentionally appear twice in the menus. In particular, items under System must not appear under Applications
I think this one should be changed to: No icon should be used for more than one default application (as the icons are used as the primary way to identify applications in the shell), and application names shouldn't be the same or too similar, see bug - https://bugzilla.redhat.com/show_bug.cgi?id=702772 as an example to such issue.
desktop@lists.fedoraproject.org
-
Adam Williamson -
Elad Alfassa -
Matthias Clasen