wmaker as Weston plug-in shell

[Scott Tablett]

Possible?

https://gitlab.freedesktop.org/wayland/weston/-/blob/master/README.md#libweston

Similar to maynard, but porting WINGs to EFL versus GTK

https://github.com/raspberrypi/maynard

[Andreas Metzler]

On 2023-08-20 Scott Tablett <scott....@gmail.com> wrote:
[...]
> Sipmilar to maynard, but porting WINGs to EFL versus GTK
[...]

Letting a niche-product (wmaker) depend on another niche product
(enlightenment) does not seem to be a good idea to me.

cu Andreas


--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'

[Kostas Michalopoulos]

On 8/20/23 18:50, Scott Tablett wrote:
> Possible?
>
> https://gitlab.freedesktop.org/wayland/weston/-/blob/master/README.md#libweston

I wouldn't rely on any GNOME stuff, they tend to break things and they
even explicitly mention they'll break the API/ABI of the library so
eventually people will have to play catch up to have WM working (to see
why this is not desirable notice how Window Maker had some very long
gaps between releases spanning several years and yet it always worked
just fine because the underlying tech didn't break).

Also i think all non-GNOME, non-KDE Wayland compositors these days rely
on wl_roots which was written explicitly for the purpose (libweston is
made for Weston). I don't know how stable the API is at the moment but
they do seem to have plans on making it stable by the time 1.0 hits
(though in their plans they do not mention if they'll break it again
when 2.0 hits like some libraries like to do these days).

Either way making Window Maker a Wayland compositor is far from a simple
task as it will need first to move all X11 specific code to its own
place (AFAIK Window Maker makes X11 calls all over the place) via a
"window system" layer and then make a wl_roots backend for that layer
(this will also help switch to some other approach in the future in case
wl_roots turns out to not be that great). This will need some research
in order to figure out what the common ground between X11 and Wayland is
in a way that doesn't make the current X11 support worse.

TBH considering that even something as basic as RandR support is broken
right now (try to change the resolution to one that is smaller than your
dock or connect and disconnect a monitor and see how the dock gets
messed up - also keep a backup of your WMState before trying that
because it is not recoverable), adding Wayland support is something i
wouldn't expect anytime soon.

Kostas

[Scott Tablett]

Thanks for reply Andreas,

Runtime/command options?

Existing libraries remain default, with options to use other libraries like EFL

Suggestion is meant as path for wmaker on Wayland/Weston

wmaker uses/depends on X11

Some comparison of X11 and Wayland
https://www.cbtnuggets.com/blog/technology/devops/wayland-vs-xorg-wayland-replace-xorg

I have no development experience, so not sure if wmaker for Wayland needs separate code base

Why EFL?

My suggestion is limited to Elementary toolkit and it's supporting libraries.

Elementary supports Wayland

Elementary has "Complete support for all widgets provided by the toolkit"
https://www.enlightenment.org/about-wayland

Other Elementary references
https://docs.enlightenment.org/stable/elementary/index.html

https://www.enlightenment.org/develop/legacy/program_guide/widgets_pg

It's also theme-able, so current wmaker look can be preserved with effort into theme

Have no idea how stats are compiled, but thought interesting since you mentioned niche,
https://gs.statcounter.com/os-market-share/desktop/worldwide

[Scott Tablett]

Thanks for reply Kostas,

> Also i think all non-GNOME, non-KDE Wayland compositors these days rely
> on wl_roots which was written explicitly for the purpose

I am seeing the same in following description of wl_roots
https://gitlab.freedesktop.org/wlroots/wlroots

Library for creating compositor

Following states "... Window management and the end user experience are often tied to the compositor rather than swappable components..."
https://wayland.freedesktop.org/

I initially thought that a Wayland compositor (like Weston) could be standalone, seperate from window manager.
Now understand a Wayland compositor is a window manager.
https://en.wikipedia.org/wiki/Compositing_window_manager#X11_and_Wayland

It may be that the only way to fully implement wmaker on Wayland is by using wl_roots.

> (libweston is made for Weston)

> I don't know how stable the API is at the moment but
> they do seem to have plans on making it stable by the time 1.0 hits
> (though in their plans they do not mention if they'll break it again
> when 2.0 hits like some libraries like to do these days).

Reading the following on Weston's online documentation,
https://wayland.pages.freedesktop.org/weston/toc/libweston.html

I see your point about stability of API.

The page also states:
Libweston is an effort to separate the re-usable parts of Weston into a library. Libweston provides most of the boring and tedious bits of correctly implementing core Wayland protocols and interfacing with input and output systems, so that people who just want to write a new “Wayland window manager” (WM) or a small desktop environment (DE) can focus on the WM part.

I now understand quotations mean Weston is window manager.

Yet the descripion of "Using libweston" on gitlab states
https://gitlab.freedesktop.org/wayland/weston/-/tree/main?ref_type=heads

ibweston is designed to allow users to use Weston's core - its client support,
backends and renderers - whilst implementing their own user interface, policy,
configuration, and lifecycle. If you would like to implement your own window
manager or desktop environment, we recommend building your project using the
libweston API.

Not sure how to go about assessing whether wmaker behaviour can be fully replicated with Weston window manager via a desktop-shell.
Should be in Weston code and API which take time to understand.
https://gitlab.freedesktop.org/wayland/weston

I suppose looking at code for included Weston desktop-shell is a starting point.

Supposing wmaker behaviour could be fully replicated via desktop -shell, thinking that would be a project separate from wmaker itself.

> Either way making Window Maker a Wayland compositor is far from a simple
> task as it will need first to move all X11 specific code to its own
> place (AFAIK Window Maker makes X11 calls all over the place) via a
> "window system" layer and then make a wl_roots backend for that layer
> (this will also help switch to some other approach in the future in case
> wl_roots turns out to not be that great). This will need some research
> in order to figure out what the common ground between X11 and Wayland is
> in a way that doesn't make the current X11 support worse.

There is Xwayland (X server) and X Window Manger (XWM) which supports X11 clients/applications.
Perhaps common ground between X11 and Wayland are defined in their source.

https://wayland.freedesktop.org/docs/html/ch05.html#sect-X11-Application-Support-xwm

Another representation
https://en.wikipedia.org/wiki/Wayland_(protocol)#/media/File:The_Linux_Graphics_Stack_and_glamor.svg

> TBH considering that even something as basic as RandR support is broken
> right now (try to change the resolution to one that is smaller than your
> dock or connect and disconnect a monitor and see how the dock gets
> messed up - also keep a backup of your WMState before trying that
> because it is not recoverable), adding Wayland support is something i
> wouldn't expect anytime soon.

Thanks for explanation!

Maybe be easier to fix condition with Wayland? :-)

Notes from developer migrating from X11 to Wayland
https://wayfire.org/2019/02/24/X11-WLC-Libweston-Wlroots.html