I run openSUSE 13.1 KDE. I came to openSUSE from Kubuntu. I remember that this issue had also occurred in Kubuntu, although not as often.
When I install an application from the repositories that has a GUI frontend, it often does not appear as an item in the kickoff menu. I can still open it by searching for it in alt+F2 or by command line, though.
I would prefer that every application I have that has a GUI frontend be listed in the kickoff menu. Is there a reason that this is not the case? How can I rectify this?
Hi
Do you have an example of an application? That generally means the package isn’t running the install macros to update the desktop files, if those applications do have desktop files or course.
If they don’t exist in the package, then you would need to create them… examples would help to clarify.
It is a mater of the packager. For some reason some don’t add the app to the menu. I don’t see this often but I have seen it . Also sometimes logging out and logging back in will show an app into the menu.
So the package code is what adds the app to the menu.
For apps that do not come in RPM format or you compile yourself you must always add the app to the menu.
That might explain it. What about installing a package through a .ymp file?
And something I install through Apper or Synaptic should appear in the menu, right?
desktop is a general term for shortcuts? It doesn’t mean ~/Desktop, does it? I don’t use my home directory at all.
It’s been a while since I installed anything, but when I did in the past, I first looked for it in the repositories (through Apper), and if it wasn’t there, then I got the .rpm from software.opensuse.org.
No desktop in the generic sense of a GUI there are many programs that are command line and thus don’t get added. Most normal packages that rtun in the GUI shold get added to the menu. BUT sometimes the guy that packaged it up missed the code or did it wrong or just thought it should not be in the menu. Or if you add a foreign package. Programs don’t get added to the desktop folder unless you manually do it.
I only use appr to update I don’t install through it generally I use Yast or zypper to install. Some don’t use appr at all. There were problems with it in the past but in 12.3 and 13.1 it seems to work ok
Hi
Well, if you install from a source file, it may contain a *.desktop file (look down in /usr/share/applications), else you would need to create one.
Again, it’s a packager (of the rpm) that needs to ensure if it exists to ensure it’s packaged, so (as a packager) I would consider this a bug with the packaging.
You can manually update the desktop file database via (as root user)
update-desktop-database /usr/share/applications/
However there may be icons and mime entries that need updating as well…
Again, if you have a specific package, then we can check on the Open Build Service at the spec file and verify what is happening.
If a desktop file (not to be confused with ~/Desktop) isn’t present, with a text editor you can create your own fairly quickly and add to ~/,local/share/applications for your user… for system wide it needs to be in /usr/share/applications.
Or just right-click on the Kickoff icon and run the menu editor included in KDE…
Btw, sometimes it’s necessary to run “kbuildsycoca4” after installing a desktop file to make it appear in the menu. (that makes KDE rebuild its cache of menu entries)
Logout/login should have the same effect though.
On 2014-07-25 05:16, gogalthorp wrote:
>
> ymp is not directly supported thus probably will not be in the menu.
> openSUSE use RPM packaging not ymp
I think you are getting a bit confused
ymp is not a package, it is the one-click install file. It contains
metadata to trigger the actual install, using finally the same RPM
package as used by YaST when you activate that repository. And it
typically adds that repo as well.
You can also use the one click installer to activate the repository that
contains the package, without installing it this time. Then you start
yast and continue, manually, with full control.
So it can not affect in this matter if you use ymp or not
IMO it’s likely relevant where the original code came from. The majority of apps that exist are not built for a specific Desktop and from what I’ve seen not all Desktops implement objects like “Kickoff menus” the same. So, you’ll find that KDE apps (officially endorsed) will create a menu entry but an app that is more generic and universally used likely won’t.
After creating a new menu item (or modifying and existing), no need for reboot or even logout/login. Only the Desktop needs to be restarted. I haven’t investigated whether there is a systemd Unit that will do this, but a command is usually available for the particular Desktop. Wolfi mentions a command which may work for KDE (I haven’t tried it) and other Desktops have similar commands (eg LXDE has lxpanelctl).
The application menu is a freedesktop.org standard and should be implemented the same by all desktop environments (that provide an application menu). An entry can specify to only show in a specific DE though.
After creating a new menu item (or modifying and existing), no need for reboot or even logout/login. Only the Desktop needs to be restarted.
The easiest (and depending on the DE the only) way to restart the Desktop is to logout/login.
In KDE you could quit the Desktop with “kquitapp plasma-desktop” and start it again with “plasma-desktop”, but this isn’t necessary for the menu refresh as “kbuildsycoca4” should do that.
I haven’t investigated whether there is a systemd Unit that will do this
No.
The Desktop is not started by a systemd unit, it is started by the display manager (the “login screen”, kdm f.e.).
The display manager is started by a sysvinit script on boot though, /etc/init.d/xdm. But restarting this (or stopping and then starting it again) is even worse than logging out/in as it forcibly kills the current desktop session.
Wolfi mentions a command which may work for KDE (I haven’t tried it)
Not quite. “kbuildsycoca4” does not restart KDE/the Desktop, it only refreshes some internal caches and signals all KDE components of the changes.
No.
According to “man update-desktop-database” this is what it does:
Build cache database of MIME types handled by desktop files
not “refresh the list of installed desktop files”…
DESCRIPTION
The update-desktop-database program is a tool to build a cache database
of the MIME types handled by desktop files.
The cache database contains the list of MIME types that can be handled
by desktop files, as well as, for each MIME type, a list of desktop
files that can handle this MIME type. This cache database ease the work
of applications that need to find an application that can open a docu-
ment of a specific MIME type: those applications will not have to parse
all the desktop files existing on the system, and can instead parse
this cache database.
