strategies for customizing the "K" menu

[Duncan]

Jerome Yuzyk posted on Wed, 02 Mar 2016 18:40:32 -0700 as excerpted:

> On Friday, February 26, 2016 11:09:46 PM Duncan wrote:
>> Jerome Yuzyk posted on Fri, 26 Feb 2016 11:51:27 -0700 as excerpted:
>> 
>> > This is a 2-part question but both are about customizing the "main"
>> > or "K" menu. I Googled variations on "custom KDE menu" but didn't
>> > come up with much. So I ask some Knerds. :-)
>> > 
>> > 
>> https://www.freedesktop.org/wiki/Specifications/
> 
> Thanks very much Duncan. Now I just have to digest all that!
> 
> Now, do I use kbuildsycoca5 to regenerate the menu after my additions?
> The man page says it: "Rebuilds the KService desktop file system
> configuration cache."
> 
> Is there another tool?

Very good question.

I believe the best answer would be to see what your distro uses when it 
updates a menu item and trigger the same, manually or by your own 
script.  Packages aren't just a tarball of files; there's an install 
script that runs too. I used to know more specific information about what 
rpm did back in the day, but that has been over a decade ago now, and 
while it's probably still similar, I imagine it's quite a bit fancier 
now... 

Anyway, use your package manager's commands to examine what the install 
script of some package including menu items does after it installs those 
menu items so they show up in the running menu, and do something similar 
yourself.


Here on gentoo, every normal kde5 package runs a function called 
kde5_pkg_postinst (from the kde5 eclass aka ebuild library, ebuilds being 
the package recipes on gentoo) after installs, and kde5_pkg_postrm after 
uninstalls, which in turn run gnome2_icon_cache_update (for the people 
who run gnome2 as well, since it's pre-xdg-standard) and xdg_pkg_post
(inst|rm) as appropriate.  I won't go into gnome2_icon_cache_update 
further, but xdg_pkg_post* are worth looking into as they're standardized.

The xdg* functions are from xdg.eclass.  As both installs and removes 
require updating the menus, etc, xdg_pkg_post_(inst|rm) both do 
effectively the same thing, calling two functions inherited from yet 
another eclass, xdg-utils.eclass:

1) xdg_desktop_database_update

This function (effectively) calls 

/usr/bin/update-desktop-database -q /usr/share/applications

See the update-desktop-database (1) manpage for more detail, but the -q 
is as might be guessed, --quiet.  You probably want to see what it spits 
out and thus don't want -q, and may even want -v|--verbose.

2) xdg_mimeinfo_database_update

This function (effectively) calls

/usr/bin/update-mime-database /usr/share/mime

Again, see the update-mime-database (1) manpage.  There's no -q|--quiet 
parameter here, but there is a -V for verbose (no long form option tho).


Of course if you're doing it only for your own user, not the entire 
system, as the package post_(un)?install routines are doing, I believe 
you'd point it at your user's location.  I suppose the spec-docs cover 
that, too.


So you'd call those to update the standard stuff, and hopefully plasma 
will see it at that point without even having to run the ksycoca (Kde 
SYstem COnfig CAche) updater.  If it doesn't, you can of course run that 
as well, but at least in theory that should only be necessary if you've 
updated kde specific stuff, not just common xdg-spec covered stuff.

(Back at the beginning of the kde4 era, the freedesktop.org specs weren't 
yet mature, and at the beginning of the kde3 era, AFAIK/IIRC they didn't 
exist at all yet, so you had to run the kde specific ksycoca updater.  
Now days, things are much more cooperatively done, with both kde and 
gnome, and a number of the other DEs as well, using the common xdg 
specs.  So the common xdg updater tools should be used and to the extent 
that you're only changing the standard menu and mime stuff, that should 
do it.  You'd still need to run the ksycoca updater if you changed 
unstandardized kde specific configuration, like I believe some of the kde 
specific *.desktop service files, say those located under /usr/share/
plasma, for instance.)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
This message is from the kde mailing list.
Account management:  https://mail.kde.org/mailman/listinfo/kde.
Archives: http://lists.kde.org/.
More info: http://www.kde.org/faq.html.