Re: Wayland support?
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.
Re: Wayland support?
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
Re: Wayland support?
On 02/17/2015 12:37 PM, BALATON Zoltan wrote: own window manager built in why do you need another one? is that a serious question? You can't be serious to ask why I might want a Model T in blue instead of black? -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
Quoting BALATON Zoltan bala...@eik.bme.hu: Hello, ... 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 Hi, thanks a lot for your reply. I will try to reply you later again, with more info. I have (or I am working on them) different functions (I will upload my current laptop code these days). For example, for titlebar, I have (is only an example): - titlebar_create(): Create the core struct, without WScreen info. - titlebar_destroy(titlebar): Destroy the core struct, if the titlebar is mapped on the screen, unmap it first. - titlebar_map(titlebar, WScreen): Show the titlebar in the WScreen (paint to X11) - titlebar_unmap(titlebar): Hide the titlebar. Really, the WScreen info is used from virtual_screen-WScreen. For example, in my code, the menu core contains the text, the relationship between menus and submenus, but not the decorations. The decorations are painted in the menu_map() function. Move elements between screens could be done using unmap+map. Again, thanks a lot for your reply. Regards, kix Rodolfo García Peñas (kix) http://www.kix.es/ -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Wayland support?
Hello World, The Wayland protocol is actually stable, Wayland has just reached version 1.7.0 and Fedora is going to use it as default in one of their next releases. Does anyone work on Wayland support in Window Maker? Best regards Andreas -- (`-''-/).___..--''`-._ `o_ o ) `-. ( ).`-.__.`) (_Y_.)' ._ ) `._ `. ``-..-' _..`--'_..-_/ /--'_.' .' (il).-'' (li).' ((!.-' Andreas Tscharner a...@vis.ethz.ch ICQ-No. 14356454 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
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. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
On Tue, 17 Feb 2015, Rodolfo García Peñas (kix) wrote: thanks a lot for your reply. I will try to reply you later again, with more info. No need to hurry, I have no time to look at it or work on Window Maker so I could only share my thoughts in the hope it might help. What you propose is probably similar to gtk where there is a creation phase and a realize phase. I'm still wondering if the added complexity of splitting to abstract objects and window system specific ones worth it? What does it bring apart from more complex code? (OK we could be window system independent but I don't think we really need that in a Window Manager for X.) Shouldn't the split be done in the initialization functions instead to make object creation and tying it to a screen separate actions? I mean couldn't the same be achieved by having a way to unmap and disassociate an object from a WScreen and add it to another? Isn't this enough to achieve screen independent objects that could be moved to another screen? Could this be implemented by two new methods on existing objects instead of introducing a new abstraction layer inbetween for everything? Some of this may already exist but probably it's part of creating the objects now so the only think needed would be to split it off into another method. (Although some objects like pixmaps need to be created on a screen so moving them to another screen would mean effectively destroying and recreating them so this independence only makes sense for higher level objects like windows but not for lower level ones like decorations.) Another comment unrelated to this but reminded by your message mentioning WScreen and virtual_screen: I'm also not a big fan of partially renaming functions and breaking any conventions and creating a mess of mixed conventions in the same code. I mean previously the naming convention was similar to OpenStep but being pure C the objects were denoted by their names only: e.g. WScreen for object with object methods named wScreen*. (functions start with lower case while object types start with capital letter). Other funtions not being object methods were usually just named someFunctionName. (This was not always followed but one could more or less tell the idea and intended object separation by looking at the names.) Then someone decided for no good reason other than personal preference that CamelCase is evil and better use underscore names instead like gtk for example. This could be OK if there was a mass renaming and folowing some convention because even in gtk there's a common prefix for all object member functions and names are not just invented randomly. If the renaming has been done object by object keeping some logic to show the object relations it would have been acceptable but what is happening now is that the object oriented design starts to disappear with names becoming a random mix of CamelCase and underscore_separated without following any convention. I have no strong feelings for any of the conventions but I'd prefer to keep some consistency and follow one or the other but not mix them and keeping one convention at least within one object. So unless a whole object is converted to underscore names keeping its naming consistent, it's better to keep the previous naming convention. It also can be considered to keep the CamelCase names for objects and only rename non-object functions to underscore names to have a clear separation of objects and other helper functions or any other sensible approach other than messing up naming by partially renaming some functions while keeping others until noone can see what functions were meant to be members of which objects. Keeping the object oriented design also helps with keeping separation between objects and to know their relations. It makes it simpler to know what is handled by which set of functions and while there is no language support for it in C one can still keep this separation and not mess up by accessing another object's data from a foreign one but use approprite member functions for that. This takes some discipline and is already broken in a few places but it would be better if new patches would keep or fix this design rather than messing it up further. Regards, BALATON Zoltan
Re: Wayland support?
Compatibility with X A screenshot showing xwayland XWayland is an X Server running as a Wayland client, thus capable of displaying native X11 client applications in a Wayland compositor environment.[33] This is similar to the way XQuartz runs X applications in OS X’s native windowing system. The goal of XWayland is to facilitate the transition from X Window System to Wayland environments, providing a way to run unported applications in the meantime. XWayland was mainlined into X.Org Server version 1.16[34] Qt applications can switch between graphical back-ends like X and Wayland at load time with the -platform command-line option.[35] In January 2011, Wayland support was moved into the Lighthouse branch of the upstream Qt repository.[36] Qt Lighthouse is shipped in the Qt 4.8 release.[37] In December 2010, GTK+ added preliminary support for switching back-ends at run time, saying interesting combinations are X11+Wayland or Quartz+X11.[38][39] In January 2011, the GTK+ Wayland backend was updated to support the multiple-backends feature and moved to the gdk-wayland-backend branch of the upstream GTK+ Git repository.[40] In April 2011, the gdk-wayland-backend branch was merged in the GTK+ master branch. On Tue, Feb 17, 2015 at 10:52:16AM +0200, Johann Haarhoff wrote: 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. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
why do I get this feeling that wayland is going to SUCK. Everytime I hear simpler and modern that means it is harder, less lexible and it sucks. KDE and GNOME suck. systemd SUCKS. I mean they suck like you can't fucking use them...and they drag your OS to a halt... and that sucks. Ruben On Tue, Feb 17, 2015 at 10:52:16AM +0200, Johann Haarhoff wrote: 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. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and and extermination camps, but incompatible with living as a free human being. -RI Safir 2013 -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
Re: Wayland support?
XWayland is an X Server running as a Wayland client, thus capable of displaying native X11 client applications in a Wayland compositor environment.[33] This is similar to the way XQuartz runs X applications in OS X’s native windowing system. The goal of XWayland is to facilitate the transition from X Window System to Wayland environments, providing a way to run unported applications in the meantime. XWayland was mainlined into X.Org Server version 1.16[34] My (possibly incorrect) understanding is that XWayland will allow one to run X clients, but they will still be managed by the Wayland Window Manager. For example, I don't think that wmaker will be able to manage Wayland windows when running under XWayland. I would like to hear from someone who knows more though. I am not on the right mailing lists, but I wonder how any of the other guys (i3, dwm, xmonad, blackbox etc.) are approaching the upcoming chaos. -- To unsubscribe, send mail to wmaker-dev-unsubscr...@lists.windowmaker.org.
