[openbox] keyboard shortcuts for the root menu

Clay Barnes clay at hci-matters.com
Thu Jul 19 15:12:04 EDT 2007

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.

Clay Barnes


GPG Public Key:  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://icculus.org/pipermail/openbox/attachments/20070719/c8892b7a/attachment.pgp>

More information about the openbox mailing list