Re: [Ayatana] Design problem: Menus hidden by default in Unity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Luke Benstead wrote on 15/03/11 21:53: ... Erm, I hate to point out the obvious, but why don't we just put the menu back in the windows and abandon appmenu as a failed experiment? Keep the title and window controls in the panel for maximized windows only (at least just for Natty). I can already imagine the replies to this email, so let me save you guys the trouble: 1. Someone will bring up Fitt's Law. Yes I know what it is. No, I don't think it should be used as an overriding reason to squash, overlap, and generally complicate a UI and shove it into an edge. I especially don't see why Fitt's law is so important for menu bars, when users get on perfectly fine with buttons, sliders, window resize grips and icons, and well, everything else. That's looking at it backwards, I think. Screen edges are efficient target areas for whatever is put there. Given that, what should they be used for? Menus are used a lot, ergo, they're a good candidate to be made more efficient. 2. Someone will likely bring up the space saving of the global menu. Firstly, the global menu only saves vertical space on a maximized window, on non-maximized windows they only save on chrome. It also saves space whenever two or more windows are stacked vertically. By keeping the title in the panel for maximized windows, we are still saving 22px on Gnome 2, with the removal of the bottom panel that brings it up to 44px. It's about finding a balance of space saving vs usability and I really think we have shot past that balance point with the global menu. Space saving vs usability is a false dichotomy. Space saving reduces scrolling and memory load, which is part of efficiency, which is part of usability. So, the question again raised is why exactly are we using a global menu? Benefits: * Much faster to use. * Saves vertical space. * Menus no longer need to be cramped by, or overflow beyond, the window width (e.g. Empathy, Gimp, Inkscape). * Menus no longer surprisingly open upwards when the window is near the bottom of the screen. * Allows the desktop to have the same menus as any other folder (which, in turn, will reduce the complexity of context menus). * In future, will allow dialogs to have Edit, Help etc menus consistent with other windows. * In future, will allow visual unification of title bars and toolbars. I know I've brought it up before, but alongside the issues we are having fitting it into the panel with the title, it also brings issues with dual monitors, large resolutions and focus-follows-mouse. It doesn't fit all use cases. ... Dual monitors are not a problem (though if they're stacked vertically, the bottom one loses its speed benefit). Large screens make the menus a bit slower, but not nearly as slow as they would be inside windows. The loss of focus-follows-mouse is a real tradeoff, though. (I've specified how it could be made compatible, but no-one has been interested enough to work on it yet.) - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2B7wIACgkQ6PUxNfU6ecr/hgCfQmwbIB8XbywmWUL6zHOJRAI8 nMkAmwbgxluzK5tYZjwp0HOM9Ssl+xFR =PTeU -END PGP SIGNATURE- ___ 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] Design problem: Menus hidden by default in Unity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Scott Kitterman wrote on 16/03/11 12:42: ... A bug is a bug no matter who files it. If we're down to it's only a real bug if certain people file the bug, then that's a real problem. ... I totally agree. I don't think my bug reports should get special treatment because I work at Canonical. But I do think bug reports are more likely to be valid if they're from the person who maintains the specification for the relevant feature, no matter who they work for. - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk2B8HcACgkQ6PUxNfU6ecqdUACguwvgaUg4DFIfy0QKpWY6y3lH iv8AnjnXwZVVolknhchlF/TYmioPazJ7 =tmJG -END PGP SIGNATURE- ___ 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] Dash should be in full screen by default in desktop
+2 After OMG! Ubuntu showed how to do it in a desktop, I did it. *Peterson* *http://petercast.net* On 17 March 2011 01:44, Muhammad Nabil ottoman.k...@yahoo.com wrote: Dash in full screen looks better. Thanks. -- This message was sent from Launchpad by Muhammad Nabil (https://launchpad.net/~ghogaru) using the Contact this team link on the Ayatana Discussion team page (https://launchpad.net/~ayatana). For more information see https://help.launchpad.net/YourAccount/ContactingPeople ___ 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
Re: [Ayatana] Dash should be in full screen by default in desktop
On 03/17/2011 12:54 PM, frederik.nn...@gmail.com wrote: On Thu, Mar 17, 2011 at 05:44, Muhammad Nabil ottoman.k...@yahoo.comwrote: Dash in full screen looks better. Thanks. +1 keeping the dash small would make sense, if another object could be displayed beside it on the same level / layer, but that doesn't seem to be the case, so it should rather utilize all the space. transparancy keeps the stuff below visually accessible, that's good to keep a map of the desktop, even when you're in the dash. I don't think this would be good when the resolution is high (well above 1280x800). It would require unnecessary mouse movements. Unity should detect when the resolution is low, then make dash full-screen automatically (IIRC this happens when resolution is 1024x600 or lower). Also Unity should add a user-friendly option, either in ccsm or at a more accessible location, which makes dash full-screen automatically. The current way to set this is to use dconf-editor, and we don't expect new users to know this. Bilal Akhtar. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Bilal Akhtar - Ubuntu Developer bilalakh...@ubuntu.com IRC nick: cdbs signature.asc Description: OpenPGP digital signature ___ 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] Replace Refine Search with something like my mockup
Hello, Let me suggest a mockup to improve navigation in the dash of Unity. The current dash is as follows: http://upload.centerzone.it/images/39303949013254839336.png In this way a lot of space is wasted and you can see the names of the sections overlap (do not know if it has already been reported in Launchpad). I am using 2D Unity. This however is my mockup: http://upload.centerzone.it/images/51624969778680994772.png Unity In 2D, we reduce the vertical scrool optimizing use of space, and then remove those checkboxes. We can also remain Refine search, but the sections should be shown as in the mockup. In Unity 3D this would be an ideal solution to replace the drop-down menu (currently very bad) so much nicer and faster. The mockup should also apply to the dash files. Excuse me if I made some mistakes in speaking English. Raffaele Carillo ___ 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] Me Menu, and single user irritation.
On 17/03/11 12:51, Saleel Velankar wrote: I think on single user scenarios, the gconf key to show the name should be toggled to 0 by default. That's a good idea. Though some thought needs to be given as to whether the existence of a guest account should toggle the gconf key back to 1/2 or not. I personally think that, under such circumstances, the user account should default to gconf key 0 (i.e. use me menu's icon-only mode), and the guest account should default to gconf key 1/2 (i.e. show 'guest' in me menu). Regards, Lee. -- I foresee a universal information system (UIS), which will give everyone access at any given moment to the contents of any book that has ever been published or any magazine or any fact. The UIS will have individual miniature-computer terminals, central control points for the flood of information, and communication channels incorporating thousands of artificial communications from satellites, cables, and laser lines. Even the partial realization of the UIS will profoundly affect every person, his leisure activities, and his intellectual and artistic development. But the true historic role of the UIS will be to break down the barriers to the exchange of information among countries and people. -- Andrei Sakharov, Saturday Review/World (August 24th, 1984) signature.asc Description: OpenPGP digital signature ___ 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] Replace Refine Search with something like my mockup (LINK FIXED)
Hello, Let me suggest a mockup to improve navigation in the dash of Unity. The current dash is as follows: http://upload.centerzone.it/images/51624969778680994772.png In this way a lot of space is wasted and you can see the names of the sections overlap (do not know if it has already been reported in Launchpad). I am using 2D Unity. This however is my mockup: http://upload.centerzone.it/images/39303949013254839336.png Unity In 2D, we reduce the vertical scrool optimizing use of space, and then remove those checkboxes. We can also remain Refine search, but the sections should be shown as in the mockup. In Unity 3D this would be an ideal solution to replace the drop-down menu (currently very bad) so much nicer and faster. The mockup should also apply to the dash files. Excuse me if I made some mistakes in speaking English. Raffaele Carillo ___ 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] Group Active Applications at One Place
Running application are available at a glance with the light to the left of the icon. Grouping them together would mean that the placement of the icons would constantly change, hindering muscle memory. The problem may be that running application are still difficult to pin point even with the lights, but I don't think constantly shuffling icons is the solution. From: vibes.ubu...@gmail.com To: ayatana@lists.launchpad.net Date: Thu, 17 Mar 2011 12:57:29 + Subject: [Ayatana] Group Active Applications at One Place Hello, My name is Nitesh and this is my first mail to Ayatana Team. I recently filed a bug in Launchpad and I will repeat the same here as advised. Active applications in Unity currently don't group at one place and they are scattered at various spots in the launcher, even in the icons that are folded in accordion style. This is a real pain because we should know what applications are currently active in one glance. Since we cannot see the entire launcher at one go, specially in large monitors, it takes quite a effort to spot and open apps that are active. It get worse when apps are pinned way at the bottom as they remain folded even when they are active. Hope you get the idea. The solution would to group them at top or at a place where active apps can be quickly spotted. Screenshots: https://bugs.launchpad.net/unity/+bug/736683/+attachment/1914060/+files/Screenshot-1.png, https://bugs.launchpad.net/unity/+bug/736683/+attachment/1914061/+files/Screenshot-2.png Launchpad bug: https://bugs.launchpad.net/unity/+bug/736683 -- This message was sent from Launchpad by dart (https://launchpad.net/~dart-v85) using the Contact this team link on the Ayatana Discussion team page (https://launchpad.net/~ayatana). For more information see https://help.launchpad.net/YourAccount/ContactingPeople ___ 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
Re: [Ayatana] Dash should be in full screen by default in desktop
Unity, as of my last checking, only uses fullscreen for above 1280x800. I know this because my lapop uses 1280x720 and switched Dash to Desktop mode. I agree that it should be made available in CCSM, though. Make the option readily usable instead of hidden away. On 3/17/11, Bilal Akhtar bilalakh...@ubuntu.com wrote: On 03/17/2011 12:54 PM, frederik.nn...@gmail.com wrote: On Thu, Mar 17, 2011 at 05:44, Muhammad Nabil ottoman.k...@yahoo.comwrote: Dash in full screen looks better. Thanks. +1 keeping the dash small would make sense, if another object could be displayed beside it on the same level / layer, but that doesn't seem to be the case, so it should rather utilize all the space. transparancy keeps the stuff below visually accessible, that's good to keep a map of the desktop, even when you're in the dash. I don't think this would be good when the resolution is high (well above 1280x800). It would require unnecessary mouse movements. Unity should detect when the resolution is low, then make dash full-screen automatically (IIRC this happens when resolution is 1024x600 or lower). Also Unity should add a user-friendly option, either in ccsm or at a more accessible location, which makes dash full-screen automatically. The current way to set this is to use dconf-editor, and we don't expect new users to know this. Bilal Akhtar. ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp -- Bilal Akhtar - Ubuntu Developer bilalakh...@ubuntu.com IRC nick: cdbs ___ 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] Unity Dock Icons behavior - Apps switching
I try a last up as there has been no answer regarding this behavior of Unity Dock to switch between opened windows of same application when clicking on the icon : for me it is very more nice to have current window displayed on screen at right and other(s) left just near the mouse. Nobody has an opinion about that ? Thanks. Xavier. On 28/02/2011 22:06, Valeryan_24 wrote: I also noticed something on Minefield (nightly development version of Firefox) : When there are many windows opened and one is not maximized (ex: Download manager, or links / javascript launches un-maximized new window), when clicking on the Minefield icon on Unity dock, it ALWAYS shows at left (or top left) this un-maximized window, even if I'm on another one when switching. This happens on Minefield, not on normal Ubuntu Firefox or Thunderbird, but also for example on Tomboy. If I open many notes, maximize all except one, this one will always appear at (top) left. Would it be possible to add a configuration option to make current window going to the (top) right when clicking to switch, and other(s) on (top) left or bottom ? Hi everybody, Unity is getting very fine and I enjoy using it. Regarding one particular thing, I would like to change the default behavior if possible, sorry if this has already been discussed and decided. It's related to switch between application windows when more than 1 is opened. For the icons in left Unity dock, there are 1, 2, 3... white triangles if 1, 2, 3 windows of the same application are active (ex : many Firefox instances, or Firefox + bookmarks page, or Thunderbird + address book + mail redaction, or many Nautilus windows...) When we want to switch from one of these windows to another, we have to click on the icon in Unity dock, and it shows us with an animation a small view of all these windows. Here I'd like that the current window is shown at the right side and the other shown closest and near the Unity dock, it would make less mouse move to change window. Some examples to be clear : http://pix.toile-libre.org/upload/original/1298217934.png I am on the Firefox window on Ubuntu page, and I want to switch on the window with Google page. When I click to Minefield icon on dock, it shows me on left side the current window, and I have to go with mouse on the right to select the other window. When there is only 1 window of an app' opened, nothing happens if I click on the dock icon (no hide, no launch of another instance), logical. So, if there are many windows opened, if I click on the icon, it normally means that I want to switch between them. In this case, it would make sense that the other windows are shown the nearest from my mouse, to make me easy and quick to switch, and not have to go on the other part of the screen. With 3 windows opened : http://pix.toile-libre.org/upload/original/1298218213.png Here I was on Thunderbird main screen (with inbox mails), and again when I click on the icon, this screen is the first proposed to me in top left. As I want to switch to one of the 2 other windows, I expect Thunderbird main screen shown on the most far position, on top right, and 2 others on bottom and top left. What do you think of that ? In this case also, could another click on dock icon re-maximize current window (if finally we do not want to switch) ? Thanks in advance. Best regards, Xavier ___ 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
Re: [Ayatana] Design problem: Menus hidden by default in Unity
Ian Santopietro wrote: What about flashing the menu with the title for the first, say, five seconds that the window is open. That gives an indication as to where the menu is, reduces visual clutter, and allows the user to get a quick preview of what menu headers are available (File, Edit, etc.) without losing the supposed benefit of the global menu. Perhaps a nice quick fading animation would help keep this from being jarring. Frankly, this sounds like the kind of heat-of-the-moment workaround that brought Unity to its current state in the first place. The impression I have is the current design is a pile of workarounds: + Let's merge the titlebar and the panel when the window is maximized and show the menubar. The title is not that important. - Oops, now the menubar position differs in maximized windows because of the buttons. - Ok, then let's fix it on that position. - Oops, ugly gap for non-maximized windows. - Ok, let's put the title there. - Oops, titles can have different sizes. - Ok, let's truncate it. - Oops, this is ugly. - Ok, let's show the entire title by default and the menu on hover. - Oops, now it's inconsistent with maximized windows. - Ok, let's do the same for maximized windows. Hey, this brings the title back for maximized windows. Win! With admittedly some poetic license, this is how I picture it: a series of local optimizations losing track of global optimization. Instead of trying to fix the current situation, I prefer going back to when the menubar was fully visible and the titlebar didn't merge with the panel, and restarting to think from there. My personal suggestion would be dropping the title in the panel as mpt suggested, but keeping the idea of merging the titlebar and the panel. This means dropping the title entirely in the maximized case, yes. I don't think anyone would really care. For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. This would leave only the space of a single close button to worry about and this could be addressed by something with a fixed size that does not need to be truncated: AN ICON. Matter of fact, I WOULD suggest placing this icon even when the window is maximized and storing a menu with window management options in it, just like you already have depending on your metacity settings. Close *is* a destructive function you don't want near File, after all... But I won't seriously support this second suggestion for the moment, because I suspect that would make closefests of maxmized windows too inneficient, and this is bad for netbook users. Thoughts? ___ 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] Design problem: Menus hidden by default in Unity
On Thu, Mar 17, 2011 at 17:14, Conscious User consciousu...@aol.com wrote: My personal suggestion would be dropping the title in the panel as mpt suggested, but keeping the idea of merging the titlebar and the panel. This means dropping the title entirely in the maximized case, yes. I don't think anyone would really care. For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. This would leave only the space of a single close button to worry about and this could be addressed by something with a fixed size that does not need to be truncated: AN ICON. Awesome. Just awesome. This fixes everything, doesn't it? Matter of fact, I WOULD suggest placing this icon even when the window is maximized and storing a menu with window management options in it, just like you already have depending on your metacity settings. Close *is* a destructive function you don't want near File, after all... But I won't seriously support this second suggestion for the moment, because I suspect that would make closefests of maxmized windows too inneficient, and this is bad for netbook users. Thoughts? I do see a problem with that last one: how is a user going to figure out how to close the window? An (X) button has familiar meaning, but an application specific icon is probably not the first place a user would look. Also, now your icon menu and File menu are located next to each other and have the same item at the end: Close. -- Remco ___ 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] Dash should be in full screen by default in desktop
On Thu, 2011-03-17 at 10:42 -0400, Jonathan Meek wrote: Unity, as of my last checking, only uses fullscreen for above 1280x800. I know this because my lapop uses 1280x720 and switched Dash to Desktop mode. I agree that it should be made available in CCSM, though. Make the option readily usable instead of hidden away. Your absolutely correct, it was a mistake on my part to keep it in GSettings instead of ccsm (there was a reason for the decision, but I realised afterwards that having it in ccsm would be still possible and better). That'll be fixed for next week's release. -- Neil Jagdish Patel | Technical Lead Desktop Experience Team Canonical 27 Floor, Millbank Tower London SW1P 4QP Ubuntu - Linux for Human Beings www.canonical.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] Replace Refine Search with something like my mockup
Il giorno gio, 17/03/2011 alle 10.45 -0300, Peterson Silva ha scritto: That looks very neat =D Peterson http://petercast.net Thank you, as you may have seen I put another message on the mailing list with the correct link. Can we continue to speak there? ___ 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] Design problem: Menus hidden by default in Unity
Hello, My 2 cents also about global menu, as just a normal and daily user (both personal and professional use of Ubuntu), not a developer nor a designer. I like it very much as it is right now, because : - It allows space saving and is very nice - For me it is not a problem that window title hides the menu at first until we go with mouse on it. Apart new users - but those will also have to learn Unity, Dock, Linux... we know it and it is very common, easy after to get at the right place to see the menu. Often, there are buttons for most common actions in the soft that replace it. - there is homogeneity (I could say Unity !) between all applications, even Firefox, Thunderbird, LibreOffice and all things related to menus are in panel at top of the screen. It does not work for the moment for softs like Videolan but as it is not a native Ubuntu application, I understand it is not a top priority. On the contrary, for Videolan, it's better because most often I use it un-maximized, so I have menus near the window. That's the second point, the only thing I would change to Global Menu IMHO : Keep window title over-riding menus and see them when mouseover, but for un-maximized window, as the title is displayed in the window, put also the menus on mouseover in this place in the window, it allows less mouse move to activate them. Some apps, like Videolan, Empathy... are commonly used in small size and placed everywhere in the screen, not always at top. Keep maximized and minimized buttons please, it's perfect like that. Remember position of a window : with Tomboy for example, even if I maximize a note, at next startup, it re-launches reduced in top left corner... By the way, it will be impossible to satisfy everybody, so we'll see what it's decided, the less we can do is to explain our choices and their consistency. It's just surprising that such an important discussion is not solved and takes place 1 month before final release ! I also hope that, perhaps not for Natty but for 11.10, Ubuntu will allow us a little configuration as it was fully possible in Gnome panel - for example dash, apps and Places shortcuts, order on the windows in the screen for switch between different instances... Best regards, Xavier ___ 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] Design problem: Menus hidden by default in Unity
On Thu, 17 Mar 2011, Xavier Guillot wrote: - For me it is not a problem that window title hides the menu at first I bet there's a possible solution somewhere with blurring/transparaceny. The model used with the notification pop-ups is that they are transparent to click-events and blur/fade when moused-over, which is effectively what the window-title/menu also does on mouse-over. -Paul ___ 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] Design problem: Menus hidden by default in Unity
For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. I can see getting rid of the maximize button, as Gnome has a point there. However, I don't feel their argument for getting rid of the Minimize button applies to Unity. It works great for Gnome, but we still have somewhere to minimize windows to in Unity, thus the Minimize button has a point. And, three buttons provides a natural feel and is aesthetically pleasing. You can't get that unless you go down to one; two won't work. And, like I said, we need to keep the minimize button while it does something. On Thu, Mar 17, 2011 at 10:14, Conscious User consciousu...@aol.com wrote: Ian Santopietro wrote: What about flashing the menu with the title for the first, say, five seconds that the window is open. That gives an indication as to where the menu is, reduces visual clutter, and allows the user to get a quick preview of what menu headers are available (File, Edit, etc.) without losing the supposed benefit of the global menu. Perhaps a nice quick fading animation would help keep this from being jarring. Frankly, this sounds like the kind of heat-of-the-moment workaround that brought Unity to its current state in the first place. The impression I have is the current design is a pile of workarounds: + Let's merge the titlebar and the panel when the window is maximized and show the menubar. The title is not that important. - Oops, now the menubar position differs in maximized windows because of the buttons. - Ok, then let's fix it on that position. - Oops, ugly gap for non-maximized windows. - Ok, let's put the title there. - Oops, titles can have different sizes. - Ok, let's truncate it. - Oops, this is ugly. - Ok, let's show the entire title by default and the menu on hover. - Oops, now it's inconsistent with maximized windows. - Ok, let's do the same for maximized windows. Hey, this brings the title back for maximized windows. Win! With admittedly some poetic license, this is how I picture it: a series of local optimizations losing track of global optimization. Instead of trying to fix the current situation, I prefer going back to when the menubar was fully visible and the titlebar didn't merge with the panel, and restarting to think from there. My personal suggestion would be dropping the title in the panel as mpt suggested, but keeping the idea of merging the titlebar and the panel. This means dropping the title entirely in the maximized case, yes. I don't think anyone would really care. For fixing the gap, I'm going to suggest something controversial, but that I wanted to suggest for a long time anyway: dropping the minimize and maximize buttons, following Gnome3's direction and under their same arguments. This would leave only the space of a single close button to worry about and this could be addressed by something with a fixed size that does not need to be truncated: AN ICON. Matter of fact, I WOULD suggest placing this icon even when the window is maximized and storing a menu with window management options in it, just like you already have depending on your metacity settings. Close *is* a destructive function you don't want near File, after all... But I won't seriously support this second suggestion for the moment, because I suspect that would make closefests of maxmized windows too inneficient, and this is bad for netbook users. Thoughts? ___ 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 CEO - Prodigy Games 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=getsearch=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
Re: [Ayatana] Design problem: Menus hidden by default in Unity
I don't feel their argument for getting rid of the Minimize button applies to Unity. It works great for Gnome, but we still have somewhere to minimize windows to in Unity, thus the Minimize button has a point. Several problems here: 1) The somewhere to minimize to was only *one* of the arguments, and not even the main one. The Shell has always been designed without taking minimization into consideration, for encouraging the use of workspaces to organize clutter. The fact that the Shell didn't have such place in its final form was more of an argument to forget about bringing minimization back, for legacy purposes, than to actually removing it in the first place. 2) Gnome could've used the Shell Dash perfectly to hold minimized applications if this place argument was the only one. In fact, ever since the Unity launcher got autohide there isn't much difference between the two with respect to this purpose. 3) The somewhere to minimize windows in the Unity launcher is a single icon for multiple application windows that uses Expose for switching. Fitting minimization in this would imply a) not including minimized windows in the Expose, creating situations where either Expose gets in the way of restoring or vice-versa b) including minimized windows in the Expose, effectively either annoying people who minimize windows to temporarily remove them from the workflow or making you question what was the purpose of minimizing in the first place This could be solved by showing minimized windows in the Expose with less priority, like miniaturized or in icon form. OSX does this. However, Mark said once in this list that he wants minimized windows to appear full-fledged in the Expose, so we are dealing with (b) Unity will ship a form of minimization that is unfamiliar and with questionable usefulness. I'm not sure if this is better than not shipping at all. :) And, three buttons provides a natural feel and is aesthetically pleasing. You can't get that unless you go down to one; two won't work. This is largely irrelevant since I'm still defending killing minimization but... what? From where this remarkable certitude on such a subjective matter, that does not even require any kind of justification, came from? :) ___ 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] Design problem: Menus hidden by default in Unity
This is largely irrelevant since I'm still defending killing minimization but... what? From where this remarkable certitude on such a subjective matter, that does not even require any kind of justification, came from? :) No Problem: http://en.wikipedia.org/wiki/Composition_(visual_arts) http://en.wikipedia.org/wiki/Composition_(visual_arts)Basically, in visual composition, when there are multiple objects involved, it becomes pleasing to have one item surrounded by an even number of objects (Thus an odd number). Five, IMO, brings clutter, particularly to window buttons, and one would be fine, but two lacks balance. On Thu, Mar 17, 2011 at 16:08, Conscious User consciousu...@aol.com wrote: I don't feel their argument for getting rid of the Minimize button applies to Unity. It works great for Gnome, but we still have somewhere to minimize windows to in Unity, thus the Minimize button has a point. Several problems here: 1) The somewhere to minimize to was only *one* of the arguments, and not even the main one. The Shell has always been designed without taking minimization into consideration, for encouraging the use of workspaces to organize clutter. The fact that the Shell didn't have such place in its final form was more of an argument to forget about bringing minimization back, for legacy purposes, than to actually removing it in the first place. 2) Gnome could've used the Shell Dash perfectly to hold minimized applications if this place argument was the only one. In fact, ever since the Unity launcher got autohide there isn't much difference between the two with respect to this purpose. 3) The somewhere to minimize windows in the Unity launcher is a single icon for multiple application windows that uses Expose for switching. Fitting minimization in this would imply a) not including minimized windows in the Expose, creating situations where either Expose gets in the way of restoring or vice-versa b) including minimized windows in the Expose, effectively either annoying people who minimize windows to temporarily remove them from the workflow or making you question what was the purpose of minimizing in the first place This could be solved by showing minimized windows in the Expose with less priority, like miniaturized or in icon form. OSX does this. However, Mark said once in this list that he wants minimized windows to appear full-fledged in the Expose, so we are dealing with (b) Unity will ship a form of minimization that is unfamiliar and with questionable usefulness. I'm not sure if this is better than not shipping at all. :) And, three buttons provides a natural feel and is aesthetically pleasing. You can't get that unless you go down to one; two won't work. This is largely irrelevant since I'm still defending killing minimization but... what? From where this remarkable certitude on such a subjective matter, that does not even require any kind of justification, came from? :) ___ 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 CEO - Prodigy Games 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=getsearch=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
Re: [Ayatana] Design problem: Menus hidden by default in Unity
On this subject I'd like to reiterate and support a suggestion previously made on this list: https://lists.launchpad.net/ayatana/msg04555.html ☮♥☯ Greg K Nicholson http://gkn.me.uk ___ 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] Design problem: Menus hidden by default in Unity
No Problem: http://en.wikipedia.org/wiki/Composition_(visual_arts) Basically, in visual composition, when there are multiple objects involved, it becomes pleasing to have one item surrounded by an even number of objects (Thus an odd number). Five, IMO, brings clutter, particularly to window buttons, and one would be fine, but two lacks balance. Those are way too subjective and general to justify the degree of certitude your tone had. There are many ways to question it. But since now you added an IMO to your statement, there is no point in discussing this further. Feel free to drop me a private email if you want to, though. ___ 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] Design problem: Menus hidden by default in Unity
+1 On Thu, Mar 17, 2011 at 6:30 PM, Greg K Nicholson g...@gkn.me.uk wrote: On this subject I'd like to reiterate and support a suggestion previously made on this list: https://lists.launchpad.net/ayatana/msg04555.html ☮♥☯ Greg K Nicholson http://gkn.me.uk ___ 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
[Ayatana-commits] [Merge] lp:~karl-qdh/indicator-datetime/nopwdprompt into lp:indicator-datetime
Karl Lattimer has proposed merging lp:~karl-qdh/indicator-datetime/nopwdprompt
into lp:indicator-datetime.
Requested reviews:
Ted Gould (ted)
For more details, see:
https://code.launchpad.net/~karl-qdh/indicator-datetime/nopwdprompt/+merge/53846
Removes prompting for password if no stored credential exists.
--
https://code.launchpad.net/~karl-qdh/indicator-datetime/nopwdprompt/+merge/53846
Your team ayatana-commits is subscribed to branch lp:indicator-datetime.
=== modified file 'src/datetime-service.c'
--- src/datetime-service.c 2011-03-16 21:47:51 +
+++ src/datetime-service.c 2011-03-17 15:55:46 +
@@ -469,7 +469,6 @@
const gchar *key,
gpointer user_data)
{
- gboolean remember; // TODO: Is this useful? Should we be storing it somewhere?
ESource *source = e_cal_get_source (ecal);
gchar *auth_domain = e_source_get_duped_property (source, auth-domain);
@@ -479,16 +478,6 @@
gchar *password = e_passwords_get_password (component_name, key);
- if (password == NULL) {
- password = e_passwords_ask_password (
- _(Enter password),
- component_name, key, prompt,
- E_PASSWORDS_REMEMBER_FOREVER |
- E_PASSWORDS_SECRET |
- E_PASSWORDS_ONLINE,
- remember, NULL);
- }
-
g_free (auth_domain);
return password;
___
Mailing list: https://launchpad.net/~ayatana-commits
Post to : ayatana-commits@lists.launchpad.net
Unsubscribe : https://launchpad.net/~ayatana-commits
More help : https://help.launchpad.net/ListHelp
