On Sun February 23 2014 4:12:48 am David C. Rankin wrote:
> All,
> 
>   Given the minimization of applications in kmenu, what is the proper way to
> patch kmenu during packaging to move/add certain applications back to the menu?
> Currently there is no konqueror-filemanager in the menu except for the
> super-user apps and I will need to add that and a few others back to the menu in
> some manner. The Arch crowd is no mom & pop group and I can hear the howls:
> "Where is the file manager in the menu?"

I have a file manager in the root of my menu: Personal Files (Home).

The default panel has the same Personal Files (Home) icon.

I have Find Files/Folders in the root of my menu.

If you want to cater to the geeks, then in the Home.desktop file, rename th GenericName key from "Personal Files" to "File Manager" and delete all Name keys (Home). But guess what? Renaming "Personal Files" to "File Manager" creates a classic i18n nightmare because all of the remaining GenericName keys will still be "Personal Files."

In this one example you would be fortunate because you could copy the Name= keys in konqfilemgr.desktop and not deal with the i18n problem.

>   I think we should come up with some common approach for TDE that allows
> packagers to easily add/move apps around in the menu at package time. This would
> allow packagers to meet the needs of the users that TDE is being packaged for.
> If for mom & pop, package the basic menu, if for advanced users give them a
> full-featured menu. I do not want to give Arch the impression that TDE is a
> stripped-down version of kde.

The menu only provides the structure of categories. Where each app is found in the menu is done through the *.desktop files with the Categories key, not the menu.  Upon startup TDE reads every single *.desktop file in all known locations and creates the tdesycoca cache to improve response.

I flush/delete the tdesycoca files often on my test machine to force re-reading of all *.desktop files.

>   How best to do it? Is it best to do it at the XDG level supplying a short menu
> for merging, or is it better to just copy the .desktop files out of
> /opt/trinity/share/applnk/.hidden to /opt/trinity/share/applications/tde? That
> could be done with a few simple lines in a build script and sed can easily alter
> the categories of others.

If I remember correctly, the applnk/.hidden directory is a legacy carry-over from the days before XDG. Anything installed there was hidden from the menu.

XDG now uses two *.desktop file keys: NoDisplay and Hidden. The latter means the app is hidden completely or ignored by anything accessing the *.desktop file. As though the app did not exist. NoDisplay keeps items off the menu but otherwise visible for other purposes, such as populating the help handbook.

>   Developing a consistent way to easily customize the menu at packaging time
> seems like a simple way for packagers to better tailor TDE to their target users
> while providing a standard way to do it in TDE.
> 
>   I welcome your thoughts on that.
> 

The biggest challenge with menus is ask 10 people for an opinion and expect 11 responses. A volatile topic.

People in some projects don't believe in submenus.

For example, try using Xfce. A menu with no submenus. The menu becomes almost unbearable in a system with multiple desktop environments installed. The Xfce devs don't use unfolding menu columns. They use scroll buttons at the top and bottom of the menu. With Xfce, KDE, and TDE all installed on the same system, I find the menu almost useless. No search field and no way to distinguish between KDE and TDE apps.

I have seen menus where the menu unfolds to the point of consuming the entire desktop. Mint for example.

Long ago many of the submenus in Trinity were stripped. The menu was much the same: a cluttered mess and unbearable. I restored the use of submenus.

I believe the general principle is no more than three levels of menus and we are at the limit now.

On my office machine I limit what is installed. There I have no menu clutter problems. On my test machine where I install most of the additional Trinity apps, the menu is a challenge. There often I have to enable the search field to find items while testing.

The default Trinity menu layout is Name-Description. That too is a volatile topic. I prefer the default to be Description-Name because new users understand app descriptions (Web Browser, Mail Client) better than they know or can guess what convoluted name a developer chose for an app. And developers have a long history of naming apps with crazy names. The entire KDE/TDE app naming scheme is nonsensical with the K/T/TDE prefix everywhere. The GNOME/GNU folks are no better.

In the renaming effort in Trinity, I rather we did not convert k->t or k->tde. I rather we just drop the entire prefix silliness. Perhaps then we could install TDE in /usr like everybody else. But that is a different topic.

A big challenge with menus is most people do  not push the limits of capacity to test the far ends of the bell curve. This is what I do with my test machine. There I see everything in the menu because almost everything is installed --- unlike my nice and clean office system.

-- 

Darrell