Hi,
I have a problem on upgrading to f18 for the input method because of the new feature, the input source on GNOME 3.6. IBus is now managed under GNOME by that feature but there are no compatibilities between older IBus configuration and GNOME's. in addition to it, there are no IME nor the shortcut key by default for certain languages. also heard that we won't ship gnome-initial-setup in f18 (assuming that it's responsible to setup for them too). thus, those matters introduces IBus won't work until one set up on gnome-control-center, which is obviously an regression.
One positive idea to migrate the configuration is to use gsettings command line tool for initial boot and my questions is:
1) is there any possible issues if any script changes something through gsettings?
2) if not, where would it be better to do? in /etc/X11/xinit/xinitrc.d ? or via XDG autostart?
3) or is there any better idea to address this issue?
TIA, -- Akira TAGOH
On Thu, 2012-09-27 at 17:19 +0900, Akira TAGOH wrote:
I have a problem on upgrading to f18 for the input method because of the new feature, the input source on GNOME 3.6. IBus is now managed under GNOME by that feature but there are no compatibilities between older IBus configuration and GNOME's. in addition to it, there are no IME nor the shortcut key by default for certain languages. also heard that we won't ship gnome-initial-setup in f18 (assuming that it's responsible to setup for them too).
We've pushed the initial-setup integration until f19, yes. I want to start looking into it soon in rawhide. But gnome-initial-setup doesn't have input sources configuration currently, anyway. It is something we need to add.
thus, those matters introduces IBus won't work until one set up on gnome-control-center, which is obviously an regression.
One positive idea to migrate the configuration is to use gsettings command line tool for initial boot and my questions is:
- is there any possible issues if any script changes
something through gsettings?
- if not, where would it be better to do? in
/etc/X11/xinit/xinitrc.d ? or via XDG autostart?
- or is there any better idea to address this issue?
I would be hesitant to put too much of hack back in place, when the initial-setup is almost there already. Scripts in /etc/X11/xinit are basically outside the session, and not a good solution; you'll have to struggle with not making them run in other desktops, etc etc. Any solution that involves writing settings at login is going to increase our already slow login time by forcing dconf to be launched.
If we absolutely need to have a solution that derives a default input source from the display language (which you still have to set up initially, anyway), I would suggest to do it inside the settings-daemon plugin, and only if we detect a 'pristine' system, ie no input sources configured at all.
Rui, Allan, what do you think ?
----- Original Message -----
If we absolutely need to have a solution that derives a default input source from the display language (which you still have to set up initially, anyway), I would suggest to do it inside the settings-daemon plugin, and only if we detect a 'pristine' system, ie no input sources configured at all.
We already do that, kind of, as we use the XKB configuration from the X server to set the default input-sources.
I don't understand how this would have worked in the past. Would you have applied just the iBus configuration, just the XKB configuration, both? Where's the list of language to input sources matches?
Anaconda could also drop the default layouts in a GSettings overlay, and we wouldn't have to do anything special.
----- 元のメッセージ ----- | | | ----- Original Message ----- | > If we absolutely need to have a solution that derives a default | > input | > source from the display language (which you still have to set up | > initially, anyway), I would suggest to do it inside the | > settings-daemon | > plugin, and only if we detect a 'pristine' system, ie no input | > sources | > configured at all. | | We already do that, kind of, as we use the XKB configuration from the | X server to set the default input-sources. | | I don't understand how this would have worked in the past. Would you | have applied just the iBus configuration, just the XKB | configuration, both? Where's the list of language to input sources | matches?
What I'm mainly concerned are ibus. if we can have additional input source for ibus for certain languages, that would be nice though. that said it's a little another story. even if we have the sort of the table of the input source for ibus corresponding to the language, it may still introduces a regression in some cases. all of the necessary information for migration is in the ibus's configuration and it may be not necessarily same to what we expect. I suppose it can be migrated by rule. but I wasn't sure where it should be done.
If Matthias's idea is the way to go, we could add another path for upgrading: if the ibus's configuration is available, use it otherwise pick up from the table according to the display language say.
-- Akira TAGOH
On 28 September 2012 06:10, Akira TAGOH tagoh@redhat.com wrote:
If Matthias's idea is the way to go, we could add another path for upgrading: if the ibus's configuration is available, use it otherwise pick up from the table according to the display language say.
I agree that this is the way to go. See the following bugs:
https://bugzilla.gnome.org/show_bug.cgi?id=685457 https://bugzilla.gnome.org/show_bug.cgi?id=685458
Rui
----- 元のメッセージ ----- | On 28 September 2012 06:10, Akira TAGOH tagoh@redhat.com wrote: | > If Matthias's idea is the way to go, we could add another path for | > upgrading: if the ibus's configuration is available, use it | > otherwise pick up from the table according to the display language | > say. | | I agree that this is the way to go. See the following bugs: | | https://bugzilla.gnome.org/show_bug.cgi?id=685457 | https://bugzilla.gnome.org/show_bug.cgi?id=685458
Great! thanks for the quick work.
| | Rui | -- | desktop mailing list | desktop@lists.fedoraproject.org | https://admin.fedoraproject.org/mailman/listinfo/desktop
-- Akira TAGOH
desktop@lists.fedoraproject.org
-
Akira TAGOH -
Bastien Nocera -
Matthias Clasen -
Rui Tiago Cação Matos