On Tue, May 15, 2012 at 4:45 PM, Satoru Matsumoto
Marguerite Su wrote:
On Tue, May 15, 2012 at 1:05 AM, Fuminobu TAKEYAMA
wrote: Some Japanese community members are googling but they cannot find how it is.
in Japanese?
and in English. I think you need more and more information to spread fcitx on the website. I also have not understand the benefit yet.
That's the point. I've installed and used fcitx for a while, but to be honest, I couldn't find its advantages against IBus and felt that it isn't mature enough, at least for now. ATM, it may be good for Chinese, but not so good for Japanese.
yes, for now. to be honest. that's why we keep ibus for J. and I'm happy to see so many J people here like to try fcitx and baby sit it to grow in J support.
Marguerite, you say 'SCIM, IBus, gcin ... are old', but 'old' doesn't always mean 'bad'. I think you haven't enough explained yet, what are the advantages of using fcitx and disadvantages of using other IM frameworks except old or new.
old doesn't mean bad at all. all of them are old.(fcitx is "old" too, it launched 1.0 in 2004) and still work on KDE (SCIM not work for GTK3) some of them are still being maintained upstream (IBUS & GCIN & FCITX). here I'll cite Weng's word to give you a summary of their technically details: SCIM nothing to say. James Su is the best in his era. SCIM is best in its era. but that era has passed. IBUS. introduced module concept. but just a try. it didn't think too much on low-level design. so its layers are not abstract enough to implement features that easy. like if you want to implement some IMF(Input Method Framework) level features, actually, you have to hack every single engine/tables it used, like anthy/canna/blabla...every one of them. FCIX. modular and abstract. if you want to implement cross-over features, do it in framework. all engines will catch up automatically. and their maintain status: SCIM: no more. IBUS: its father left to Google. like James Su left SuSE. now its maintained by Red Hat/Fedora guys. and they're few to change low-level framework( to talk about IM, only you and us, I mean quite few developers in C and J community know what an IM really are, but unlikely not in FH/F, even SuSE. if you know James and ask him, the answer is yes. it sounds small, but actually a huge system, almost in every detail in low-level. so if you design a system without take IM into consideration, it's hard to change later. that's why we Chinese developers strongly against GNOME' idea to integrate IM into desktop) . so can only maintain comparability between framework and engines, distributions. it means it can be used for now, but what if a brand new engine comes that has much more features for users and much more requirements on engines? IBus can't catch up. because in low-level they didn't think that much. FCITX: well its features are solid (fcitx-anthy is actually experimental, fcitx-mozc just see its second release in our distro), and still under development. so it has many possibilities in future. so if you try it( of course, now you have no mature J support to try, but it'll come quickly in the coming month), you'll like it. Features: SCIM: no need to say much since it dead. IBUS: you're the user. FCITX: in engines, they're the same. so technically, if you "feel" mature IBUS-anthy well, you will at least feel the same well of fcitx-anthy. and it has much more user-oriented features. (later I can wiki it on fcitx wiki. although I don't know Japanese, but maybe I could use some "video tutorials" to show what these features are... and I'll add such details to our wiki, for distro packagers, not me, nor you, nor tiwai or ftake, but for newcomers who'll take over our maintainership in the future. to catch up with brief knowledge/basic introductions/required respects to maintain an IM.
If you just want to provide much more easy way to select IM framework (not IM engine, here I say...) to users, I don't raise an objection. For example:
- fcitx and related packages will be included in install DVD - (ATM) only when users select Chinese language during installation, these packages will be automatically installed (is this technically available?).
according to coolo and tiwai, if I didn't understand wrong. yes. and available.
- in that case, symlink of fcitx will be put in /etc/X11/xim.d/zh_* directories as 30-fcitx
... is this what you want? If yes, Japanese and Korean users won't be affected by the change tentatively, and once they will recognize the benefit of fcitx, they will be easily able to transit from IBus to fcitx. :-)
yes. that's what I'll do. Ja is still ibus by default. and I'll ship mozc in DVD too. (it's not openly developed. so Takashi suggested not to set it as default IM) so you can install mozc manually. but if you didn't select anything, it'll be ibus-anthy. technically I seems have to write a start-up script and set its priority 60 or 70 (IBUS is 50)
However, one thing we have to remember is, IIRC, if fcitx will be included in install DVD, that means it would be included in main OSS repo. As you may know, packages in main OSS repo shouldn't be easily upgraded unless security holes or bugs are found and should be fixed. IE, if you want to provide up-to-date packages to users constantly, a development branch repo for that (maybe M17N repo?) is also needed anyhow.
oh yes. I understand. actually, I didn't learn the maintain procedure part of OBS. but I'll. and if fcitx has a low-level (not compile time) bug, I'll transfer to weng, and he can fix it in 2/3 hours maybe. the I'll push that patch to update. but I won't think that'll happen too often. because fcitx is 4.2.3 now and 8 years old in Simplified Chinese. and has become default IM for debian SC in maybe 2007 or 2008. history proves it does not have that much bugs.
Best,
-- _/_/ Satoru Matsumoto - openSUSE Member - Japan _/_/ _/_/ Marketing/Weekly News/openFATE Screening Team _/_/ _/_/ mail: helios_reds_at_gmx.net / irc: HeliosReds _/_/ _/_/ http://blog.zaq.ne.jp/opensuse/ _/_/ -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org
Marguerite -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org