Re: [Ayatana] Persistent menu mockup
On 04/21/2011 07:36 AM, S. Christian Collins wrote: 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? The shifting breaks muscle memory. But you could just reserve the space needed for the window buttons, leaving it empty, if a non-maximized window is focused. For the sake of completeness: Or treat the window buttons as part of the menu in all cases, always as first elements even before "File". -- Thorsten Wilms thorwil's design for free software: http://thorwil.wordpress.com/ ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Persistent menu mockup
On 21 April 2011 06:36, S. Christian Collins 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
Re: [Ayatana] Fitts Law
- "Luke Benstead" wrote: > > These questions really need answering, > > Luke. > I somewhat doubt we will get any response, it's looking more and more like the time when window controls were switched to the left, after a while "the opposition" just gave up and later on Mr. Shuttleworth declared how he was right to do the switch as no one is raising the issue any more. It looks like their modus operandi, ignore the counter arguments long enough that the proponents give up and then declare yourself the winner. And just for the sake of clarification, I don't now and didn't then, care much about whether window controls are on the left or the right, just pointing out a similar pattern. Cheers, Mitja ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] The top right thing
On Thu, Apr 21, 2011 at 02:01, Daniel Silva wrote: > I'd call it the power button. > correct, since that's what this button is called in the physical world. the button is a button, the menu behind it may carry an entirely different name, but the button is what it is ;) ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Fitts Law
On Wed, Apr 20, 2011 at 20:35, Toby Smithe wrote: > > This just seems to be, in the most part, a vacuum outlet for community > discontent, rather than a place for constructive discussion. > every public mailing list behaves like that, when under heavy load. some break, some recover afterwards.. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Let's have the launcher phagocytize the new system tray
On Wed, Apr 20, 2011 at 19:32, Peterson Silva wrote: > > Well, this inspired me. Do we really need the system tray when similar > things can be achieved through the launcher now? > what system tray are you referring to? perhaps re-read this excellent article by mpt to revive the topic a little.. http://design.canonical.com/2010/04/notification-area/ > > The same goes for, say, Transmission (when not launched, right-clicking > would only show regular menu; after it's launched, right-click would show > indicator menu), Ejecter (I'm currently using it, that's why I had the > idea), keyboard layout, messaging menu... Everything! > appindicators were a transitional solution for migrating the systray-icons with all the functionality they had to the new category-based Ayatana status indicator menu system. Giving Appindicators the prominence you suggest would be elevating them from a transitional concept to a permanent solution, which, imo, they do not deserve. > Shut down button, with all its options, could also become an icon in the > launcher (something not removable, like the rubbish bin is right now). > to be perfectly honest, i would prefer for the power button to remain a hardware thing, but as it is right now, i can live with it being duplicated in the DE's UI for the moment. > > I guess it would be better to keep the clock in the panel, though. > yeah, altogether i think the panel must be gotten rid of at some point. we don't need to forsake a whole bar of display space permanently, only to but a bgcolor behind a bunch of monochrome icons. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
[Ayatana] 'Open a New Window' Jumplist
In was thinking about the 'Open a New Window' jumplist entry for Firefox should be available in every web browser and file browser or any app that supports multiple windows. Newbies would want to try to open a new window by right clicking the Launcher icon and since it's there for Firefox, why not add more consistency and add it to all apps that support multiple windows? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] 'Open a New Window' Jumplist
Le jeudi 21 avril 2011 à 10:28 -0400, Melvin Garcia a écrit : > In was thinking about the 'Open a New Window' jumplist entry for > Firefox should be available in every web browser and file browser or > any app that supports multiple windows. Newbies would want to try to > open a new window by right clicking the Launcher icon and since it's > there for Firefox, why not add more consistency and add it to all apps > that support multiple windows? That's because there is no way (no API) to know that for sure. Hence the patching .desktop approach for it. An application can also add that with libunity (dynamic quicklists support). Didier ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
