fcitx 4.2.4

[Weng Xuetian]

fcitx 4.2.4
1. fix some xim problem
2. add fcitx-gclient for glib and gir binding, can be used to control
fcitx or implement fcitx client.
3. merge fcitx-keyboard into fcitx
4. bind specific keyboard layout with inputmethod (you need up to date
fcitx-configtool，gtk3 ver or kcm-fcitx to configure this feature)
5. adjust some default hotkey setting.

NOTICE, if you’re using some custom xmodmap script, and if you don’t
want to be affected, please disable “override XKB system setting”.
Only xkb option is supported for now.

1、修复一些xim的问题。
2、增加fcitx-gclient，提供了glib和gir的绑定，可以用于控制fcitx或实现fcitx的client。
3、fcitx-keyboard 合并进 fcitx
4、将特定键盘布局和输入法绑定（需要最新的fcitx-configtool，gtk3版和或者kcm-fcitx来设置这个功能）
5、修改一些默认设置

注意，如果你使用自定义的xmodmap脚本，并且不希望受到影响，请禁用“覆盖系统XKB设置”，目前fcitx-xkb只支持xkb
option里面的设置不受影响。

fcitx-configtool 0.4.4
1. fix a potential crash with newer gtk3
2. rework gtk3 version UI, able to configure input method from input
method page

1、修复一个潜在的崩溃问题
2、重新修改gtk3版的界面，支持从输入法页配置输入法

kcm-fcitx 0.3.4
configure input method from input method page

支持从输入法页配置输入法。

fcitx-table-extra 0.3.1
1. adjust some quick-classic hotkey
2. fix some error in scj6
3. add wubi-large for large charset

1、调整速成古典版的快捷键
2、修复仓颉第六代的一些错误
3、增加五笔大字集的码表

fcitx-table-other 0.2.0
add more table from scim-table

从scim-table移植更多码表

fcitx-sunpinyin 0.3.7 + fcitx-cloudpinyin 0.2.2
need sunpinyin git master to save cloudpinyin result to sunpinyin userdict.

需要sunpinyin的git master，支持将cloudpinyin的输入法保存到sunpinyin用户词典中。

[Peiding CHEN]

Bravo!!!
Thanks

--
Peiding CHEN
Etudiant, Spécialité - Energétique et Environnement
Université Pierre et Marie CURIE
Paris
France

[Z C]

could you add any support for old system?

cannot compile fcitx-configtool on Ubuntu 10.04, because the GTK version is old

--
You received this message because you are subscribed to the Google Groups "fcitx" group.
To post to this group, send email to fc...@googlegroups.com.
To unsubscribe from this group, send email to fcitx+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fcitx?hl=en.

[wen...@gmail.com]

Even Gtk2 is not enough?

-DENABLE_GTK2=On -DENABLE_GTK3=Off

Z C于12-6-5 上午11:00写道：

[X Yin]

我想确认一下，升级到4.2.4之后，上次给4.2.3的那个xim和gio补丁是不是就用不
到了呢？

Thanks!

Sincerely yours
Xing

[Weng Xuetian]

是的

[Havanna]

以前的在拼音输入法下，按l_shift临时快速输入英文的快捷键被取消了吗？今天找来找去没找到该项设置

在 2012年6月3日星期日UTC+8下午7时48分08秒，csslayer写道：

[wen...@gmail.com]

1，临时英文模式不再存在了

2、可以设置为l shift选项仍然存在，但是功能变成和ctrl space一样。

记得现在的名字应该是“额外的输入法切换键”

Havanna于12-6-7 上午11:50写道：

--
You received this message because you are subscribed to the Google Groups "fcitx-dev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/fcitx-dev/-/fzyXfE4bMO4J.
To post to this group, send email to fcit...@googlegroups.com.
To unsubscribe from this group, send email to fcitx-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/fcitx-dev?hl=en.

[ogtifs]

I am sorry to say this update has completely ruined my fcitx
experience.

I am a C++ developer with a complex fcitx setup. My xkb layout is a
custom modified dvorak layout for entering English, French, German and
Chinese Pinyin (accented zìmǔ, not hànzì) via dead/compose keys. I use
fcitx primarily for Cangjie5, but also Pinyin, Korean Hangul, and a
module I wrote myself for entering hanzi from a hand tablet.

