Who is working on the non-drawing parts?

[Marty Jack]

Excellent to hear.  I support an overall model that carries forward the aspects of X that are still helpful and tosses the rest.  Kristian is right, you can't push it to the toolkit.  You need something central that has the client database and can update it race condition free.

I am prepared to sign up to help out.  Give me a few days to understand the protocol spec.  I could come up with the other list very quickly based on what I have already working.

Two things that come to mind immediately that could stand a complete redesign are the situation with multiple monitors and the situation with multiple desktops.  I am sure I will have a few more after I think for a few days.

Right now we have a drastically different way of handling monitors connected to different video cards as opposed to several monitors connected to the same video card.  One is handled by addressing different screens and the other is handled by partitioning the coordinate space on a single screen.  It would be great to have a single model and a single coordinate space that handles everything.

Right now we have two drastically different models of multiple desktops.  One uses the _NET_DESKTOP_NUMBER to assign windows to desktops and one partitions the coordinate space on a single virtual desktop (VIEWPORT and GEOMETRY).  There is a major issue with the single virtual desktop because the reported window coordinates move depending on what the visible part of the virtual desktop is, and you end up having to do headstands and extra round trips to implement the pager.  This could be fixed easily if there were only one definition of the coordinate space.

I notice you are planning on using the keymapping library, which is good, but the keydefinition compiler is another thing that could stand to be reimplemented from a blank sheet of paper.  I will get to that eventually.  I only wrote four production quality compilers, so it should be easy if I get to break compatibility on some parts of the language.

I don't know how well it will go over to fold the window manager in with the server, given how many different models there are for toplevel window layout (tiling, stacking, and such), and people are fervent about the way that they like.  Also, I don't yet fully buy into the part about no client controlled window placement.  We need some way for docks to position themselves appropriately.

On 11/24/2010 12:14 PM, Kristian Høgsberg wrote:
> 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
>