On Tue, 17 Feb 2015, Rodolfo García Peñas (kix) wrote:
Johann Haarhoff <joh...@haarhoff.org.za> escribió:

Does anyone work on Wayland support in Window Maker?

I don't think is is possible. From the Wayland FAQ:

How can I replace Wayland's Window Manager

The Wayland architecture integrates the display server, window manager
and compositor into one process. You can think of Wayland as a toolkit
for creating clients and compositors. It is not a specific single
compositor or window manager. If you want a different window manager,
you can write a new one.

I don't know much about Wayland but the immediate question is: Why would you want to do that? If Wayland has it's own window manager built in why do you need another one? It's like support for Windows or OS X. Not needed as those systems have their own window managers and not really support replacing it. This is contrary to X which has no window manager by default and allows and encourages others to implement it. Window Maker is a window manager for X (as stated in the info box) and Wayland aims to be an incompatible replacement of X. So they are not really a good match at first sight.

I think this mail is related to my previous comments about the wmaker abstraction. wmaker could continue running in Wayland, but not natively, using an X11 server for Wayland. wmaker needs X11 to run.

OK, this is a different scenario but if Wayland provides an X11 server then it's no different than running on any other X11 server so why is any modification needed for this case?

2. When wmaker starts, it creates a different WScreen struct for every X11 screen.
3. Using the previous dots (1 and 2):
a. When wmaker is restarted, all items must be destroyed and recreated. Because the WScreen struct is destroyed and re-created.

The screen contains Visuals, GCs, colors, fonts, etc. that are specific to a screen in X11. You need these to draw to a screen. Also an X display can have several screens that are not necessarily using the same visuals so objects created for one screen cannot be easily moved to a different screen without unmapping, recreating everything and mapping it on the new screen. The fact that most displays are supporting 24 or 32 bit depths these days and the only difference are ususally screen size may not make it obvious but this is still true using the X APIs and Window Maker was developed when lower depth screens were common. This might explain some of the limitations. (Also X is a remote display system so some objects might be created in the server so the handle you have for them in the client are not valid on another screen only on the one it was created.)

b. Are not possible make X11 screen changes without restart wmaker. Wmaker doesn’t support screen swapping, screen changes, screen attach and de-attach in laptops… wmaker depends on X11 configuration.

This is not necessarily true, adding new screens should be possible the same way as adding multiple screens is now possible during startup. The only thing needed would be to detect new screens and start managing them when connected the same way as done at startup now. This is not implemented and instead of implementing this correctly now restart is done as a quick and dirty fix in place of proper support for dinamically creating screens at runtime. Disconnecting screens might be problematic though as you need to figure out what to do with objects still using that screen.

No support for different window systems (Wayland,...), at least native support.

Not really a target IMO. Being an X window manager, it is OK to depend on X. Rewriting Window Maker to be a Wayland or other window system window manager is a different target. Especially when those systems have their own window managers and not need any other one.

c. Behaviors using “Xinerama”, “XRandR” and multiple independent screens are different. The windows, the WDock, the Clip,… belongs to an WScreen. The number of WDock, Clips,… is fixed. d. Items position in the WScreen is complex. Every item (Dock, Clip, Menu, Window …) has their own method to display it.

I'm not sure this is because of the WScreen objects and not only because the implementation of these are not sophisticated enough and have some assumptions that don't work well with more complex setups.

What I am doing?:

The method I am using is easy. I split the WScreen struct in two different structs:

WScreen: Hardware related info.
virtual_screen: Non-hardware related info

Items are painted in the virtual_screen, not in the WScreen.

I haven't checked your code but I see a potential problem with this. You need the hardware info to be able to paint on the screen so your objects will be tied to the screen once you display them. At this point there will be no difference between a WScreen and a virtual screen so I don't see what this split brings. Note that you can't easily move objects from one screen to another if they have references to visuals, gcs, fonts, etc. It may work on screens that have the same visuals which might be common now but removing support for more complex setups is breaking previous functionality that's already there and not really correct in X which allows this to exist.

Or maybe I'm missing something because I did not check the code, just talking at a higher design level. But I remember I needed to revert some of your previous changes which seemed OK at first but turned out it broke displays with multiple screens because removing screen references from objects made them display on multiple screens and mix up things like icons attached to one clip showing up on another screen and so on.

Are you sure it's not more complex than you think and you've considered all scenarios and not trying to build on overly simpified assumptions?


Reply via email to