Unify keyboard shortcuts

[Owen Taylor]

On Sat, 2003-08-16 at 09:57, Thomas Leonard wrote:
> On Sun, Aug 03, 2003 at 12:26:29AM +0200, Ellis Whitehead wrote:
> > This would probably be quite easy from the KDE side.  We currently have all 
> > the general shortcuts (i.e., not those for a single specific application) in 
> > ~HOME/.kde/share/config/kdeglobals, but there would be nothing preventing us 
> > from reading and writing to another location or with another format.
> 
> Sounds good. I think we just need to move the [Keys] section to its own
> file ($XDG_CONFIG_DIRS/freedesktop.org/common_shortcuts?).
> Should [Global Shortcuts] be shared too?
> 
> Are the key names the same between KDE and GTK? GTK uses keys in the form
> <Ctrl>S, which is easy to convert, but some of the special keys might have
> different names (or is everyone using XKeysymToKeycode?).

Using the X names for the key symbols seems natural enough that I doubt
anybody does anything different.

> What happens if the config file is missing? Does the user get no default
> keys, or does each application fall back to doing its own thing?
> I suppose the GNOME or KDE libraries would just symlink it to their own
> defaults file if it was missing, whichever was run first.
> 
> Can the user change a default key from a specific application? What
> happens if I change Save from Ctrl+S to F3 in my text editor, and then
> change it back? Does it go back to following the global defaults?
> 
> How are applications notified of a change? I guess we could require them
> to be restarted for now, and use DBUS for real-time updates later...

We'll have to solve the cross-desktop config key issue at some poin.
(XSETTINGS is basically an attempt to make an end-run around the
problem by simplifying the problem to read-only export of keys
set by some unknown mechanism). The answer probably involves DBUS.
But I don't think it involves a local INI file and a "reread"
message.

I think starting stating to use INI files for config in XDG 
specs rather than  just data storage (desktop, icon theme files) 
would be a mistake at this point; the move from INI files to GConf 
in GNOME brought real tangible benefits:

 - Per-directory change notification
 - Network transpareny
 - Centralized caching
 - Potential ability to do atomic changes of multiple keys

Perhaps trying to solve the shortcut problem prior to resolving
this is premature. Though certainly starting work on specifying
the problem wouldn't hurt.

 - What types of keys are being considered?
 - What specific keys should be in the "global key name registry"?
 - What is the intended set of user interfaces that this 
   supports? Can keys be changed from the UI of individual
   apps rather than just globally?
 - For application accelerators, how does conflict resolution
   work? If I change File/Save to something other than Control-S,
   it's pretty likely to conflict with other accelerators in
   many applications.

The mechanism seems, in some sense, to be the trivial part, since
it just involves a big global database of name=>key binding
pairs, which can be read, and written(?). 

> > I have no idea about how Gnome does it, but would be glad to work on a
> > common solution.
> 
> Does GNOME do this at all at the moment?

Well, GNOME does various different things:
 
 - A large number of specific key shortcuts are configurable through
   GConf; things like launching the panel menu or 

 - There is the notion of a "key-theme" for GTK+ that configures
   widget bindings. You can switch the current key theme through
   XSETTINGS, but you have to 

 - Application shortcuts (Save) are not generally configurable in
   GNOME apps. GTK+ has a mechanism for doing this for individual
   apps which is generally turned off in GNOME. 

I'm not really sure what keys are under consideration here. 
The "launch a panel" part doesn't seem important for cross-desktop
configuration.

If the emphasis is solving the other two issues, it actually becomes
more of a GTK+ issue than a GNOME issue in that most of the needed
modifications would be at the GTK+ level.

Regards,
						Owen