Kimpanel,aka KDE Input Method Panel, is a universal frontend for multiple input methods, keeping them with integrated and uniform looks with KDE. Kimpanel is now disabled. Because the default building procedure will search for scim header, if not found, Kimpanel will not be built. And there are two approaches to building Kimpanel. One is re-adding scim-devel as BR, another is disabling scim header searching with a patch I adopted from Kubuntu. I would prefer the latter one. And after building Kimpanel itself, I would make a subpackage for the IBus backend. And I now have two proposals to get it done. I would prefer the latter one. 1. Install the IBus component provided by upstream to make Kimpanel as the frontend for IBus. Attached spec patch: kdeplasma-addons-spec-xml.patch Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=2124289 Advantages: * The frontend for IBus changing out of box. * No new alternative and scriptlet. * The original frontend of IBus will be restored when the subpackage is removed. Disadvantages: * Kimpanel will be the frontend for IBus in all desktop environments, not exclusively in KDE. * A Python module will be installed to /usr/libexec/ . (This can also be overcome by patching the IBus component file.) 2. Install an alternative of xinputrc for each Kimpanel backend, though, by now, only for the IBus backend. I would prefer this one. Attached spec patch: kdeplasma-addons-spec-xinput.patch Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=2124285 Advantage: * Manual input method choosing with im-chooser * The python module can be installed to recommended path. Disadvantage: * New alternative of xinputrc may seem redundant.
Created attachment 407483 [details] Patch for the first proposal
Created attachment 407484 [details] Patch for the second proposal
> Kimpanel is now disabled. Because the default building procedure will search > for scim header, if not found, Kimpanel will not be built. Also because we didn't know how to make the IBus backend work out of the box, without manual configuration. The big issue there is that there are 2 components, the "frontend" plugged into the daemon which just exports a D-Bus interface and the plasmoid, which both need to be set up together and which are controlled by different mechanisms. > And there are two approaches to building Kimpanel. One is re-adding scim-devel > as BR, another is disabling scim header searching with a patch I adopted from > Kubuntu. I would prefer the latter one. Me too. We don't want kdeplasma-addons to depend on the deprecated SCIM. > And after building Kimpanel itself, I would make a subpackage for the IBus > backend. The subpackage should be all of kimpanel including the IBus backend. It doesn't make sense to ship kimpanel with no backend. > 1. Install the IBus component provided by upstream to make Kimpanel as the > frontend for IBus. [snip] > Disadvantages: > * Kimpanel will be the frontend for IBus in all desktop environments, not > exclusively in KDE. This is a no go. The other desktop folks won't like this one. > 2. Install an alternative of xinputrc for each Kimpanel backend, though, by > now, only for the IBus backend. I would prefer this one. [snip] > Advantage: > * Manual input method choosing with im-chooser That's not an advantage, quite the opposite. This solution is also not acceptable. We need to: * have Kimpanel be the default IBus backend IF AND ONLY IF the user is running KDE (yes, this means the desktop must be detected at runtime and an appropriate backend chosen), * have the Kimpanel plasmoid be added to the panel (or the systray if possible) automatically if it is installed (e.g. using a Plasma setup script, as allowed by KDE >= 4.4).
And where is that ibus-kde.conf file you're using as Source1? And attaching that Kubuntu patch would also be helpful so we don't have to track it down.
And FYI, Kimpanel being a plasmoid, it won't work at all outside of KDE (well, you can use it inside a plasmoidviewer, but ugh!), so the frontend to use MUST be detected at runtime. Neither your solution 1. (as you say) nor your solution 2. (which is based on alternatives, which are a global systemwide choice) do this.
> The subpackage should be all of kimpanel including the IBus backend. It doesn't > make sense to ship kimpanel with no backend. Yeah. In foreseeable future, making a Kimpanel subpackage including all supported backends is a better solution, because, by now, only the IBus backend provides files, excluding the backend for the deprecated SCIM. If the ibus backend installs files to path which owned by ibus package, then kimpanel subpackage will have to require ibus. > We need to: > * have Kimpanel be the default IBus backend IF AND ONLY IF the user is running > KDE (yes, this means the desktop must be detected at runtime and an appropriate > backend chosen), > * have the Kimpanel plasmoid be added to the panel (or the systray if possible) > automatically if it is installed (e.g. using a Plasma setup script, as allowed > by KDE >= 4.4). OK. These are affirmatively the final goals. > And FYI, Kimpanel being a plasmoid, and also a ususal executable '/usr/bin/kimpanel' . It will work just by running that command in any desktop environment. After all, I just want to remind you of this. I know people will not like to use Kimpanel in their GTK+-based desktop environments.
Created attachment 407494 [details] an alternative of xinputrc for ibus+kimpanel
Created attachment 407495 [details] patch from Kubuntu to diable kimpanel scim backend
Created attachment 407497 [details] patch for correcting IBus icon path
Created attachment 407609 [details] Enable building Kimpanel and make a subpackage for it A new build Attached spec patch: kdeplasma-addons-spec-kimpanel.patch Koji scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=2124910 In this build: 1. 'plasma-kimpanel' is a standalone and complete subpackage for Kimpanel. > * have Kimpanel be the default IBus backend IF AND ONLY IF the user is running > KDE (yes, this means the desktop must be detected at runtime and an appropriate > backend chosen), This goal will easily be met if additional runtime detecting commands are added to ibus.conf. I filed a new bug against ibus: https://bugzilla.redhat.com/show_bug.cgi?id=583716
I have some suggestions. /usr/lib64/kde4/plasma_wallpaper_marble.so->plasma-wallpaper-marble /usr/lib/kde4/plasma_applet_kimpanel.so->plasma-applet-kimpanel So I think plasma-applet-kimpanel may be a more appropriate name for the kimpanel subpackage. Because applets/kimpanel/backend/ibus/panel.py import ibus python modules, So it depends on ibus. I think it's reasonable to split out a kimpanel ibus subpackage to reduce the dependencies of plasma-applet-kimpanel. Also we can temporarily not ship panel.py until it's stable enough for fedora.
> Because applets/kimpanel/backend/ibus/panel.py import ibus python modules, So > it depends on ibus. I think it's reasonable to split out a kimpanel ibus > subpackage to reduce the dependencies of plasma-applet-kimpanel. Also we can > temporarily not ship panel.py until it's stable enough for fedora. 'panel.py' must be included. Though it's not stable _enough_, it works well. If 'panel.py' not installed to /usr/libexec, which is the place recommended by upstream, /usr/share/%{name of the kimpanel package}/ may also a good place. 'panel.py' will work wherever it was placed. And because kimpanel will have nothing to do with ibus if ibus is not installed and can work with other backend instead, it's not necessary to make it requiring ibus. Or if /usr/share/ibus/ui/kimpanel is finally considered the better place, then making a subpackage for ibus backend must be the necessary solution.
If we want to use the same naming convention as for third-party plasmoid packages, then kde-plasma-kimpanel would be the name to use. Alternatively, we could also use traditional subpackage naming (kdeplasma-addons-kimpanel). I think kimpanel should just require IBus. It's the only backend we're shipping. Kimpanel won't work at all without IBus.
(In reply to comment #13) > I think kimpanel should just require IBus. It's the only backend we're > shipping. Kimpanel won't work at all without IBus. There is Fcitx backend available, which ships no file. Kimpanel will work with Fcitx and without IBus.
(In reply to comment #13) > I think kimpanel should just require IBus. It's the only backend we're > shipping. Kimpanel won't work at all without IBus. In other word, Fcitx+Kimpanel will work without additional supporting file.
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.
(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.
Well, I'd like to ship with kimpanel a Plasma script which adds the plasmoid to the panel by default if it's installed, so it works out of the box. If we allow users to install only kimpanel and no backend, that wouldn't be that great an idea, though we could maybe ship the script with the IBus backend.
I am going to make the same case that if someone chose Fcitx and installed Kimpanel, when s/he logs in KDE, Kimpanel will be the frontend of Fcitx. So I will not accept that the package which contains Kimpanel itself requires IBus.
Created attachment 408331 [details] Enable building Kimpanel and make a subpackage for it A new build. Koji: http://koji.fedoraproject.org/koji/taskinfo?taskID=2132394 In this build: 1. A plasma desktop script is added. Kimpanel will be added to the panel automatically after a new login when the package installed. And I wrote little JavaScript, so somebody may optimise the codes. 2. The subpackage is named 'plasma-applet-kimpanel' after the same convention of 'plasma-wallpaper-marble'. 3. 'panel.py' is moved to '%{_kde4_appsdir}/kimpanel/backend/ibus/'. And I had a test showing that the IBus backend will not work if this file is not executable. By the way, plasma desktop scripts may use two new directories: '%{_kde4_appsdir}/plasma-desktop/updates' and '%{_kde4_appsdir}/plasma-desktop/init'. So these directories should be added to the 'kdebase-workspace' package. Refer to: http://techbase.kde.org/KDE_System_Administration/PlasmaDesktopScripting
Created attachment 408334 [details] Plasma desktop script adding Kimpanel to panel automatically
Created attachment 408379 [details] Enable building Kimpanel and make a subpackage for it fix directory ownership and requirement
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle. Changing version to '14'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I'm taking this off the 4.5 tracker as it's clearly not a blocker. (We haven't been shipping Kimpanel all this time.)
So what is this issue going on then? if we still need to take any action, please move out from f14 to avoid auto-closing.
KDE SC 4.8 now has a rewritten kimpanel. I haven't looked at what exactly needs to be done to package it (hopefully it will be more automatic), but I suspect that the ibus changes we've been asking for in bug #583716 will still be needed.
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle. Changing version to '19'. (As we did not run this process for some time, it could affect also pre-Fedora 19 development cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.) More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
This was implemented awhile back, but unfortunately, can't find specific mention of it in kdeplasma-addons changelog