Bug 727806

*** Bug 737435 has been marked as a duplicate of this bug. ***

moving rawhide -> 16. Problem exist in Fedora 16.

*** Bug 737435 has been marked as a duplicate of this bug. ***

it is not feature, but problem.

As I wrote on IRC:

<Kevin_Kofler> Oh, the D-Bus activation fun…
<Kevin_Kofler> We have a similar bug filed for KDE apps.
<tagoh> aha
<Kevin_Kofler> They also have this kind of trouble.
<Kevin_Kofler> D-Bus activation is broken. :-Z/
<Kevin_Kofler> :-/
<Kevin_Kofler> I don't think setting Net/ThemeName is the proper fix, because it doesn't distinguish GTK+ 2 and 3.
<Kevin_Kofler> KDE upstream wants to start up D-Bus later in startkde so it picks up the environment settings.
<Kevin_Kofler> (because of the issue with Qt/KDE apps)
<Kevin_Kofler> That should also help here.
<tagoh> hm, yeah.. there are similar issues on the modules loading for 2 vs 3
<Kevin_Kofler> OTOH, that might also not be a long-term solution, if something wants to start up D-Bus before startkde.
<Kevin_Kofler> Unless we restart it in startkde, but yuck!
<Kevin_Kofler> Hmmm, indeed, it's getting fired up from xinitrc.d now. :-/
<Kevin_Kofler> I guess we'll have to kill it in startkde.
<Kevin_Kofler> startkde already starts up D-Bus.
<Kevin_Kofler> IMHO, that xinitrc.d script is very unhelpful.

Plus:

<Kevin_Kofler> What should xsettings-kde set Net/ThemeName to? It works from KDE settings, KDE settings have a Qt theme, not a GTK+ one.
<Kevin_Kofler> If you have no gtkrc, it tries setting the GTK+ theme to the same name as the Qt one, which is unlikely to work in most cases.
<Kevin_Kofler> Well, it may work for Oxygen (does oxygen-gtk announce its name as "Oxygen" or "Oxygen-GTK"?), but otherwise?
<Kevin_Kofler> Of course, we could hardcode Oxygen-GTK, but I don't think that's a great solution either.

I guess xsettings-kde could read the config file(s) kcm_gtk uses if we really want to do this, but this leaves the issue that it won't allow setting a different theme for GTK+ 2 and 3, which I think we should allow in kcm_gtk (though currently it doesn't support GTK+ 3 at all).

But I think the D-Bus environment issue needs fixing in any case. See also https://bugs.kde.org/show_bug.cgi?id=267770 for a similar issue with Qt/KDE applications.

just wonder if we have any packaging policy for xinit scripts and it does help in this case or can be improved if proposing something to do for the case condition on the xinit scripts.

posted renaming proposal to the xdg mailing list http://lists.freedesktop.org/archives/xdg/2011-October/012083.html

but no one seems interested in this discussion ;o)

For a workaround, I could stop invoking imsettings-daemon through dbus but start it as the usual process at the startup. which inspired from http://lists.fedoraproject.org/pipermail/desktop/2011-October/007441.html

I guess the xdg autostart mechanism is came after setting the above things up right?

So, as I explained, xsettings-kde is probably not the right place to fix this, changing subject and reassigning.

*** Bug 750723 has been marked as a duplicate of this bug. ***

*** Bug 753488 has been marked as a duplicate of this bug. ***

This problem resolved for me.

To fix this problem, there are two issues, one is the lack of the auto startup of the ibus-daemon at the correct time, the other is the bindings for KDE/QT for the accounts xinputrc definition.

for --xim, which is what I use, I made a .xinputrc method from the template from the xim definition for ibus in /etc/X11/xinit//xinput.d

(i.e. xim.conf)

I copied xim.conf to my shell account as dot file .xinputrc.

I then removed the following lines (commented them out.)

#XIM=ibus
#XIM_PROGRAM="/usr/bin/ibus-daemon"
#ICON="ibus"
#XIM_ARGS=" --xim"
#PREFERENCE_PROGRAM=/usr/bin/ibus-setup
#SHORT_DESC="IBus"
#QT_IM_MODULE=ibus

if test -f /usr/lib/qt4/plugins/inputmethods/libqtim-ibus.so || \
   test -f /usr/lib64/qt4/plugins/inputmethods/libqtim-ibus.so;
then
    QT_IM_MODULE=ibus
else
    QT_IM_MODULE=xim
fi

This solved the problem with a borked ibus-daemon setup at KDE load time by setting up the correct load environment, but not running the ibus-daemon just yet.

To do that, you have to create an autostart file in /etc/xdg/autostart, which I made one as follows:

