glazier can't compile with both x11 and wayland support

[flukejones]

Glazier seems to have numerous issues on Linux.

1. Default backend is X11. This is a problem for many reasons: a. x11 is unmaintained and no-longer the default graphics session on many distributions b. it then runs through XWayland, which causes further issues (root cause of #16 )
2. It can't be compiled with both X11 and Wayland due to the way it imports items within itself.
3. The wayland backend currently segfaults (on gnome due to https://github.com/linebender/glazier/issues/81)

I don't know if you want to continue on with glazier - winit is a solid alternative. Or maybe make floem window-management agnostic? Either way the inability to support both x11 and wayland is problematic where wayland should be the default with a fallback to x11.

As it stands the only possible way to run examples or lapce/floem branch on hybrid GPU linux systems is to offload to the dGPU (increasing power use considerably).

[flukejones]

Backtrace of glazier with wayland backend. Crashes on intel and nvidia:

warning: queue 0x555557399b20 destroyed while proxies still attached:
  wl_display@1 still attached
[New Thread 0x7fffd6bff6c0 (LWP 289040)]

Thread 1 "counter" received signal SIGSEGV, Segmentation fault.
0x00007ffff44d83e5 in wl_proxy_create_wrapper () from /lib64/libwayland-client.so.0
Missing separate debuginfos, use: dnf debuginfo-install dbus-libs-1.14.6-1.fc38.x86_64 elfutils-libelf-0.189-1.fc38.x86_64 expat-2.5.0-2.fc38.x86_64 glibc-2.37-1.fc38.x86_64 libX11-1.8.4-1.fc38.x86_64 libX11-xcb-1.8.4-1.fc38.x86_64 libXau-1.0.11-2.fc38.x86_64 libXext-1.3.5-2.fc38.x86_64 libcap-2.48-6.fc38.x86_64 libdrm-2.4.114-2.fc38.x86_64 libedit-3.1-45.20221030cvs.fc38.x86_64 libffi-3.4.4-2.fc38.x86_64 libgcc-13.0.1-0.12.fc38.x86_64 libglvnd-1.6.0-2.fc38.x86_64 libglvnd-egl-1.6.0-2.fc38.x86_64 libpciaccess-0.16-8.fc38.x86_64 libstdc++-13.0.1-0.12.fc38.x86_64 libwayland-client-1.22.0-1.fc38.x86_64 libwayland-egl-1.22.0-1.fc38.x86_64 libwayland-server-1.22.0-1.fc38.x86_64 libxcb-1.13.1-11.fc38.x86_64 libxkbcommon-1.5.0-2.fc38.x86_64 libxshmfence-1.3-12.fc38.x86_64 libzstd-1.5.5-1.fc38.x86_64 llvm-libs-16.0.1-1.fc38.x86_64 lz4-libs-1.9.4-2.fc38.x86_64 mesa-libgbm-23.0.2-2.fc38.x86_64 mesa-libglapi-23.0.2-2.fc38.x86_64 mesa-vulkan-drivers-23.0.2-2.fc38.x86_64 ncurses-libs-6.4-3.20230114.fc38.x86_64 systemd-libs-253.2-1.fc38.x86_64 vulkan-loader-1.3.243.0-1.fc38.x86_64 xz-libs-5.4.1-1.fc38.x86_64 zlib-1.2.13-3.fc38.x86_64
(gdb) bt
#0  0x00007ffff44d83e5 in wl_proxy_create_wrapper () from /lib64/libwayland-client.so.0
#1  0x00007fffe7868b3e in wsi_wl_display_init () from /usr/lib64/libvulkan_lvp.so
#2  0x00007fffe7869b34 in wsi_wl_surface_get_formats () from /usr/lib64/libvulkan_lvp.so
#3  0x0000555556172215 in ash::extensions::khr::surface::{impl#0}::get_physical_device_surface_formats::{closure#0} (count=0x7ffffffebd0c, data=0x0)
    at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.37.2+1.3.238/src/extensions/khr/surface.rs:82
#4  0x00005555561b37a5 in ash::prelude::read_into_uninitialized_vector<u32, ash::vk::definitions::SurfaceFormatKHR, ash::extensions::khr::surface::{impl#0}::get_physical_device_surface_formats::{closure_env#0}> (f=...) at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.37.2+1.3.238/src/prelude.rs:46
#5  0x00005555561721d3 in ash::extensions::khr::surface::Surface::get_physical_device_surface_formats (self=0x55555747e610, physical_device=..., surface=...)
    at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/ash-0.37.2+1.3.238/src/extensions/khr/surface.rs:81
#6  0x000055555613b031 in wgpu_hal::vulkan::adapter::{impl#9}::surface_capabilities (self=0x5555573bca18, surface=0x55555747e530) at src/vulkan/adapter.rs:1622
#7  0x0000555555d945ad in wgpu_core::instance::{impl#6}::request_adapter::gather::{closure#1}<wgpu_hal::vulkan::Api, ()> (exposed=0x5555573bc920)
    at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.15.1/src/instance.rs:743
#8  0x0000555555cbc23f in alloc::vec::{impl#1}::retain::{closure#0}<wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global, wgpu_core::instance::{impl#6}::request_adapter::gather::{closure_env#1}<wgpu_hal::vulkan::Api, ()>> (elem=0x5555573bc920) at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/vec/mod.rs:1567
#9  0x0000555555c96e8b in alloc::vec::{impl#1}::retain_mut::process_loop<alloc::vec::{impl#1}::retain::{closure_env#0}<wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global, wgpu_core::instance::{impl#6}::request_adapter::gather::{closure_env#1}<wgpu_hal::vulkan::Api, ()>>, wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global, true> (original_len=3, f=0x7ffffffec608, 
    g=0x7ffffffec610) at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/vec/mod.rs:1647
#10 0x0000555555c980cb in alloc::vec::Vec<wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global>::retain_mut<wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global, alloc::vec::{impl#1}::retain::{closure_env#0}<wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global, wgpu_core::instance::{impl#6}::request_adapter::gather::{closure_env#1}<wgpu_hal::vulkan::Api, ()>>> (self=0x7ffffffec758, f=...) at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/vec/mod.rs:1676
#11 0x0000555555cbbff3 in alloc::vec::Vec<wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global>::retain<wgpu_hal::ExposedAdapter<wgpu_hal::vulkan::Api>, alloc::alloc::Global, wgpu_core::instance::{impl#6}::request_adapter::gather::{closure_env#1}<wgpu_hal::vulkan::Api, ()>> (self=0x7ffffffec758, f=...) at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/alloc/src/vec/mod.rs:1567
#12 0x0000555555d93eac in wgpu_core::instance::{impl#6}::request_adapter::gather<wgpu_hal::vulkan::Api, ()> (instance=..., inputs=0x7ffffffecdd0, compatible_surface=..., force_software=false, 
    device_types=0x7ffffffec9e8) at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.15.1/src/instance.rs:739
