way-cooler/way-cooler

Wayland compositor for AwesomeWM

Way Cooler

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.

way-cooler's Issues

Active container should be able to select non-view containers

Right now the active container will only point to view containers, which is sufficient for basic use of the tiling aspects, but we need a way for the user to select multiple containers. While easy to implement in the back end, it is blocked by #72 since we need a way to give visual feedback to the user on which windows are currently selected.

Move over to dbus for IPC

Our ad-hoc IPC socket does not look like it will scale well for our needs. Lets look into moving over to dbus, this crate looks mature enough to use.

Some commands (like window close) command doesn't work

I noticed some commands don't seem to be working now (such as close window, normally alt+q) does this have to do with changes made in xkb @SnirkImmington? This also changes depending on whether running with cargo run or cargo build. While debugging #52 I came across this issue, so it may have to do with that as well.

Allow users to deny clients going fullscreen

This will allow users to hide some client side borders (since clients hide them when they go fullscreen) and be sure that some client can't suddenly take control of their screen. The keybinding/command to make a view go fullscreen will still work if this is enabled, Way Cooler will just ignore the fullscreen bit on the view. This might cause issues with browser video players (i.e Youtube) if enabled.

Since the tree requires a bunch of configuration options, some struct to keep track of this, e.g TreeOptions or something should be integrated so that these options can be added on in a non-hacky manner, see #76.

• Implement configurable rule to the tree to ignore the bit flag when drawing windows on the screen.
• Add configuration option ignore_client_fullscreen_request

Nothing but background shows

Greetings,
been itching to go wayland for so long now and when I saw something awesomewm-inspired my heart skipped a beat. I am burning to play with this thing.

For the moment, though, if I try running it on both of my up to date arch boxes, only the (purple) background shows. No other functionalities/hotkeys appear to work besides my custom cursors being used and Alt+Shift+Esc actually exiting.

This, and no discernibly different, behaviour shows whether I install from aur or via
cargo install way-cooler,
and whether run from within an x-session or on a separate tty.

Since it showed some similarity to #52 I tried with wlc versions 0.0.6 through 0.0.3 as well, no difference.

I would have tried "removing dlopen from Cargo.toml". which I interpreted as, roughly, cloning the repo,
taking things like ["client", "dlopen"] to ["client"] inside Cargo.toml and then doing
cargo install --path <pathtorepo>, but the ensuing compilation fails with

