Xmobar will quickly move itself back should it be moved. Dzen2 however, will happily be moved and resized. Neither of these should be applied to the moving and resizing logic.

Another note: dzen2 doesn't get panel space allocated like xmobar does.

Every time that wtftw is restarted, the old xmobar process will end up being a zombie, rather than shutting down.

This can be readily seen with programs such as roxterm, gnome-terminal or firefox. Additionally, the program doesn't seem to be given a proper shutdown signal, since firefox has displayed its crash recovery page upon start-up.

Not sure if it's really an issue, but I just noticed it and though it's worth mentioning.

wtftw should be tested against rust nightly but it is being tested against stable in travisCI

Implement swapping of current window with window above/below (same behavior as mod+shift+{j,k} in xmonad)

Add i3wm-like containers.

Down at the bottom

You should recommend cargo build --release because it will build a faster executable.

Hi.
Did you consider switching to tags instead of workspaces ? I find them much more usefull (as you can do workspaces with tags). It was a major point for me not to switch from awesome to xmonad.

Make additional layout types possible by providing a layout plugin architecture.

• wtftw works with dual monitors?
• what are the alternatives to xmobar? I don't want haskell depedency. (see this on config file)
• what font and programs are you using on the screenshot?
• why should I use wtftw than dwm or even awesome?

Currently, as far as I know, there is no way to close a window with a keyboard shortcut unless the program has its own shortcut for closing itself.
If a way to actually close windows exists, it should be added to the example config. Otherwise, it'd be good to have some sort of way to do that added.

util.rs: run and spawn_pipe are too similar; consider refactoring.
spawn_pipe uses .arg instead of .args; it can't take multiple arguments.

Multiple arguments is required for dzen2 to be configured.
spawn_pipe(config, "dzen2", vec!("-h", "16", ...));

I'd have this implemented but have to go now. :-( Maybe tomorrow.

Although doing it's job, it's not the correct way. :-)

[2] 1234 illegal hardware instruction (core dumped)

The error message is
task '<main>' panicked at 'called Result::unwrap()on anErr value: couldn't create directory (File exists; path=/home/freefull/.wtftw; mode=0755)', /build/rust-git/src/rust/src/libcore/result.rs:745
Rather than failing, File exists can probably be just ignored.