#13 0x0000555555f1cd95 in wgpu_core::hub::Global<wgpu_core::hub::IdentityManagerFactory>::request_adapter<wgpu_core::hub::IdentityManagerFactory> (self=0x555557497350, desc=0x7ffffffecdc0, inputs=...)
    at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/wgpu-core-0.15.1/src/instance.rs:769
#14 0x0000555555d03c16 in wgpu::backend::direct::{impl#7}::instance_request_adapter (self=0x555557497350, options=0x7ffffffed318) at src/backend/direct.rs:576
#15 0x0000555555d1a0ba in wgpu::context::{impl#5}::instance_request_adapter<wgpu::backend::direct::Context> (self=0x555557497350, options=0x7ffffffed318) at src/context.rs:1932
#16 0x0000555555d6b75e in wgpu::Instance::request_adapter (self=0x7ffffffed000, options=0x7ffffffed318) at src/lib.rs:1424
#17 0x0000555555c2147a in floem_vger::VgerRenderer::new<glazier::window::WindowHandle> (window=0x7fffffff80e8, width=0, height=0, scale=1) at vger/src/lib.rs:39
#18 0x0000555555c057b9 in floem::renderer::Renderer::new (handle=0x7fffffff80e8) at src/renderer.rs:18
#19 0x0000555555c118da in floem::context::PaintState::connect (self=0x555556eafc10, handle=0x7fffffff80e8) at src/context.rs:593
#20 0x0000555555bf28a2 in floem::app_handle::{impl#3}::connect<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>> (self=0x555556eafbd0, handle=0x7fffffff80e8) at src/app_handle.rs:464
#21 0x0000555556b5c4e0 in glazier::backend::wayland::window::{impl#8}::build::{closure#0} (winhandle=...) at src/backend/wayland/window.rs:478
#22 0x0000555556af65b9 in glazier::backend::wayland::surfaces::surface::Data::with_handler_and_dont_check_the_other_borrows<(), glazier::backend::wayland::window::{impl#8}::build::{closure_env#0}> (
    self=0x555556ea95d0, f=...) at src/backend/wayland/surfaces/surface.rs:283
