Correct, utf8 is not currently supported by the code that deals with shortcuts, although displaying it in the menus does work.

I have a patch done that adds utf8 support. Just need to clean it up and do the doc changes. I've tested it as much as I can without a russian keyboard and running with en_US. Please be prepared (kak pioner) to test it some more and tell me if anything breaks.

-pasha

(In reply to Paul G from comment #1)
> I have a patch done that adds utf8 support. Just need to clean it up and do
> the doc changes. I've tested it as much as I can without a russian keyboard
> and running with en_US. Please be prepared (kak pioner) to test it some more
> and tell me if anything breaks.
> 
Good news! You may send this patch to me by e-mail.

Created attachment 3515 [details]
Adds support for utf8 menu accelerators

Support for utf8 menu accelerators implemented in the attached patch. Previously, you could only use alphanumeric ASCII as menu accelerators.

Note: There are 0 alterations to the default codepath, any changes are entirely predicated on utf8 support being enabled via config, so it can't break anything unless the user specifically requests it.

Patch adds:
  * Support for alphanumeric utf8 menu accelerators [off by default]
  * Support for graph (any-non-formatting/whitespace-printable) utf8 menu accelerators [off by default]
      (this enables them for ASCII as well, since ASCII is a subset of UTF8)

Testing:
  * I've tested this as extensively as I can without a keyboard where I can see what I'm typing with a layout other than 'us'. It seems robust/safe, especially since no changes were made to the default codepath.

Additional testing:
  Someone with the appropriate kb/locale/use case should test further. Stick the following in your menu.xml:

---
		<menu id="test" label="_Пробное">
		    <item label="Бац">
				<action name="Execute">
					<command>
						notify-send Бац OK
					</command>
				</action>
	            </item>
		    <item label="_.Бац">
				<action name="Execute">
					<command>
						notify-send .Бац .OK
					</command>
				</action>
	            </item>

		</menu>
---

Without anything new in your rc.xml, you should be seeing current master behaviour. With utf8Enabled enabled in the menu section of rc.xml, "_Пробное" should work and "Бац" should work, while "_.Бац" should not. With utf8AllowGraph additionally enabled, "_.Бац" should now work as well.

If you'd rather clone than patch, my current patchset against Mikachu's master is always going to be at: https://github.com/paulie-g/mikachu-openbox

(In reply to Paul G from comment #3)
> Created attachment 3515 [details]
> Adds support for utf8 menu accelerators
It works fine at me. I test also with ukrainian letters under russian locale, no problem.

But what is the meaning in the introduction of the new settings?  All Linux distributions use now utf8 as system encoding, it would be natural to improve unconditional utf8 support in the menu. New setting is the unnecessary problems for the user, this is some extra lines of the code.
What bad can happen if uft8 will certainly enabled?

(In reply to Alexey Korop from comment #4)
> (In reply to Paul G from comment #3)
> > Created attachment 3515 [details]
> > Adds support for utf8 menu accelerators
> It works fine at me.

Great!

> I test also with ukrainian letters under russian
> locale, no problem.

Imperialist ;)
 
> But what is the meaning in the introduction of the new settings?  All Linux
> distributions use now utf8 as system encoding, it would be natural to
> improve unconditional utf8 support in the menu. New setting is the
> unnecessary problems for the user, this is some extra lines of the code.
> What bad can happen if uft8 will certainly enabled?

I was just trying to improve the chances of the patch being applied. If it can't possibly break anything unless the user affirmatively enables it, maybe it'll make it in quicker. There may be a release soon and I'm hoping for it to be included in it. All the maintainer has to do to enable utf8 support by default, if he chooses to do so, is change 'no' to 'yes' for utf8Enabled.

The second setting needs to be off by default because it can change which character is used automatically as an accelerator for people who use plain ASCII and I consider it undesirable to break backwards compatibility for existing configs without very good reason. Most people won't want to use, say, punctuation as accelerators, but the option is there for people who do. It may also transpire that glib is wrong about whether something is alphanumeric in a given language and this option will enable the user to fix it herself.

On a related note, are there any more utf8 compatibility issues elsewhere in ob, say with keyboard bindings?

(In reply to Paul G from comment #5)
> On a related note, are there any more utf8 compatibility issues elsewhere in
> ob, say with keyboard bindings?
  Near upon. There is the old annoing problem with accelerators if multilayout keyboard used, independent of the utf8 enabling. Active layout may not correspond to the defined accelerators When the menu is displayed. 
  For instance my layouts are "en,ru,ua" and all accelerators are in latin. When I call some menu it is probable that current layout is not "ru" or "ua" and accelerators not works before I manially switch layout to "en".
  Long ago I create the patch that solve this problem. This patch add the global parameter to define the layout number that must be activated when the any root level menu is displayed. F.i. <TopMenuKbdGroup>0</TopMenuKbdGroup>. But now (after utf8 support improved) I want to add a similar setting for the individual menu. I plan post this patch (as separate bug ticket) in a few days.

(In reply to Alexey Korop from comment #6)
Sorry, mistake:
> current layout is not "ru" or "ua"
Must be: 
  current layout is "ru" or "ua"

(In reply to Alexey Korop from comment #6)
> I plan post this patch (as separate bug ticket) in a
> few days.
Done - bugs 6371, 6372.