All CJK support from one install

[Kai Hendry]

Hi guys,

I maintain Webconverger a browser only opensource Linux distribution.
In terms of i18n support, the support for I guess latin based
characters sets is great. However CJK support not right now. In the
past I used SCIM packages like so:

Chinese:
scim-chinese scim-tables-zh scim-uim xfonts-intl-chinese
ttf-arphic-ukai ttf-arphic-uming xfonts-wqy iceweasel-l10n-zh-cn

Japanese:
ttf-vlgothic scim-anthy scim-uim scim-skk scim-prime scim-canna
scim-tables-ja iceweasel-l10n-ja

Korean:
scim-hangul scim-tables-ko scim-uim ttf-unfonts ttf-alee
xfonts-baekmuk iceweasel-l10n-ko

However things have changed since then. Tbh I'm only an English
speaker, so I am unfamiliar with the daily use of input methods. SCIM
IIUC has fallen from favour and is unmaintained?

Furthermore Webconverger doesn't use packages. It ships a "chroot"
which is designed to support _everyone_. So based solely on a locale=
and xkb= switch, I want to Webconverger able to switch to different
locale environments. Big plus points if we can somehow make CJK
switches instantly from the browser.

http://webconverger.org/i18n/


So I am writing to ask you developers of fcitx if your input method
can support what I want without swapping out packages or doing
anything particularly cumbersome. I'm also keen to get any advice to
which opensource fonts are popular and good, so Webconverger's surfing
experience is great for CJK users.

Many thanks and happy Chinese New Year,

[Weng Xuetian]

Hi, thank you for your interest in fcitx.

First of all, if scim could work in webconverger in the past, there is no reason that fcitx can't.

And please notice, fcitx treat xkb layout as an input method, and it will actually handle that on its own, and CJK users will not only use one input method (Basically they are usually choose what they are familiar with). And what enabled by default is usually based on what installed (Since I follow the idea that: if user installed it, then he want to use it).

So if you want to have a profile for different language, I think you'd better ship different ~/.config/fcitx/profile, or have a ui to let user configure it (fcitx-config-gtk{,3}), or only install a subset of package.

I see your package name looks like the one on debian/ubuntu? So you can just replace "scim-" prefix to "fcitx-" to check the package (though there are still some difference between package name).

You can check this list for what is being supported (well, support is already quite complete and can cover scim)
http://fcitx-im.org/wiki/Category:Input_Method

As for font, creating CJK font is always a big work (imagine that 128 ascii with tens of thousands of different CJKV character), so there is not much opensource/free CJK fonts around.

ttf-droid (font on android, it also provides cjk font, sans style CJK font), ttf-hanazono (Cover a large set of CJK font, basically the "serif style" CJK font), ttf-wqy-microhei (based on ttf-droid, but cover a larger set of character).

[Kai Hendry]

To get started I installed fcitx & fcitx-hangul Archlinux packages,
because I'm a little familiar with Hangul.

First thing I ran was fcitx-configtool, which didn't work:
http://sprunge.us/VJLf

I fiddled around using https://wiki.archlinux.org/index.php/Fcitx and
http://fcitx-im.org/wiki/Configure_(Other) as a guide and eventually
control+space works in the terminal, but not Firefox or Chrome.

I tried installing fcitx-gtk3 and that didn't seem to work, however
fcitx-gtk2 does allow for FF/Chrome input. Is that normal?

So now I have a working setup with:

x220:~$ pacman -Ql | grep fcitx | awk '{print $1}' | sort -u
fcitx
fcitx-gtk2
fcitx-hangul


Some further comments. Is it normal to have all these addons on a
typical "hangul" install?
http://sprunge.us/LbVP

The panel seems quite small
http://s.natalian.org/2013-02-12/2013-02-12-170954_1366x768_scrot.png

I am wondering if CJK users will know to "control+space" and be able
to use the small panel.

The small panel doesn't seem fixed to any particular area of the
screen. Shouldn't it be anchored on the bottom left or right?

Besides Hangul, I also seem to have Pinyin, Shuangpin, Wubi &
WubiPinyin input methods. Is that normal to have all those extras?

I am thinking those extra input methods might be accidentally
triggered and confuse a Korean ?

Does fcitx use xkb layout or locales to short list the input method options?


When I click "Configure" it does nothing. I wonder if I can remove the
Restart/Exit options as they look superfluous to me.

The virtual keyboard looks interesting, but it looks too small to be
practical say on a touch screen monitor. Or can that be changed?

Would a Japanese user want to use fcitx-mozc: Fcitx Module of A
Japanese Input Method for Chromium OS, Windows, Mac and Linux (the
Open Source Edition of Google Japanese Input) ?


I have more comments, though I will save them for tomorrow. Thank you!

[Felix Yan]

On Tuesday, February 12, 2013 17:19:06 Kai Hendry wrote:
> To get started I installed fcitx & fcitx-hangul Archlinux packages,
> because I'm a little familiar with Hangul.
>
> First thing I ran was fcitx-configtool, which didn't work:
> http://sprunge.us/VJLf

Try start fcitx-configtool from fcitx menu? (thus, run fcitx at least once first)

>
> I fiddled around using https://wiki.archlinux.org/index.php/Fcitx and
> http://fcitx-im.org/wiki/Configure_(Other) as a guide and eventually
> control+space works in the terminal, but not Firefox or Chrome.
>
> I tried installing fcitx-gtk3 and that didn't seem to work, however
> fcitx-gtk2 does allow for FF/Chrome input. Is that normal?

Yes, FF/Chrome are both based on gtk2, not gtk3. Looking at their package dependencies proofs this too.

>
> So now I have a working setup with:
>
> x220:~$ pacman -Ql | grep fcitx | awk '{print $1}' | sort -u
> fcitx
> fcitx-gtk2
> fcitx-hangul
>
>
> Some further comments. Is it normal to have all these addons on a
> typical "hangul" install?
> http://sprunge.us/LbVP

Yes, all those other than "hangul" are built-in addons, and does no harm :)

>
> The panel seems quite small
> http://s.natalian.org/2013-02-12/2013-02-12-170954_1366x768_scrot.png
>
> I am wondering if CJK users will know to "control+space" and be able
> to use the small panel.
>
> The small panel doesn't seem fixed to any particular area of the
> screen. Shouldn't it be anchored on the bottom left or right?

You could try kimpanel (for kde plasma) as well as kimtoy for a better panel.

>
> Besides Hangul, I also seem to have Pinyin, Shuangpin, Wubi &
> WubiPinyin input methods. Is that normal to have all those extras?

Yes, they are built-ins too.

