Wayland compositor for AwesomeWM

Overview

Way Cooler

Downloads License

Way Cooler is the compositor component of AwesomeWM for Wayland.

Building

To build Way Cooler, ensure you have meson installed (as well as wlroots, or use the subprojects/ directory and build it locally).

Then, execute:

meson build
ninja -C build

To run the compositor simply execute build/way-cooler/way-cooler in a TTY or any existing window manager.

It can run with this patched version of the Awesome client. The simplest way to execute both is to run way-cooler -c </path/to/patched/awesome>.

Though technically they can run standalone, the compositor is not usable by itself and the client will fail out in other compositor due to the custom protocols not being present.

Development

Way Cooler is under active development. If you would like to contribute you can contact me best on IRC (I also hang out on freenode).

Master is not usable for production. There are old versions of Way Cooler that do work, however:

  • Is written in Rust and must be built with cargo.
  • They use an old framework, wlc, and thus are very limited and buggy.
  • Was not designed to emulate Awesome, but instead has i3 tiling and its own (very incomplete) Lua libraries.
Comments
  • The future of wlc

    The future of wlc

    Hey there, I am currently working on fireplace as some of you might now, and I also guess most of you know about sway and track its status as well, because it is the most popular and feature complete compositor build upon wlc.

    Recently sway decided to switch to an in-house compositor and so far there are no guarantees, that their new compositor will be usable completely independently from sway, if it can be dynamically linked and if we may be able to write rust bindings as a direct result of it.

    wlc will of course still exist, but its situation is already complicated, although sway is making use of it as well and maintenance is kept at a bare minimum to keep it functional. I honestly expect this situation to get even worse, once sway has made that transition.

    As a result, I am thinking about switching the compositor library as well for fireplace. Current alternatives I see are:

    • Writing bindings for libweston (it seems quite usable, but more investigation is necessary)
    • Rewriting wlc in rust. Because this is quite the huge undertaking, I would suggest translating the original wlc library with corrode, fixing the result until it can be used as a direct replacement and then gradually re-write parts of it, writing bindings where required on the way and replacing certain libraries with the rust ecosystem.

    I personally don't think wlcs design is overly complicated, it is clearly structured, the biggest difficulty comes from the inherently complex things wlc does.

    That said I am in favor of using libweston (if possible) instead of maintaining another project.

    The reason, I am bringing up this issue here, should be fairly obvious. way-cooler will be influenced by sway's decision as well and I wanted to suggest to join forces on finding and writing a suitable replacement. What do you think?

    opened by Drakulix 37
  • Support Awesome-style tags

    Support Awesome-style tags

    Instead of i3-style workspaces, did you consider using awesome-style tags? I found them much more useful, and workspaces can be "emulated" using tags. It's why I stick to Awesome instead of workspace-based managers.

    opened by Yamakaky 27
  • Only shows blackscreen when I start

    Only shows blackscreen when I start

    However, app seems to be responsive. If I type Alt + Shift + Esc it closes.

    From the docker build I learned I should see a mouse pointer. Is the graphics for that mouse pointer not included in the repos or something like that? sway works on my system and it also makes use of wlc. So I think the error is not on wlc. Ideas?

    Bug 
    opened by vinipsmaker 25
  • Allow colors to contain alpha values

    Allow colors to contain alpha values

    Hi

    This patch will allow ARGB values to be defined:

    • 0xbbggrr - Normal (non-transparent) color (still works)
    • 0xaabbggrr - Transparent color

    That's also the reason I chose ARGB over RGBA - it makes parsing the value very simple. This way, I can just parse the u32, and don't have to look at the original string (eg. the alpha bits are optional).

    Looking at the string would have some advantages however:

    • Distinct between formats like: "0xrgb", "0xrrggbb" and "0xaarrggbb"
    • Allow different parsing methods for different formats

    I think this could be adressed in a later patch, with a notice communicated to the users.

    I've noticed, the colors in the hex value are defined as 0xbbggrr - which is a bit weird - but I didn't want to change it yet, as it breaks backwards-compatibility with old config files (users probably will be confused when their colors suddenly look different). Thus, I haven't changed it. Swapping red and blue in from would easily fix this.

    Thank you all for developing this software, its very fun to use and simple to set up!

    opened by timo-schmid 19
  • Launching way-cooler from X works, but not from tty

    Launching way-cooler from X works, but not from tty

    Hey !

    I installed way-cooler on VoidLinux, and it is working when I launch it from X11, but when I try to launch it from the TTY, it does not work. I have all the INFO about the environment variables but I have a return code of 1 with no explanation.. Any idea ?

    Thank you :)

    Distribution 
    opened by Sh4d1 19
  • client.get()

    client.get()

    Here's one way to do it.

    Set the CompositorHandle in a lua UserData and set it to a named registry value. Now we can get the Server anytime we want it in the awesome code.

    Now the View can have some kind of to_lua() function and we can just put them all in a table and then client.get() will be implemented.

    What do you think?

    opened by acrisci 17
  • Split Compositor and Awesome compatibility up

    Split Compositor and Awesome compatibility up

    In an effort to be compatible with Awesome, Way Cooler removed its threading and message passing that it used in the past to communicate between Lua code and Wayland. In Awesome there's only one thread, and it mostly works out ok.

    However, Wayland is such a different architecture that there have been issues we are running into that make this approach flawed:

    • Lua code can lock up the entire compositor, so nothing is rendered and no input can be processed. This is the biggest flaw by far, and it's something Gnome is also struggling with. To solve this you either need a complicated timeout mechanism or threads/processes.
    • Awesome restarts itself by simply execing itself again. This is fine in X because you are simply another client to the X server and the other clients don't care if you're not there. However, in Wayland the compositor is responsible for the clients and so if it goes down they go down as well.
      • As a side note, Way Cooler historically restarted itself by simply tearing down and reconstructing the Lua interpreter. This is no longer possible due to how Awesome libraries are designed around using glib. You need to tear down the glib loop when you tear down Lua, and you currently you can't do that without tearing down Wayland as well. This can be made to work, but is still fragile because glib (and the bindings to it) seem poorly designed around threading and shared resources anyways.
    • Wayland was designed to be more secure and by allowing arbitrary execution of code within the same context as handles to low level primitives like input devices and DRM handles it makes it even less secure than Awesome in X because you're given a false sense of security. The other clients can't do anything, but Awesome code is essentially a privledged client that is left to run unchecked.
      • To adequately solve this you need to put limitations and changes into the Lua libraries and define a more strict security policy when it comes to what code can be executed. However a necessary first step is separating the trusted "core" code with the untrusted non-core code. This is similar to how modern browsers sandbox plugins by making them escrow their requests via IPC to the browser kernel.
    • Awesome has an amazing test suite. They are able to accomplish this because Awesome itself is just a small client to a more complicated and trusted core. This is much more difficult to test if the compositor and the Lua code are connected. It makes it much more difficult to have a mock compositor to test the Lua code, and mock lua code to test the compositor if they are burned together into the same binary.
      • You could work around this as well, it's not untestable. But if you split them up into two processes you can test them by making a mock of the other and seeing how they communicate back and forth.

    Currently we have just one thread, and that makes working on the Awesome side really easy. We know no compositor code is being ran so we can just use the various objects directly without having to send requests to an escrow. Same thing in the compositor code: we can grab the data we need directly from Lua (e.g. grabbing Cairo surfaces and rendering them). The ease this puts on development is really high.

    However, the limitations it imposes on performance, extensibility, and testing makes it not tenable in the long term.

    Currently Way Cooler already is showing issues not even related to the above:

    1. Startup has a slight lag as the Lua code starts executing
    2. There is a very bad memory leak from somewhere. Like 3 gigabytes in 3 minutes bad.
    3. wlroots-rs and glib weren't designed for thread safety so the original design of having a Lua thread is not very tenable and forced us into this decision of using one thread.
    4. A compositor is very complicated (10k of lines roughly, even with wlroots + Rust). Supporting the Awesome libraries is very complicated as well. These two complex things working in tandem is hard to get right with shared resources. Way Cooler is 4k lines already and doesn't actually do anything.
    5. Working in awesome/ and working in compositor/ already feels like you are working on separate programs so the benifit of having work in awesome/ able to reach across to compositor/ is lost because you need to know the underlying details of both in order to work effectively instead of abstracting it out via message passing. They do very separate, very complicated things, to the point that they should be separate programs.

    I don't forsee this change disrupting the goal of being 1-1 with Awesome, but is something that must be done if Way Cooler can be an acceptable alternative to Awesome. Having your entire computer locked up because you accidentally did one while true end is not fun or secure.

    This will take much more time to develop though. I forsee using a custom wayland protocol for the two halves to communicated and we'd need to have a nice way to serialized the data that's sent back and forth. That will take time away from actually implementing the compositor or awesome interface.

    CCing @psychon and @acrisci since you both have contributed a lot to the two pieces of Way Cooler.

    Meta 
    opened by Timidger 17
  • WIP: Run a Glib main loop (GMainLoop)

    WIP: Run a Glib main loop (GMainLoop)

    GLib provides a default GMainContext (g_main_context_default). Awesome's Lua code accesses this directly through LGI for things, e.g. gears.timer.start_new. However, this only works if a GMainLoop is actually running for the default context. Thus, if way-cooler wants to be compatible with awesome's Lua code, it needs to run a GMainLoop.

    Lua by itself is not thread-safe. Thus, LGI implements locking and automatically locks/unlock stuff at the C/Lua transition. However, LGI cannot detect the Lua->C transition that happens when way-cooler loads the rc.lua and then at the end continues running. Thus, from LGI's point-of-view, it is still in Lua-land and so its mutex is locked. Thus, LGI must be loaded from the same thread that will also run the main loop (since the mutex is recursive; aka can be locked multiple times by the same thread).

    The above considerations resulted in this patch series.

    • The first commit unexports the LUA global so that it can be enforced that only one thread every runs Lua code.
    • The second commit actually changes the API added in the previous commit to switch to the Lua thread. This is a separate commit since I had quite some problems in getting this to work and the resulting code is bad (especially the error handling, aka unwrap())
    • The next commit only happened accidentally, because without it the following commit would not work (the main thread tries to send() to the Lua thread immediately after starting it, but send() does not work yet because RUNNING is still false => panic). This is just a (bad) work-around which a later commit (silently) reverts.
    • Next, Lua initialisation is actually moved to the thread running Lua code.
    • The following commit switches to using GMainLoop. This also reverts the removal of RUNNING and instead removes SENDER (since std::sync::mpsc cannot easily be polled inside a GMainLoop).
    • The last commit happened because I wanted to get rid of the LUA global. It is only accessed from the Lua thread and so I thought I could get away with a a thread_local!. Well... some banging my head against rustc later I gave up and instead "only" moved the LUA global into the only module using it.

    This PR was only lightly tested, mainly by "does require("gears.timer").start_new(function() print("I live!") return true end) work?" and by "is there a deadlock?" (I'm actually surprised by how many deadlocks I encountered along the way and how long it took me to figure out what I just wrote in the second paragraph of this text about "LGI's lock is never unlocked"). Also, the resulting code feels "wrong/bad" to me. I'd be happy for suggestions on how to improve this.

    If you want to, you can merge this (and just commit follow up commits to make the code less ugly (run_with_lua, the introduction of a new (untested) ExecWithLua, ...)). However, I feel bad for even proposing this and am quite unhappy with some of the ugliness lurking in here.

    NOTE: While writing the above it occurred to me: I'm not actually sure if send() is still order-preserving, aka earlier send()s are handled before later ones. I guess it is, but if this might be a problem, please tell me to double-check.

    NOTE: Calling g_source_attach from other threads is actually documented as being safe:

    A GMainContext can only be running in a single thread, but sources can be added to it and removed from it from other threads.

    https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#glib-The-Main-Event-Loop.description

    Edit: Some docs on LGI's mutex: https://github.com/pavouk/lgi/blob/master/docs/guide.md#6-threading-and-synchronization

    opened by psychon 17
  • Implement basic clients method for tag

    Implement basic clients method for tag

    Create a clients method as well as a client initialization mecanism in the tag constructor to allow to set the clients. A downside of this implementation is that clients are stored as values rather than references, so they are not the original Lua values. Small changes were made in the clients file to allow tests while the root API is not finished.

    I am fairly new to rust, so some code may not be optimal, sorry. As said in the commit message, to keep TagState lifetime-free and keep the Tag object in the standard format, clones are stored instead of references. This in turn means that the clients are not the original lua values. If you see a workaround, please let me know, so I can improve the code (and my knowledge).

    Related: https://github.com/way-cooler/way-cooler/issues/394

    opened by AdminXVII 14
  • Don't show view title twice for Tabbed/Stacked borders

    Don't show view title twice for Tabbed/Stacked borders

    This completes #439, to make the Tabbed/Stacked borders behave exactly like they do in i3.

    Now, the titles of views no longer show up twice in Tabbed/Stacked layouts.

    @Arnaz87 visually, is there anything I missed? Combined with #448 and #447 this should make complete the i3-style tiling for Way Cooler.

    Example of what Tabbed and Stacked looks like: proper-i3

    opened by Timidger 14
  • Popup windows should be centered on the screen

    Popup windows should be centered on the screen

    Currently, we just float the windows and don't do anything with their positioning. However, by default this puts them in the top left corner (0, 0). Instead, they should be in the exact center of the screen.

    • Grab the resolution of the screen
    • Find the mid point
    • Subtract by width and height of the view
    • ???
    • Profit
    Bug Regression 
    opened by Timidger 14
  • Add an official Ubuntu PPA

    Add an official Ubuntu PPA

    There are a lot of problems with installing Way Cooler on Ubuntu.

    To remedy this, there should eventually be an officially hosted Ubuntu PPA where we can point users to.

    Distribution 
    opened by Timidger 6
  • Provide a RPM based package

    Provide a RPM based package

    Hi,

    it would be nice if you could provide a package for Fedora / CentOS / etc... Ideally as part of the official repository but a copr or an other custom repo would also be fine. A possible solution could be the openSuse Build Service.

    Meta Distribution 
    opened by Rikorose 7
  • Add AwesomeWM compatibility

    Add AwesomeWM compatibility

    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.

    Meta 
    opened by Timidger 5
  • libinput configuration?

    libinput configuration?

    I wrote the initial libinput config for sway. I don't like writing C and was thinking about contributing similar functionality here so that I can compare the dev experience of Rust and C for a small contribution to an existing OSS project.

    Is this something of interest? Any ideas on how you might want to see it implemented? Seems like you write the core functionality in Rust and then it's exposed with lua for configuration...

    I think it should be straightforward since this also uses wlc like sway.

    opened by colemickens 4
Releases(v0.8.1)
  • v0.8.1(Nov 22, 2018)

  • v0.8.0(Jan 24, 2018)

    Configuration

    • Changed the format for colours in the init.lua file. No longer accepts a number and instead should be a string. This is backwards incompatible.

    Thanks to @timo-schmid for providing the patch for this release.

    Source code(tar.gz)
    Source code(zip)
    way-cooler(28.59 MB)
  • v0.7.0(Dec 24, 2017)

    This is the final release of Way Cooler that will utilize wlc. From this point forward, consider rust-wlc abandoned.

    Way Cooler is switching to wlroots. You can follow the porting process on our wlroots-rs bindings repo. Once those bindings are complete, Way Cooler will switch to wlroots for v0.8.0. Once the move is complete, work will begin again on making Way Cooler function as a drop-in replacement for AwesomeWM.

    To see all changes in this release, consult this milestone listing.

    Distribution

    • NixOS users can now enjoy a much more complete Way Cooler experince thanks to the work done by @gnidorah. (https://github.com/way-cooler/way-cooler/issues/446)
    • Install script from http://way-cooler.org/download now properly sets the uid bit for non-systemd systems. (https://github.com/way-cooler/way-cooler/issues/398)
    • Raspberry Pi's are now officially supported. (https://github.com/way-cooler/way-cooler/issues/369)
    • It is now possible to compile Way Cooler for ArmV7 devices. (https://github.com/way-cooler/way-cooler/issues/445)

    Extension Programs

    Note that all of the extension programs (wc-bg, wc-lock, and wc-grab) have backward incompatible changes in this release. Previous versions will not work as expected!

    Background

    The following changes take effect in this release:

    • The background program binary has been renamed to wc-bg (originally way-cooler-bg).
    • The background program now properly assigns backgrounds to all outputs.
    • A default background is now used when the background program is provided no arguments. Thanks to @platipo for the background contribution! (https://github.com/way-cooler/way-cooler/issues/141)
    • The background program no longer uses a hack in order to render but uses the standard desktop-shell Wayland protocol.
      • As a consequence, you can now use sway-bg on Way Cooler and wc-bg on Sway.

    Lockscreen

    • The lockscreen program no longer uses a hack in order to render but uses a modified version of the desktop-shell protocol.
      • It is modified so that we can lock multiple screens using an effect. This may change in the future, but that means we are non-standard compared to e.g Sway.
    • Added a fancy new blur effect that will blur the screen when it locks. (https://github.com/way-cooler/way-cooler-lock/releases/tag/v0.2.0)

    Screenshot taker

    • Updated to use the latest D-Bus protocol. (https://github.com/way-cooler/way-cooler-grab/releases/tag/v0.3.0)

    Way Cooler

    Configuration

    • Can now choose whether root containers have borders or not. (https://github.com/way-cooler/way-cooler/pull/451)

    Dependencies

    • Moved from hlua to rlua in preparation for AwesomeWM compatibility. (https://github.com/way-cooler/way-cooler/issues/378)
    • Updated wayland-rs to v0.12.0. (https://github.com/way-cooler/way-cooler/pull/452)
      • Fixes build error on some Ubuntu systems. (https://github.com/way-cooler/way-cooler/pull/452)
    • Updated petgraph to v0.4.7 (https://github.com/way-cooler/way-cooler/pull/400)
    • Updated rust-wlc.

    WLC updates

    • Updated to use the latest pointer motion callback. This fixes the rounding bug that would cause the mouse to not perform as expected. (https://github.com/way-cooler/way-cooler/pull/453)
    • Can now copy text from/to pure Wayland and XWayland clients. (https://github.com/way-cooler/way-cooler/issues/328)

    AwesomeWM Compatibility

    • Started preleminary work on AwesomeWM compatibilty. (https://github.com/way-cooler/way-cooler/pull/383, https://github.com/way-cooler/way-cooler/pull/396, https://github.com/way-cooler/way-cooler/pull/429, https://github.com/way-cooler/way-cooler/pull/423)
      • Most of this is setting up the OO and signal systems used by the Lua libraries. This is mostly complete and all that's left is implementing the interfaces.

    Lua

    • Config directory now included in Lua's package.path (https://github.com/way-cooler/way-cooler/pull/352)
    • Defaulting to the pre-compiled configuration fallback now properly cleans up state from the previous Lua instance. (https://github.com/way-cooler/way-cooler/issues/382)

    Tiling

    • Tabbed/Stacked tiling made much more like i3. Special thanks to @Arnaz87 for putting the work in to fix the rendering! (https://github.com/way-cooler/way-cooler/pull/439, https://github.com/way-cooler/way-cooler/pull/450)
    • Floating containers no longer show in Tabbed/Stacked list. (https://github.com/way-cooler/way-cooler/issues/440)
    • Title bar now displayed correctly even when its value is different from the other border sizes. (https://github.com/way-cooler/way-cooler/issues/410)
    • Floating containers are now properly pulled forward again when focused. (https://github.com/way-cooler/way-cooler/pull/432, https://github.com/way-cooler/way-cooler/issues/412)
    • When a floating view is the focused view it is now properly displayed on top of other floating views (https://github.com/way-cooler/way-cooler/issues/415, https://github.com/way-cooler/way-cooler/pull/413)

    Soundness fixes

    • Spawning programs no longer sometimes triggers a segfault. (https://github.com/way-cooler/way-cooler/issues/430)
    Source code(tar.gz)
    Source code(zip)
    way-cooler(31.41 MB)
  • v0.6.2(Aug 15, 2017)

    Lua

    Added the no-op command, this allows the user to register a keybinding but not yet make it do anything. #363

    Tiling bugfixes

    • dmenu will no longer render as too tall #355
    • Scrollbars and other small windows no longer have weird visual artifacts #364
    • All popup windows should now be properly focused on the screen #218

    Distribution

    • The install page on way-cooler.org should function correctly now
    • Binaries are now statically compiled with wlc by default
    Source code(tar.gz)
    Source code(zip)
    way-cooler(24.68 MB)
  • v0.6.1(Jul 30, 2017)

    New features

    This version introduces two new features: The ability to unbind keybindings and to allow passthrough for keybindings. See #345 for more details.

    Changes to existing features

    • Root level containers have always have borders now. #315
    • If XDG_RUNTIME_DIR doesn't exist, an error explaining that is logged. #310

    Bugfixes

    • Screen scraping doesn't scrape active output (needs v0.2 of wc-grab) #349

    • Nested sub containers do not render borders properly when using new container command when a new container can't be spawned (e.g when there's one child) #344

    • Popup windows are no longer sized incorrectly #337

    • Popup windows should now be always centered on the screen correctly #218

    • Switching containers to a new workspace will no longer cause it to be invisible on a workspace that is not active. If it is moved to an inactive workspace, that one is made visible instead #333

    • Floating windows now update their focused colour correctly #320

    • Floating sub windows (e.g right click menus) no longer spawn with borders #319

    • Floating windows (such as dmenu) are no longer hidden when spawned in a tabbed/stacked container #317

    • Nested Tabbed/Stacked borders are now rendered correctly #313

    Source code(tar.gz)
    Source code(zip)
    way-cooler(24.40 MB)
  • v0.6.0(Jun 2, 2017)

    This has been, by far, the biggest release for Way Cooler. I'd lie if I said this was a result of feature creep. There were actually features I removed in favour of a later release (namely #273 and #138) just so I could get this one out of the door.

    Way Cooler has come a long way. If you want to learn more about what has changed please read this release, the linked issues, the up-to-date README, look at our fancy new website, and finally look at the fancy pictures I have attached that I took while developing these features.

    If you'd like to download Way Cooler, the best way is through the download page on the site: http://way-cooler.org/download

    Going forward, more attention is going to be paid to the Lua and D-Bus API. There's going to be some huge changes, but there will be stabilization happening not soon after that in order to encourage the development of client programs for Way Cooler. Once that is done, I will finally get started on writing the last really needed client program for Way Cooler: the top bar.

    Redshift support

    #201 #285 Contrary to popular belief, you can use Wayland with redshift :wink:. Way Cooler now works with a patched version of redshift. To specify for it to work, simply specify redshift -m wayland and it will work just as it did before.

    This is the same way Sway does it, and if you want this to become mainstream I suggest talking to the maintainers of redshift in order to get this merged into upstream.

    Multi-head output

    #297 #64 Finally, finally Way Cooler now supports multiple monitors. It doesn't yet support hotplugging, due to a bug in wlc, however if you start Way Cooler with multiple monitors plugged in they will properly be assigned and used.

    Scrot-like program

    #171 There's a new program in the growing repository for Way Cooler, wc-grab. This is a fairly simple program that emulates scrot somewhat. It takes a screenshot of the current active output and dumps it to a file. By default, it dumps it to screenshot.png, but that can be controlled with the -o flag.

    See wc-grab --help for more information.

    Lockscreen support

    #279 Way Cooler now supports lock screens as of #279. In order to lock the screen, in the Lua file you simply specify which program should be used. When the appropriate keybinding is pressed, Way Cooler locks down and puts the client program front and center. Once the client program closes (either gracefully or not), control is returned to the user.

    I have made wc-lock as a simple implementation of a lock screen for Way Cooler. It uses PAM to authenticate, so once the program is spawned the user simply has to type in their password and hit enter in order to return to the normal operation.

    Basic mode support

    #299 Related to lock screen support, basic modes have been added to Way Cooler. There are three so far:

    1. Default - just like before
    2. Locked - when a lockscreen is active
    3. Custom - Everything runs as in default, but for every wlc callback a custom Lua function can be invoked

    For more information, see the attached issue #299 .

    Tabbed/Stacked tiling support

    #301 #163 Way Cooler now has tabbed/stacked tiling support, just like i3/sway does. This is the last i3-related feature that is plan to be added. If more would like to be added, I suggest either sending a patch or letting your voice heard why a certain feature should be ported as well.

    Container borders

    Related to tabbed/stacked tiling, nested containers now have borders drawn around them, making it much easier to see where nested containers are without guessing from the way the windows are laid out.

    Bug fixes

    • Can no longer remove root container in workspaces #280
    • Fixed duplicate active number crash #276
    • Background now uses output geometry #291
    • Fixed issues when gaps were enabled #289
    Source code(tar.gz)
    Source code(zip)
    tabbed_borders_work.png(502.98 KB)
    testing-way-cooler-install.png(452.10 KB)
    way-cooler(22.88 MB)
    way-cooler-scrot.png(565.28 KB)
  • v0.5.2(Mar 17, 2017)

    Resizing

    • There is now an option to select the behaviour of the mouse when resizing (e.g, snap to the window like in Awesome, or don't snap anywhere like in i3). See the updated default configuration for more information. #269
      • This added a new configuration category, mouse. This will be expanded later to provide more options for the mouse, including libinput configuration once #189 is addressed.

    Borders

    • Title bars will now update their text to reflect the title of the window #270
    • Gaps and borders can now be used at the same time #263
    • Active border color should now work better (e.g less times when two are highlighted active, or when none of them are even though the user is focused on a window) #263

    Windows

    • Popup windows now attempt to focus in the center of the screen, and are never too small than the minimum floating window limit. #264
      • Note that due to limitations in Xwayland, they may not always have their geometry properly set, so they may still sometimes appear in the top left corner.
    • Way Cooler now remembers which view you focused on within in a container. In other words, the algorithm to select the last active window is now one-to-one with i3. #204

    Bug Fixes

    Sending containers across workspaces will no longer cause a duplicate active number (and a crash) #267

    Source code(tar.gz)
    Source code(zip)
    way-cooler(17.65 MB)
  • v0.5.1(Feb 26, 2017)

    Bug Fixes

    • Fixed race condition that caused tree instability (e.g a crash)
      • This was normally triggered by closing e.g mpv with the close window command.

    Configuration

    Backwards incompatible changes

    • Cleaned up util functions
    • Removed spawn_dmenu and spawn_terminal command, please use util.program.spawn_once instead.
    Source code(tar.gz)
    Source code(zip)
  • v.5.0(Feb 21, 2017)

    This release expands the graphical capabilities of Way Cooler, adding core features such as borders and bar support while also paving the way for more advanced features such as notifications.

    This is also the first release with a binary attached. It is an x86_64 ready-to-run version of Way Cooler statically linked to the latest wlc release (0.0.8).

    New Configuration format

    • The configuration format has changed significantly. This is a backward incompatible change. Please see the example configuration for more information.
    • In short, values must now be part of a category (e.g, no longer border_size it's way_cooler.windows = { borders = { size = 20 } }, for example).
    • config object has been merged into way_cooler.

    X11 Bar support

    • Added support for X11 bars, such as polybar and lemonbar
    • To enable, set the x11_bar variable under the programs category to the name of the window that the bar spawns (e.g, bar when running lemonbar as lemonbar -n "bar"
    • Support for more integrated bars will come in a later version.

    Borders

    • Added compositor/server side borders.
    • Size and active/inactive color configurable through configuration option.
      • Color specified as a hexadecimal number
    • Title bars are also independently configurable, e.g they have their own size and colors.

    Gaps

    • Added gap support between windows. You can think of these as transparent borders.

    D-Bus

    • Commands now block when locking the layout tree. This means that commands should fail much less often especially when in a tight loop.
    • Added ActiveWorkspace command to get the name of the current workspace.

    Bug Fixes

    • Context menus should stop disappearing/crashing the program.
      • Note that they may not be positioned correctly, this will be fixed in a later patch.
    • Floating windows will now properly become fullscreen.
    • Defaulting to the pre-compiled configuration file is now much more obvious in the log.
    • Floating windows should now no longer snap back to their position.
    • Lua thread listener should now no longer die when restarting and having a bad config.
    • Floating a window in a sub container should no longer cause a crash.
    • The background should now resize when the output changes resolution.
    Source code(tar.gz)
    Source code(zip)
    way-cooler(16.44 MB)
  • v0.4.2(Jan 9, 2017)

    Commands / Keybindings

    • Added fullscreen command
      • Default keybinding is mod+f
      • Command is also exposed through the D-Bus command FullScreen
    • Added commands to control the location of the pointer.
      • Absolute positioning (SetPointerPos)
      • Placing the mouse at the corner of a container (GrabAtCorner)
    • Modifier for mouse controls (eg resize and move window) is now configurable
      • The default modifier is now Alt, instead of the previous Ctrl

    Tiling

    • Popup windows now automatically are floating.
    • Wayland apps (eg termite, weston-terminal, etc) should no longer have blurry text.
    • Resizing a window while running Way Cooler from a TTY now works correctly.

    Logging

    • Way Cooler now log all environment variables in the prelude of the log.
    • When a key is bound to a command that is now logged.

    Background

    • Resizing the output / changing the resolution will now properly update the background.

    Misc

    • Already existing debug checks have been turned on for release builds.
    • Restart should properly call the user-defined restart callback now.
    • Updated to use the StableGraph of Petgraph, which should improve performance and reliability.
    Source code(tar.gz)
    Source code(zip)
  • v0.4.1(Jan 2, 2017)

    Configuration

    • Can now restart Way Cooler in place. Will restart the background program (if any), and reload all keybindings and other options.

    Tiling

    • Can now open a new window even if there is no currently active container
    • Closing a window now uses the "recently used" path to focus on the next window
    • Popup windows will now stay on their workspaces and not otherwise do weird things (mostly)
    • Floating windows are now always rendered above tiled windows
    • Floating an empty workspace no longer causes Way Cooler to hang

    Logistics

    • Way Cooler can now be compiled statically with wlc
    • Basic binary distribution. Currently only x86_64, will later have i686 and armv6 here as well. To install, unpack the tar file and run install.sh
    • Added a login manager entry for Way Cooler (confirmed to work on light-dm and gdm)

    Background

    • way-cooler-bg no longer needs to have a cursor file specified.
    Source code(tar.gz)
    Source code(zip)
    way-cooler-x86_64.gz(1.66 MB)
  • v0.4.0(Nov 25, 2016)

    Major Highlights

    • Switched IPC to D-Bus
      • To run in a TTY session, need to start Way Cooler with dbus-launch --exit-with-session way-cooler
    • Removed background program, it is now a separate project
      • Added support for images, including png, jpg, and gif formats.
      • Fixed issue where the cursor could not be loaded on some distros (such as Ubuntu). We now package a backup cursor icon.

    Tiling/Layout

    • Can now resize windows
      • When resizing tiled windows, it is ensured that you can not make them size 0.
      • Resize with ctrl+<right-click> and drag.
    • Can now make windows floating with Alt+Shift+Space
      • Switch between floating and non-floating with Alt+Space
    • Way Cooler now remembers what window you last had focused, using a clever "path" system to keep track of active paths.
    • Fixed problem where the active path was not being updated properly when switching workspaces
    • Reduced the number of debug print statements.

    Init file

    • Added special function way_cooler_init. This function will be triggered after Way Cooler has completed initialization. It is where all start up programs should go, and ultimately will be a nice place to hand out tokens when we implement security levels to the IPC.
    Source code(tar.gz)
    Source code(zip)
  • v0.3.2(Aug 27, 2016)

    This branch is mostly a couple of bugfixes and a couple of layout additions.

    New Features

    • --version flag
    • windows can be moved between containers
    • New keybindings in int file - Alt+Shift+<arrow key> to move window between containers

    Bugfixes

    • Issues with key bindings sometimes not working
    • Tiling losing focus when dmenu was closed
    • WIndows with close prompts not being closable
    • Switching to current workspace turning wndows invisible
    Source code(tar.gz)
    Source code(zip)
    init.lua(3.51 KB)
Owner
Way Cooler
Development of the Way Cooler window manager and extensions
Way Cooler
Easy c̵̰͠r̵̛̠ö̴̪s̶̩̒s̵̭̀-t̶̲͝h̶̯̚r̵̺͐e̷̖̽ḁ̴̍d̶̖̔ ȓ̵͙ė̶͎ḟ̴͙e̸̖͛r̶̖͗ë̶̱́ṉ̵̒ĉ̷̥e̷͚̍ s̷̹͌h̷̲̉a̵̭͋r̷̫̊ḭ̵̊n̷̬͂g̵̦̃ f̶̻̊ơ̵̜ṟ̸̈́ R̵̞̋ù̵̺s̷̖̅ţ̸͗!̸̼͋

Rust S̵̓i̸̓n̵̉ I̴n̴f̶e̸r̵n̷a̴l mutability! Howdy, friendly Rust developer! Ever had a value get m̵̯̅ð̶͊v̴̮̾ê̴̼͘d away right under your nose just when

null 294 Dec 23, 2022
Steno for Wayland

WayPlover Steno for Wayland Description A Steno Stroke Interpreter for Wayland. Open Steno Project Learn Plover Usage wayplover --port /dev/ttyACM0 --

Travis Davis 9 Oct 23, 2022
A wallpaper daemon for Wayland compositors

Paper A wallpaper daemon for Wayland compositors implementing the layer-shell protocol. Features Supports png and jpg format Tiled wallpapers Bordered

snakedye 20 Nov 26, 2022
`xrandr` for Gnome/wayland, on distros that don't support `wlr-randr`

gnome-randr-rust A reimplementation of xrandr for Gnome on Wayland, especially for systems that don't support wlr-output-management-unstable-v1 (e.g.

Max Ainatchi 40 Dec 21, 2022
Turn off monitors to save power (for Wayland)

Same as xset dpms force off, but for Wayland. It requires zwlr_output_power_manager_v1 and org_kde_kwin_idle support from the Wayland compositer. wlro

依云 15 Dec 8, 2022
Dynamic key remapper for X11 and Wayland

???????????? ⌨️ xremap is a key remapper for Linux. Unlike xmodmap, it supports app-specific remapping and Wayland. Concept Fast - Xremap is written i

Takashi Kokubun 643 Jan 8, 2023
Wallpaper daemon for Wayland

wpaperd wpaperd is a minimal wallpaper daemon for Wayland. It allows the user to choose a different image for each output (aka for each monitor) just

Danilo Spinella 53 Dec 28, 2022
Default implementation of the Wayland protocol for use with wl

Wayland An implementation of core Wayland interfaces and convenience functions for accelerating the development of Wayland clients and servers using t

AidoP 1 Jan 24, 2022
A simple program that provides DBus interface to control display temperature and brightness under wayland without flickering

wl-gammarelay-rs Like wl-gammarelay, but written in rust, runs on a single thread, has three times less SLOC and uses DBus (for simplicity). Dbus inte

Max Verevkin 33 Nov 23, 2022
A simple clipboard manager for wayland.

Wpilman A simple clipboard manager for wayland. Installation Just compile it yourself or install the AUR package: paru -S wlipman-git # or yay -S wlip

null 3 Jan 13, 2023
Wayland clipboard manager that will make you clap 👏

Clapboard - clipboard manager that makes you clap ?? Clapboard is a simple clipboard manager for Wayland, built in Rust. It saves a history of your cl

Yo'av Moshe 18 Jan 28, 2023
A wayland native, highly customizable runner.

anyrun A wayland native krunner-like runner, made with customizability in mind. Features Style customizability with GTK+ CSS More info in Styling Can

null 18 Jan 22, 2023
A launcher/menu program written in Rust for wlroots-based Wayland compositors

tehda tehda (ᴛᴀʏ-dah /ˈteɪ̯.dæ/ or /teh.da/; Finnish for "to do, perform, execute") is a launcher/menu program, like dmenu, rofi, or wofi, written in

Nadia 4 Jan 29, 2023
Minimal, flexible & user-friendly X and Wayland tiling window manager with rust

SSWM Minimal, flexible & user-friendly X and Wayland tiling window manager but with rust. Feel free to open issues and make pull requests. [Overview]

Linus Walker 19 Aug 28, 2023
Swayidle alternative to handle wayland idle notifications, sleep and lock events in Rust with Lua scripting based configuration language

swayidle-rs This is intended as a replacement of sway's idle management daemon. I use it as a tool to understand rust message passing and state manage

Reza Jelveh 8 Nov 27, 2023
xdotool-like for KDE Wayland

kdotool - a xdotool clone for KDE Wayland Introduction Wayland, for security concerns, removed most of the X11 APIs that xdotool uses to simulate user

Jin Liu 25 Dec 3, 2023