After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 108021 - Merge gkb functionality into control-center
Merge gkb functionality into control-center
Product: gnome-control-center
Classification: Core
Component: general
Other other
: High enhancement
: ---
Assigned To: Control-Center Maintainers
Control-Center Maintainers
Depends on:
Reported: 2003-03-10 18:21 UTC by Andrew Sobala
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement

Description Andrew Sobala 2003-03-10 18:21:17 UTC
It should be possible to change keyboard types in the control center, since
this is a much more intuitive place to change a desktop setting.
Comment 1 Havoc Pennington 2003-03-10 18:28:17 UTC
If we do that the keyboard layout backend stuff needs to move out of
gnome-applets. Probably makes sense.
Comment 2 Christian Rose 2003-03-10 18:29:40 UTC
Gswitchit (, a gkb replacement
available in GNOME cvs in the module "gswitchit", already has a
control center page. Perhaps gkb should be replaced by gswitchit in a
future GNOME release.
Comment 3 Andrew Sobala 2003-03-10 18:44:04 UTC
> Perhaps gkb should be replaced by gswitchit in a future GNOME release.

That would be worth bringing up in the soon-to-come GNOME 2.4 module
GEP. Not much point discussing it further in a bug, though; it belongs
on mailing lists.
Comment 4 Sergey V. Udaltsov 2003-03-10 20:38:22 UTC
I don't mind to discuss this in any mailing list - just let me know
where. Will desktop-devel-list be ok?
Comment 5 Andrew Sobala 2003-03-10 20:59:49 UTC
Probably. But note:

The code exists.
Comment 6 Sergey V. Udaltsov 2003-03-12 17:10:41 UTC
The code? Which code? In a very best case it puts gkb properties into
control-center. But I highly doubt (would be glad to be wrong at this
point) it makes gkb revolutionary better in xkb area. Actually, gkb is
good for X servers without xkb extension - but it does not use all the
xkb sweetness.

Well, the current situation seems to be more or less ok. For gkb is
good enough for _all_ cases (including proprietary X servers,
including hardware X terminals). But distributions shipped with XFree
are able to take gswitchit from 5th toy and have all its advantages.
Or is this bad?
Comment 7 Jody Goldberg 2003-03-13 04:51:43 UTC
Sergey I don't understand your comment.  My patch adds a capplet
wrapper to gkb-new and another will move the keybinding that switches
the layouts from gkb into the settings daemon.  All of the current
data remains where it is for now.

Can you expand on what you mean ?
Comment 8 Sergey V. Udaltsov 2003-03-13 11:44:32 UTC
One can customize gkb endlessly (in Control Center or anywhere else).
The facts about gkb are:

1. (-) gkb is not xkb-aware. It just invokes setxkbmap to change the
WHOLE XKB CONFIGURATION. It is expensive thing - to reload the whole
config. Instead of just calling a couple of xkb functions to change
the group.

2. (-) gkb does not take advantage of all the available xkb options
(related to indicators, special keys, ...). It just does not have
configuration repository to know about these things. Some while ago
gswitchit introduced the module xfree86.xml (now it is in XFree 4.3.0)
to make the UI configuration tools development easier. libxklavier
gives some API to access this repository.

3. (-) gkb currently does not allow per-window layout tracking. And it
makes sense - since setxkbmap invocation is expensive, it would be not
too nice to call it on every window switch.

4. (+) Not bound to xkb, gkb can use ANY number of layouts. gswitchit
sets up xkb configuration only once - so it is limited by 4 groups.

5. (+) gkb works in environments where xkb is not available. In Xnest,
in old/proprietary X servers.
Comment 9 Jody Goldberg 2004-02-19 17:30:09 UTC
This has been done.