kimtoy in kdereview

[nihui]

hi
 
Yes, we have kimpanel plasmoid in plasma-addons, and we have skim for scim in old kde3 days.
kimtoy is technically the standalone version of kimpanel plasmoid with many additional features.
Both kimtoy and kimpanel plasmoid are strictly not input method framework like ibus,
they act as frontend(or panel) for the underlying input method frameworks.
Users can still write/type using ibus built-in frontend without KDE ones,
but some nice intergrations between KDE and input method frameworks will be missing,
such as storing ibus settings in kconfig instead of gconf/dconf and consistent style in KDE environment, etc.
 
the benefits of kimtoy over the current kimpanel plasmoid includes:
no dependence on a running plasma desktop, you can use it in other DE like xfce...
kconfig intergration for ibus and scim
very powerful theming support and customization
more intergration, thumbnailers and strigi analyzers
 
best wishes,
nihui


在 2012-08-16 00:44:45，"Albert Astals Cid" <aacid at kde.org> 写道：
>El Dissabte, 11 d'agost de 2012, a les 11:43:45, nihui水竹院落 va escriure:
>> hi all
>
>Hi
>
>> 
>> I am very happy to inform you all that kimtoy is now in kdereview. The final
>> target is extragear-utils.
>> 
>> kimtoy is an input method frontend for KDE. It is an alternative to kimpanel
>> plasmoid. kimtoy aims to provide a stable and intergrated frontend for
>> input methods, such as fcitx, scim and ibus. kimtoy makes easy for
>> fcitx/ibus/scim users. These three input methods should work out of box.
>> 
>> it has a powerful theming system, it supports hundreds of sogou skins from
>> http://pinyin.sogou.com/skins/ (in chinese) and fcitx skins. it is a quite
>> handy and useful tool for East Asian language users. If you type
>> chinese/japanese/korean etc, try it and you will love it ;)
>> 
>> app page with some screenshots:
>> http://kde-apps.org/content/show.php?content=140967
>> 
>> 
>> your reviews and comments are welcome :)
>
>Didn't we have something like this previously? If we had what are the benefits 
>of this over what we have at the moment?
>
>And if we did not have anything like this, how did people write before?
>
>Sorry for being 0 knowledgeable in this issue :-)
>
>Cheers,
>  Albert
>
>> 
>> 
>> best wishes,
>> nihui
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20120816/e6abe0fe/attachment.htm>