The ConceptFrame currently provided with SCTK is not dpi-aware and could easily be.

When the application doesn't specify an XCursor theme/size, read it from XCURSOR_THEME and XCURSOR_SIZE. This allows the compositor to have primitive control over these settings.

This is already done by various X11 clients, Qt, Weston clients, mpv, glfw, etc.

As far as I can see, this is the only use of the rand crate in this entire library. The problem is that winit (the main user of this crate) also depends on rand(), but a different, incompatible version (0.6.1 vs sctk: 0.5.*). This means, if I compile winit, I have two duplicated versions of the rand crate.

But does opening file descriptors have to be cryptographically secure? Otherwise, I'd replace this with a simple xorshift or something different, since as far as I can see it's only about "opening the next available file descriptor".

Otherwise, would it be possible to update the rand dependency and publish it to crates, so that winit and sctk use the same major version of rand?

If the scale factor of an output changes, the surface hidpi-tracking will not pick it up until the next enter/leave event.

The ThemedPointer should be improved to support dpi-scaled icons loading.

From https://wayland.freedesktop.org/docs/html/apa.html#protocol-spec-wl_seat:

It is a protocol violation to issue this request on a seat that has never had the pointer capability.

Observed behaviour in alacritty and in the example clients (with WAYLAND_DEBUG=server):

[2601723.234] [email protected](4, "wl_seat", 5, new id [unknown]@27)
[2601723.259]  -> [email protected](2)
[2601723.267]  -> [email protected]("seat0")
[2601723.276] [email protected]_surface(new id wl_surface@28)
[2601723.287] [email protected]_pointer(new id wl_pointer@29)
listener function for opcode 0 of wl_seat is NULL
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 32, kind: BrokenPipe, message: "Broken pipe" }', src/libcore/result.rs:999:5
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

The bitfield value 2 sent by the server in the capability event means that the seat has keyboards but not pointer or touch devices. It should be easy to request the creation of the appropriate protocol objects based on the capabilities sent by the server.

It would be nice to add some initial support for layer-shell surfaces.
For example, these can be used by apps who need to display a top-level 'overlay' window.
While that's often the default initial configuration with stacking WM, this extra semantic precision helps tiling WM.
https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml
Looks like it could be a variant of ShellSurface.
That would make it easy to use by Window and maybe eventually winit.

With the 0.7 version, we get more flexibility to style CSD decorations. This is great.
There are still a few more parameters that would be useful in order to implement more refined CSD.

[colors]

1. button idle color when window is inactive - frequently inactive windows change button background in addition to header background.

[visibility]

2. min/max button visibility - need to be able to turn them on/off if we want more minimalist header.

[sizes]

3. button padding - height is already controlled by header size so that's fine, but it would be nice if we could specify start/end padding so that button aren't so narrow.

4. font_size - being able to specify font size that ultimately controls header size would be nice too.

Thanks!

Right now some error types are completely useless, so debugging such things or getting useful information to users is a bit hard.

Example

It'll be nice to return more meaningful errors instead of ().

Something similar (but simpler) than the Window type for xdg_popups, handling the multiple protocols compatibility issues as well.

This should be a simpler abstraction than Window as we don't need to deal with decorations.

We need some abstraction for pointer grab mechanisms, exposing a convenient API for the pointer-constraints and relative-pointer protocols.

When using set_title() and also handling an event of the windows implementation a mutex deadlock occurs.

set_title() triggers a FrameRequest::Refresh by locking the windows implementation. If the windows implementation is locked while inside the windows implementation then a deadlock occurs.

A small example being

match next_action.lock().unwrap().take() {
  Some(WEvent::Refresh) => {
    window.set_title("refreshed".into());
    window.refresh();
    window.surface().commit();
  }
}

I've run into an issue when running some examples dependant on this create.

Windows are created with their decorations outside of the top and left bounds of the monitor.

When I try and resize the window it panics with thread 'main' panicked at 'attempt to multiply with overflow', src/window/basic_frame.rs:380:27
Gnome activities overview seems to indicate a window with no size.

In src/window/mod.rs on resize start the Event::Configure event has a new_size of (1, 1)
frame.subtract_borders returns negative numbers which wrap at the end of new_size.map.
Changing the return value to (map(w, 1) as u32, max(h, 1) as u32) fixes the panic.

It seems like it's not reporting the window size or the decorations to the shell.

It's using the xdg shell.
I've tried it with the client-toolkit selection and gfx quad examples.
Gnome 3.28.2

I noticed the wl_shm helper uses a regular temporary directory to create an in-memory file. This should probably be replaced with XDG_RUNTIME_DIR as creating a file for wl_shm backed by a disk should really be avoided.

