At Fri, 11 May 2012 21:20:26 +0800, Weng Xuetian wrote:
On Fri, May 11, 2012 at 9:04 PM, Marguerite Su <i@marguerite.su> wrote:
On Fri, May 11, 2012 at 8:56 PM, Karl Eichwalder <ke@suse.de> wrote:
Marguerite Su <i@marguerite.su> writes:
can you help drag Korean coordinator into this thread?
I guess both our Korean community translators are no longer active; from the 'translators' file:
Korean (ko) teheo Tejun Heo <teheo =at= suse.de> xein Yunseok Choi <xein =at= naver.com>
Thus I think all we can do, is to ask on opensuse developer lists.
-- Karl Eichwalder SUSE LINUX Products GmbH R&D / Documentation Maxfeldstraße 5 90409 Nürnberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
the suse.de might be inactive, but naver.com must be in use. (naver is the most popular search engine, like google.)
so I cc-ed him.
To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Hi, I'm fcitx's maintainer.
For gnome https://live.gnome.org/ThreePointFive/Features/IBus
Actually fcitx also have xkb support, named fcitx-keyboard (which is already in M17N), and I can confidently say it's provides more feature than ibus. It provides not only keyboard layout integration but also word predication and spell-checking for keyboard layout user. Maybe not so useful for native speaker, but will benefit language learner I think.
There is no doubt that fcitx is the more feature-rich and actively developed project :) The action we need now is rather to contact with GNOME devs, tell the concerns regarding the integration and provide some patch if available. They certainly should think of the support of multiple IMs, so the earlier is better than sticking with the hard-coded ibus support in GNOME.
One thing need to notice, that fcitx is the only input method support kcm in KDE. And it's already works. Fcitx can also works natively under gnome-shell, with this extension help: https://extensions.gnome.org/extension/261/kimpanel/. And I'm also the maintainer of kimpanel in KDE. (kimpanel is a general dbus protocol for input method UI, works with scim/ibus (kde upstream), fcitx (fcitx upstream).
BTW, this leads me to some questions. What is the standard start-up procedure? Is it supposed to be started from a startup desktop file? Currently, we start a shell script in /etc/X11/xim.d/*, but this could be in a desktop file, too. The start-up in that place seems sometimes racy with d-bus activation, for example. 12.2 would be a good chance for cleaning up this old stuff, but we need more inputs.
One of basic idea of fcitx, is to work seamlessly under all environment. And it's really following this path. Fcitx can support UI with both KDE plasma or gnome-shell, or it's native one, without user interaction. And it can also provides systemsetting integration under KDE, and gtk2/3 configuration UI. If anyone want to put a gnome-control-center entry of fcitx or even deeper integration, it will be also easy to accomplish.
This is one of the feature that no existing input method could compare with.
For Japanese, I will work on anthy support in the future (helps are welcome), maybe two or three month later (Since I need to finish my graduate paper for now).
That'll be great. Anthy is no active development, but it's fairly stable and solid, thus still good to take as default, until mozc really gets accepted by all FOSS people. If you have any test patch available, let me know. thanks, Takashi -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org