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 725038 - .XCompose is ignored
.XCompose is ignored
Status: RESOLVED NOTABUG
Product: gnome-settings-daemon
Classification: Core
Component: keyboard
3.10.x
Other Linux
: Normal normal
: ---
Assigned To: Rui Matos
gnome-settings-daemon-maint
Depends on:
Blocks:
 
 
Reported: 2014-02-24 04:46 UTC by Seán de Búrca
Modified: 2015-05-13 20:26 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
Custom compose file (125 bytes, text/plain)
2014-02-24 04:46 UTC, Seán de Búrca 		Details

Description Seán de Búrca 2014-02-24 04:46:19 UTC 
Created attachment 270088 [details]
Custom compose file

I have a .XCompose file in my home directory to create custom compose sequences, but the file is ignored and only the default compose sequences are available. .XCompose should be read and respected.
Comment 1 Bastien Nocera 2014-11-10 00:07:39 UTC 
Completely correct, you'll need to load it yourself, such as with such a script:
https://git.gnome.org/browse/gnome-settings-daemon/tree/plugins/common/input-device-example.sh
Comment 2 Rui Matos 2014-11-10 12:49:50 UTC 
Just a clarification: ~/.XCompose is loaded and processed by Xlib and/or the application toolkit. There's nothing for the desktop environment to do about it.
Comment 3 Bastien Nocera 2014-11-12 10:04:37 UTC 
(In reply to comment #2)
> Just a clarification: ~/.XCompose is loaded and processed by Xlib and/or the
> application toolkit. There's nothing for the desktop environment to do about
> it.

My mistake, .Xmodmap is loaded through a script as in comment 1, .XCompose isn't.
Comment 4 Seán de Búrca 2015-05-13 20:02:09 UTC 
(In reply to Rui Matos from comment #2)
> Just a clarification: ~/.XCompose is loaded and processed by Xlib and/or the
> application toolkit. There's nothing for the desktop environment to do about
> it.

Is this an issue for gtk+, then?
Comment 5 Rui Matos 2015-05-13 20:06:44 UTC 
(In reply to Seán de Búrca from comment #4)
> Is this an issue for gtk+, then?

It's an application issue.
Comment 6 Seán de Búrca 2015-05-13 20:26:01 UTC 
(In reply to Rui Matos from comment #5)
> (In reply to Seán de Búrca from comment #4)
> > Is this an issue for gtk+, then?
> 
> It's an application issue.

Obviously this doesn't mean that every application needs to explicitly declare that it supports custom user .XCompose. As it currently stands, none of my GNOME-based applications support ~/.XCompose, so the question becomes where in the stack this belongs, and I don't think "in every application" is the correct answer.