Re: 3.6 Feature: IBus/XKB integration

在 2012年5月13日 星期日 02:19:25,Benjamin Otte 写道:

> Marguerite Su <i <at>> writes:

> > what if after one or two years, a brand-new IM comes.

> >

> > then you guys will remove all ibus codes and start what you do today

> > again?

> >

> > and after another one or two years, again again.

> >

> > then it becomes you guys' life-time career to fix bugs and reinvent the

> > wheels.

> Yes, that is exactly what I do.

> In fact, I enjoy it a lot to port to a new and better solution and making

> sure that solution works really well [1] than trying to be compatible with

> lots of different options.


> If one chooses a single target, one has a lot of advantages:

> - Tight integration is possible.

> - One can rely on certain behaviors of that target

> - New features can be used immediately

> - We have a single point of contact for discussions about the future


> Of course, this also requires a lot of things working well between that

> single target and GNOME:

> - A target that is working well for all use cases

> - A willingness from both sides to cooperate

> - A working relationship between the involved people


> You can find a lot of examples where this works very well [2] and of course

> I can also come up with some where it didn't work and we needed to change

> things and start over. [3]


> So what I think we as the GNOME project want to see happen is that we find a

> team that is excited to work with us on improving input methods in GNOME

> applications. [4] If that project is called IBus, fcitx, XIM or is

> something that is redone from scratch, I don't know. I also don't know if

> the project of choice will be ready as-is or will need significant

> improvements. I also don't consider myself the person to decide it.


> But I am very convinced about two things:

> We want a single solution.

> And we want you to be happy with it.


> Benjamin



> 1: If you want references, look at the GTK Cairo work I did. And that is now

> superseded by Clutter. You can also look at the transition from X11 to

> Wayland for an example of that. I'm pretty sure we will make a rather

> seamless transition at one point there and not try to support both.

> 2: Tight coupling of GNOME with X11, NetworkManager, WebKit or Pulseaudio

> improved things a lot. At least that's my opinion.

> 3: The big example of a failed relationship is with Mozilla. It failed once

> already (the Epiphany guys with GtkMozEmbed - they started over with WebKit)

> and the _javascript_ situation (gjs is based on Mozilla's SpiderMonkey) isn't

> very nice either. Another example that never worked out is spell-checking.

> Enchant was never really integrated into GTK and that is why you can't

> spell-check normal text entries...

> 4: As a GTK maintainer, I'm not happy about IM modules as they generally

> contain very ugly and often just look plain bad when they try to pop up

> their own little X windows in all the wrong places. I'd also be very happy

> if I could show more useful information than an underlined pre-edit string.


I agree with desktop should be only one solution. But why not let user/distro to decide which is the best solution for them?


for 2, correct, but the case is different here, you guys even don't know what's matters for input method. And put a such tighter integration is not so good even for ibus developer to improve their function.


from my point of view, and easy and tight integration would be, input method makes their UI them inside the control center, and simply provides a way to replace the current keyboard layout setting.


for 4, As Input method developer, I'm also not happy about how crappy Gtk input method support is, and there are some points fundamental wrong inside Gtk/Gdk and all input method including Scim, IBus, Fcitx must to use dirty hack to workaround Gtk problem, from Gtk2 to Gtk3, things never changed and even become worse.


I'd like to put my point to gtk's list. Though that's a different story here.

Attachment: signature.asc
Description: This is a digitally signed message part.

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]