Skip to content
This repository has been archived by the owner on Jan 11, 2020. It is now read-only.

Add AwesomeWM compatibility #338

Open
Timidger opened this issue Jul 17, 2017 · 5 comments
Open

Add AwesomeWM compatibility #338

Timidger opened this issue Jul 17, 2017 · 5 comments
Assignees
Labels

Comments

@Timidger
Copy link
Member

Timidger commented Jul 17, 2017

I've been thinking a lot about the state of the Lua libraries in Way Cooler, and how they compare to AwesomeWM (one of the window managers that Way Cooler was based on). They have a large, well tested, high user base system set up. This is something I can't recreate, certainly not on my own.

However, AwesomeWM doesn't currently have a Wayland equivalent nor is one (as of time of writing) in the works. After talking with the developers, they plan for the Wayland version of AwesomeWM to be in Rust as well. Seeing this as a point of collaboration, I have started working on a library that will allow a compositor written in Rust to add support for using the existing AwesomeWM Lua library as a means to control the compositor.

The library's main focus will be abstracting some of the lower-level details of talking to Lua (e.g having an OO structure) and will provide callbacks to the compositor that they must implement in order to be compliant (e.g, returning the position of the pointer, or drawing to the screen).

It can't be 100% compliant, because it's basically a thin wrapper around xcb, but it should be able to re-create 90% of the functionality.

The rough plan is as follows:

  1. Make the library <In Progress> Making it in house, follow these issues
  2. Integrate into Way Cooler
  3. Deprecate (but do not remove) the current Lua libraries in Way Cooler. Release v0.7
  4. Remove the old Way Cooler Lua integration (Release v0.8). The WM will then be split into two "flavors":
    a) Awesome-style (basically a clone of AwesomeWM in Wayland)
    b) Way Cooler (also known as i3-style) that will be configured using a static configuration file and extended using D-Bus clients.
  5. Assuming Awesome devs want to collaborate on a "true successor" to AwesomeWM, work with them to integrate said library in their compositor.
  6. Assuming 5, remove the AwesomeWM compatibility in Way Cooler, transition totally to a D-Bus focused WM (in terms of extensibility). That means no more Lua in Way Cooler. (Release < 1.0) That would be a separate project entirely, if that ever happens

This has been rolling around in my head for a few weeks, and I think this is the correct approach moving forward. It gives better support for Lua in the short term, can convert more users to using Way Cooler, and gives me a better avenue to pursue making a window manager based on D-Bus in the future.

Hopefully, this should be enough to resolve this awesome issue.

@Timidger Timidger added this to the 0.7 milestone Jul 17, 2017
@Timidger Timidger self-assigned this Jul 17, 2017
@Yamakaky
Copy link

Yamakaky commented Jul 17, 2017

Assuming 6

You mean "assuming 5" ?

@Timidger
Copy link
Member Author

Whoops, yeah I did mean 5. Edited

@Gedweb
Copy link

Gedweb commented Jul 20, 2017

Lua-config is flexible, but provide permanent overhead. I prefer use predefined configuration, like a dconf. And in a conclusion - AwesomeWM config is not a better reference point.

@Timidger
Copy link
Member Author

@Gedweb Way Cooler hasn't ever used static configuration, we've always been using Lua (just our own ad-hoc Lua libraries, not Awesome's).

As mentioned however, we'll be providing a static configuration option in our "i3 flavor" once this change lands and the old Lua lib/thread is removed.

@Timidger
Copy link
Member Author

Just a quick update on the progress of this issue:

For those who followed the development of the library (or those that look it over now) you'll see I'm trying to recreate the awesome source line by line. This has the benefit of being compliant by definition, but a few negatives that have made it too difficult to continue to work on.

  1. Working at such a low level of abstraction means the library was completely unsafe, and I ran into quite a few UB that I attempted to patch as well as I could
  2. Abstracting this to work with any compositor is difficult
  3. Converting the source line by line to both Rust and Wayland is too much effort (even one is asking a lot).

So I have decided to shift tactics a bit, and instead will implement it in a more iterative fashion within Way Cooler.

Going forward I'm going to implement the API exposed by Awesome in Way Cooler, deprecating our APIs anytime there's any overlap (I see the program spawning utilities as a good example of this). As time goes on, more and more of the API will be added with the expectation that you can eventually drop in the default Awesome rc.lua and it should just work. Most of the effort towards the end will going towards making sure that Lua gets xcb type objects, but if that proves to not be viable I will instead try to make it 90% compatible (as in, same API but the return / input types might be slightly different).

All current Way Cooler Lua functions will continue to live behind the way_cooler table and all new additions for AwesomeWM will pollute the namespace as needed (e.g they will not be hidden behind an awesome module/table because that hinders the ability for scripts to work on both Awesome and Way Cooler).

I've already started work on this by upgrading our very outdated hlua integration (which targets Lua 52) with the much more up to date rlua (which targets Lua 53) in #380.

I will add separate issues for each of the Awesome modules that I will add (This is to make it easier for contributors to work on it, if they so wish, and to make it easier to mark the progress). I don't expect to get to all of them by 0.7, but I hope to cover most of the low hanging fruit by then.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

3 participants