<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 12:56 PM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Yichao,<br>
<div class="im"><br>
On 3 April 2013 17:50, Yichao Yu <<a href="mailto:yyc1992@gmail.com">yyc1992@gmail.com</a>> wrote:<br>
> On Wed, Apr 3, 2013 at 12:43 PM, Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com">hoegsberg@gmail.com</a>><br>
> wrote:<br>
</div><div class="im">>> I can't think of anything that does this in any desktop environment<br>
>> I've ever seen.  If as usecase for this comes up we can certainly add<br>
>> it, or any desktop environment can define its own extension to allow<br>
>> this kind of behavior.  But think about it - spontaneously popping up<br>
>> a window that grabs pointer and keyboard input is not a nice thing to<br>
>> do.  Typically a system-tray would pop up a tooltip or a notification<br>
>> bubble, and then maybe you can go click on it to popup a menu.<br>
><br>
> I am talking about real use case, which is the statusnotification protocol.<br>
> Why is having a focus not enough for this??<br>
<br>
</div>I think the point Kristian's trying to make is that the user<br>
interaction is different.  When you launch a popup menu, it grabs all<br>
input, and the user cannot interact with any other application unless<br>
it's dismissed.  Notification windows usually appear and slide away<br>
after a small time, but never exclusively grab input and prevent the<br>
user from interacting with other applications until they're explicitly<br>
dismissed.  If that happened every time I received an email, I<br>
would've smashed my laptop to bits by now.<br>
<br>
Pop-up has a very specific meaning here: it's a menu launched by the<br>
active application in response to user input, which can be dismissed<br>
without penalty either when the user interacts with an element outside<br>
the menu, or, e.g., when the screensaver activates.  Notifications are<br>
not the same thing, because dismissing them can involve some kind of<br>
loss.  If you want a notification that does not capture all input,<br>
then we can work out a surface type for that.  If you really do want a<br>
notification that does capture all input, then it's not a pop-up menu,<br>
it's a modal dialog or similar, as we already have for password<br>
prompts.<br></blockquote><div><br></div><div style>Yes I am talking about menu not notification (sorry the name is status notifier[1] instead of status notification), which is the system tray protocol.</div><div style><br>

</div><div style>Also having to send a serial of the event which triggers the action is really unfriendly to toolkits and all of them may just have to save the last serial globally (as what is done in weston clients now) and use it when sending out the requests, what is the point then of letting the client to save it instead of just saving it in the compositor? And is having a focus really not enough?</div>

<div style><br></div><div style>[1] <a href="http://www.notmart.org/misc/statusnotifieritem/basic-design.html">http://www.notmart.org/misc/statusnotifieritem/basic-design.html</a></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
Cheers,<br>
Daniel<br>
</blockquote></div><br></div></div>