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