Also, it's possible to create the file, open it, and immediately unlink it to make sure we're not leaking it.

Bonus point: some systems support better ways to allocate an anonymous file (see https://github.com/myfreeweb/shmemfdrs). Some systems also support file sealing which can ensure the file won't shrink (shrinking a file can cause SIGBUS on the compositor side, it's currently mitigated with a signal handler but it's a pretty hacky solution).

The root global of the data device tree is the wl_data_device_manager.

I'm not yet very familiar with this part of the protocol.

This causes thread 'main' panicked at 'Attemping to create an object from a non-attached proxy.' when trying to get a frame callback from a sctk-created surface.

I guess I should've realized that it's not Main but I was completely baffled by this error, wondering what the hell is going on with my frame callback for quite some time >_<

Or at least I couldn't find it. I'm guessing it's in logical pixels with respect to the current surface DPI factor?

It seems like graphics tablets are currently unsupported. There is a protocol extension https://docs.rs/wayland-protocols/0.27.0/wayland_protocols/unstable/tablet/index.html

What is the scope of client-toolkit? It seems to me that some of the stuff that is handled in winit could be moved over here, like utilities for hidpi handling for example.

I could just use winit of course but I'm interested in experimenting with a new wayland protocol for creating menus, like for example in macosx where they are part of the window manager. In particular I want to create a spacemacs style compositor.

Format of colors is ARGB.

colors:
  primary_color: 0xff101010,
  secondary_color: 0xffffffff,
  close_button_color: 0xff101010,
  close_button_icon_color: 0xffffffff,
  maximize_button_color: 0xff101010,
  maximize_button_icon_color: 0xffffffff,
  minimize_button_color: 0xff101010,
  minimize_button_icon_color: 0xffffffff,

Close button has strange colors due to winit bug, but maximize and minimize buttons should reflect current SCTK behavior.

When a window is created in weston, the first time a user tries to resize it, it they do so from the top or left border, the window jumps at the opposite side of the pointer.

This only happens with the first resize.

I noticed that when a very large window size (around u32::max_value()) is specified via set_max_size, it causes a protocol error with the following error message:

xdg_toplevel@31: error 4: invalid negative max size requested -256 x -226
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 71, kind: Other, message: "Protocol error" }', src/libcore/result.rs:1084:5
...

There are two potential sources of integer overflow that cause this problem. The first one is conversion from u32 to i32:

Would it be a good idea to use saturating arithmetic in these places to prevent them from wrapping around to negative values?

Example: take kbd_input.rs and replace the event loop with the following:

    let window = Arc::new(Mutex::new(window));
    {
        let window = window.clone();
        std::thread::spawn(move || {
            loop {
                window.lock().unwrap().refresh();
                std::thread::sleep_ms(100);
            }
        });
    }

    loop {
        event_queue.dispatch().unwrap();
    }

Crash:

thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:71
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/sys_common/backtrace.rs:59
             at src/libstd/panicking.rs:197
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:211
   4: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:381
   6: rust_begin_unwind
             at src/libstd/panicking.rs:308
   7: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
   8: core::panicking::panic
             at src/libcore/panicking.rs:49
   9: core::option::Option<T>::unwrap
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/macros.rs:12
  10: <smithay_client_toolkit::window::concept_frame::ConceptFrame as smithay_client_toolkit::window::Frame>::redraw::{{closure}}
             at src/window/concept_frame.rs:468
  11: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &mut F>::call_once
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/ops/function.rs:279
  12: core::option::Option<T>::map
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/option.rs:416
  13: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/iter/adapters/mod.rs:570
  14: <core::iter::adapters::flatten::FlattenCompat<I,U> as core::iter::traits::iterator::Iterator>::next
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/iter/adapters/flatten.rs:219
  15: <core::iter::adapters::flatten::FlatMap<I,U,F> as core::iter::traits::iterator::Iterator>::next
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/iter/adapters/flatten.rs:49
  16: <alloc::vec::Vec<T> as alloc::vec::SpecExtend<T,I>>::from_iter
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/liballoc/vec.rs:1819
  17: <alloc::vec::Vec<T> as core::iter::traits::collect::FromIterator<T>>::from_iter
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/liballoc/vec.rs:1731
  18: core::iter::traits::iterator::Iterator::collect
             at /rustc/a53f9df32fbb0b5f4382caaad8f1a46f36ea887c/src/libcore/iter/traits/iterator.rs:1465
  19: <smithay_client_toolkit::window::concept_frame::ConceptFrame as smithay_client_toolkit::window::Frame>::redraw
             at src/window/concept_frame.rs:462
  20: smithay_client_toolkit::window::Window<F>::refresh
             at ./src/window/mod.rs:406
  21: crash::main::{{closure}}
             at examples/crash.rs:125

