protocol questions

[Kristian Høgsberg]

On Wed, Apr 03, 2013 at 12:04:46PM -0400, Yichao Yu wrote:
> On Wed, Apr 3, 2013 at 11:16 AM, Kristian Høgsberg <hoegsberg at gmail.com>wrote:
> 
> > On Wed, Apr 3, 2013 at 10:59 AM, Yichao Yu <yyc1992 at gmail.com> wrote:
> > >
> > >
> > >
> > > On Wed, Apr 3, 2013 at 12:00 AM, Daniel Stone <daniel at fooishbar.org>
> > wrote:
> > >>
> > >> Hi,
> > >>
> > >> On 3 April 2013 03:09, Kristian Høgsberg <hoegsberg at 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.

I can't think of anything that does this in any desktop environment
I've ever seen.  If as usecase for this comes up we can certainly add
it, or any desktop environment can define its own extension to allow
this kind of behavior.  But think about it - spontaneously popping up
a window that grabs pointer and keyboard input is not a nice thing to
do.  Typically a system-tray would pop up a tooltip or a notification
bubble, and then maybe you can go click on it to popup a menu.

> > 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 at lists.freedesktop.org
> > >> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > >
> > >
> >