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.
"""
It will be an very difficult task to integrate wmaker into the same
process as wayland. Also
~/projects/wmaker$ grep -R "\sX" src/ WINGs/ wmlib/ wrlib/ WPrefs.app/ |
grep -iv "binary" | wc -l
4184
There are around ~4000 calls to X11 in wmaker, not a trivial task to
replace them.
Dear Window Maker developers,
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.
Now, I am busy with other projects and I (now) cannot continue with my
wmaker branch (https://github.com/awmaker/awmaker). I will continue in
the future with it, but I would like to share my first impressions
with my fork/branch. These tips could help you to improve wmaker and
include Wayland or non-X11 support.
1. The wmaker uses WScreen struct to handle all objects. WScreen is
X11 realted object. For example, for a window, this is the code. The
code for all objects is the same, a pointer to WScreen:
src/window.h:
177 typedef struct WWindow {
178 struct WWindow *prev; /* window focus list */
179 struct WWindow *next;
180
181 WScreen *screen_ptr; /* pointer to the screen structure */
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.
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. No
support for different window systems (Wayland,...), at least native
support.
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.
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.
wmaker has two different arrays (or lists) one for WSCreens and other
for virtual_screens. When wmaker starts, it binds the previously
created virtual_screens to the real screens (WScreen structs). If
virtual_screens are cero, wmaker is starting, and new virtual_screens
must be created, one per WScreen. But if the virtual_screen array is
not cero (XConfigure event, wmaker restart...), we should bind these
virtual_screens to the WScreens.
We could have the same virtual_screens that WScreens (or more!, or
less!). If more, we have virtual screens hidden, like the workspaces…
But the main tip is, we can restart wmaker, swap the screens, connect
or disconnect screens,... Because the items are painted to the
virtual_screen, we can use the same functions to found the right
position in the screen.
I did a lot of changes to do it. Now the items are created and hidden,
not destroyed. I removed the brother menu in the menu struct,...
OTOH, I split the functions in X11 related code and abstract (no
window system related). To change the code to Wayland, we need rewrite
only the X11 related functions.
I tried to upload the wmaker upstream changes to the awmaker code, to
re-join both projects in the future, so see the differences could be
easy.
The code is there, and this mail tries to explain the main ideas. Feel
free to implement them in wmaker. If you need help, write me or to the
list.
As I said, I will continue with the fork, but I have no time now.
git: https://github.com/awmaker/awmaker
I have more patches in my laptop, but I need time to upload them. I
someone is interested, I could try to upload them soon.
Cheers,
kix
Rodolfo García Peñas (kix)
http://www.kix.es/
--
To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