An early version is available in wayland-protocols : https://docs.rs/wayland-protocols/0.20.1/wayland_protocols/misc/server_decoration/client/index.html

There is also ongoing discussion on the wayland mailling lists and some variant of the protocol is likely to be soon standardized : https://lists.freedesktop.org/archives/wayland-devel/2018-April/037933.html

The idea would be to make a ServerFrame<F: Frame> implementing window::Frame that would use the server decoration protocol if available and if not fallback to the F frame.

Will smithay-client-toolkit support server-side decorations?

For example, here is a build failure on mips-unknown-linux-gnu:

error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/basic_frame.rs:40:19
   |
40 |           if active {
   |  ___________________^
41 | |             #[cfg(target_endian = "little")]
42 | |             return [0x80, 0x80, 0x80, 0xFF];
43 | |             #[cfg(target_endian = "big")]
44 | |             [0xFF, 0x80, 0x80, 0x80];
   | |                                     - help: consider removing this semicolon
45 | |         } else {
   | |_________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/basic_frame.rs:45:16
   |
45 |           } else {
   |  ________________^
46 | |             #[cfg(target_endian = "little")]
47 | |             return [0x60, 0x60, 0x60, 0xFF];
48 | |             #[cfg(target_endian = "big")]
49 | |             [0xFF, 0x60, 0x60, 0x60];
   | |                                     - help: consider removing this semicolon
50 | |         }
   | |_________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/basic_frame.rs:89:38
   |
89 |               ButtonState::Disabled => {
   |  ______________________________________^
90 | |                 #[cfg(target_endian = "little")]
91 | |                 return [0x20, 0x80, 0x80, 0xFF];
92 | |                 #[cfg(target_endian = "big")]
93 | |                 [0xFF, 0x80, 0x80, 0x20];
   | |                                         - help: consider removing this semicolon
94 | |             }
   | |_____________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/concept_frame.rs:40:19
   |
40 |           if active {
   |  ___________________^
41 | |             #[cfg(target_endian = "little")]
42 | |             return [0xE6, 0xE6, 0xE6, 0xFF];
43 | |             #[cfg(target_endian = "big")]
44 | |             [0xFF, 0xE6, 0xE6, 0xE6];
   | |                                     - help: consider removing this semicolon
45 | |         } else {
   | |_________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/concept_frame.rs:45:16
   |
45 |           } else {
   |  ________________^
46 | |             #[cfg(target_endian = "little")]
47 | |             return [0xDC, 0xDC, 0xDC, 0xFF];
48 | |             #[cfg(target_endian = "big")]
49 | |             [0xFF, 0xDC, 0xDC, 0xDC];
   | |                                     - help: consider removing this semicolon
50 | |         }
   | |_________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/concept_frame.rs:60:16
   |
60 |           } else {
   |  ________________^
61 | |             #[cfg(target_endian = "little")]
62 | |             return [0x78, 0x78, 0x78, 0xFF];
63 | |             #[cfg(target_endian = "big")]
64 | |             [0xFF, 0x78, 0x78, 0x78];
   | |                                     - help: consider removing this semicolon
65 | |         }
   | |_________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/concept_frame.rs:70:37
   |
70 |               ButtonState::Hovered => {
   |  _____________________________________^
71 | |                 #[cfg(target_endian = "little")]
72 | |                 return [0x52, 0x43, 0xD9, 0xFF];
73 | |                 #[cfg(target_endian = "big")]
74 | |                 [0xFF, 0xD9, 0x43, 0x52];
   | |                                         - help: consider removing this semicolon
75 | |             }
   | |_____________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/concept_frame.rs:82:37
   |
82 |               ButtonState::Hovered => {
   |  _____________________________________^
83 | |                 #[cfg(target_endian = "little")]
84 | |                 return [0x70, 0xCB, 0x2D, 0xFF];
85 | |                 #[cfg(target_endian = "big")]
86 | |                 [0xFF, 0x2D, 0xCB, 0x70];
   | |                                         - help: consider removing this semicolon
87 | |             }
   | |_____________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error[E0308]: mismatched types
  --> /cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.3/src/window/concept_frame.rs:94:37
   |
94 |               ButtonState::Hovered => {
   |  _____________________________________^
95 | |                 #[cfg(target_endian = "little")]
96 | |                 return [0xE8, 0xAD, 0x3C, 0xFF];
97 | |                 #[cfg(target_endian = "big")]
98 | |                 [0xFF, 0x3C, 0xAD, 0xE8];
   | |                                         - help: consider removing this semicolon
99 | |             }
   | |_____________^ expected array of 4 elements, found ()
   |
   = note: expected type `[u8; 4]`
              found type `()`
                                                                                
