Re: [evolution-patches] Re: (no subject)

[<anna ximian com>]

Hi Guys:

(sorry for munged subject lines, etc -- I still can't quite make evo
send mail properly)

Rodney, basing accelerators on the letters used for shortcuts is, I'm
afraid, rather far from being a complete strategy. On the other hand,
the HIG offers us a complete strategy, which makes me much more inclined
to adopt (and then work to improve) its recommendations.

The following reasons that the "use the shortcut to determine the
accelerator" approach is a flawed methodology come to mind:

1)it isn't just menuitems (eg items accompanied sometimes by shortcuts)
that have accelerators ; almost every label in an accessible app should
have one. We need a methodology for assigning accelerators to widgets,
independent of whether or not they are menuitems. 2) there is no
guarantee that the letter used for the shortcut necessarily appears in
the word,  3) many menuitems don't have shortcuts, but do need
accelerators (and you haven't proposed a concrete, consistent way to
assign accelerators in that case),  4) shortcuts and accelerators are
different in scope, hence one is differently constrained when assigning
them (eg, I can use Ctl+E only once in my app, but I can use _E once per
submenu),  5) shortcuts don't necessarily use letters at all (eg, f9 for
send/recv),  6) shortcuts use keys like Shift and Alt to show
relationships between different menuitems (think of the relationship
between Ctl+K and Shift+Ctl+K) -- there is no way to represent or
account for this in a one character accelerator. They are fundamentally
different beasts, shortcuts and accelerators.

etc.

...

Now, I believe that Michael is right when he reminds us that the way a
label sounds is not always sufficient to determine what its accelerator
should be. To insist pedantically on using sound as the one and only
guideline for determining accelerators would be shortsighted. Yet, as a
base guideline, it is surely less flimsy than the
map-the-accelerator-to-the-shortcut approach -- for starters, at least
every label *has* sounds associated with it.

It is similarly true that HIG-ifying Evolution is a necessarily rocky
experience, because many of the guidelines presented in the HIG were
developed with the needs of smaller applications in mind. (A
particularly concrete example of where the HIG fails to provide us with
sufficient/useful information is in its padding and spacing guidelines
-- the HIG assumes that ~all windows are GtkDialogs, while Evolution
contains its own fair share of GnomeApplication windows, etc.) I agree
with you guys that it isn't a perfect tool.

You said in your mail, Rodney, that you haven't read much of the HIG,
but that you find it self-contradictory in places. Do you have specific
guidelines in mind? I can address them individually, if you do. In the
meantime, if you remain interested in doing gui work in Evolution, then
I think it would be worth your time to sit down and read the HIG. We
are, at this point (for better or for worse), entirely committed to
following its recommendations and trying to help it grow.

Anyhow, I stick by my recommendation that for now:
1. we follow the HIG to the letter on this issue,
2. we keep track of what problems we encounter in doing this, along with
what if any problems our users tell us they have with the accelerators,
3. and then we report back to the HIG people, to let them know exactly
how and where their guidelines fail.

regards,
Anna