[Desktop Entry]
Encoding=UTF-8
Type=Application
Version=1.0
Name=Input Method starter
Name[as]=নিবেশ পদধতি আৰমভকৰতা
Name[bn_IN]=ইনপট পদধতি আরমভের পরণালী
Name[ca]=Iniciador del mètode d'entrada
Name[da]=Inputmetode starter
Name[de]=Eingabemethoden-Starter
Name[es]=Iniciador del Método de Entrada
Name[fr]=Démarrer la méthode de saisie
Name[gu]=ઈનપટ પદધતિ શર કરનાર
Name[hi]=इनपट विधि आरभकरता
Name[it]=Caricatore di Input Method
Name[ja]=入力メソッドスターター
Name[kn]=ಇನಪುಟ ವಧಾನ ಆರಂಭಗಾರ
Name[ko]=입력 방식 시작기 
Name[ml]=ഇനപടട മെഥേഡ ആരംഭികകനനതിനളള സംവിധാനം
Name[mr]=इपट पदधत सटारटर
Name[or]=ନବେଶ ପରଣାଳୀ ଆରମଭକାରୀ
Name[pa]=ਇਪਟ ਢਗ ਸਟਾਰਟਰ
Name[pl]=Uruchamianie metody wprowadzania
Name[pt_BR]=Método de entrada iniciado
Name[ru]=Модуль запуска метода ввода
Name[ta]=உளளடு முறை துவககி
Name[te]=ఇనపుట పదదత పరరంభక
Name[uk]=Запуск системи способів введення
Name[zh_CN]=输入法引导器
Name[zh_TW]=輸入法啟動器
Comment=Input Method starter
Comment[as]=নিবেশ পদধতি আৰমভকৰতা
Comment[bn_IN]=ইনপট পদধতি আরমভের পরণালী
Comment[ca]=Iniciador del mètode d'entrada
Comment[da]=Inputmetode starter
Comment[de]=Eingabemethoden-Starter
Comment[es]=Iniciador del Método de Entrada
Comment[fr]=Démarrer la méthode de saisie
Comment[gu]=ઈનપટ પદધતિ શર કરનાર
Comment[hi]=इनपट विधि आरभकरता
Comment[it]=Caricatore di Input Method
Comment[ja]=入力メソッドスターター
Comment[kn]=ಇನಪುಟ ವಧಾನ ಆರಂಭಗಾರ
Comment[ko]=입력 방식 시작기 
Comment[ml]=ഇനപടട മെഥേഡ ആരംഭികകനനതിനളള സംവിധാനം
Comment[mr]=इपट पदधत सटारटर
Comment[or]=ନବେଶ ପରଣାଳୀ ଆରମଭକାରୀ
Comment[pa]=ਇਪਟ ਢਗ ਸਟਾਰਟਰ
Comment[pl]=Uruchamianie metody wprowadzania
Comment[pt_BR]=Método de entrada iniciado
Comment[ru]=Модуль запуска метода ввода
Comment[ta]=உளளடு முறை துவககி
Comment[te]=ఇనపుట పదదత పరరంభక
Comment[uk]=Запуск системи способів введення
Comment[zh_CN]=输入法引导器
Comment[zh_TW]=輸入法啟動器
Exec=/usr/bin/ibus-daemon --xim
Terminal=false

Put the above into a file...I named mine ibus-start.desktop and copy it into /etc/xdg/autostart.

This solves the problem of ibus-crashes at launch time and places the correct icon (mouse keyboard kde) in the systray in plasma.

Now I can write in English and Chinese, and my systray has a nice mouse icon/keyboard.

Much better than the abrt icon.

:-)

Also might I just add in closing, this seems like a simple fix, (did several of my co workers and friends machines.) so I am not sure why it was overlooked??

But the lack of KDE support in this version of Fedora is very prominent in this release (had to fix a ton of bugs myself.)  This particular problem is a simple package management/KDE build/deployment issue.

I personally use KDE in Fedora because I feel like many others do, that a desktop that treats you like an imbecile, like the GNOME community seems to want to head in that direction, is not something I want to use because the world is never as simple as a imbecile desktop like GNOME 3 would have you believe.  (Not all problems believe it or not can be solved with over sized buttons to push on....no really, it is true.)

Besides, KDE can be just as restrictive as GNOME 3 with the correct KIOSK template.

Please spend more time on KDE issues and I will keep posting bugs fixes.

-gc

You will miss some features on that way due to the limitation of XIM.

Closing as provided my own fix as noted.  Solves problem with KDE 4.7.4

This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

The underlying problem still exists, but is probably not going to be fixed ever. :-( We fixed the issue in current xsettings-kde builds by reading the setting from the gtkrc kcm_gtk writes and exporting that as a ThemeName XSetting, so I guess this can indeed stay closed.