error: aborting due to 9 previous errors
                                                                                
For more information about this error, try `rustc --explain E0308`.
error: Could not compile `smithay-client-toolkit`.
warning: build failed, waiting for other jobs to finish...
error: build failed

The xdg_output protocol extension allows the compositor to provide additional metadata about the outputs, we need to retrieve and expose it.

Combined with the physical size from wl_output it can for example be used to compute a fractional scaling factor for the outputs.

The wp_viewporter extension, when supported by the compositor, allows the client to crop and resale the contents of a buffer before it is displayed.

Example uses can be:

• pre draw some single large buffer, and animate movement over it by simply moving the viewport
• useful for rescaling video playback into some UI component

We should provide some sort of example showing how to send messages from a tokio event loop.

Currently SCTK will explicitly request SSD when creating a window, but call unset_mode() when the user calls set_decorate(true), then following the compositor's preference.

This leads to inconsistencies when the compositor prefers CSD but honors SCTK's request for SSD at startup: if decorations are disabled then re-enabled, they will appear as CSD.

What should be do? Always prefer SSD or always follow the compositor preference?

I find the map_keyboard_with_repeat API a bit too high level for a toolkit.
If possible I think it would be nicer to let the users (higher level frameworks?) explicitly setup what's needed.
That would require to show the xkb layout keycode->keysym mapper.

P.S: Users of calloop key repeat helper are probably looking for that higher level anyway so the
glued together combined map/unfold over the keyboard input callback should be fine for that case.

Currently we double-buffer, but do not make sure the server has finished using our buffers before destroying and overwriting them. We should wait for wl_buffer.release events.

This is coming from from much higher in the stack, but in my testing on Alacritty, which uses this library via winit, changing the button color (other than the hovered color) doesn't seem to do anything. Can anyone observe similar results?

libwayland has a limit for 4KB for a title, which could lead to a protocol error if you set a very long title, so limiting title to 1KB could prevent random crashes in apps, which forward title right away, without checking (e.g. alacritty).

It'd be good to make an alternative implementation of repetition based on calloop timers, making it possible for an user already using calloop integration in wayland-client to also insert key repetitions in it, avoiding to spawn one more thread.

Its pixels disappear when moving the mouse across them, so it's probably a damage issue? Occurs on default examples, e.g. themed_frame, as well as alacritty.

I don't think that it's a desirable behavior for a library to log random things to stdout. I guess using https://github.com/rust-lang/log could improve things and downstream clients could filter out the library logging if they want to.

The memmap crate, that SCTK currently uses for memory-mapping in the SHM helpers (MemPool and DoubleMemPool) seems to be unmaintained. It has not received a single commit in 2 years, and has several reported issues.

We probably need to consider choosing an other one.

Initially reported as rust-windowing/winit#993.

The rapid succession:

• press SHIFT
• press E
• release SHIFT
• release E

causes the key repetition of e to be erroneously triggered once, even if the E was pressed for shorter than the repeat delay.

This reproduces using the kbd_input example.

Running mutter-3.34.3-2.fc31.x86_64 (and/or whatever the default wayland/gnome 3 environment is on Fedora); you can repro this with:

cargo run --release --example themed_frame

clicks in the titlebar go through to whatever is behind the window.

I'm using client-toolkit 0.6 in my real app, but the same issue can be reproduced with master.

I suspect that mutter likely recently changed its behavior as I only started to hit this today after a reboot, although it has been bothering a friend that reported it in wez/wezterm#139 for about a week.

In alacritty, sometimes when gaining back focus after it being lost (because I started a program), the key repetition of <enter> is triggered even though the key on my keyboard is not.

I think this is because alacritty lost the focus while the <enter> key was pressed, and for some reason the repetition triggered again when the focus was re-gained. This is very likely a bug in sctk.

This allows virtual keyboards and IME to work.

https://github.com/wayland-project/wayland-protocols/blob/master/unstable/text-input/text-input-unstable-v3.xml

Just do a TTY switch and try to resize a window, it should freeze and just update a border(at least on sway).

Works just fine on v0.6.x, so I'd assume a v0.7.0 regression.

Had been thinking about it for some time, so writing all this here for potential feedback.

Up to now, my main drive for SCTK was using it to implement winit's Wayland support. This has affected SCTK's development, in that I never really took time to do serious API design.

