<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 3, 2013 at 12:43 PM, Kristian Høgsberg <span dir="ltr"><<a href="mailto:hoegsberg@gmail.com" target="_blank">hoegsberg@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Apr 03, 2013 at 12:04:46PM -0400, Yichao Yu wrote:<br> > On Wed, Apr 3, 2013 at 11:16 AM, Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com">hoegsberg@gmail.com</a>>wrote:<br> ><br> > > On Wed, Apr 3, 2013 at 10:59 AM, Yichao Yu <<a href="mailto:yyc1992@gmail.com">yyc1992@gmail.com</a>> wrote:<br> > > ><br> > > ><br> > > ><br> > > > On Wed, Apr 3, 2013 at 12:00 AM, Daniel Stone <<a href="mailto:daniel@fooishbar.org">daniel@fooishbar.org</a>><br> > > wrote:<br> > > >><br> > > >> Hi,<br> > > >><br> > > >> On 3 April 2013 03:09, Kristian Høgsberg <<a href="mailto:hoegsberg@gmail.com">hoegsberg@gmail.com</a>> wrote:<br> > > >> > On Sat, Mar 30, 2013 at 01:31:34AM -0400, Matthias Clasen wrote:<br> > > >> >> - It looks like I can't trigger a popup from a key or touch event,<br> > > >> >> because set_popup requires a serial that corresponds to an implicit<br> > > >> >> pointer grab. That is sad, I like the menu key...<br> > > >> ><br> > > >> > Yes, it looks like we'll need new protocol for that. It's also not<br> > > >> > possible to trigger keyboard move or resize of windows.<br> > > >><br> > > >> Hm, do we really need new protocol for this, or, given that serials<br> > > >> are display-global, can we just bump wl_shell_surface to v2 and note<br> > > >> that v2 and above accept _either_ a key or button press for the serial<br> > > >> argument to set_popup? I don't see any potential for confusion or<br> > > >> getting things wrong, and it saves everyone a lot of really tedious<br> > > >> typing.<br> > > ><br> > > ><br> > > > Why should there be a serial at all? What if the client got some input<br> > > from<br> > > > elsewhere, e.g. popup a warning or sth like that because of a hardware<br> > > > error??<br> > ><br> > > That would just be a regular top-level window or a transient window.<br> > > The popup window type is specifically for popup menus or dropdowns,<br> > > which activate in response to user action and under X grabs mouse and<br> > > keyboard. Under wayland the grab is internal to the server and tied<br> > > to the popup window, but we still an input event serial to make sure<br> > > an application can only pop up a grabbing window in response to a user<br> > > input.<br> > ><br> ><br> > But the client may still want to popup a grabbing window (e.g. system-tray<br> > menu) in response to other event (e.g. dbus event) indirectly caused<br> > (handler in another process) by the user input.<br> <br> </div></div>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></blockquote><div><br></div><div style>I am talking about real use case, which is the statusnotification protocol.</div><div style>Why is having a focus not enough for this??</div> <div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5"><br> > > Kristian<br> > ><br> > > >> >> - The wl_pointer interface seems to be a bit weak wrt to device<br> > > >> >> properties. I would at least expect to learn about the number of<br> > > >> >> buttons and right-handed vs left-handed, etc.<br> > > >> ><br> > > >> > Daniel covered this, though I do think that we should be able to<br> > > >> > determine the set of all buttons supported by all mice and communicate<br> > > >> > to the client if there's a case for that.<br> > > >><br> > > >> Certainly evdev lets you see which buttons are supported by a pointer,<br> > > >> as well as which keys are supported by a keyboard - at least to the<br> > > >> extent that the hardware actually exposes this through HID, which is<br> > > >> even less reliable than EDID. But it's definitely possible to do, and<br> > > >> AFAICT hardware tends to err on the side of exposing too many<br> > > >> capabilities, rather than too few (i.e. you're not going to get an<br> > > >> event for a mouse button we previously claimed not to have).<br> > > >><br> > > >> While we're here though, I'd love to clarify what a value of 1.0 in a<br> > > >> wl_pointer::axis event means. Right now, anything with a wheel will<br> > > >> send 1.0 per wheel click, whereas two-finger scrolling on touchpads<br> > > >> will send 1.0 per pixel. This makes axis events totally unusable for<br> > > >> when you have a mouse and touchpad both: half your scrolls are going<br> > > >> to be wrong. Can we settle on, and document, 1.0 as an arbitrary unit<br> > > >> roughly equivalent to one 'click' of a wheel, and scale appropriately<br> > > >> in the touchpad driver?<br> > > >><br> > > >> And if we're going to stick with evdev BTN_* codes for button events,<br> > > >> we should probably document that one too.<br> > > >><br> > > >> Cheers,<br> > > >> Daniel<br> > > >> _______________________________________________<br> > > >> wayland-devel mailing list<br> > > >> <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a><br> > > >> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a><br> > > ><br> > > ><br> > ><br> </div></div></blockquote></div><br></div></div>