|
Bugzilla – Full Text Bug Listing |
| Summary: | (patch) collapse bloated menus ... | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Michael Meeks <mmeeks> |
| Component: | GNOME | Assignee: | E-mail List <gnome-bugs> |
| Status: | RESOLVED INVALID | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Critical | ||
| Priority: | P5 - None | CC: | aj, federico |
| Version: | Beta 3 | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
picture
another picture |
||
Created attachment 47852 [details]
picture
Shows the improvement - instead of a menu full of sub-menus with just 1 item -
we merge all those into the parent menu (the threshold is tweakable but 1 works
well ;-). The old behavior is on the left, the new on the right => far more
useable IMHO.
Created attachment 47853 [details]
another picture
Same for multimedia - unfortunately not really highlighting the effect - since
I have a 3-item menu selected but ... ;-)
I'm all for that patch (wow, I didn't even know libmenu existed). There's two problems: the penchant for categorizing and subcategorizing things ad nauseam, and having N possibilities for accomplishing simple tasks. Why do I even have a submenu for "Volume Control"? Patch submitted. Hi Guys! I'd like to start out by congratulating Michael for taking it upon himself to provide a solution to an unfortunate usability problem. I think that his solution has a few kinks that we ought to work out before we use this patch. 1. Can we see a screenshot of how the *default* menus look with your patch, Michael? Mark Gordon showed me your patch on his laptop to shocking effect -- some crazy x app without an icon had been elevated to a top level position. 2. Since XD2, we have been working to ensure that all items in our menus have sensible names which describe their functionality. Indeed, many GNOME apps now have .desktop files which ensure that when they show up in the menus, they are given sensible, descriptive names. Our menus have won us accolades time and again, and we have been privileged to have lots of time to run usability tests etc on them. The thing is, not all of the apps that we are currently shipping have sensible .desktop files. Some of them lack human friendly names, some of them lack icons, some of them are miscategorised. Because your patch elevates apps to top level (or higher level) positions in the menus, some of the helpful context that having well named submenus provided is no longer. This means that poor .desktop files are significantly more serious than they previously were; they now potentially provide the total information about a given menu item. I believe that before we can use your patch, we should do two things. First, we should perform an audit of the .desktop files that correspond to apps which we ship by default. We should ensure that everything we ship is well labeled and described, and that it has a good icon. Second, we should verify with a bit of usability testing that people are generally ok with the way that their menus change when they add or remove applications. This is a serious change you've added. It means that the menus are going to be more difficult to document, and that people will not be able to simply remember an item's position in a menu in order to access it. Maybe this is fine. Maybe it isn't. We should do a little research and make sure that it's ok! Finally -- Michael -- I really do think that you did a nice job with this patch. I write not because I want to kill your patch, but because I want to be sure that we treat the problem seriously enough (by auditing the .desktop files and working the kinks out of the menu item behaviour) that your patch, our menus, are as succesful as they can possibly be. regards, Anna 1. A before and after screenshot is already attached. 2. The menus being run by default are not the ximian-menus, they are the default menus. This patch is irrelevant to good .desktop information and it is far too late to change any .desktop file information for SL 10.0. I also asked both garret and rodney last week about the menus and neither had an objection. The two options for 10.0 are to remove the patch or keep it. AJ, ok to pull the patch? Post 10.0 there will be other menu changes rendering this invalid. Well - I guess the problem is, that I'm using only a Gnome-only install. I guess these other random .desktop files come from a full install or something. It's a shame to leave the menus as broken as they are for Gnome - IMHO it makes the Gnome both ugly and rather harder to use removing it. Once again - it seems we've pre-emptively given up on the idea of having a good-looking & usable set of Gnome menus in SL; the rational behind that decision is not clear to me. Of course - one variant - if these (broken anyway) mis-characterized packages are causing grief, is to ensure that only sub-menus have this merge-single-item-sub-menus property set on them instead of the top-level. The patch is ok. This is what we do in KDE for some time already and showed you folks but you didn't want it at that time ;-) Michael, I don't know what .desktop file issues you have and would have expected some bugreports much earlier already on these from the GNOME users. We made some changes already in desktop files and the selections so that a GNOME system (and a KDE system) looks sane. Anna has some more details about the problems AJ, Nat also asked Kelli and I to remove it so I submitted gnome-menus with the patch reverted. |
So - this really annoyed my wife - this patch 'fixes' it - screenshots show the effect - not tested heavily - but works nicely for me :-) Index: libmenu/gmenu-tree.c =================================================================== RCS file: /cvs/gnome/gnome-menus/libmenu/gmenu-tree.c,v retrieving revision 1.37 diff -u -p -u -r1.37 gmenu-tree.c --- libmenu/gmenu-tree.c 25 Jul 2005 10:53:55 -0000 1.37 +++ libmenu/gmenu-tree.c 27 Aug 2005 10:51:40 -0000 @@ -1169,8 +1170,8 @@ gmenu_tree_directory_new (GMenuTreeDirec { retval->default_layout_values.mask = MENU_LAYOUT_VALUES_NONE; retval->default_layout_values.show_empty = FALSE; - retval->default_layout_values.inline_menus = FALSE; - retval->default_layout_values.inline_limit = 4; + retval->default_layout_values.inline_menus = TRUE; + retval->default_layout_values.inline_limit = 1; retval->default_layout_values.inline_header = FALSE; retval->default_layout_values.inline_alias = FALSE; }