23 Feb
2014
23 Feb
'14
10:12 a.m.
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.
--
David C. Rankin, J.D.,P.E.
23 Feb
23 Feb
5:21 p.m.
New subject: [trinity-devel] Howto best Patch kmenu at Packaging Time?
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
1 Mar
1 Mar
7:28 a.m.
New subject: [trinity-devel] Howto best Patch kmenu at Packaging Time?
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.
--
David C. Rankin, J.D.,P.E.
7:36 a.m.
New subject: [trinity-devel] Howto best Patch kmenu at Packaging Time?
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?
--
David C. Rankin, J.D.,P.E.
3949
days inactive
3955
days old
3 comments
2 participants
participants (2)
-
Darrell -
David C. Rankin