01:32 Nosrep: because the registry's global_remove event only gives a uint32_t, do i have to keep track of the name myself (and do i even need to handle global_remove? wl-clipboard looks like it doesn't)
01:32 danieldg: you don't have to, no
01:33 danieldg: you can also just track the id of any resources you bind
01:33 danieldg: remove is mostly only for outputs and seats, if you don't use those you don't care
01:36 Nosrep: ic
01:36 Nosrep: then ill probably just track the name of the seat (or copy wl-clipboard and not care :x)
01:39 danieldg: wl-clipboard is short-running; removals mostly only matter for long-running things
01:54 Nosrep: wl-paste has a watch mode, but idk if that uses a different listener? i dont think so though
01:55 danieldg: no, that one is longer-lived but not really meant to be 'forever'
01:56 danieldg: though if you use it as a daemon I guess it does live long enough that it should handle removals
02:14 Nosrep: so let's say the wl_seat gets removed or something, do i have to destroy the zwlr_data_control_device too or will it call finish itself or something?
02:15 danieldg: you should destroy it just to free the id; it might fire finish for you, though
02:17 Nosrep: aight thanks
06:43 emersion: mstoeckl: thanks for trying to simplify the buffer size control MR
06:43 emersion: last time i looked, i just didn't understand it fully
07:53 pq: cambrian_invader, if you don't use --log argument to weston, it prints all logs to stdout/err. Maybe your systemd service unit discards that somehow, or maybe the logs get associated with a unit you did not expect? Are you sure 'weston' is an actual binary and not a script messing with the output redirection?
07:55 pq: cambrian_invader, maybe the logs go to the user journal, not system journal?
08:05 narodnik: for the keyboard listener event keymap, do I really need to use mmap in rust, thus forcing me to load libc in my code?
08:05 emersion: mmap is a system call
08:06 emersion: you don't necessarily need libc to do that
08:06 emersion: although my understanding is that the Rust stdlib uses libc
08:06 narodnik: yeah i still need to manually load it in my user code
08:07 narodnik: so i can access mmap
08:08 emersion: you can just do the syscall
08:12 narodnik: not possible without adding an external library
08:14 emersion: you don't need any external lib do perform a syscall
08:15 narodnik: well i then need some assembly code, right?
08:15 narodnik: or how would i do that
08:17 emersion: i would hope that at least a crate exists for this
08:18 emersion: some links:
08:18 emersion: https://github.com/jasonwhite/syscalls
08:18 emersion: https://github.com/rust-lang/rfcs/issues/2610
08:18 emersion: with Go, you would be able to just compile with CGO_ENABLED=0 to get this behavior
08:19 emersion: anyways, this dives into a Rust discussion not really related to Wayland
08:21 pq: narodnik, I believe "mmappable" is a stricter requirement than "readable", so I think using read system calls should be fine too, as long as you avoid relying on the file offset property of the file description.
08:22 pq: I don't know why simply reading wouldn't work.
08:22 emersion: indeed
08:22 emersion: use pread over read
08:23 pq: I have no idea how that translates to Rust though.
08:23 pq: I'd expect Rust APIs to not rely on the shared file offset to begin with.
08:23 pq: but I don't know
08:25 emersion: pq, be it mmap or read, i think the Rust stdlib just calls libc
08:25 pq: but pread vs. read?
08:25 emersion: i don't know how/if the stdlib exposes this
08:26 pq: I'd expect read without p to not be exposed at all
08:26 emersion: doesn't seem to be in the stdlib https://docs.rs/positioned-io/latest/positioned_io/
08:27 pq: d'oh
08:27 emersion: read without p is exposed in the stdlib, but not with this name of course
08:28 emersion: File::open then read_exact for instance, i'd expect that results in a libc read() call
08:28 pq: I would have expected a Rust file wrapper object to keep track of the position itself instead of relying on the kernel.
08:28 pq: oh well, doesn't matter what we expect
08:30 pq: one should never assume and always check the API doc - in this case one cannot trust Rust safety, because Rust is not the one opening the file.
08:32 emersion: https://github.com/rust-lang/rust/blob/b657dc555b1ecf837cc4ea471fbae6a731529d55/library/std/src/sys/unix/fd.rs#L88
08:33 emersion: hm, i should stop getting myself into such rabbit holes
08:33 pq: haha
08:34 pq: looks like read_at uses pread
08:35 emersion: yes, so maybe that crate linked above was from a time when the stdlib was missing this feature
08:36 emersion: https://doc.rust-lang.org/std/os/unix/fs/trait.FileExt.html#tymethod.read_at
08:36 emersion: hm, this is specific to Unix though
08:38 emersion: yeah, the crate provides the functionality on more platforms
08:38 emersion: https://github.com/vasi/positioned-io/blob/master/src/unix.rs
08:38 emersion: alright, time to stop now :P
08:56 narodnik: pq, emersion: it's fine, I will use libc library for mmap
08:56 narodnik: i realized it's already being used in my ffi bindings for wayland
09:06 vyivel: can xdg_popups be remapped? afaiu, an xdg_surface must ack a configure event before committing with a buffer attached, and mutter/kwin seem to never send one to an already unmapped popup; however, if xdg_popup.reposition is sent, weston and anvil(smithay) reply with a configure event anyway, which technically allows the xdg_popup to map again
09:06 vyivel: unless i'm mistaken, xdg-shell doesn't really forbid remapping xdg_popups, but then mutter/kwin behavior seems strange
09:07 vyivel: xdg_popup.reposition description states that "a xdg_popup.repositioned followed by xdg_popup.configure and xdg_surface.configure will be emitted in response", regardless of whether the xdg_popup is mapped
09:11 jadahl: vyivel: the only way to map a popup is xdg_surface.get_popup(). you should be able to remap the same wl_surface by recreating that role
09:12 emersion: jadahl: what about attaching a NULL buffer to unmap, then doing an initial commit?
09:12 jadahl: emersion: only meant to work with xdg_toplevel IIRC
09:12 jadahl: get_popup()+grab() needs a serial
09:12 emersion: right, but that would be without a grab
09:13 jadahl: seems only xdg_toplevel defines what happens if you attach null
09:17 jadahl: iirc when this was designed, the conclusion was that xdg_popup was not remappable without a new get_popup, but xdg_toplevel could be.
09:18 jadahl: this was discussed during the time when we decided whether to allow attach(null) at all
09:19 vyivel: so, a compositor should (try to; it's racy anyway) never send configure events to a popup that has been mapped and unmapped, and the client must never remap it, right?
09:22 jadahl: thats my interpretation - only send a configure to an unmapped popup in response to get_popup
09:25 vyivel: a configure isn't sent in response to get_popup, that would be too early
09:25 vyivel: it's sent in response to an initial commit
09:29 jadahl: sure, I mean on a new xdg_popup, not a reused one
09:29 jadahl: sorry for the confusion
09:31 pq: what's a good phrase for "B must be after A, and only once after each A" without implying "immediately"?
10:11 wlb: weston Issue #780 opened by Pekka Paalanen (pq) Toytoolkit window minimum size no longer respected https://gitlab.freedesktop.org/wayland/weston/-/issues/780 [Clients]
10:52 wlb: wayland Merge request !329 opened by Simon Ser (emersion) Draft: Add support for the deprecated-since XML attribute https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/329
11:05 kennylevinsen: pq: "each A must eventually be followed by exactly one B"?
11:05 kennylevinsen: or "by a matching B"
11:11 pq: kennylevinsen, there cannot be B for a different A in between.
11:11 kennylevinsen: So you can have multiple A's, and each needs to have a B, and the B's must be in order?
11:12 pq: only ABABABAB is allowed. AA cannot happen, BB is not allowed.
11:13 kennylevinsen: Would "ABA" be technically be allowed with no further traffic? (no answered B but also no further A)
11:15 pq: yes, because it's a transient state
11:15 pq: a necessary transient state
11:16 kennylevinsen: "each A must be acknowledged by B before further A"?
11:17 pq: that's from server perspective, how about from client perspective?
11:18 kennylevinsen: to clarify, A is client-to-server, B is server-to-client? or other way around?
11:18 pq: the other way around
11:20 pq: I presume there is no good phrase for this, like there is "iff" for "if and only if".
11:21 kennylevinsen: Hmm. I think the mentioned description works fine for both server and client.
11:23 kennylevinsen: In my head, the "before further A" implies that the answer is not required immediately
11:24 pq: sure, but it also implies that "further A" is expected; it's not
11:24 pq: further A is possible only after restarting sequence
11:24 kennylevinsen: True. "... can occur" perhaps? You might also have an idea of whether a B *should* occur, which is not currently communicated.
11:25 pq: too difficult in abstract :-)
11:25 kennylevinsen: Indeed, and I assume it's abstract for good reason. :)
11:25 pq: yeah, I was curious if there is a generic phrase
11:26 kennylevinsen: No silver bullet without extra words to describe the exact phrase you mentioned - my main ideas is to use a less complicated phrase :)
11:27 kennylevinsen: e.g., the client has less requirements: "A must eventually be acknowledged by B" fits the abstract, with server having more words.
11:27 kennylevinsen: client does not care about ABAB ordering as that's enforced by the server
11:28 pq: but ABB would be wrong
11:29 pq: or B without A
11:29 kennylevinsen: I feel that "acknowledge" in the B description implicitly excludes ABB and B.
11:30 narodnik: https://github.com/eyelash/tutorials/blob/master/wayland-input.c#L52
11:30 narodnik: is this code still the correct way to implement this function?
11:31 kennylevinsen: Otherwise, clarify: "B acknowledges a pending A. B without pending A is an error."
11:32 kennylevinsen: (also implied if A change state from pending to active, but being explicit can be good.)
11:41 wlb: weston Merge request !1324 opened by Marius Vlad (mvlad) Revert "clients/window: Update min_allocation for smaller widths/heights" https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1324 [Toytoolkit]
11:46 emersion: narodnik: no, need MAP_PRIVATE iirc
11:47 emersion: also completely missing error handling
11:48 narodnik: ok ty
11:48 narodnik: i found this https://wayland-book.com/seat/keyboard.html
12:01 wlb: wayland/main: Simon Ser * protocol: fix whitespace https://gitlab.freedesktop.org/wayland/wayland/commit/72da004b3eed protocol/wayland.xml
12:01 wlb: wayland Merge request !324 merged \o/ (protocol: fix whitespace https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/324)
12:19 wlb: weston Issue #780 closed \o/ (Toytoolkit window minimum size no longer respected https://gitlab.freedesktop.org/wayland/weston/-/issues/780)
12:19 wlb: weston Merge request !1324 merged \o/ (Revert "clients/window: Update min_allocation for smaller widths/heights" https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1324)
12:19 wlb: weston/main: Marius Vlad * Revert "clients/window: Update min_allocation for smaller widths/heights" https://gitlab.freedesktop.org/wayland/weston/commit/5b1207a425f1 clients/window.c
12:22 pq: What's your favorite toolkit for writing "small" Wayland apps where you also need low-level access to all Wayland details, e.g. get a hand of the wl_surface backing a sub-surface used with OpenGL, and custom protocol extensions?
12:23 pq: while being able to easily have simple widgets like buttons, sliders, and non-editable text
12:28 emersion: *crickets*
12:29 emersion: more seriously, maybe one of these GL mini-toolkits?
12:29 pq: hmm. Would they let me pick an arbitrary EGLConfig? Particularly 16F.
12:30 pq: I don't need GUI widgets *in* OpenGL, but I do need one widget that gives me an OpenGL sub-surface to do what I want with.
12:30 pq: hmm, but GUI widgets in OpenGL could help...
12:31 pq: right now I'm trying to use Weston's toytoolkit and I find myself reinventing the concept of a "button" from Cairo primitives and wl_pointer events. >_<
12:32 kchibisov: gui toolkits exposing details is a rare thing I'd say.
12:32 pq: this was supposed to be a fun side-project, but not *this* fun
12:32 pq: indeed
12:32 kchibisov: Like I know that with winit you can do most of it, it'll just take a bit of time.
12:33 kchibisov: And your custom protocol will be handled on your own, but you have wl_display/wl_surface and such.
12:33 pq: I imagine the Rust raw_window_handle etc. smithay toolkit ecosystem might come really close, after you bolt ICED widgets on it
12:33 kchibisov: For your case egui could be more or less what you want.
12:33 pq: which is something I want to do, but... later
12:34 kchibisov: if you want to have 1-2 buttons and such.
12:34 pq: hmm
12:34 pq: and text?
12:34 pq: simple text
12:34 kchibisov: Yeah, very simple text with egui as well.
12:34 kchibisov: it's like imgui.
12:34 pq: alright
12:35 kchibisov: I just know that you can achieve what you want with glutin + winit under like 10-20 mins.
12:35 kchibisov: If we rule out buttons.
12:35 kchibisov: Because glutin exposes all the EGL config picking on you.
12:35 pq: yeah, I've occasionally typing a glutin+winit app at home for a few months now
12:36 kchibisov: I've been doing that for like 5 years.
12:36 pq: but I will also be needing direct Wayland access
12:36 kchibisov: You can do so.
12:36 kchibisov: You take the display, create a queue out of it and you're good to go.
12:36 kchibisov: And dispatch the queue inside your `run`.
12:36 kchibisov: alacritty does that for a long time.
12:37 kchibisov: Because we needed frame callbacks, and winit has some issues with making them in, so we have our own queue to do what we want.
12:37 pq: I see
12:38 kchibisov: So you can do anything you want outside of winit, except when you'd need a reference to e.g. xdg_toplevel or some winit object.
12:38 kchibisov: (unless it's wl_surface exposed by winit)
12:40 kchibisov: Though, nothing stops winit from exposing the role objects.
12:41 wlb: weston Issue #769 closed \o/ (xwayland _NET_WM_STATE_ABOVE property / gitk crash relative & abs positioning https://gitlab.freedesktop.org/wayland/weston/-/issues/769)
12:41 wlb: weston/main: Derek Foreman * xwayland: Fix assert with some parented windows https://gitlab.freedesktop.org/wayland/weston/commit/123e921871c8 libweston/desktop/surface.c
12:41 wlb: weston/main: Derek Foreman * libweston-desktop: Unset use_geometry when unsetting relative_to https://gitlab.freedesktop.org/wayland/weston/commit/eebbe26d7b3c libweston/desktop/surface.c
12:41 kchibisov: it's just, if there's a direct need to expose some internals, we can make it.
12:41 wlb: weston Merge request !1305 merged \o/ (xwayland: Fix assert with some parented windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1305)
12:58 bl4ckb0ne: pq im working on a window toolkit oriented on buffer handling specially for that kind of opengl use case
12:59 kchibisov: window toolkit or gui?
12:59 kchibisov: Because for example window toolkit shouldn't even care about buffers, it's al on users.
13:00 pq: cool, what project is that?
13:00 wlb: weston Merge request !1325 opened by Philipp Zabel (pH5) libweston: set the presentation clock in the compositor https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1325
13:01 bl4ckb0ne: window toolkit
13:02 kchibisov: Is it similar to what glfw/sdl does? Where it ties the graphics/windowing together, so you have to express the buffer handling and develop pixel formats of some sort?
13:03 bl4ckb0ne: https://git.sr.ht/~bl4ckb0ne/hel/ very wip, i get about an hour every other day to work on it
13:03 bl4ckb0ne: basically its vk wsi but rendering api agnostic
13:04 bl4ckb0ne: not similar to glfw/sdl, it doesnt touch the rendering part
13:04 bl4ckb0ne: i started it because i was getting annoyed at the lack of gl flexibility from sdl
13:04 kchibisov: Ah, so you do similar to what miniquad does in rust.
13:05 kchibisov: Well, not exactly though.
13:06 bl4ckb0ne: im still thinkering event processing, if i do full async like wayland or queue everything then dispatch
13:07 kchibisov: queue won't work cross platform.
13:07 kchibisov: callback based will work.
13:07 kchibisov: But I don't think you care?
13:07 bl4ckb0ne: why?
13:07 kchibisov: I mean, I doubt you care to support macOS/Windows.
13:08 kchibisov: Because on macOS queue can't work due its design.
13:08 bl4ckb0ne: i do plan on that yeah
13:08 kchibisov: And on ios queue also won't really work.
13:08 bl4ckb0ne: what i mean is some kind of event buffer like openxr does
13:08 kchibisov: you can't buffer on macOS.
13:08 kchibisov: At least, not all events.
13:09 kchibisov: Are you familiar with how macOS windowing works?
13:09 bl4ckb0ne: not at all
13:10 kchibisov: You basically inherit their default window stuff and must implement methods.
13:10 kchibisov: macOS calls you back to the methods it expects to be implemented.
13:10 kchibisov: Some methods require sync handling.
13:10 kchibisov: As in they must do certain action without any buffering right away.
13:11 kchibisov: Winit was queue based in early days, but then we moved to callbacks because how macOS/Windows works.
13:11 kchibisov: And Wayland/X11 you can make whatever.
13:11 kchibisov: You can't even have a good js like event loop with macOS windowing system, because it's not even kqueue.
13:13 kchibisov: You also can't really make wsi like interface on macOS either.
13:13 kchibisov: Unless you go full metal or ANGLE.
13:14 kchibisov: where ANGLE is basically does that on top of metal.
13:14 kchibisov: With their GL you won't go far.
13:15 wlb: weston/main: Derek Foreman * xwayland: Use weston_coord https://gitlab.freedesktop.org/wayland/weston/commit/60a00d8c6c9a libweston/desktop/xwayland.c xwayland/window-manager.c xwayland/xwayland-internal-interface.h
13:15 wlb: weston/main: Derek Foreman * desktop-shell: Use weston_coord for configure_static_view https://gitlab.freedesktop.org/wayland/weston/commit/9056a11460af desktop-shell/shell.c
13:15 wlb: weston/main: Derek Foreman * libweston: Replace struct_weston_position with weston_coords https://gitlab.freedesktop.org/wayland/weston/commit/89ff5ddfd9aa desktop-shell/shell.c include/libweston/libweston.h libweston/desktop/surface.c libweston/desktop/xdg-shell-v6.c libweston/desktop/xdg-shell.c
13:15 wlb: weston/main: Derek Foreman * desktop-shell: store xwayland positions in weston_coord https://gitlab.freedesktop.org/wayland/weston/commit/c4d24c01b30b desktop-shell/shell.c
13:15 wlb: weston Merge request !1278 merged \o/ (Rework 2D coordinate handling part 7 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1278)
13:18 kchibisov: Though, you have a corresponding name for that project, so have fun.
13:18 bl4ckb0ne: i see, thanks for the tips
13:18 bl4ckb0ne: yeah, im very happy with the naming
13:42 narodnik: kchibisov: lol i was just adding wayland input support to miniquad
13:42 narodnik: https://github.com/not-fl3/miniquad/pull/388
13:42 kchibisov: I think miniquad is still in beta with Wayland?
13:43 kchibisov: Or was it merged?
13:43 narodnik: yeah but it's usable
13:43 kchibisov: Yeah, I use winit because miniquad has a different scope.
13:45 kchibisov: Oh, it's using raw libwayland, that's impressive.
17:12 wlb: wayland-protocols/main: Sebastian Wick * security-context-v1: Document out of band metadata for flatpak https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/b19ee1a7e39c staging/security-context/ engines.md security-context-v1.xml
17:12 wlb: wayland-protocols/main: Sebastian Wick * security-context-v1: Document what can be done with the open sockets https://gitlab.freedesktop.org/wayland/wayland-protocols/commit/5293896cce3e staging/security-context/security-context-v1.xml
17:12 wlb: wayland-protocols Merge request !232 merged \o/ (security-context-v1: Document out of band mechanism and clarifications on socket usage https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/232)
17:24 orowith2os: @kchibisov impressive, and weird
17:24 orowith2os: Wayland bindings exist for Rust, why is miniquad using the raw stuff? @narodnik
17:25 kchibisov: orowith2os: dunno, rust has really weird ecosystem wrt windowing.
17:26 orowith2os: Fair enough
17:26 kchibisov: It's like everyone knows how to do everything and literally no-one tries to cooperate.
17:27 kchibisov: So instaed of helping with winit, subpar solutions are borned sometimes.
17:28 orowith2os: My dive into Smithay showed me that 1. I'm not ready for anything low level, 2. I'm never interacting with the bare windowing system, and 3. I have quite a ways to go in regards to learning to program :p
17:28 kchibisov: I'm not saying that miniquad is subpar, but the wayland impl they have could be better, if they opted for wayland-rs at least.
17:28 kchibisov: still simpler than doing raw pointers.
17:29 emersion: smithay contained quite a lot of magic last time i tried to look
17:29 kchibisov: smithay yes.
17:29 emersion: i never managed to wrap my head around it
17:29 kchibisov: I also have no clue what is going on in it.
17:29 kchibisov: But the client side is rather simple.
17:30 kchibisov: And I write clients, so I don't mind what they do on the server.
17:30 orowith2os: Maybe qtile is more my style, though then I have to learn python :D
17:32 kchibisov: Though, from what I understood it got better in smithay recently.
17:41 drakulix[m]: And I am always happy to mentor people trying to wrap their head around smithay. Not that @emersion has a need to do that. 😅
17:43 emersion: good to know!
17:44 drakulix[m]: In general you matrix chat is very active and welcoming. 🙂
17:47 drakulix[m]: Also regarding miniquad, Fedor (dev of it) has quite some opinions regarding wayland: https://mastodon.gamedev.place/@fedor/110724678396369995
17:47 drakulix[m]: I don't agree with them and this is not an invite to argue with them, but I find the perspective interesting.
17:48 drakulix[m]: But the goal for miniquad seems to be cross-platform, all dynamically loaded, small footprint.
17:48 kchibisov: I don't care about arguing with anyone about Wayland in rust, I just write code for myself mostly.
17:49 drakulix[m]: Given these design goals, they are quite hesitant to use any common libraries for this sort of thing.
17:49 kchibisov: ¯\_(ツ)_/¯
17:49 drakulix[m]: Though I would also prefer everybody to spent time making winit better instead. Well...
17:49 kchibisov: They could make sctk/wayland-rs better, winit needs more work on anything other than Wayland.
17:50 drakulix[m]: Clearly they don't see an incentive in doing that.
17:54 drakulix[m]: s/you/our/
18:18 bl4ckb0ne: kchibisov: i went through SDL cocoa code to see what you were talking about and its horrible
18:18 kchibisov: That's one of the reason I do drink.
18:18 kchibisov: Each time I go through either cocoa or X11 code we have in winit, I don't want to live.
18:18 kchibisov: it got better, but it's really depressing.
18:19 kchibisov: And when it comes to cocoa, it's like that in every lib I've checked.
18:19 kchibisov: Maybe except some really small ones.
18:19 bl4ckb0ne: mmh
18:20 bl4ckb0ne: callback seems like the way to go indeed
18:20 kchibisov: Like wrapping objective-c is not a rust way of doing things.
18:20 bl4ckb0ne: i just have to fix the wl frame kickstart
18:20 kchibisov: Instead, let's use obj-c runtime internals from pure rust.
18:20 kchibisov: much fun.
18:22 kchibisov: At least we're close to have a swift lang alternative, our bridging is getting better and better.
18:28 kchibisov: bl4ckb0ne: also, be aware that window on macOS must be created while the event loop running.
18:29 kchibisov: You can do that without much issues when you have it blocked, but it could dismiss some features from it.
18:35 bl4ckb0ne: would something like that work https://paste.sr.ht/~bl4ckb0ne/29aac241ce82dc30b5f9e1ec834dbaae7c917f89
18:37 kchibisov: The main issue is that you can't really have a buffer.
18:37 kchibisov: Unless your buffer is something else.
18:37 kchibisov: The thing about buffering though, is that user can buffer themselves.
18:38 kchibisov: But they can't do direct callback handling with buffering.
18:38 bl4ckb0ne: event buffer or pixel buffer
18:38 kchibisov: event buffer.
18:39 kchibisov: Like you can cleary do your own buffering from the callbacks by passing growable buffer around.
18:40 kchibisov: Though, you could try, I made a choice in winit with doing callbacks.
19:02 bl4ckb0ne: callback seems to be the sanest indeed
19:16 kchibisov: How wl_data_device::enter's wl_data_offer is expected to be handled?
19:17 kchibisov: Is it the same as wl_data_device::selection?
19:18 kchibisov: It has the same nullable offer, but it doesn't say what I should do with null.
20:33 kchibisov: I guess it doesn't say anything because you have a `must destroy` in leave?