protocol questions

[Yichao Yu]

On Wed, Apr 3, 2013 at 12:43 PM, Kristian Høgsberg <hoegsberg at gmail.com>wrote:

> 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.
>

I am talking about real use case, which is the statusnotification protocol.
Why is having a focus not enough for this??


>
> > > 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
> > > >
> > > >
> > >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130403/9b3b8362/attachment-0001.html>