First of all the new fcitx is unable to be disabled, meaning I could
no longer enter in English. I found I needed to add one of the new
keyboards appearing in .config/fcitx/profile. Of course none of these
was my custom layout, but I chose an arbitrary one and used your
suggestion to change "overrideXkbSetting" in config-xkb. Now it
started to behave, I can enter in symbols I mapped onto my xkblayout
such as ß and currency symbols. Entering a dead key for an accented
character such as á or ǚ causes fcitx to crash with this error:

fcitx: symbol lookup error: /usr/lib/fcitx/fcitx-keyboard.so:
undefined symbol: unorm_normalize_49

I strongly disagree with the decision to change from a three-state to
a one-state model (not two-states since "Inactive" is just a different
layout). I understand you wish to make it simpler, but fcitx really
should not intercept every one of my xkb keystrokes when I want it
disabled, it's not supposed to be a keylogger! Please can we have
either two states (Disabled and Active) or equivalently, add a new
"keyboard layout" that leaves xkb to do what it wants without
interfering.

At this stage I am forced into the horrible situation of configuring
my window manager to launch fcitx with a keystroke and kill it with
another whenever I want to type some Chinese or Korean, just to let my
xkb layout work as it should.

Fcitx is an amazing piece of software that I use every day. If I can
be of help in any way please let me know. 感谢您的鼎力！

[XeCycle]

ogtifs <ogt...@gmail.com> writes:

> I am sorry to say this update has completely ruined my fcitx
> experience.

+1 on this.

> I am a C++ developer with a complex fcitx setup. My xkb layout is a
> custom modified dvorak layout for entering English, French, German and
> Chinese Pinyin (accented zìmǔ, not hànzì) via dead/compose keys. I use
> fcitx primarily for Cangjie5, but also Pinyin, Korean Hangul, and a
> module I wrote myself for entering hanzi from a hand tablet.

My layout is not so complicated as yours; it's a layout with some
keys remapped.

[...]

> I strongly disagree with the decision to change from a three-state to
> a one-state model (not two-states since "Inactive" is just a different
> layout). I understand you wish to make it simpler, but fcitx really
> should not intercept every one of my xkb keystrokes when I want it
> disabled, it's not supposed to be a keylogger! Please can we have
> either two states (Disabled and Active) or equivalently, add a new
> "keyboard layout" that leaves xkb to do what it wants without
> interfering.

Another problem here. I used to have C-\ to activate it, then
Shift to toggle; now I cannot. Shift at any time will toggle IM,
which is inconvenient in most times. But if I disable it I'll
have to use C-\ whenever I want to switch input method.

[...]

> Fcitx is an amazing piece of software that I use every day. If I can
> be of help in any way please let me know. 感谢您的鼎力！

Another thank you here. I hope you add a choice to revert to the
original behaviour.

--
Carl Lei (XeCycle)
Department of Physics, Shanghai Jiao Tong University
OpenPGP public key: 7795E591
Fingerprint: 1FB6 7F1F D45D F681 C845 27F7 8D71 8EC4 7795 E591

[Weng Xuetian]

As for the crash problem, I already notice it and fixed it upstream.
I will release 4.2.4.1 soon to address some bug in 4.2.4.

As for the model, well, I don't think the 3 state is easy to
understand, and not easy to control. I understand some people are
using complex xkb settings, so the xkb module can be even disabled
from kcm-fcitx or fcitx-configtool or use some option to make it work
like before.

The only difference that may not be changed back is that the "left
ctrl" behavior.

If you talk about keylogger-like behavior, that's what input method
for. And it's a must if you want to use compose key in application
which can only use xim. If you talk about the communication overhead
between application and input method framework, there are some place
that can be optimized in the future, but since it's not critical so
it's not on my list for now.

Hope you understand my decision.

> --
> You received this message because you are subscribed to the Google Groups

> "fcitx" group.
> To post to this group, send email to fc...@googlegroups.com.

> To unsubscribe from this group, send email to

> fcitx+un...@googlegroups.com.

> For more options, visit this group at

> http://groups.google.com/group/fcitx?hl=en.
>
>

[Weng Xuetian]

