FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Desktop

 
 
LinkBack Thread Tools
 
Old 05-09-2011, 05:20 PM
Matthias Clasen
 
Default release criteria revisions

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

--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 05-09-2011, 05:49 PM
Adam Williamson
 
Default release criteria revisions

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

--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 05-09-2011, 06:10 PM
Elad
 
Default release criteria revisions

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.


--
-Elad.
--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 
Old 05-10-2011, 09:52 PM
Adam Williamson
 
Default release criteria revisions

On Tue, 2011-05-10 at 21:07 +0000, BeartoothHOS wrote:

> How is that paradigm meant to apply to those absent-minded souls
> among us who disremember what an otherwise familiar item is called? There
> are a bunch of things (in fact more as time passes, alas!, especially
> anent renamed ones) that I find by groping toward a mental picture of
> something "down over about there." My verbal memory is crammed with
> languages living and dead, but my pictorial memory has a little room left.

One, Matthias said 'primary'; the tree view still exists, it's just
expected that most of the time you'll find it more efficient to search.

Two, you can search on description as well as name, so if you know what
the thing does, you can probably find it.

> > Bingo! I was trying to recall history reading old mailing list posts,
> > but Adam nails it. That matches my recollection of where that criteria
> > comes from.
>
> Am I missing an obvious remedy?? Since it was considered, surely
> some remedy *was* found and accepted.

For the Other category? We have various approaches, discussed in the bug
report, but it's not certain we'll adopt any of them for release time.
One is to dump all the Settings category items in System Tools, another
is to retain the Administration and Preferences categories from F14, yet
another is to just have Preferences and have all Settings category
entries in there.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net

--
desktop mailing list
desktop@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/desktop
 

Thread Tools




All times are GMT. The time now is 04:19 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org