[Gtkradiant] Re: IShortcuts

[Timothee Besset]

This goes hand in hand with a rewrite of the way we handle the keyboard
internally. Right now most commands are binded to keys using "keyboard
accelerator", which is a Gtk feature. And some commands are still handled
the "usual" way (i.e. by reading the keys / modifiers and comparing
against an array).

This is rather heterogeneous and I would like to see a way to get rid of
the keyboard accelerator code. Ideally all key events would go through a
central API in Radiant where they would be processed. The API would
provide ways to the app and plugins to register their key combinations. We
will also need a strategy to resolve conflicts (i.e. several commands
getting bound the same key combination / not interpreting the same way
depending on where the focus is etc.)

I would like to see a blunt cleanup of all the keypress_event binds, and
just dump keypresses to the console and see what happens / what info we
get. Then see how it behaves with inspectors / entity dialogs / floating
windows / plugin windows. Then start writing an API describing how we want
the new keyboard stuff to work. 

We want two ways:
- by events (typically keyboard shortcuts to execute something)
- by polling (query the keyboard state .. typically for camera movement etc.)

TTimo

------------------------
> IShortcuts:
>
> API for plugin modules to register certain key combinations as "shortcuts"
> to call functions implemented by the plugin
>
> Basic functionality:
>
> plugin submits a key combination (along with an integer command ID) to
> radiant. Radiant independently decides whether the key combination is
> valid to use as a shortcut. If Radiant decides the key combination is ok,
> it associates the key combination with the plugin handle and the command
> ID. Subsequently, whenever the key combination is activated, the
> associated plugin handle and command ID are used to call the plugin
> function