Actually your problem is not related to two state model, and can be
solved in a another way. I can understand and I know it maybe a
problem for some people. I may change some behavior of the key but the
model will not changed.

By the way, I hate to use shift so much so default is still left ctrl.
I even have mis-operation under windows. You can left ctrl a try, or
if you have a keyboard with right ctrl, you can even use right ctrl.

Hopefully I will change the modifier-based switch key (say single
shift, ctrl) behaviour in 4.2.5, which will be defined with "such key
will only used if it's active, or it's switch to inactive with such
key".

[XeCycle]

Weng Xuetian <wen...@gmail.com> writes:

> Actually your problem is not related to two state model, and can be
> solved in a another way. I can understand and I know it maybe a
> problem for some people. I may change some behavior of the key but the
> model will not changed.

I do understand this being simpler, but your change is radical.
Before you fix all obvious bugs you should probably leave this
an optional feature, and inform the user about this change.

> By the way, I hate to use shift so much so default is still left ctrl.
> I even have mis-operation under windows. You can left ctrl a try, or
> if you have a keyboard with right ctrl, you can even use right ctrl.

# 可选值：
# R_CTRL R_SHIFT L_SHIFT L_CTRL ALT_L_SHIFT ALT_R_SHIFT
# CTRL Both SHIFT Both Disabled

Too few choices here. I have left Ctrl and Alt swapped, so I
should use L_ALT if I follow your advice; but it's not available
here.

BTW I use CTRL for second candidate.

> Hopefully I will change the modifier-based switch key (say single
> shift, ctrl) behaviour in 4.2.5, which will be defined with "such key
> will only used if it's active, or it's switch to inactive with such
> key".

Does that mean, I can C-\ to get it enabled, then Shift to
disable, but not Shift to get back again?

[Weng Xuetian]

On Sun, Jun 10, 2012 at 10:42 PM, XeCycle <xec...@gmail.com> wrote:
> Weng Xuetian <wen...@gmail.com> writes:
>
>> Actually your problem is not related to two state model, and can be
>> solved in a another way. I can understand and I know it maybe a
>> problem for some people. I may change some behavior of the key but the
>> model will not changed.
>
> I do understand this being simpler, but your change is radical.
> Before you fix all obvious bugs you should probably leave this
> an optional feature, and inform the user about this change.
>
>> By the way, I hate to use shift so much so default is still left ctrl.
>> I even have mis-operation under windows. You can left ctrl a try, or
>> if you have a keyboard with right ctrl, you can even use right ctrl.
>
> # 可选值：
> # R_CTRL R_SHIFT L_SHIFT L_CTRL ALT_L_SHIFT ALT_R_SHIFT
> # CTRL Both SHIFT Both Disabled
>
> Too few choices here.  I have left Ctrl and Alt swapped, so I
> should use L_ALT if I follow your advice; but it's not available
> here.

(Complains that there are so few key on keyboard :P, I don't add alt
here since alt is some key I think should not here. Anyway it's easy
to add. )

>
> BTW I use CTRL for second candidate.
>
>> Hopefully I will change the modifier-based switch key (say single
>> shift, ctrl) behaviour in 4.2.5, which will be defined with "such key
>> will only used if it's active, or it's switch to inactive with such
>> key".
>
> Does that mean, I can C-\ to get it enabled, then Shift to
> disable, but not Shift to get back again?

Actually I mean, initially:
-> only C-\ to enable (1)
-> if you use shift to disable, then you can use shift to enable it again.
-> if you use other key or other method to disable, then you cannot
use shift to enable it (back to 1).

[XeCycle]

Weng Xuetian <wen...@gmail.com> writes:

[...]

> (Complains that there are so few key on keyboard :P, I don't add alt
> here since alt is some key I think should not here. Anyway it's easy
> to add. )

Okay, thanks. However I think it better to use a general syntax
to express arbitrary keys here, allowing more flexibility.

>> BTW I use CTRL for second candidate.
>>
>>> Hopefully I will change the modifier-based switch key (say single
>>> shift, ctrl) behaviour in 4.2.5, which will be defined with "such key
>>> will only used if it's active, or it's switch to inactive with such
>>> key".
>>
>> Does that mean, I can C-\ to get it enabled, then Shift to
>> disable, but not Shift to get back again?
>
> Actually I mean, initially:
> -> only C-\ to enable (1)
> -> if you use shift to disable, then you can use shift to enable it again.
> -> if you use other key or other method to disable, then you cannot
> use shift to enable it (back to 1).

