install KIM on opensuse 15.3 with plasma

Hi, on my PC I use KIM, a very useful service menu, but it seems that it is not for plasma, I found this instructions to install KIM on plasma, are they correct?
substantially this:

Download KIM for KDE 4 from You will get an archive file named more or less kim4-0.9.5.tar.gz. We use KIM 0.9.5 version because at this time there is no version for KDE 5.
Extract it in you $HOME directory
To install KIM, don’t run the shell script named That is the script for KDE 4, not for KDE 4. Instead, perform these commands manually based on the same script but for KDE 5:

sudo cp ~/kim4/src/kim_.desktop /usr/share/kservices5/ServiceMenus/
sudo cp ~/kim4/src/bin/kim_

manythanks :slight_smile:

I’m running openSUSE Tumbleweed and put

  • the kim_*.desktop
    files in /usr/share/kservices5/ServiceMenus/ - the kim_*
    shell scripts in /usr/bin/

However in the kim_* shell scripts i had to replace the usage of qdbus by qdbus-qt5 to get things working.



manythanks, I tried to download KIM (KIM5 as I understood it should be for plasma) from here:
but I don’t know what to download in all this list, there is no a .tar.gz file as in the instructions
if I click on src I also don’t know what to download

and also in :
there are no files

I installed kim a long time ago from Packman but it’s no longer available there.

Nevertheless if you got to and click the “Code”-button a pull-down-menu should open and offer you to download a .zip file (

You can extract that with ark and run the included install script.

Beware! All the installed kim_* shell scripts still use qdbus.



I just downloaded “kim5-0.9.6+git.20210711.d023d22-8.3.noarch.rpm” from that site (for openSUSE Tumbleweed).

All included kim_* scripts still try to call qdbus but Tumbleweed only offers qdbus-qt5 ???



Beware! All the installed kim_* shell scripts still use qdbus.

Must not be done because:

rpm -ql libqt5-qdbus
stephan@linux64:~> la -al /usr/lib64/qt5/bin/qdbus
lrwxrwxrwx 1 root root 22  8. Mai 02:30 /usr/lib64/qt5/bin/qdbus -> ../../../bin/qdbus-qt5

You can also use the rpm from the Repo i published above…

I have installed the rpm and its working without any change.

Thats only the one I posted above, deltafox is a branch of edogawa…

So Leap does not behave like Tumbleweed.

My system:

Operating System: openSUSE Tumbleweed 20210916
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
Kernel Version: 5.14.2-1-default (64-bit)

> which qdbus
which: no qdbus in (~/bin:~/bin:/home/b1/bin:/usr/local/bin:/usr/bin:/bin)
> which qdbus-qt5
> la -al /usr/lib64/qt5/bin/qdbus
-rwxr-xr-x 1 root root 65032 19. Aug 12:17 /usr/lib64/qt5/bin/qdbus



manythanks, it works, I installed from here:
I don’t know why but the edogawa project page:
doesnt show options for leap 15.3, so I checked in the repos page and there was.

Because it is in SLE branch, not openSUSE.

??? yes, I can see now, so it means that now opensuse and SLE has the same repositories?

Partly yes.
Leap 15.3 is using SLE 15 SP3 as basement.
Problem with soo is already solved - you can get all packages for Leap 15.3 directly there - check now.

Search tools and OBS UI were created in assumption that each distribution consists of the single project and packages in this distribution are built inside of this project. This is no more true for openSUSE Leap 15.3 - most packages in openSUSE Leap 15.3 (and likely in future versions) are directly imported from SLE and built as part of SLE. So the only repositories that are associated with these packages are SLE repositories.

The situation is not nice but also probably not easy to solve. It works when you start with distribution (or top level project) and request packages inherited from other projects. But when you start with binary package, you only know project where this binary package was built. There can be arbitrary number of other projects inheriting the same built binary.

Search page on s.o.o now has workaround, but it hard codes list of SLE repositories for Leap 15.3, so this does not really scale and every new Leap release will have the same issue with search engine. opi is not fixed at all. And own OBS tools fail as well. This is something nobody thought of when switching Leap development model to follow SLE.