A few questions and a suggestion for dnd

[Kristian Høgsberg]

On Sun, Nov 14, 2010 at 12:08 PM, Fabian Henze <flyser42 at gmx.de> wrote:
> Hello list,
> I read the wayland documentation in the specs folder of the git repository and
> while I am impressed of the simplicity and elegance of waylands design, a few
> questions came to my mind. I hope they are not too specific for a display
> server in such an early state :-)

No, I appreciate the input.  In fact, at this point, the most useful
feedback is on highlevel architecture issues like what you bring up,
not so much whether or not the demo clients segfault occasionally ;-)

> 1. If the design of the pointer is controlled by the client, how will this be
> consistent among applications? Especially, if the user wants to change the
> system-wide pointer theme? How will clients decide what e.g. the "hand" or
> text-selection pointer looks like?

There has to be a out-of-band theme mechanism that lets applications
agree on a icon/font/cursor/color theme.  In X we have the xsettings
protocol, which provides this, but that's really a workaround for the
fact that applications can't agree on one configuration system.

> If I understood the document correctly, the pointer image is not reset, if the
> pointer leaves a surface.

Yup.

> If so:
> 2. Will all clients have to reset the pointer once they receive motion events?
> Isn't this ineffective? Will the "root surface" (is that what it's called?)
> also have to do this?

Yes, clients have to set the cursor, and no, it's not inefficient.
Wayland doesn't have sub-surfaces that would let you set a pointer per
surface, so clients have to track motion within their surface and
update the cursor accordingly.  For example, if the cursor moves into
a textfield, the client has to set the I-beam cursor etc.  The
consequence of this design is that the server can't know what cursor
to set.  Maybe the last cursor set for a surface was the I-beam
cursor, then the pointer exits and enters from a different edge, where
it enters a menu.  The menu needs the arrow cursor so if the server
was to set the I-beam cursor and the app was slow, we would just see a
brief flash of I-beam, before the app sets it back to the pointer.  A
tiny delay before setting the right cursor is better than setting the
wrong cursor briefly. And typically, there wont be any noticable
delay.

The root surface is handle by the compositor and the compositor will
set the default cursor when the pointer enters the root surface (where
default cursor is up to the compositor).

> 3. What are the minimum requirements to run wayland? Does the system have to
> have a 3D capable GPU? what about virtual GPUs? e.g. cirrus for qemu or
> whatever other emulators use?

All wayland needs is a way to share surfaces.  And there's a shm
mechanisms that uses fd passing,which works on any graphics cards.  So
you could implement wayland with client side all sw rendering (cairo
image backend, for example) and do software compositing on the server
side.  The only requirement in that case is that you can do
modesetting in the compositor.  Wayland could run on /dev/fb, in other
words.

> And finally an idea for the drag and drop mechanism:
> Would it be possible (and desirable) to modify dnd in the following way:
> When the drag starts, the initiator surface creates a new surface, which
> contains just an image of the drag content and is positioned relative to the
> pointer. After the target surface accepted the drag, it gains access to the
> surface and can do whatever animation with it. This would make drag and drop
> visually more appealing.
> I hope you understand what I mean and how this would be useful. If you don't,
> I can try to create a quick mockup using gimp :-).

I think that it may be useful to split the cursor image from the image
being dragged.  The use case I have in mind is where you want to do a
"snap back" animation in case the drop is declined, that is, the
dragged icon slides back to the origin if the source rejects the drop.
 The compositor will have to implement that (it's the only place where
we know where the drag was started and where it was rejected), but in
the current scheme, the compositor doesn't have the dragged icon
without the cursor composited on top.  My concern was that I don't
want lag between the cursor and the drag icon, but the compositor can
ensure that even if the two are not in the same texture, so I think we
can do this.

I'm not sure about passing the image to the drop target though.  It's
easy enough to let the client pass an ID for the buffer that holds the
icon image, and I guess I don't see a problem with that.  I'll have to
try to implement it and see how it works.

Kristian

> P.S.: I found two typos in the documentation: The first one is on page 5, where
> "drag.offer(mime-type1" misses a brace and the second one is on page 8 in 3.1,
> where "fromt" should be "from". Do you care for a patch or do you quickly fix
> this yourself?
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>