>
> I am thinking those extra input methods might be accidentally
> triggered and confuse a Korean ?

Not really, they won't be triggered until you manually add them to the list.

>
> Does fcitx use xkb layout or locales to short list the input method options?

Yes, but only on kcm-fcitx (by default).

>
> When I click "Configure" it does nothing.

That means you did not have a configuration gui installed correctly.

>
> I wonder if I can remove the Restart/Exit options as they look superfluous to me.

No, for now :P But again, use kimpanel or kimtoy will allow you to get rid of this.

> The virtual keyboard looks interesting, but it looks too small to be
> practical say on a touch screen monitor. Or can that be changed?

There's a seperate thread on this list discussing the virtual keyboard, maybe take a look?

>
> Would a Japanese user want to use fcitx-mozc: Fcitx Module of A
> Japanese Input Method for Chromium OS, Windows, Mac and Linux (the
> Open Source Edition of Google Japanese Input) ?

Yes.

>
> I have more comments, though I will save them for tomorrow. Thank you!

:)

Felix Yan
Twitter: @felixonmars
Wiki: http://felixc.at

[Kai Hendry]

On 12 February 2013 17:29, Felix Yan <felix...@gmail.com> wrote:
> Yes, all those other than "hangul" are built-in addons, and does no harm :)

I'm very sensitive to "bloat" for the Webconverger distribution.

>> Besides Hangul, I also seem to have Pinyin, Shuangpin, Wubi &
>> WubiPinyin input methods. Is that normal to have all those extras?
> Yes, they are built-ins too.
>> I am thinking those extra input methods might be accidentally
>> triggered and confuse a Korean ?
> Not really, they won't be triggered until you manually add them to the list.

I didn't manually add them though. I'm confused. Are they "built in"
or has the package maintainer added them needlessly?

>> Does fcitx use xkb layout or locales to short list the input method options?
> Yes, but only on kcm-fcitx (by default).

kcm-fcitx seems to have a crazy amount of dependencies. I can't afford
to use this panel and drag in QT et al. :(

http://sprunge.us/FLhP

What is the name of this panel? http://s.natalian.org/2013-02-12/fcitx-panel.png
I want this to work. :-)

> That means you did not have a configuration gui installed correctly.

Well fcitx's panel shouldn't offer the option, if I've chosen not to
install a GUI, should it? :)

>> I wonder if I can remove the Restart/Exit options as they look superfluous to me.
> No, for now :P But again, use kimpanel or kimtoy will allow you to get rid of this.

I don't want to add more software to fix a trivial problem. :}

> There's a seperate thread on this list discussing the virtual keyboard, maybe take a look?

Do you have a link to the relevant email please?
http://s.natalian.org/2013-02-12/1360662065_1366x768.png

>> Would a Japanese user want to use fcitx-mozc: Fcitx Module of A
>> Japanese Input Method for Chromium OS, Windows, Mac and Linux (the
>> Open Source Edition of Google Japanese Input) ?
> Yes.

Ok, so I need to check mozc integration too. Was hoping to get away
with not installing yet another program for an input method. ;)

Aim to have the lightest weight possible CJK support in Webconverger,
with your help. :)


Kind regards,

[Felix Yan]

On Tuesday, February 12, 2013 17:49:13 Kai Hendry wrote:
> On 12 February 2013 17:29, Felix Yan <felix...@gmail.com> wrote:
> > Yes, all those other than "hangul" are built-in addons, and does no harm :)
>
> I'm very sensitive to "bloat" for the Webconverger distribution.

Then you could re-package fcitx, to build/install every module seperately so you have more freedom on what has to be installed :) Anyway, this is what I'm gonna do but just not done yet.

>
> >> Besides Hangul, I also seem to have Pinyin, Shuangpin, Wubi &
> >> WubiPinyin input methods. Is that normal to have all those extras?
> > Yes, they are built-ins too.
> >> I am thinking those extra input methods might be accidentally
> >> triggered and confuse a Korean ?
> > Not really, they won't be triggered until you manually add them to the list.
>
> I didn't manually add them though. I'm confused. Are they "built in"
> or has the package maintainer added them needlessly?

Like the addons, you could choose not to build them at all at build time, or they could be splitted too.

>
> >> Does fcitx use xkb layout or locales to short list the input method options?
> > Yes, but only on kcm-fcitx (by default).
>
> kcm-fcitx seems to have a crazy amount of dependencies. I can't afford
> to use this panel and drag in QT et al. :(
>
> http://sprunge.us/FLhP

In fact, fcitx is qt-oriented, and modules such as quickphrase needs qt too. But kcm-fcitx itself is for KDE for sure (so it depends on kdebase-runtime), so unfortunately it has to bring in such crazy amount of dependencies :(

>
> What is the name of this panel? http://s.natalian.org/2013-02-12/fcitx-panel.png
> I want this to work. :-)

This is the default one? (or the classic-ui?) Sorry I'm not the dev so not very familiar with those UIs :P

>
> > That means you did not have a configuration gui installed correctly.
>
> Well fcitx's panel shouldn't offer the option, if I've chosen not to
> install a GUI, should it? :)

In fact, there SHOULD be a dependency on something like "fcitx-config-gui", and both kcm-fcitx and fcitx-configtool (fcitx-configtool-gtk2) provides it. This will be done in near future :P

>
> >> I wonder if I can remove the Restart/Exit options as they look superfluous to me.
> > No, for now :P But again, use kimpanel or kimtoy will allow you to get rid of this.
>
> I don't want to add more software to fix a trivial problem. :}
>
> > There's a seperate thread on this list discussing the virtual keyboard, maybe take a look?
>
> Do you have a link to the relevant email please?
> http://s.natalian.org/2013-02-12/1360662065_1366x768.png

Sorry, it's on the fcitx list, not fcitx-dev. Here's the link:
https://groups.google.com/forum/#!topic/fcitx/DURM1lxz1lI

>
> >> Would a Japanese user want to use fcitx-mozc: Fcitx Module of A
> >> Japanese Input Method for Chromium OS, Windows, Mac and Linux (the
> >> Open Source Edition of Google Japanese Input) ?
> > Yes.
>
> Ok, so I need to check mozc integration too. Was hoping to get away
> with not installing yet another program for an input method. ;)

A better choice could be fcitx-anthy, together with the anthy package. It's a) smaller in size, and get rid of the qt dependency so it is even smaller b) more stable and widely used.

>
> Aim to have the lightest weight possible CJK support in Webconverger,
> with your help. :)

My pleasure :)

[Kai Hendry]

