On 21 April 2011 06:36, S. Christian Collins <s.chriscoll...@gmail.com> wrote: > On 04/20/2011 11:41 PM, Conscious User wrote: >> >> Without explaining what is your idea for maximized windows, the >> usefulness of the mockup is very limited. >> >> Most people would agree that making the menubar moving left and >> right is not an acceptable solution, so explaining what would >> you do in the maximized case is essential. > > Why couldn't the same solution work for maximized windows as well? The only > difference being the presence of the close, minimize and maximize buttons to > the left of the global menu when a window is maximized. Sure, this would > cause the menu to shift over to make room for the window buttons, but would > this really be so much of a distraction to people? > > -~Chris >
This doesn't really solve any of the problems with the current implementation, only the menu hiding problem. The problem is, if a window is maximized and it's controls move to the panel, and then a smaller window is focused how do you close the maximized window without focusing it? How do you avoid the ambiguity caused by both the maximized and smaller window both needing space in the panel. And more importantly, if we keep merging the maximized window the panel it looks like the window controls/menu/title of the focused window are those of the maximized window. The real issue is there is just not enough room in that panel for all the stuff we want to put in it. Any suggestions we make are just us trying to tweak a broken design. Let's start again, what was the goal for moving this stuff in the panel? a. Increasing available vertical space b. Making things easy to find and hit (e.g. the continually over-emphasized Fitt's Law) c. Remain consistent The current design succeeds at #a and fails #b and #c. The menu isn't easy to find, it's not easy to hit, and the panel is not consistent. So, let's rethink from the beginning, what elements do we have access to? 1. The application name 2. The window title 3. The window controls 4. The menu bar 5. The application icon #2 is required, #1 and #5 can be either/both/neither, #3 is required, #4 is required. In 10.10, all of those items are accessible whether or not the window is focused, this is consistent. So, any movement into a panel will result in some context switching. We have the following options: 1. Move controls, title and menu into the panel but DO NOT merge the titlebar. Everything would be consistent (always displayed based on window focus, no visual ambiguity), but what we've done is basically pointless because now we have an empty titlebar on all windows 2. Move the menu bar to the panel, and DO NOT merge the titlebar. Now we have what OSX settled on, probably a good balance. 3. Merge the window controls and title on maximize only, keep menu bars INSIDE the window. No visual ambiguity, we save vertical space on the title, and it looks pretty cool. Everything is consistent. 4. Remove the panel completely. If we are trying to increase vertical space, that would be the first thing to consider dropping. We'd need a new home for the indicators. Personally, I think #3 is the best option. But it doesn't matter anyway, none of it is gonna change, and any discussions on this list will be largely ignored, Luke. _______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp