Hello,
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?
Regards,
BALATON Zoltan