On 12 February 2013 18:08, Felix Yan <felix...@gmail.com> wrote:
> Then you could re-package fcitx, to build/install every module seperately so you have more freedom on what has to be installed :) Anyway, this is what I'm gonna do but just not done yet.

I need to support CJK, so I need the extra input methods, but I want
to be careful I'm not dragging in anything unnecessary or overloading
the user with choices.

> In fact, there SHOULD be a dependency on something like "fcitx-config-gui", and both kcm-fcitx and fcitx-configtool (fcitx-configtool-gtk2) provides it. This will be done in near future :P

Well i don't want any Webconverger user (think of a pensioner), having
to configure anything. Ideally if a Korean Webpage is open, e.g. <html
lang="ko">, then the most appropriate input method (Hangul) is
available from a Control+Space invocation.

Currently in Webconverger, we support one primarily locale at one
time. For example a boot with the options locale=it xkb=-layout%20it,
fixes you the Italian keyboard and language. I think we can do this
for Korea or Chinese or Japanese in the short term too. As to avoid
detecting the locale of the viewed Webpage (which is probably tricky
to do) and to avoid any input method configuration. By default it will
boot to a US keyboard and Control+space to get the input support or
vice versa? Thinking aloud here.

> A better choice could be fcitx-anthy, together with the anthy package. It's a) smaller in size, and get rid of the qt dependency so it is even smaller b) more stable and widely used.

Thanks for the tip. I would look into that anthy next after I'm happy
with Hangul. :-)

감사합니다

[Felix Yan]

On Tuesday, February 12, 2013 18:21:52 Kai Hendry wrote:
> > In fact, there SHOULD be a dependency on something like "fcitx-config-gui", and both kcm-fcitx and fcitx-configtool (fcitx-configtool-gtk2) provides it. This will be done in near future :P
>
>
> Well i don't want any Webconverger user (think of a pensioner), having
> to configure anything. Ideally if a Korean Webpage is open, e.g. <html
> lang="ko">, then the most appropriate input method (Hangul) is
> available from a Control+Space invocation.
>
> Currently in Webconverger, we support one primarily locale at one
> time. For example a boot with the options locale=it xkb=-layout%20it,
> fixes you the Italian keyboard and language. I think we can do this
> for Korea or Chinese or Japanese in the short term too. As to avoid
> detecting the locale of the viewed Webpage (which is probably tricky
> to do) and to avoid any input method configuration. By default it will
> boot to a US keyboard and Control+space to get the input support or
> vice versa? Thinking aloud here.
>

My idea:

*) Write a plugin for fcitx to switch to a certain im, to achieve either of this. Then you could Catch the target im (from your firefox plugin?) in the fcitx plugin, and activate/deactivate it.

As I'm not a fcitx dev (yet), I dunno if it is possible switching to an input method that not on the list, but it's still okay if this could not be done: instead, add ALL available input methods (chosen by you) onto the list, and remap the input method activation hotkey. So you could catch ctrl-space (or whatever you want) yourself in the plugin.

[Yichao Yu]

On Tue, Feb 12, 2013 at 4:19 AM, Kai Hendry <hen...@webconverger.com> wrote:
> To get started I installed fcitx & fcitx-hangul Archlinux packages,
> because I'm a little familiar with Hangul.
>
> First thing I ran was fcitx-configtool, which didn't work:
> http://sprunge.us/VJLf

Because you don't have a valid configure gui installed.

>
> I fiddled around using https://wiki.archlinux.org/index.php/Fcitx and
> http://fcitx-im.org/wiki/Configure_(Other) as a guide and eventually
> control+space works in the terminal, but not Firefox or Chrome.
>
> I tried installing fcitx-gtk3 and that didn't seem to work, however
> fcitx-gtk2 does allow for FF/Chrome input. Is that normal?

Please install fcitx-{gtk{2,3},qt} if you want to use it in
{gtk{2,3},qt} programs unless you want to use the XIM protocol and
freeze your application.

>
> So now I have a working setup with:
>
> x220:~$ pacman -Ql | grep fcitx | awk '{print $1}' | sort -u
> fcitx
> fcitx-gtk2
> fcitx-hangul
>
>
> Some further comments. Is it normal to have all these addons on a
> typical "hangul" install?
> http://sprunge.us/LbVP

They are not builtins. They are in the same source repo with fcitx
main program, and they are installed because archlinux doesn't split
packages.

>
> The panel seems quite small
> http://s.natalian.org/2013-02-12/2013-02-12-170954_1366x768_scrot.png
>
> I am wondering if CJK users will know to "control+space" and be able
> to use the small panel.

They all know, and you can also uses a skin with a larger panel.

>
> The small panel doesn't seem fixed to any particular area of the
> screen. Shouldn't it be anchored on the bottom left or right?

No

>
> Besides Hangul, I also seem to have Pinyin, Shuangpin, Wubi &
> WubiPinyin input methods. Is that normal to have all those extras?

It make sense to have those enabled when they are installed, so a user
don't need to add it after install.

>
> I am thinking those extra input methods might be accidentally
> triggered and confuse a Korean ?

He can choose not to install them on a distro that split those
packages and can always disable them.

>
> Does fcitx use xkb layout or locales to short list the input method options?
>

Please install the fcitx-configtool package (not the command) if you
don't want to install kcm-fcitx.

>
> When I click "Configure" it does nothing. I wonder if I can remove the
> Restart/Exit options as they look superfluous to me.

Usually a input method user uses keyboard shortcut's.

>
> The virtual keyboard looks interesting, but it looks too small to be
> practical say on a touch screen monitor. Or can that be changed?

That's mainly for special input now. Use a dedicated virtual keyboard
as for now.

>
> Would a Japanese user want to use fcitx-mozc: Fcitx Module of A
> Japanese Input Method for Chromium OS, Windows, Mac and Linux (the
> Open Source Edition of Google Japanese Input) ?
>

It is said to be better than fcitx-anthy.

>
> I have more comments, though I will save them for tomorrow. Thank you!
>

> --
> You received this message because you are subscribed to the Google Groups "fcitx-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fcitx-dev+...@googlegroups.com.
> To post to this group, send email to fcit...@googlegroups.com.
> Visit this group at http://groups.google.com/group/fcitx-dev?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Yichao Yu]

