aquariwm/aquariwm

A modular Wayland compositor and X11 window manager that's approachable.

AquariWM

AquariWM will be an X11 window manager and Wayland compositor focused on a highly modular design. It will also focus on high-quality documentation and being accessible and welcoming to all.

Modularity

Tiling window layout managers will be able to be provided by external applications ('AquariWM clients'). AquariWM clients will also be able to provide decoration managers, providing the window decorations for windows.

Other areas of modularity will exist too but ideas for them will become clear as AquariWM is developed - areas could include input methods, config/settings managers, or adding modularity that X11 already has to the AquariWM Wayland compositor (window managers and compositors being provided by external clients being one example).

Current state

At the time of writing (December 2023), AquariWM development is in early stages, though the layout manager system is implemented in Rust (with the goal of transitioning to use a custom protocol in the future, the specifics of which are yet to be decided). @Antikyth, the only author of AquariWM at the time of writing, is working on generational-arena-tree, a tree implementation in Rust that gives the flexibility to implement more complex features for tiling layouts (e.g. taking windows' minimum and maximum sizes into account). Specifically, it allows:

• nodes to be mutated directly,
• nodes to be iterated over mutably,
• nodes to be split by type into separate branches (nodes that may have children) and leaves (nodes that may not have children), which each have their own associated data type.
  • This is required because, in window layouts, every branch has an orientation, and every leaf has a window. No branch may have a window, and no leaf may have an orientation.

Here is a screenshot of a working Main + Stack layout manager implemented in the current state of AquariWM:

aquariwm's Issues

Stack layout: if removing the last window in the stack, remove the stack too.

Layouts: allow user to swap the windows of different window nodes

The user should be able to swap the windows of any two window nodes, even if they are on different branches of the layout tree.

This means having mutable references to two (disjoint) parts of the same tree, so I have a feeling unsafe is gonna be required.

Layouts: change the representation of layout trees

Working with layouts is complicated a lot by my representation of the layout tree. While it is the most obvious way to represent a tree, I understand now that there are other ways, and ways that will make other layout features that need to be implemented easier.

The main complication with these layouts is that each group has a lot more information than just its children (orientation, dimensions, coordinates at minimum).

I think a better approach here, which I haven't learned that much about yet, is to somehow use Rc and Weak to let nodes have references to their parents. I'm not sure how mutating groups' orientation, dimensions, and coordinates fits in with that.

Implement desktops and layout regions

Layout regions are areas of the screen used for a tiling layout. Normally, that would be the whole screen, but they could be useful on an ultrawide, for example, where you might split the monitor in two using two layout regions. Of course, you might also want to just have the one layout region even on an ultrawide.

Probably the most useful way for layout regions to work is that they show different desktops, i.e. you can have two desktops open on the same monitor.

Copy GitHub Actions `ci` workflow from XRB

I already made a really useful ci workflow for XRB which we can use for AquariWM too. The docs section of the workflow would need to be updated, as it's XRB-specific.

X11 winit testing window doesn't close unless forced

The testing window won't close when you request to (e.g. by pressing a cross button or close window keybinds). It does when AquariWM is force closed e.g. with the stop button in the IDE.

This isn't an issue on Wayland because the Wayland winit window is managed by Smithay.

Support toggling windows between tiling and floating modes

Window focus 'flickering'

It seems that there is a 'flickering' effect of the window focus.

  2022-07-30T09:32:09.907897Z TRACE aquariwm::aquariwm: Bringing the newly focused window to the top of the stack, window: 4194308
    at src/aquariwm.rs:149

  2022-07-30T09:32:09.908112Z TRACE aquariwm::aquariwm: Bringing the newly focused window to the top of the stack, window: 4194306
    at src/aquariwm.rs:149

  2022-07-30T09:32:09.908193Z TRACE aquariwm::aquariwm: Focusing window entered by cursor, window: 4194308
    at src/aquariwm.rs:135

  2022-07-30T09:32:09.908282Z TRACE aquariwm::aquariwm: Focusing window entered by cursor, window: 4194306
    at src/aquariwm.rs:135

  2022-07-30T09:32:09.908322Z TRACE aquariwm::aquariwm: Bringing the newly focused window to the top of the stack, window: 4194308
    at src/aquariwm.rs:149

  2022-07-30T09:32:09.908537Z TRACE aquariwm::aquariwm: Bringing the newly focused window to the top of the stack, window: 4194306
    at src/aquariwm.rs:149

  2022-07-30T09:32:09.908633Z TRACE aquariwm::aquariwm: Focusing window entered by cursor, window: 4194308
    at src/aquariwm.rs:135

  2022-07-30T09:32:09.908711Z TRACE aquariwm::aquariwm: Focusing window entered by cursor, window: 4194306
    at src/aquariwm.rs:135

The window manager can get into a state where two different windows are brought to the top in short succession, which generates two 'enter window' events, causing those two windows to be focused and then brought to the top, continuing the cycle. Obviously, there wouldn't be any problem if the window manager didn't focus windows based on 'enter window' events generated in reaction to that window coming to the top after being focused.

Layouts: find best compromise to try to respect as many windows' min and max sizes as possible

Vertical group example

For example, if a window in a vertical group has a minimum width larger than another window in that vertical group's maximum width, you'd either just use the minimum width of the larger one, or somewhere in between (might make the larger one unusable though).

For that same vertical group, the minimum and maximum heights of windows would also affect how window proportions are scaled and how the sizes of new windows are chosen.

If the vertical group spans the whole display's height, and it has two windows in it that both have minimum heights larger than half the display height, then both those windows would also have to be forced to be smaller than their minimum heights.

Nodes

The concept of minimum and maximum sizes will have to be supported by nodes too - a window node's minimum and maximum sizes need to be inherited by all the window node's ancestors to some degree.

This isn't going to be easy to do all the calculations around.

Manual resizing implications

This also has implications for how users are allowed to resize their nodes.

In my opinion, the way this should be handled is users simply are not allowed to resize a node more than its maximum size or less than its minimum. If the node is already in one of those situations due to having to make a compromise with other nodes, the user is able to resize the compromising nodes within the range of compromise.

Because that's not the easiest to understand, here's a diagram:

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃                                   ┃
┃         Window A: minimum         ┃
┃                                   ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
┏━━━━━━━━━━━━━━━━━━━┓
┃                   ┃⎧              ⎫
┃ Window B: maximum ┃⎨ Resize range ⎬
┃                   ┃⎩              ⎭
┗━━━━━━━━━━━━━━━━━━━┛

Get some super basic controls working on X11

The ability to open a new terminal window with Super + Shift + Enter and close the current window with Super + Shift + Q would be very helpful for testing. The code for this is already there at the moment, but not functioning. I need to research converting keysyms to keycodes in x11rb and make sure that I'm grabbing the keys correctly.

Detect X11 environment by `DISPLAY` env variable when not using testing mode

Layouts: coordinates of reversed orientations is not reversed

`GroupNode::insert_window` doesn't use `GroupNode::insert_node`

This means it isn't taking reversed orientations into account.

Replace `WindowNode` window methods with making the `window` field public

Layouts: explore search methods

Are there any search methods that can be used to make searching for (leaf) nodes on a tree more efficient?

One thing to note here is that windows have numerical IDs, and so theoretically could be sorted (though the tree itself can't have the order of nodes within groups changed - this would only be useful if there could be some kind of a flat, sorted list of windows mapped to their nodes in the tree).

X11: implement ICCCM and EWMH support

Get layout managers working on the Wayland version