[openbox] keyboard shortcuts for the root menu
danakj at orodu.net
Thu Jul 19 19:45:48 EDT 2007
On 7/19/07, Clay Barnes <clay at hci-matters.com> wrote:
> On 12:50 Thu 19 Jul , Dana Jansens wrote:
> > On 7/8/07, Jonas J Linde <jonas at init.se> wrote:
> > >And Jonas J Linde spoke unto the world. And said:
> > >>And Jonas J Linde spoke unto the world. And said:
> > >>>And Dana Jansens spoke unto the world. And said:
> > >>>>On 6/29/07, Jonas J Linde <jonas at init.se> wrote:
> > >>>>If you want to go ahead and make it do all the stuff I've talked about
> > >>>>here (exclusively use _, without the option) against the 3.4-working
> > >>>>branch in SVN that would be cool, or I can do it when I get to it as
> > >>>>well.
> > >>>
> > >>>OK, I'll start working on it.
> > >>
> > >>Here's a new patch - this one against the 3.4-working branch. Skipping
> > >>the shortcut color bit made the patch a lot simpler although switching
> > >>from & to _ made it seven times larger.
> > >>
> > >>I'll see if I can find a better way to use color instead of underline
> > >>and get back to you when I do.
> > >
> > >Hi again,
> > >
> > >So, here's the patch to allow menu.items.shortcut.color, (and optionally
> > >menu.items.active.shortcut.color, menu.items.disabled.shortcut.color and
> > >menu.items.active.disabled.shortcut.color) in the themerc file. I
> > >couldn't figure out a good way to remove an attribute from the Pango
> > >layout so it got a bit complicated with five layout attributes out of
> > >which only one is used at a time. I'm not convinced that this is the
> > >Correct Way to do it but at least it's a way.
> > >
> > >As I hinted previously, if menu.items.shortcut.color isn't set,
> > >underlining will be used instead so as not to break old themes.
> > >
> > >Would this be OK for inclusion in the next release?
> > So I've been thinking about it. I have a branch in my repository
> > right now with this functionality in it. I changed the theme element
> > names up, and did the code quite differently - the patch provided
> > broke all the render lib's (shotty) encapsulation. But I'm really
> > hesitant to add this still, because for 99.9% of users, when they turn
> > on this option, nothing will happen, and they will consider it broken,
> > and file a bug report. Maybe just using the opposite of the current
> > color would be better, like an xor operation does. I will continue to
> > think about it, but it might not show up in the next release.
> > Dana
> From an HCI standpoint, this option is a dangerous one. While
> well-chosen colors won't do much harm, theme designers and tweakers
> would have to be fairly well-versed in color theory to be able to make
> that selection well. For example, blue is focused in a different way
> than other colors, meaning a blue letter with the rest being black
> letters would render the blue letter surprisingly hard to read (unless
> shades and tones to the two colors are chosen very carefully).
> Additionally, many designers will be tempted to choose colors that are
> poorly (if at all) differentiable by people of limited color
> perception (color-blind, colloquially).
> I think we're much better off with the traditional underlining,
> despite its lower visibility in some cases.
Yeah, I agree with all of that, it's definitely an important
consideration. The only point against it is that it would be optional
(and default off). And color contrast is already a big issue in menus
with many themes.
More information about the openbox