When using uzbl, Focusing some textfields (for instance the search bar on GitHub) causes the X session to freeze.

Seriously, what's up with browsers nowadays?

This means you don't get a fullscreen client if you have only one client open on a corresponding tagset.

When we start Xephyr, activate NumLock, start the window manager to connect to the Xephyr-instance, deactivate NumLock, the events we receive "pretend" that NumLock is still on.

Unsigned Integer overflow on all tiling layouts (except monocle).

For some reason, a lot of WmCommand::Redraw's are sent and handled, resulting in flicker, when using aforementioned software.

If you start e.g. firefox, then switch to a different tagset, and the client's window appears only then, you end up with a client being focused that isn't visible. Basically, this boils down to the assumption about the new client being visible being incorrect. Even though there is code that is supposed to handle this, the logic seems faulty.

If we want to support temporary modes, we need to somehow determine when to return from it. This we can only do when we receive key events we have subscribed for. That's a bummer.

Mind including a screenshot in the README so a possible newcomer gets a clue what to expect?

We get twice as many, and with odd ordering (?) + weird dimensions.

At times, a client is kept around that doesn't show anything, whose properties are garbage and that didn't previously exist.

• implement hint lookup for dialog windows?
• resize to some other available size?
• move to the center of the screen

This feature would be very nice to have. The initial idea is to implement it as a Layout instance. However, as it is now, that's impractical (since Layouts don't carry mutable state).
Thus, the following changes would have to be made:

• Each OrderEntry is a tree of windows and splits, as i3 handles all of it's windows
  • verify that no illegal structure of the tree is possible.
• A Layout is a strategy allowing to do multiple things, namely:
  • Restructure an arbitrary tree into a layout-specific, canonical shape.
  • Handle inserting and deleting windows.
• A "manual" layout would emulate i3's behaviour by inserting windows at the cursor.
• The tree converions mentioned above should follow a convention (ie. the master is always the left-most leaf in the tree, that is, top left).
• So, superficially, everything remains roughly the same if you use the simple layouts already present (like the various *Stack).
• More complicated layouts, like Grid and Monocle would need some additional thought, but a simple convention (or two), combined with the idea that layouts still build the geometries associated with a tree of clients, should make them entirely possible.

Based on the points above, some other aspects of the already existing infrastructure will see some change: Depending on whether the tree holds information on the splits (and I guess it should), focus and window swap can be moved out of layouts, as well as the ugly hack with new_client_as_master (maybe). Client set updates should also happen as soon as possible, to avoid complication.

When running in release mode, layouts generate unexpected output. I suspect overflows.

Pretty self-explanatory - add pledge(2) calls to all binaries produced.

For some reason, firefox' reaction time is vastly worse compared to other environments and applications. Reaction time and graphical update are significantly slower for some reason.

This behaviour would be expected when you switch to a screen, which doesn't display any clients (and whose current tagset's clients aren't displayed anywhere else). However, if you now press keys not grabbed by the window manager, they get passed to the client previously focused on the other screen.

Roadmap

• add logging of key callbacks.
• analyze cause, possibly other issues:
  Apparentl firefox ignores our client message. We'll need to investigate further, why and how that happens.
• implement workaround / fix.

Notes

It might be connected to firefox opening multiple windows (which we have trouble with), see #18.

On config branch, no info on master so far.

We add clients as slaves per default and focus them, which is fine. However, if the layout is Monocle, this leads to problems (windows open hidden and focus disappears).

The best way to address this is probably to add client addition rules to layouts (?)

They are located here.

firefox is put on the current TagSet, but it's supposed to go to web.

See title, focused windows are simply wrong.

The following crash can be triggered when pressing the brightness keys on some systems:

INFO:gabelstaplerwm::wm::window_system: executing binding for KeyPress { code: 233, mods: 0, mode: Normal }
thread 'main' panicked at 'wait() should either return Ok or panic', /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/process/process_unix.rs:74
stack backtrace:
   1:     0x5559793389ba - std::sys::imp::backtrace::tracing::imp::write::h1d59ca58eb86a1e2
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:42
   2:     0x555979337d01 - std::panicking::default_hook::{{closure}}::hc8550e2dc230bf9b
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:351
   3:     0x55597933720c - std::panicking::rust_panic_with_hook::h319375f6b98710b0
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:367
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:555
   4:     0x555979336a51 - std::panicking::begin_panic::h8462d4bdb88c73cc
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/panicking.rs:517
   5:     0x55597933f847 - std::process::Command::spawn::h174a0ef6a697e968
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/sys/unix/process/process_unix.rs:74
                        at /buildslave/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/process.rs:559
   6:     0x5559792e8044 - gabelstaplerwm::wm::config::exec_command::h3ed28e821b936b9b
   7:     0x5559792fe4f1 - gabelstaplerwm::wm::config::setup_wm::{{closure}}::hb4bda0dcbc2dc40b
   8:     0x5559792f470f - gabelstaplerwm::main::h403f0e00ab78e9c3
   9:     0x5559793005ef - main
  10:     0x7f44d98354e0 - __libc_start_main
  11:     0x5559792dad79 - _start
  12:                0x0 - <unknown>

The title says it all - the sole master window is always placed as if the inverted attribute wasn't set.

Better yet, place them somewhere where they will be never seen (ie at negative x and y coordinates). Alternatively, we could unmap windows and cache their geometries to reduce redraws and to avoid such issues in the future.

The division by two, which the layout performs on window sizes, underflows when windows get microscopically small. This is pretty bad because debug builds will crash, and release builds will fuck up the visuals.

The coordinates used are incorrect, as we don't account for the placement of the current screen, yet use it's size as a guideline.

This would be a pretty big change. For now, determine what the needed changes to existing code and infrastructure are.

• wrap a screen's root window (together with some info on location), a tagset, vector of visible windows and screen geometry into a struct and place a vector of those in the Wm struct. Clarification: we still only have one screen/root window. Also, visible windows might also have to stay in our Wm object, I'm not sure.
• allow for focus changes across screens
  • implement neighbour relationships across screens
• interact with RandR
• don't hide windows when monitors disappear
• implement better visualization of tagset overlap (as in, provide the information necessary)
• make redraws local to the affected screen(s)

Maybe we should compute them on-the-fly anyway?

Window manager becomes unresponsive after some fullscreen apps have been started, ran and exited.