On Tue, Feb 12, 2013 at 4:49 AM, Kai Hendry <hen...@webconverger.com> wrote:
> On 12 February 2013 17:29, Felix Yan <felix...@gmail.com> wrote:
>> Yes, all those other than "hangul" are built-in addons, and does no harm :)
>
> I'm very sensitive to "bloat" for the Webconverger distribution.
>
>>> Besides Hangul, I also seem to have Pinyin, Shuangpin, Wubi &
>>> WubiPinyin input methods. Is that normal to have all those extras?
>> Yes, they are built-ins too.
>>> I am thinking those extra input methods might be accidentally
>>> triggered and confuse a Korean ?
>> Not really, they won't be triggered until you manually add them to the list.
>
> I didn't manually add them though. I'm confused. Are they "built in"
> or has the package maintainer added them needlessly?
>
>>> Does fcitx use xkb layout or locales to short list the input method options?
>> Yes, but only on kcm-fcitx (by default).
>
> kcm-fcitx seems to have a crazy amount of dependencies. I can't afford
> to use this panel and drag in QT et al. :(
>
> http://sprunge.us/FLhP
>
> What is the name of this panel? http://s.natalian.org/2013-02-12/fcitx-panel.png
> I want this to work. :-)
>
>> That means you did not have a configuration gui installed correctly.
>
> Well fcitx's panel shouldn't offer the option, if I've chosen not to
> install a GUI, should it? :)

Yes it should always offer this. It can also open your editor if you
have set your EDITOR correctly. (although you should always install a
configure gui.)

>
>>> I wonder if I can remove the Restart/Exit options as they look superfluous to me.
>> No, for now :P But again, use kimpanel or kimtoy will allow you to get rid of this.
>
> I don't want to add more software to fix a trivial problem. :}

That is not a problem and that cannot be fixed by kimpanel or kimtoy.
None of them hide this option.

>
>> There's a seperate thread on this list discussing the virtual keyboard, maybe take a look?
>
> Do you have a link to the relevant email please?
> http://s.natalian.org/2013-02-12/1360662065_1366x768.png
>
>>> Would a Japanese user want to use fcitx-mozc: Fcitx Module of A
>>> Japanese Input Method for Chromium OS, Windows, Mac and Linux (the
>>> Open Source Edition of Google Japanese Input) ?
>> Yes.
>
> Ok, so I need to check mozc integration too. Was hoping to get away
> with not installing yet another program for an input method. ;)
>
> Aim to have the lightest weight possible CJK support in Webconverger,
> with your help. :)
>

Lightest weight -> trouble.

>
> Kind regards,

[Yichao Yu]

On Tue, Feb 12, 2013 at 5:08 AM, Felix Yan <felix...@gmail.com> wrote:
> On Tuesday, February 12, 2013 17:49:13 Kai Hendry wrote:
>> On 12 February 2013 17:29, Felix Yan <felix...@gmail.com> wrote:
>> > Yes, all those other than "hangul" are built-in addons, and does no harm :)
>>
>> I'm very sensitive to "bloat" for the Webconverger distribution.
> Then you could re-package fcitx, to build/install every module seperately so you have more freedom on what has to be installed :) Anyway, this is what I'm gonna do but just not done yet.
>
>>
>> >> Besides Hangul, I also seem to have Pinyin, Shuangpin, Wubi &
>> >> WubiPinyin input methods. Is that normal to have all those extras?
>> > Yes, they are built-ins too.
>> >> I am thinking those extra input methods might be accidentally
>> >> triggered and confuse a Korean ?
>> > Not really, they won't be triggered until you manually add them to the list.
>>
>> I didn't manually add them though. I'm confused. Are they "built in"
>> or has the package maintainer added them needlessly?
> Like the addons, you could choose not to build them at all at build time, or they could be splitted too.
>
>>
>> >> Does fcitx use xkb layout or locales to short list the input method options?
>> > Yes, but only on kcm-fcitx (by default).
>>
>> kcm-fcitx seems to have a crazy amount of dependencies. I can't afford
>> to use this panel and drag in QT et al. :(
>>
>> http://sprunge.us/FLhP
> In fact, fcitx is qt-oriented, and modules such as quickphrase needs qt too. But kcm-fcitx itself is for KDE for sure (so it depends on kdebase-runtime), so unfortunately it has to bring in such crazy amount of dependencies :(

NOOOOOOOOOOOOOOOOOOO quickphrase does not and will NEVER require qt.
Qt is the preferred gui toolkit but it will NEVER be a hard dependency
of fcitx main program (or any non-gui related addons)

And you can also install fcitx-config-gtk3 provided by
fcitx-configtool or fcitx-config-gtk2 provided by
fcitx-configtool-gtk2 (cannot remember the exact package name).

>
>>
>> What is the name of this panel? http://s.natalian.org/2013-02-12/fcitx-panel.png
>> I want this to work. :-)
> This is the default one? (or the classic-ui?) Sorry I'm not the dev so not very familiar with those UIs :P

Isn't it exactly the same with what u have?

[Weng Xuetian]

Ok, I guess you might want to check fcitx-remote?

$ fcitx-remote -h

Usage: fcitx-remote [OPTION]
        -c              inactivate input method
        -o              activate input method
        -r              reload fcitx config
        -t,-T           switch Active/Inactive
        -e              Ask fcitx to exit
        -a              print fcitx's dbus address
        -m <imname>     print corresponding addon name for im
        -s <imname>     switch to the input method uniquely identified by <imname>
        [no option]     display fcitx state, 0 for close, 1 for inactive, 2 for acitve
        -h              display this help and exit

I guess fcitx-remote -s hangul is what you want, if you want to that automatically integrated into your browser :)

And there are also -c, -o, -t, -T you might want to play with.

[Weng Xuetian]

As for dependency, you will not be able to find another input method framework have lesser dependency on fcitx. :) (And yes, we're actually proud of this)

It is possible to build fcitx without X if you only want to run fcitx with fbterm. We are also working on a mac port, so actually core part can strip dependency down to only libc and pthread (obviously, frontend dependency is not included).

After think about your requirement, you will at least need:

libx11

cairo and pango (for GUI)

dbus

Your browser seems to be a modified version of firefox, so gtk2 (and you already have that it in system so no problem again :D)

Does that work for you?

[Kai Hendry]

On 12 February 2013 23:45, Weng Xuetian <wen...@gmail.com> wrote:
> As for dependency, you will not be able to find another input method
> framework have lesser dependency on fcitx. :) (And yes, we're actually proud
> of this)

You should be. This is good news in terms of Webconverger integration.

> After think about your requirement, you will at least need:
> libx11
> cairo and pango (for GUI)
> dbus

That's fine.

> Your browser seems to be a modified version of firefox, so gtk2 (and you
> already have that it in system so no problem again :D)

The browser we currently use is actually the "official build" from
getfirefox.com
https://github.com/Webconverger/webc/tree/master/opt/firefox

> Does that work for you?

Yes, I will work on integration in the next days and hopefully get
your review. :)

