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 674874 - don't read .xmodmap files by default
don't read .xmodmap files by default
Status: RESOLVED FIXED
Product: libgnomekbd
Classification: Core
Component: Config
unspecified
Other Linux
: Normal normal
: ---
Assigned To: libgnomekbd maintainers
Sergey V. Udaltsov
Depends on: 674221
Blocks: 523057
 
 
Reported: 2012-04-26 13:33 UTC by William Jon McCann
Modified: 2017-07-17 18:26 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description William Jon McCann 2012-04-26 13:33:23 UTC
Currently we read a set of xmodmap files from HOME
                gchar *xmodmap_file = g_build_filename (g_get_home_dir (),
                                                        XMODMAP_KNOWN_FILES
                                                        [i],
                                                        NULL);

This probably not a great idea because it can silently break the user's input and there is no way to fix it from the UI.

Perhaps we should ignore them by default.
Comment 1 Sergey V. Udaltsov 2012-04-26 13:46:40 UTC
Before, we had that setting in g-s-d (configurable in gconf) - the list of "well-known" xmodmap files. It was enough just to make that list empty in gconf. Then, it was removed:

http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/keyboard/gsd-keyboard-xkb.c?id=4239cb8a5d73af79d2cdf0f294a33d31fbbb9afe

Are you saying it should be returned back?

Of course, dropping .xmodmap support is not an option.
Comment 2 Bastien Nocera 2012-04-26 14:17:29 UTC
(In reply to comment #1)
> Before, we had that setting in g-s-d (configurable in gconf) - the list of
> "well-known" xmodmap files. It was enough just to make that list empty in
> gconf. Then, it was removed:
> 
> http://git.gnome.org/browse/gnome-settings-daemon/commit/plugins/keyboard/gsd-keyboard-xkb.c?id=4239cb8a5d73af79d2cdf0f294a33d31fbbb9afe
> 
> Are you saying it should be returned back?
> 
> Of course, dropping .xmodmap support is not an option.

That code should be removed, and we should add code to gnome-settings-daemon to call the hotplug script for keyboards too. See bug 674221.
Comment 3 Bastien Nocera 2012-04-26 14:18:57 UTC
(In reply to comment #2)
<snip>
> That code should be removed, and we should add code to gnome-settings-daemon to
> call the hotplug script for keyboards too. See bug 674221.

Which to happen needs libgnomekbd to do _nothing_ on keyboard plug, otherwise you'll end up breaking what people put in the scripts...
Comment 4 Sergey V. Udaltsov 2012-04-26 14:23:15 UTC
libgnomekbd should definitely configure new keyboards with the layouts specified in the g-c-c.

AFTER that, xmodmap settings should be applied (directly, using explicit xmodmap support - or indirectly through the script). I do not mind replacing xmodmap execution with the script execution - that does the job anyway.
Comment 5 Bastien Nocera 2012-04-26 14:34:00 UTC
(In reply to comment #4)
> libgnomekbd should definitely configure new keyboards with the layouts
> specified in the g-c-c.

gnome-settings-daemon should be asking libgnomekbd to do it then. Otherwise there's two things racing to set layouts, etc. on keyboards.

1. launch pre-script
2. tell libgnomekbd to set the layouts
3. launch post-script

But we need libgnomekbd to stop touching devices unless it's been asked to. That means anything in the "device-added" signal handler needs to be made something for gnome-settings-daemon to call.
Comment 6 Sergey V. Udaltsov 2012-04-26 14:52:23 UTC
Currently the model is

1. libxklavier is notified by XKB
2. g-s-d notified by libxklavier's signal (X-new-device)
3. g-s-d configures XKB (apply_xkb_settings)
4. g-s-d invokes libgnomekbd's xmodmap support (gkbd_keyboard_config_patch)

So, between #2 and #3 g-s-d can invoke pre-script. And instead of #4 g-s-d would call the post-script. Is that fair?
Comment 7 Bastien Nocera 2012-04-26 18:39:35 UTC
I thought that there was no need for a pre-script. gnome-settings-daemon fixed in master, up to you now.
Comment 8 Sergey V. Udaltsov 2012-05-04 22:26:33 UTC
Agreed. The function is removed from libgnomekbd.

Actually, not that kbd code in g-s-d and g-c-c is under heavy redesign (with the vision to enhance ibusability) - I am totally prepared to pass the ownership of libgnomekbd to anybody interested. It only makes sense as a helper library for g-s-d and g-c-c, these 2 projects should drive the requirements to libgnomekbd...
Comment 9 soulsonceonfire 2017-07-17 18:26:52 UTC
So how do I enable those scripts? where is the documentation?