IBus UI review
by Matthias Clasen
Not sure if this is the correct place to send this, but I'll send it
here anyway (please tell me if there's a better place).
I've recently installed ibus in order to get some impression of how our
new im framework will integrate in the desktop. While playing with it, I
took some notes, that I'd like to share.
Matthias
---
Status icon
- The tooltip "IBus - Running" is pretty pointless less and should be
removed until there is something useful to say
- There is no way to switch back to "no input method" from the status
icon. I have to press Ctrl-space to go back. Maybe add an "None" entry
at the bottom of the menu ?
Toolbar
- Why do input methods seem to fancy these weird undecorated floating
toolbars ? Does it add anything that is not already present in the
status icon ?
- If we can't drop it, can there at least be a way to turn it off ?
- The toolbar seems useless if "focus-follows-mouse" is turned on, since
it becomes inactive on focus out. This also affects the status icon.
Menus
- What is the plan, going forward, wrt to im-chooser ? I'd hate to have
2 input method related menuitems in the default install. My preference
would be to not install the im-chooser by default, since it is only
needed to switch back to 'legacy' frameworks.
- It would be great if we could use the generic "Input Method" menuitem
for the ibus preferences, and maybe rename im-chooser to "Input Method
Framework" or something like that.
- Alternatively, if we can't get rid of im-chooser by default, maybe
ibus-setup should not have its own menu item (I notice that scim-setup
doesn't have one either), since it is available via im-chooser.
- There is a mismatch between the menuitem and the ibus-setup window,
both the window title and icon don't match the menu, as they should.
Preferences, General tab
- "Aauto start IBus on session login" is very techno babble. Can we make
that something like "Enable Input Methods" ? I don't think there is any
need to talk about sessions and autostart here.
- Keyboard shortcuts: I would love to see these moved to the keyboard
shortcuts capplet, which has support for handling application-defined
shortcuts. As a bonus, you get automatic conflict handling. The one
restriction is that currently, only one key-combination per action is
possible. If having multiple is essential, you could either split it
into "Trigger", "Alternative Trigger", "Second Alternative Trigger", or
file a bug and I'll look into enabling multiple shortcuts per action in
the keybinding capplet
- "UI" is a bad section label. How about "Fonts & Style" instead ? Even
better would be to split it into two sections, a la
Input Window
Lookup table orientation: [Vertical]
[ ] Use the system font
Input Window Font: [Sans 10]
Language Bar
[ ] Show language bar
[ ] Hide language bar when it is not needed
Preferences, Engine tab
- "Engine" is a technical term that is not really helpful here. How
about "Languages" instead ?
- There are some icons missing in the combo box, e.g Telugu-apple,
Telugu-rts, Marathi-phonetic, Marathi-itrans...
- The main list needs to repeat the language name (like the status icon
menu already does) otherwise it is not clear if "phonetic" is Oriya or
Marathi.
Preferences, About tab
This should not be done as a tab, it is very much against the style of
our preference tools. There is already an About menu item on the status
icon. If you absolutely want to have an "About" in the preferences, it
should be a left-aligned "About" button in the action area that brings
up an about dialog. But I'd really just get rid of it.
14 years, 11 months
Re: Fedora-i18n-list Digest, Vol 59, Issue 9
by Peter Pang
Hi,
I understand there is ibus-chewing for AI Zhuyin input method.
The request I submitted is mainly focused on "pure" Zhuyin input method.
There are users using chewing, but still many users are using traditional "pure" Zhuyin
input method. I would highlight this need so that ibus could also add this Zhuyin input
method.
Thanks for the web info, and how can I get the Zhuyin table for ibus-table?
I am simply a user and not good at ibus technical components.
Of course, the more I know, the more I can research.
Could we know any easier way to have "pure" Zhuyin in ibus system or how to handle tables?
Kind regards,
Peter
> Date: Thu, 16 Apr 2009 12:29:06 +1000
> From: Ding-Yi Chen <dchen(a)redhat.com>
> Subject: Re: request for ibus input method?
> To: Fedora internationalization discussions
> <fedora-i18n-list(a)redhat.com>
> Message-ID: <1239848946.3904.9.camel(a)localhost.localdomain>
> Content-Type: text/plain; charset=utf-8
>
> There is ibus-chewing for AI Zhuyin input method,
> However, if you are after "pure" zhuyin, you may provide a table for
> ibus-table.
>
> See
> http://code.google.com/p/ibus/issues/detail?id=94&q=table&colspec=ID%
> 20Component%20Type%20Status%20Priority%20Milestone%20Owner%20Summary
>
> For example.
>
> æ¼ ä¸ï¼2009-04-15 æ¼ 11:03 +0800ï¼Peter Pang æå°ï¼
> > Hi
> >
> > I am using Fedora 10 now and realize Fedora 11 is going to use ibus as default input
method.
> > Since we are using Zhuyin (Mandarin Phonetic Symbols 注é³è¼¸å
¥æ³) a lot and do
not find
> > this function in ibus now.
> >
> > Could you advise if there is any plan to add Zhuyin to ibus future?
> >
> > If this Zhuyin question is a FAQ, please give me a link to this FAQ subject.
> > Thanks.
> >
> > Kind regards,
> > Peter
> >
> > --
> > Fedora-i18n-list mailing list
> > Fedora-i18n-list(a)redhat.com
> > https://www.redhat.com/mailman/listinfo/fedora-i18n-list
> --
> Ding-Yi Chen
> Software Engineer
> Internationalization Group
> Red Hat, Inc.
>
> Looking to carve out IT costs?
> www.apac.redhat.com/promo/carveoutcosts/
>
> ------------------------------
>
> --
> Fedora-i18n-list mailing list
> Fedora-i18n-list(a)redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-i18n-list
>
> End of Fedora-i18n-list Digest, Vol 59, Issue 9
> ***********************************************
15 years
request for ibus input method?
by Peter Pang
Hi
I am using Fedora 10 now and realize Fedora 11 is going to use ibus as default input method.
Since we are using Zhuyin (Mandarin Phonetic Symbols 注音輸入法) a lot and do not find
this function in ibus now.
Could you advise if there is any plan to add Zhuyin to ibus future?
If this Zhuyin question is a FAQ, please give me a link to this FAQ subject.
Thanks.
Kind regards,
Peter
15 years
Re: ibus-hangul bugs
by Warren Togami
On 04/09/2009 09:53 PM, Choe Hwanjin wrote:
>>> I think it isn't acceptable for most users.
>> Would it be wrong for ibus-hangul to begin in Hangul mode? That seems very
>> reasonable?
>
> It's possible, but I think it is not a solution.
> Even if ibus-hangul begin in hangul mode, users should still press
> ctrl-space to
> input hangul and then user should press right-alt to change input mode, which
> don't have consistency.
Note: The medium-term plan is to get rid of global hotkey defaults.
This means Ctrl-space is only a global trigger for languages like
Chinese and Indic. Hankaku, Alt-Hankaku or Alt-` are triggers for
Japanese. Hangul or right-Alt are triggers for Korean.
For now we decided we are out of time for Fedora 11, so we will ship
with all the above triggers enabled as globals. This is not ideal. We
will improve this further after Fedora 11 after some design discussions.
>> I agree it should be configurable, but we need a compromise with expected
>> defaults for the Fedora 11 development deadline in less than a week.
>
> But current ibus' default lookup table orientation is horizontal not vertical.
> And ibus-hangul can't change its value.
> If we change the key mapping, it doesn't match the horizontal lookup table.
> Is it acceptable?
>
> I think that current ibus lookup table orientation is horizontal,
> therefore key mapping for
> lookup table should follow the orientation.
I'm surprised, but phuang made the new ibus default vertical. It seems
after Fedora 11 we will have vertical/horizontal decided by the language
engine.
> it is easy to make right-ctrl as Hanja conversion key.
> But it needs some time to add english mode in ibus-hangul.
> I don't have time to do it now.
> And basically I don't agree to add english mode in every language engine.
>
> And Shift-Space is mostly used trigger key in korean linux desktop.
> So I think shift-space is enough for now.
As noted above, we delayed implementing these proposed changes. In the
short-term the only remaining changes we need are the two patches for
right-Ctrl and proper arrow key behavior with vertical Hanja candidate
selection.
In the long-term we need further discussion about the Big Picture plan
forward. I will CC you with future summaries as we discuss this plan.
Thank you,
Warren Togami
wtogami(a)redhat.com
15 years
Re: ibus-hangul bugs
by Warren Togami
On 04/08/2009 12:44 AM, Choe Hwanjin wrote:
> On Tue, Apr 7, 2009 at 1:16 PM, Warren Togami<wtogami(a)redhat.com> wrote:
>> Hello Krisna,
>>
>> We have decided to make the Fedora ibus defaults behave exactly like Windows
>> IME in order to match the majority end-user expectations. This means we
>> will not ship with legacy default hotkeys in cases where they conflict like
>> Shift-Space. Users may configure it that way in options if they desire
>> non-default hotkeys and behaviors. I have bought a Korean USB keyboard so I
>> can test Korean input with both US and KO layouts.
>>
>> I hope for your comment on the following.
>>
>> 1) BTW, where did F9 as Hanja conversion button come from? This seems like
>> another legacy that conflicts with unrelated software. Windows and Mac do
>> not have F9 as Hanja by default. Perhaps this is because all modern Korean
>> keyboards have a Hanja button, making the legacy F9 obsolete?
>
> Yes, it is legacy. It came from hangul word processor and it still
> uses same key to
> convert hanja. It also used in Ami (old korean xim). scim-hangul,
> nabi, imhangul
> also use F9 as hanja conversion key. I prefer F9 and Hanja key as hanja
> conversion key.
> But if you insist, It's ok for me to remove F9 from hanja conversion keys.
Please keep F9 for now, until it can be configurable within ibus-hangul.
>
>> 2)
>> https://www.redhat.com/archives/fedora-i18n-list/2009-April/msg00004.html
>> Here is the current proposal for ~6-month ideal IM behavior, and the
>> compromise behavior for Fedora 11. Fedora 11 development freeze is one week
>> from now. I really need people to respond to this proposal.
>
> For koreans, they may be annoyed with right-alt and right-ctrl as trigger
> key and hanja conversion key.
> There are korean keyboard driver type 1, 2, 3 on windows, and with type 3,
> shift-space works as trigger key.
What is type 1 and 2?
>
>> 3)
>> https://bugzilla.redhat.com/show_bug.cgi?id=494445
>> ibus-hangul missing right-Alt or Hangul Han/En mode
>> How difficult might it be to implement this for ibus-hangul, so it behaves
>> equivalently to Windows Hangul? Currently it is especially unfriendly to
>> use ibus-hangul with a US keyboard layout because we lack Han/En mode
>> switching.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=491042
>> We especially need ibus-hangul to handle Han/En mode switching because we
>> cannot define right-Alt as a default global trigger, as it would be too
>> disruptive to non-Korean users.
>>
>> Do you agree? I really hope for your help to add this to ibus-hangul,
>> because without this ibus-hangul is not usable with US keyboard.
>
> It requires that the input framework is enabled on start, or a user should
> press trigger key twice.
>
> Let's think about the behavior:
> 1. Run gedit.
> 2. Input method is not enabled yet. So a user should enable input method by
> pressing 'ctrl-space'.
> 3. Now korean input method is enabled but it is in english mode. So the user
> should press 'right-Alt' or anything else.
> I think it isn't acceptable for most users.
Would it be wrong for ibus-hangul to begin in Hangul mode? That seems
very reasonable?
>
>> 4)
>> https://bugzilla.redhat.com/show_bug.cgi?id=493687
>> ibus-hangul should default to vertical candidate selection
>> phuang says the next build will do vertical candidate selection
>> automatically for both ko and ja.
>>
>> https://bugzilla.redhat.com/show_bug.cgi?id=493706
>> [PATCH] ibus-hangul Hanja arrow keys are wrong
>> I think this patch is reasonably correct, especially with ko vertical
>> candidate selection.
>
> I think ibus-hangul should detect lookup table orientation and change
> the arrow key behavior according to the lookup table orientation.
> And I think it should not fixed, it should be changeble by a user or a
> programmer.
I agree it should be configurable, but we need a compromise with
expected defaults for the Fedora 11 development deadline in less than a
week.
>
>> 5)
>> https://bugzilla.redhat.com/show_bug.cgi?id=493509
>> [PATCH] ibus-hangul missing right Ctrl for Hanja button
>>
>> I know you mentioned that some Korean users don't want this. My testing
>> however has found this to be default in Windows/Mac even with Korean layout
>> keyboard. I think this should be default because US keyboard users expect
>> it. You should add an option to ibus-hangul to turn it off if you think it
>> is important that some users really don't want it. Do you agree?
>
> It's not difficult to add another hanja conversion key.
> And it is better to make it configurable.
> But making hot key configure widget takes some time.
I agree it should be configurable, but again we need to have something
usable in a week. The Han/En issue above and to a small degree the lack
of this hotkey makes ibus-hangul currently unusable without a Korean
keyboard. We should add configurability after Fedora 11 when we have
more time to implement the ideal interface.
#4 above is the most important issue we have remaining for ibus in
Fedora 11.
>
>> 6)
>> https://bugzilla.redhat.com/show_bug.cgi?id=492929
>> ibus-hangul can cause gtk app to lockup
>> Very nasty bug hangul specific. phuang said he fixed this upstream but I am
>> waiting for new builds to test it.
>
> I didn't know that.
> I will test it later, because I have no time recently.
Good news, phuang fixed this, it was a bug in ibus core.
Warren Togami
wtogami(a)redhat.com
15 years
Draft IBus Hotkey Behavior Plan v0.1
by Warren Togami
Please comment on the below draft.
Cycle Hotkey Behavior
=====================
We have agreed to match the Windows IME hotkey cycling behavior in order
to match user expectations.
Alt-Shift
This hotkey cycles to the next language.
Ctrl-Shift
This hotkey cycles to the next engine within the current language, if
there is more than one engine for that language. In practice this only
does something in Chinese, while it does nothing in single engine
languages like Japanese or Korean. There is no time to implement this
for Fedora 11, so we will compromise by having Alt-Shift cycle through
all engines for all languages until we later implement this secondary
cycling hotkey.
Ideal Trigger Hotkey Behavior
=============================
After F11, we intend on changing the default behavior of hotkeys to be
similar to Windows behavior, where hotkeys associated with a language
are active only when that language engine is the current engine.
Chinese
CTRL-Space
India
CTRL-Space
Japanese
Hankaku, Alt-Hankaku, Alt-`
Korean
right-Alt
This means if Japanese is the current language engine, CTRL-Space does
nothing. If Korean is the current language engine, Alt-` does nothing.
The goal is to bring our IM behavior into line with non-technical normal
user (hint: not Linux user) expectations, while making it easy to
restore the old Linux behavior with an option.
I believe after we implement the above behavior, we could possibly
improve upon it:
* In this ideal plan, the global trigger hotkey would default to blank.
A user may set their desired global trigger hotkey if they want to
restore the previous behavior.
* We may want to consider always enabling non-native hotkeys deemed to
be non-conflicting, or making this an option. For example, Hankaku and
Alt-` wont upset any other user. right-Alt would upset non-Korean
users, however Han/En is unique and might be deemed as non-conflicting.
* Other possible improvements over Windows behavior.
This ideal plan would need to implement some type of per-language
hotkeys that inherit from the current engine. We don't have time to do
this before Fedora 11. Thus we will do a simpler plan for Fedora 11,
and return to do it properly later.
Fedora 11 Compromise Trigger Behavior Plan
==========================================
Default Global Triggers
CTRL-Space, Hankaku, Alt-Hankaku, Alt-`
These as default global triggers satisfy nearly all normal end-user
expectations without upsetting anyone.
Korean Hotkey Behavior
======================
https://bugzilla.redhat.com/show_bug.cgi?id=493509
US Layout Hotkeys
right-Alt Han/En switch in language bar, does not dismiss bar
right-Ctrl Hanja conversion button
KO Layout Hotkeys (might already be done, needs testing)
Han/En button switch in language bar, does not dismiss bar
Hanja conversion button
* phuang says Korean users expect Alt-Space as trigger, but it seems to
do nothing by default on Windows.
* krisna mentioned left-Alt as being expected to be Hanja, but it seems
to do nothing on Windows. US Korean users seem to universally expect
right-Ctrl to be Hanja.
* Variants of these preferences seem to exist. We should study SCIM
Hangul, Windows and Mac to see what preferences exist.
Japanese Hotkey Behavior
========================
(TODO)
Chinese Hotkey Behavior
=======================
(TODO)
Warren Togami
wtogami(a)redhat.com
15 years
ibus-hangul bugs
by Warren Togami
Hello Krisna,
We have decided to make the Fedora ibus defaults behave exactly like
Windows IME in order to match the majority end-user expectations. This
means we will not ship with legacy default hotkeys in cases where they
conflict like Shift-Space. Users may configure it that way in options
if they desire non-default hotkeys and behaviors. I have bought a
Korean USB keyboard so I can test Korean input with both US and KO layouts.
I hope for your comment on the following.
1) BTW, where did F9 as Hanja conversion button come from? This seems
like another legacy that conflicts with unrelated software. Windows and
Mac do not have F9 as Hanja by default. Perhaps this is because all
modern Korean keyboards have a Hanja button, making the legacy F9 obsolete?
2)
https://www.redhat.com/archives/fedora-i18n-list/2009-April/msg00004.html
Here is the current proposal for ~6-month ideal IM behavior, and the
compromise behavior for Fedora 11. Fedora 11 development freeze is one
week from now. I really need people to respond to this proposal.
3)
https://bugzilla.redhat.com/show_bug.cgi?id=494445
ibus-hangul missing right-Alt or Hangul Han/En mode
How difficult might it be to implement this for ibus-hangul, so it
behaves equivalently to Windows Hangul? Currently it is especially
unfriendly to use ibus-hangul with a US keyboard layout because we lack
Han/En mode switching.
https://bugzilla.redhat.com/show_bug.cgi?id=491042
We especially need ibus-hangul to handle Han/En mode switching because
we cannot define right-Alt as a default global trigger, as it would be
too disruptive to non-Korean users.
Do you agree? I really hope for your help to add this to ibus-hangul,
because without this ibus-hangul is not usable with US keyboard.
4)
https://bugzilla.redhat.com/show_bug.cgi?id=493687
ibus-hangul should default to vertical candidate selection
phuang says the next build will do vertical candidate selection
automatically for both ko and ja.
https://bugzilla.redhat.com/show_bug.cgi?id=493706
[PATCH] ibus-hangul Hanja arrow keys are wrong
I think this patch is reasonably correct, especially with ko vertical
candidate selection.
5)
https://bugzilla.redhat.com/show_bug.cgi?id=493509
[PATCH] ibus-hangul missing right Ctrl for Hanja button
I know you mentioned that some Korean users don't want this. My testing
however has found this to be default in Windows/Mac even with Korean
layout keyboard. I think this should be default because US keyboard
users expect it. You should add an option to ibus-hangul to turn it off
if you think it is important that some users really don't want it. Do
you agree?
6)
https://bugzilla.redhat.com/show_bug.cgi?id=492929
ibus-hangul can cause gtk app to lockup
Very nasty bug hangul specific. phuang said he fixed this upstream but
I am waiting for new builds to test it.
Warren Togami
wtogami(a)redhat.com
15 years
Re: iBus translations submission!
by Piotr Drąg
Xavier Conde Rueda pisze:
> thanks for the info, we'll have time to submit a translation. However,
> I would like to know why a core module like this is not in fedora-11
> but in various. In order to priorize translations, I would like to
> know which translations are "core" and which isn't. Why packagekit,
> rpm, yum, iBus and pulseaudio - among others - are not under the
> fedora-11 category? I think that this category should group all
> packages that are installed by default and are part of the system.
>
All of these are external modules, independent from Fedora. In
fedora-11-like categories we have only projects that we are upstream of.
--
Piotr Drąg
http://raven.pmail.pl
15 years
