Re: Again: please clarify the decision on IBus integration

[Aron Xu <aronxu gnome org>]

On Mon, Jul 9, 2012 at 10:51 PM, Rui Tiago Cação Matos
<tiagomatos gmail com> wrote:
> On 9 July 2012 16:27, Aron Xu <aronxu gnome org> wrote:
>> I know your wish is good, so I said it looks elegant. But in real
>> world it's not that easy to add another layer of abstraction as "input
>> sources" here.
>
> Why? Can you please elaborate on this?
>

So do you know what input method framework exactly do right now? You
can't think it's purely something like an application in GNOME, it was
a secondary class citizen but if you clearly understand how X server
handles user input, then it's at a higher level than usual GNOME
applications of the stack, which is at the same level of the X codes
which handles user input.

Input method is not a desktop environment's component, just like X,
it's a system wide stuff. Users can lost some specific experience of a
DE (say GNOME), but he/she must have the same input experience on
every part of the system (maybe we can limit to X in the mean time),
no matter if
there is GNOME, KDE, *box or even pure Xlib/XCB applications. In this
perspective, it's not GNOME to choose an input method to intergrate,
it's GNOME's job to intergrate with current IMFs better (if you really
want to make a difference). This also explains why you have found that
all
existing input methods tend to make themself cross platfrom, i.e.
working with all kinds of applications and maintain many things by
themselves. This is intended, this is what called user experience from
a system designer's perspective, and it's true stuff that users rely
on like X which should not be altered by a simple design assumption
from GNOME.


>> First of all, IMF is actually almost what you think as
>> "input sources", and XKB may be a part of it. In this way users can
>> switch between German XKB and Chinese (Pinyin) without problem because
>> they are all under the management of the IMF. Such kind of work has
>> been their for long in IBus, as you may know ibus-xkb.
>
> I do know about ibus-xkb and fcitx seems to also be growing that kind
> of functionality. I just don't agree that that makes sense in an
> integrated environment such as GNOME. Does GNOME offload its printer
> settings to some external component? What about its display device
> settings (monitor setups, resolution)? So why should we do it for
> "input sources"?
>

It does not make any sense that you think an intergrated desktop
enviroment like GNOME is able to handle the input events of the whole
system, but input method frameworks are designed to do that. GTK+
currently does not pass all keyboard input to IMF first and it's
proved to be broken (I see you may don't agree as you never met the
problems, but if you are an IMF user, you might already meet them for
quite some times). I've said that input method framework is something
at a lower level in the desktop stack, so I would like to ask you some
questions in the way you are asking me:  Does GNOME load printer
support from driver to configuration into its internal component? Dose
GNOME load the whole stack of X into its internal component?

For the questions you've asked me, I can answer that GNOME uses the
interface provided by lower level software to configure printers,
GNOME uses the interface provided by lower level software to setup
monitors, and screen resolutions. GNOME should use the interface of
IMFs to achieve better user experience, and you can push the interface
being established and standarlized - it's just not too complicated,
I'll talk about it later.

> IMO, IM engines are useful to translate/compose symbols from user
> input and an IM framework is useful so that we don't need to have
> different code for each of Chinese, Japanese, Korean or others. But it
> ends there. If you start offloading keybindings and other
> configurations then how do you make sure that the UI will be
> consistent with the remaining GNOME UI?
>

Yes, IM engines can be roughly though as "translators", but IM engine
is not the thing we are talking, IMF will handle it for system-wide
and user-wide usages, but not limited to GNOME in any mean. IM
framework is not a tool for you to ease your work and implement a
simple but does-not-work solution. You need to understand that IMF is
something deeper in the system stack than GNOME.

There are people proposed about the possibility of making a framework
of IMFs, I'd rather make it clear that it should be a standard
interface of IMFs, for various desktops to have better intergration
with them. This standard interface should be consist of how
configrations are exported, how keyboard shortcuts are managed, etc.
It's not a complete list, but this interface should provide enough
stuff for us to implement a nice UI and keyboard shortcut management
because we have a way to communicate with IMF, just like what we have
with XKB in X. Then GNOME can choose a team of IMF developers to work
on "reference implementation", hardcoding one of any IMF is not
feasible to fufill the needs.

It's again hard to understand that why not an IMF can be good enough,
or even why an IMF can hardly be improved to be good enough. At least
it costs a lot of years... When you are using a keyboard, then the XKB
mapping is in not about to change and you have almost no choice; but
for input method users, they can always choose from different
developers and vendors. If you are using mobile devices with
iOS/Android, you might know that there are many vendors providing
input methods, the basic functions are almost the same but you will
have a preferred one for some details. This is also true on Windows
and Linux, users are nit-picking and if you tried to limit their
choice then he/she must be angry with you, :-)



--
Regards,
Aron Xu