[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Input method integration
From:       Andriy Rysin <arysin () gmail ! com>
Date:       2012-07-01 17:49:44
Message-ID: 4FF08DB8.5010900 () gmail ! com
[Download RAW message or body]

Keyboard layout module has a lot of things inside: there's daemon to 
watch switching windows and adjusting layout, it also listens to KDE 
shortcut for switching (if user prefers to use KDE shortcut instead of 
predefined xkb ones), it also listens to keyboard (and mouse) 
hot-plugging and reconfigures layout if keyboard has been inserted. 
There's the layout indicator widget which is used in screensaver lock 
dialog to allow user to switch layout when entering password. There's 
keyboard layout tray indicator. There's plasma applet indicator. There's 
KCM UI which allows to configure: hardware parameters (like repeat delay 
and rate and keyboard model), layouts, layout switching/indicator (e.g. 
flag/label), shortcuts to switch layouts, it allows to have spare 
layouts (xkb only allows to have 4 layouts at the same time congifured, 
spare layouts allow to have more and to have smaller number of main 
layouts with easy switch and some additional available in context menu). 
There's also xkb parameters configuration which allows user to fine tune 
their keyboard input.

Most of these features came from highly voted wish requests by the 
users. Replacing keyboard module completely with IM module will make 
sense only if none of this functionality is lost (or at least if it's 
replaced by similar or better one). I understand IM may provide higher 
level input configuration which is good but I doubt we can easily 
replace the keyboard module with IM without losing things along the way.

So far I can see the only way of integration is by allowing the user to 
switch to higher-level IM if needed, but leaving all current 
configuration intact. E.g. we could add a parameter "Configure as IM" 
e.g. by adding another tab "Input Method" where user can configure IM. 
if IM is configured the Layouts and Xkb options tabs will be 
automatically set based on IM needs (possibly making them read-only). If 
user does not need IM it'll work as is now.

Keyboard daemon can be extended to check if IM is activated and provide 
additional functionality for IM on top of xkb.

Also I know pretty much everything about keyboard module as I said I 
don't know much about IM and don't use it so I would need to see some 
technical proposal before I can estimate on how the integration can be done.

Regards,
Andriy

On 06/27/2012 12:43 PM, Weng Xuetian wrote:
> On Thu, Jun 28, 2012 at 12:24 AM, Andriy Rysin <arysin@gmail.com> wrote:
>> Hi Weng,
>>
>> I'm a maintainer of keyboard module and I'd like to see input methods
>> integrated in keyboard module. Although I am not sure about replacing
>> keyboard module altogether - it has a lot of features, I'm open to extending
>> it especially if it's done in modular fashion.
> First let me talk about why IMF need to manage layout. For example, if
> a people need to type German and Chinese together on the same machine,
> first he may want to change to german, and typing for some time, then
> he change Chinese Pinyin. And wait, what's the current xkb layout
> should it be? It should back to English (US) in most case, since
> german layout have some conflicts with Chinese Pinyin, and key
> position is different. For current implementation, the IMF itself
> change the layout setting automatically, and I think it would be
> better for most user.
>> Please note I know pretty much nothing about IM so I would need detailed
>> information on what is to be done.
> This is how fcitx manage keyboard layout and input method together
>
> http://wstaw.org/m/2012/06/27/plasma-desktoppg1860.png
>
> I'd like to see kcm_keyboard layout configuration part to take the
> same response for this.
>
> Xkb option (dead key, blablabla..) and the model, key repeat part need
> to be touched.
>> Could you please prepare a technical reasoning and details of proposed
>> changes so I and potentially others could evaluate the impact?
>>
> About my proposal:
> For first point, the reason behind making KDE take response start
> input method, is input method configuration is too hard for normal
> user. Specific environment variable [1], special auto start command.
> Distro provides some techinics to start IMF, ubuntu/debian have
> im-switch and im-config, opensuse use /etc/X11/xim.d, fedora have
> imsettings, from my experience, they are both broken in some case, but
> what for other distro, for example, arch, or some other distro, and
> IMF should be a necessary part of DE.
>
> For second point, the idea behind replace the layout configuration, is
> that if IMF take response of configure layout, the kded keyboard
> setting is conflict and duplicates with IMF itself, and IMF can track
> things in more detailed level, from "window" or "application" level,
> to "input context" level, which cannot be done with kded keyboard.
>
> So for kcm keyboard, if a IMF is choosed and available, it should
> present the IMF configuration, otherwise it can fallback to the old
> UI.
>
> [1] http://fcitx-im.org/wiki/Input_method_related_environment_variables
>
>>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<



>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]