cargo build --verbose
Compiling wtftw_core v0.2.0 (file:///home/archie/wtftw)
Running rustc src/wtftw.rs --crate-name wtftw_core --crate-type rlib -g -C metadata=2de27ca0385d84de -C extra-filename=-2de27ca0385d84de --out-dir /home/archie/wtftw/target/deps --emit=dep-info,link -L /home/archie/wtftw/target/deps -L /home/archie/wtftw/target/deps
Fresh xlib v0.1.0 (https://github.com/Kintaro/rust-xlib.git?ref=wtftw#343b40e0)
Fresh xinerama v0.0.1 (https://github.com/Kintaro/rust-xinerama.git#60c722b1)
src/layout.rs:327:41: 327:43 error: mismatched types: expected collections::vec::Vec<u64>, found collections::vec::Vec<u32> (expected u64, found u32)
src/layout.rs:327 Some(ps) => parse_strut_partial(ps),
^~
src/layout.rs:331:40: 331:41 error: mismatched types: expected collections::vec::Vec<u64>, found collections::vec::Vec<u32> (expected u64, found u32)
src/layout.rs:331 Some(s) => parse_strut(s),
^
error: aborting due to 2 previous errors
Could not compile wtftw_core.

Caused by:
Process didn't exit successfully: rustc src/wtftw.rs --crate-name wtftw_core --crate-type rlib -g -C metadata=2de27ca0385d84de -C extra-filename=-2de27ca0385d84de --out-dir /home/archie/wtftw/target/deps --emit=dep-info,link -L /home/archie/wtftw/target/deps -L /home/archie/wtftw/target/deps (status=101)

i use 32bit machine

Make code more rust idiomatic

Windows rearrange in wrong order when a window is deleted, especially if it's from the master pane.

When starting, take control of already running windows. This is necessary for restarting/reloading the window manager after a configuration change or recompilation.

I am playing around with wtftw...

I created a /usr/share/xsessions/wtftw.desktop file which points to a bash script in /usr/bin/wtftw which in turn calls RUST_LOG='debug' /home/code/wtftw/target/wtftw

when I put an error into my config.rs wtftw is stuck after logging it cannot compile the config.

When follow focus is enabled, update the focused window in the corresponding workspace stack

   Compiling wtftw_core v0.3.1 (file:///home/test/Projects/wtftw)
core/src/config.rs:92:9: 123:10 error: internal compiler error: cannot relate bound region: ReScope(DestructionScope(150)) <= ReLateBound(DebruijnIndex { depth: 1 }, BrAnon(0))
core/src/config.rs:92         Config {
core/src/config.rs:93             general: GeneralConfig {
core/src/config.rs:94                 focus_follows_mouse: true,
core/src/config.rs:95                 focus_border_color:  0x00B6FFB0,
core/src/config.rs:96                 border_color:        0x00444444,
core/src/config.rs:97                 border_width:        2,
                      ...
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: run with `RUST_BACKTRACE=1` for a backtrace
thread 'rustc' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:176

stack backtrace:
   1:     0x7fee7dc1a5c9 - sys::backtrace::write::h350af8200010e467Z5r
   2:     0x7fee7dc22519 - panicking::on_panic::h4194b7c3f2c96e6a0Kw
   3:     0x7fee7dbe3212 - rt::unwind::begin_unwind_inner::hf945ded7ea7b4f57aqw
   4:     0x7fee7afbd07d - rt::unwind::begin_unwind::h8796533312692526900
   5:     0x7fee7afbd012 - diagnostic::SpanHandler::span_bug::h7e9f54619e37e35df6B
   6:     0x7fee7bc9f73a - middle::infer::region_inference::RegionVarBindings<'a, 'tcx>::make_subregion::h473442f3e4c3f39dBev
   7:     0x7fee7bcb802f - middle::infer::mk_subr::h0776c164be74f332nty
   8:     0x7fee7d35f01f - check::regionck::type_must_outlive::h4669d3aa7f47c5baLue
   9:     0x7fee7d35d1ca - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  10:     0x7fee7d35d37c - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  11:     0x7fee7d35d37c - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  12:     0x7fee7d35d533 - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  13:     0x7fee7d35d37c - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  14:     0x7fee7d35d37c - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  15:     0x7fee7d35d37c - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  16:     0x7fee7d35d37c - check::dropck::iterate_over_potentially_unsafe_regions_in_type::hcb1bbdbbf6cef3aaMDa
  17:     0x7fee7d35bd58 - check::dropck::check_safety_of_destructor_if_necessary::h4c427730a42a4da1Wxa
  18:     0x7fee7d38cf6d - check::regionck::check_safety_of_rvalue_destructor_if_necessary::h9b6ec91f45b6399abQd
  19:     0x7fee7d386cc1 - check::regionck::visit_expr::hc9e3bd482aef71ae7ad
  20:     0x7fee7d384dba - check::regionck::Rcx<'a, 'tcx>::visit_fn_body::h6820d6f59a6da53bzNc
  21:     0x7fee7d3fd71d - check::check_bare_fn::h705b7c21d36bdd45Tun
  22:     0x7fee7d409a6c - check::check_method_body::h9107e7ed5684a56cP6n
  23:     0x7fee7d3fb365 - check::CheckItemBodiesVisitor<'a, 'tcx>.Visitor<'tcx>::visit_item::h4df3e762586989feWrn
  24:     0x7fee7d3fb79f - check::CheckItemBodiesVisitor<'a, 'tcx>.Visitor<'tcx>::visit_item::h4df3e762586989feWrn
  25:     0x7fee7d4bbd4a - check_crate::closure.38931
  26:     0x7fee7d4b57bc - check_crate::h779a0efdf619d19euJC
  27:     0x7fee7e16a37f - driver::phase_3_run_analysis_passes::heb3d8e9920254d63tGa
  28:     0x7fee7e14e1ac - driver::compile_input::hd3dd730970eb45c2Qba
  29:     0x7fee7e2041b1 - run_compiler::h4be6ca332f13312675b
  30:     0x7fee7e201a02 - boxed::F.FnBox<A>::call_box::h7925108573723512372
  31:     0x7fee7e200fc9 - rt::unwind::try::try_fn::h5378213576640735239
  32:     0x7fee7dc9ac28 - rust_try_inner
  33:     0x7fee7dc9ac15 - rust_try
  34:     0x7fee7e201264 - boxed::F.FnBox<A>::call_box::h12991688188475136491
  35:     0x7fee7dc212b1 - sys::thread::Thread::new::thread_start::h750ed153b2916909hxv
  36:     0x7fee77cbd373 - start_thread
  37:     0x7fee7d87327c - clone
  38:                0x0 - <unknown>

Could not compile `wtftw_core`.

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

Currently using:

cargo 0.2.0-nightly (a483581 2015-05-14) (built 2015-05-15)
rustc 1.2.0-nightly (c23a9d42e 2015-05-17) (built 2015-05-17)

Chromium and other apps crash the WM when started.

I have an issue on FreeBSD with XOrg. All Input works, but the windows don't gain focus until I press "CapsLock". Then, I can write to a window, but with the issue that everything is all-caps. Am I just using things wrong or missing something or is this a bug?

The platform is FreeBSD/XOrg...

Move configuration file to ~/.config/.wtftw dir and use json file for easy configuration instead of config.rs which requires compilation every-time config changes

When moving a window to another workspace, for example from workspace 2 to 1, it remains visible on workspace 2 until workspaces are switched.

I run pretty basic Debian Jessie on my ThinkPad, and wtftw seems to have a weird behavior: after a while, the only thing that can use the keyboard is firefox.

Steps:

1. Use wtftw for a while. Everyhing works just fine.
2. at some point, bad stuff happens
3. Notice that you can't switch workspaces, use xmobar, or even quit. Typing in text boxes in Firefox works, though.

I'm using the stock config file, just pointing at my own xmobarrc.

Hello Kintaro, loving your window manager; intend to switch away from XMonad! Although, before I do; I'd like to make a number of suggestions, enhancements and other notes. :-)

Layout notes

• Fullscreen looks better without borders
• Resizing panes is fun, but better when you can resize both axises. (I.e. Shift for the other)
• Spacing variable is ignored; is this meant to be the gap between the windows and the screen's edges?

BYO panel?

• A problem that I've had with xmobar is that it doesn't compile into XMonad, it would be nice to see a bar that compiles into the window manager.
• Integration means that we don't need to redraw the entire bar when any single component changes; I.e. A clock ticking.
• Overloaded panel? Prompt for running programs, notifications or dynamically setting various variables (I.e. MPD_HOST env variable for MPD related functions; which works very well for audio controls).

Expanding on keyboard keys?

• Wouldn't it be nice if we could do for example "M-s-<Return>" or scan for delayed keys for combinations such as "M-s a" to have M-s for search; and a for ArchWiki.
• Not sure if this could be expanded through using macros? Hopefully so.

Window groups/border colours

• Something that I've considered for a while is having various border colours for windows in different groups; I.e. As a class or role associated to the window.
• An example for where this is useful is when you have various jails/chroots with different networking rules or file access.
• Active colour could be a modifier (I.e. +#222222) and would apply against any underlying colour.

Potential libraries for wtftw-contrib ;-)

• Rust bindings to libmpd (for tighter integration and less shell I/O).
• Tmux listing and auto attaching; like https://github.com/vodik/dotfiles/blob/master/xmonad/lib/XMonad/Util/Tmux.hs.
• Each of the above 3 sections (panel,keyboard,window-groups) if modular enough.

Sadly; I'm a bit too rusty with rust; I'm learning and I'm looking into the layout suggestions currently. :)
P.S: Great to hear that Wayland is also a possibility as it would mean that the efforts for X continue to be of value when people switch to Wayland. ^,^ Oh and Merry Christmas!

-DarkFox

Host system: Evolve OS.
Desktop: Budgie Desktop (wm = libmutter based, potentially the issue)
rust: rustc 0.13.0-nightly (126db549b 2014-12-15 00:07:35 +0000)

Head: d42426c

Screenshot will explain it better than I could.

It looks like https://github.com/Kintaro/wtftw/blob/master/core/src/core.rs.racertmp was added by mistake, since it is nearly a copy of core.rs. I assume that's not wanted, and should probably be blacklisted?

I'm using the latest rust nightly, rustc 1.0.0-nightly (4db0b3246 2015-02-25) (built 2015-02-26)
and the latest cargo, cargo 0.0.1-pre-nightly (5773064 2015-02-25) (built 2015-02-25)

And here's the build log:
http://pastebin.com/pUrENWnX

Moving windows to other workspaces is buggy when running on multiple screens. Somehow related to issue #3

It seems that the executable links dynamically to Rust's libraries. While that results in a decreased file size, it means you can't run it after upgrading the compiler, forcing you to recompile.

/home/freefull/code/other/rust/wtftw/target/wtftw: error while loading shared libraries: librustrt-4e7c5e5c.so: cannot open shared object file: No such file or directory

Group windows in tabs/stack.

Looks like the same issue as in: #33 Also crashing when mod+mouse_click; both left and right clicking on in my case; dzen2. My guess is this will also crash if you attempt to move a program that itself crashes before or during resizing or dragging actions.

thread '<main>' panicked at 'called `Option::unwrap()` on a `None` value', /build/rust-git/src/rust/src/libcore/option.rs:361
stack backtrace:
   1:     0x7f17dbd80ed0 - sys::backtrace::write::h05df4e8815446982JGt
   2:     0x7f17dbda24e0 - <unknown>
   3:     0x7f17dbd0eaa0 - rt::unwind::begin_unwind_inner::h0690c94aa99feb22jLz
   4:     0x7f17dbd12810 - rt::unwind::begin_unwind_fmt::h6ec597b88ba9684eGIz
   5:     0x7f17dbda2220 - rust_begin_unwind
   6:     0x7f17dbde3370 - panicking::panic_fmt::hb0df6a3c5702841fLkl
   7:     0x7f17dbde1070 - panicking::panic::h3ea292ab163166f4bil
   8:     0x7f17d8d66f40 - option::Option<T>::unwrap::h16714267831571719553
   9:     0x7f17d8d66e50 - core::Workspaces<$u{27}a$GT$::find_screen::h6082bf681eba30cdIyb
  10:     0x7f17d8daff60 - window_manager::WindowManager<$u{27}a$GT$::focus::h058bbd92ab1e2927sed
  11:     0x7f17d8cf79b0 - configure::unboxed_closure.3733
  12:     0x7f17dcbecda0 - main::hdcd4cd1bf298f93bNaa
  13:     0x7f17dbdffc30 - <unknown>
  14:     0x7f17dbdffc20 - rust_try
  15:     0x7f17dbda3e90 - rt::lang_start::h083805dd5d25294860z
  16:     0x7f17dcbf13b0 - main
  17:     0x7f17daa7bf50 - __libc_start_main
  18:     0x7f17dcbe23a0 - <unknown>
  19:                0x0 - <unknown>
[2]    16841 illegal hardware instruction (core dumped)  ./target/wtftw

core/src/core.rs:find_screen; It is unsafe to assume that the Option is Some(). None is undefined behavior.

642     pub fn find_screen(&self, window: Window) -> Screen<'a> {
643         if self.current.contains(window) {
644             self.current.clone()
645         } else {
646             self.visible.iter()
647                 .filter(|x| x.contains(window))
648                 .nth(0).unwrap().clone()
649         }       
650     }   

Patch? Not quite sure, however, the following proves that it is where we crash.

642     pub fn find_screen(&self, window: Window) -> Screen<'a> {
643         if self.current.contains(window) {
644             self.current.clone()
645         } else {
646             match self.visible.iter().filter(|x| x.contains(window)).nth(0) {
647                 Some(s) => s.clone(),
648                 None => panic!("What to do now?")
649             }
650         }       
651     }   

Which results in:

thread '<main>' panicked at 'What to do now!?', src/core.rs:648

The usage of unwrap appears to be quite common within the source tree; might be good to remove every instance.

For this and other unwrap patches, it may be suited if the return value itself becomes an Option or Result.

Right now, panels such as xfce4-panel get treated like any window. It'd be nice if such panel programs would get treatment similar to how other window managers treat them.
This probably should be implemented around the same time as EWMH support, given panel programs rely on EWMH too.

Running pkill xmobar will cause the window manager to die when it tries to unwrap an Err value.

task '<main>' panicked at 'called `Result::unwrap()` on an `Err` value: broken pipe (Broken pipe)', /build/rust-git/src/rust/src/libcore/result.rs:745

$ cargo build

   Compiling xlib v0.1.0 (https://github.com/Kintaro/rust-xlib.git?ref=wtftw#343b40e0)
        Running `rustc /home/asdf/.cargo/git/checkouts/rust-xlib-191d9c84d6d9b1f9/wtftw/src/lib.rs --crate-name xlib --crate-type rlib -g -C metadata=edc8cf4f06f71c9d -C extra-   filename=-edc8cf4f06f71c9d --out-dir /home/asdf/Projects/wtftw/target/deps --emit=dep-info,link -L /home/asdf/Projects/wtftw/target/deps -L /home/asdf/Projects/wtftw/target/deps -Awarnings`
           Compiling wtftw_core v0.2.0 (file:///home/asdf/Projects/wtftw)
                Running `rustc src/wtftw.rs --crate-name wtftw_core --crate-type rlib -g -C metadata=b4d67fb3614c8af5 -C extra-filename=-b4d67fb3614c8af5 --out-dir /home/asdf/    Projects/wtftw/target/deps --emit=dep-info,link -L /home/asdf/Projects/wtftw/target/deps -L /home/asdf/Projects/wtftw/target/deps`
                error: unknown emission type: `dep-info`
                Build failed, waiting for other jobs to finish...
                error: unknown emission type: `dep-info`
                Could not compile `xlib`.

                Caused by:
                  Process didn't exit successfully: `rustc /home/asdf/.cargo/git/checkouts/rust-xlib-191d9c84d6d9b1f9/wtftw/src/lib.rs --crate-name xlib --crate-type rlib -g -C   metadata=edc8cf4f06f71c9d -C extra-filename=-edc8cf4f06f71c9d --out-dir /home/asdf/Projects/wtftw/target/deps --emit=dep-info,link -L /home/asdf/Projects/wtftw/target/deps -L /   home/asdf/Projects/wtftw/target/deps -Awarnings` (status=101)

rustc 0.12.0-dev
cargo 0.0.1-pre-nightly (fd5d7a9)

The code fails to build with the latest Rust nightly because TreeMap no longer exists in libstd. It can be replaced with a different structure (probably BTreeMap) or the TreeMap from https://github.com/Gankro/collect-rs/ can be used.

I've created this as an issue instead of a pull-request because I'm not sure which resolution would be preferred.

Issue: The README's provided workflow for making use of a custom configuration is:

1. run wtftw, which creates ~/.wtftw/
2. copy repository's /config/config.rs to the created config dir under ~/.wtftw/src/
3. try out / adjust to taste.

This workflow causes a build error / the configuration is unused because the default ~/.wtftw/Cargo.toml does not have wtftw-contrib as a dependency. Some users will not know how to quickly fix this.

Here are three possible resolutions:

1. add wtftw-contrib as a dependency in the default Cargo.toml even though the default configuration doesn't require it.
2. create a full configuration dir in /config and instruct users to copy over the entire dir
3. explain in the readme that the example config requires the addition of the wtftw-contrib dependency (and optionally how to add dependencies to the Cargo.toml, using wtftw-contrib as an example)

Implement ability to reload the code and restart the WM on the fly.

Now that #67 issue was closed I have got another issue.

thread '<unnamed>' panicked at 'unable to start terminal', core/src/handlers.rs:48

I'm running wtftw on Xephyr using the default config.

http://doc.crates.io/faq.html#why-do-binaries-have-cargo.lock-in-version-control,-but-not-libraries?

As previously commented and recently removed 6715bf7; the following is better enabled as it centers all windows evenly from the sides.

window_system.resize_window(window, w - config.border_width,
                                    h - config.border_width); // Don't need to double

To make the gap between windows equal to the gap around the windows; the gap needs to be applied also to the screen/root-window's borders.

let g = self.gap; // Don't need to half

The notes infer that the numbers are better configured accordingly and not dynamically modified at runtime.

When using it in a real X system and not via Xephyr/Xnest,
wtftw does not respond to any key commands until a gui application is started via tty.

Change config file from json to a rust code format, akin to Xmonad.