** Description changed: Binary package hint: notify-osd - Currently the notify-osd notifications allot space for the volume - control/brightness semi-notifications; this is rather jarring when the - volume/brightness isn't being adjusted, unlike in Jaunty where - application notifications default to above the volume/brightness. + Currently the notify-osd notifications allot space for the volume control/brightness semi-notifications; this is rather jarring when the volume/brightness isn't being adjusted, unlike in Jaunty where application notifications default to above the volume/brightness. + ------------- + Latest specs in the wiki for *Lucid* , https://wiki.ubuntu.com/NotifyOSD#Work%20for%20Lucid: + + Change in position: The top of any notification bubble should be positioned near the bottom right corner such that if the bubble grows to its maximum height, it is snug at the bottom right corner. Confirmation bubbles should use a slot immediately above that notification bubble slot. + ------------ + The Karmic design was a design decision , any comments relating to the position can be discussed in the ayatana Mailing list or you can follow the discussion > + http://www.mail-archive.com/ayat...@lists.launchpad.net/msg00741.html ------------- - This is a design decision , any comments relating to the position can be discussed in the ayatana Mailing list or you can follow the discussion > - http://www.mail-archive.com/ayat...@lists.launchpad.net/msg00741.html + Any discussions regarding the position need to be discussed in the ayatana mailing list. It is an open list anyone can join and participate. - Any discussion regarding the position need to be discussed in the mailing list. - -------------- + This is a bug report and kindly do not post comments which do not add + any useful information regarding the particular bug. - Mark Shuttleworth's comments from the mailing list: - - "The position is final for 9.10 but can certainly be reconsidered for - Lucid. - - The factors that need to be considered are: - - * fitting things into the corner is most aesthetically pleasing - - * the "synchronous" notifications (like brightness and volume) are - fixed in size - - * the async notifications (IM's etc, things that happen elsewhere, not - in response to a keypress) are variable sized and can grow vertically - - * sliding things around when something else grows is really bad, it is unpredictable and frustrating for a user trying to look at the thing - that suddenly moves, so: - - synchronous should not be below async (so that it does not have to slide down) - - the bottom right corner doesn't work (because then async has to grow "upwards") - - * the top right corner has a lot of stuff there - window decorations, tabs, tab controls (new tab, close tab etc) and in many apps, a search input. So even though the look-through and click-through is *cool*, it's - still better not to put async right into the top right corner - - For 9.10, two positions were considered and tried: - - In both cases, we put sync above and async below, to avoid sliding - problems. We put them on the right hand side of the screen, as that's a - less-used area. - - In the first case, we used the midpoint of the right side of the screen and placed the notifications there, with sync above and async below. It seems slightly odd to have them "hanging in space", but they conflict - with far less content there. This was the plan for 9.10. However, when it landed, there were a lot of complaints saying that folks didn't like it "out of a corner". - - As a compromise, we moved to plan b, which was to put them in the top right, with sync above. That means that the common case, with async notifications, appears to leave a "gap". But it also avoids the worst overlaps with things like window and tab controls, and usually also the - search bar. - - That's where we settled for 9.10. For 10.04 I would like to revisit the midpoint of the right hand side. I would not want to rehash old territory, so please factor in the above in proposing new ideas. I'm of - the view that this decision involves at least one ugly compromise no matter which way it goes, and am happy to make the call so far (i.e. happy to be the one with the thick skin). - - If there is an implementation which avoids the issues and is sane, I'd - love to include it. - - Mark" + Also , To maintain a respectful atmosphere, please follow the code of + conduct - http://www.ubuntu.com/community/conduct/
-- Notifications should show up closer to top right https://bugs.launchpad.net/bugs/438536 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