Compiling way-cooler v0.3.2 (file:///home/ulmeyda/repositories/way-cooler) error:
no method named "has_parent" found for type "&mut layout::core::graph_tree::InnerTree" in the current scope --> src/layout/core/graph_tree.rs:186:43
186 | if cfg!(debug_assertions) && self.has_parent(child_ix) {

which, understandably, is what currently happens when installing from the git version aur package, as well.

Would appreciate some leads to resolve it. Am still hyped.

Many kisses

Add --version flag

Let's keep -v for a verbose mode

Allowing multiple workspaces to be visible/active

This is based on the discussion in #48.

Right now it is assumed only one workspace is active at a time. In other window manangers, such as i3 and awesome it is possible to have views not associated with the current workspace active and on the screen. i3 uses a scratch pad which essentially dissociates a view with any workspace allowing it to always be present, while awesome enhances the concept of a workspace into the idea of a tag.

With tags, the relationship is reversed: tags are associated with views, and multiple tags can be associated with views (as opposed to a view being a child of one and only one workspace). With this relationship, you simply have to activate multiple tags and the views related to those tags will be visible on the screen. A tag is considered a super set of workspaces.

Currently, workspaces are good enough for Way Cooler, but there is interest in having a mechanism to enable views not on the workspace to be visible. In order to keep the option of tags open for the future, we'll implement an awesome-like solution as opposed to the i3 one.

Workspaces will continue to exist as they normally do, but you can have multiple of them active at a time (similar to how you can have multiple tags active at a time). You can not associate multiple workspaces to a view, you can only have multiple workspaces active (and they will continue to be called workspaces).

Tracking issue: problems loading the init file

Pains with the init file is one of the biggest issues new users run into. If init.lua is missing, or invalid in some way, way-cooler will crash somewhat unhelpfully. I have many ideas about making the process smother and robust that I had put off, that need to be implemented.

Included default init file

• Compile config/init.lua into way-cooler to use as the default init file.
• Add --default-init flag to force using this "internal" init file (i.e. for developers, and as a first suggestion in bug reports...)
• Add --init-file=<path> arg as an alternative to setting$WAY_COOLER_INIT_FILE (if both are specified, only look at the command line)
• Add export-init <path> to save this init file to disk (and consider doing it during first run/etc). Executing way-cooler export-init <path> should not run the wm, and should be used in install scripts.
• Also --print-init? To print directly to stdout? way-cooler export-init [-o <path>]?
• Add a comment programmatically at the beginning of the default init file saying which way-cooler version it was generated in. This way if later commands are added and the user still has a default init file from an old version, they can know to regenerate it.
• In the future, "flavors" of way-cooler may be provided with different default init files.

Selecting the init file

• The Lua thread should print directly to stdout if it cannot find an init file instead of logs (and use the default one anyway).
• The Lua thread should print specific explanations if it looks for an init file from environment variables (i.e. XDG_CONFIG_DIR) but cannot find init.lua.
• way-cooler will print a helpful message to stdout saying how to save and modify the init file.
• In the future, it should be easy to ask way-cooler to auto-reload init file changes.

Running initialization

• Useful error messages should be printed directly to stderr ("command cannot be found", " is not a recognized key", along with the accompanying line of the init file.
• If the init file fails, the Lua keybindings shall be cleared, Lua state re-initialized, and the default init file re-run.
• We should attempt to print other error messages in a more helpful way (the string escaping is pretty bad; there might be a format! flag to disable it?)
• In the future, way-cooler should be able to safely rollback some changes made during initialization, and to more thoroughly test whether an init file is valid.

Print warning message for proprietary Nvidia driver users

Users of proprietary Nvidia drivers will not be able to use Way Cooler. Nvidia has not released support for Wayland in their drivers, and so nouveau will need to be used. Sway does something similar already, and it would benefit debugging user issues if we include this kind of check as well.

Support changing the screen brightness through fn keys

Floating windows

It should be possible to set windows to be floating. Floating windows are bound to the root container, and their weight is not taken into account while tiling.

Default keybinding will be alt+space to send to floating, like it is in i3.

Can't open new window when there is no active container

To fix: if no active container, use the path to locate the place to put the window (i.e: treat the end of the path as the active container)

Using petgraph StableGraph

Hi, our projects were mentioned together here (reddit discussion). Do you want to work together on using StableGraph instead? It's a wrapper around Graph. Being a data structure with holes, its safe code maps somewhat less nicely to to vectors and indices (performance wise: in Graph, the bounds check is the existence check, in Stable Graph you need both the bounds check and a check on an Option).

I've already started adding some more methods for being closer to parity with Graph.

Split background into a separate program

The code that currently deals with drawing the background (background.rs) should be relegated to a different program/repo. Since it is dealt with as its own surface, it's best dealt as a separate client program.

There are difficulties with how to integrate this in terms of packaging with Way Cooler, but this is a discussion that would have come up sooner or later as our client programs improved.

@SnirkImmington, is there anything we can/should do now, or should we put this off until we start doing binary distributions. One immediate solution we can do, at least for Arch, is to have another package for this and mark it as "optional" for Way Cooler.

Improve init file search logs and remove user information

At the moment we rely on error logs for debugging and to provide feedback to users. @vinipsmaker has suggested removing any personal or specific information from these logs so users don't feel they have to comb through them and we don't leak any unnecessary information. He specifically pointed out the home directory/user name in the init file logs. They look something like this right now:

WARN [lua::init_path] src/lua/init_path.rs:42 $XDG_CONFIG_HOME=/home/snirk/.config, was not a valid path to a config file. Defaulting ... 
TRACE [lua::init_path] src/lua/init_path.rs:47 Looking at "/home/snirk/.config/way-cooler/init.lua"
INFO [lua::init_path] src/lua/init_path.rs:49 Reading init file from "/home/snirk/.config/way-cooler/init.lua"

The logs when searching for the init file should also be improved, as this is a very common mistake that we need to be more explicit about. Logs should instead look more like:

INFO [lua::init_path] init_path.rs:40 Will search for config file at (1) $WAY_COOLER_INIT, (2) $XDG_CONFIG_HOME/way-cooler/init.lua, (3) ~/.config/way-cooler/init.lua, and default to /etc/way-cooler/init.lua
INFO [lua::init_path] init_path.rs:40 $WAY_COOLER_INIT not defined, looking in regular directories... (1)
INFO [lua::init_path] init_path.rs:42 Found environment variable $XDG_CONFIG_HOME=~/.config, but did not find ~/.config/way-cooler/init.lua (2)
WARN [lua::init_path] init_path.rs:47 The user config file ~/.config/way-cooler/init.lua was not found. Will default to /etc/way-cooler/init.lua (3)
ERROR [lua::init_path] init_path.rs:48 Could not find /etc/way-cooler/init.lua - you need the way-cooler init file to use way-cooler!

way-cooler could not find an init.lua to use. We have looked for it {list of places}. You need an init.lua file to use way-cooler.
We supply a default init.lua in our GitHub releases:
<link to this version's GitHub init file>
You should install that to /etc/way-cooler/init.lua as a backup, and copy it to your config folder {~/.config or $XDG_CONFIG_DIR if it was defined before}/way-cooler/init.lua and do your modifications there. 
Alternatively, you can use the $WAY_COOLER_INIT variable when running way-cooler to point directly at the file way-cooler should use.

Those last couple of lines would be printed directly to stdout.

We should also consider compiling the default init file into way-cooler (to be used after /etc/way-cooler/init.lua - but this raises more questions and prompts more discussion (is this a good idea for when we release different "styles"? Does this affect the discoverability of the init file? When we have more standard methods of distribution will this be a problem?)

Also, having Lua restart with a different init file during the initialization phase (i.e. "default to /etc/way-cooler/init.lua") is a separate issue.

Long-term features

These are the list of features we expect to support prior to a 1.0 release:&

• i3 style tiling with custom layout options (in progress) and workspace configuration (see #19)
• Config files for Lua, fine-tuned global settings(see #18)
• Inter-process channels to allow external programs to interact with way-cooler (see #20)
• Lua thread running internally as a basic client (see #16)
• An internal representation of the config JSON, accessed through Lua and IPC (see #17)

In addition, these external programs are needed:

• way-cooler-client: Simple client program to explore IPC and eval Lua in way-cooler from the command line
• way-cooler-bar: Simple and customizeable top bar powered by cairo with Lua widgets
• "barly": top bar with HTML/JS widgets
• way-cooler-helm: A launcher to be paired with way-cooler (optional)

Also, it would be good to have libraries for using way-cooler IPC from these languages:

• Lua
• Python
• Rust

Finally, although it will be a difficult undertaking, we would like to provide way-cooler compatible versions of existing X programs/configuration:

• xbindkeys
• xdotool
• xmodmap
• xrandr

Configuration features

These are some features we want in the config:

• "The registry" - JSON key/value store of configuration used by way-cooler
• Registry mapped to config files
• Flags to prevent some values in the registry from being changed by Lua
• Config read from defaults or $HOME/.config/way-cooler, etc.
• Lua script called on initialization

Add Tree Paths

Right now there are several niceties that can't be implemented because the way Way Cooler remembers the active container is "dumb". It's essentially just an index into the Node, and as soon as it is removed or switches it completely forgets it.

If we promote the edge weights to be more than simple u32s and instead complex structs that remember which of their children were accessed last we can have a far more sophisticated concept of what Node was used last. This will allow Way Cooler to switch between containers and go back the last view that was used in that Container. It will also allow us to many more actions even if we don't have an active container but only a general path to one.

Look into fancy mouse support (i.e macros/keys on mouse)

Not sure what will be needed from Wayland/wlc in order to accommodate this, but it would be nice if they keys on mice could be used in Way Cooler.

Lua restartability

As of now, there is no way to restart the Lua thread or reload the config. These should both be merged into the same change.

We also need to take #57 (data race between Lua, commands, wlc) into account.

Tiling features

These features are desired of the way-cooler tiling algorithm (see way-cooler/tree/tiling):

Workspaces

• Can have names or use numbers
• Can be generated on the fly or exist as a static list
• Each monitor can have its own workspace list,
• or the list is global across all outputs
• Can move containers between workspaces

Containers

• Views are assigned to containers
• Containers can tile horizontally or vertically
• Containers can be nested
• Containers can be controlled i3 style
• Can move containers to other containers
• Custom tiling patterns so container keybindings aren't needed

Views

• Try not to tile views that don't want to be tiled
• Floating views

Server side window decorations

The only decorations used in Way Cooler now are drawn by client applications. This is not only looks ugly, but is a blocker for #73, which requires a visible way to show how many containers you are selecting.

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.

Automate GitHub Deploys via Travis

In order to release new versions of Way Cooler quickly and efficiently (including hotfixes), and to enable releasing binaries, we should use Travis to deploy releases to GitHub. The new release cycle would look like:

• Create branch/commits to update readme, Cargo.toml, Cargo.lock with new version
• Update wiki for version-specific changes/changelogs
• Merge version-specific changes in
• Push git tag for the version
• Travis handles some release stuff:
  • Updates docs
  • Compiles binaries for multiple architectures (linux, freeBSD, ARM versions)
  • Creates the GitHub release for that tag
  • Uploads binaries + init.lua to GitHub release
• Publish to crates.io
• Update AUR package/etc.
• Close any remaining issues, milestones, and Trello board posts

It would be nice if Travis could also handle updating packages or other boilerplate that could accidentally be forgotten as well.

We could go all out and use some scripts to update the readme/etc with version numbers but that's not needed. Statically linking binaries is another issue so we can wait for that.

For version 0.3.3, I suggest we have:

• Travis git-tag hook to post a GitHub release (OAUTH tokens, etc.)
• Travis attaching init.lua and maybe the basic unlinked way-cooler x86_64 linux to the GitHub release

If we don't use Travis to automate anything else about our releases (like some kind of non-obsessive person), we should at least have a specific "playbook" for how we release: making a release branch, specific commits for updating the readme/docs/etc., and a specific order of running cargo publish, etc.

Segfault on startup due to background

The background image is loaded up, and then mysteriously destroyed just a moment later. This causes a segfault, and Way Cooler terminates. Tested as of 034dcbe (current master), on Arch Linux 64bit.

WORKAROUND: Set the color in the configuration file to be empty, and it should work as the background will then not load.

Add support for background images

Right now Way Cooler only supports solid color background images. There is strange behavior when attempting to write out the image buffer after reading it from an image surface.

Weird black lines appear on the image, and the color saturation seems to be depleted though the image is discernible.

Here's an example of what the output looks like:

and here's what it's supposed to look like:

Add contributing page

We should also list easy things that others can do, for example:

• Better documentation,
• Adding tests
• Adding client libraries for languages
• Random other easy tasks
  • For example, switching parent panics over to the Result<_, GraphError::MissingParent(node)>

Closing a window (with close_window command) that has a pop-up "Are you sure" dialog has strange behavior

I'll use emacs as an example. If you edit a open file buffer in emacs, but don't save your changes, if you try to close the window (i.e with alt+q) then a dialog box opens asking you questions on how it should deal with the file.

Here, different things can happen:

• If you choose to e.g look at the buffer, then we've already removed it from the tree. This means that you can freely do things in emacs (for the most part) but it will no longer behave with the rest of the containers in the tree. If it was the only app open, then all other apps are now obscured. The only fix is to open a terminal and type in pkill emacs, and wait for the buffer to be garbage collected.
• If you choose to close the window (saving or not) then the window is properly closed but the display/ buffer s not cleared, so the last view you had of emacs will stay up (but non-interactable, since its not really "there") and obscuring things until you switch to a window where those pixels can be overwritten.

What is it with Rust crates never ever caring to add git tags on the repo?

Hey, it'd be useful for me to package this software for ArchLinux if git tags are provided. If you care about preserving the history of the project, tags are useful too.

Project standards for code format, linting, etc

Way Cooler and rustwlc both have somewhat poor code formatting standards. While I am personally somewhat opposed to rustfmt and similar projects which limit the shape of source code, what we have right now is not very unified. We need a solid list of rules that we can point new contributors to that will be definitive. We also need to hold ourselves to these standards!

Code format

• Tabbing must be done at 4 spaces without the use of \t, this is final.
• Maximum line width? I suggest we take inspiration from the Linux kernel and have line width limits. However, in Rust our code can end up with many generic function signatures which can't fit in certain widths. 80 characters is also good for being able to read on two tabs at a time. 90 could also be an option.
• Import ordering - We've done a good job of (mostly) ordering use statements, but I've left a lot of newlines between them. Perhaps these should be cleaned up. Hopefully this becomes easier as editor support increases and we can stop typing them ourselves.
• use within methods - In a couple of places where we have an import with a narrow scope, it has been nice to have a use statement there and not at the top of the file. Should this be avoided or discouraged?
• Naming - should we look through the code and standardize naming?
• Modules - @Timidger has called me out many a time for placing too much code in mod.rs. We should look at other crates and come up with a scheme of when to split modules into multiple files.
• Rustwlc in particular has code that we wrote with little knowledge of Rust
• Cover code formatting in clippy or rustfmt config, prevent badly-formatted code from being pushed via travis? Too extreme? I'd rather have an automated service say no than nit through a PR for formatting the way they do in wlc. This would be cool for GitHub integration (i.e. the rustwlc bot from before)

Comments

• Require doc comments all over the project? Use #![deny(missing_docs)]?
• Require more inline comments? Require comments documenting specific algorithms
• Doc tests - show off syntax of internal APIs, easy to help new contributors, but can slow down development and is really just designed for libraries

Testing

• Add coveralls badge when ready
• Add travis build badge
• Consider running travis build through docker image (we may run into travis timeouts)
• Bring unit test coverage up, try to target edge cases
• Create a checklist of window manager user interactions in order to test functionality of tiling/keybindings/ipc/window open+close/X support/etc. especially to help with regressions
• Automate running that checklist using scripting, such as x tools, docker, etc. (very long term)
• Test code in callbacks
• Use dummy-rustwlc or other mocks to perform broader integration tests
• Analyze memory and CPU usage

Lints

• Use of unwrap - I have been advocating to remove all use of .unrap() and replace with a (not always helpful) .expect(message). Should this stay? Can we standardize error messages so there isn't as much overhead of calling .expect()?
• Error types - internally, we have been fine with matching on enum fields to discern the type of error found. Should we move towards implementing the Error type and including messages?

Structure

• I know I have to rewrite registry, ipc, lua, and probably commands and keys to use a struct instead of global methods. How should we consider this for other parts of way-cooler?

Dependencies

• If we can write a fix or solve a problem internally, there's a turning point somewhere between "don't rewrite the standard libraries" and "using left-pad". I advocate a conservative use of external dependencies - especially ones which are close to features "plain Rust" has already. For example, I don't think we should use quickerror or tempfile, as we can just write impl Error for MyErrorType ourselves, thanks, and tempfile is std::fs::temp_path. But I do love the json! macro because it makes code across the IPC a lot more concise.
• I think the unix_socket stuff is in std by now, we should get rid of that

Documentation

• We need to move docs from a folder in the source to the wiki (and link to it in the readme)
• We need to move the cargo docs of rustwlc to a subdirectory of Immington Industries GitHub page
• Can we run cargo doc with fancy flags so that non-exported code (i.e. all of it) is documented?
• High-level view of the structure of our code?
• Since we are tagging releases now and want to move to a faster schedule, should we start to utilize the milestone feature of Github? e.g: one for 3.2.0?

Feel free to comment with anything I should add (or insert directly into this @Timidger)

Add a TreeOptions struct for easy configurability

We want to allow the Tree to have a bunch of options associated with it. An extensible struct that keeps track of that would be really nice to have. It could be populated at startup by the config file and then updated through the IPC or Lua thread as needed via a Command/Property.

In order to make it extendable we probably should just not list each individual field. @SnirkImmington do you have any ideas? A HashMap would be the easiest way to do that, though there might be a better way, especially in order to ensure that all options are set properly and that there are sane defaults.

We could make the entire struct via fancy macro that lets you specify a new option, it's type, and whether or not it's optional. Then expose a builder that fails if you try to compile it without setting one of the non-optional types. (The optional types would wrap the type in an Option).

It crashes when mpv closes

Just open any video (mpv -vo=wayland video_file) and wait until finishes (or press q) and way-cooler crashes. If you cannot reproduce the issue just with just this info, I can look more into it (share video file, get logs, and so on).

Commands & keybindings features

These features are needed to use commands and keybindings (see way-cooler/tree/registry-rejson):

• Keybindings use commands from the registry
• Key presses can be sent through IPC
• Lua can register key handlers in init script
• Reconfigure keybindings at runtime

Consider statically linking to wlc

There have been issues when the wrong version wlc is used, and there are confused users such as #84. This could also help later with packaging Way Cooler, because we could distribute as a single binary.

This might bloat up the size of it a bit more, but it should be able to work. Do you have any strong thoughts on this @SnirkImmington?

Core Feature: multi-head output

This is a very sought after feature, and will need to be broken down into different tasks in order to achieve it.

• Change workspace initialization to include initializing all outputs, similar to how i3 places a new workspace on each output, starting at 1, then 2, etc...
• Add a new invariant to the tree: Each output needs to have at least one workspace. Add it to validation checks and add tests on all methods that might invalidate this (such as workspace pruning movement/pruning methods).
• Rewrite the container movement / focus movement methods to account for moving into another output at the edge of a workspace. Since they are individual buffers, we do not know where the output exists at. This feature has been punted. An explicit command to move to a workspace/output is used instead, like in i3
• Ensure we use the correct resolution setting functions from wlc.
• Gracefully handle adding and removing outputs to the tree.

Core Feature: status bar

A status bar is needed for Way Cooler. The design is still up in the air, and this will be updated when there is more information...

Error during cargo build: cannot find lwlc

>  ~/Development/rust/way-cooler [master] cargo build
   Compiling way-cooler v0.3.1 (file:///home/leshow/Development/rust/way-cooler)
error: linking with `cc` failed: exit code: 1
note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/home/leshow/Development/rust/way-cooler/target/debug/way_cooler.0.o" "-o" "/home/leshow/Development/rust/way-cooler/target/debug/way_cooler" "-Wl,--gc-sections" "-pie" "-nodefaultlibs" "-L" "/home/leshow/Development/rust/way-cooler/target/debug" "-L" "/home/leshow/Development/rust/way-cooler/target/debug/deps" "-L" "/home/leshow/Development/rust/way-cooler/target/debug/build/lua52-sys-aa34817026bf3754/out" "-L" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "-Wl,-Bdynamic" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libunix_socket-f57ceccd621da067.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libjson_macro-c5250c7eaafd504c.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libenv_logger-bf2abd6bc9475582.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libtempfile-7cea1a50ab366cea.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblog-bf16bb9a4912b11d.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libpetgraph-ecccc010e64842ee.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libregex-9bb42fd004f4f034.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libthread_local-e5ce0d44bcaf00e6.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libfixedbitset-0ba3fe99bd419295.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libhlua-57b40b3f2598625e.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libthread_id-bcd46c79a620a618.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbyteorder-e4fc6ea0c49cabcf.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libwayland_client-863352c3ba8be54e.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbitflags-b8c7fb7df9b2bc2e.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libregex_syntax-6ded9701a0454251.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libnix-c1e6d03f33fcdbb4.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libcfg_if-72c1f992b13d5087.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libvoid-2cc31605fcb01ba1.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/librustwlc-102404df61ba3682.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbitflags-0e272044714c8076.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libuuid-07cb77d7842354e7.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/librand-49a08859d086fffe.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/librustc_serialize-3561541d79c18212.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblua52_sys-4555b89660e7fe43.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libaho_corasick-e528bf4fdf3954ff.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libmemchr-c555f740a543880f.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblibc-30d46fdd62f8c2eb.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libutf8_ranges-5c6a6dacba3be7ce.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libwayland_sys-a76d565bcb2f450c.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblazy_static-3a04918be71c80ee.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libdlib-2029350dd34cb019.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblibloading-ff9323b73f47a6f4.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/liblazy_static-359f5533c970cd71.rlib" "/home/leshow/Development/rust/way-cooler/target/debug/deps/libbitflags-75746cc7f0e9d928.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcollections-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_unicode-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librand-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc_jemalloc-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-e8edd0fd.rlib" "/home/leshow/.multirust/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-e8edd0fd.rlib" "-l" "wlc" "-l" "wlc" "-l" "wlc" "-l" "xkbcommon" "-l" "wlc" "-l" "util" "-l" "dl" "-l" "dl" "-l" "pthread" "-l" "gcc_s" "-l" "pthread" "-l" "c" "-l" "m" "-l" "rt" "-l" "util" "-l" "compiler-rt"
note: /usr/bin/ld: cannot find -lwlc
/usr/bin/ld: cannot find -lwlc
/usr/bin/ld: cannot find -lwlc
/usr/bin/ld: cannot find -lwlc
collect2: error: ld returned 1 exit status

error: aborting due to previous error
error: Could not compile `way-cooler`.

To learn more, run the command again with --verbose.

Change release build so that a panic results in an abort

Because we are being called from C, we should abort instead of panic. Panicking unwinds the stack, which has undefined behavior on a stack made by C.

Fix should be bundled with #98

Resize windows in the layout

This will be slightly more complicated than it is in the simple example for rust-wlc. You need to shrink the neighbors as much as you grow the window, in order to not expose the background at all. For floating windows they will be freely resizable.

Move logging over to slog

We need much more structured logging, slog looks like it has the features we want (filtering based on some meta-data, multiple-outputs so we can log to a file and keep it around if it crashes.

IPC features

These are the planned features for inter-process communication with way-cooler:

Command Socket

• Available at /tmp/way-cooler/socket /run/way-cooler/<ID>/socket
• An environment variable is set to indicate what <ID> is.
• Socket handles the case when there was previous or multiple way-cooler instances.
• Socket handles requests in a multithreaded way
• Socket accepts and replies with JSON packets
• Socket accepts requests for event listeners

Packets

• get get values from registry
• set set values in the registry
• exists see if a value exists
• run to run a command
• version to query version
• commands to list commands

Lua IPC

• Lua thread registered as internal IPC client
• Lua can register event handlers

In addition, we need an event API.

Containers "remember" last active child

With Tree Paths finally merged in, containers now have the necessary information to determine which container was last active. This means switching focus will feel much more natural, as switching between different views that are children of container (or between different workspaces) will go the last active one.

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?

Log output should go to a file

We should write the log output to a file, which makes it easier to see what went wrong and let us pretty print some more.

We should also make it possible to clear log output automatically if Way Cooler quit successfully, and otherwise keep it around. We can do this by stamping out /var/log/way-cooler-<timestamp>, which will make each one unique.

This can remain configurable, in order to not chew up people's disks, or if we want to keep log output even if we successfully quit.

Switching to the current workspace turns all the views invisible

Apps that don't work

Here's a list of apps that don't currently work (and any solutions to fix them, if possible). Note that these issues are probably from upstream and we can't fix them, they are simply listed here for visibility.

Please report any misbehaving apps in this thread.

• Firefox (48.0)
  • Doesn't work at all, crashes with TypeError: OS is null, looks like a JavaScript error.
  • Firefox Nightly 51.a1 seems to work.
  • Older versions may work under XWayland
• Pcmanfm (1.2.4)
  • Segfaults after using it for a bit. Difficult to reproduce.
  • Seems to be fixed in 1.2.5
• d-feet
  • Segfaults when using wayland as gdk backend, workaround is to run it as GDK_BACKEND=x11 d-feet (see bug report here)

Add ability to move views between containers

Right now the only modification you can do to the placement of views is move them between workspaces. This is not entirely helpful for when you want to move them around with their other siblings or move them into sub containers.

There are some edge cases that need to be considered, but most of them should be pretty easy. We are not looking for complete feature parity with i3, but just what makes sense in this context. If it would make more sense to move it into a separate keybinding, it can be changed. For now though it will be very similar, if not identical, to how i3 works.

This will not add support for moving containers, as that requires having some visual way to view containers (#72) and some way to select parent/child containers as the active container (#73)

Lua features

These features are needed for the Lua thread:

IPC

• Lua thread is an internal IPC client
• Lua can register its own callbacks to IPC events (i.e. keybindings)
• Accept terminate and restart commands
• Use move semantics/clone-on-write for Arc values from the registry to prevent some copying

Libraries

• Lua called through init script
• Invisible wrapper to registry
• Registry fields with nested names
• JSON support

Most of the value of the Lua thread comes from compatibility with the configuration, commands, keybindings, etc.

Can't move workspaces unless you're focused on a window

Right now this happens because when you're not focused on a window the WM does't know which workspace to tear down before drawning the next workspace. This can be solved for now with simple boolean flags on the Workspaces to indicate if they are visible, but will be replaced with a pathing system in a couple updates.

Segmentation Fault when running weston-terminal

After running way-cooler, I get a segmentation fault when I try to run weston-terminal with Alt-Return

 INFO [way_cooler] wlc: Activating tty                                                                                                                            [123/138]
 INFO [way_cooler] wlc: WLC-1 Chose mode (0) 1920x1080                                                                                                            [122/138]
 TRACE [callbacks] output_resolution: WlcOutput(1) from  Size { w: 0, h: 0 } to Size { w: 1920, h: 1080 }                                                         [121/138]
 INFO [way_cooler] wlc: EGL context is double buffered                                                                                                            [120/138]
 INFO [way_cooler] wlc: EGL version: 1.4 (DRI2)                                                                                                                   [119/138]
 INFO [way_cooler] wlc: EGL vendor: Mesa Project                                                                                                                  [118/138]
 INFO [way_cooler] wlc: EGL client APIs: OpenGL OpenGL_ES OpenGL_ES2 OpenGL_ES3                                                                                   [117/138]
 INFO [way_cooler] wlc: EGL context (RGB888)                                                                                                                      [116/138]
 INFO [way_cooler] wlc: EGL_CHROMIUM_sync_control EGL_EXT_create_context_robustness EGL_EXT_image_dma_buf_import EGL_KHR_create_context EGL_KHR_fence_sync EGL_KHR[115/138]
proc_addresses EGL_KHR_gl_renderbuffer_image EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EG[114/138]
faceless_context EGL_KHR_wait_sync EGL_MESA_configless_context EGL_MESA_drm_image EGL_MESA_image_dma_buf_export EGL_NOK_swap_region EGL_NOK_texture_from_pixmap EG[113/138]
_sub_buffer EGL_WL_bind_wayland_display                                                                                                                           [112/138]
 INFO [way_cooler] wlc: GL version: OpenGL ES 3.1 Mesa 11.2.2                                                                                                     [111/138]
 INFO [way_cooler] wlc: GL vendor: Intel Open Source Technology Center                                                                                            [110/138]
 INFO [way_cooler] wlc: GL_EXT_blend_minmax GL_EXT_multi_draw_arrays GL_EXT_texture_filter_anisotropic GL_EXT_texture_compression_dxt1 GL_EXT_texture_format_BGRA8[109/138]
S_compressed_ETC1_RGB8_texture GL_OES_depth24 GL_OES_element_index_uint GL_OES_fbo_render_mipmap GL_OES_mapbuffer GL_OES_rgb8_rgba8 GL_OES_standard_derivatives GL[108/138]
cil8 GL_OES_texture_3D GL_OES_texture_float GL_OES_texture_float_linear GL_OES_texture_half_float GL_OES_texture_half_float_linear GL_OES_texture_npot GL_OES_EGL_[107/138]
OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_type_2_10_10_10_REV GL_OES_get_program_binary GL_APPLE_texture_max_level GL_EXT_discard_framebuffer G[106/138]
d_format_bgra GL_NV_fbo_color_attachments GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_vertex_array_object GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_[105/138]
on_dxt5 GL_EXT_texture_rg GL_EXT_unpack_subimage GL_NV_draw_buffers GL_NV_read_buffer GL_NV_read_depth GL_NV_read_depth_stencil GL_NV_read_stencil GL_EXT_draw_buf[104/138]
XT_map_buffer_range GL_KHR_debug GL_OES_depth_texture_cube_map GL_OES_surfaceless_context GL_EXT_color_buffer_float GL_EXT_separate_shader_objects GL_EXT_shader_i[103/138]
x GL_EXT_draw_elements_base_vertex GL_KHR_context_flush_control GL_OES_draw_elements_base_vertex GL_OES_texture_storage_multisample_2d_array GL_EXT_blend_func_ext[102/138]
EXT_buffer_storage GL_EXT_shader_samples_identical                                                                                                                [101/138]
 INFO [way_cooler] wlc: GLES2 renderer initialized                                                                                                                [100/138]
 INFO [way_cooler] wlc: Set new bsurface to output (1)                                                                                                             [99/138]
 TRACE [callbacks] output_created: WlcOutput(1): WLC-1                                                                                                             [98/138]
 TRACE [layout::tree] Adding new workspace to root                                                                                                                 [97/138]
 TRACE [layout::tree] Switching to workspace 1                                                                                                                     [96/138]
 TRACE [layout::tree] Found workspace 1 
 TRACE [callbacks] output_focus: WlcOutput(1) focus=true 
 INFO [way_cooler] wlc: Added output (1) 
 INFO [way_cooler] wlc: become active 
 TRACE [callbacks] output_resolution: WlcOutput(1) from  Size { w: 1920, h: 1080 } to Size { w: 800, h: 480 } 
 TRACE [callbacks] output_resolution: WlcOutput(1) from  Size { w: 800, h: 480 } to Size { w: 1920, h: 1058 } 
 INFO [way_cooler] wlc: Xwayland started (DISPLAY :1) 
 INFO [way_cooler] wlc: xfixes (5.0) 
 INFO [callbacks] Preparing compositor! 
 INFO [callbacks] Initializing Lua... 
 TRACE [lua] Initializing... 
 TRACE [lua] Lua initialization finished. 
 TRACE [lua::thread] Initializing... 
 DEBUG [lua::thread] Loading Lua libraries... 
 TRACE [lua::thread] Loading way-cooler lua extensions... 
 TRACE [lua::thread] Loading way-cooler libraries... 
 DEBUG [lua::thread] Entering main loop... 
 TRACE [lua::thread] Lua: awaiting request 
 INFO [callbacks] [key] Found an action for KeyPress { modifiers: MOD_ALT, keys: [Keysym(65293)] } 
 TRACE [callbacks] view_created: WlcView(2): "Wayland Terminal" 
 TRACE [layout::tree] Adding view WlcView(2) to Node { parent: 0x7f8cc8cb6bc0, val: Workspace { name: "1", focused: false }, children: [] } 
 TRACE [callbacks] view_focus: WlcView(2) true 
 TRACE [callbacks] view_request_geometry: WlcView(2) wants Geometry { origin: Point { x: 0, y: 0 }, size: Size { w: 742, h: 392 } } 
 TRACE [callbacks] view_focus: WlcView(2) true 
...
 TRACE [callbacks] view_request_geometry: WlcView(2) wants Geometry { origin: Point { x: 0, y: 0 }, size: Size { w: 742, h: 28840 } }
 ERROR [way_cooler] wlc: gles2: function shm_attach at line 541: glTexImage2D(0x0DE1, 0, gl_format, pitch, buffer->size.h, 0, gl_format, gl_pixel_type, data) == GL_INVALID_VALUE
 TRACE [callbacks] view_request_geometry: WlcView(2) wants Geometry { origin: Point { x: 0, y: 0 }, size: Size { w: 742, h: 31052 } }
 INFO [way_cooler] wlc: Terminating wlc...
 INFO [way_cooler] wlc: Terminating compositor...
 INFO [callbacks] Compositor terminating!
 INFO [way_cooler] wlc: Output (1) terminated...
 TRACE [callbacks] output_destroyed: WlcOutput(1)
 TRACE [lua::thread] Handling a request
 TRACE [lua::thread] Received terminate signal
 INFO [lua::thread] Lua thread terminating!
thread 'Lua thread' panicked at 'Lua thread received termination request.', lua/thread.rs:153
note: Run with `RUST_BACKTRACE=1` for a backtrace.
 INFO [way_cooler] wlc: Removed bsurface from output (1)
 INFO [way_cooler] wlc: Removed output (1)
 INFO [way_cooler] wlc: Compositor terminated...
 INFO [way_cooler] wlc: Cleanup wlc
 INFO [way_cooler] wlc: Closing Xwayland
 TRACE [callbacks] view_destroyed: WlcView(2)
 INFO [way_cooler] wlc: Parent exit (3072)

This does not seem to be an issue specific to your project, as rust-wlc's sample project Give similar issues.

System info: Linux 4.6.3-1-ARCH, Lenovo T450s. Issue persists whether run from login shell or from an X graphical environment