Return values in Wayland XML specification

[Pekka Paalanen]

On Mon, 15 May 2017 07:05:26 +0200
Wojciech Kluczka <wojciech.kluczka at gmail.com> wrote:

> In Wayland array can contain only integers.

Hi,

not exactly. The data type inside an array is unspecified by the XML
language. You can use literally anything, it's just a binary blob with
a size, with some array-like helpers around.

The helpers are the ones that impose the most restrictions, which is
that each element in the "array" must be of the same size. But if you
never use wl_arrat_for_each(), even that is not strictly necessary.

Of course, one should use some common sense when defining (in
documentation!) what array contents are. Getting too creative with
array type arguments is probably not good.

> See how listing of outputs is done. Server creates one global `wl_output`
> per output, client binds to the global, server sends events with output
> parameters (list of modes among them) and then event `done` to indicate it
> stopped sending info about this output. You probably don't want one global
> per window. I'd go with one global `window_manager` which sends events (one
> per window) after bind and after creation of window (or on request,
> depending on your needs).

Yes, that is a good design suggestion.

If the events are always sent only as a response to a request, then
there is no need for a 'done' event. The client can send the request
followed by wl_display.sync, and once the sync callback arrives, all
responses have been received.

But, if the server can spontaneously send a series of events, then you
probably need a 'done' for the client to know when the series is
complete again.

On Mon, 15 May 2017 04:05:43 +0100
adlo <adloconwy at gmail.com> wrote:

> For example, getting a list of windows and returning it as an array.
> How would this be done? How are arrays represented in Wayland XML?

The above is one design.

I would perhaps not use an array to list windows, because when you get
to around a thousand simultaneous windows maybe, it's possible you
cannot send the event anymore. There are limits to how big one message
can be.

You also need to update the window list over time, which is much better
done by sending events just for new and removed windows, rather than
sending the whole list every time.

Also, if you need to transmit meta-data for each window, it might be
useful to write a protocol interface for a window, and create a
protocol object to represent each window. When the meta-data changes,
the server can send an event on that protocol object rather than a
tuple { window id, attribute }.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170515/dacb2213/attachment-0001.sig>