#23 0x0000555556af4c4b in glazier::backend::wayland::surfaces::surface::Data::with_handler<(), glazier::backend::wayland::window::{impl#8}::build::{closure_env#0}> (self=0x555556ea95d0, f=...)
    at src/backend/wayland/surfaces/surface.rs:269
#24 0x0000555556c0b6c6 in glazier::backend::wayland::surfaces::toplevel::Surface::with_handler<(), glazier::backend::wayland::window::{impl#8}::build::{closure_env#0}> (self=0x7fffffff8d98, f=...)
    at src/backend/wayland/surfaces/toplevel.rs:124
#25 0x0000555556b5c10a in glazier::backend::wayland::window::WindowBuilder::build (self=...) at src/backend/wayland/window.rs:476
#26 0x0000555556b96a8e in glazier::window::WindowBuilder::build (self=...) at src/window.rs:547
#27 0x0000555555b92fae in floem::app::{impl#2}::window::{closure#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>
    (cx=...) at src/app.rs:87
#28 0x0000555555be88c7 in leptos_reactive::runtime::{impl#2}::run_scope_undisposed::{closure#0}<(), floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>> (runtime=0x555556e9c248) at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/leptos_reactive-0.2.5/src/runtime.rs:357
#29 0x0000555555be5332 in leptos_reactive::runtime::with_runtime::{closure#0}<((), leptos_reactive::scope::ScopeId, leptos_reactive::scope::ScopeDisposer), leptos_reactive::runtime::{impl#2}::run_scope_undisposed::{closure_env#0}<(), floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>>> (runtimes=0x7ffff7c751f0) at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/leptos_reactive-0.2.5/src/runtime.rs:297
#30 0x0000555555bedf15 in std::thread::local::LocalKey<core::cell::RefCell<slotmap::basic::SlotMap<leptos_reactive::runtime::RuntimeId, leptos_reactive::runtime::Runtime>>>::try_with<core::cell::RefCell<slotmap::basic::SlotMap<leptos_reactive::runtime::RuntimeId, leptos_reactive::runtime::Runtime>>, leptos_reactive::runtime::with_runtime::{closure_env#0}<((), leptos_reactive::scope::ScopeId, leptos_reactive::scope::ScopeDisposer), leptos_reactive::runtime::{impl#2}::run_scope_undisposed::{closure_env#0}<(), floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>>>, core::result::Result<((), leptos_reactive::scope::ScopeId, leptos_reactive::scope::ScopeDisposer), ()>> (
    self=0x555556d8fae0, f=...) at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/thread/local.rs:446
#31 0x0000555555beb87c in std::thread::local::LocalKey<core::cell::RefCell<slotmap::basic::SlotMap<leptos_reactive::runtime::RuntimeId, leptos_reactive::runtime::Runtime>>>::with<core::cell::RefCell<slotmap::basic::SlotMap<leptos_reactive::runtime::RuntimeId, leptos_reactive::runtime::Runtime>>, leptos_reactive::runtime::with_runtime::{closure_env#0}<((), leptos_reactive::scope::ScopeId, leptos_reactive::scope::ScopeDisposer), leptos_reactive::runtime::{impl#2}::run_scope_undisposed::{closure_env#0}<(), floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>>>, core::result::Result<((), leptos_reactive::scope::ScopeId, leptos_reactive::scope::ScopeDisposer), ()>> (self=0x555556d8fae0, 
    f=<error reading variable: Cannot access memory at address 0x90>) at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/thread/local.rs:422
#32 0x0000555555be32d8 in leptos_reactive::runtime::with_runtime<((), leptos_reactive::scope::ScopeId, leptos_reactive::scope::ScopeDisposer), leptos_reactive::runtime::{impl#2}::run_scope_undisposed::{closure_env#0}<(), floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>>> (
    id=..., f=...) at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/leptos_reactive-0.2.5/src/runtime.rs:293
#33 0x0000555555be864e in leptos_reactive::runtime::RuntimeId::run_scope_undisposed<(), floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>> (self=..., f=..., parent=...) at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/leptos_reactive-0.2.5/src/runtime.rs:351
#34 0x0000555555bb4ccb in leptos_reactive::scope::Scope::run_child_scope<(), floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>> (self=..., f=<error reading variable: Cannot access memory at address 0x80>)
    at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/leptos_reactive-0.2.5/src/scope.rs:133