[Kai Hendry]

On 12 February 2013 23:33, Weng Xuetian <wen...@gmail.com> wrote:
> And there are also -c, -o, -t, -T you might want to play with.

Still a little worried about the "user experience" with this tiny
classic toolbar http://r2d2.webconverger.org/2013-02-13/fcitx.html

How do I only enable say Hangul/Latin keyboard? Is there documentation
with this classic skin? I'm not sure what the items of the toolbar do.


Kind regards,

[Kai Hendry]

Next I'm wondering why Debian packaging drags down aspell / enchant /
spelling libs IIUC and friends. Why?

http://sprunge.us/hPOC

Perhaps I'm far better off building from source? Unless I'm missing
something. :)


Thanks!

[Kai Hendry]

Does anyone know how xinput.d works?
https://github.com/Webconverger/webc/tree/cjk2/etc/X11/xinit/xinput.d

I don't understand how it's sourced.

I expected after `ln -s /etc/X11/xinit/xinput.d/ko_KR
~/.xinput.d/ko_KR` and restarting X, fcitx would be running on a
Debian based system with Hangul.

What am I missing?


Many thanks,

[Yichao Yu]

http://fcitx-im.org/wiki/Input_method_related_environment_variables

[Kai Hendry]

Hi!

On 14 February 2013 13:56, Yichao Yu <yyc...@gmail.com> wrote:
> http://fcitx-im.org/wiki/Input_method_related_environment_variables

This page doesn't tell me how xinput.d/ works and invokes fcitx.

Else I'll end up doing things by hand like I do on my Arch laptop. :)
https://github.com/kaihendry/Kai-s--HOME/blob/master/.xinitrc#L38

Kind regards,

[Yichao Yu]

On Thu, Feb 14, 2013 at 1:57 AM, Kai Hendry <hen...@webconverger.com> wrote:
> Hi!
>
> On 14 February 2013 13:56, Yichao Yu <yyc...@gmail.com> wrote:
>> http://fcitx-im.org/wiki/Input_method_related_environment_variables
>
> This page doesn't tell me how xinput.d/ works and invokes fcitx.

Debian's xinput.d include something that you are not interested in
(debian specific settings) what you need to do is just set those
environment variables mentioned in that link to fcitx-wiki (before
fcitx started) and run fcitx.

p.s. You don't need to run fcitx with 'fcitx &' just 'fcitx' is enough
p.p.s. if you want to run dbus, run it before fcitx started.

>
> Else I'll end up doing things by hand like I do on my Arch laptop. :)
> https://github.com/kaihendry/Kai-s--HOME/blob/master/.xinitrc#L38
>
> Kind regards,
>
>> On Wed, Feb 13, 2013 at 10:49 PM, Kai Hendry <hen...@webconverger.com> wrote:
>>> Does anyone know how xinput.d works?
>>> https://github.com/Webconverger/webc/tree/cjk2/etc/X11/xinit/xinput.d
>>>
>>> I don't understand how it's sourced.
>>>
>>> I expected after `ln -s /etc/X11/xinit/xinput.d/ko_KR
>>> ~/.xinput.d/ko_KR` and restarting X, fcitx would be running on a
>>> Debian based system with Hangul.
>>>
>>> What am I missing?

what you are missing is you shouldn't look at debian.

[Yichao Yu]

or this page

http://fcitx-im.org/wiki/Configure_(Other)

[Kai Hendry]

On 14 February 2013 15:03, Yichao Yu <yyc...@gmail.com> wrote:
> p.s. You don't need to run fcitx with 'fcitx &' just 'fcitx' is enough

I wonder if it makes sense to control fcitx using systemd?

https://wiki.archlinux.org/index.php/Systemd/User


You could a service file for each locale, like

fcitx-korean.service with
ConditionKernelCommandLine=locale=ko


That would setup fcitx with Hangul ...


I won't bother with xinput.d since no one seems to know how it works
and it's poorly documented.

[Aron Xu]

Hi,

Perhaps I'm able to give you some insights about how Debian initialize
input method frameworks. Basically xinput.d is abandoned in Wheezy,
it's used in im-switch which has been replaced by im-config.

You shouldn't tune those stuff by editing configuration files by hand,
neither Fcitx nor Debian IME team will provide support for doing such.
Please have a look at the man page of im-config for choosing input
method engines, and fcitx-config-gtk/kcm-fcitx for configuring Fcitx
itself.



--
Regards,
Aron Xu

[Kai Hendry]

Hi Aron!

On 14 February 2013 17:39, Aron Xu <aronm...@gmail.com> wrote:
> Perhaps I'm able to give you some insights about how Debian initialize
> input method frameworks. Basically xinput.d is abandoned in Wheezy,
> it's used in im-switch which has been replaced by im-config.

I see, still im-config requires Zenity which sadly has a crazy amount
of dependencies.

> You shouldn't tune those stuff by editing configuration files by hand,
> neither Fcitx nor Debian IME team will provide support for doing such.
> Please have a look at the man page of im-config for choosing input
> method engines, and fcitx-config-gtk/kcm-fcitx for configuring Fcitx
> itself.

I think I will have to write scripts to manage fcitx / fcitx-remote
with CJK, to get things lightweight like I need them to be. :)

[Aron Xu]

On Thu, Feb 14, 2013 at 7:07 PM, Kai Hendry <hen...@webconverger.com> wrote:
> Hi Aron!
>
> On 14 February 2013 17:39, Aron Xu <aronm...@gmail.com> wrote:
>> Perhaps I'm able to give you some insights about how Debian initialize
>> input method frameworks. Basically xinput.d is abandoned in Wheezy,
>> it's used in im-switch which has been replaced by im-config.
>
> I see, still im-config requires Zenity which sadly has a crazy amount
> of dependencies.
>

An alternative to zenity is dialog, a command-line program with very
few dependencies. You can use this command:
apt-get install im-config dialog
Zenity won't be pulled into the system by this way.

>> You shouldn't tune those stuff by editing configuration files by hand,
>> neither Fcitx nor Debian IME team will provide support for doing such.
>> Please have a look at the man page of im-config for choosing input
>> method engines, and fcitx-config-gtk/kcm-fcitx for configuring Fcitx
>> itself.
>
> I think I will have to write scripts to manage fcitx / fcitx-remote
> with CJK, to get things lightweight like I need them to be. :)
>

No, it's not lightweight, but just re-invent wheels, IMHO. Please be
more patient to learn about input methods before you think you've know
enough.



--
Regards,
Aron Xu

[Weng Xuetian]

On Thursday 14 February 2013 19:07:52，Kai Hendry :

