The way /etc/X11/xinit/xinitrc.d/50-xinput.sh attempts to detect an xsettings manager is: function check_xsettings_manager() { case "$DESKTOP_SESSION" in *gnome|openbox|xfce4) return 1 ;; *) return 0 ;; esac } This is used in this context: check_xsettings_manager && which im-xsettings-daemon > /dev/null 2>&1 && im-xsettings-daemon & The im-xsettings-daemon take the selection and prevent gnome-settings-daemon from starting. So, if DESKTOP_SESSION is not set or happens to be any other value (besides the three handled by the code) imsettings breaks the session. The DESKTOP_SESSION variable is only the name of the desktop file that is used to determine the session to start. This probably breaks for any session not started by GDM, and certainly breaks any non-standard session: online-desktop, jhbuild, etc.
This is just broken. If you need to know if an xsettings manager is running, check for an xsettings manager, not for the kind of session. This reminds me of the time when im-settings would start its own session bus... Really, all this needs to be moved inside the session
So which session does it need to be moved inside? I was looking at xdg's autostart mechanism, which may be a common way, but all of WMs doesn't necessarily support that. doing something in the X session was better way to support them without extra works. I know this is an ugly hack though, then why don't we have only one xsettings manager that is capable to extend xsettings parameters with add-ons? I'm not an expert around this though, current situation that each desktops owns their xsettings manager sounds not good to me. there are no way of sharing the settings without patching out for every xsettings managers. applications plays different against the desktops. some features doesn't work on some desktop, which depends on xsettings, and so on. Is there any reasons we do/did not want to do that?
The very purpose of xsettings is to export each desktops own configuration through a desktop-neutral interface. So an xsettings manager must be implemented on top of each desktops configuration system. Having im-settings run its own xsettings manager doesn't make any sense whatsoever to me...
That sounds a bit inconsistent to me. how come the implementation of xsettings isn't the desktop-neutral? and that's not really an answer for my question. and if we can do that, I don't even have own xsettings manager in imsettings, but just could provide an add-on to plug into it. even if that has a pluggable mechanism, it could still be located to the desktops configuration system. that should be an advantage of the common xsettings manager and no one needs to re-implement the manager anymore.
the implementation of an xsettings manager is not desktop neutral, because it takes the settings from the desktop configuration system (gconf in the gnome case) and exports them as xsettings. If all desktops used the same configuration system, they could all use the same xsettings manager. But then, xsettings would not be necessary in the first place. However, that is not the world we live in.
Yes, but they could still provide the necessary settings as modules. some of them can be shared among the desktops, but some of them can't. my POV isn't to use all the same configuration for all the desktops. but to have a common xsettings manager for some shareable settings. desktop-specific configuration could be excluded with the certain way. Actually why I've had own xsettings manager in imsettings was, because I got an report that imsettings doesn't work on icewm. from your POV, are you saying that it was a bug in icewm and other WMs doesn't have a xsettings manager? even if they don't ship that nor support it?
No, I would say that imsettings not working with a barebones wm is a consequence of choosing xsettings as an implementation vehicle.
So what would you suggest?
I'd suggest to a) Just live with the fact that changing input methods on the fly won't work in 'barebones' environments. We don't make a big deal of the fact that changing gtk themes on the fly doesn't work in those enviroments either. b) Investigate if we really need 3 processes just to manage im-settings (im-info-daemon, im-settings-daemon and gconf-im-settings-daemon). In fact, looking at the whole input method picture, the bloat is even more astonishing... I see no less than 10 processes in my session related to this (scim-helper-manager, scim-bridge, scim-launcher, ...). Also, I notice imsettings-xim running even though I've selected scim - why is that ? c) Drop this: [ -x /usr/bin/gconftool-2 ] && /usr/bin/gconftool-2 -t string -s /desktop/gnome/interface/gtk-im-module "$GTK_IM_MODULE" || : It should not be necessary (thats what gconf-im-settings-daemon is for, right ?), and xinitrc.d scripts have no business messing with my gconf database... This is another case of unforeseen side-effects, since it causes gconfd to be started... d) Finally, I'd recommend to take another look at using autostart to get all this running. Overall, I'm left with the impression of a grotesquely complicated system, that has been constructed just because we can't decide on a single input method framework and make that work well with the desktop...
(In reply to comment #9) > a) Just live with the fact that changing input methods on the fly won't work in > 'barebones' environments. We don't make a big deal of the fact that changing > gtk themes on the fly doesn't work in those enviroments either. > b) Investigate if we really need 3 processes just to manage im-settings > (im-info-daemon, im-settings-daemon and gconf-im-settings-daemon). In fact, im-info-daemon and im-settings-daemon could be merged - I just wanted to have a separate namespace for different purpose. gconf-im-settings-daemon however may not. I don't like to make extra deps for other desktops. > looking at the whole input method picture, the bloat is even more > astonishing... I see no less than 10 processes in my session related to this > (scim-helper-manager, scim-bridge, scim-launcher, ...). Also, I notice I don't know the background of scim's architecture. but that should be different issue. nothing comes out of just talking about it as "Input Method processes is too much running", like GNOME/KDE links too much libraries. > imsettings-xim running even though I've selected scim - why is that ? That's an XIM server switcher. since the destination is determined at the startup time with XMODIFIERS, it's impossible to change the input method on the fly without a process between applications and a XIM server. > c) Drop this: > > [ -x /usr/bin/gconftool-2 ] && /usr/bin/gconftool-2 -t string -s > /desktop/gnome/interface/gtk-im-module "$GTK_IM_MODULE" || : > > It should not be necessary (thats what gconf-im-settings-daemon is for, right > ?), and xinitrc.d scripts have no business messing with my gconf database... Indeed yes, it should be. I don't remember why I added it. I'll let me test without it. > d) Finally, I'd recommend to take another look at using autostart to get all > this running. If I do accept a), yes, I can. then I need to think of the way to notice like "im-chooser/imsettings doesn't work on current desktop".
Fixed in 0.103.0-1.fc10.
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping