On Mon, Jul 15, 2013 at 12:21 PM, Osamu Aoki <os...@debian.org> wrote:
>
> Hi,
>
> I just installed FEDORA 19 to see how it should work according to them.
>
> On Mon, Jul 15, 2013 at 01:37:49AM +0800, Aron Xu wrote:
>> On Sun, Jul 14, 2013 at 8:04 PM, Osamu Aoki <os...@debian.org> wrote:
> ...
>
> For non-GNOME3 such as LXDE etc., im-chooser is attractive, but for
> GNOME3 no at this moment.
>
>> Personally, I think starting input method by the DE is the next to go,
>> i.e. done by gnome-settings-daemon and kdeinit/kded.
>
> I agree.  Basically sticking to the upstream decision is good idea.
>
> If KDE also start integrating IM setting, may be we should think about
> unified approach to such integrated DE.
>

Although KDE does not have plan so far, we can see this small kcm
module doing basically the same thing:
http://kde-apps.org/content/show.php/kcm+imchooser?content=146776&PHPSESSID=ca03e058b90

>> This enables the
>> DE to implement better integrated experience of input methods. For DEs
>> do not have this support, or people who don't use a DE, then tools
>> like im-config and imsettings are still needed. I believe this means
>> some detection on both sides to determine who should be responsible on
>> starting and maintaining IMs.
>
> I think simply disabling im-config for us is good idea.
> Let's discuss this at http://bugs.debian.org/654307
> Basically, create Blacklist for im-config baed on DE.
>
> 70im-config_launch to include something like:
>
> case "$BASESTARTUP" in
>   gnome-session*)
>     : # NOP
>     ;;
>   kde-session*) # what ever KDE sets.
>     : # NOP
>     ;;
>   *)
>     ... do what im-config used to do
> esac
>
> This is something needed for jessie !
>

I think we need to be careful on disabling im-config, as DE has the
ability to override variables at run time. We need to make sure the
user has an IM to be functional anyway, so it would be better to
define a method that the DE and signal tools like im-config to disable
itself.

>> > As for GNOME3 gnome-shell related GUI configuration, I found a post for
>> > similar issues on Ubuntu bug list for im-switch by Ma:
>> >  https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/875435
>
> I see.  That looks like what we experience now.
>
>> >  A better approach of supporting IBus and other IM framework is using a
>> >  separate UI.  The UI can be very native to DE concerned and it
>> >  communicates with the IM framework concerned through DBus.
>> >
>> >  I've found four existing examples:
>> >  https://github.com/tualatrix/fcitx-gimpanel (DE: Unity, IMF: Fcitx)
>> >  https://github.com/fujiwarat/ibus-gjs (DE: GNOME, IMF: IBus)
>> >  http://userbase.kde.org/Tutorials/Kimpanel (DE: KDE, IMF: Multiple)
>> >  https://github.com/csslayer/kimpanel-for-gnome-shell (DE: GNOME, IMF: 
>> > Multiple)
>> >
>>
>> I agree that separate UI can be the best idea of supporting different
>> situations, and in Fcitx we are using DBus as the canonical message
>> bus for virtually everything. An example is that Fcitx does not have
>> any indicator related dependencies, but it can appear in Ubuntu's
>> appmenu with full functions, this is just the opposite way that what
>> Ubuntu uses to implement ibus's indicator patch.
>
> As I checked FEDORA19, its default Setting GUI can select all iBus
> modules now.  But not for fcitx, SCIM, ....  But solving this should be
> outside of im-config.  The best we can do is not doing anything to
> interfare with them for integrated DEs.
>
>> (Note that fcitx-gimpanel is semi-abandoned and
>> kimpanel-for-gnome-shell is the recommended way of using Fcitx under
>> Gnome Shell.)
>
> I see.  How do you switch to kimpanel-for-gnome-shell?  Any GUI tool?
> Are they compatible with integrated ibus?
>

By installing and enabling the gnome-shell plugin. When the plugin is
running, Fcitx will switch to that UI on the fly. It does work with
IBus, but needs additional settings.

There is another way of handling UI of IMs in KDE, there is a plasma
component called KIMPanel, both Fcitx and IBus can use it as UI (maybe
also SCIM, not very sure), and KIMPanel itself is well integrated with
the desktop. Such component is also replaceable and there is a fork
called KIMToy which changed quite a lot from the original one. Fcitx
has the ability to switch among different UIs on the fly, so
KIMPanel/KIMToy isn't a problem.

> As to the original wishlist bug #716898,  this should be
>   "im-config: dynamic IM-setting classic WMs (non-GNOME3)"
> and this may be done by offering im-chooser for them while disabling it
> for GNOME3 and other IM setting integrated DE.  This is long term... if
> anyone find too much time to kill :-)
>
> Osamu
>


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to