On 2/20/23 6:28 AM, Slávek Banko via tde-devels wrote:

For tdelibs there is a building option WITH_KDE4_MENU_SUFFIX. Is it possible that this is the thing you are looking for?

I suspect not. That build option likely only affects KDE4 and probably has not been tested with KDE 5. The old "[KDE4]" designation was (mostly) obsoleted by the patches from bug report 977. That was 11 years ago. I do not remember the exact details and do not know what has further changed since then.

When KDE software is installed there is a "KDE" submenu in each TDE top level menu. The goal is to avoid clutter when the full KDE suite of packages is installed. This is done through tde-applications.menu and $TDEDIR/share/desktop-directories/kde-*.directory files.

There does not seem to be a quick way to merge KDE apps directly into the TDE menus and avoid the "KDE" submenu.

The current menu structure with these "KDE" submenus presumes a full TDE and full KDE suite of packages installed. The "KDE" submenu then seems sane. There also is the tde-applications.menu-no-kde option to not show any KDE apps.

The presumptions start splintering when only a handful of non conflicting KDE packages are installed or a careful blend of both TDE and KDE packages are installed.

Under such an environment the "KDE" submenus create extra navigation. For example, installing Okular should have a menu entry directly in the TDE Office menu without any KDE submenu. Another example is users might prefer a KDE version of a package rather than TDE. For example, Gwenview, but with the presumptions the "KDE" submenu will appear for Gwenview.

One solution is through kmenuedit. That starts getting messy and every time a new KDE package is installed might require further menu editing.

Another solution is copy the respective KDE *.desktop file from /usr/share/applications to $HOME/.local/share/applications or /usr/local/share/applications and delete the "KDE;" designator from the Categories key. Then the KDE app appears directly in the TDE menu without a "KDE" submenu.

A third administrative menu would provide the option to merge KDE apps directly into the TDE menu:

* tde-applications.menu-no-kde (already provided) * tde-applications.menu-with-kde-submenus (default: currently tde-applications.menu) * tde-applications.menu-with-kde-no-submenus (new option)

Or, rather than a third menu option, possibly a TCC GUI check box to display KDE apps without the submenus (basically internal code ignores the "KDE;" category in the *.desktop files).

Some people might still want the separation and some might not. A third option would provide user choice.

I could not find an easy global solution, hence the post.

On 2/21/23 12:43 AM, deloptes via tde-devels wrote:

May be this is better and may be it can be done so that TDE reads KDE files and puts the entries together in some meaningful way - prefixing them or so

In my case here I do not have much of KDE installed. I have /usr/bin/qdbusviewer which is part of qtchooser, but does not have any desktop file and I also have some other Qt5 stuff, but I do not have any KDE submenu, so it is interesting to know what exactly is creating the KDE submenu - is it TDE parsing desktop file?

I am not a coder, but yes. The Categories key in the desktop files is used to determines which top level menu to place the menu item, but if "KDE;" also exists in the Categories key then the item is placed in a respective special "KDE" submenu in that top level menu.

Since no other desktop environment (DE) is treated this way in the TDE menu there must be special code for the "KDE;" Categories element.

A "Merge KDE Menus" check box (TCC Menus) or at least an underlying config option could instruct the underlying code to ignore the "KDE;" element in the Categories key, which then would treat the placement in the menus just like other DEs. With that option no third top level admin menu would be needed. Perhaps the check box could be ghosted out if there are no "KDE;" elements found in any Categories keys.