[Fedora-i18n-bugs] [Bug 583545] Enable building Kimpanel and make a subpackage for it

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.


https://bugzilla.redhat.com/show_bug.cgi?id=583545

--- Comment #17 from Chen Lei <supercyper at 163.com> 2010-04-20 10:41:08 EDT ---
(In reply to comment #16)
> I see, the required D-Bus interface is shipped with current versions of Fcitx.
> Still, Fcitx is not our default input method solution, it only covers one
> language and so isn't suitable as a default, and I don't think it makes sense
> to allow installing kimpanel without a working backend. (On the other hand,
> requiring IBus probably doesn't guarantee you actually have an input method for
> your language, or even any language, installed either.)
> What I'd like to see is that installing kimpanel makes it work out of the box,
> i.e. you install kimpanel and have input methods fully working in KDE. That
> way, we could make kimpanel conditional on kdebase-workspace under
> input-methods in comps and a simple groupinstall would get you input method
> support after installing from the KDE spin.    

How about to ship kimpanel within kdeplasma-addons and kdeplasma-addons-libs?
It's small and won't break anything. Then we can ship ibus backend and some
other backends separately. The kimpanel itself is extendable and can have many
IM backends(currently only backends for ibus and the deprecated scim).

There we could make ibus backend conditional on kdebase-workspace under ibus in
comps as you suggested.

Note:
If we don't diable kimpanel scim backend and BR:scim-devel, kimpanel itself
won't depend on scim libs. Only scim backend will link with scim libs.

-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.