The Latest Wayland Work: Making Libweston

[TheBlackCat]

This seems like a great idea on the surface of things.. I can see certain errors being present in one compositor and not the other, things acting totally differently, etc - but isn't the compositor meant to be fairly simple anyway? Deciding which client gets the input, and pasting all the clients together for the graphical output..

That is not as easy as it appears at first glance (for example Mir's early security problems). And in Wayland the compositor is also the window manager, so it has to handle all the window management functionality as well.

[old486whizz]

This seems like a great idea on the surface of things.. I can see certain errors being present in one compositor and not the other, things acting totally differently, etc - but isn't the compositor meant to be fairly simple anyway? Deciding which client gets the input, and pasting all the clients together for the graphical output..

[MoonMoon]

Yes, but can it minimize windows?

If this is a library to make it easier to write Wayland compositors why should it have functions that handle behavior specific to the compositor? You would have to write that yourself anyways.

[giucam]

This is actually great idea to fairly obvious problem.
No idea how much would clients that currently depend on wayland+weston have to change, but I assume that changes required in other projects (gnome3..) would be minimal or none.

Gnome wouldn't be affected at all, mutter is a standalone compositor.

This is actually great idea to fairly obvious problem.
Wayland (more or less bunch of protocols and interfaces) are 'stable' for quite some time while Weston (reference compositor, currently including most of the codebase) might not suite everyone.
e.g. it would be way easier to create tilling window manager off existing weston code than from 'scratch' using wayland only.

No idea how much would clients that currently depend on wayland+weston have to change, but I assume that changes required in other projects (gnome3..) would be minimal or none.

[uid313]

Minimize windows?

Yes, but can it minimize windows?

[rabcor]

Wayland developers interested in learning more can check out the libweston patch series although the 15 patches have yet to receive widespread comment nor merged into mainline Weston.

I wish I was, I would be really interested in writing my own compositor and developing a bit for libinput for example (For one I have a great idea for a compositor, and a desktop shell, and I'd like to assist with wacom tablet implementation to libinput and Logitech G-series keyboards for my own benefits), but I barely know the basics of C++ so I don't know how to get there learning OpenGL to write a compositor seems like an uncomfortably daunting task according to the rumors I hear and I just have no familiarity with driver programming but suspect they're a bit much for a novice like me.

[giucam]

For XWayland, one of the changes was "libweston-ify XWayland", instead of "adopt for other purposes" should have been adopt for other compositors?

Yes, that change makes the xwayland module usable by other compositors.

[Michael]

Uhm... Michael, you seem a bit confused.

This would be for compositors only, not for wayland clients. (Though a compositor can be a client too, but the client part wouldn't use libweston.)

Not sure what you mean with that XWayland part, XWayland has only one purpose, and this patchset doesn't change that.

Whoops, one of the "clients" meant to write compositors. Typo.

For XWayland, one of the changes was "libweston-ify XWayland", instead of "adopt for other purposes" should have been adopt for other compositors?

[giucam]

Uhm... Michael, you seem a bit confused.

While there's already libinput and other libraries in place for easing the process of writing new Wayland compositors, Giulio Camuffo has proposed forming libweston out of the reference Weston compositor code so that it can be potentially reused by other Wayland clients.

This would be for compositors only, not for wayland clients. (Though a compositor can be a client too, but the client part wouldn't use libweston.)

This libweston could allow potentially using Weston's X11 and DRM back-end APIs by other Wayland clients/compositors, making XWayland easier to adapt for other purposes, etc.

Not sure what you mean with that XWayland part, XWayland has only one purpose, and this patchset doesn't change that.