can't get wtftw to run

[philippkeller]

I'm trying to run wtftw on a fresh ubuntu installation, but I was not successful so far. Building with cargo build --release on rust nightly was successful.

Xephyr -screen 800x600 :1 &
DISPLAY=:1 ./target/release/wtftw &
DISPLAY=:1 thunar &

worked without error, but when switching to the window I expect that Alt+Shift+Enter would do anything. But it does nothing.

Also when putting this into /usr/share/xsessions/wtftw.desktop:

[Desktop Entry]
Name=wtftw
Comment=improved dynamic tiling window manager
Exec=wtftw
TryExec=wtftw
Type=Application
X-LightDM-DesktopName=wtftw
DesktopNames=wtftw

When choosing wtftw at the startup, the nothing happens. The background pic still shows, linux is frozen, etc. I put wtftw into /usr/bin/.

I also tried to run wtftw directly in the shell, this blocks. I thought maybe it just takes long because it runs a cargo build from ~/.wtftw/ so I ran cargo build and cargo build --release from ~/wtftw/ and ran wtftw directly again, it still blocks.

Some infos about my env:

$ rustup show
Default host: x86_64-unknown-linux-gnu
installed toolchains
--------------------
stable-x86_64-unknown-linux-gnu
nightly-x86_64-unknown-linux-gnu (default)
active toolchain
----------------
nightly-x86_64-unknown-linux-gnu (default)
rustc 1.19.0-nightly (75b056812 2017-05-15)

~/oss/wtftw on  master! ⌚ 7:47:57
$ uname -a
Linux philipp-ThinkPad-X1-Carbon-4th 4.8.0-49-generic #52~16.04.1-Ubuntu SMP Thu Apr 20 10:55:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

[Kintaro]

When running in Xephyr, did you capture input?

…

On Thu, May 18, 2017, 14:49 Philipp Keller ***@***.***> wrote: I'm trying to run wtftw on a fresh ubuntu installation, but I was not successful so far. Building with cargo build --release on rust nightly was successful. Xephyr -screen 800x600 :1 & DISPLAY=:1 ./target/release/wtftw & DISPLAY=:1 thunar & worked without error, but when switching to the window I expect that Alt+Shift+Enter would do anything. But it does nothing. Also when putting this into /usr/share/xsessions/wtftw.desktop: [Desktop Entry] Name=wtftw Comment=improved dynamic tiling window manager Exec=wtftw TryExec=wtftw Type=Application X-LightDM-DesktopName=wtftw DesktopNames=wtftw When choosing wtftw at the startup, the nothing happens. The background pic still shows, linux is frozen, etc. I put wtftw into /usr/bin/. Some infos about my env: $ rustup show Default host: x86_64-unknown-linux-gnu installed toolchains -------------------- stable-x86_64-unknown-linux-gnu nightly-x86_64-unknown-linux-gnu (default) active toolchain ---------------- nightly-x86_64-unknown-linux-gnu (default) rustc 1.19.0-nightly (75b056812 2017-05-15) ~/oss/wtftw on  master! ⌚ 7:47:57 $ uname -a Linux philipp-ThinkPad-X1-Carbon-4th 4.8.0-49-generic #52~16.04.1-Ubuntu SMP Thu Apr 20 10:55:59 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#109>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG0CSWqE2F94rx60kbA_psp6vTEU29yks5r69uxgaJpZM4NewoM> .

[savage-engineer]

Build is also successful for me with rust 1.19-nightly (not using rustup, but mozilla nixpkgs overlay).

Running the following:

$ export RUST_BACKTRACE=1 && Xnest -geometry 800x600+0+0 :1 & DISPLAY=:1 ./target/release/wtftw &

Results in the following:

thread 'main' panicked at 'Exiting', xlib/src/xlib_window_system.rs:72                     
stack backtrace:
   0: std::sys::imp::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: wtftw_xlib::XlibWindowSystem::new
   7: wtftw::main
   8: __rust_maybe_catch_panic
   9: std::rt::lang_start
  10: __libc_start_main
  11: _start
             at ../sysdeps/x86_64/start.S:120

Not sure if this is the same problem, but seems like same symptoms - crashes out straight away.

If running from shell as wtftw it blocks.

[philippkeller]

@Kintaro yes I captured mouse/keyboard with Ctrl+Shift.
Also, I see the same error as @savage-engineer when running export RUST_BACKTRACE=1 && Xnest -geometry 800x600+0+0 :1 & DISPLAY=:1 ./target/release/wtftw &

[Kintaro]

Good news: I am able to reproduce it.
Bad news: I have no clue what is going on.

XOpenDisplay returns null. But with null as input, it should default to the DISPLAY variable. But it somehow is unable to find a display. There is no code related to that initialization that got changed. Neither did the relevant parts in the x crate.

[philippkeller]

I don't think I can be of help debugging here. Or can I?

is there a workaround? I'm just about to set up a tiling window manager and would just love to get started somehow with wtftw. The binary in releases is fairly old, is there another binary I could use for the time being?

[Kintaro]

Xephyr -screen 800x600 :1 &
DISPLAY=:1 ./target/release/wtftw &

Starting it like this does not give me that error.

Starting it with

export RUST_BACKTRACE=1 && Xnest -geometry 800x600+0+0 :1 & DISPLAY=:1 ./target/release/wtftw &

does.

But the unresponsiveness it then gives...I need some time to figure that out. If it's an easy fix, I'll try to provide it. If it's more elaborate, I will take note of it, as I'm working on a new version, from scratch, as this one is quite old. Try maybe reverting to older versions and trying these.

Still at work, same for this weekend, so it could take some time, sorry.

[philippkeller]

Unfortunately I was not successful to get an older version to work. What I tried:

• downloading the release wtftw-1.2.tar.gz and compiling with rust 1.2.0 and rust 1.3.0
• compiling the current version with rust nightly 2017-01-04
• using an older version of the x11 crate
• updating all versions with cargo update

It always throws the same error when trying with Xephyr

[Kintaro]

I know that it used to work, that's for sure. My best guess at the moment that it's maybe a problem with a dependency. Really confused by this error.

[Kintaro]

Quick update: still no clue what the heck is going on. I tried locking older versions of dependencies, but somehow it still remains. Spooky action at a distance

[steveej]

I suspect this is a race. As a workaround try adding 100ms of delay -- Xephyr :1 & (export DISPLAY=:1; sleep 0.1; wtftw & xterm &) -- this makes it work for me.
I'm not suggesting to add this delay to the code though ;-)