awesomeWM / awesome
Dismiss Join GitHub today GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign up
"Wayland" or Mir support of awesome #159 New issue
Closed zaxebo1 opened this issue Mar 6, 2015 · 23 comments
zaxebo1 commented Mar 6, 2015 Assignees
No one assigned As X will be discarded in a short time by Fedora and Ubuntu etc. GNOME, KDE etc are being directly
compatible with Wayland (or Mir ). Even with e19 release the enlightment window manager also directly Labels supports wayland. enhancement Is there any plan /roadmap for awesome for porting to wayland need info wontfix 3
Projects Elv13 commented Mar 6, 2015 • edited Member None yet
X wont be discarded for at least 15 years. It will be supported as an alternate protocol in Wayland and Mir Milestone just as it is on OS X. No milestone Awesome doesn't have the heavy handed abstraction layers some other WM may have. It is a lean XCB based WM. The Awesome core probably cannot be extended to support Wayland (let alone Mir). A rewrite 10 participants is AFAIK the only viable option. The lua layer could probably be re-used with some changes. There is currently no plan to do that.
Wayland support is going to happen. We built those abstractions,
3
actionless commented Mar 6, 2015 Member
talking about rewriting -- can it be just a lua wrapper for an already existing library like https://github.com/Cloudef/wlc or https://github.com/michaelforney/swc ?
Elv13 commented Mar 6, 2015 Member
MayTODO: [ ] Pixman backend [ ] FB backend [ ] Wayland backend
The FB and PixMap backends would be quite useful, one less layer of abstraction. I guess it will stay a "wait and see" approach for some time (and well, patches welcome).
1
zaxebo1 commented Mar 6, 2015
@Elv13 you are right that X will not discarded in that sense. But once wayland becomes mainstream, then the X apps will run on X; and that X will itself run on XWayland , which will then run on Wayland.
HENCE, X which was running directly on machine, will then run on top of wayland (using XWayland). So, awesomeWM which prides in fast execution , will become inefficient as "awesomeWM->X->XWayland- >Wayland" when compared" with itself as the situation today is just "awesomeWM->X". This four layer situation ( "awesomeWM->X->XWayland->Wayland" ) may or may not make it a CPU hog, but it will definitely make it a laptop battery draining hog compared to today's situation :-(
1 2
zaxebo1 commented Mar 6, 2015
we can not avoid wayland issue, one way or other - it is going to meet us very soon:
Fedora 20 with Wayland preview (post of year 2013) http://www.phoronix.com/scan.php?page=article&item=fedora20_wayland_preview&num=1
roadmap of Wayland and Fedora (post of year 2013) https://lists.fedoraproject.org/pipermail/devel/2013-March/180546.html
Fedora 22 even more emphasis on Wayland (post of year 2015) http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Workstation-22-Features
Elv13 commented Mar 6, 2015 Member
"patches" welcome
zaxebo1 commented Mar 7, 2015
okk :-)
ff2000 commented Mar 16, 2015
AFAIK XWayland is only used when running a legacy X application in a wayland powered environment. So for asesome nothing will change: it will just run directly on X as it did before, no XWayland involved.
zaxebo1 commented Mar 16, 2015
@ff2000 : as of now Awesome window manager uses XCB (X protocol C-language binding), which is client of X11 display server protocol. ==> So yes, awesomeWM is X application ===>So, awesomeWM is a legacy X application in wayland powrred environment ===>So, Xwayland will be involved
ff2000 commented Mar 16, 2015
Awesome is a special application - it's a window manager, so it IS the "environment". wayland is used in the compositor, but awesome DOES NOT composite. For compositing you need special applications like compton (and AFAIK they also don't have a wayland roadmap). It is the WM/compositor who decides if it can run wayland or not. And as long as the login manager is not entirely stupid it won't force wayland on legacy X sessions. XWayland is something the compositor has to deal with - run X applications in an embedded X server.
In short: I really don't see a reason that you should be worried about performance issues because awesome won't run inside XWayland.
blueyed added the enhancement label Mar 17, 2015
aignas commented May 20, 2015 Contributor
Just a thought... would it be possible to use the upcoming libweston , which from what I understand could be used as a compositing library?
Elv13 commented May 20, 2015 Member
Code is code, so I guess with unlimited effort and respect for the laws of physics and economics, everything is possible. It would still take monumental effort and a full rewrite of the C code.
kierun commented Nov 26, 2015
+1 for Wayland support. I would hate to go look for another WM. I can offer some time to test and report bugs if that helps. I'd offer time to code as well but having twins, I have no time to even sleep.
zaxebo1 commented Nov 26, 2015
I'd offer time to code as well but having twins, I have no time to even sleep.
Ha. I can really empathise with you :-D
psychon added wontfix need info labels Feb 10, 2016
psychon closed this Jul 4, 2016
actionless commented Aug 19, 2016 Member
found in the news one more interesting project related to the topic https://github.com/Immington-Industries/way-cooler
6
Elv13 commented Aug 20, 2016 • edited Member
I took a look too. It is based on https://github.com/Cloudef/wlc. If we had to port Awesome, this would be the way to go too. It is a WM core just like Awesome own CAPI. It has most of the base APIs we need to create the CAPI lua interface Awesome awful/wibox/gears depends on. We can steal some of https://github.com/SirCmpwn/sway code to get the wiboxes showing properly. They mostly do that same as us (cairo surfaces + events). The third step is to port Awesome events to libinput (for both X11 and Wayland). After those 3 steps, 80% of Awesome features should work properly in Wayland. It isn't that much work, but I don't have the time or motivation to do it myself for the foreseeable future.
WLC is dead, long live wlroot-rs
1
Timidger commented Apr 14, 2017
Hey, owner of Way Cooler here. Just found this thread.
Although Way Cooler isn't designed to be an exact successor for Awesome on Wayland, we definitely will try to support the same level of customization that Awesome has using a similar mechanism (i.e: Lua).
Most of the work so far has been to make it usable and to use my favourite type of tiling scheme (i3-style), though I have plans to have add a tiling system that works like Lua by defining the placement of windows using user-defined Lua code.
Feel free to make suggestions or pull requests on the project. I'm open to adding any of the features you might want to bring over from Awesome.
3 8 ❤ 7
zaxebo1 commented Apr 14, 2017
@Timidger : saw "Way Cooler" which you referred, just now. Thanks for the link. It seems really a great project, esp as it is written in rust and supports wayland. I hope it as good as i3 and awesome. Is there some quick comparison somewhere?
Timidger commented Apr 14, 2017
@zaxebo1 I don't have any write up comparing them feature by feature, whether planned or not, but here's a quick run down of how I envisioned the influences come from:
The layout is primarily i3-based (e.g, there's a tree consisting of Outputs, Workspaces, Containers, and Views). This was chosen because the awesome layout's can be considered a subset of i3 (it's just a special way to layout the children of a container). This was also chosen because I personally like i3- style tiling more, but I want to incorporate the awesome-style by allowing containers to defer to Lua for tiling Heavy focus on using D-Bus clients to extend the window manager. I know Awesome uses D-Bus, though I'm not sure how it compares to Way Cooler's. In Way Cooler, it's designed so that core functionality, such as the lock screen, notification system, and top bar are all swap-able client programs. For example, we don't currently have a top bar but I envision at least two being made by me: one simpler that uses a static configuration file, and a more dynamic one that will use the Lua thread. I made this design decision because while I like Lua, I found it difficult to use conflicting extensions for Awesome because they didn't play nicely with each other. As well, because many X-utilities no longer work it serves to help replace some of the functionality that is lost. Lua is the main configuration language right now. It has a very tight integration with Way Cooler, being able to do everything a D-Bus client can do (but much faster!) and more (e.g it will eventually be the way clients are given permissions to access D-Bus. You can think of the Lua API exposed by Way Cooler as a super-set of the D-Bus commands we expose). But right now it's serving as a mostly glorified init file that doesn't do much after starting the window manager.This should change in the future, though it's very reliant on what the users want built into it. At the very least I think I will have a way to import a Lua library that can define how the user want's the Lua-controlled top bar to behave, but beyond that I haven't planned for the Lua thread to do anything else during runtime. Really would love user feed-back for what functionality I should implement to make the Lua thread more useful outside of the initialization (e.g timeouts calling functions, or maybe event-based callbacks or something).
This main design is fairly set in stone (though anything can change before 1.0), it's more the specifics that need ironing out. I've been focused on the tiling and other "core" features lately (e.g server-side borders, tabbed/stacked tiling, and other features that the compositor needs to implement), but hopefully I can start working on the customization aspects more (I have some ideas kicking around, like themes defined as yaml files that can be loaded dynamically from Lua)
2
kierun commented Apr 19, 2017
@Timidger Any chance of Way Cooler implementing floating windows? I know, I am a freak using a tilling window manager in floating mode. ☺
kierun commented Apr 19, 2017
@Timidger
Floating windows per workspace
Not enough coffee, I have the dumb, and I cannot brain. Apologies for the noise.
2
Timidger referenced this issue Jul 17, 2017
Add AwesomeWM compatibility #338 Open
charwhee commented Jan 25, 2018
"2018: The Year of Awesome... The goal of 2018 is for Way Cooler to be a fully compatible AwesomeWM clone."
http://way-cooler.org/blog/2017/12/24/way-cooler-2017.html
8 5 ❤ 4
Timidger commented Jan 26, 2018
Yep, that's the goal! Hopefully it's achievable this year.
1 ❤ 9