Nice :) I'll try git checkouts if you'll fix them soon.

[Peiding CHEN]

I would like return to three-state switch too.
Alternatively, I wrote a script to kill or start fcitx process and set ctrl+space to this script. But I can't get back my previous input method when I restart.
So I changed several keyboard shortcut and try to get used to the new change.

[Weng Xuetian]

Please do not complain two-state switch with such reason. The three
state never have a clear definition, what's the difference between
"close" and "inactive" and what's the relationship of them between
keyboard layout, no clear answer.

If only shift will be used if they are used to inactivate input method
(or called, switch to the first one), it's easy to implement. You guys
can give master a try.

For people who using the custom xkb (means, custom layout, xmodmap or
something similar), disable xkb module will work.

[Peiding CHEN]

For me, it only involves the habit.

please do something to deal with this:

I usually set "ctrl+shift+T" to open a new tab in terminal. With fcitx-4.2.4, when I finish creating the new tab. Input method is changed to. (I made a mistake, I mentioned "ctrl+shift" to open a new tab)

Thanks

[Weng Xuetian]

So do I, I also use ctrl shift t to create terminal tab.

Unless you release "shift" before "t", there will be no problem.

If you think it's a trouble for you, you can choose "alt shift", "alt
super" or disable this key.

[Peiding CHEN]

Yeah, I've already done it.

[Oliver Giles]

Let me try to word this more carefully:

Previously there was a three-state model. I agree with you: this is
overly complicated, the definition was not so clear.

Now we have a one-state model. Fcitx is always enabled, you can just
change the "layout".

I understand your comment about an IME is like a keylogger. I'm simply
saying it would be nice to be able to turn off fcitx without having to
kill it. To me, the best solution is a real two-state model:

On = fcitx intercepts keystrokes, applies its current layout behaviour
and produces characters
Off = fcitx is disabled, does not intercept keystrokes, leaves the
keyboard up to xkb. This could be seen as either of the previous
"Disabled" and "Inactive" states.

By "disable xkb module" do you mean compile it with some configure-time
parameter, or set the "overrideXkbLayout" to false, or some other
disable option I'm unaware of? If I understand correctly, by removing
the module completely I will be unable to use my xkb layout at all,
since it is currently not possible to disable fcitx.

[Weng Xuetian]

I just say disable the xkb module in fcitx, just like this.

http://wstaw.org/m/2012/06/11/plasma-desktopTJ1579.png.

It only means you cannot use fcitx to switch layout, you can still use
your old way (like from your desktop), doesn't mean anything more.

[Weng Xuetian]

By the way, the second module in screentshot will be disabled by
dependency, and it only expose some dbus interface for xkb module, so
you don't need to touch it.

On Mon, Jun 11, 2012 at 7:51 AM, Oliver Giles <ogt...@gmail.com> wrote:

[Oliver Giles]

Is there an alternate interface to this configuration option? I use a
minimal window manager on Arch Linux, no KDE or Gnome, and typically
configure fcitx by editing files in ~/.config/fcitx

Thank you for your patience.

[Weng Xuetian]

the screenshot is using fcitx-configtool, a gtk3 one. I don't think it
will introduce too much dependency for you, (more and more gtk2
application will be ported to gtk3, so I expect that useless people
hate gtk3 or have old system, they will have gtk3 on there system. ).

Or you can adjust the pkgbuild to build a gtk2 version (UI is a little
bit different, but still no much dependency)
(add -DENABLE_GTK2=On -DENABLE_GTK3=Off to cmake option)

It's highly recommended at least to have a gtk3 version UI, since for
gtk one, it will be mainly maintained in the future. (Which means,
gtk2 version will probably only have bug fix in the future).

If you insist on "least dependency",
create this file (~/.config/fcitx/addon/fcitx-xkb.conf) with this content.

[Addon]
Enabled=False

BTW, It will not stop sending all the key to fcitx. And you still need
to make sure "English US" is at the first one (though it's not "real"
english us).