Azul won't start on Wayland.

[Siborgium]

Description

I'd like Azul to work, hovewer it doesn't, panics on startup instead.

Version / OS

• azul version:
  The latest one from master branch.

• Operating system:
  Arch Linux

• Windowing system (X11 or Wayland, Linux only):
  Wayland (Sway as compositor)

Steps to Reproduce

1. Compile and run

Additional Information

[Siborgium]

Couldn't manage to attach logs properly to the issue topic, so I'll just paste them here.

[ERROR][azul::logging] An unexpected panic ocurred, the program has to exit.
Please report this error and attach the log file found in the directory of the executable.

The error ocurred in: src/libcore/option.rs at line 345 in thread main

Error information:
called `Option::unwrap()` on a `None` value

Backtrace:

azul::logging::set_up_panic_hooks::panic_fn @ logging.rs:86
core::ops::function::Fn::call @ function.rs:69
 @ panicking.rs:482
 @ panicking.rs:385
 @ panicking.rs:85
 @ panicking.rs:49
<core::option::Option<T>>::unwrap @ macros.rs:11
winit::platform::platform::wayland::window::Window::get_current_monitor @ window.rs:314
winit::platform::platform::Window::get_current_monitor @ mod.rs:335
winit::window::<impl winit::Window>::get_current_monitor @ window.rs:406
azul::window::get_hidpi_factor @ window.rs:869
azul::window::FakeDisplay::new @ window.rs:803
<azul::app::App<T>>::new @ app.rs:177
azul::main @ main.rs:22
std::rt::lang_start::{{closure}} @ rt.rs:64
 @ rt.rs:49
 @ panicking.rs:297
 @ lib.rs:87
 @ panicking.rs:276
 @ panic.rs:388
 @ rt.rs:48
std::rt::lang_start @ rt.rs:64
unresolved function

$ swaymsg -t get_outputs
Output eDP-1 'Chimei Innolux Corporation 0x1734 0x00000000' (focused)
  Current mode: 1600x900 @ 60.007999 Hz
  Position: 0,0
  Scale factor: 1.000000
  Subpixel hinting: unknown
  Transform: normal
  Workspace: 2:Правка
  Available modes:
    1600x900 @ 60.007999 Hz

The program I was trying to run is just helloworld from examples section.

However, the other examples I've tried to run didn't work neither.
The issue exists independently of compositor, I also tried weston and cage, nothing changes.

[fschutt]

Yes, see #116. Not sure when I can fix it, I'm currently working to get Windows up and running again (currently upgrading glutin / winit).

[renannprado]

I have exactly same issue.

Workaround: set the WINIT_UNIX_BACKEND environment variable to x11, WINIT_UNIX_BACKEND=x11.

Ref: #147 (comment)