Keyboard shortcut themes

[Brian J. Tarricone]

On Sun, 31 Aug 2008 19:07:04 +0200 Jannis Pohlmann wrote:

> Hey,
> 
> I'm kind of back working on the alpha release and the keyboard
> shortcuts of xfwm4 in particular. However, it occurs to me that the 
> keyboard themes which we have in both xfwm4 and the command shortcuts 
> make things overly complicated, especially if we want to avoid 
> conflicts between xfwm4 and command shortcuts.
> 
> Before we can finish this several questions have to be answered:
> 
>  a) Do we want to share themes between xfwm4 and the command
>     shortcuts?
>  b) If a), how do we make this behaviour transparent to the
>     user? Just imagine a user creates a new theme in xfwm4 and loses
>     all his command shortcuts because the command shortcuts are now
>     empty or copied from a default theme?
>  c) If not a), how do we handle conflicting shortcuts? Imagine there's
>     one xfwm4 theme and two command themes and the user creates a new
>     xfwm4 shortcut - what if this shortcut already exists in one of
>     the command themes?
> 
> The way I see it, there are four possible solutions: the good (2x),
> the bad and the ugly:
[...]
> Are there any other good ones you can think of? What are your
> opinions anyway?

I can think of an "almost good" solution:

Leave the dialogs separate as they are, and support independent key
themes for both of them.  When the theme is changed and the manager
goes and does XGrabKey() for each key, watch for BadAccess errors.  For
each key that generates BadAccess, store it in a list somewhere.  When
finished trying to grab all keys, check that list and display a list of
failed keybindings to the user, pointing them to the other dialog if
they want to figure out what's hogging the key (if they're using a
separate app, e.g. xbindkeys, to manage keybindings, they're on their
own figuring it out).  Maybe color the treeview rows a different color
or put an error icon in the rows to show there's something wrong.

Pros: Behavior very similar to 4.4.x, so no one will complain that we
took features away or changed things such that they're now confusing,
and there shouldn't be much new code to write.  Key grabs are checked
for success/failure, and failures are reported to the user so they can
possibly try to see what's going on.

Cons: The current (4.4.x) keytheme stuff is pretty unintuitive IMO, so
leaving things the way they are is probably not a 'pro'.  Conflicts are
(sometimes) only caught when the user applies a theme, not
necessarily when they initially set up the keybinding.

	-b