GNOME Bugzilla – Bug 689040
candidate window of input source integration is ugly
Last modified: 2013-02-12 04:57:25 UTC
The padding of the candidate selection popup is too large that can keep out an enormous amount of space on the content of window.
Created attachment 229833 [details] screenshot attached
Is this the stock gnome-shell candidate window ? I can't seem to get it to produce a horizontal layout here, I always get a vertical one.
(In reply to comment #2) > Is this the stock gnome-shell candidate window ? I can't seem to get it to > produce a horizontal layout here, I always get a vertical one. There is one setting at ibus-setup, toggle it to vertical one, and kill ibus-daemon, restart gnome-shell. This will switch you to a vertical one. (which is the default setting for Chinese?) But in fact, toggle it to vertical one is still ugly... the padding is way to large.
I'm going to ask for input from a designer here. But be aware that the popups are part of the shell and thus must remain visually consistent.
I agree with the bug report. There are some mockups for the candidate windows on github: https://raw.github.com/gnome-design-team/gnome-mockups/master/input-sources/input-sources-summary.png
Ok, so let's make this bug be about what we need from the candidate popups. Right now the popups include the following elements in the following order (not all of them are necessarily visible at the same time): [ preedit text ] [ auxiliary text ] [ candidates table ] * preedit is used to display the characters that are going to be committed to the widget when the widget isn't able to display them itself. AFAICT, this only happens for XIM using applications like xterm. * auxiliary is used differently by different engines. E.g. ibus-libpinyin displays the latin characters as they are being typed there while ibus-anthy displays used auxiliary to display a string like (4/6) to explicitly convey the pagination of the candidates table. * the candidates table is pretty much what is says and it comes in 2 orientations, vertical and horizontal, which is determined by the engine. (I think this is configurable by engine and then the main ibus-daemon has an override setting for this) So, we have this ambiguity about the auxiliary string which we should discuss with engine developers and try to standardize because what we're doing now is applying the same style to something that has different meanings according to each engine. Mike, your input here is very welcome.
Takao, can we have your input about this?
I think the original bug is the pad is too large. It was not happened in ibus-gjs: http://desktopi18n.wordpress.com/2012/01/13/ibus-gjs-new-lookup-window/ After you removed the css file, the pad was enlarged. https://github.com/fujiwarat/ibus-gjs/blob/master/data/theme/gnome-shell.css#L2054 I think showing "(4/6)" is good and it's default in ibus gtk candidate window but it seems pinyin override the label. Is it another issue against the original bug? I think the custom auxiliary window is needed by pinyin.
(In reply to comment #8) > I think the original bug is the pad is too large. > It was not happened in ibus-gjs: > http://desktopi18n.wordpress.com/2012/01/13/ibus-gjs-new-lookup-window/ > > After you removed the css file, the pad was enlarged. > https://github.com/fujiwarat/ibus-gjs/blob/master/data/theme/gnome-shell.css#L2054 > > I think showing "(4/6)" is good and it's default in ibus gtk candidate window > but it seems pinyin override the label. Is it another issue against the > original bug? > I think the custom auxiliary window is needed by pinyin. (In reply to comment #6) > Ok, so let's make this bug be about what we need from the candidate popups. > > Right now the popups include the following elements in the following order (not > all of them are necessarily visible at the same time): > > [ preedit text ] > [ auxiliary text ] > [ candidates table ] > > * preedit is used to display the characters that are going to be committed to > the widget when the widget isn't able to display them itself. AFAICT, this only > happens for XIM using applications like xterm. > > * auxiliary is used differently by different engines. E.g. ibus-libpinyin > displays the latin characters as they are being typed there while ibus-anthy > displays used auxiliary to display a string like (4/6) to explicitly convey the > pagination of the candidates table. > > * the candidates table is pretty much what is says and it comes in 2 > orientations, vertical and horizontal, which is determined by the engine. (I > think this is configurable by engine and then the main ibus-daemon has an > override setting for this) > > So, we have this ambiguity about the auxiliary string which we should discuss > with engine developers and try to standardize because what we're doing now is > applying the same style to something that has different meanings according to > each engine. > > Mike, your input here is very welcome. Oh, Wow. This is the first time in my life seeing the auxiliary text looks like this. So in Chinese, the string like (1/5) is helpless because the number tend to be (1/60). In Chinese this auxiliary text is usually showed as "full preedit", containing finished Chinese characters and unfinished (in searching) pinyins. It does look weird when you have a preedit text showing up. For most of Chinese users the preedit looks either duplicate or only show the finished Chinese characters. Chinese user don't have a habit of looking at the preedit text at the top. Because the auxiliary text is closer to search result. It also have historical reasons, back in the 1990s, input method don't have callbacks, so auxiliary text show the pinyin, and following is the search result. I don't think making the auxiliary text consistent is possible.
*** This bug has been marked as a duplicate of bug 691902 ***