Re: [Ayatana] why compiz in place of mutter
Em 29-01-2012 10:10, Chow Loong Jin escreveu: On 29/01/2012 16:22, supernova wrote: Goodmorning (GMT+1) to all. Yesterday I tried Precise, and it works very good. I have seen that it is a bit slower and more fat than the gnome-shell, as it happened for 11.10, 11.04, ... . I guess it is due to compiz, which is more heavy than mutter. Why don't use mutter then? Unity doesn't use effects as rotation and wobbly. So mutter could be sufficient. Before Unity came along, Compiz was much leaner than Mutter/GNOME Shell was, using around 20MB of memory at any point of time, and not leaking any. After Unity came along, Compiz's memory consumption jumped up to ~80-100MB. If anything, Unity is why Compiz is running slower and fatter than previously. If I remember correctly, Unity came along at the same time Compiz 0.9.0 did, and 0.9.0 was the complete rewrite from C to C++. So Unity is probably not the only reason. ___ 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] why compiz in place of mutter
Em 29-01-2012 10:58, Chow Loong Jin escreveu: On 29/01/2012 20:55, Conscious User wrote: Em 29-01-2012 10:10, Chow Loong Jin escreveu: On 29/01/2012 16:22, supernova wrote: Goodmorning (GMT+1) to all. Yesterday I tried Precise, and it works very good. I have seen that it is a bit slower and more fat than the gnome-shell, as it happened for 11.10, 11.04, ... . I guess it is due to compiz, which is more heavy than mutter. Why don't use mutter then? Unity doesn't use effects as rotation and wobbly. So mutter could be sufficient. Before Unity came along, Compiz was much leaner than Mutter/GNOME Shell was, using around 20MB of memory at any point of time, and not leaking any. After Unity came along, Compiz's memory consumption jumped up to ~80-100MB. If anything, Unity is why Compiz is running slower and fatter than previously. If I remember correctly, Unity came along at the same time Compiz 0.9.0 did, and 0.9.0 was the complete rewrite from C to C++. So Unity is probably not the only reason. Not quite. I was using a Compiz 0.9.0 compiled using the script from git://anongit.compiz.org/users/soreau/scripts before Unity came along, and its memory consumption was ~20MB. Unity made all the difference. Ok, I stand corrected. Wondering how much of this is improving in Unity 5... ___ 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] GTK application menus
Hi, GTK applications, in particular GNOME core applications, are moving towards supermenus. https://live.gnome.org/ThreePointThree/Features/ApplicationMenu http://www.omgubuntu.co.uk/2012/01/gnomes-revamped-web-browser-is-minimal-mighty/ There is even a APIs to recognize those and render appropriately depending on the shell / OS. http://developer.gnome.org/gtk3/3.3/GtkApplication.html How will Unity render those? The current design does not allow doing what OSX does, because the left gap is occupied by the window buttons when the window is maximized. ___ 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] Notifications in unity
Em 02-12-2011 01:45, Chow Loong Jin escreveu: On 02/12/2011 03:45, Dylan McCall wrote: That this is the case should raise a red flag for everyone who has paid attention to NotifyOSD. A big part of the design is that an application can't control where notifications are. It can't treat a notification bubble as a part of its own user interface — neither as a dialog box nor a fancy tooltip. Yet indicator-sound is doing that intentionally, by default! That same thing goes against a big part of indicators, too: indicator-sound has no place assuming that indicators are at the top right of the screen or in any way related to notifications. I'll assume you're talking about the notification that pops up when you scroll on the volume icon. This notification is exactly the same as the notification when you press the volume buttons on the keyboard. I don't see any part of this behaviour depending on the position of the notification on the desktop. Whether the volume indicator appears at the top right, bottom left, or even centre of the screen, this behaviour will be consistent between your sound indicator and your keyboard volume buttons and is unlikely to look out of place (or at least any more out of place than it will if it's in the centre/bottom left anyway). And that's why my previous statement that volume scrolling is the only example where the current bubble positioning makes sense is actually wrong. It's not a valid example. So I really can't think of *any* example supporting the current positioning scheme. ___ 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] Notifications in unity
Which reminds me, shouldn't we stop pretending that synchronous and asynchronous notifications are similar enough to deserve being close? They are not, and the current approach causes more problems than solves. What problems does it cause? The most obvious one is the ugly gap when no synchronous notification is being shown. But I personally think that making synchronous and asynchronous informations have the same appearance and positioning is a mistake by itself. One is to notify and is supposed to call the user's attention. The other one is to provide feedback and is something that the user expects to appear. So much visual similarity for such different things is confusing. What problems does it solve? I am *supposing* that the idea is concentrating all notifications in a single place of the screen, thus simplifying things for the user. But this only makes sense if their purpose is similar enough to deserve such concentration, and I don't think they are. I do admit that the positioning is good when changing the volume with the scrollwheel, but that's the only case I can think of. If we must insist that their appearance must be the same, then the synchronous bubbles should at least be moved to somewhere else, like the lower corner (they can be there with no problems, since their size is fixed) In December 2009 I drew up some possible alternative placements.https://wiki.ubuntu.com/NotifyOSD#position Ops, sorry. I'm using the old sync vs. async terminology when I should be using confirmation vs. notification. Anyway, is it my impression or the current placement is not even considered a valid one according to the specification? Option 3 is by far my favorite. I remember Option 2 being tested and receiving some bad feedback (of questionable value, though, as I remember it was available for a very short period of time) Are there any reasons for not testing option 3? But I don't think even the appearance should be the same. In the attached screenshot you can see what appears when I click the play button when no player is open (I suppose it's a bug that notify-osd is not handling this), and in my opinion is much better. Why do you think it's better? (I'm not necessarily disagreeing with you on any of these, but we need to be able to explain *why* something is worse or better.) It's visually and positionally different enough to not be confused with async notifications, and provides a very clear feedback. And at least in my opinion the exposition time is short enough to avoid intrusiveness (like volume gauges on TVs) Also, notice how much more transparent it is. It seems significatively less clickable than OSD bubbles. It can get away with being more transparent because it contains only large chunky graphics, never text. Yes, but I'm not necessarily suggesting this for async notifications too, just mentioning this as an advantage. ___ 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] White text in lenses doesn't work well with light background images.
Le terça 30 agosto 2011 à 14:24 +0100, Matthew Paul Thomas a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jo-Erlend Schinstad wrote on 27/08/11 04:35: It's fantastically cool how the lenses background color changes with the desktop wallpaper. But when the wallpaper is a light one, then the text in the lenses become difficult to read. For example, Oneiric comes with the «Touch the light» wallpaper. At present, on my laptop, when I'm using that wallpaper, I'm completely unable to read any text in the dash or other lenses. http://launchpad.net/bugs/824916 So the text needs to change with the wallpaper dominant color as well, although I don't know exactly how. ... Here would be a good place to compare proposals for how to fix the problem. I shall start with two that immediately pop to mind: 1 - use an outline 2 - use the opposite of the background in a chosen color space It should be mentioned that GNOME always had this problem with the label of desktop icons. It partially solves it with a drop shadow, but it is not enough for light backgrounds. Attached is a screenshot with a wallpaper from the Natty default set. I don't use KDE, but I'm guessing they stopped worrying about this problem when desktop icons were moved to a plasma widget, which has a friendly combination of colors providing that the theme is sane. attachment: Capture.png___ 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-dev] The return of the ellipsis
Wrong: ☑ Automatically shorten pasted URLs. Right: ☑ Automatically shorten pasted URLs Well, that looks familiar... :) Is there a single, 100% reliable place where all those rules are documented? ___ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Persistent menu mockup
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. Le mercredi 20 avril 2011 à 11:50 -0500, S. Christian Collins a écrit : Hi folks, Many people have mentioned the problems with the inconsistency of the new panel (menu only visible on hover, etc.). Here is my proposed solution to this problem: * The menu of the active window is always displayed in the panel. * The title of the active application is displayed on the right side of the panel, just to the left of the system tray. * There is a clear division in the panel between the application title and the system tray to visually link the window's title with its menu. * The application's icon is displayed transparently beneath the window title for at-a-glance identification of the active window. This would make it easier to tell which window is currently active. * If the active window's menu is long enough to drift into the application title, the title would simply fade out at its leftmost edge (similar to its current behavior whereby the title fades at the rightmost edge when the menu appears). Have a look at my mockup and decide for yourself: ___ 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] New natty scrollbar issues
Sorry, but every pixel counts is not a definition of a problem. Before coming up with a solution, first you have to define what the problem you are trying to solve is. This is the supposed problem as defined by Christian Giordano, the man behind this scroll bar implementation: Today’s scrollbars are optimized for cursor driven UI but they became easily unnecessary and bulky on touchable and small screen devices. In those cases, optimization of the screen’s real-estate becomes essential. Other platforms optimized for touch input like Android and iOS are already using a light-weight solution visible only while dragging the content. I don't see any definition of any problems in there, just some presumptions. I'm not saying scroll couldn't be improved, it's just the approach that I believe is wrong, hence solution in search of a problem. The problem *is* clear: scrollbars are optimized for cursor driven UI but they became easily unnecessary and bulky on touchable and small screen devices. The issue is that the solution is *incomplete*: in order to improve the experience for touch screens, mouse users were forgotten and their experience that was previously optimized is not anymore. Ironically, this is the *opposite* of the menu-on-hover issue, where mouse users were prioritized and touch screen users were forgotten. It seems that, in addition to John and Matthew not talking to each other, Christian and John are also not talking to each other. Matthew has already acknowledged that there's no such thing as an interface optimal for both mouse and touch, so the design team should either make up their mind about what they're optimizing for, or Canonical should release an Ubuntu Touch Edition and separate the design projects accordingly. ___ 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] why global menubar/application menu isn't such a great idea
Mitja Pagon a écrit: You are making all sorts of false assumptions about how people use computers. If you ever observed regular users you would know, that most don't use keyboard shortcuts, some don't even know they exist. Furthermore, I've personally once came across someone who didn't know they could right click. There are drawback to global menus (especially as implemented in Unity) and there are benefits, but calling them bad UI is just uninformed personal option. And calling menus oh so 1999 just makes you look silly and again uninformed. Try reading some of the links you included and you will hopefully gain some understanding of the subject you are talking about. While I disagree with Mitja's tone (as usual), I agree with his main point. Most of giff's points were based on general assumptions backed up by little more than anecdotal evidence. And anecdotal evidence is easily countered: less than a week ago a user in this list mentioned how he had no problems with using OSX in a large HD monitor, for example. The existence of things like DejaMenu is hardly convincing evidence either, specially in the Linux ecosystem where there are hacks for anything and everything. Also, giff mistakenly uses an old post about the original Unity as an argument, ignoring the fact that netbooks are not the primary target anymore, effectively invalidating some of his points from the very beginning. The rest of the text is mostly questionable, with some apparent contradictions, both internal (ex: emphasizing how unnecessary the menu is, while complaining about the global menu making it slow) and external (ex: complaining how prominent it is, while a lot of people are complaining about not being prominent enough due to the show-on-hover). Overall, the points are not clear from a realistic point of view. At the end of the day, it seems the main point of the text is menus will die someday, so let's pretend this day has already arrived and move from there, which kinda... doesn't work in real life. :) ___ 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] Merging libindicate into libnotify
The idea that all non-immediate notifications should be grouped together in a single place, regardless of topic, is very much like the idea that progress for all long-running tasks should be grouped together in a single place regardless of task. It's the kind of categorization that may make perfect sense to engineers, but to others it risks looking like a jumble of unrelated things. What are your thoughts on, for example, what Jockey, PolicyKit and File Transfer currently do? They basically use an appindicator to persist, just like Update Manager did in the past with the notification area. Do you think this should be the standard procedure for all apps that do not fit in the current categories (messaging and sound)? If no, how should they be fixed? If yes, why not do something similar for Update Manager instead of popping up the window? One of the motivations behind the introduction of Notify OSD was to encourage applications to use general-purpose notification systems less often. Notifications of things are more helpful if they are closer to those things, for example embedded in relevant windows. Aren't the most common usage of notifications the situations where relevant windows are *not* currently in sight, or when there is no such thing as relevant windows at all? ___ 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] Merging libindicate into libnotify
Hi, In Natty, the Ubuntu One item was moved from the Me Menu from the Messaging Menu. Was this agreed on by the design team? If it was, I think this is a good opportunity to wonder if there is still a point in trying to tie the Messaging Menu to messaging applications only. Currently, the messaging menu is the desktop resource that covers that case where notifications require response but not necessarily immediate. The no-response case is covered by the bubbles and the immediate response case is covered by unfocused dialog boxes, or whatever will replace them (the never implemented morphing boxes in the specification or the IDO thingies that Empathy is using now) in the future. The existence of libindicate is something that has always bothered me. The not-necessarily-immediate-response case is a common scenario required by a significative number of applications, and requiring those applications to support an extra library (and thus extra patching for working in Ubuntu) is unpleasant. Shouldn't this case be covered by the Notification Spec and each desktop offer a standard single mechanism for handling them, independently of the app? Shouldn't the Messaging Menu drop the messaging app requirement and become the standard Ubuntu mechanism for handling these kind of notifications? For the sake of consistency and for the sake of not driving upstream crazy, I do believe that this case should be well-specified in libnotify, and the manipulation of something like the messaging menu, should be part of NotifyOSD. ___ 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] Merging libindicate into libnotify
Le jeudi 31 mars 2011 à 12:35 -0700, Dylan McCall a écrit : This is something that _is_ covered by a particular subset of the notification specification; it's just that it isn't guaranteed. Gnome Shell is doing what you want here: they went ahead and defined persistent notifications, which their message tray is optimised for. Unfortunately, it's all wrapped into the same notification specification for some reason. The platform as a whole now has an impressively convoluted setup for notifications. It's almost as if we don't want people using these. Here's what an application must do, as I understand it: * First, I will ask the notification server for its capabilities. Does it support persistence? * Yes? Great, I'll show a resident notification. * No? Okay, just give it a long life and a few actions, I guess. * I can't do actions? Okay, change the message to reflect that, maybe tell the user where to find me. * Wait, do I even know what this notification server is doing? Ugh, it's probably notify-osd. I guess I'll assume it's a transient notification. * Am I reading the right version of the notification spec? * Well, now that I've gone this far, it can't hurt to add libindicate. Right? * Do I actually belong in the messaging menu? Don't care: I want a resident notification, and my developers don't want to maintain any more strings! * The end. Android does this well: http://developer.android.com/guide/topics/ui/notifiers/index.html There is no overlap. Each type of notification is optimised for one task. You choose, from the onset, if you want a Toast notification, a Status Bar notification, or a dialog notification. Each one does exactly what it says on the tin and it does it well. An application doesn't waste resources trying to figure out how to present a notification at runtime and the system knows exactly how each type of notification is meant to be displayed. Perhaps there is room for consolidating Ubuntu's great work on transient notifications and Gnome's great work on persistent notifications by managing these as separate systems with their own specifications. Because, as the messaging menu pretty clearly reminds us, they are. In my opinion, separating the systems is not necessary, and wrapping all cases in the same specification is not a bad thing. The main problem is, as you pointed out, this GetCapabilities mess. The applications should not *care* whether the server supports persistence or not: it should just say that the notification is supposed to persist. Whether the server will do this competently, is not the applications' problem. But save for this GetCapabilities issue, the specification is fine. The serves are broken. Gnome3 is too optimized for persistent notifications, while Ubuntu is too optimized for transient notifications. Ideally, someone developing an application for Ubuntu should not worry about using something like libindicate: he should use only libnotify, and NotifyOSD would be responsible for throwing persistent notifications to something like the messaging menu. The problem with the current implementation is: NotifyOSD simply *ignores* actions and it's up to the application developer to explicitly include libindicate support in his app. Worse: he can only do that if he can argue that his app fits in the messaging application concept. This has left this weird conceptual gap in the Ubuntu desktop, where notifications that are persistent but not related to messaging have nowhere to go, and things like Jockey, PolicyKit and Apport are now as conceptually broken as they were before: only now they use AppIndicators as their playground, instead of the notification area. (I think Apport was recently changed to use popups instead, but I don't feel this is ideal either... it's not that urgent) The Messaging Menu should be refined to support *any* persistent notifications, not only from messaging applications. Only then this conceptual gap will be closed. Until that happens, we will stay either with legacy things like jockey popping up in the indicator area or with strange things like Ubuntu One being in the Messaging Menu. ___ 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] Indicator-sound and highlighting the track on mouseover
It is interactive: when you click on it, the track information is copied to the clipboard and you can paste it somewhere else. Whether this is useful, specially considering discoverability, is a different discussion. In my personal opinion... well, no. Le samedi 26 mars 2011 à 15:32 -0400, Brett Cornwall a écrit : Hello, I have been wondering for some time - is there a particular reason for having the now playing text fields in the sound indicator highlighted on mouseover? It gives the impression that it's an interactive item but it's merely there for displaying information. Would it not make more sense to have no mouseover highlight? screenshot: http://ubuntuone.com/p/jax/ If yes, should I report a bug? I wanted to check to make sure there's no design decision including this behavior first. Thank you. ___ 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] List of running windows of an application in the launcher quicklist
Le samedi 26 mars 2011 à 19:11 +, Luke Benstead a écrit : On 23 March 2011 14:13, Bilal Akhtar bilalakh...@ubuntu.com wrote: The current way of switching between windows of the same app is time-consuming. The launcher icon has to be clicked twice for the 'spread' compiz view to get activated, and then we switch between windows. Alongside this, it would be good to have a numbered list of running windows of an app, in its launcher icon's quicklist. This list would be separated from the rest of the quicklist items by a separator line. An example of such an implementation is in Gnome-Shell. I agree, I think switching windows in Unity is cumbersome and frustrating. Windows 7 actually gets this right IMO, if you hover the application icon you are shown a list of that application's windows. You can select the window you want in a single click, it's extremely fast and easy to use. DockbarX also implements this for GNOME and also gives the option of window previews instead of a list. I urge anyone who hasn't tried DockbarX to give it a spin under GNOME 2.x I think it would be a huge improvement to Unity if this kind of window switching was implemented. Hello, First of all, let me say that I fully support the idea of listing the open windows in the quicklist. This is very expected behavior and it is always frustrating to right-click the icon and not see it there. About the Scale, as a fan of the plugin even before Unity was first announced, I'm going to play Devil's Advocate a little bit. For starters, just to make Bilal's statement a little bit more accurate, I should mention that activating scale does not require two clicks. It does only if no window of the application is currently in focus. If a window of the application is, activating Scale only requires one click. What happens is that the first click gives focus to the last focused window of the application. That makes sense for the very common case where you switching between two apps, but between specific windows of such apps: requiring scale every time you switch from one to the other would be annoying. Second, let's not confuse Unity's current implementation with the concept itself. The current implementation is questionable in a lot of ways and it is important to recognize which issues raised here are *inherent* to the concept and which ones are wrong implementations that could be solved with simple refinements. For example, the lack of labeling bug raised by Bazon and the lack of a distinguished appearance for minimized windows make Scale much less useful than it could be. As it can be seen in this screenshot from Bug 734253, OSX does this right: http://mac101.net/files/2009/06/20090629_screenshot_on_2009_06_29_at_73451_pm.png Now, I agree with Luke when he says that Aero Peek works very well with Windows 7, but supposing some tweaks here and there, there are no big differences between Peek and Scale. And Scale has the advantage of having larger thumbnails. Peek solves this with the transparency effect, but let's not forget that this only works because Windows only has a single workspace. I think the Scale *can* work, and a complete redesign is not necessary. ___ 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] Launcher pulse prominence
I'm glad I'm not alone, then. Vish raised a good point on IRC. Currently the backlight is set to always on, but if they change that to no backlight or toggle backlight the pulse might be more noticeable. I toggle the backlight completely off (with the arrows I don't see the point, and I prefer to see the original icons instead of their forcefully square versions that sometimes have the backlight too close to the icon itself) and in my opinion yes, this indeed does *wonders* for making the pulse more proeminent, ___ 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] Improving Launcher behavior
The original Unity had top and bottom folding, and used an intelli-folding that essentially solved all the current problems: the last clicked icon was always kept in the same place, and top or bottom folding would be used depending on the situation. Think CoverFlow. I quite liked it, to be honest. It was like a fancy way of scrolling that almost didn't require *actual* scrolling. http://design.canonical.com/2010/06/introduction-to-unity-launcher/ I have no idea why the top folding was dropped. It introduced all the current problems without real benefits, it seems... I already asked about this but got no response: https://lists.launchpad.net/ayatana/msg04927.html Hi, I have a suggestion regarding the behavior of the Unity Launcher. I think the problem with the current design is that when you have enough icons so they fold, when you mouse over the launcher you need to scroll to get to the bottom icon. I caught myself scrolling with my mouse a lot since the launcher is hidden most of the time by default (dodging windows) and I also can't mouse over and expand it from bottom. My suggestion to solve this problem is to unfold the icons on the launcher in relation to the position of the mouse pointer. That way icons would never leave the bottom or the top of the screen, so no scrolling would be required. Moving the mouse toward the bottom of the launcher, where there are folded icons would cause them to unfold and at the same time the top icons would fold one by one, so the icons don't move too much around. Also, moving the mouse to the top of the launcher would always get you to the first icon and moving to the bottom would get you to the last icon. What do you think? Is this something worth doing and are there other problems with this approach that I haven't considered? ___ 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
Matthew Paul Thomas wrote: ... (I pretty much agree with the paragraphs before, so I'm simply omitting them...) I think the Gnome Shell designers are badly underestimating the use cases for minimize. Maybe... but the problem is, so is Unity, at least currently. It didn't remove minimization but made it... weird. And anyone who thinks dragging is a replacement or a maximize button probably hasn't done any user testing recently. Ok, admittedly I'm biased on this one because Aero Snap is one of the things I went faster from discovering to using all the time... And even before that I was fond of the double click. In guess in my mind the max button is already useless... I should mention, though, that in my opinion the fact that Unity merges the titlebar with the panel makes the dragging slightly more intuitive: you drag the titlebar to the thing it's going to be merged to. Perhaps *too* slightly to make a difference, but does help. ___ 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
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
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
Is it a coincidence that the two of them worked in Open source projects _before_ joining Canonical design team..? ;-) This topic has been hashed, re-hashed over-n-over again several times.. I, for one, definitely see a huge improvement in communication from the design team. Several members have replied here to questions that are being asked. And IMO, recently, this has ceased to be a problem.. We have to realize that this mailing list is *very* high volume and you really can not expect everyone in the design team to read each-n-every mail and reply to every idea that is being thrown out at them.. I'm always amazed how Mark is able to keep up though, and at MPT too but to a lesser extent.. ;-) And this mailing list is *not* a place for them to propose their ideas. They have blogged about most of their new ideas on their blog. This is just a communication channel where we can propose ideas for their consideration. I think its high time we dropped the design-team-bashing for not communicating each and every time a change is made.. ;-) You completely missed my point. Yes, I'm talking about the lack of communication between the design team and the community, but this time as a mere *consequence* of issue actually being discussed: that the communication is broken *internally* on the design team. As far as I know, design team members not being aware of other design team members are doing is *not* a topic hashed, re-hashed over-n-over again several times. ___ 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] Double side springboard! The video.
Looking good! I think the corner button could flip the launcher AND activate the Dash. It makes sense: - clicking on an application launcher closes the Dash if it's open anyway, so there's little use in making the application side available when the Dash is open - the tendency is to Dash gradually replace Nautilus in everyday usage, so it makes sense that when Dash is open the launcher is populated with folders and devices... and clicking on them could switch the Dash context instead of opening Nautilus Le mardi 15 mars 2011 à 16:18 +0100, andrea azzarone a écrit : Maybe this is batter than a simple mockup: http://www.youtube.com/watch?v=1RudBG7pfzgfeature=player_embedded I have used ubuntu logo as Shortcuts dash, because I just wanted to make the idea! I hope you like it! Andrea Azzarone http://www.ubuntusecrets.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] Design problem: Menus hidden by default in Unity
I have a simple proposal to fix these problems: The application title should be removed from Unity's menu bar. I'm reliably informed that this would be extremely low risk, in that it would involve changing two lines of code. But how would be the design for maximized windows? I'm guessing the fixed-size title in the menubar is there to occupy the same space the buttons do when maximized, so the menubar doesn't move when the window is maximized. Plus, for maximized windows there is also the problem of how the (potentially long) title and the menubar could share the panel without the show-on-hover. On a side note, I'm kinda baffled at how fragmented the design process seems to be judging by this email... I thought mpt was aware of this for a long time. ___ 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
Thorsten Wilms wrote: The alternative would be to show both title and menu, but giving the menu priority. For habituation and quick aiming, it's important that the menu always starts in the same spot from the left (assuming LTR reading direction). To guarantee that, without using an offset from the left that will always be too small or too large, the title would have to be right-aligned to the right side of the window or panel. But clipped/faded-out on the right, when necessary. And where would the window buttons go? If this discussion ends up concluding that they are better on the right, the universe will probably explode with irony. ___ 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
Remco wrote: The thing I find jarring is that we have this mysterious design team that basically discusses things behind our backs here at Ayatana. I understand that a small team with face-to-face meetings can be beneficial to design, but a problem lies in communication and collaboration between the team and Ayatana. Yeah, the current situation is... weird, to say the least. I've always heard rumors that the design team worked far from the rest, but at the same time always felt comforted by the fact that at least *someone* from the team (Matthew and, before, David Siegel) was active here. Apparently, that doesn't mean much. I know that different people in the design team probably work in different things, and I know that it's not the first time Ubuntu has a design change not approved by all members of the team (ex: IIRC, Matthew didn't agree with music icons in the Sound Menu instead of specific app icons), but to see such a miscommunication in such a prominent part of Unity is a little bit... shocking. ___ 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] Introduction and suggestion
Actually, and I already mentioned this to Phong, but that isn't a mockup,, rather what my panel looks like after tweaking my Ambiance theme. The Panel does follow the user preferences. My bad. Where I said current visual of the panel I actually meant current visual of the launcher. The launcher is hardcoded. I don't feel like the unity pane and the window titlebar are the same thing, rather the panel provides titlebar-like functionality in the case of a maximized window with focus. All other times, the panel serves as a place for indicators, the menu, and the dash button. Additionally, it continues to serve this purpose while holding the window controls for maximized windows, which I feel keeps it further separate from the titlebar. The panel isn't a titlebar, it's more. In this case, it's a part of unity, and should be visually consistent with it. Those are all subjective opinions. We can play this semantic-tweaking game all day, but there isn't much sense to it. :) Repeating what I said in my previous email: the discussion is useless if the launcher remains hardcoded. And if it becomes themable, then it's purely a theme discussion and I'm not sure if it belongs to this list. ___ 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] We need a short-term solution for mail applications and the messaging menu
In an effort to get *some* reaction other than Jeremy's to this thread, let me ask something to the people of this list: how many of you actually use Evolution? And how many of you feel confortable with the current way it's integrated to the Messaging Menu (and now Unity)? More specifically, how many of you think that the current setup of not being able to hide the window is acceptable while the separation of mail notification service does not happen? I have the impression that the user experience of Evolution always ends up being overlooked because the majority of people uses a webmail client and does not really care. Hi all, Let me start the discussion by saying I agree with Matthew: https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-coherent-behavior-for-apps-in-messagingmenu http://design.canonical.com/2011/03/quit/ The engineering solution here is for messaging clients to split out the code that checks for new messages, so that it can optionally run even while the rest of the application is not. However, I don't think this separation is coming anytime soon. Meanwhile, for several releases now Evolution is being the only inconsistent application in the Messaging Menu, the only that quits on close, the only one that needs to be present on both the MM and the taskbar (soon to be Unity Launcher). Thunderbird is getting Messaging Menu support with the exact same problem, and to make things worse we will now not only have redundancy of presence, but also redundancy of information presentation: http://bazaar.launchpad.net/~indicator-applet-developers/evolution-indicator/trunk/revision/77 http://www.omgubuntu.co.uk/2011/03/thunderbird-getting-some-unity-love/ Evolution/Thunderbird should be on the launcher, or the messaging menu, but *not* on both of them. I don't expect a patch that modularizes Evolution or Thunderbird dropping from the sky, so we need a short term solution instead of continuing to ship the current, horribly redundant, situation. My suggestion is to either accept Geoff Goehle's patch: https://code.launchpad.net/~goehle/evolution-indicator/dont-quit-on-close/+merge/42151 or to remove Evolution from the Messaging Menu entirely, as it can be argued that email is not something you should be interested in being constantly notified about anyway and Evolution consumes a lot of memory. (see pitti's comments in the first link) 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] 'Control Center' should be in 'Launcher' not in 'Session Menu'
Mark Curtis wrote: Someone else suggested putting it in the Me Menu This would solve both problems of not being close to Shut Down nor cluttering up the Launcher Ian Santopietro wrote: I agree with putting it in the Me Menu. We can't put everything only one click away, since with all that you want to do on a daily basis, that would make for a very cluttered environment. Frequently used apps should go in the launcher, along with the places. Most other things should be left out. M. Adnan Quaium wrote: +1 Me menu sounds promising. I'm seeing arguments against the Session Menu and the Launcher, but no arguments actually in favor of the Me Menu specifically. I think it would be equally or more inadequate than the Session Menu. I agree with the previous proposal of making it a Dash view. The control center is just a categorized set of application shortcuts, exactly what the Dash is optimized to handle. ___ 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] We need a short-term solution for mail applications and the messaging menu
Hi all, Let me start the discussion by saying I agree with Matthew: https://blueprints.launchpad.net/ubuntu/+spec/packageselection-desktop-n-coherent-behavior-for-apps-in-messagingmenu http://design.canonical.com/2011/03/quit/ The engineering solution here is for messaging clients to split out the code that checks for new messages, so that it can optionally run even while the rest of the application is not. However, I don't think this separation is coming anytime soon. Meanwhile, for several releases now Evolution is being the only inconsistent application in the Messaging Menu, the only that quits on close, the only one that needs to be present on both the MM and the taskbar (soon to be Unity Launcher). Thunderbird is getting Messaging Menu support with the exact same problem, and to make things worse we will now not only have redundancy of presence, but also redundancy of information presentation: http://bazaar.launchpad.net/~indicator-applet-developers/evolution-indicator/trunk/revision/77 http://www.omgubuntu.co.uk/2011/03/thunderbird-getting-some-unity-love/ Evolution/Thunderbird should be on the launcher, or the messaging menu, but *not* on both of them. I don't expect a patch that modularizes Evolution or Thunderbird dropping from the sky, so we need a short term solution instead of continuing to ship the current, horribly redundant, situation. My suggestion is to either accept Geoff Goehle's patch: https://code.launchpad.net/~goehle/evolution-indicator/dont-quit-on-close/+merge/42151 or to remove Evolution from the Messaging Menu entirely, as it can be argued that email is not something you should be interested in being constantly notified about anyway and Evolution consumes a lot of memory. (see pitti's comments in the first link) 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
[Ayatana-dev] Limiting the vertical size of the Unity launcher
Hello! This is probably a question for Jason, but I'm not 100% sure. When Unity lands, I intend to use the bottom left corner to place a small conky window, as I am a system stats junkie. But I won't want the Unity launcher to get in the way of conky and vice versa, so I need the Unity launcher to stop at X pixels from the bottom. How can I achieve that? Because this is of no interest whatsoever to the average user, I'm not asking for a setting or anything... I would just like to know where in the code I should hack into. (hence posting this to ayatana-dev) Thanks in advance! ___ Mailing list: https://launchpad.net/~ayatana-dev Post to : ayatana-dev@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana-dev More help : https://help.launchpad.net/ListHelp
[Ayatana] Where did the top folding go?
Hello, I've been bugging Neil Patel about this on Twitter lately and would like to know what the rest of the team has to say. It seems that Unity has purposefully dropped the ability to fold icons on top and now only folds the bottom ones. Even after some weeks, I still think it's very awkward to use because it feels like a scrollbar that always returns to the top when you leave it: an icon folded at the bottom will always re-fold even though it was the last icon clicked. This kinda goes against muscle memory and gives an unbalanced distribution of importance among the icons: the top ones are always faster to access. At least for me, it is very common for the workflow to be focused on the more recently opened windows, which are precisely the bottom ones. Neil mentioned possibilities of making the active window icon more noticeable even when it's in the folded area. This would be nice, but the unbalance would still be there. What was, after all, the reasoning for removing top folding? ___ 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] Left close buttons on tabs
It is true that Chrome does not currently cover the use case Matthew presented, even with the buttons on the right, but I think his point was that it *could* if the devs *wanted to*, while with buttons on the right, it is not possible without awkwardness. That said, I do question if two having different behaviors (sliding when the tab is not the final one, resizing when it is) is a good idea... sounds inconsistent and awkward in its own way. Also, even buttons on the right do not properly cover the case where the use wants to start closing by the last tab, but there are not enough tabs to horizontally fill the screen, unless we follow the tabs are streched for horizontal feeling even when there are very few tabs philosophy of Nautilus... which is kinda ugly, to be honest. Le lundi 28 février 2011 à 14:14 -0500, Mark Curtis a écrit : Chrome's tab behavior for quickly closing tabs is for quickly closing the current tab and the ones after (to the right) of it. If close buttons for the tabs were on the left, then Chrome's behavior would be the same, reorder the tabs upon close, resize them (if necessary) ones the mouse leaves the tab area. Date: Mon, 28 Feb 2011 18:34:18 + From: m...@canonical.com To: ayatana@lists.launchpad.net Subject: Re: [Ayatana] Left close buttons on tabs -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mark Shuttleworth wrote on 20/02/11 15:04: The close-multiple-tabs-fast behaviour just requires that the tab realignment be smart. If you look closely, Chrome realigns twice, once for fast closing, then for better spacing. In other words, if fast-closing is a goal, then it's perfectly possible to ensure that successive close buttons are placed underneath one another, and then the whole set are re-flowed once the obvious closefest is over. ... That would be correct only when none of the tabs you were closing was the last one in the row. If yo u did close the last tab, though, then putting the close button for the previous tab under the cursor would require the developer to choose one of three unattractive options. 1. Widen all tabs to be even wider than they will be once you leave, and crop part of the last one: | | |/x 1 \/x 2 \/x 3 \/x 4 \/x 5 \| ↓ | __ __ __ ↓| |/x 1 \/x 2 \/x 3 \/x 4 |\ ↓ | __ __ ↓| |/x 1 \/x 2 \/x 3 | \ | | |/x 1 \/x 2 \/x 3 \| (after leaving) 2. Widen all tabs except the last one to be wider than they will be once you leave, with the last one temporarily being narrower than all the others: | | |/x 1 \/x 2 \/x 3 \/x 4 \/x 5 \| ↓ | __ __ __ ↓___ | |/x 1 \/x 2 \/x 3 \/x 4 \| ↓ | __ __ ↓___ | |/x 1 \/x 2 \/x 3 \| | | |/x 1 \/x 2 \/x 3 \| 3. Make all tabs temporarily jump one place to the right, resizing back to the left when you leave: | | |/x 1 \/x 2 \/x 3 \/x 4 \/x 5 \| ↓ | ↓___ | |__/x 1 \/x 2 \/x 3 \/x 4 \| ↓ | ↓___ | |/x 1 \/x 2 \/x 3 \| | | /font |/x 1 \/x 2 \/x 3 \| Close buttons at the trailing end avoid any of these awkward choices. And as a bonus, if all the tabs you closed were, when you closed them, the last tab in the row, no further resizing is required once you leave the area. | | |/ 1 x\/ 2 x\/ 3 x\/ 4 x\/ 5 x\| ↓ | __ _ __ ↓ | |/ 1 x\/ 2 x\/ 3 x\/ 4 x\| ↓ | ___↓ | |/ 1 x\/ 2 x\/ 3 x\| | | |/ 1 x\/ 2 x\/ 3 x\| - -- mpt -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk1r6qoACgkQ6PUxNfU6ecoXHwCgs/EA2wsDs1y7pstHoNeQWQVT Ke0An0cR05yK1xapSBQOaoTaNjUL4+AQ =JWlY -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 ___ 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] The Unity launcher window matching policy
Hello, I was thinking about filing a bug (perhaps multiple, per-app bugs) to track all applications in the Ubuntu repositories (or at least all applications in a default install) whose windows are not being currently correctly matched to a .desktop file in the Unity launcher, causing ugly icons and inability to pin to the dock. Some examples: policykit, bluetooth-wizard, evolution-backup... But I can't do that accurately without knowing the exact policy for window matching that the launcher is using. Jason, is it doing exactly the same as Docky (looking for .desktop files according to the window class and using StartupWMClass for corner cases like Java apps, iirc) I wanted to post in every report the exact procedure to fix. I was originally going to post this in the ayatana-dev list, but this can raise some conceptual issues (ex: should all windows be pinnable?) ___ 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 Unity launcher window matching policy
Hi Jason, thanks for all the information. I think a wiki page is more efficient than a bug report for tracking those issues, so I started a crude draft in: https://wiki.ubuntu.com/Unity/WindowMatching I already added pango-view as Paul pointed out. Please, if anyone sees mistakes (there are probably many right now) point them out. Hopefully at least all apps included in the default install can be fixed until release. ___ 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] I don't think global menu and the panel is good for a touch OS
It is futile to attempt to solve a problem that does not yet exist. What are you talking about? Ubuntu is being installed in touch devices as we speak: http://www.engadget.com/2011/01/11/augen-improves-gentouch-78-teases-lenovo-u1-hybrid-competitor/ http://www.gizchina.com/2010/12/28/ubuntu-tablet-details-surface/ Not to mention that Unity is supposed to be touch-friendly by design: http://www.markshuttleworth.com/archives/383 Of course, if you think a 24px bar is a useful UI in a touch-oriented environment, i will not agree. I don't, and that's another point against Unity in its current form for touch devices. ___ 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] I don't think global menu and the panel is good for a touch OS
I'm not really interested in brainstorming right now. Natty is going to be released in three months and I'm interested in knowing which ideas the official design team *already have* to address the hover issue, or why they don't consider it an issue. -Original Message- From: frederik.nnaji frederik.nn...@gmail.com To: Conscious User consciousu...@aol.com Cc: ayatana ayatana@lists.launchpad.net Sent: Tue, Jan 18, 2011 8:39 am Subject: Re: [Ayatana] I don't think global menu and the panel is good for a touch OS On Tue, Jan 18, 2011 at 11:26, Conscious User consciousu...@aol.com wrote: It is futile to attempt to solve a problem that does not yet exist. What are you talking about? Ubuntu is being installed in touch devices as we speak: http://www.engadget.com/2011/01/11/augen-improves-gentouch-78-teases-lenovo-u1-hybrid-competitor/ http://www.gizchina.com/2010/12/28/ubuntu-tablet-details-surface/ Not to mention that Unity is supposed to be touch-friendly by design: http://www.markshuttleworth.com/archives/383 Of course, if you think a 24px bar is a useful UI in a touch-oriented environment, i will not agree. I don't, and that's another point against Unity in its current form for touch devices. Ah ok i get you now. So how about unity launcher, NO appmenu, wingpanel 48px transparent and transparent titlebars with large hide button and large float button? float button would scale down the window aka document and make it transparent just like when i'm moving windows in compiz in current natty. also.. i suggest strongly to reduce the opacity by at least another 10% by default.. ___ 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] I don't think global menu and the panel is good for a touch OS
They are very different things, and a design that works well for one will hardly ever work well for the other. I'm a little bit confused now because Mark's blog post about Unity clearly stated that some design decisions were motivated by touch devices. Is the Unity design still taking touch into consideration or this was completely dropped once it was decided that Desktops would use it too? ___ 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] I don't think global menu and the panel is good for a touch OS
I'm particularly interested in this issue. I like the show on hover, but how is it going to be addressed in touch devices? eye-tracking? I'm not talking about the future. I'm asking how the designers are handling this issue *now*, for Natty. ___ 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] Evolution indicator
Hey Vish and other, As told in https://lists.launchpad.net/ayatana/msg04544.html, we discussed that behavior at last UDS and it seems that emails shouldn't be seen as a service. mpt will be able to develop it a little bit more right now. One issue I'm now noticing at that blueprint discussion is that it started about harmonizing the behavior of sound and messaging applications and ended with the conclusion that sound apps are more service-y than message apps. But what about harmonizing the behavior between *different* messaging applications? Fact is, among all four applications I have in the MM (Empathy, Evolution, Gwibber, Liferea), Evolution is the *only* one without a hide behavior. ___ 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] I don't think global menu and the panel is good for a touch OS
Le jeudi 13 janvier 2011 à 23:39 -0500, Mark Curtis a écrit : I figured the point raised in this topic would be that the global menu items currently are only visible on HOVER. Something that is impossible to do on a touch based device. I'm particularly interested in this issue. I like the show on hover, but how is it going to be addressed in touch devices? ___ 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] Compatibility goals for Natty appmenu
Hi, I'm curious with respect to the appmenu compatibility goals targeted for Natty. So far there are some important apps non-compatible with it: XUL apps [Open,Libre]Office Swing apps SWT apps MonoDevelop I know that XUL is being worked on, but I heard no news about the rest. I'm particularly interested in SWT compatibility as an Eclipse user. ___ 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] The Unity launcher and minimized windows
Hi, Currently the Unity launcher in Natty does not offer any way to restore minimized windows if another window from the same application is opened (the scale plugin is invoked instead, considering only non-minimized windows). I suppose this is because it's just an alpha, but what is the intended behavior in the final version? Making the scale plugin include minimized windows the same way it includes non-minimized windows, I think it's a bad idea. Minimized windows are in a different state and that should be visually shown. I'm attaching an ugly, made-in-five-seconds mockup with a suggestion: when an icon is clicked in the launcher and some windows of the app are minimized and some are not, the launcher shows the minimized ones as icons below. That way the user knows which windows will be restored and which ones will be just focused when selected. It also gives less trouble to compiz by not asking it to generate previews for minimized 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] The Unity launcher and minimized windows
Minimize should be deprecated, because it was a workaround for hide window, which would have been a non-reversible gesture without tools like docky or the unity launcher now, or the window list back then. Minimize is a synonym for iconify, now list to me the situations in which you want a program main window to be iconified onto a certain part of the screen?! Actually, I've been a supporter of killing minimization for years. My suggestions in this thread are more for legacy purposes, as I don't see the removal of such a taken-for-granted feature being seriously adopted any time soon. ___ 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] Messaging Menu and the MeMenu
How about getting rid of the section headings and showing instant messaging items on top, inboxes with their service-icon as prefix below!? That *does* help cleaning up, but then we need another way of opening the IM program when no new messages have arrived. ___ 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] [Fwd: Re: Presence via Me Menu]
so.. what could the local relevance of Invisible aka hidden be? is there any? In IM being invisible means that you want the world to treat you like you were offline. That means not sending you anything, regardless of how important it is. Invisible can be seen as the ultimate maximum level of do not disturb. ___ 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] Messaging Menu and the MeMenu
Right now, the Messaging Menu and MeMenu are kind of connected, in that the functionality of the MeMenu changes by clicks in the Messaging Menu. For example, to get a text box for a broadcast account in the MeMenu, the user has to go to the Messaging Menu to start Gwibber. Furthermore, to actually use the inactive status buttons in the MeMenu, the user has to start chat from the messaging menu, As Conscious user said, the IM status problem has always been a bug. The Gwibber problem, on the other hand, is a design flaw. One solution could be merging the two menus, but that could create too large a menu. A better solution could be to have the textbox and buttons appear when the user sets up the two accounts for the first time, and to keep them active. I think both of those would make a lot of sense. Perhaps someone could sketch what a combined menu might look like? I would like to know what the rationale for the current functionality is. There is none. I'm resurrecting this thread now that I'm finally regularly on Maverick. The more I use the Message Menu, the more I get convinced that it shouldn't have more functionality than it does now. In fact, I got fed up of the Contacts and Compose in the Evolution entry and removed them, making the menu purely an inbox (see attachment) I think the Messaging Menu *should* be purely an inbox, because one of the most common complaints against the notifications redesign is how reacting to IM/mail notifications is now less efficient (opening an menu and looking for an entry instead of simply clicking on the tray icon). I personally think that the difference is negligible, but *only* if the menu is not too cluttered. I don't think the current separation between the Message and Me menus is necessarily a bad thing. I believe it only needs some refinement, both in design and implementation, to show that the idea of thinking functionality-wise (inbox vs. outbox) instead of application-wise (empathy, evolution, etc.) is not absurd as it seems at a first glance. Some things that get in the way of this objective now: - Shortcuts for configuring im/microblog accounts in the Me Menu. This overlaps with the messaging menu directly and keeping those entries there does not make sense once the accounts are configured... the Messaging Menu does it more correctly, showing them only if no accounts are configured - Ubuntu One in the Me Menu... I don't think it really fits. - Contacts and Compose in the Messaging Menu... having two outbox entries lost in the middle looks and feels wrong... and adds clutter attachment: menu.png___ 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] Do You Use Gwibber?
Well, I don't know how else entry could be interpreted... -Original Message- From: frederik.nnaji frederik.nn...@gmail.com To: Conscious User consciousu...@aol.com Cc: ayatana ayatana@lists.launchpad.net Sent: Fri, Dec 10, 2010 3:45 pm Subject: Re: [Ayatana] Do You Use Gwibber? On Tue, Dec 7, 2010 at 17:13, Conscious User consciousu...@aol.com wrote: As for the entry in the Messaging Menu, if it had character counting and url shortening I'd be using it a lot more, because it makes sense: I shouldn't need to explicitly open Gwibber to post a message, just like I shouldn't need to explicitly open my contact list just to change my status. i think you mean the status input field of the Me Menu here, right? ___ 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] Do You Use Gwibber?
Sigh... so indeed it was my fault. And I in fact re-read what I wrote two or three times to make sure there wasn't any ambiguity and still managed to miss that... Sorry. :( Anyways, for the sake of giving a more complete answer: it should be mentioned that the Me Menu has always been designed to be more functional with respect to microblogging thant it is now: https://wiki.edubuntu.org/MeMenu#Use%20cases -Original Message- From: Frederik Nnaji frederik.nn...@gmail.com To: Conscious User consciousu...@aol.com Sent: Sat, Dec 11, 2010 2:36 am Subject: Re: [Ayatana] Do You Use Gwibber? On Sat, 2010-12-11 at 03:36 -0500, Conscious User wrote: Well, I don't know how else entry could be interpreted... ..because you wrote entry in the Messaging Menu i was not sure if you meant Me Menu.. i personally use the word entry synonymously to menu item sometimes.. that's why i got a lil confused, all good now, i get it :D thanks for your brilliang ideas, i've been learning a lot by just reading your msgs! safe nnaji -Original Message- From: frederik.nnaji frederik.nn...@gmail.com To: Conscious User consciousu...@aol.com Cc: ayatana ayatana@lists.launchpad.net Sent: Fri, Dec 10, 2010 3:45 pm Subject: Re: [Ayatana] Do You Use Gwibber? On Tue, Dec 7, 2010 at 17:13, Conscious User consciousu...@aol.com wrote: As for the entry in the Messaging Menu, if it had character counting and url shortening I'd be using it a lot more, because it makes sense: I shouldn't need to explicitly open Gwibber to post a message, just like I shouldn't need to explicitly open my contact list just to change my status. i think you mean the status input field of the Me Menu here, right? ___ 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] progress window chrome
Discussions about an eventual progress indicator aside, I think this is the kind of thing modal dialogs are meant to eliminate. http://people.freedesktop.org/~david/gnome-shell-modal-dialogs.png -Original Message- From: frederik.nnaji frederik.nn...@gmail.com To: Ayatana List ayatana@lists.launchpad.net Sent: Mon, Dec 6, 2010 6:43 pm Subject: [Ayatana] progress window chrome what purpose has the titlebar in the attached image? I can only imagine that it is meant as a drag handle.. anybody? ___Mailing list: https://launchpad.net/~ayatanaPost to : ayat...@lists.launchpad.netunsubscribe : https://launchpad.net/~ayatanaMore 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] Do You Use Gwibber?
Finally, it would be really nice if Gwibber pulled in my most current status update from Identi.ca and placed it into the Me menu, so I could see what my current status is when I go to update it. Interestingly enough, this has already been part of the specification for a long time now: https://wiki.edubuntu.org/MeMenu#Broadcast field The default contents of the field depends on what your last posting was to each of the set up broadcast accounts. - If the last posting was the same to all broadcast accounts (for example, if you have only one broadcast account item set up), the default contents of the field should be the text of that last posting. - In all other cases, the default contents of the field should be nothing. ___ 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] Do You Use Gwibber?
I use Gwibber a lot. One thing I didn't like about the Gwibber integration with the Messaging Menu was how it showed message-specific entries instead of box entries with unread counts like the Evolution integration does. Ken Van Dine recently fixed that and I'm very happy for that. As for the entry in the Messaging Menu, if it had character counting and url shortening I'd be using it a lot more, because it makes sense: I shouldn't need to explicitly open Gwibber to post a message, just like I shouldn't need to explicitly open my contact list just to change my status. I like the idea of the Messaging Menu being an app-independent inbox and the Me Menu being an app-independent outbox. That's why I'd prefer that the evolution compose entry was in the Me Menu. -Original Message- From: frederik.nnaji frederik.nn...@gmail.com To: Ayatana List ayatana@lists.launchpad.net Sent: Mon, Dec 6, 2010 5:59 pm Subject: [Ayatana] Do You Use Gwibber? esteemed readers, Do you use Gwibber? It would be quite gratifying if this thread could produce some statistics or opinions. I'm currently evaluating the role of Gwibber in the Ayatana subsystem. We currently have Mail and IM portrayed by two seperate icons in the panel: 1) the envelope - Mail - Messaging Menu 2) the speech bubble - IM - Me Menu Please respond, if you have the time... I'd welcome opinions, symbolic icons for Gwibber or simply a boolean response ;) ___Mailing list: https://launchpad.net/~ayatanaPost to : ayat...@lists.launchpad.netunsubscribe : https://launchpad.net/~ayatanaMore 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] Launcher' icons size to big
Jason, while we're at this subject, could you please tell if Unity is going to follow the WM_CLASS emergency fallback that Docky currently uses? Since Unity is going to use those big icons, I'm particularly worried whether it will always ensure overriding small icons with large enough ones, even when the window is not directly associated to a .desktop file. -Original Message- From: Jason Smith jason.sm...@canonical.com To: Martín A. Casco martinca...@gmail.com Cc: ayatana ayatana@lists.launchpad.net Sent: Sun, Dec 5, 2010 7:05 pm Subject: Re: [Ayatana] Launcher' icons size to big On Sun, 2010-12-05 at 21:47 -0300, Martín A. Casco wrote: I understand your point. But just an example, since I use Ubuntu (from Hardy), I always used AWN and 32 x 32 pixels for icon's launchers and never have fuzzy problems... Even with Cairo and Docky. I wrote docky, trust me, it happens :) But, if we use 52 x 52 small screens will loose to much space on launcher, and auto-hide can't be the solutions, for many users like me, auto-hide is not used.. Compared to the old launcher you lose an extra 2-4 pixels horizontally. I understand then point about horizontal space. I believe a better hiding mode may be useful for you. I hope to have intellihide ready soon. Even more, with 52 x 52 icon's size, we can't add more apps to the launcher, I know the option arrange icons when we have a lot of apps on launcher or to many apps open, but this option is very unusable, it's look nice, but it's unusably.. 52x52 vs 48x48 makes no difference in terms of number of vertical applications on the launcher in a standard netbook screen. The last once folds a tiny bit sooner is all. I should note the code is completely flexible in icon sizing so we can do resolution independent UI in the future. Bets, El dom, 05-12-2010 a las 18:53 -0500, Jason Smith escribió: There are unfortunate limitations on icon sizing in Linux. We are stuck with 24px, 32px, 48px, and 64px icons. We can interpolate in between, however this will make it fuzzy. Further 32x32 is not a good option since a lot of applications only ship a 24, 48, 64 set of icons. Further, svg's while scalable, do not scale all that well either. What are designed to be 1px lines end up being fractions of pixels, making them fuzzy as well. For the compiz version of Unity it was then decided to use 48x48 icons, with a 2 pixel border in the tile. This represents a growth in tile size from mavericks 48x48 to Natty's 52x52. The icons do *look* a lot bigger though because the icon fills a lot more of the tile now. In reality however, the icons are only 8% bigger. Some of this loss can be made up for by a smaller padding on each side of the launcher. If you look at the launcher in Maverick you will see the icons are fuzzy. Be warned though, once you notice this, you can never un-notice! To be truly scalable, Icon authors need to make svg's, and svg needs a way to denote a line has a fix pixel size. Until this is both possible and completed, we are stuck in the world of fixed icon sizes... or shipping lots of icons. -- Jason Smith | Desktop Experience Team GNOME Developer Canonical USA Inc. T. +1.248.756.6266 | jason.sm...@canonical.com Ubuntu - Linux for human beings | www.ubuntu.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.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
Re: [Ayatana] Handling workspaces in Unity's launcher
2) Even for applications with a single window, I believe cases where users are not interested in such association are frequent. Several users treat workspaces as extra space to be used as needed (Gnome shell for example was designed with that in mind) and not as fixed spaces. I'm not sure I'm following you here. You say it's frequent for users not to want which association? You mean they don't want four workspaces but add and remove them as needed? If that's what you mean, I think Seb's idea addresses that gracefully, offering an easy way to add and remove additional workspaces right on the spot. There are two separate points here. The first one is that sometimes users have no interest in associating an app to a specific workspace, but always want them to appear whenever they are working at the moment. This is usually true for IM and microblog apps. The second point is that if workspaces are treated as being used on demand, then pinning launchers on specific workspaces does not make sense. Seb's idea does not have this problem because he works with the concept of state, he is not pinning launchers but opened applications. 3) The size, and therefore easiness of interaction, of each workspace is proportional to the number of itens inside it. This makes switching to a specific workspace, literally, a moving target. True. I've made a second group of mockups, based on Seb's idea, which I think will solve that problem. Please take a look at them: * http://imgur.com/492ux.png * http://imgur.com/zSlew.png In the first mockup you see the situation with only one workspace: There are no empty workspaces, only the one being used (with firefox and hamster windows) and a second, empty one, which you can click or drag launchers to. When you drag a launcher to that second workspace or navigate to it and open an app (in the second mockup I opened GIMP), a third, empty workspace appears which you can in turn navigate to. Therefore, there is always one empty desktop (plus the ones that are in use). Never more, never less. I think you didn't understand my main concern. I was talking about the area corresponding to each workspaces changing size depending on the number of apps opened or launchers pinned. This means that the user does not have a fixed point in screen to switch to a workspace this way. I think it gives the user a way to add workspaces easily AND use them correctly (i.e. not having empty workspaces just laying around), allows the user to perform an expose only on the current workspace, allows easy reordering of the workspaces and allows keeping an eye of which apps are in the current workspace (making it easier to find them in the sidebar because those on other workspaces don't get in the way). I do think improves the user experience. I can see it if the user's workflow is completely workspace-centric. It it's not, however, the taskbar is trying to do a lot of things at the same time and none of them optimally: - It's not optimal for switching workspaces or switching between applications in the same workspace, because of the moving target problem: the place where you have to click keeps changing. - It's not optimal for switching between applications because two instances of the same application would be separated by workspaces. If the user has a I want to switch to that Firefox window where Gmail is open and not I want to switch to that Firefox window in workspace 4, the separation makes his job harder, not easier. I do agree with the need for workspace-specific expose, 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] Global Menu behaviour
Well, with the solution presented earlier, there would not be that problem, because *all* apps which were not maximized would have their menu below the titlebar, and if you think about it, so would the maximized windows, only it's not just below the titlebar, it's on it. Please do not underestimate the annoyance power of that it's not just below the titlebar, it's on it. It's small, but it still was annoying enough for me to give up on the global menu for the moment. I was almost sold on it because I don't use OpenOffice and I don't use the Firefox menu bar and can hide with with an extension. However, I frequently use Eclipse which is not supported by the global menu yet, and the inconsistency between maximized windows ended up being unbearably annoying. ___ 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] Messaging Menu and the MeMenu
I'd rather have the message just pop up in front of me then have to go through a menu. That is about as close to real life as you can get. Disagreed. In real life, sometimes when someone calls hey, do you have a sec? and you are very focused and want to finish something first, you can turn your head and say just a couple of secs or make a two sign with your hand, or something, without actually interrupting your workflow. A window popping up in front of you would be the equivalent of the person waving the hand in front of you and only stopping when you explicitly shove it away. I think something as intrusive as popups are only acceptable for urgent things like disk running out of space. ___ 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] Global Menu behaviour
Before any kind of conclusions, a survey with long-time OSX users should be made. After all, not only they use a Global Menu all the time, but a lot of them also have huge monitors. Le mercredi 27 octobre 2010 à 17:23 +0200, Oscar RdG a écrit : Hi there, On Wed, Oct 27, 2010 at 5:06 PM, Anzan Hoshin Roshi anzanhoshinro...@gmail.com wrote: On 27 October 2010 10:59, Vincent Moulin cont...@nilux.org wrote: Hi, I am now using Unity and feel confused with how the global menu works. I think both approaches (Global and, erm… Not-Global) have advantages and disavantages, and feel that the best for usability and consistency would be to mix both approaches. Here is a quick and dirty mockup of how I think menus should work : http://dropbox.nilux.org/global-menu.png Feedback/comments appreciated :) I quite agree. I do not agree. I am using the global menu indicator on maverick desktop for a week now, and I love it. I have found out that I do not use very often the app menu so I like it on the panel, far from the window app, even with the small applications (eg. Empathy, Gwibber). Of course, that is just my opinion :) Cheers. ___ 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] [Ayatana-dev] Unity and tooltips
Frederik, I think you are confusing things. Vish didn't say the intention was to eliminate each and every textual information possible, just the tooltips. The bad situation is when an unclear icon tries to solve its unclearness by adding a tooltip. The problem is extra, unnecessary text, not text itself. Some indicators are better being textual, like indicator-datetime. I personally don't see anything wrong with that. -Original Message- From: frederik.nnaji frederik.nn...@gmail.com To: vish v...@ubuntu.com Cc: ayatana-dev ayatana-...@lists.launchpad.net; Ayatana List ayatana@lists.launchpad.net Sent: Thu, Oct 21, 2010 12:26 am Subject: Re: [Ayatana] [Ayatana-dev] Unity and tooltips instead we chose to use symbolic icons?why does the appmenu consist of words still?this is totally inconsistent with the other indicators and makes nosense from a interaction point of view.if we are trying to replace blunt primary school orthography withmetaphors in formal symbolic language, we ought to make one bold stepaway from clinging to vertically stacked text-based menus as thesolution to everything.designing a menu structure in UML might justify the excessive use ofwritten language, yet the goal is to afford unique andsimple-as-possible objects for each interaction possibility.i suggest using symbolic icons for File, Edit and especiallyView in indicator appmenu. ___ 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] [ubuntu-art] Meerkat volume control design
Le jeudi 14 octobre 2010 à 10:50 +0100, Matthew Paul Thomas a écrit : -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dylan McCall wrote on 13/10/10 18:08: ... Right now a regular menu item is used as a title in one place (Rhythmbox), and an action in another (Mute). The font and spacing is identical in both cases. ... It's an action in both cases. ...but represented by a verb in one case and a noun in the other. I think that's what Dylan meant. ___ 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] (In)sensitive menu itens for displaying information
I agree that the effect of the track data item is pretty undiscoverable. I'd love to see suggestions for that. This is more or less one of the points I was trying to make with my original message. Technically, it does not *need* to have an effect, there's nothing wrong with having purely informative things. The problem is fitting this in the everything is a menu item paradigm. The problem with the current setup, in my opinion, is not discoverability, but the fact that the action, even when discovered, is not very useful. It seems there just for the sake of having an action and touches the pattern of showing more details about the information only very lightly. I personally think that a more elegant solution would be merging the app name and track name into a single item. Or maybe showing full information about the track in the app, but not every player supports that. ___ 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] Messaging Menu and the MeMenu
Le vendredi 01 octobre 2010 à 17:55 -0500, Apoorva Sharma a écrit : to get a text box for a broadcast account in the MeMenu, the user has to go to the Messaging Menu to start Gwibber. Not true. The text box will appear if the Gwibber service is running. If the user configures Gwibber to start the service on login (and if I remember correctly this is checked by default), the text field will always be there and work regardless if he clicked on the Gwibber entry in the Messaging Menu or not. to actually use the inactive status buttons in the MeMenu, the user has to start chat from the messaging menu, According to the specification, this is not supposed to happen. https://wiki.ubuntu.com/MeMenu#Instant%20messaging%20statuses Each item should be sensitive whenever at least one of the accounts you have set up in Empathy supports that status, regardless of whether Empathy is currently running. ___ 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 still suggest morphing out the info text field from the bottom of the indicator array.. Replacing the indicators with a notification is also a good idea, but seems to me to be more of a fancy theme for our notification bubbles, the default imo should be near the indicators yet should not obscure them. Remember: the indicator menus are for interaction, this area of the panel is for interaction, the indicators are not only control LEDs to monitor the state of a service.. obscuring a group of special menu buttons would be too obtrusive.. I made a previous point about this, which unfortunately was completely ignored: the indicators are *menus*, which means that interacting with them involves clicking on them and *immediately after* moving the cursor down, thus freeing the notification to reappear. There might be situations when the user has no reason to move the cursor afterwards (ex: he clicked on indicator-datetime just to see the calendar), but in those he also has no strong reason to stand still either. ___ 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
Le mercredi 22 septembre 2010 à 11:01 -0400, Mark Russell a écrit : On 09/22/2010 06:16 AM, frederik.nn...@gmail.com wrote: I think the design of our pretty bubbles is good, implementation not yet complete and i have only one flaw to comment on: Notify only! ATM the bubbles don't only notify, they also relay complete IM messages.. that is an abuse by Empathy, which must be stopped IMO. +1. When people minimize their chat window it's often because they don't want others reading the IMs over their shoulder. The current behavior is precisely what shouldn't happen. This is an interesting point but beyond the scope of this list. The problem exists regardless if the user is using NotifyOSD or the vanilla notification-daemon. It is something to be discussed with the Empathy devs (and Pidgin devs, and Gajim devs, and aMSN devs, and Emesene devs, etc.) ___ 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 think it demonstrates a big pain point for the message indicator, really. So, we get this nice, big message in the panel and then it shrinks down to a menu item inside a little icon surrounded by other little icons. Let's say there are a few different indicators lit up for different reasons, too. There is lots of noise there, and the message which was just given so much importance has been pressed into a tiny corner. We're forcing the user to hunt for something we were just dangling in front of his or her eyes. Not exactly a solution, but it's interesting to remember that the original mockups for NotifyOSD included a subtle minimizing animation which made very evident that the notification went to the messaging menu. http://www.markshuttleworth.com/archives/253 ___ 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
Le samedi 18 septembre 2010 à 16:57 +0200, zekopeko a écrit : IIRC the main problem with that approach is the movement being distracting to the user. It can be argued, however, that such distraction is much lower if the notifications are given in the panel, like the previous mockup proposes. On Sat, Sep 18, 2010 at 4:51 PM, Conscious User consciousu...@aol.com wrote: I think it demonstrates a big pain point for the message indicator, really. So, we get this nice, big message in the panel and then it shrinks down to a menu item inside a little icon surrounded by other little icons. Let's say there are a few different indicators lit up for different reasons, too. There is lots of noise there, and the message which was just given so much importance has been pressed into a tiny corner. We're forcing the user to hunt for something we were just dangling in front of his or her eyes. Not exactly a solution, but it's interesting to remember that the original mockups for NotifyOSD included a subtle minimizing animation which made very evident that the notification went to the messaging menu. http://www.markshuttleworth.com/archives/253 ___ 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 though we already established that notifications are even less important than the least important of the user tasks? That's the only possible justification for them being ethereal. To be more clear, I think this goal is *already* being achieved quite nicely by NotifyOSD *when mouse interaction is involved*. The problem is when one of the two following cases happen: a) The user is typing something in a text field right behind the bubble. Your heuristic works in this case, but it's a little bit of an overkill. I certainly don't mind receiving notifications when I'm writing something completely far away from the bubble area. b) The user wants to just read something covered by the bubble. This is more difficult for your heuristic to cover because he might not be actually interacting at that moment. In fact, in the case of long texts he might not be interacting for several seconds. ___ 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
A notification appears (the mouse cursor is not below the notification). The user is now notified. When they move their mouse to that area (bear in mind that they are 'notified' and have no further use for the graphic) it once again fades away and reappears when the cursor departs. This, irritatingly hangs around for about 5 seconds. I know! I am notified! Why are you hanging about cluttering my screen? Because hovering your mouse over the notification does not necessarily mean that you have already read it. It could also mean that what you wanted to click on was more urgent than reading the notification or that you were already in the process of going there to click something and didn't want to stop (or simply couldn't stop, as a lot of actions we do in the desktop are repetitive and become automatic and lightning quick after a while). At least for me, both of those cases are not rare. In my opinion (unless the notification does something like launching the relevant app or is dismiss-able by clicking on x) it should simply vanish when the user moves their mouse cursor over it. That would probably cause a lot of accidental dismissals. Believe me, I'm the first in line to complain that NotifyOSD is *far* from being perfect, but as you can see it is not exactly trivial to come up with fixes that do not cause other, significative, problems. There are a lot of different cases to consider. ___ 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
Le jeudi 16 septembre 2010 à 13:29 +0100, Luke Benstead a écrit : On 15 September 2010 17:25, Greg K Nicholson g...@gkn.me.uk wrote: On 15 September 2010 16:54, Conscious User consciousu...@aol.com wrote: I know it's the space for the confirmation bubbles, but I think it would be much better if those appeared in another place entirely, like a bottom corner. I've suggested before that synchronous notifications (e.g. volume) should appear horizontally centred. Then the asynchronous notifications (IM etc.) can appear immediately below the top panel, at the right. No-one has come up with any drawback whatsoever to this design —yet ;) -- Greg That's definitely the best solution I've heard yet. Why are we not doing that? Luke. As a matter of fact, because the confirmation bubbles have a fixed size, they can be placed pretty much anywhere with little issues. If I were to guess the reason of the current placement, is that the designers believe that giving the user two different places from which bubbles can come from is confusing. Can someone confirm? ___ 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
Le jeudi 16 septembre 2010 à 16:22 +0100, Michael Jonker a écrit : With specific reference to Unity and the notification: We need to get ready for the touchscreen market. The present logic of the notification is mouse-centric and will need to be overhauled for touch screen. In this situation, the mouse cursor causing the notification to fade will not be available and the notification will simply take up real estate for a length of time the user cannot control. An idea would be placing the notifications in a place dedicated to it, which won't be clicked regardless of the situation. In high resolutions, an excellent candidate is the (currently wasted) space in the middle of the top panel. For low resolutions the problem is a little bit more hairy, methinks... ___ 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 thought the current OSD design was based on the idea that it doesn't matter if you miss one notification. ;-) So what would be wrong if the notification was simply discarded in that case? It collided with a much more important action, so it's only natural that it would yield priority. Like I said, it's not necessarily a much more important action. It could be a very mundane action, but whose movement you couldn't stop by reflex. Furthermore, it is one thing to miss one notification because you were away or not paying attention. It is another, and much more annoying, thing to know *something* has happened and never knowing *what*. IMHO much of those problems are due to the NotifyOSD giving itself too much airs. If it truly accepted its role of being secondary to everything else, and just disappeared when it's unwanted, it would be a lot less intrusive. Actually there's a really simple fix that would solve both your problem and the one of obscuring graphical applications, and it's this: don't ever show a notification while the user is working on something else. The way to detect the user work must be heuristic, but there are some good clues to it: - never show the notification while the user is actively providing input. Typing, moving the cursor, drag gestures. - After heavy user actions (pressing keys, clicking) wait at leas 5 seconds before showing a notification. - If the user is working at a fast pace and the notification remains hidden for this reason for longer than its useful lifetime, simply discard it forever. These small additions would prevent a notification getting in the way. In these cases the user wouldn't have noticed or wanted to read it anyway, so nothing of value is lost. I can be typing very fast... to copy a recipe of cake my grandmother sent me. I can be constantly moving the cursor... to play a flash game. I can be working at a fast pace... because I had one coffee too many, not necessarily because the task is important. I think you are proposing a *very simple* heuristic to guess *very complex* 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] unity and notifications
It always has and still appears to me that the notifications should not be completely ephemeral, or rather, not all notifications should be. Instead there should be a log of some kind where I can look up what happened while I was away. Maybe notifications need to come in various levels of seriousness for this to work, though, because I would indeed not be interested to read a log of a hundred IM status changes. Actually, a lot of this is implemented already. Logging missed notifications that require not-necessarily-immediate response is what the Messaging Menu does. And in Lucid notifications have priority levels. Low priority bubbles are not shown when Totem is playing, for example. ___ 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] The new default wallpaper
Hello, Some of you might be already aware of the controversy caused by the (supposed) new default wallpaper: http://www.omgubuntu.co.uk/2010/08/ubuntu-1010-default-wallpaper.html http://humphreybc.wordpress.com/2010/08/29/the-joke-that-is-mavericks-default-wallpaper/ https://bugs.launchpad.net/ubuntu/+bug/625193 Because no one at the bug report mentioned the problem here, despite being repeatedly recommended by Vish to doing so, I am bringing up the subject. Personally, I must admit I have never seem such a heavy backlash before. It is very common to see people not liking the default wallpaper, but this time there was a substantial number of people that simply did not care at first because they were *absolutely sure* it was just a placeholder. The design team constantly blogs about the new Gtk theme, the Ubuntu font and design decisions. It would be interesting if they could share their thoughts on this controversy and the design process that led to the current decision. ___ 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 new default wallpaper
Backlash? Where? Are we now considering the above mentioned blog as a representative of the whole Ubuntu community? (...) Of course not, when did I say that? I'm comparing the current situation with previous ones about wallpapers that also included blogs, and I'm also considering the size of the bug report. That said, I do admit that the popularity boom of OMG inevitably brings some bias. However, whether it should be considered representative of the Ubuntu community or not is not my main point: I merely wanted to know if the design team had something to share concerning the decision process. Like it happened with the window buttons, once again we have a significative design decision pushed on the brink of the UI freeze, without explanations or even making clear whether it's final or not. This is annoying for documentation people and leaves doubts whether there is a point in having a UI freeze at all. Vish, I agree completely with your comments on the report about the need for objectivity and arguments instead of subjective opinions. But that goes both ways: if there are arguments *in favor* of the wallpaper, why not share them before or at least not very much after it was introduced? This is working very well for the Application Menu and the new font. Isn't Ubuntu a meritocracy? Properly introducing the reasons of something new is necessary to judge its merits. Please, I don't want to turn this into a discussion about OMG. I even reverted the subject title change. ___ 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] OMG!Ubuntu a bane or a boon? [was]Re: The new default wallpaper
And I'm not talking about the articles themselves, I'm talking about the comments since that was the rationale for the bug and the follow-up consolidate! If I'm to mention about the articles, did anyone verify if it was indeed the final wallpaper? It might well be! But, did anyone verify? Alteast before consolidating all the negative comments in one place? I ask this now, because the earlier theme article lead to people questioning the theme changes *here* on the Ayatana mailing list and as we all now know its wasnt the default theme! You guys have a good platform but somehow it gets misused[by others]! There needs to be a sanity check somewhere. Either better fact-checked reporting [obviously people believe what you write] or we disregard those comments as the pulse of the community[until something is actually true]. Vish, do not generalize. There are two reasons why I agreed with you back then but cannot do it now: 1) This time we are not talking about a PPA, but about an official update that came from the official repositories. 2) It is past UI freeze. Like I said in my other email, if we are going to use it has happened before as an argument, then the very concept of UI freeze needs to be rewworked. Being responsible for the Manual team, Benjamin Humphrey for example has every right to feel frustrated when the statement: The user interface must be stabilized at some point, so that documentation writers and translators can work on a fixed target that doesn't obsolete screenshots or documentation. (https://wiki.ubuntu.com/UserInterfaceFreeze) turns out to be untrue in two releases in a row. ___ 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] OMG!Ubuntu a bane or a boon? [was]Re: The new default wallpaper
This reply is still going to the list because it concerns the transparency of the design process as a whole and is not restricted to OMG-related issues. (in my opinion) If you don't agree, it's going to be my last. Can you point to another list which would be more adequate? UIF mention of the documentation writers and translators is the Ubuntu Docs team and the Ubuntu Translators. And not the Ubuntu Manual. And UIFe are granted by those two teams. Is it? Doesn't the Docs team sometimes need screenshots too? Now what are we really worried about ? The UIF or the wallpaper? We must realize we cant have both of those. ;) That's *exactly* my point. The way I see it, there are two possibilities: a) The wallpaper is final. In this case, the concerns *are* valid and your whole point about people complaining before knowing is moot. (there is the problem of rudeness, but this is a separate matter to be discussed separately) b) The wallpaper is not final. In this case, what exactly the users are guilty of? Of trusting the UIF? Of not knowing that the UIF is unreliable, despite the fact that there are no mentions of that in the wiki? Yes, perhaps there was an overreaction, but I wouldn't call trusting the release schedule a lack of responsibility. I don't disagree that the OMG users (and some of its owners) sometimes need a change in attitude. But shifting the entire blame to OMG and not seeing the design transparency problems this hysteria is a symptom of is a mistake. ___ 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] OMG!Ubuntu a bane or a boon? [was]Re: The new default wallpaper
Oops. Only after sending my last message I realized Vish replied only to me. Sorry about that and please ignore 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
Re: [Ayatana] Unity launcher - will an autohide option be available?
I agree with the auto-hide to save screen space, but having it reappear on proximity would be a pain - it shares space with most web pages navigation bar, so it would often get in the middle of browsing. A better option for a hidden bar is the one supported by Firefox Mobile (Fennec). The button bar is placed just outside the visible screen, and it is shown by dragging the screen to the right. This could be implemented in Unity with a finger gesture in multi-touch screens, or by dragging the panel in mouse or single-touch interfaces. There is another option, which seems to be getting popularity with upstream Gnome in the moment: momentum-based autohide. Basically, detecting if the mouse was thrown or simply touched the edged based on its acceleration. ___ 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] Brainstorming the Me Menu again
Hello, So I've been thinking: a big problem with the Me Menu comes from the fact that there is not an universally recognized word for the act of microblogging. There are tweets, dents, and Facebook made the rather poor choice of using status updates (increasing the confusion with IMs) One thing that is universal, though, is how they are displayed: picture on the left, message to the right with the name in bold. So why not take advantage of the familiarity of this layout to make the purpose of the broadcasting field more evident? See the attached mockup. One of the reactions to the mockup will be we don't have the menu item for customizing About Me anymore. Well, quite frankly, it is a Preferences-like item. Isn't those things supposed to be accessed quite rarely after the first setup? The same goes for the two accounts items in the bottom, is it really necessary to keep them there all the time, cluttering the interface? Thinking about that, and considering consistency with the sound indicator and the power indicator, I think it's better to just merge all those things in a Preferences item at the bottom. You will also notice that I added a says: to the broadcasting field. I thought it might be a good way to differentiate broadcasts from IM custom status, which are more like temporary descriptions. But I'm not entirely sure on this one. Thoughts? attachment: mockup.png___ 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] Brainstorming the Me Menu again
I think this does quite a lot for clearing up the purpose of that field. But if you just look at that without prior/external knowledge, you still would have to ask: Say where? To whom? I agree. In fact, seconds after sending the mockup I wondered if it wouldn't confuse users into thinking it was a IM reply field, like the gnome-shell message tray: http://people.gnome.org/~mccann/shell/mockups/20090630/04-chat-details.png As much as I hate to admit it (and God knows how much I do), I don't think that there is a brand-neutral word as effective as that dreadful word, tweet. ___ 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] Brainstorming the Me Menu again
Yes, the broadcast field is certainly a learnable feature in the MeMenu. It will make publishing your current thought to the world very comfortable, i'm sure. But please somebody help me understand why i have a field to publicly log my thoughts next to IM presence status settings, while i can't even inform my contacts about why exactly i do not want to be disturbed right now.. I still don't understand the idea behind this configuration.. The MeMenu always had both broadcasting and custom IM status in the specification: https://wiki.ubuntu.com/MeMenu In fact, you can see that the custom status part is supposed to be quite rich in details. The implementation just needs to be completed, which IIRC is supposed to happen in Maverick. ___ 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] Brainstorming the Me Menu again
I still think it's unclear what that text box does. I made a quick mockup which adds some text to the text boxes, explaining what they are supposed to do. This text goes away when the text box is activated. The social networking text box says Post Twitter message... when the Twitter icon is selected. It should change to whatever social network is selected. When more than one is selected, we are pretty much back to the original problem, unless we do something like concatenate everything (post to Twitter/Identi.ca/Facebook), which sounds kinda heavy. Furthermore, one of the things I currently like the most in the Me Menu is the fact that the text box receives focus automatically when you click on the Me Menu icon. That wouldn't fit your proposal as it would immediately delete the explanation text. A possible adaptation would be deleting it only when the user starts typing, but I have some doubts whether it can be made obvious enough that the text is temporary and not solid. ___ 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 - Review
Actually I was suggesting we *don't* use different icons for the MeMenu title and menu items. While colour would be useful as it's used elsewhere (eg Empathy client) it conflicts with the specific meaning colour has in the menu bar. And using mixed monochromatic/colour icons for the menu's title/items adds another layer of understanding that needs to be learned. Consistency is great. Whoops. My bad. ___ 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] Lack of harmony between panel applets
In due course, similar capabilities will be added. But for the moment it's minimalist. Here's me hoping that those similar capabilities will be implemented in a neat d-bus service way which follows an app-independent protocol, thus closing one of the most common complaints against the current clock, which is being too tied to Evolution. ___ 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 - Review
Le dimanche 27 juin 2010 à 21:59 +0100, Mark Shuttleworth a écrit : On 23/06/10 14:37, Conscious User wrote: If I understood correctly, James was suggesting *keeping* the panel monochromatic but giving colors to the MeMenu items. It makes sense: the colors in this case are not for calling attention, but for helping you to find the desired option faster. ... but whichever option you choose should then be reflected in the menu. I agree, but reflected does not necessarily imply perfectly copied. The colors would be something *extra*, not a contradiction. ___ 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] Lack of harmony between panel applets
New panel applets were introduced to the newer versions of Ubuntu. They improved the experience, because of their features, but they also created some inconsistencies in the GNOME Panel. If I remember correctly, it used to be that only the Menu Bar had associated elements (Applications, Places, and System buttons). With the new Indicator Applet and Indicator Applet Session, some icons on the right end of the top panel behave differently. There is now a lack of harmony, which I described here http://img340.imageshack.us/img340/9033/ayatanapanelissue.png . To fix this issue, we can change the way things are rendered, change their positioning, tweak how they behave, etc. What are your thoughts? This separation is addressed in the fact that they are getting rid of the notification area, moving all icons to the indicator applet. The clock applet has a new version in the works as well. Yes, indicator-datetime is coming, but the death of the notification area depends on larger adoption of libappindicator and this can take a very long time, and several Ubuntu releases. Until it happens, separating the notification area more blatantly, like it's being proposed for Gnome (they are doing experiments with moving non-system icons to the bottom right corner), might be a good idea. If I remember correctly, there was a design principle stating that if things are different, make them very different because small differences look like mistakes. That sounds like the issues Allan is pointing: because the things in the corner *look* like they have similar behavior, it is frustrating for the user discovering that they do *not*. ___ 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 should be Gwibber's behavior when acessed from the messaging menu?
A Twitter client is what I had in mind when I specified that the API should let applications attach a count to the application item itself (...) If there are multiple accounts, then it might show a separate item for each account: (...) It might also have separate items for @replies, direct messages, etc. Nice! Is anyone involved in Gwibber development/integration already aware of this vision? ___ 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 reboot required notification during updates
When you're still upgrading the 'reboot required' notification is already showing up in the session indicator at the right top of the screen. This happens at least during release upgrades. However, rebooting when the system is installing something is not the best idea, so maybe the updater should wait with showing that notification until APT is completely finished, to prevent breakage. Also, is the user already warned when they try to shut down or reboot when software is still being installed or upgraded? I reported this a while ago, but the report seems to be a little bit stuck on figuring out the best solution... https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/548981 ___ 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] Lock Screen / Guest Session / Switch From / Log Out / Suspend / Hibernate / Shut Down
Le samedi 19 juin 2010 à 07:30 -0700, David Hamm a écrit : is it possible to wake from sleep and hibernate after a set time? I don't know about Linux, but if I remember correctly Windows 7 has such feature, so in terms of hardware it seems possible. ___ 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
We'll have to think about that :-) Suggestions? Show the ones that most recently changed status? I think that would introduce an unpredictability factor that a lot of users wouldn't like. Like it happens with the panel, I think we should consider that even without the space problem there is the simple fact that cluttering the indicator area diminishes its usefulness. I've always been a supporter of enforcing a limit on indicators, like the Windows 7 notification area does by throwing the excess icons in a popup (and allowing the user to choose which ones have priority), because trusting application developers to follow common sense simply does not work. For windicators the problem is even worse, so at the risk of someone calling me by the Godwin word, I'd support even flat out *forbidding* more than a certain number via library constraints, not only separating them to a popup. :) ___ 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
erm...Windicator Priorities? I personally prefer not having to choose when there's excess. I'm in favor of not allowing excess, period. ___ 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] Farewell to the notification area
Now, moving on with the discussion itself: Real shortly then: broken but not-yet-replaceable applications needs two things from their indicators: 1. to be able to interact left/right click etc 2. to be able to be seen at all times Instead of keeping the notification area *exactly* as it is or hiding it entirely inside an indicator menu, one possible middle-ground alternative is creating a space for Wine icons that behave the same way as the Windows 7 Notification Area. http://msdn.microsoft.com/en-us/library/aa511448.aspx Gnome/Ubuntu rejected this kind of fine-grained control over the years with the argument that it's better to prevent NA abuse to begin with. The guidelines for using using libappindicator (kinda) prevent this for happening with native apps, but with Windows apps this is impossible to enforce, so perhaps it's more acceptable. ___ 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
With help from Ted Gould of the DX team, I have now (mostly) finished a specification for windicators, with a few examples. https://wiki.ubuntu.com/Ayatana/Windicators Nice work. I don't know if you simply consider this too obvious, but I think there should be a guideline recommending that windicators should be always designed to be optional, in the sense that the application should not be broken if they did not exist. Let's not bring to the title bar the same historical abuse of the notification area. :) ___ 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
So far, these just seem to be menus, but with an optional icon instead of text. So I have to ask: Why don't these belong in the regular application menu bar? guess The windicators will also be able to use the icons to show status, like panel indicators do. /guess ___ 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 to about right-clicking on the indicator-applet?
I had filed a bug report on this issue: https://bugs.edge.launchpad.net/ubuntu/+source/indicator-applet/+bug/519553 I, too, have seen the negative effects of it at this point. It hasn't been as pronounced as my original doomsday prediction, but it is troubling. To be honest I'm not totally happy with Ted's decision on that bug report, so now is definitely a good time to initiate some more chattering. For Maverick, there is time to fix the problem, and I am sure people here can come up with lots of options. Two come to mind for me: We seem to be stuck with Gnome Panel and its quirks for a while yet. So, as a first solution that would magically fix everything (except Bonobo, and the part where applets are positioned with absolute screen coordinates), I think it would be pretty nice if that thing's horrific approach for placing panel applets was revised. I filed an enhancement on just that upstream: https://bugzilla.gnome.org/show_bug.cgi?id=616244 (Strangely it does not seem to be a duplicate). It's fairly simple on paper: instead of always being in a mode where applets can be moved, give the entire panel a toggleable Edit mode. Edit mode could just show handles and the relevant Move / Remove menu items for each applet. The stuff for locking applets to the panel would be completely eradicated in the process. If someone is in edit mode, he probably wants to move whatever panel applets he tells to move. If he isn't, he doesn't want them to move anywhere for any reason. A fancier implementation could capture mouse events over each applet in Edit mode, so a left click anywhere on an applet would then drag it, for example. The notification area _is_ being phased out. Unfortunately it's still there on Maverick desktop… For another solution, maybe the indicator applet could also provide the notification area for this release. It may be possible to embed that exact applet using Bonobo, rather than complicate the very elegant code base. Of course the indicator applet wouldn't need to draw a handle for that notification area, since it's a fixed part of the indicator applet itself. Then the notification area would normally be completely invisible, appearing only when it's in action. Now the indicator applet would be able to draw a handle of its own without feeling self-conscious, and finally do away with that cursed right click menu! One observation: Gnome Shell will have System Status Indicators and the Gnome developers seem to agree that the icons should behave as if they are part of a menu-bar and icons can be clicked with any mouse button but should always perform the same action no matter what button is used. [1] Furthermore, they will do away with panel applets. This implies two things: 1) If Ubuntu and its indicators eventually move to Gnome-Shell, this will most likely become a non-issue. 2) While such moving does not happen, we shouldn't expect much cooperation from Gnome upstream for improving the Gnome 2 panel, as it is not part of their vision for Gnome 3. It will be maintained, but not much focus will be on its improvement. However, good news is that the panel is not being *abandoned* either, as good progress is being made in making it Bonobo-free. [2] [1] http://live.gnome.org/GnomeShell/Design/Guidelines/SystemStatus [2] https://bugzilla.gnome.org/show_bug.cgi?id=572131 ___ 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] Farewell to the notification area
Kristoffer, calm down. This is a brainstorm phase. None of the ideas proposed so far were proposed in the most polished form possible, and there are many other possible ideas to consider. It is a little bit premature to conclude that keeping the notification area exactly as it is for Wine apps is the best solution based on the fact that you didn't like two crude, unpolished suggestions. Nobody ever claimed that those suggestions are the only possible alternatives. It might be that you are absolutely correct and keeping the area is the best way. Who knows? But how to reach this conclusion before a more exhaustive discussion on alternatives? There is no evil conspiracy to break your desktop experience, just a desire to see if there are any improvement possibilities that are being overlooked. Le mercredi 16 juin 2010 à 17:14 +0200, Kristoffer Lundén a écrit : It's the exact right word, since I wasn't talking about functionality. Rocks are functional, but have a broken experience when it comes to building houses, especially if you are used to a hammer. It may not be breaking functionality (actually for icons that indicate status, it does that too since it will be hidden) but it DOES break experience. Regressing to a window in particular would be a horrible experience and totally unacceptable. Cramming it into some kind of drop-down indicator not much better, since a lot of apps communicate via these old indicators. You do realize that moving these indicators to windows or menu in no way unbreaks them, or makes them conform - they will stick out just as sorely, or worse. Sticking them in a menu does not make them behave like the rest of the desktop, so that effort is not accomplishing anything anyway. Just because all top levels are then menus does not mean that the perceived experience is any more coherent - Id argue that it's less coherent because it's unexpected and still does not conform. I understand the initial reaction to try and fit everything into the new menus, but in cases like this, the result just ends up (potentially much) worse and still fool noone that it's one system. If we choose to use Wine or Java, we expect to step outside the blessed sandbox - now let us do that, please. No. Anecdotal, of course, but I know of exactly zero people on Ubuntu that does not run at least Wine to get at least Spotify which relies somewhat heavily on having a systray icon. At work, I also have a Java systray icon from DavMail without which I could not practically use Ubuntu at work (not impossible, just much harder, esp the calendar and Evolution is a crashing joke). Though the DavMail icon would suffer less from being in a menu, it does communicate that it's working etc by changing appearance so it's not nice to hide it in menu or window, even though it's rarely important. The solutions here are, for Spotify: get a Linux client or provide an alternative - native app, plugin to Rhythmbox etc - there's a non-free library and several open efforts. And for DavMail: if it's possible for Java to use the menus in a nice way, bugfiling or even patches. That's two examples that concern me. There's more. Steam, for instance, is a huge thing when it comes to gaming in Wine, since a lot of games do work well. They are rumored to release a Linux client though, and at that point they could probably be petitioned to behave nicely. Just don't break my desktop experience with what I feel is essentially misdirected efforts, doing nothing to make the desktop more usable while also not making it seem more coherent in any way. ___ 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] Farewell to the notification area
A massive portion of Ubuntu users use Wine or Java apps to some degree. If we are trying to improve usability, how would relegating non-application-indicator-conforming apps to floating windows improve a user's experience compared to the current situation of having the (empty most of the time) old style notification area alongside the indicator-applet? I'm all for moving as many apps as possible to application indicators, but I can't see a better solution than leaving the notification area applet there. A Wine indicator applet would be nice, but Windows applications simply listen out for mouse click messages and do whatever they want when they receive them, so it's just not possible to do it in a way that would work consistently. That said, if there was a Windows version of the indicator applet and libraries, we might see some applications move to it - you never know :) How about a middle-ground compromise? Not using a full blown window, but putting the Wine tray icons inside an indicator menu. Horrible mockup attached for illustration. attachment: Capture.png___ 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] Farewell to the notification area
How about a middle-ground compromise? Not using a full blown window, but putting the Wine tray icons inside an indicator menu. Horrible mockup attached for illustration. I thought about that, but AFAIK you can't have right clicking (perhaps also double clicking) inside an indicator menu. Are we talking about an impossible-to-overcome-by-design-gtk-limitation or a workable-around-jumping-through-some-hoops limitation? ___ 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] Farewell to the notification area
Plus, with this mockup, you need an inidicator icon/menu for each class of application that might put things in the notification area? No. Just for the corner cases that cannot use libappindicator and never will, like Wine and Java. Are there any other besides those two? All other classes of applications can simply use libappindicator. ___ 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 should be Gwibber's behavior when acessed from the messaging menu?
But try something different. Try bringing up the normal Gwibber window, with the other messages dimmed and that message not dimmed. Or the normal Gwibber window scrolled to the message in question. The dimming idea is interesting and could be applied to multiple streams if at least one of them contain the post. But what if none of the open streams contain the post? (ex: user received a message from identi.ca, but currently only has some twitter streams open) Kinda corner case, but possible. ___ 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] Ubuntu themes(future)
Le mercredi 09 juin 2010 à 17:44 +0200, dani planas armangue a écrit : I've recently been looking at changes in the art of ubuntu (light themes and new icons) and I think you are doing things wrong. topics you are only basing the color palette rather than usability: -colors to saturate(orange specialy but same the violet) -Buttons of different sizes -progresbars diferent sizes -toolbars diferent sizes etc. .. The results are pretty crappy in my opinion (although this still alpha) On the other hand we were to look at some of the gnome-look themes that have had more success: -Elementary -Equinox. the two themes focus on USABILITY. and this is where we must go in my opinion. we can use the elementary theme changing colors to suit the palette of ubuntu but ended following their guidelines and elements. because they take years to improve this theme, something he have learned. Dani, You should try to be a little bit more objective. Your entire post goes little beyond I don't like it, and this is not really enough to start a productive discussion. You mentioned guidelines and elements of Elementary and Equinox. Which are those, specifically? Why are they better, technically? Where are you drawing the line between personal opinions and facts that would apply to most average users? And not using aggressive words like crappy to characterize the work that nice people put effort into would also help. :) ___ Mailing list: https://launchpad.net/~ayatana Post to : ayatana@lists.launchpad.net Unsubscribe : https://launchpad.net/~ayatana More help : https://help.launchpad.net/ListHelp
