1) Don't change menu structures without asking. FYI, most of the time the answer will be "no".
2) If your package is in any of the default package sets: a) You must get approval for any changes that change the menus. This includes renaming items or adding new .desktop files. In other words, almost any change to a .desktop file, save translations. b) The menu item should usually be the application's generic/descriptive name. For example, use "Web Browser" instead of "Mozilla" or "Mozilla Web Browser".
3) If your package is NOT in any of the default package sets: a) The menu name should usually be the application's given name + the generic/descriptive name. For example, use "Mozilla Web Browser" instead of "Web Browser" or "Mozilla".
3) The default packages in the package sets (in the comps file) may not include any applications that are functional duplicates. In other words, if the user clicks all the package sets in the installer (other than everything), they should not end up with two web browsers or two spreadsheets in the menus. To give a hypothetical example, lets say we shipped Gnumeric as one of the default apps in the "Office" package set. In this case OpenOffice.org Calc should not show up in the menus, even if the openoffice.org package is installed (presuming we install the rest of openoffice by default). One way to address this would be to include a separate "openoffice.org-calc" package that simply installs a .desktop file. a) Exception: Although KDE and GNOME overlap we include both in package sets. To deal with this, we mark smaller utilities and core desktop pieces that overlap (e.g. gnome-utils, kdeutils, kdebase, kdemultimedia, gnome-media, kdeadmin, etc) with "OnlyShowIn=...". That way we still don't get overlapping menu items. By default all items in these sort of packages should be marked OnlyShowIn. Ask me about specific things you think should be exceptions.
Some general guidelines:
- Include a generic version of the name, even if your app isn't install by default (e.g. "Mozilla Web Browser"). - Don't add menu entries for things for the heck of it. For example, the number of people who launch emacs from the menus is probably very small. ;-) If its mostly launched from the command line (could still be an X application, note), don't put it in the menus. - Don't add a bunch of entries for the same application unless its a really big monster application (like OpenOffice.org). For example, KBabel, a translation tool has three menu entries. It shouldn't! - Don't have a "_____ Configuration" menu entry (e.g. Chromium Configuration). Configuration should be launched from inside the app. If its not, cry, but don't add it to the menus ;-)
As soon as we have a Fedora wiki, I'll put this information up there and maintain it.
-Seth
Once upon a time, Seth Nickell snickell@redhat.com said:
- The default packages in the package sets (in the comps file) may not
include any applications that are functional duplicates. In other words, if the user clicks all the package sets in the installer (other than everything), they should not end up with two web browsers or two spreadsheets in the menus. To give a hypothetical example, lets say we shipped Gnumeric as one of the default apps in the "Office" package set. In this case OpenOffice.org Calc should not show up in the menus, even if the openoffice.org package is installed (presuming we install the rest of openoffice by default). One way to address this would be to include a separate "openoffice.org-calc" package that simply installs a .desktop file.
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
On Thu, 13 May 2004, Chris Adams wrote:
Once upon a time, Seth Nickell snickell@redhat.com said:
- The default packages in the package sets (in the comps file) may not
include any applications that are functional duplicates. In other words, if the user clicks all the package sets in the installer (other than everything), they should not end up with two web browsers or two spreadsheets in the menus. To give a hypothetical example, lets say we shipped Gnumeric as one of the default apps in the "Office" package set. In this case OpenOffice.org Calc should not show up in the menus, even if the openoffice.org package is installed (presuming we install the rest of openoffice by default). One way to address this would be to include a separate "openoffice.org-calc" package that simply installs a .desktop file.
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
There is also the issue of where one app provides functionality that another does not.
An example (but not part of Fedora core) is Xine v.s. Mplayer. I have various files that one will play and not the other. When one does not work, I try the other.
The Highlander approach ("There can only be one!") is a bad way to handle things. Not something to lose ones head over...
On Thu, May 13, 2004 at 05:04:38PM -0700, alan wrote:
up with both in the desktop menus that way.
There is also the issue of where one app provides functionality that another does not.
Same is true with OOo v Gnumeric to be honest. Gnumeric is a spreadsheet , Ooo is an office suite with at best a toy spread sheet module.
The Highlander approach ("There can only be one!") is a bad way to handle things. Not something to lose ones head over...
So is 500 things on the menu. The general user needs guidance on what to run, but I agree with you that stuff that is deliberately added should be on the menu of that user- a lot of this is "where is the ****ing menu editor" stuff though. Once you hav that then the desktop can give you the expected basic program described by purpose and the user can add things like "real spreadsheet" and "non-sucky audio player"
On Sun, 16 May 2004, Alan Cox wrote:
On Thu, May 13, 2004 at 05:04:38PM -0700, alan wrote:
up with both in the desktop menus that way.
There is also the issue of where one app provides functionality that another does not.
Same is true with OOo v Gnumeric to be honest. Gnumeric is a spreadsheet , Ooo is an office suite with at best a toy spread sheet module.
So how much work to make gnumeric into OOspread :).
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
I couldn't agree more - I admin systems for a number of people. They use various pieces of software on their own - some like gnumeric b/c it is fast, some like open office calc for other reasons. What is the merit in removing these menu options? How will you allow for difference of choices b/t users?
-sv
On Thu, 2004-05-13 at 20:11 -0400, seth vidal wrote:
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
I couldn't agree more - I admin systems for a number of people. They use various pieces of software on their own - some like gnumeric b/c it is fast, some like open office calc for other reasons. What is the merit in removing these menu options? How will you allow for difference of choices b/t users?
This is not the same issue. You can still install whatever the hell you want for your users. This is about what we treat as a default, or slightly customized default, install. From the installer you can still select individual packages, or go inside a package set and select one of the packages that is not installed by default but is a member of that set.
That said, the current "everything shows up in everybody's menu" way of doing things is lame. That problem should be addressed head on.
-Seth
This is not the same issue. You can still install whatever the hell you want for your users. This is about what we treat as a default, or slightly customized default, install. From the installer you can still select individual packages, or go inside a package set and select one of the packages that is not installed by default but is a member of that set.
ok - this part wasn't terribly clear in your policy - it would be useful to specify that a bit.
That said, the current "everything shows up in everybody's menu" way of doing things is lame. That problem should be addressed head on.
I think that is a function of getting the menu editing working, not a function of setting .desktop file policy. Moreover, when a user first logs in - they should probably see the range of options of installed software, otherwise they'll probably never find the rest of it.
-sv
On Thu, 2004-05-13 at 22:07, seth vidal wrote:
I think that is a function of getting the menu editing working, not a function of setting .desktop file policy. Moreover, when a user first logs in - they should probably see the range of options of installed software, otherwise they'll probably never find the rest of it.
And you expect users to sit down when they first log in and evaluate all the various options for software, pick one for each task? Nobody wants to do that. They want one application that just works.
Colin Walters wrote:
On Thu, 2004-05-13 at 22:07, seth vidal wrote:
I think that is a function of getting the menu editing working, not a function of setting .desktop file policy. Moreover, when a user first logs in - they should probably see the range of options of installed software, otherwise they'll probably never find the rest of it.
And you expect users to sit down when they first log in and evaluate all the various options for software, pick one for each task? Nobody wants to do that. They want one application that just works.
Not necessarily, but he (and I) expect to be able to make these kinds menu choices for ourselves, which a functional menu editor would provide.
-- Rex
On Fri, 2004-05-14 at 09:18, Rex Dieter wrote:
Colin Walters wrote:
On Thu, 2004-05-13 at 22:07, seth vidal wrote:
I think that is a function of getting the menu editing working, not a function of setting .desktop file policy. Moreover, when a user first logs in - they should probably see the range of options of installed software, otherwise they'll probably never find the rest of it.
And you expect users to sit down when they first log in and evaluate all the various options for software, pick one for each task? Nobody wants to do that. They want one application that just works.
Not necessarily, but he (and I) expect to be able to make these kinds menu choices for ourselves, which a functional menu editor would provide.
I'm not arguing against menu editing, I'm arguing for good defaults in the menu.
Not necessarily, but he (and I) expect to be able to make these kinds menu choices for ourselves, which a functional menu editor would provide.
I'm not arguing against menu editing, I'm arguing for good defaults in the menu.
Then I think I'm confused.
If you have good defaults, before you have editing support, how is a user supposed to find applications that are installed by not the menu default?
-sv
And you expect users to sit down when they first log in and evaluate all the various options for software, pick one for each task? Nobody wants to do that. They want one application that just works.
As opposed to what other option? Hunt around to edit their menus up?
If they don't know what's on the machine, then how are they supposed to determine which application is best for them?
Moreover, what if they already have a preferred application? But it's not the 'preferred one' by your standards. How are they supposed to find it?
-sv
On Fri, 2004-05-14 at 09:21, seth vidal wrote:
And you expect users to sit down when they first log in and evaluate all the various options for software, pick one for each task? Nobody wants to do that. They want one application that just works.
As opposed to what other option? Hunt around to edit their menus up?
I wouldn't expect most users to edit the menu at all. They'll just use the default.
If they don't know what's on the machine, then how are they supposed to determine which application is best for them?
Again, I don't think most users are going to want to spend time evaluating various applications.
Moreover, what if they already have a preferred application? But it's not the 'preferred one' by your standards. How are they supposed to find it?
If they have a preferred application, they're more of a power user. Probably something like the MacOS "Applications" folder would be a good solution here, as Rex suggested.
I wouldn't expect most users to edit the menu at all. They'll just use the default.
*boggle* what is the threshold to move from new user to power user - it seems it is set a bit too low.
Just b/c someone likes a different application doesn't mean they're skilled enough to find it buried 10 layers deep.
Again, I don't think most users are going to want to spend time evaluating various applications.
Ok - so I have to ask - how many user interactions have y'all had? (y'all == the people deciding this policy?)
I interact with users everday - more importantly users of desktop linux systems and they pick over the apps all day until they find one they like, then they cling to it like lichen on a cave wall.
If they have a preferred application, they're more of a power user. Probably something like the MacOS "Applications" folder would be a good solution here, as Rex suggested.
preferring an application makes someone a power user?
What is your scale for going from new user to power user? could you explain it b/c I think we're working at VERY different definitions.
-sv
On Fri, 14 May 2004, seth vidal wrote:
I wouldn't expect most users to edit the menu at all. They'll just use the default.
*boggle* what is the threshold to move from new user to power user - it seems it is set a bit too low.
In the current situation where you have to edit xml files manually to edit the menus I guess the "most users dont edit the menu" stands pretty well :-/
Again, I don't think most users are going to want to spend time evaluating various applications.
Ok - so I have to ask - how many user interactions have y'all had? (y'all == the people deciding this policy?)
I interact with users everday - more importantly users of desktop linux systems and they pick over the apps all day until they find one they like, then they cling to it like lichen on a cave wall.
Heh, nice expression :) The "most users" term bothers me here - maybe the average secretary in corporate environment isn't interested in editing menus or evaluating different applications but that's not the target crowd of FC, the last I heard.
I've absolutely nothing against having sane, good defaults in the menus but too much of "we know whats best for you" is .. too much, especially considering the target group of FC, half of which are hackers and the rest on their way there I assume :)
- Panu -
Hi,
Well, somebody needs to write an app that can edit the XML menu files easily...
Dan
On Fri, 2004-05-14 at 17:29 +0300, Panu Matilainen wrote:
On Fri, 14 May 2004, seth vidal wrote:
I wouldn't expect most users to edit the menu at all. They'll just use the default.
*boggle* what is the threshold to move from new user to power user - it seems it is set a bit too low.
In the current situation where you have to edit xml files manually to edit the menus I guess the "most users dont edit the menu" stands pretty well :-/
Again, I don't think most users are going to want to spend time evaluating various applications.
Ok - so I have to ask - how many user interactions have y'all had? (y'all == the people deciding this policy?)
I interact with users everday - more importantly users of desktop linux systems and they pick over the apps all day until they find one they like, then they cling to it like lichen on a cave wall.
Heh, nice expression :) The "most users" term bothers me here - maybe the average secretary in corporate environment isn't interested in editing menus or evaluating different applications but that's not the target crowd of FC, the last I heard.
I've absolutely nothing against having sane, good defaults in the menus but too much of "we know whats best for you" is .. too much, especially considering the target group of FC, half of which are hackers and the rest on their way there I assume :)
- Panu -
-- fedora-devel-list mailing list fedora-devel-list@redhat.com http://www.redhat.com/mailman/listinfo/fedora-devel-list
On Fri, 14 May 2004 10:47:36 -0400, Dan Williams dcbw@redhat.com wrote:
Hi,
Well, somebody needs to write an app that can edit the XML menu files easily...
Dan
-jef"vim or emacs"spaleta
On Fri, May 14, 2004 at 05:29:33PM +0300, Panu Matilainen wrote:
On Fri, 14 May 2004, seth vidal wrote:
I interact with users everday - more importantly users of desktop linux systems and they pick over the apps all day until they find one they like, then they cling to it like lichen on a cave wall.
Heh, nice expression :) The "most users" term bothers me here - maybe the average secretary in corporate environment isn't interested in editing menus or evaluating different applications but that's not the target crowd of FC, the last I heard.
Well I have never felt the need to change the menu myself, but that's because I use the shell far too much. In general I'm a bit vary of the concept of "normal user" vs. "power user", because we try to make a global picture of it and I don't think it reflects actual user behaviour. A user will learn more about an interface if there are informations about how to change the way it interract with it. To me the most common example is having shortcuts keystroke printed when you display a menu, if you don't show them, 99% of the users will not learn any of them (see how long it takes to make progresses in vi as an example). And IMHO 2 person can become more proficient in the use of a given interface even if they take different ways to adapt their behaviour. User A may add a shortcut to the application on the desktop, User B may add it to the menu if not present and User C may use the "Open recent" to always get to the same document. The common pattern between both are: - that there is some user specific information associated to the interface to customize it to the current user way to interract with it - that you need some knowledge from the interface that such customization is possible
IMHO Colin is right that most users won't modify the menu if there is no easy way to do it indicated from the interface itself (IMHO a good plug would be by within the Run Application dialog). Whether allowing the menu to be modified to fit a given user way to interract with the interface boils down to : 1/ an estimate wether this would help users 2/ how hard it would be to support this option 3/ finding a good way to plug the support in the interface
1/ seems to be unclear 2/ keeping a copy of the XML should not be hard 3/ seems not that simple.
Daniel
On Fri, 14 May 2004 10:09:39 -0400, Colin Walters walters@redhat.com wrote:
Again, I don't think most users are going to want to spend time evaluating various applications.
Don't want to...sure they dont want to. But the fact remains that default applications that are being decided apun can be considered at best a compromise. No one can say with authority that ALL defaults being chosen are the best for 90% of people out there. Too many tastes and too many apps for the 90% rule to work for all the defaults.
Most people will be fine with most defaults. Exactly 3 users in the userbase will be completely happy with ALL the default chosen apps. I full expect most people to feel that at least one chosen default application is ill fitting for their needs and will go looking for an alternative. Making it easy to find those few personalized alternative and to incorporate those personalized choices into the establish UI for calling apps is good design. Now... this does not require full menu editting and control. But there must be a way...a sensible way to promote prefered applications into the menus.
If they have a preferred application, they're more of a power user.
I don't know if I'd go that far... I would say they have been corrupted by a power user, who got them hooked on an application. I wouldn't call my wife a power user, but she likes galeon a lot. Its my fault for showing to her, and now i have to make sure its on her system or there is hell to pay.
Probably something like the MacOS "Applications" folder would be a good solution here, as Rex suggested.
UI clutter is what that is. Do we really want another way to access applications from the gui? The fact that in mac the applictions folders served a sort of packaging purpose as well, and mac had the idea of the recent applictions idea, the applictions folders was a piece of a thought out puzzle and served more than a single purpose of keeping menus uncluttered.
I dont think implementing the Applications folder in the gnome/kde ui makes a lot of sense since it would be solely used to push things out of the menu and there is no corresponding recent applictions concept to have the menu ui learn your usage habits. If you are going to push all the 'other' applictions besides the default into a folder view in the file manager, you will have to have a way for the menu to learn from that user's usage of the application folder, so the menu will populate preferred or commonly used apps based on user habits.
The real fix to this issue is getting the menus to learn user habits. Either get menu editting working so users can codify what they want directly or build in some logic so that the menu structure learns from the users habits. Power users are going to want full control of the menus, and I would assume that novice users would appreciate auto-population of the menus based on application usage.
-jef
On Fri, 2004-05-14 at 16:09, Colin Walters wrote:
On Fri, 2004-05-14 at 09:21, seth vidal wrote:
And you expect users to sit down when they first log in and evaluate all the various options for software, pick one for each task? Nobody wants to do that. They want one application that just works.
As opposed to what other option? Hunt around to edit their menus up?
I wouldn't expect most users to edit the menu at all. They'll just use the default.
This is only true for "mere users" in the sense as the car drivers who wouldn't change their tires by themselves. You are ignoring all those who use e.g. enlightenment because it's so 733T, something else only because it's different... By your reasoning nobody on Windows would use anything besides IE which is just plain wrong (thankfully).
If they don't know what's on the machine, then how are they supposed to determine which application is best for them?
Again, I don't think most users are going to want to spend time evaluating various applications.
Again, you are looking at a very limited set of users.
Moreover, what if they already have a preferred application? But it's not the 'preferred one' by your standards. How are they supposed to find it?
If they have a preferred application, they're more of a power user. Probably something like the MacOS "Applications" folder would be a good solution here, as Rex suggested.
ACK.
Nils
Moreover, what if they already have a preferred application? But it's not the 'preferred one' by your standards. How are they supposed to find it?
Maybe all that needs to be done is expand the "Preferred Applications" app where it will dynamically recognize all apps installed for a particular "user function".
For example imagine a user function such as a web browser:
When the user enters into preferred apps they see every recognizable browser that is installed on the OS. From this point there could be a radial button that allows the user to:
1) view the default app for this function 2) view all installed apps for this function or 3) view only the selected apps for this function
This covers the basic users who will normally use the default, to users want everything, to users who want just certain apps shown in the menu.
-ern
Colin Walters wrote:
And you expect users to sit down when they first log in and evaluate all the various options for software, pick one for each task? Nobody wants to do that. They want one application that just works.
This works great for new users. But what about those who have been using the system for some time? Last year your default was application Foo. This year it's application Bar, with application Foo suddenly no longer in any menus. Do you expect the users to blindly acquiesce and switch to your new default choice in the middle of trying to do actual work?
Not every user will be sitting in front of your desktop for the first time. Some of them will be upgrading.
--icon
Seth Nickell wrote:
<snip>
This is not the same issue. You can still install whatever the hell you want for your users. This is about what we treat as a default, or slightly customized default, install. From the installer you can still select individual packages, or go inside a package set and select one of the packages that is not installed by default but is a member of that set.
That said, the current "everything shows up in everybody's menu" way of doing things is lame. That problem should be addressed head on.
-Seth
Once you get past that 20th century-command line mentality, you'll be ok. ;) There are billions of people that use computers that never see the command line: If it's not on a menu it doesn't exist. If I install some software it better show up on the menu. Especially if I do an 'everything' install, I what to be able to find everything on a menu somewhere! I guess that attitude comes from having been a GUI designer/builder/programmer for several years. Richard Hally
On Thu, May 13, 2004 at 10:58:29PM -0400, Richard Hally wrote:
Once you get past that 20th century-command line mentality, you'll be ok. ;)
And Red Hat even recognizes this, to some degree (that's why the Terminal was stuffed into the System Tools submenu in the Red Hat 8.0 era, IIRC).
There are billions of people that use computers that never see the command line: If it's not on a menu it doesn't exist.
This *almost* matches my thoughts. More precisely, I think it's more like "if it's not reachable via the GUI, without having to know the program's name in advance, it doesn't exist." For instance, Mac OS X programs tend to show up in an "Applications" folder on the hard drive rather than in a menu. Perhaps there could be a folder, somewhat like this (and reachable from the "Places" menu in Nautilus) could be used to avoid overloading the menus. (I say "somewhat" because in some sense the Applications folder in OS X also takes the place of RPM, insofar as it can be used to install or remove the typical OS X program.)
Or perhaps there could be a "Show More Programs"/"Show Fewer Programs" toggle in the menu, which would explode the menu with everything that's installed or trim it back down to the Red Hat defaults. This would be sort of like the little menu expansion tab thingies in Windows ME/XP, except it would not attempt to adapt itself to the user, and perhaps would be less annoying as a result.
FWIW, under Mac OS 9 (arguably the best real-world OS from a usability standpoint) the normal setup was to put very few programs into the menus, and to leave the rest accessible via the file manager. The x most frequently used programs were also placed in a "Recent Applications" submenu (the typical value of x was something like 10 or 15). However, it was pretty easy to make a submenu with an entry for each file on your hard drive, if you wished. (BTW, the Apple Menu also existed as a folder in the file manager, and that's how the menu was edited.)
I'm starting to ramble a bit, but hopefully somebody will find this feedback useful. One last point: IMO we need some sort of functional and easy menu editing before we can deal with this problem in a sane manner. Without that, we're going to be whacking at problems with a hammer when we really need to use a screwdriver, so to speak.
-Barry K. Nathan barryn@pobox.com
On Fri, 2004-05-14 at 02:22, Barry K. Nathan wrote:
For instance, Mac OS X programs tend to show up in an "Applications" folder on the hard drive rather than in a menu. Perhaps there could be a folder, somewhat like this (and reachable from the "Places" menu in Nautilus) could be used to avoid overloading the menus.
I think that's a good idea, personally.
Sorry for my poor english.
Le ven 14/05/2004 à 08:22, Barry K. Nathan a écrit :
(snip) Or perhaps there could be a "Show More Programs"/"Show Fewer Programs" toggle in the menu,
What i want seem "simple" to me. I want a flag per Program : Extra_flag : true|false The default is set by RedHat/Fedora.
No "real" menu editing.
If Extra_flag is set to "true", the program is placed in an extra menu.
The extra menu can be like the one RH8.0 provided.
Extra menu can also be an entry at the top of the Gnome menu.
Exemple for system-config-bind and gucharmap (in French here). system-config-bind : Extra_flag = false gucharmap : Extra_flag = false - gnome menu - accessoires - Calculatrice - Table de caractères (gucharmap) - paramètres système - paramètres de serveur - service de nom de domaine (system-config-bind) - écran de connexion
Now suppose "Extra_flag = true" for system-config-bind and gucharmap : - gnome menu - accessoires - Calculatrice - paramètres système - écran de connexion - extra - accessoires - Table de caractères - paramètres système - paramètres de serveur - service de nom de domaine
Or with the layout of RH8.0 - gnome menu - accessoires - Calculatrice - extra - Table de caractères - paramètres système - paramètres de serveur - extra - service de nom de domaine - écran de connection
The extra_flag can be set by a contextual menu : - "move to extra menu" - "move to main menu"
which would explode the menu with everything that's installed or trim it back down to the Red Hat defaults. This would be sort of like the little menu expansion tab thingies in Windows ME/XP, except it would not attempt to adapt itself to the user, and perhaps would be less annoying as a result.
(snip)
Le ven 14/05/2004 à 23:18, Matias Feliciano a écrit :
The extra_flag can be set by a contextual menu :
- "move to extra menu"
- "move to main menu"
This should also be great if a user who don't know the root password can say "move the folder "system paramter" to extra". Same with the "programming" folder.
He can also do "move to extra menu" the folder "preference" after he set his preference.
On Fri, 2004-05-14 at 04:58, Richard Hally wrote:
Seth Nickell wrote:
<snip> > > This is not the same issue. You can still install whatever the hell you > want for your users. This is about what we treat as a default, or > slightly customized default, install. From the installer you can still > select individual packages, or go inside a package set and select one of > the packages that is not installed by default but is a member of that > set. > > That said, the current "everything shows up in everybody's menu" way of > doing things is lame. That problem should be addressed head on. > > -Seth >
Once you get past that 20th century-command line mentality, you'll be ok. ;) There are billions of people that use computers that never see the command line: If it's not on a menu it doesn't exist. If I install some software it better show up on the menu. Especially if I do an 'everything' install, I what to be able to find everything on a menu somewhere! I guess that attitude comes from having been a GUI designer/builder/programmer for several years.
I second that. In fact, I cannot help to think of the current approach as a band-aid, to provide a reasonably sane menu structure in the light of virtually non-existing means to edit it.
I think menu handling should ensure the following:
- Ensure a sane, uncluttered menu structure per default (current policy would do that) - Enable people to change the menu easily, whether in place or through a menu editor or via the file manager needs to be discussed. - Actually abstract the type of the application from the implementation where that makes sense. Would make sense for e.g. web browsers to have one "Web Browser" entry starting either the user's preferred or system default web browser, wouldn't make sense for e.g. games. Kind of alternatives for menu entries, but don't beat me yet ;-).
What we need IMO is basically e.g.:
- Mozilla, Galeon, Epiphany, Konqueror, ... having desktop files listing them as web browsers (probably by GenericName or whatever though something like AppType would be better in my eyes) - Something defining a system wide default for each GenericName/AppType - Menus referencing the GenericName/AppType whatever per default - Some means for users to override the system wide GenericName/AppType - Some means for users to edit their menus - Reorganizing structure (hard) - Adding/Removing/Changing entries which are either generic applications that only call the system or user set default or specific apps
Nils
On Fri, 2004-05-14 at 12:55, Nils Philippsen wrote:
- Enable people to change the menu easily, whether in place or through a
menu editor or via the file manager needs to be discussed.
I'd say just right-click the menu button, choose "Add or Remove Applications" or something.
- Actually abstract the type of the application from the implementation
where that makes sense. Would make sense for e.g. web browsers to have one "Web Browser" entry starting either the user's preferred or system default web browser, wouldn't make sense for e.g. games. Kind of alternatives for menu entries, but don't beat me yet ;-).
Would be kind of nice as an extension of the Preferred Applications concept, but it's probably not worth the effort it involves - it'd be a fair bit of engineering to make this go. And all you really gain is that if you prefer Galeon your Galeon menu item says "Web Browser" instead of "Galeon Web Browser"
I guess the bigger win would be to be able to change one place and modify our default browser, if you're an admin who wants users to have a different browser. Right now you have to modify the panel configuration (not for the faint of heart), the Preferred Applications setting, and also the MIME association, or so.
- Some means for users to edit their menus
- Reorganizing structure (hard)
- Adding/Removing/Changing entries which are either generic applications that only call the system or user set default or specific apps
A simple "Add or Remove Applications" dialog that just lists all the apps in the menu with a check box for whether to show it would be pretty easy. It'd be nice to see someone write that. The app would just add include/exclude entries to the XML file.
The GUI for structure rearrangement is a lot more work, and not all that high value for end users. Admins and geeks who want to do this (e.g. to just kill all the subfolders and have a flat list of a few items, or whatever) should be able to edit the text files (the new format is fairly rational and well-documented, at least I feel it is ;-)).
Not to discourage someone who wants to write the code for structure rearrangement, if someone wants to try. ;-)
Havoc
On Fri, 14 May 2004, Havoc Pennington wrote:
Would be kind of nice as an extension of the Preferred Applications concept, but it's probably not worth the effort it involves - it'd be a fair bit of engineering to make this go. And all you really gain is that if you prefer Galeon your Galeon menu item says "Web Browser" instead of "Galeon Web Browser"
I guess the bigger win would be to be able to change one place and modify our default browser, if you're an admin who wants users to have a different browser. Right now you have to modify the panel configuration (not for the faint of heart), the Preferred Applications setting, and also the MIME association, or so.
Having a general framework for preferred applications without kludges like htmlview which "everything" honors would pretty much make this whole discussion irrelevant. I really don't want to see 5 different email clients and 7 different browsers in the menus, regardless of what's installed. What I want is to have "Web browser", "Email", "Text editor" etc generic functionality descriptions in the menus and only change it *once* in *one* place where I can pick up my preferred browser or editor etc from everything that's installed (or maybe even available) and be done with it.
Easier said than done :(
- Panu -
On Sat, May 15, 2004 at 06:41:43PM +0300, Panu Matilainen wrote:
Having a general framework for preferred applications without kludges like htmlview which "everything" honors would pretty much make this whole discussion irrelevant. I really don't want to see 5 different email clients and 7 different browsers in the menus, regardless of what's installed. What I want is to have "Web browser", "Email", "Text editor" etc generic functionality descriptions in the menus and only change it *once* in *one* place where I can pick up my preferred browser or editor etc from everything that's installed (or maybe even available) and be done with it.
Easier said than done :(
But a good scheme. Even if something like htmlview can't realistically be arranged for everything, this still seems like a decent approach for a menu editor to take.
I couldn't agree more - I admin systems for a number of people. They use various pieces of software on their own - some like gnumeric b/c it is fast, some like open office calc for other reasons. What is the merit in removing these menu options? How will you allow for difference of choices b/t users?
I think this example shows why we need "enough entries" in the menues. It still must remain a longterm goal to only ship the useful apps we find and instead of e.g. having 3 apps with different features to have only one app with all features and working for all users. That might be a little bit simplistic and might not match OOcalc versus gnucash where both apps will be needed by users to put them both into the menues. Users dislike a lot to start apps from the commandline...
greetings,
Florian La Roche
On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
Once upon a time, Seth Nickell snickell@redhat.com said:
- The default packages in the package sets (in the comps file) may not
include any applications that are functional duplicates. In other words, if the user clicks all the package sets in the installer (other than everything), they should not end up with two web browsers or two spreadsheets in the menus. To give a hypothetical example, lets say we shipped Gnumeric as one of the default apps in the "Office" package set. In this case OpenOffice.org Calc should not show up in the menus, even if the openoffice.org package is installed (presuming we install the rest of openoffice by default). One way to address this would be to include a separate "openoffice.org-calc" package that simply installs a .desktop file.
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
You would if you install OOo and Gnumeric and OOo Calc. This isn't a restriction on installing individual packages, or even packages inside a package set, just packages that get turned on by default when you enable a package set.
-Seth
On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
Actually, I think this would be fine as long as only one of them were selected as a default in anaconda. If somebody goes to the trouble of clicking to turn on all of the optional things in every component, if the results are somewhat similar to an everything install in terms of having a little bit more clutter, that doesn't strike me as a horrible thing
Jeremy
On Thu, May 13, 2004 at 09:15:24PM -0400, Jeremy Katz wrote:
On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
Actually, I think this would be fine as long as only one of them were selected as a default in anaconda. If somebody goes to the trouble of clicking to turn on all of the optional things in every component, if the results are somewhat similar to an everything install in terms of having a little bit more clutter, that doesn't strike me as a horrible thing
This sounds like a very good idea to really come to useful menues.
greetings,
Florian La Roche
On Thursday 13 May 2004 21:15, Jeremy Katz wrote:
On Thu, 2004-05-13 at 19:06 -0500, Chris Adams wrote:
I understand trying to make things simpler, but I also have a problem with this. I will sometimes intentionally install multiple things (like OOo and Gnumeric), with the intention of checking them both out to see which one I like (or does what I want) better. I install both from the regular install menu in anaconda; with your rule above, I wouldn't end up with both in the desktop menus that way.
Actually, I think this would be fine as long as only one of them were selected as a default in anaconda. If somebody goes to the trouble of clicking to turn on all of the optional things in every component, if the results are somewhat similar to an everything install in terms of having a little bit more clutter, that doesn't strike me as a horrible thing
I agree. While evolution is nice, I prefer kmail and specifically select it for installation. However, I also run metacity and mostly other gnome applications because I prefer them. The current FC2 menus do not show kmail as an option in the menu ... I know how to fix this but others may not.
While some applications purely duplicate each other, others may provide a different style of working (kmail vs evolution) or may not work in every condition (Xine vs Mplayer cited by Alan). If this effort (described in this thread) is intended as part of the effort to provide menu editing ... great! However, it should be easily possible to add or subtract items graphically.
Seth Nickell wrote:
- If your package is in any of the default package sets:
...
b) The menu item should usually be the application's generic/descriptive name. For example, use "Web Browser" instead of "Mozilla" or "Mozilla Web Browser".
- If your package is NOT in any of the default package sets:
a) The menu name should usually be the application's given name + the generic/descriptive name. For example, use "Mozilla Web Browser" instead of "Web Browser" or "Mozilla".
Why mess with names like this at all when functional equivalents exist *now* in .desktop files using Name and GenericName, e.g. for mozilla: Name=Mozilla GenericName=Web Browser
The display of these are (user) configurable (at least in KDE) whereas hardcoding changes as you suggest certainly are not.
-- Rex
On Fri, 2004-05-14 at 07:27 -0500, Rex Dieter wrote:
Why mess with names like this at all when functional equivalents exist *now* in .desktop files using Name and GenericName, e.g. for mozilla: Name=Mozilla GenericName=Web Browser
The display of these are (user) configurable (at least in KDE) whereas hardcoding changes as you suggest certainly are not.
Because they're not using them properly, and so invent rules to work around bugs
Name should be name and GenericName should be GenericName.
And they should be used as
+----------------------+ | Name GenericName[1] | | Comment |
[1] order here should respect somehow what makes sense for other languages. maybe a field to specify invert-order is needed, like invert-order="list of locales"
But this is a discussion for freedesktop.org's mailing lists.
Rui
Rui Miguel Seabra wrote:
On Fri, 2004-05-14 at 07:27 -0500, Rex Dieter wrote:
Why mess with names like this at all when functional equivalents exist *now* in .desktop files using Name and GenericName, e.g. for mozilla: Name=Mozilla GenericName=Web Browser
The display of these are (user) configurable (at least in KDE) whereas hardcoding changes as you suggest certainly are not.
Because they're not using them properly, and so invent rules to work around bugs
Who are "they"? What bugs?
Name should be name and GenericName should be GenericName.
And they should be used as
+----------------------+ | Name GenericName[1] | | Comment |
[1] order here should respect somehow what makes sense for other languages. maybe a field to specify invert-order is needed, like invert-order="list of locales"
I don't follow what you're saying here at all, so could you please elaborate for my slow moving brain this morning (probably for lack of coffee).
-- Rex
On Thu, 2004-05-13 at 18:04, Seth Nickell wrote:
- If your package is in any of the default package sets:
a) You must get approval for any changes that change the menus. This includes renaming items or adding new .desktop files. In other words, almost any change to a .desktop file, save translations.
If I understand correctly, this scopes to F-Core packages and any package which updates a F-Core package, not the run of the mill from F-Extras. At this stage of the project (Core == Redhat dominated; Extras == Community driven) that sounds reasonable. As that changes I expect issues to arise such as: who is doing the approval? What are the criteria for adding menu entries?
b) The menu item should usually be the application's generic/descriptive name. For example, use "Web Browser" instead of "Mozilla" or "Mozilla Web Browser".
I think this is a backwards decision. I'm much more in need of seeing a program's given name in order to decide if I want to run it than it's generic purpose. Otherwise, what happens if I've selected two or three web browsers for my machine? How do I tell which one "Web Browser" maps to? If I want to map another browser to that menu item, I would have to remap the original to its given name in addition to mapping my new web browser to the "web browser" entry.
(This is different from mapping an entry to invoke the 'Preferred Web Browser' into the menu. In that scenario, _I'd_ have selected which one it was and there would already be another, specific, entry in the menus for it when I wanted to change it.)
- If your package is NOT in any of the default package sets:
a) The menu name should usually be the application's given name + the generic/descriptive name. For example, use "Mozilla Web Browser" instead of "Web Browser" or "Mozilla".
Reasonable. But I don't like the way this differs depending on default package set/non-default package set. Just use 'Mozilla Web Browser' whether it's a default or not.
- The default packages in the package sets (in the comps file) may not
include any applications that are functional duplicates. In other words, if the user clicks all the package sets in the installer (other than everything), they should not end up with two web browsers or two spreadsheets in the menus. To give a hypothetical example, lets say we shipped Gnumeric as one of the default apps in the "Office" package set. In this case OpenOffice.org Calc should not show up in the menus, even if the openoffice.org package is installed (presuming we install the rest of openoffice by default). One way to address this would be to include a separate "openoffice.org-calc" package that simply installs a .desktop file.
This solution seems to shift the clutter from the menu into the package manager: Instead of an extra entry for OOo Calc in the menu we have an extra package in the system.
As an alternative I propose giving per user menu editing the following features:
1) 'Defaults view'/'All view' preference toggle on the menus that either shows the entries redhat has decided are reasonable defaulted on or all .desktop entries.
2) User is easily able to set entries to be shown in (their private) Default view from now on.
a) Exception: Although KDE and GNOME overlap we include both in package sets. To deal with this, we mark smaller utilities and core desktop pieces that overlap (e.g. gnome-utils, kdeutils, kdebase, kdemultimedia, gnome-media, kdeadmin, etc) with "OnlyShowIn=...". That way we still don't get overlapping menu items. By default all items in these sort of packages should be marked OnlyShowIn. Ask me about specific things you think should be exceptions.
When handling the 'All view' menu preference proposed above, I think we need to disregard 'OnlyShowIn.' This allows a user to display tools for environments other than their own if they want to cherry-pick the one that is best suited to their needs.
Some general guidelines:
- Include a generic version of the name, even if your app isn't install
by default (e.g. "Mozilla Web Browser").
Reasonable
- Don't add menu entries for things for the heck of it. For example, the
number of people who launch emacs from the menus is probably very small. ;-) If its mostly launched from the command line (could still be an X application, note), don't put it in the menus.
- Don't add a bunch of entries for the same application unless its a
really big monster application (like OpenOffice.org). For example, KBabel, a translation tool has three menu entries. It shouldn't!
- Don't have a "_____ Configuration" menu entry (e.g. Chromium
Configuration). Configuration should be launched from inside the app. If its not, cry, but don't add it to the menus ;-)
These guidelines remind me of the following Elliot Lee .signature circa 1997: What`s nice about GUI is that you see what you manipulate. What`s bad about GUI is that you can only manipulate what you see.
The menu provides a GUI to help you find the program you want to run. It may not be able to do that very effectively with five hundred web browsers displayed but it _certainly_can't_ if there's no way to display the program you want at all.
Unless I misunderstand how menus are generated, a policy that disallows certain .desktop in the distribution will cause this kind of problem. Instead, the .desktops should be installed in the system but contain information on whether they should _by_default_ be displayed. That way it's possible to create GUI'd methods to add or subtract the additional programs from the menus.
-Toshio