Hi,
As for your use case, im-config is quite useless.

You can remove it, and do it as http://fcitx-im.org/wiki/Configure_%28Other%29
.

Compile on your own fcitx is definitely a way to avoid some dependencies, but
you might need to know, input method will always cost a large space to hold
enough data. Especially for Chinese and Japanese if you really want to
provides Good behavior.

Enchant and presage is something fcitx uses to provides word completion, as
shown in this screenshot, http://fcitx-im.org/wiki/File:Fcitx-Keyboard.png ,
so you might know that input method is not only for CJK, but also for Latin-
Character based language if you want. You can decides to use it or not, newer
fcitx can use those as runtime dependency, BTW.

Regards
Xuetian

[Weng Xuetian]

On Thursday 14 February 2013 19:07:52，Kai Hendry :

Aron packages fcitx for debian, so he think you should use im-config, while as
I explained in previous email, you can uninstall it and go with your
~/.xinitrc and http://fcitx-im.org/wiki/Configure_%28Other%29 follow
instruction in this page.

im-config is useful if you need to use more than one input method framework,
like you use scim and fcitx and need to switch between them, but those script
is unfortunately always buggy...

Regards
Xuetian

[Weng Xuetian]

On Wednesday 13 February 2013 13:16:54，Kai Hendry :

It provides some switch for input method, and some other function.

You can completely hide it with ~/.config/fcitx/conf/fcitx-classic-ui.config

MainWindowHideMode=Hide

Regards
Xuetian

[Kai Hendry]

On 14 February 2013 22:24, Weng Xuetian <wen...@gmail.com> wrote:
> Aron packages fcitx for debian, so he think you should use im-config, while as
> I explained in previous email, you can uninstall it and go with your
> ~/.xinitrc and http://fcitx-im.org/wiki/Configure_%28Other%29 follow
> instruction in this page.
> im-config is useful if you need to use more than one input method framework,
> like you use scim and fcitx and need to switch between them, but those script
> is unfortunately always buggy...

`im-config -c` does run, but I still don't understand how XIM_PROGRAM
fcitx gets invoked, so I'm giving up on using it. I'm trying to
replicate my working setup under Archlinux in Debian based
Webconverger https://github.com/Webconverger/webc


So instead of setting up a build chain, I thought I would try use the
1:4.2.4.1-7 based fcitx packages. However I can't get it to launch,
there are dbus issues which I am uncertain how to debug.
http://s.natalian.org/2013-02-19/dbus-issue.png

When I run dbus-launch by hand, I get a clean 0 exit code. So I don't
see where fcitx has the problem.

AFAICT dbus is running, so I am unsure why fcitx cannot connect.
http://ix.io/4sn

Any tips? Is it worth compiling fcitx from source?

I did notice Archlinux has fcitx-dbus-watcher but Debian 1:4.2.4.1-7
packaging does not. Should I be worried?

If you want me to break up this thread in future with a better title
"dbus debian issue with fcitx-dbus-watcher?" just let me know.

Thanks,

[Kai Hendry]

On 12 February 2013 23:45, Weng Xuetian <wen...@gmail.com> wrote:

> After think about your requirement, you will at least need:
> libx11
> cairo and pango (for GUI)
> dbus

In the INSTALL file https://github.com/fcitx/fcitx/blob/master/INSTALL
you list dbus as an alternative dependency. But as you say above and
in the wiki, it's a hard dependency?
Also confusingly you list a lot of dependencies upon
http://fcitx-im.org/wiki/Compile_from_source I think you need to
separate that list into depends and optdepends. Be good if you can
give an example of a gtk2 app (firefox), so as to save time for fools
like myself who wasted time with gtk3. :)

I'm a bit of Cmake newbie (why can't GNU Make & autohell do?), so
forgive any stupid questions.
CMakeCache.txt IIUC shows me your defaults and the things switched on are:

CMAKE_COLOR_MAKEFILE:BOOL=ON
ENABLE_BACKTRACE:BOOL=ON
ENABLE_CAIRO:BOOL=ON
ENABLE_DBUS:BOOL=ON
ENABLE_ENCHANT:BOOL=ON
ENABLE_GETTEXT:BOOL=ON
ENABLE_GIR:BOOL=ON
ENABLE_GLIB2:BOOL=ON
ENABLE_GTK2_IM_MODULE:BOOL=ON
ENABLE_ICU:BOOL=ON
ENABLE_LIBXML2:BOOL=ON
ENABLE_OPENCC:BOOL=ON
ENABLE_PANGO:BOOL=ON
ENABLE_PRESAGE:BOOL=ON
ENABLE_QT:BOOL=ON
ENABLE_QT_IM_MODULE:BOOL=ON
ENABLE_SNOOPER:BOOL=ON
ENABLE_TABLE:BOOL=ON
ENABLE_X11:BOOL=ON
ENABLE_XDGAUTOSTART:BOOL=ON


Could you please advise a bare minimum CJK build for Firefox (gtk2)
use? I don't need QT surely and I don't need enchant do I?

Thanks!

[Weng Xuetian]

On Tuesday 19 February 2013 14:45:37，Kai Hendry :

This page is a little bit out of date (missing some new option in new
version), but you can still check this for how to add option to cmake.

http://fcitx-im.org/wiki/Compile_from_source

(Disable Qt Part)
-DENABLE_QT_IM_MODULE=Off
-DENABLE_QT=Off

(Disable GObject Introspection)
-DENABLE_GIR=Off

(Disable /etc/xdg/autostart/fcitx-autostart.desktop install)
-DENABLE_XDGAUTOSTART=Off

(Disable Xkb part)
-DENABLE_LIBXML2=Off
-DENABLE_ICU=Off

(Some additional stuff can be disabled)
-DENABLE_OPENCC=Off
-DENABLE_PRESAGE=Off
-DENABLE_ENCHANT=Off


Regards
Xuetian

[Kai Hendry]

Ok with your suggestions Weng, I have a build with:

x220:/tmp/f/fcitx/src/build$ grep BOOL=ON CMakeCache.txt

CMAKE_COLOR_MAKEFILE:BOOL=ON
ENABLE_BACKTRACE:BOOL=ON
ENABLE_CAIRO:BOOL=ON
ENABLE_DBUS:BOOL=ON

ENABLE_GETTEXT:BOOL=ON
ENABLE_GLIB2:BOOL=ON
ENABLE_GTK2_IM_MODULE:BOOL=ON
ENABLE_PANGO:BOOL=ON

ENABLE_SNOOPER:BOOL=ON
ENABLE_TABLE:BOOL=ON
ENABLE_X11:BOOL=ON

