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 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.
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.
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.
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.
On 02/23/2014 11:21 AM, Darrell wrote:
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.
Yes, that is a different topic, but one worth noting. To fix that we will just have to branch 3.5.13-2 to 3.6 and cherrypick tdehwlib, docbook and other fixes from R14. The renaming should have been limited to Help files, menu entries, about dialogs (just what the user sees) -- and only those core files that would collide with kde4 with TDE was installed in /opt and kde4 in user. The XDG/KDE3 environment took care of 99% of that to begin with.
It appears that the renaming effort was somehow attempting remove all conflicts and rename all files so that TDE and kde4 could be installed and coexist side-by-side in /usr. Not only did renaming take a majority of development time for current code, but insured that every kde3 app a user might want to use on tde must now go though a renaming process of its own.
I suspect R14 has probably had 50-80% of the development manhours dedicated to renaming, fixing problems related to renaming, or porting applications to work with the new names instead of functionality development. You alone probably have 2000+ hours on renaming. That in total is probably many thousands more, if not tens-of-thousands of hours in total that could have gone into functional improvements.
We are where we are, but it is frustrating to hit Alt+F2 and type a command only to have the run dialog disappear without effect. A good part of that renaming could have probably been avoided. The good news is -- it is done.
On 02/23/2014 11:21 AM, Darrell wrote:
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.
What I want to do is set up the menus for my users in the following manner. Take the system menu for example -- it is a mess when you have a full install. I have completely cleaned it by adding 4 logical submenus for the applications that were already under System (based on what they do - broadly):
System Configuration Monitor Terminal Applications Utilities
Leaving only apps: File Manager Krusader Konsole
This leaves a well balance System menu (in order):
http://www.3111skyline.com/dl/dt/trinity/ss/kmenu-system.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/kmenu-system-configuration.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/kmenu-system-monitor.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/kmenu-system-superuser.jpg (already there)
http://www.3111skyline.com/dl/dt/trinity/ss/kmenu-system-terminal.jpg
http://www.3111skyline.com/dl/dt/trinity/ss/kmenu-system-utilities.jpg
So if I understand what you are saying, then I will need to somehow patch or sed all of the .desktop files for all of the applications to do that at packaging time?