Bug 583545 - Enable building Kimpanel and make a subpackage for it
Enable building Kimpanel and make a subpackage for it
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kdeplasma-addons (Show other bugs)
19
All Linux
low Severity medium
: ---
: ---
Assigned To: Rex Dieter
Fedora Extras Quality Assurance
: i18n
Depends On:
Blocks: 583716
  Show dependency treegraph
 
Reported: 2010-04-19 00:49 EDT by Robin Lee
Modified: 2014-09-30 11:28 EDT (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-09-30 11:28:29 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch for the first proposal (3.21 KB, patch)
2010-04-19 00:51 EDT, Robin Lee
no flags Details | Diff
Patch for the second proposal (4.03 KB, patch)
2010-04-19 00:54 EDT, Robin Lee
no flags Details | Diff
an alternative of xinputrc for ibus+kimpanel (261 bytes, application/octet-stream)
2010-04-19 02:06 EDT, Robin Lee
no flags Details
patch from Kubuntu to diable kimpanel scim backend (968 bytes, patch)
2010-04-19 02:07 EDT, Robin Lee
no flags Details | Diff
patch for correcting IBus icon path (733 bytes, patch)
2010-04-19 02:09 EDT, Robin Lee
no flags Details | Diff
Enable building Kimpanel and make a subpackage for it (2.88 KB, patch)
2010-04-19 10:27 EDT, Robin Lee
no flags Details | Diff
Enable building Kimpanel and make a subpackage for it (3.34 KB, patch)
2010-04-22 10:08 EDT, Robin Lee
no flags Details | Diff
Plasma desktop script adding Kimpanel to panel automatically (790 bytes, text/javascript)
2010-04-22 10:13 EDT, Robin Lee
no flags Details
Enable building Kimpanel and make a subpackage for it (3.35 KB, patch)
2010-04-22 12:43 EDT, Robin Lee
no flags Details | Diff

  None (edit)
Description Robin Lee 2010-04-19 00:49:25 EDT
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.
Comment 1 Robin Lee 2010-04-19 00:51:40 EDT
Created attachment 407483 [details]
Patch for the first proposal
Comment 2 Robin Lee 2010-04-19 00:54:01 EDT
Created attachment 407484 [details]
Patch for the second proposal
Comment 3 Kevin Kofler 2010-04-19 01:02:24 EDT
> 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).
Comment 4 Kevin Kofler 2010-04-19 01:04:49 EDT
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.
Comment 5 Kevin Kofler 2010-04-19 01:11:06 EDT
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.
Comment 6 Robin Lee 2010-04-19 02:04:36 EDT
> 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.
Comment 7 Robin Lee 2010-04-19 02:06:13 EDT
Created attachment 407494 [details]
an alternative of xinputrc for ibus+kimpanel
Comment 8 Robin Lee 2010-04-19 02:07:41 EDT
Created attachment 407495 [details]
patch from Kubuntu to diable kimpanel scim backend
Comment 9 Robin Lee 2010-04-19 02:09:24 EDT
Created attachment 407497 [details]
patch for correcting IBus icon path
Comment 10 Robin Lee 2010-04-19 10:27:50 EDT
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
Comment 11 Chen Lei 2010-04-20 06:20:17 EDT
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.
Comment 12 Robin Lee 2010-04-20 06:56:10 EDT
> 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.
Comment 13 Kevin Kofler 2010-04-20 09:13:54 EDT
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.
Comment 14 Robin Lee 2010-04-20 10:00:18 EDT
(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.
Comment 15 Robin Lee 2010-04-20 10:02:20 EDT
(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.
Comment 16 Kevin Kofler 2010-04-20 10:13:13 EDT
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.
Comment 17 Chen Lei 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.
Comment 18 Kevin Kofler 2010-04-20 10:54:16 EDT
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.
Comment 19 Robin Lee 2010-04-20 12:09:26 EDT
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.
Comment 20 Robin Lee 2010-04-22 10:08:57 EDT
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
Comment 21 Robin Lee 2010-04-22 10:13:10 EDT
Created attachment 408334 [details]
Plasma desktop script adding Kimpanel to panel automatically
Comment 22 Robin Lee 2010-04-22 12:43:32 EDT
Created attachment 408379 [details]
Enable building Kimpanel and make a subpackage for it

fix directory ownership and requirement
Comment 23 Bug Zapper 2010-07-30 07:24:06 EDT
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
Comment 24 Kevin Kofler 2010-08-19 05:44:47 EDT
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.)
Comment 25 Akira TAGOH 2011-12-05 06:18:01 EST
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.
Comment 26 Kevin Kofler 2011-12-05 07:28:48 EST
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.
Comment 27 Fedora End Of Life 2013-04-03 14:56:41 EDT
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
Comment 28 Rex Dieter 2014-09-30 11:28:29 EDT
This was implemented awhile back, but unfortunately, can't find specific mention of it in kdeplasma-addons changelog

Note You need to log in before you can comment on or make changes to this bug.