Re: [Ayatana] Awesome critical review of Unity
Another solution: * The menu and title in the panel always refer to the topmost maximised window. * For non-maximised windows, the menu lives in the window's title bar. * If there is no maximised window, the panel shows whatever it would for a clear desktop. This maintains a logical connection between a window and its title and menus. It avoids showing one window's title in two places. The downside is that menus for non-maximised windows are no longer at the screen edge, so take longer to acquire and click. This is *not* a regression versus Ubuntu 10.10's Gnome 2 desktop. -- ☮♥☯ 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] Awesome critical review of Unity
However, Greg, is the downside you are describing for the current layout with menu bar indiscriminately in title bar or the layout you're describing? The disadvantage I described was for the layout I described. Having the menu always in the panel makes it quicker to acquire and click, which is good, but it appears connected to the wrong window. In my view, having the menu appear to be connected to the right window is more important than speed. Put another way, the problem with the current layout is this: even though the menu is in a consistent place all the time, it doesn't *feel* consistent, and that's confusing. -- ☮♥☯ 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] Awesome critical review of Unity
In any case, I am in agreement with your solutions, and the only think I want to add is to change the complete hidden nature of the current menu bars. Users new to Unity would be totally clueless as to where the menu bar is, regardless of it's position on the panel or title bar. If the menus are slightly faded out and fades in on mouse over would look good on top of being functional. Once again, I'll take the opportunity to reiterate this solution to that problem: 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] window and workspace management in unity
This is already implemented in Compiz's Scale Addons plugin. Another, complementary approach would be to have a lower limit for the zoom factor when scaling—say, around 2/3—and clip windows if necessary to only show the top-left corner (top-right in RTL locales). ___ 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] Menu bar integrated in title bar in Unity
Why not integrate (and hide) the menu bar in the title bar instead for ummaximized windows? This makes sense logically. For maximised windows, the panel takes over the function of a title bar. So it seems sensible that if the active window is unmaximised, the title bar should behave in the same way as the panel. This means that normally the window title is displayed, and the menu only appears on hover. Dragging the window is achieved by dragging a blank space on the title bar. (This is already how it's done for a maximised window.) When the active window isn't maximised, the section of the panel its window controls and menu usually occupy should either be kept blank or show controls for the topmost maximised window. This central part of the panel could even become completely transparent if there are no maximised windows at all, leaving only the indicator menus and the launcher and an otherwise-clear desktop. Any attempt to drag a window into the transparent area would maximise it. (This is already implemented by Compiz Grid) The massive downside to all of this is Fitts's law: the effective target area of a menu bar is vastly reduced when it isn't at the screen's edge. For that reason alone, and despite its logical and aesthetic elegance, I think we have to reject this idea. ___ 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] On Vincent Moulin's idea of partial global menu in unity
Gnome Shell currently uses the grave as shorthand for whichever key appears above Tab on your keyboard layout. So presumably this would be localised for each keyboard layout. On 29 Oct 2010 12:39, Barry Warsaw ba...@canonical.com wrote: On Oct 29, 2010, at 10:37 AM, Philipp Wendler wrote: Using ` is a horrible idea in my opionion, be... It would be interesting to know what Apple does on non-US keyboards. -Barry ___ 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] What do app authors do for Account Dialogs?
I don't think it's useful to enforce one account per service. It has to be a common use case to have, for example, a personal Twitter account and a business one. This should even make the UI design simpler: rather than having a fixed, finite, unscalable list of empty accounts - one per service - already there waiting to be populated; just start with an empty list and allow the user to add as many accounts as she likes, choosing the service provider for each independently. On 11 Oct 2010 09:46, Allan Day allanp...@gmail.com wrote: The mockup seems to imply that one may only have one account of a particular type, eg. only one... That's right. Is this limitation going to be present in the implementation, or have I misinterpreted the mock... That was Hylke's (who drew the mockup) intention, as far as I'm aware. There are undoubtedly cases where one person has more than one set of account details for the same service, or where several people use the same local user account. Whether it is a good idea for the control center to cater to those use cases is another question, however. This has been discussed a little on the #gnome-design channel, though I can't remember the specifics... Best, Allan -- Blog: http://afaikblog.wordpress.com/ IRC: aday on irc.gnome.org __... ___ 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 and notifications
I like this idea, fwiw. Another point: currently, if when the bubble appears the pointer is already in its vicinity, i.e. the area where fading would occur, the bubble won't fade at all until the user moves away and back. This is in the spec, but seems contrary to the whole point of bubbles fading on hover. I suggest that instead, all asynchronous notifications should be queued until the pointer moves away (similar to a suggestion above). As an exception, high priority (urgent) notices could be shown anyway after x (~30) seconds even if the pointer's still there. As a bonus (though not a goal), this design would enable users who really care to deliberately queue notices while they're away. -- Greg K Nicholson On 17 Sep 2010 09:12, Diego Moya turi...@gmail.com wrote: On 17 September 2010 09:03, Conscious User wrote: To be more clear, I think this goal is *alread... Maybe the heuristic can be refined to not block notifications while typing unless in that case. But then you get the second problem also while writing... b) The user wants to just read something covered by the bubble. This is more difficult for you... I actually support having a quick way to close a notification. I don't think it's the traditional 'X' icon, though, but something more radical: hide the notification if the mouse hovers it, and *don't show it again even if the mouse moves away*. The notification should act as a real bubble, disappearing on touch. As I said, the user moving the mouse over the notifiacion region means that the content was more important at that moment than the notice, so there's no problem in closing it. The information in it should be already in the panels anyway; the user has already taken notice that there existed a bubble, and can go to the appropriate menu to read it. Combined with my heuristic, there's no problem that an involuntary mouse movement would close the bubble before the user notices it. ___ 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] How Mozilla does community-driven open source design
Mozilla's approach to community-driven design is exactly the same as Ubuntu's: solicit ideas and implementations from all and sundry, then take an opinionated decision on which to include by default. Where Mozilla succeed better is that: 1. They solicit ideas more actively using their brand—Extend Firefox and Mozilla Labs, for example. Ubuntu often still feels like a collection of disparate stuff; while Ayatana feels too top-down. 2. They have better communication about why they're making the design decisions they are. Usually they: a) show the various options, to get the community used to the idea that something will be changing b) the community discuss various merits or otherwise c) Mozilla then demonstrate why the chosen idea's the best (with eye-candy for added effect) See the current tabs-on-top discussion: http://ur1.ca/0eq4i Mozilla learnt this early on from several “ZOMG NOES!” decisions pre–Firefox 1.0 where LITERALLY-EVERYONE (i.e. a vocal minority who eventually got over it) was up in arms. It's telling that I can't actually remember what those decisions were. Ubuntu has just had this with the lucid window-buttons-on-the-left surprise, where we skipped straight to step c. 2½. There's less perception of a singular design figurehead. I suppose this is largely because several people have assumed this role over time (Ben Goodger, Beltzner, Faaborg). I think Ubuntu would benefit if we moved away from the idea that “everything sabdfl says is gospel; everything else is rumour”. design.canonical.com is helping here. ___ 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] Papercut or not? Bug #495403 in One Hundr ed Paper Cuts: “Do not raise windows or dialog s without user input”
OK, I didn't express myself clearly here: So when should the window manager switch from assuming you want a new window focused, to assuming you don't? When you deliberately focus another window. That's assuming the question. Whether you deliberately focus another window is what the window manager is trying to guess. Let's say windows A and B are already open, and A is focused. Window A is a panel, dock or app-launcher of some sort. Window A spawns a new window, C, which takes 30 seconds to open. Window A, upon spawning the new window, would immediately throw focus to something defined as «nothing». If, after those 30 seconds, focus is with «nothing», then window C should assume focus when it opens. The user can move focus away from «nothing» to a window by clicking (or mousing-over) it as now. After five seconds? Ten? Twenty? It shouldn't be timed. I suggest that if you haven't had time to focus another window (i.e. if you haven't started doing something else), focus the new window. If you've focused another window, the new window should open in the background. So how do you define started doing something else? When focus passes to any window. And how can the window manager, by itself, tell which was the action that resulted in the window eventually opening? The window manager doesn't need to know what launched the window. The focus state of the new window should only be based on what's focused when the new window opens. The launching app can then affect the new window's focus indirectly by throwing focus to «nothing». If «nothing» remains focused by the time the new window opens, focus the new window. If something is focused when the new window opens, it keeps focus. In the OpenOffice.org case, that would mean the previously focused window would remain focused for about 30 seconds after you launched OpenOffice.org, *then* become unfocused as soon as OO.o became able to do anything. By “the launching app” here, I meant the panel/dock. In this case, the previously-focused window (called A above) relinquishes focus immediately when OOo is launched/spawned (e.g. the icon clicked). For 30 seconds, «nothing» is focused. When the OOo window (C) finally gets round to opening, «nothing» is still focused, so OOo assumes focus. Alternatively, if during those 30 seconds I click on and thus focus window B, a window is focused and so OOo appears in the background. When a new window opens, it should assume focus if and only if «nothing» is focused. ___ 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] Papercut or not? Bug #495403 in One Hundr ed Paper Cuts: “Do not raise windows or dialog s without user input”
This doesn't work very well if an application in one workspace opens a modal dialog under a long living application in another workspace. Yes. If an application wants to open a dialogue, it really ought to throw focus to that dialogue. If it's opening a modal dialogue, surely it *must* throw focus to the modal dialogue. Therefore a modal dialogue should never appear behind the focused window. ___ 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] Papercut or not? Bug #495403 in One Hundr ed Paper Cuts: “Do not raise windows or dialog s without user input”
That is precisely what it does, and has done for years. But it will always be guessing. If you're watching a video and it mentions an unfamiliar word, and you launch the Dictionary to look it up, and it takes two seconds to launch, you want it to take focus. But if you launch OpenOffice.org and it takes 40 seconds to launch, probably you don't want it to suddenly cover the video you'll be watching 40 seconds later. So when should the window manager switch from assuming you want a new window focused, to assuming you don't? When you deliberately focus another window. After five seconds? Ten? Twenty? It shouldn't be timed. I suggest that if you haven't had time to focus another window (i.e. if you haven't started doing something else), focus the new window. If you've focused another window, the new window should open in the background. And how can the window manager, by itself, tell which was the action that resulted in the window eventually opening? The window manager doesn't need to know what launched the window. The focus state of the new window should only be based on what's focused when the new window opens. The launching app can then affect the new window's focus indirectly by throwing focus to «nothing». If «nothing» remains focused by the time the new window opens, focus the new window. If something is focused when the new window opens, it keeps focus. ___ 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] Windicators
On 4 May 2010 05:48, Tyler Brainerd tylerbrain...@gmail.com wrote: Actually I believe Mark gave some pretty clear reasons why. They want the upper right to have a particular analogy, just like they want the upper left. Right is for notifications, volume, brightness, and similar controls, the left is for menus, opening and closing, and other window management. It really does follow a logic; or, at least, more logic then no logic. It just wasn't particularly stated clearly. The Shut Down (etc.) menu is in the top-right. I understand it was put there by analogy with the windows' close buttons. Should it now be in the top-left? ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
