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. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org http://www.happyassassin.net -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
