Bug 1563

Sounds like a bug to me.  Raising priority.

Tim

Created attachment 1351 [details]
tdelibs : fix application menu

More generally than the original bug, I've found several problems in the T-Menu in R14:
1) Unable to run kcontrol (icon exists but does nothing)
2) Some items not displayed at all (kfind)
3) The same items as (2) are not found by search menu (both classic and kickoff menu)
4) In some computers, categories icons are missing

I think there is confusion in XDG menu files, between TDE and KDE (but possibily other desktop environment too)

When look in tdelib's kded code, it looks like the 1st menu file TDE is looking for is "applications.menu".
This file generally exists under "/etc/xdg/menus" and is provided by the Linux distribution. It is supposed to be desktop-independant BUT it looks like it's not suitable for TDE (yet ?).
So TDE provides it's own "applications.menu", but is usually installed as "/opt/trinity/etc/xdg/tde-applications.menu". It looks like this file is *never* used currently because it has an incorrect name.

The attached patch changes KDED's behaviour. The menu file is renamed "tde-applications.menu" to avoid conflict with "applications.menu". It MUST be installed under /etc/xdg/menu , do NOT move it under /opt/trinity as we did before !

After installing it, you will see that:
1) kcontrol icons works again
2) missing items (kfind) are visible again.
3) search menu works agains
4) top-level categories icons are back.

Also, under each category, KDE4's applications are grouped into a "KDE" subcategory (with missing icon I'm afraid). It looks this grouping is not a bug, it was intended to be that way, but never worked (for me) until now !

I will test this patch.

I am seeing everything in Slackware and can launch apps such as kfind, kcontrol, etc. Yet I accept that perhaps some menu items do not work correctly or do not appear with certain distros as I don't remember any exhaustive testing when we updated the menus.

Francois,

When we revamped the menus long ago, we wanted an option to not show KDE4 apps in the Trinity menu. We also wanted to group all KDE4 apps because without the grouping, the menu became almost unmanageable with KDE4 clutter. Even on a large monitor some of the submenus took almost the entire screen to display. Smaller screens such as laptops and netbooks would have been a nightmare and public relations disaster.

With those goals we therefore grouped the KDE4 apps into submenus and also created applications.menu-no-kde. There is no automated way to install the no-kde menu. Administrators have to manually copy the no-kde menu over the existing applications.menu. (I use a script to make the change when I update Trinity packages.)

With the menu being renamed and moved to /etc/xdg/menus, does the applications.menu-no-kde approach still work? Do we need to rename and copy the no-kde menu to /etc/xdg/menus rather than /etc/trinity/xdg/menus?

I'm not doubting the need for the patch. I only want to ensure we test thoroughly for both of the aforementioned use cases. Those who do not want KDE4 apps in the menu should have that option and those who do want KDE4 apps in the menu want as little menu clutter as possible.

Do you mean that, since the revamp time, you have the KDE4 applications grouped in a "KDE" submenu ? Because I had never seen that, on any of the distributions I build for ...

Do you have KDE4 installed or any other Desktop installed ?

The problem looks pretty clear to me now: the "main" menu file TDE is looking for is "applications.menu".
On CentOS6 (among other), Centos provides a file /etc/xdg/menu/applications.menu .
In 3.5.13.2 I've imitated the Debian/Ubuntu packaging (maybe a mistake) and built tdelibs so that "appications.menu" from TDE is installed as "/opt/trinity/etc/xdg/menus/kde-applications.menu" (notice the kde- prefix).
As a result, TDE does NEVER use the TDE-provided file (because wrong file name) and uses the distribution-provided one.
In that situation, I see many problems in the menu (crash, app not found, missing icons ...)


There are 2 possible solution:
- Either we fix the packaging, we do NOT rename the "applications.menu" to "kde-applications.menu", and keep files under /opt/trinity to avoid conflict
- Or we rename all of our files, so that we can safely install under /etc . That's what I do in my patch.

> Do you mean that, since the revamp time, you have the KDE4 applications grouped in a "KDE" submenu?

Yes.

> Do you have KDE4 installed or any other Desktop installed?

I have KDE4 and Xfce installed. I use both only for testing and comparison purposes.

