Who is working on the non-drawing parts?

[Kristian Høgsberg]

On Wed, Nov 24, 2010 at 10:38 AM, Jerome Glisse <j.glisse at gmail.com> wrote:
> On Wed, Nov 24, 2010 at 8:42 AM, Marty Jack <martyj19 at comcast.net> wrote:
>> This is all good that the drawing and input event path is cleaned up.  I am concerned that will be elegant, and the parts that aren't drawing will be tacked on in a poor way.  I would be interested in helping make sure this comes out well.  Having worked on LXDE and a potential follow-on for a few years now, I have come away with a very good understanding of all the existing X mechanism.
>>
>> Maybe this is all understood and I simply haven't found where it is written down.
>>
>> I am interested in what will replace things like
>>
>> - ICCCM/EWMH, where a desktop environment can enumerate and control the display clients
>> - the things that root and application window properties are used for under X
>> - some of the things that selections are used for under X (poor man's system-wide lock manager)
>> - Accessibility knobs ("AccessX features")
>> - Window states (Iconify, deiconify, "I'm a dock", fullscreen, and such)
>
> Up to toolkit, wayland is about compositing buffer and sending input.
> I would advice to leave wayland out of this business and to encourage
> some common platform on freedesktop for window properties valid
> accross toolkits (gtk, qt, ...)

No, this is actually something Wayland has to handle as well.  You
can't just implement these protocols in the toolkit if there's nobody
to talk to.  Wayland combines the display server, the window manager
and the compositor in one process and thus, must provide an
alternative for the functionality provided by these processes and
protocols layered on top of X mechanisms.  This means that the Wayland
protocol ends up being a mix of (the useful pieces of) X protocol,
ICCCM, EWMH, XDnD.

It's not something that's going to be tacked on, it's going to be
directly supported in the protocol.  When you look at ICCCM and EWMH,
they base all the protocols and conventions on atoms, window
properties and selections.  This is the only way it can work, since
the window manager is just another client.  In Wayland the window
manager is the server and it doesn't really make sense to serialize
all this meta data into window properties, when you can just define an
interface that lets you set the data directly.  The Wayland protocol
lets you query for extensions similar to how X works, so we can add,
extend and phase out extensions over time.  So for example, instead of
setting the _NET_WM_VISIBLE_NAME property, there will be a protocol
request that lets you set this meta data.

Right now drag and drop is implemented, I have a good plan for copy
and paste.  Move and resize works similar to the _NET_WM_MOVERESIZE
message. One of the things I'm looking into now is how to translate
the different EWMH window types into Wayland terms.  One of the
challenges in the Wayland protocol is that clients can't specify an
absolute position for their window or query the current location of
the window.  So when showing up a drop-down menu, the application has
to specify surface position relative to the menubar window, for pop-up
menus, relative to the pointer etc.  The current idea is that
surface.map(x, y, w, h) is going to be replaced with a number of map
requests:

  surface.map_toplevel() - show a surface as a toplevel window; the
compositor picks a location.

  surface.map_popup(device, dx, dy, flags) - show a surface as a popup
menu relative to the devices pointer location; flags specify behavior
in case the surface extends beyond screen edges.

  surface.map_overlay(surface, dx, dy) - map a surface with a static
offset relative to a parent surface (drop down menus etc)

  surface.map_fullscreen() - map a surface fullscreen; the compositor
can change resolution to match the surface size if necessary/desired

and possibly others.

There's a lot of ground to cover there, but it's not as daunting as it
may seem.  A lot of the more hairy X protocol is only there to make it
possible to run a window manager or compositor as an X client, and
there a bit of overlap between ICCCM and EMWH.  A great contribution
would be a writeup that provides an overview of the functionality in
the X protocol, ICCCM, EWMH, Xdnd, xsettings specs and then a
classification into "not necessary", "already done", "needs wayland
support", or "can be done over dbus or such".

Kristian