> On 十月 4, 2016, 3:56 p.m., Eike Hein wrote:
> > Instead of using fcitx-, would it be possible to make generic icons per 
> > language code so they can also be used by kimpanel (which in turn can use 
> > fcitx or ibus or scim)? Do you really need different icons for each IME 
> > engine instead of just per language?
> > 
> > Having icons for specific fcitx plugins upstream seems like bad layering.
> 
> Yunhe Guo wrote:
>     > Instead of using fcitx-, would it be possible to make generic icons per 
> language code so they can also be used by kimpanel (which in turn can use 
> fcitx or ibus or scim)?
>     > Having icons for specific fcitx plugins upstream seems like bad 
> layering.
>     
>     I just use the same icon name in original Fcitx icons. These icons were 
> tested with Fcitx classic UI, not Kimpanel. But as far as I know, **kimpanel 
> is just a part of Fcitx project**. So here is no "fcitx plugin" problem. What 
> icons that Fcitx uses is always what kimpanel uses. So these icons will 
> provide same support to ibus and scim if they use kimpanel as UI (by default, 
> not).
>     
>     > Do you really need different icons for each IME engine instead of just 
> per language?
>     
>     Those Chinese IMEs are totally different. It is impossible to use only 
> one icon for all without confusing users.
> 
> Xuetian Weng wrote:
>     Can you separate the request into two different ones? input-keyboard 
> addition is quite generic. while the im icon is input method specific.
> 
> Yunhe Guo wrote:
>     Now input-keyboard in another patch 
> https://git.reviewboard.kde.org/r/129098/
> 
> Eike Hein wrote:
>     The situation is this:
>     * fcitx has its own UI frontend
>     * ibus has its own UI frontend
>     * plasma-desktop contains kimpanel, which can act as UI frontend for 
> either fcitx or ibus
>     
>     From the Plasma, POV we care most about kimpanel. kimpanel currently 
> shows the icons provided/requested by the IME. So if fcitx is used as 
> backend, it will show your icons. But it won't when using the ibus backend, 
> since ibus uses different icon names.
>     
>     My goal is to raise the visual quality level of the entire ecosystem - 
> many distros currently default to ibus, and when Plasma is started in a 
> locale that needs one, it will automatically add impanel to the panel as IME 
> frontend. Due to the lack of icons, that means CJK is currently 
> ugly-by-default for many users.
>     
>     So my proposed way to fix this would be:
>     * Agree on generic icon names (e.g. ime-zh-sunpinyin)
>     * Ask fcitx and ibus to switch to using the generic icon names
>     * For a transitional period, also provide the icons under legacy 
> fcitx/ibus names
> 
> Eike Hein wrote:
>     Sorry, RB fucked up my bullet lists. Fixed:
>     
>     The situation is this:
>     * fcitx has its own UI frontend 
>     * ibus has its own UI frontend
>     * plasma-desktop contains kimpanel, which can act as UI frontend for 
> either fcitx or ibus
>     
>     From the Plasma, POV we care most about kimpanel. kimpanel currently 
> shows the icons provided/requested by the IME. So if fcitx is used as 
> backend, it will show your icons. But it won't when using the ibus backend, 
> since ibus uses different icon names.
>     
>     My goal is to raise the visual quality level of the entire ecosystem - 
> many distros currently default to ibus, and when Plasma is started in a 
> locale that needs one, it will automatically add impanel to the panel as IME 
> frontend. Due to the lack of icons, that means CJK is currently 
> ugly-by-default for many users.
>     
>     So my proposed way to fix this would be:
>     * Agree on generic icon names (e.g. ime-zh-sunpinyin)
>     * Ask fcitx and ibus to switch to using the generic icon names
>     * For a transitional period, also provide the icons under legacy 
> fcitx/ibus names

Back to the purpose of this patch... It provide support for Fcitx. If you need 
ibus or scim, then that will be provided by other patches. That is beyond the 
topic here...

1. If this patch is acceptable, I will provide patches for ibus and scim later, 
based on this patch. Generic icon patch will be provided after they make a 
agreement on names. (Need quiet a long time)
2. If this patch is not acceptable, I need to improve it.

Generic icon names is a long time task. It is better to support something than 
nothing. It cannot be a good reason to reject this patch.


- Yunhe


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/129091/#review99774
-----------------------------------------------------------


On 十月 4, 2016, 4:38 p.m., Yunhe Guo wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129091/
> -----------------------------------------------------------
> 
> (Updated 十月 4, 2016, 4:38 p.m.)
> 
> 
> Review request for Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> -------
> 
> This patch adds icons for Fcitx system tray icon. Fcitx is the default input 
> method framework in most Chinese GNU/Linux desktop system. These icons will 
> make Fcitx looks better in system tray.
> 
> Icons included:
> 
> input.svgz
> 
> - input-keyboard
> 
> fcitx.svgz
> 
> - fcitx
> - fcitx-kbd
> - fcitx-pinyin
> - fcitx-shuangpin
> - fcitx-wubi
> - fcitx-pinyin-libpinyin
> - fcitx-shuangpin-libpinyin
> - fcitx-bopomofo
> - fcitx-sunpinyin
> - fcitx-googlepinyin
> - fcitx-emoji
> 
> 
> Diffs
> -----
> 
>   src/desktoptheme/breeze/icons/fcitx.svgz PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129091/diff/
> 
> 
> Testing
> -------
> 
> 
> File Attachments
> ----------------
> 
> Spectacle.Et8101.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/10/03/37e4e60f-d256-4799-a001-d3443d226f51__Spectacle.Et8101.png
> Spectacle.AD8101.png
>   
> https://git.reviewboard.kde.org/media/uploaded/files/2016/10/03/5d052366-942b-4a83-a055-6202423b6e64__Spectacle.AD8101.png
> 
> 
> Thanks,
> 
> Yunhe Guo
> 
>

Reply via email to