Keyboard shortcut themes

[Jannis Pohlmann]

On Sun, Aug 31, 2008 at 10:59:35PM -0700, Brian J. Tarricone wrote:
> 
> 
> 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.

Doable, but ...

> 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.

Cons: Yeah, still the same unintuitive behaviour. Maybe it wasn't such a
good feature to introduce in the first place. Confusing behaviour: When 
switching command shortcut themes we can tell the user that some 
shortcuts are already used by xfwm4. But after the next login these will
work and those of xfwm4 won't because xfce4-settings-helper is started 
before xfwm4. 

IMHO it's better to avoid conflicts (except for those introduced by
xbindkeys) rather than trying to resolve them. Especially since if we
still are to use themes resolving means to aid the user in resolving
them manually. I'd rather keep things simple. The design is overly
complex and therefor we should get rid of it unless there's a clean way
to keep it.

  - Jannis