Re: Message Tray design is intrusive

[Giovanni Campagna <scampa giovanni gmail com>]

2013/5/12 Rahul Jain <equites vero gmail com>:
> Hello. This is my first post here as a Shell user. I think the recent design
> of the message tray is very intrusive. Even in Windows 8, I admire their
> utilization of hot corners in a manner that is non-intrusive to the work
> that you are doing. For example, top-right hot corner triggers control icons
> in the side, when you mouse over the icons, they get highlighted, but
> nothing gets activated until you actually specify a mouse click. It does not
> disable your desktop! It does not steal focus from your applications either.
> However, the message tray in Gnome disables your entire desktop.
> Accidentally bringing it up is common also, even with pressure sensitivity.
> And it intrudes upon your work. In a desktop, it is hard to follow your
> mouse and be extremely careful abut it's placement. The Activities corner is
> okay since you don't really work near there. But you have to be extremely
> careful with the mouse, because if you leave it for two seconds to the
> bottom edge, it takes away app focus and disables your desktop completely.
> This design is dysfunctional. You can't expect your users to watch their
> mouse vigilantly every second. I suggest a less intrusive design that does
> not disable your desktop or take away focus at all, the early versions of
> Gnome Shell were MUCH better in respect to the message tray behaviour. I
> would like to hear the opinions of other users also, and if people agree,
> maybe a bug could be filed by someone. Thanks.

Before anything, I should point out that there is also a technical
problem behind this: if you want to move windows up and keep sending
events to them, you need to move them at the X level, which would also
notify all of them of the change, and cause a performance problem
(they would attempt to resize, so you get more ConfigureRequests in
the compositor, it's kind of a vicious circle). To avoid that, we
don't really move windows, we just composite them at the "wrong"
location, and therefore we need to block events.
Maybe when wayland comes (which gives us full input transform in the
compositor), we can revise this decision, but for now, either keeping
windows still or having the tray modal.

Giovanni