On 2017-01-20 , Yong Bakos wrote: > Across the board, would be nice to have summary attributes where they > are missing.
Will add those for the final patch. Omitted them where they seemed superfluous. > I just noticed that this, and the linux-dmabuf-unstable protocol have > different > copyright notices from the rest of the protocols Wayland source. Not sure if > this matters or not. I just copied this from another protocol, don't recall which. Could have been an old version. > > + wl_surfaces. These surfaces are assigned a size by the compositor > > + (generally understood to be the size of the output) and are rendered > > with > > + a z-depth that corresponds to the layer they are among. > > to the surface_layer type? (This last phrase is a bit cumbersome to > understand.) I should rework this anyway, this revision of the protocol doesn't have the assumption that the size is the size of the output. > > + These flags are a bitfield and are used by set_interactive to > > specify > > + what sorts of input the surface should interact with. > > + </description> > > + <arg name="none" value="0x0" /> > > + <arg name="pointer" value="0x1" /> > > + <arg name="keyboard" value="0x2" /> > > + <arg name="touch" value="0x4" /> > > Hm, what's the use case for a layer_surface to be interactive, but only via > certain > modalities and not others? For example, a layer might provide the ability to bind gestures to commands and only grab touch. A panel might want the pointer but not need the keyboard - note that it would capture all keyboard input if it asked for it. > > + > > + By convention, conventional compositors will send input events to > > + surfaces below the shell surface layer when there are no shell > > surfaces > > + or when the surface is clicked (and thus receives focus). Above the > > + shell surface layer, the topmost surface receives all input of the > > types > > + it requests. > > + </description> > > + <arg name="types" type="uint" summary="mask of input devices to > > use"/> > > + </request> > > + > > + <enum name="anchor"> > > + <description summary="corners to anchor surfaces to"> > > + Specifies the corners and edges of an output that you may anchor > > the > > + surface to. > > + </description> > > + > > + <entry name="top_left" value="1"/> > > + <entry name="top" value="2"/> > > + <entry name="top_right" value="3"/> > > + <entry name="right" value="4"/> > > + <entry name="bottom_right" value="5"/> > > + <entry name="bottom" value="6"/> > > + <entry name="bottom_left" value="7"/> > > + <entry name="left" value="8"/> > > + <entry name="center" value="9"/> > > Consider ordering these to be congruent with some similar entries in > wayland.xml and xdg-shell-unstable. (Despite this, I'm a fan of clockwise from > the top, too.) I'm not sure that would be useful, though I'm not necessarily opposed. -- Drew DeVault -- Drew DeVault _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
