On Fri, May 11, 2012 at 9:58 PM, Takashi Iwai
At Fri, 11 May 2012 21:49:26 +0800, Marguerite Su wrote:
On Fri, May 11, 2012 at 9:43 PM, Takashi Iwai
wrote: At Fri, 11 May 2012 21:20:26 +0800, Weng Xuetian wrote:
On Fri, May 11, 2012 at 9:04 PM, Marguerite Su wrote:
On Fri, May 11, 2012 at 8:56 PM, Karl Eichwalder
wrote: 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
xein Yunseok Choi 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.
nope, the kcm is for configuration, see kcm-fcitx package in M17N.
it integrates its settings into user "system settings". that's the first and only IM does so now.
the gnome shell extension is kimpanel. provides the input panel for fcitx in Gnome shell.
startup staff is still handled by fcitx main package itself. using shell scripts in xim.d
but if you switched to other ways, he'll catch up in a flash.
OK. As long as the shell-script startup is OK, I'm fine. But, for example, with uim, we've got a problem with the startup of GNOME, D-bus and some panels. It looks like a race since restarting later after the session up works fine.
if you don't wanna configure your settings, you do not even need kcm-fcitx or fcitx-config-gtk2(3). they're separate packages. package fcitx has a .conf file as its config, kcm and gtk are used to edit this file. they're just pure UI for better user experience. so no race problem at all. fcitx starts with system(after X11). then kcm reads the config file, since kcm/gtk is not even functional if desktop environment is not ready. Marguerite.
Takashi
-- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org