backtrace and snooper look a little scary. What are they? Can they be
turned off?

Is there a way to see compile switches in the fcitx binary?


With `echo MainWindowHideMode=Hide >>
~/.config/fcitx/conf/fcitx-classic-ui.config`, things are perfect.
Control+Space by default switches me between hangul & latin keyboard
like I want for my initial support with Korean.

However I want to setup a system wide configuration for
"MainWindowHideMode=Hide", since I need to nuke $HOME in Webconverger
to keep it a "clean slate" for the next user. For example
~/.config/fcitx/clipboard/history.dat could be a privacy violation
between user sessions, so I need a rm -rf ~/.config at
https://github.com/Webconverger/webc/blob/master/home/webc/webc.sh#L183

I'm also curious to know how fcitx knows that I want hangul by default
(without a ~/.config/fcitx). Because IIUC there is more than
/usr/lib/fcitx/fcitx-hangul.so by default.

Thank you in advance!

[Weng Xuetian]

On Wednesday 20 February 2013 15:43:33，Kai Hendry :

> Ok with your suggestions Weng, I have a build with:
>
> x220:/tmp/f/fcitx/src/build$ grep BOOL=ON CMakeCache.txt
> CMAKE_COLOR_MAKEFILE:BOOL=ON
> ENABLE_BACKTRACE:BOOL=ON
> ENABLE_CAIRO:BOOL=ON
> ENABLE_DBUS:BOOL=ON
> ENABLE_GETTEXT:BOOL=ON
> ENABLE_GLIB2:BOOL=ON
> ENABLE_GTK2_IM_MODULE:BOOL=ON
> ENABLE_PANGO:BOOL=ON
> ENABLE_SNOOPER:BOOL=ON
> ENABLE_TABLE:BOOL=ON
> ENABLE_X11:BOOL=ON
>
>
> backtrace and snooper look a little scary. What are they? Can they be
> turned off?

Backtrace and snooper you'd better have them on.

Backtrace is only useful if you are on Mac and doesn't have the "backtrace"
function at all.

Fcitx will write a log file to ~/.config/fcitx/log/crash.log if anything bad
happens with a backtrace for debugging.

Snooper is a way to workaround silly gtk input method implementation.

>
> Is there a way to see compile switches in the fcitx binary?
>

Currently, no.

>
> With `echo MainWindowHideMode=Hide >>
> ~/.config/fcitx/conf/fcitx-classic-ui.config`, things are perfect.
> Control+Space by default switches me between hangul & latin keyboard
> like I want for my initial support with Korean.
>
> However I want to setup a system wide configuration for
> "MainWindowHideMode=Hide", since I need to nuke $HOME in Webconverger
> to keep it a "clean slate" for the next user. For example
> ~/.config/fcitx/clipboard/history.dat could be a privacy violation
> between user sessions, so I need a rm -rf ~/.config at
> https://github.com/Webconverger/webc/blob/master/home/webc/webc.sh#L183

Change fcitx-classic-ui.desc, find the [ClassicUI/MainWindowHideMode] and
change the "DefaultValue" to whatever you want.

You can patch this file before you package it.

>
> I'm also curious to know how fcitx knows that I want hangul by default
> (without a ~/.config/fcitx). Because IIUC there is more than
> /usr/lib/fcitx/fcitx-hangul.so by default.
>

Fcitx have two way to register input method entry, one is more "static", the
other is "more" runtime (means list need to be generated by code).

Hangul use a static method.

You can check the file installed under
/usr/share/fcitx/inputmethod/hangul.conf , it have a "priority" value in it.
The priority value decides the default order of one input method (if
~/.config/fcitx/profile ) is not generated.

There is also some special value have special meaning. 0 means it will be
ignored completed (even not shown in available list), values larger than 100
means it's available but not enabled.

Regards
Xuetian

[Ma Xiaojun]

Hi, Weng

"ttf-wqy-microhei (based on ttf-droid, but cover a larger set of
character)" may not be true now.

Latest upstream release of ttf-droid is said to cover CJK ExtA.
But ttf-wqy-microhei is forked from ttf-droid old version that only
covers CJK and its addition hasn't covered ExtA.

Reference:
http://en.wikipedia.org/wiki/CJK_Unified_Ideographs
http://wenq.org/forum/viewtopic.php?f=12&t=1267

[Kai Hendry]

On 12 February 2013 11:03, Ma Xiaojun <damag...@gmail.com> wrote:
> Latest upstream release of ttf-droid is said to cover CJK ExtA.
> But ttf-wqy-microhei is forked from ttf-droid old version that only
> covers CJK and its addition hasn't covered ExtA.

Hi Ma,

Which version exactly of ttf-droid is that? Debian uses 20111207,
which sounds old:
http://packages.qa.debian.org/f/fonts-droid.html

I can see Archlinux source their own version from 20121017
https://projects.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ttf-droid#n14

Thanks for the tip! Now everything will look the same. ;) I guess
Dejavu etc can't compete with Google?

[Kai Hendry]

Hi,

I'm making notes on http://webconverger.org/fcitx/

And I have a branch with fcitx included.
https://github.com/Webconverger/webc/commits/fcitx

However im-fcitx.so is strangely not running, even though it's there in:
https://github.com/Webconverger/webc/tree/fcitx/usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/immodules

What am I missing??

Many thanks,

[Weng Xuetian]

On Thursday 28 February 2013 15:46:50，Kai Hendry :

http://fcitx-im.org/wiki/Input_method_related_environment_variables#GTK_IM_MODULE

Check this, if you compile it by hand, then you must missing updat the a
cached list for gtk immodules.

Regards
Xuetian

[Kai Hendry]

On 28 February 2013 21:39, Weng Xuetian <wen...@gmail.com> wrote:
> http://fcitx-im.org/wiki/Input_method_related_environment_variables#GTK_IM_MODULE
> Check this, if you compile it by hand, then you must missing updat the a
> cached list for gtk immodules.

Indeed I was missing the file, which I fixed here:
https://github.com/Webconverger/webc/commit/63fa077758b6b9e0710f4ab4be6a85adda2ba276
But it didn't work until I updated the file
/usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/gtk.immodules after much time
wasting :(

IIUC it doesn't matter if you have `export GTK_IM_MODULE=fcitx` env
variables setup, once this gtk.immodules is correctly setup,
im-fcitx.so always loads. Which makes me think... how do I turn
im-fcitx.so off for non-CJK character sets?
http://ix.io/4zm <-- looks wasteful especially if I'm using en_US. :/

Looking at https://github.com/Webconverger/webc/tree/fcitx/usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/immodules
is a bit scary. What or how are all those other input methods used?
Perhaps I shouldn't care, but I am wondering if there is any conflict.

https://github.com/Webconverger/webc/commits/fcitx

I am a South African, so I don't know how non-power user CJK people
actually interact with fcitx. My ambition is to support Hangul in
Webconverger 18.0. As I believe the interaction is simply:

ko: Hello [Ctrl+Space] Hangul [Ctrl+Space] back to latin chars

For C & J (which I plan to support later)

zh: Hello [Ctrl+Space] Pinyin
jp: Hello [Ctrl+Space] ????

Thanks in advance. :-)