--Type <RET> for more, q to quit, c to continue without paging--
#35 0x0000555555bb4c83 in leptos_reactive::scope::Scope::child_scope<floem::app::{impl#2}::window::{closure_env#0}<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>>> (self=..., f=<error reading variable: Cannot access memory at address 0x10>) at /home/luke/.cargo/registry/src/github.com-1ecc6299db9ec823/leptos_reactive-0.2.5/src/scope.rs:115
#36 0x0000555555b929cb in floem::app::Application::window<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>> (self=..., app_view=0x555556e9bb60, config=...) at src/app.rs:71
#37 0x0000555555b931ac in floem::app::launch<floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>, fn(floem::app_handle::AppContext) -> floem::views::stack::Stack<(floem::views::label::Label, floem::views::stack::Stack<(floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>, floem::views::click::Click<floem::views::label::Label>)>)>> (app_view=0x7fffff7fe000) at src/app.rs:13
#38 0x0000555555b91536 in counter::main () at examples/counter/src/main.rs:86

[flukejones]

Can't build glazier with both backends (I'll file something there too):

error[E0659]: `application` is ambiguous
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/application.rs:21:21
   |
21 | use crate::backend::application as backend;
   |                     ^^^^^^^^^^^ ambiguous name
   |
   = note: ambiguous because of multiple glob imports of a name in the same module
note: `application` could refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:40:9
   |
40 | pub use x11::*;
   |         ^^^^^^
   = help: consider adding an explicit import of `application` to disambiguate
note: `application` could also refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:51:9
   |
51 | pub use wayland::*;
   |         ^^^^^^^^^^
   = help: consider adding an explicit import of `application` to disambiguate

error[E0659]: `clipboard` is ambiguous
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/clipboard.rs:16:25
   |
16 | pub use crate::backend::clipboard as backend;
   |                         ^^^^^^^^^ ambiguous name
   |
   = note: ambiguous because of multiple glob imports of a name in the same module
note: `clipboard` could refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:40:9
   |
40 | pub use x11::*;
   |         ^^^^^^
   = help: consider adding an explicit import of `clipboard` to disambiguate
note: `clipboard` could also refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:51:9
   |
51 | pub use wayland::*;
   |         ^^^^^^^^^^
   = help: consider adding an explicit import of `clipboard` to disambiguate

error[E0659]: `error` is ambiguous
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/error.rs:20:21
   |
20 | use crate::backend::error as backend;
   |                     ^^^^^ ambiguous name
   |
   = note: ambiguous because of multiple glob imports of a name in the same module
note: `error` could refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:40:9
   |
40 | pub use x11::*;
   |         ^^^^^^
   = help: consider adding an explicit import of `error` to disambiguate
note: `error` could also refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:51:9
   |
51 | pub use wayland::*;
   |         ^^^^^^^^^^
   = help: consider adding an explicit import of `error` to disambiguate

error[E0659]: `menu` is ambiguous
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/menu.rs:15:21
   |
15 | use crate::backend::menu as backend;
   |                     ^^^^ ambiguous name
   |
   = note: ambiguous because of multiple glob imports of a name in the same module
note: `menu` could refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:40:9
   |
40 | pub use x11::*;
   |         ^^^^^^
   = help: consider adding an explicit import of `menu` to disambiguate
note: `menu` could also refer to the module imported here
  --> /home/luke/.cargo/git/checkouts/glazier-3a172f69e2427c5a/ab692f5eb10e/src/backend/mod.rs:51:9
   |
51 | pub use wayland::*;
   |         ^^^^^^^^^^
   = help: consider adding an explicit import of `menu` to disambiguate

**SNIP etc etc**