Currently, SCTK is just a pile of loosely coupled helpers to simplify writing Wayland apps, rather than an integrated toolkit. I've recently decided to reduce my involvement in winit and focus back on Smithay and SCTK. Following this, I'd like to work into making SCTK into a proper toolkit for writing Wayland apps.

This issues will serve to collect design ideas in general, I don't have a lot to put in yet and any input of people using or willing to use SCTK would be welcome.

It looks like the wayland client toolkit fails to build on OpenBSD 6.4. This has been reported to Alacritty here: alacritty/alacritty#1784.

The relevant error output is the following:

   Compiling smithay-client-toolkit v0.4.1
error[E0432]: unresolved import `nix::sys::memfd`
 --> /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.4.1/src/utils/mempool.rs
  |
4 | use nix::sys::memfd;
  |     ^^^^^^^^^^^^^^^ no `memfd` in `sys`

error: aborting due to previous error

I'd propose a breaking change to make this crate empty by default if the build target is not Linux, this way it should always build on all systems. Note that other crates like winapi do something similar.

When running alacritty master (alacritty/alacritty@14dc170) on Weston-8.0.0, I get a panic:

RUST_BACKTRACE=full ./alacritty/target/debug/alacritty

thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 1, kind: PermissionDenied, message: "Operation not permitted" }', src/libcore/result.rs:1188:5
stack backtrace:
   0:     0x55f9e1395f64 - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::h7b11b2a23cd910b3
   1:     0x55f9e13b966c - core::fmt::write::hca7efce6c0791439
   2:     0x55f9e1392ac7 - std::io::Write::write_fmt::he56b7f6fb86cf3b5
   3:     0x55f9e139822e - std::panicking::default_hook::{{closure}}::hf51e7f0a7424f5cd
   4:     0x55f9e1397f21 - std::panicking::default_hook::he8ba9c8182908cf7
   5:     0x55f9e139890b - std::panicking::rust_panic_with_hook::hf9a08396e191b616
   6:     0x55f9e13984be - rust_begin_unwind
   7:     0x55f9e13b5a6e - core::panicking::panic_fmt::h1ec1b70c49f8bf0e
   8:     0x55f9e13b5b67 - core::result::unwrap_failed::h9d4b97b9a9041349
   9:     0x55f9e11bb6e3 - core::result::Result<T,E>::unwrap::h461ed369cb24ece9
                               at /build/rust/src/rustc-1.41.0-src/src/libcore/result.rs:956
  10:     0x55f9e114c43e - smithay_client_toolkit::keyboard::KbState::init_with_fd::hb7b864f674677262
                               at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.6.6/src/keyboard/mod.rs:302
  11:     0x55f9e0f94222 - <smithay_client_toolkit::keyboard::KbdHandler<Impl,RepeatImpl> as wayland_client::protocol::wl_keyboard::EventHandler>::keymap::hcf78d802990a4f5b
                               at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/smithay-client-toolkit-0.6.6/src/keyboard/mod.rs:834
  12:     0x55f9e0fa1aef - <wayland_client::protocol::wl_keyboard::WlKeyboard as wayland_client::proxy::HandledBy<T>>::handle::hf6902ab43d9c5639
                               at /home/daniel/src/alacritty/target/debug/build/wayland-client-5043a85dfcd418bb/out/wayland_api.rs:7523
  13:     0x55f9e0f6c1e7 - wayland_client::proxy::NewProxy<I>::implement::{{closure}}::h76b0197b36b56539
                               at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.23.6/src/proxy.rs:369
  14:     0x55f9e0f9973b - <alloc::boxed::Box<F> as core::ops::function::FnMut<A>>::call_mut::h0a8530b4628d3528
                               at /build/rust/src/rustc-1.41.0-src/src/liballoc/boxed.rs:1029
  15:     0x55f9e0fd19b3 - wayland_client::imp::proxy::proxy_dispatcher::{{closure}}::hc1e623a00100b545
                               at /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/wayland-client-0.23.6/src/native_lib/proxy.rs:369

was for LoopHandle in map_keyboard_with_repeat which does not exists for map_keyboard

First locked in setup_surface{quick_assign} for enter/leave
The callback is called from recompute_scale_factor.
Suggestion:
Don't pass the callback to enter/leave (locked).
call recompute_scale_factor directly from the event handler, make it return new_scale_factor.
unlock
Call the callback

Following 1c6ac4c, the Frame now has access to the whole set of XDG states for the window. This includes the Tiled* states, which notify that the window is tiled on some of its sides.

The ConceptFrame should take this information into account, by unmapping the invisible subsurfaces for the associated tiled sides, so that it does not display resizing cursor hints on tiled sides.