The problem here isn't the dark toolbar wasting space, it's just making the space taken more apparent. The issue is the new Gnome 3 settings application wasting space. The new toolbar is only a color; it does not take up any additional space.
I'm in support of the dark toolbars. I think they draw a nice distinction between the UI/interface, and the user content. As it stands, dark toolbars help the user focus on the content in the window. A dark panel helps this, but dark toolbars draw a cleaner separation between content, and the tools that act on that content. On Sun, Jul 24, 2011 at 05:40, Sony-qs <sony...@live.de> wrote: > ** > I'm new here, but that's a nice discussion! That's right, the dark Toolbar > isn't space friendly. And I began to love the space I won with natty ;-) > "nrundy" talked about a search box in the toolbar ... and yes they often > need many space, so why don't put it in the right corner under the toolbar, > if there's one! The box could be half transparent and hover onMouseOver! > look@this <http://img715.imageshack.us/img715/7816/4uieph1png.jpg> > > Another question: I even miss fixing the Unity-Panel to accept > keyCombinations for Alt+E (Edit) -> Alt-C (Configuration)! First step is > working but then you can only choose with Up and Down! Work in progress? > Greetings from Germany > > Am 22.07.2011 19:39, schrieb Carl Ansell: > > I feel that the toolbars should only be used where it makes sense. In the > earlier example, it did not make sense to have a thick toolbar for just a > search box. > > > Having them blend in with the top panel could be seen as a good thing when > the window is active. Both the toolbar and the menu would be together, and > it is worth remembering that the global-menu means that the panel is > integrated with the running application. > > > > When the application becomes inactive, the toolbar could slide upwards and > out of view, like the unity launcher slides to the left at present. After > all, if the application is inactive, the toolbar is not going to be needed > until it becomes active again, in which case the toolbar can re-appear. > > > ------------------------------ > From: nru...@hotmail.com > To: ayatana@lists.launchpad.net > Date: Fri, 22 Jul 2011 13:08:40 -0400 > Subject: Re: [Ayatana] Oneiric Dark Toolbars waste vertical space - what > was the point of Unity? > > The newly implemented Dark Toolbars to Oneiric have left me wondering if > the Developers have forgotten one of the driving principles for Unity--to > reclaim vertical space? > > Look at the following comparison between Natty as it is today and Oneiric > with Dark Toolbars. In Oneiric, not only has writing been placed underneath > the icons (taking vertical space) but there is now a huge/thick > vertical-space-wasting "Dark Toolbar" with only one item on it: the search > box. COME ON! I thought the whole point of Unity was to allow more space for > the items in the window. Does everything that uses Gnome 3.0 have to present > enormous amounts of chrome with no purpose other than to waste vertical > space? One of the things I love about Natty is how much vertical space has > been reclaimed. Now it's looking like all that is going to be gone in > Oneiric. > http://imgur.com/a/w9pBQ > > ------------------------------ > From: nru...@hotmail.com > To: ayatana@lists.launchpad.net > Date: Fri, 22 Jul 2011 11:06:08 -0400 > Subject: Re: [Ayatana] Oneiric Dark Toolbars are a BAD idea - here's why > > Dark Toolbars are a BAD idea. The Top-Panel should remain a significantly > darker color than application toolbars. > > Gnome-shell has the right idea where they made the top-panel black, > communicating that the top-panel is NOT part of a running application. > Google has started putting a black top-panel across its webpages, > communicating that the top-panel is NOT part of the search results or web > page's content. These dark top-panels provide an always-present, constant > frame of reference that grounds the user and differentiates it from the > project's focus (i.e., a web search, a web page's content, or a running > application). This grounded focus is lost when Dark Toolbars are merged to > the top-panel. > > The Top-Panel is NOT part of a running application. Yet this is exactly > what is communicated to the user when application toolbars are essentially > merged to the Top-Panel. Keeping the top-panel separate from application > toolbars is even more important now because of Unity's new space-saving > design. To move an entire window for example, a user can click on the > Titlebar. Yet dark toolbars would be the same color as the titlebar. To > restore a maximized window, the user can double-click free space on the > top-panel. Yet dark toolbars would present loads of free space the same > color as the Top-Panel. There are all kinds of problems with choosing Dark > Toolbars. > > Aesthetically it is also a failure. It shrouds regularly used > tools/buttons in darkness. The buttons and tools should be clearly visible > and accessible by the user. Not hidden in a darkened state. > > A better approach would be a gradation of darkening as one moves toward > the top-panel. For example, the top-panel would be a dark color (like > Ambiance). The Toolbar would be a middle color (like the present cream or > maybe a gray), in this way bridging the gap, adding a gradation, from the > lighted/white background where the work is done to the darker panel. The > work area is lighted because that's where the user's focus is. The toolbar > area is darker than the work area because it is an area of "peripheral" > focus for the user as he/she works. Tools/buttons are referenced and > consulted during the work process. The OS's top-panel is dark because this > is an Always-Present constant that doesn't change, and it is not actively > engaged when a user is working on a project, hence it is black/dark in > color. The Toolbars do NOT share this state. The Toolbars should not be > identified with the Top-Panel. > > An Operating System's Top-Panel is NOT the same as an Application's > Toolbar controls. They should not be treated the same visually. Yes, an > application's Global Menu and window controls appear in the top-panel when > maximized. But these are items that are established and utilized primarily > when beginning or ending a work project. A Toolbar on the other hand is > actively engaged during work. For example, when writing a paper, a user will > look up to identify the selected font name or font size, whether a specific > formatting option is engaged, and so forth. Looking at the Global Menu does > not provide visual feedback like this--hence it makes sense to put it in the > Top-Panel and have it be darkened in color like the Top-Panel. It is > readily accessible by mouse and keyboard shortcut to serve its purpose. But > visually, it has no purpose; hence, one of the driving forces to move it the > top panel and get it out of the way and prevent it from taking up space. It > does not make sense from a usability standpoint to treat an application's > toolbar (which shows the font name, font size, etc) in a darkened state. > There is already a LOT of dark in ubuntu. Adding more by making the toolbars > dark is a mark against efficient usability and more of an esoteric aesthetic > preference that has nothing to do with usability and functional design. > > > ------------------------------ > From: jorge.ortega...@gmail.com > Date: Thu, 21 Jul 2011 22:07:25 +0100 > To: ayatana@lists.launchpad.net > Subject: Re: [Ayatana] Oneiric Dark Toolbars/Menubar Issues > > I think it is an interesting solution. I suggested before something a bit > more radical: that every application when open, would create its own virtual > workspace. To do this only for maximised applications is also, I think, a > good idea. > > On 21 July 2011 19:36, Jonathan Meek <shrouded.cl...@gmail.com> wrote: > > I recently say the post on OMG!Ubuntu! about the possibility of dark > toolbars being included for Oneiric and this sparked an interesting debate > among someone I know who I asked to draft his thoughts on the issue for post > to the Ayatana list for discussion. Here it is: > > > PROBLEM: > The management of maximised windows in Unity is principally flawed and > could potentially cause confusion. > This problem arises due to the location of the toolbars of maximised > windows, and the global menu in the Unity panel. > Consider the screenshot at http://cdn.om. Both the toolbar and the menu > would be together, and it is worth remembering that the global-menu means > that the panel is integrated with the running > application.gubuntu.co.uk/wp-content/uploads/2011/07/2011-07-19-150134_1366x768_scrot-1.png<http://cdn.omgubuntu.co.uk/wp-content/uploads/2011/07/2011-07-19-150134_1366x768_scrot-1.png>. > In the screenshot, you can see that because of the dark theming of the > toolbar of the image preview window, it appears to be a part of the panel > and the global menu. > The screenshot demonstrates a situation in which this is undesirable. It > may appear to the user that the toolbar for the image preview application is > a part of the global menu for the settings application. A similar problem > may arise in the event that a user has, for instance, two documents open in > a word processor, and one maximised behind another unmaximised window. In > this case, it may appear that the toolbar of the window behind operates on > the window in front. This could cause confusion and annoyance. > SOLUTIONS: > There are a number of potential solutions, including theming inactive > windows differently and displaying the title bar of full screen windows. > In my opinion, the best solution I have observed is the solution in use on > Mac OS X Lion. Lion creates a dynamic workspace for each maximised window, > in effect treating maximised (or full-screen) applications as additional > workspaces. This means that it is impossible to end up with a situation > where an unmaximised window is in front of a maximised window. > > From Jonathan Rothwell <jonat...@notroswell.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 > > > > _______________________________________________ Mailing list: > https://launchpad.net/~ayatana Post to : > ayatana@lists.launchpad.netUnsubscribe : > https://launchpad.net/~ayatana More help : > https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: > https://launchpad.net/~ayatana Post to : > ayatana@lists.launchpad.netUnsubscribe : > https://launchpad.net/~ayatana More help : > https://help.launchpad.net/ListHelp > > _______________________________________________ Mailing list: > https://launchpad.net/~ayatana Post to : > ayatana@lists.launchpad.netUnsubscribe : > https://launchpad.net/~ayatana More help : > https://help.launchpad.net/ListHelp > > > _______________________________________________ > Mailing list: https://launchpad.net/~ayatana > Post to : ayatana@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ayatana > More help : https://help.launchpad.net/ListHelp > > > > _______________________________________________ > Mailing list: https://launchpad.net/~ayatana > Post to : ayatana@lists.launchpad.net > Unsubscribe : https://launchpad.net/~ayatana > More help : https://help.launchpad.net/ListHelp > > -- Ian Santopietro *Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html* "Eala Earendel enlga beorohtast Ofer middangeard monnum sended" Pa gur yv y porthaur? Public GPG key (RSA): http://keyserver.ubuntu.com:11371/pks/lookup?op=get&search=0x412F52DB1BBF1234
_______________________________________________ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