wayland::window::WindowHandle` to implement `Into<window::WindowHandle>`

Some errors have detailed explanations: E0277, E0308, E0659.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `glazier` due to 34 previous errors

[birkskyum]

https://github.com/tauri-apps/tao could also be very relevant here.

[WeetHet]

Glazier seems to have numerous issues on Linux.

1. Default backend is X11. This is a problem for many reasons:
   a. x11 is unmaintained and no-longer the default graphics session on many distributions
   b. it then runs through XWayland, which causes further issues (root cause of [Invalid surface on Intel iGPU driver #16](https://github.com/lapce/floem/issues/16) )

2. It can't be compiled with both X11 and Wayland due to the way it imports items within itself.

3. The wayland backend currently segfaults (on gnome due to [Gtk backend crashes on startup (at least on wayland) linebender/glazier#81](https://github.com/linebender/glazier/issues/81))

I don't know if you want to continue on with glazier - winit is a solid alternative. Or maybe make floem window-management agnostic? Either way the inability to support both x11 and wayland is problematic where wayland should be the default with a fallback to x11.

As it stands the only possible way to run examples or lapce/floem branch on hybrid GPU linux systems is to offload to the dGPU (increasing power use considerably).

Isn't winit basically a standard by now? In my opinion, using winit is a great idea, why not?

[jrmoulton]

This has been discussed a few times (on the discord I think). The current reasoning is that glazier is positioning itself to be a better fit for what Lapce and floem will be used for which is desktop applications. Glazier is responsible for handling abstractions over differences in the OS (for things such as timers and menu items). Winit sees that as something that should be implemented as a separate crate and not core functionality. Lapce (and therefore floem) places importance on things like menu items and other similar things working.

From the glazier README

but the goal is to abstract over most of the other integration points with the underlying operating system.

In general, winit is probably more suitable for games and game-like applications, while Glazier is intended to provide more of the full desktop GUI experience, including system menus and support for IME.

This is the answer to the question of why not winit.

It does seem like progress on glazier is slow though and I'm doubtful that it will ever pick up traction in the community given the popularity of winit and from my experience support from glazier members is also currently slow. Floem also seems like it would be a good option for mobile but glazier doesn't intend to support it without contributions and without community traction I'm doubtful that will ever happen.

Do you still see progress moving forward on glazier @dzhou121?

[birkskyum]

This issue with desktop features was actually why I suggested TAO in the first place - it's a fork of winit, but adding all the desktop environment features we need, since Lapce and Tauri have shared needs there. From tao repo:

Acknowledgement This is a fork of winit which replaces Linux's port to Gtk. We need it not only because of webkit2gtk, but also a lot of Desktop Environment features like menu bar, system tray, global shortcuts etc. In the future, we want to make these features more modular as separate crates. So we can switch back to winit and also benefit the whole community.

[dzhou121]

Glazier team is working on a new wayland backend which is promising. TAO wouldn't work for us because GTK backend can't (or not easily) work with Wgpu.

[birkskyum]

Thank you for pointing that out - I wasn't aware of that incompatibility issue.

It seems like the glazier team already has removed gtk, so it would be interesting to know what the state of the issues initially mentioned by @flukejones are at this point.

[WeetHet]

This has been discussed a few times (on the discord I think). The current reasoning is that glazier is positioning itself to be a better fit for what Lapce and floem will be used for which is desktop applications. Glazier is responsible for handling abstractions over differences in the OS (for things such as timers and menu items). Winit sees that as something that should be implemented as a separate crate and not core functionality. Lapce (and therefore floem) places importance on things like menu items and other similar things working.

From the glazier README

but the goal is to abstract over most of the other integration points with the underlying operating system.

In general, winit is probably more suitable for games and game-like applications, while Glazier is intended to provide more of the full desktop GUI experience, including system menus and support for IME.

This is the answer to the question of why not winit.

It does seem like progress on glazier is slow though and I'm doubtful that it will ever pick up traction in the community given the popularity of winit and from my experience support from glazier members is also currently slow. Floem also seems like it would be a good option for mobile but glazier doesn't intend to support it without contributions and without community traction I'm doubtful that will ever happen.

Do you still see progress moving forward on glazier @dzhou121?

Yes, those are problems, but winit is used by many GUI libraries and is basically the only alive library now. Glazier is getting some work done but should we stick with is because it is more convenient in short term?

[jrmoulton]

@WeetHet I think sticking with glazier in the short term won't harm Floem. Even if Floem ever does switch away from glazer to winit it isn't going to be much more work then than it will be now (and likely less once problems in the winit scope are solved).

Floem currently uses glazier and for the reasons @dzhou121 mentioned switching to winit/tao isn't an option right now without at least a lot of work.

Glazier definitely isn't dead. It has the core functionality that is needed including features that are important to Lapce/Floem. The core developers working on Galzier are spread thin working on other problems in xilem and vello. Progress is slow but for now it is a good option for Floem.

Going forward it will likely remain a good option for Floem as the goals align well and progress does seem to move well when features are required.