Remember, this is MaxGUI, which is generic, so we are coding below the exposed APIs...
Stating the obvious for any other readers - ths also means that the need to change current behaviour arises because current GTK behaviour differs from other maxgui implementations.
So... any ideas?
First a question, then some thoughts - is this information used anywhere? It almost looks like the purpose of this is for there to exist a single system-wide app that is used to define hotkeys - is that the case? (Not aware of one). Is this information ever visible to anyone to the best of our knowledge?
Okay, so there's no means to pass additional data in to use for the key maps, so it will have to be generated from existing information.
The most obvious starting point is the AppTitle - use this as at least part of the <WINDOWTYPE>. I guess ideally we would categorise all other windows used by an app, but no idea how we could do that. So maybe just use the window title used when first created? Or would it be simpler to use some kind of window ID (if such a concept exists in gtk?).
As for categories, a hotkey can always be linked to a gadget, e.g. a menu, a button, or for non specific hotkeys, presumably in effect linked to the base window? So category could be type of gadget.
Finally, the action can be derived from the gadget text, e.g. interrogate the menu structure to determine the menu item the key relates to is "File/Save As...", or just take the text of a button "Ok" or "Cancel". the problem will be what to name these...maybe just the name of the keyboard combo?
The issue with some of the above is that it could vary during runtime (e.g. window tile changes). Is that an issue? You'd probably have to track changes to the names of all the gadgets that could be affected and amend the hotkeys then - yuck:
Anyway, in summary:
<WINDOWTYPE> = AppTitle-WindowName
Category1 = GadgetType
Category2 = ~GadgetText
Examples:
MaxIDE-MaxIDE/Menu/File/Save As...
MaxIDE-Find/Button/Find Next
MaxIDE-MaxIDE/Window/Ctrl-Tab