[openbox] keyboard shortcuts for the root menu

[Dana Jansens]

On 6/29/07, Jonas J Linde <jonas at init.se> wrote:
> Hi,

Hello!

> Thanks for a great window manager.

Heh, thank you :)

> I was happy to find that the 3.4 version had keyboard shortcut support
> for the menus built in so that I could retire my own not quite finished
> patch for that purpose. However, I would really like the shortcut
> specification feature that is available in the client menu to also be
> available in the root menu. And, while I'm at it, I'd prefer to have the

Originally I was thinking of generated menus, like the Debian menu, or
menumaker menus, and how these would not be generating shortcut keys,
so Openbox had better pick some nice defaults.  But I guess a lot of
people do build menus by hand, and this could be really handy.

> shortcut character rendered with a different color instead of being
> underlined.

We'll come to this later..

> So, I've made a patch against 3.4.2 that achieves those goals. It allows
> underscore ('_') in addition to ampersand ('&') as the character to
> specify the shortcut (as excessive use of ampersands gets kind of ugly

If &'s are no good in an XML file, I'd rather just use _'s
exclusively, instead of both.  Right now there is no use of &'s
outside of the C code itself, so it wouldn't break anything to change.
 Just a search and replace of all the translation files.

> in xml). It also adds two configuration options; one boolean <shortcuts>
> tag that goes into the <menu> section and one <shortcutColor> tag that
> goes into the <theme> section within the <font place="MenuItem"> tag.

Originally, with the &'s, I also envisioned it actually showing up in
menu items and being confused for a highlight, and so it made sense to
me to just not let you highlight, and have Openbox just use the first
letter.  But I see _'s ending up in human-friendly descriptions a lot
less than &'s, so I'm not sure we need an option at all for this.  I'd
prefer to just have the option always there for you, if you want to
use _'s, and if not, well no harm done.

> If the shortcuts boolean isn't true the root menu won't be parsed for
> shortcut specifiers and if the shortcutColor string isn't set
> underlining will be used when rendering the shortcuts.

The coloring is a bit more problematic.  Specifying colors in your
config file is a really ugly thing IMO because that option is only
going to work with 1 theme.  It needs to be a part of the theme.  The
problem here is that I don't see a way to derive a default color for
this from older themes.  So, essentially, it would not work well in
any themes that didn't explicitly get made with support for it in the
future.  I don't want to add features to the 3.4 series that
essentially break with any existing themes, and I don't want to make a
hacky option that is theme-specific in the config file, so I don't see
this one happening right now.  Maybe in the future beyond 3.4 (which
is currently being worked on a little and thought about).

> It would be great to get this patch applied to an upcoming version, so
> please let me know if there is something I should change to make it
> acceptable.

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.  (In SVN there was a slight change in the menu code which would
be relavant to this - where explicitly chosen highlights would be
underlined, but default ones (ie first character) would not be.)

What do you think?

Dana