> There are 2 possible solution:

My concerns are 1) limit the menu clutter and potential confusion by grouping KDE4 apps, many of which have the same app names and descriptions as TDE apps, and 2) provide a nominal mthod for administrators to not show KDE4 apps at all. This has always "just worked" for me in Slackware but as I mentioned, no exhaustive testing was ever conducted with other distros.

I realize there was a hack long ago to add [KDE4] to KDE4 menu descriptions but the hack does not really eliminate clutter and confusion. Hence my solution long ago to group all KDE4 apps. With the grouping we could (should?) dispense with the [KDE4] tagging.

Francois, your patch seems to be working for me on Slackware.

The default tde-applications.menu still groups all KDE4 apps in separate KDE submenus. That reduces clutter and confusion with KDE4/TDE apps of the same name.

When I save tde-applications.menu as tde-applications.menu.orig and then manually copy tde-applications.menu-no-kde menu to tde-applications.menu, the KDE submenus disappear and I no longer see any KDE4 apps in the menu.

I don't use the kickoff menu but from both menus seem to work there too.

Do you have permissions to push patches? If not I'll push to git.

Question: Do you think we should delete the [KDE4] menu tagging hack? With the menu grouping isolating the KDE4 apps, the [KDE4] tag is redundant and adds clutter.

Created attachment 1429 [details]
Patch to delete [KDE4] tag from KDE4 submenu items

I created a patch to delete the [KDE4] menu tagging hack. With the menu grouping isolating the KDE4 apps, the [KDE4] tag is redundant and only adds clutter.

To anybody who wants to test this second patch, first build tdelibs with Francois's patch. Test on a system that has KDE4 installed. Verify the TDE menus have KDE submenus and notice the menu items all contain [KDE4] in the description.

Then build tdelibs again with the second patch. The [KDE4] tag should no longer be seen.

For those who are curious, as root save tde-applications.menu as tde-applications.menu.orig and then manually copy tde-applications.menu-no-kde menu to tde-applications.menu. The KDE submenus disappear.

Maybe we should add a configuration option somewhere to enable/disable the [KDE4] suffix ?

Yes, that would be an option.

For myself, now that the KDE4 items all are nicely grouped to avoid clutter and confusion, I find the addition of the [KDE4] tag redundant and contributing to clutter. I tested the patch and the KDE submenus now are more readable.

I thought about changing the Trinity submenu names from KDE to KDE4 but what happens when KDE moves to KDE5? We probably can test for the existence of kde4-config or kde?-config and that would tell us which version of KDE is running. These would be compile time tests to ensure the Trinity submenu name is correct. I like this idea better than a compile time option to toggle the [KDE4] tag.

The patch in attachment 1351 [details] pushed to git in commit 5da63fe9.

To everybody following this bug report, please vote whether we should use the patch in attachment 1429 [details] to delete the [KDE4] tag in the menus or add a compile time option to use the tag.

Darrell, the GIT commit is incomplete.
Now, there is neither "applications.menu" nor "tde-applications.menu" and it causes FTBFS.
Please re-add the renamed files.

> Please re-add the renamed files.
I should pay better attention. I've been out all day but looks like Slavek already fixed the problem in commit cf1952a4. I'm sorry.

> Maybe we should add a configuration option somewhere to enable/disable the
> [KDE4] suffix ?
Francois, I'm not a code guru and I have only a basic idea how to implement your idea. I know an "ifdef" is needed in the source code but the respective environment variable needs to be created during the configuration phase. Rather than me push my patch that deletes the [KDE4] suffix (attachment 1429 [details]), would you create a patch to support a configuration option?

I'll test the patch of course. :-)

I think the default should be to disable the [KDE4] suffix. For example, -DBUILD_KDE4_MENU_SUFFIX=NO.

I still think the [KDE4] suffix adds clutter, but I agree we let packagers decide. :-)

A patch for compilation support to enable/disable [KDE4] suffix in KDE4 menu items pushed to git in commit 365f0306.

The new cmake configuration option is -DWITH_KDE4_MENU_SUFFIX and the default is OFF.

I tested compiling with both ON/OFF and I saw no problems. Works great both ways.