[Weng Xuetian]

On Friday 01 March 2013 13:13:18，Kai Hendry :

> On 28 February 2013 21:39, Weng Xuetian <wen...@gmail.com> wrote:
> > http://fcitx-im.org/wiki/Input_method_related_environment_variables#GTK_IM
> > _MODULE Check this, if you compile it by hand, then you must missing updat
> > the a cached list for gtk immodules.
>
> Indeed I was missing the file, which I fixed here:
> https://github.com/Webconverger/webc/commit/63fa077758b6b9e0710f4ab4be6a85ad
> da2ba276 But it didn't work until I updated the file
> /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/gtk.immodules after much time
> wasting :(
>
> IIUC it doesn't matter if you have `export GTK_IM_MODULE=fcitx` env
> variables setup, once this gtk.immodules is correctly setup,
> im-fcitx.so always loads. Which makes me think... how do I turn
> im-fcitx.so off for non-CJK character sets?
> http://ix.io/4zm <-- looks wasteful especially if I'm using en_US. :/
>
> Looking at

> https://github.com/Webconverger/webc/tree/fcitx/usr/lib/i386-linux-gnu/gtk-> 2.0/2.10.0/immodules is a bit scary. What or how are all those other input

> methods used? Perhaps I shouldn't care, but I am wondering if there is any
> conflict.

No scary actually, it won't take more memory than you can notice, btw fcitx's
im module will just behave like "simple" or "none" if fcitx is not running.

If you really want to do that, just use export GTK_IM_MODULE to some thing
else, gtk-im-context-none for example.

>
> https://github.com/Webconverger/webc/commits/fcitx
>
> I am a South African, so I don't know how non-power user CJK people
> actually interact with fcitx. My ambition is to support Hangul in
> Webconverger 18.0. As I believe the interaction is simply:
>
> ko: Hello [Ctrl+Space] Hangul [Ctrl+Space] back to latin chars
>
> For C & J (which I plan to support later)
>
> zh: Hello [Ctrl+Space] Pinyin
> jp: Hello [Ctrl+Space] ????

Anthy / Mozc, pick up what fit you need.
>
> Thanks in advance. :-)


Regards
Xuetian

[Kai Hendry]

On 1 March 2013 14:09, Weng Xuetian <wen...@gmail.com> wrote:
> If you really want to do that, just use export GTK_IM_MODULE to some thing
> else, gtk-im-context-none for example.

Thanks for the tip. I've incorporated my non-crufty manual build of
fcitx-hangul here: https://github.com/Webconverger/webc/commits/fcitx

However the Hangul input method not loading. I re-enabled the classic
menu and tried to select the input method as shown upon
http://r2d2.webconverger.org/2013-03-01/fcitx-hangul.html but it just
disappears. I guess it's not loading properly, but I have no idea how
to debug what's going wrong.

Any ideas how I could debug this?

Many thanks,

[依云]

On Fri, Mar 01, 2013 at 01:13:18PM +0800, Kai Hendry wrote:
> [...]

>
> zh: Hello [Ctrl+Space] Pinyin
> jp: Hello [Ctrl+Space] ????

Just to point out, some zh_CN people will prefer Wubi, and zh_TW people
may need Cangjie or others.

--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

[Fei Ke]

To support these requirments he may try fcitx-rime.

[Kai Hendry]

On 21 March 2013 23:31, Fei Ke <zer...@gmail.com> wrote:
> To support these requirments he may try fcitx-rime.

https://github.com/fcitx/fcitx-rime IIUC from the README is mainly Chinese only?

Be good if there is non-BOOST and written in C.

I need to summon the energy to try get this working again. :-)

[Weng Xuetian]

On Friday 01 March 2013 14:58:57，Kai Hendry :

Check the command line out put to see if there is some "could not be found
library".

Regards
Xuetian

[Weng Xuetian]

On Tuesday 26 March 2013 14:42:51，Kai Hendry :

Well, actually you don't need to bother that..

rime is a little bit too fancy for your requirement. For chinese the built in
one is enough to support most common case.

Regards
Xuetian

[Weng Xuetian]

On Friday 01 March 2013 13:13:18，Kai Hendry :

> On 28 February 2013 21:39, Weng Xuetian <wen...@gmail.com> wrote:
> > http://fcitx-im.org/wiki/Input_method_related_environment_variables#GTK_IM
> > _MODULE Check this, if you compile it by hand, then you must missing updat
> > the a cached list for gtk immodules.
>
> Indeed I was missing the file, which I fixed here:
> https://github.com/Webconverger/webc/commit/63fa077758b6b9e0710f4ab4be6a85ad
> da2ba276 But it didn't work until I updated the file
> /usr/lib/i386-linux-gnu/gtk-2.0/2.10.0/gtk.immodules after much time
> wasting :(
>
> IIUC it doesn't matter if you have `export GTK_IM_MODULE=fcitx` env
> variables setup, once this gtk.immodules is correctly setup,
> im-fcitx.so always loads. Which makes me think... how do I turn
> im-fcitx.so off for non-CJK character sets?
> http://ix.io/4zm <-- looks wasteful especially if I'm using en_US. :/
>
> Looking at

> https://github.com/Webconverger/webc/tree/fcitx/usr/lib/i386-linux-gnu/gtk-> 2.0/2.10.0/immodules is a bit scary. What or how are all those other input

> methods used? Perhaps I shouldn't care, but I am wondering if there is any
> conflict.
>
> https://github.com/Webconverger/webc/commits/fcitx
>
> I am a South African, so I don't know how non-power user CJK people
> actually interact with fcitx. My ambition is to support Hangul in
> Webconverger 18.0. As I believe the interaction is simply:
>
> ko: Hello [Ctrl+Space] Hangul [Ctrl+Space] back to latin chars
>
> For C & J (which I plan to support later)
>
> zh: Hello [Ctrl+Space] Pinyin
> jp: Hello [Ctrl+Space] ????
>
> Thanks in advance. :-)

Anthy I guess.

https://github.com/fcitx/fcitx-anthy

Regards
Xuetian