The current editor-type menu flipping is a byproduct of Blender trying to solve a tricky problem in UI design, which is allowing header-menu-bars to live on the top or the bottom. I think Blender's flipping menus work acceptably for text-header-menus, because a particular menu type is accessed from only one direction. (aka, the user probably buts all 3dview headers on the bottom of 3dviews).
However, the window-editor-type-menu is often and repeatedly used from both orientations. This flipping ruins consistency. It not only makes it harder for new users to recognize it as the same thing (because it's upside-down), but it hurts experienced users by ruining their ability to build muscle memory for the menu. The multi-column layout is objectively a better solution to the two competing goals. Items can be kept in a consistent position, making the menu easier to recognize, learn, and use. Frequently used operations can be kept close to the start-point by keeping the menu vertically short, making those operations fast to reach from either orientation. It is simply a better solution to the problem. it is dramatically easier to remember where things are in *larger* modifier and constraint menus, because they have a non-flipping multi-column layout. ------ Which brings us back to "preferences" .... There is no question there are many possible groupings, headers, and motivations for those groupings. In fact, if the small amount of feedback I've seen so far is any indication, 50 blender users designed multi-column layouts, we would probably see 50 different solutions. I'd like to respond to this with three main points. 1) *ANY* non-flipping multi-column layout is better than the current solution as long as it keeps commonly used items close to the start-point. Objectively, -mathematically- it achieves the two optimization goals better. It works better for UI design. It works better for humans trying to find things. It's just better. 2) Because different users have different preferences about where things should be in this menu, user-preferences don't help us converge on a single layout. My model for resolving this "abundance of preferences" is to try to use a mix of utility and logical structure. @Brecht - The proposed "WTAS" grouping does have logic behind it, but I'm not at all saying it's the best. The main goal was trying to determine which views in blender could be "standalone programs in their own right" and put those into the workspaces section...Blender is useful for a heck of alot more than the 3dview, but that functionality is dizzyingly hard to find because those "top level program views" are mixed among views like "properties" and "graph editor". I'd love to hear some more detailed feedback about grouping structure and headings, either here, or on the bf-funboard thread... Here is an easier-to-view review of the better groupings I've tried so far.. http://dj1.willowmail.com/~jeske/Projects/Blender/ETS.html _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers