Bug 583716

Created attachment 407641 [details]
Additional runtime detecting in ibus.conf for Kimpanel

Test for any kind of KDE session including something like 'openbox-kde'.

I also guess a enable/disable shell environment value might be useful while I'm not sure if all people always want to use Kimpanel when it's installed.

Created attachment 407720 [details]
Additional runtime detecting in ibus.conf for Kimpanel

Test for any kind of KDE session including something like 'openbox-kde'.

I propose to make things out of box. And people who use KDE and do not want to use Kimpanel, then can just remove the Kimpanel package.

More discussion in KDE SIG may be necessary, and as my personal experience, the IBus backend of Kimpanel is not yet stable enough. So this bug may be considered as FutureFeature by now.

(In reply to comment #2)
> I also guess a enable/disable shell environment value might be useful while I'm
> not sure if all people always want to use Kimpanel when it's installed.

Created attachment 407724 [details]
Enable building Kimpanel and make a subpackage for it

Test for any kind of KDE session including something like 'openbox-kde'.

Created attachment 407725 [details]
Additional runtime detecting in ibus.conf for Kimpanel

Test for any kind of KDE session including something like 'openbox-kde'.

legacy grep doesn't have -q.

Created attachment 407728 [details]
Additional runtime detecting in ibus.conf for Kimpanel

Redirect output to /dev/null instead

Looks good with me :).

which package kimpanel is included in?

BTW, I am also thinking if it is better that kimpanel installs another ibus-kde.conf. And the user could make choice with imchooser.

Refer to: https://bugzilla.redhat.com/show_bug.cgi?id=583545
This bug depends on that one.
Kimpanel is not yet included in any package by now.
(In reply to comment #10)
> which package kimpanel is included in?

I tried this in the second proposal in https://bugzilla.redhat.com/show_bug.cgi?id=583545  .
(In reply to comment #11)
> BTW, I am also thinking if it is better that kimpanel installs another
> ibus-kde.conf. And the user could make choice with imchooser.

test -f /usr/share/ibus/ui/panel.py -a "x$DESKTOP_SESSION" = "xkde"

is enough.

s/ui/ui\/kimpanel/.
panel.py is not a exec lib and also a generic name and should be installed into %{_datadir}

Because there are some kde variations like openbox-kde, so we should test sub-string and not identity.
(In reply to comment #14)
> test -f /usr/share/ibus/ui/panel.py -a "x$DESKTOP_SESSION" = "xkde"
> 
> is enough.

Indeed, panel.py should be in something like /usr/share/ibus-kimpanel/, not in /usr/libexec.

Created attachment 408091 [details]
Additional runtime detecting in ibus.conf for Kimpanel

Patch updated.

The following would be another idea to get third party IBus panels.

IBUS_SUBFILES=`(ls /etc/X11/xinit/xinput.d/ibus-*.conf 2>/dev/null; echo ok > /dev/null;)`
for FILE in $IBUS_SUBFILES ; do
  . $FILE
done

XIM_ARGS=${XIM_ARGS:-"--xim -j 60"}

Created attachment 408353 [details]
Additional runtime detecting in ibus.conf for Kimpanel

panel.py moved

(In reply to comment #19)
> IBUS_SUBFILES=`(ls /etc/X11/xinit/xinput.d/ibus-*.conf 2>/dev/null; echo ok >

I think 'ibus-*.conf' may not be a good pattern for third-party additional setting files, because this pattern has special meaning for imsettings.

(In reply to comment #21)
> I think 'ibus-*.conf' may not be a good pattern for third-party additional
> setting files, because this pattern has special meaning for imsettings.    

I don't understand what is the special meaning.
There are many updates so it looks wrong to update ibus.conf directly to describe a specific UI(kimpanel) in upstream because it means you may ask to update it in the future again.
The previous idea means to have a fix to support general ibus arguments.
The /etc/X11/xinit/xinput.d could be for XIM but not a specific IM setting so the idea is the main conf specifies the XIM name and I also think it might be a similar way with xim.conf. The directory of the sub conf is an idea but also /usr/share/ibus might be another option.

or I also think just simply will not fix. It would be no big problem to add an additional main conf for kimpanel. Users also can add $HOME/.xinputrc instead.

(Quoted from /usr/share/doc/imsettings-0.108.0/README)
> Information files for Input Method
> ======================================
> To make Input Methods available from IMSettings, every Input
> Methods that hopes so has to have the information file to
> let IMSettings know. those files is usually put under a
> directory where you can change the default value with
> --with-xinputdir. the filename has to contain .conf or
> something that you can also change the default value with
> --with-xinput-suffix to avoid listing every Input Methods
> that might not work for some languages. Input Methods
> doesn't support multiple languages such as XIM doesn't have
> to have .conf suffix or so. xim.conf can deals with such
> configuration files properly for appropriate languages
> according to current locale.

Of cause using third party additional setting file is also a solution. All I hope is to make Kimpanel useful out of box.

The idea of the pluggable ibus-*.conf scriptlets for things like kimpanel to plug into is interesting. I'd suggest putting them somewhere other than /etc/X11/xinit/xinput.d/ so they don't interfere with toplevel Xinput scriptlets though. Maybe /usr/share/ibus/ibus.conf.d/*.conf?

What's sure is that we need some solution, whether it's pluggable scriptlets or the patch to ibus.conf itself, for kimpanel to work as expected.

Or maybe /etc/ibus.conf.d/*.conf might be a better location? It depends on whether we want our users to be able to tweak those files or not.

BTW, I think the bugfix timeline will be set up after bug 583545 is fixed.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

It seems bug 583545 is not fixed yet.
I'd want the kimpanel sub package at first.

kimpanel is launched by plasma-desktop now in f27.