ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
melonai0 is now known as melonai
Serus has quit [Ping timeout: 480 seconds]
Serus has joined #wayland
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
fmuellner has quit [Ping timeout: 480 seconds]
tent405 has joined #wayland
jmdaemon has joined #wayland
nerdopolis has joined #wayland
columbarius has joined #wayland
co1umbarius has quit [Remote host closed the connection]
iomari891 has joined #wayland
<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)
<danieldg> you don't have to, no
<danieldg> you can also just track the id of any resources you bind
<danieldg> remove is mostly only for outputs and seats, if you don't use those you don't care
<Nosrep> ic
<Nosrep> then ill probably just track the name of the seat (or copy wl-clipboard and not care :x)
<danieldg> wl-clipboard is short-running; removals mostly only matter for long-running things
carlos_ has quit [Ping timeout: 480 seconds]
<Nosrep> wl-paste has a watch mode, but idk if that uses a different listener? i dont think so though
<danieldg> no, that one is longer-lived but not really meant to be 'forever'
<danieldg> though if you use it as a daemon I guess it does live long enough that it should handle removals
iomari891 has quit [Remote host closed the connection]
nerdopolis has quit [Ping timeout: 480 seconds]
<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?
<danieldg> you should destroy it just to free the id; it might fire finish for you, though
<Nosrep> aight thanks
Guest6394 has joined #wayland
Guest6394 has left #wayland [Konversation terminated!]
gallo has joined #wayland
julio7359 has joined #wayland
sima has joined #wayland
sima has quit [Remote host closed the connection]
sima has joined #wayland
Company has quit [Quit: Leaving]
tent405 has quit [Quit: tent405]
julio7359 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
<emersion> mstoeckl: thanks for trying to simplify the buffer size control MR
<emersion> last time i looked, i just didn't understand it fully
mvlad has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
carlos_ has joined #wayland
rasterman has joined #wayland
iomari891 has joined #wayland
<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?
tent405 has joined #wayland
tent405 has quit []
<pq> cambrian_invader, maybe the logs go to the user journal, not system journal?
<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?
<emersion> mmap is a system call
<emersion> you don't necessarily need libc to do that
<emersion> although my understanding is that the Rust stdlib uses libc
<narodnik> yeah i still need to manually load it in my user code
<narodnik> so i can access mmap
<emersion> you can just do the syscall
<narodnik> not possible without adding an external library
<emersion> you don't need any external lib do perform a syscall
<narodnik> well i then need some assembly code, right?
<narodnik> or how would i do that
<emersion> i would hope that at least a crate exists for this
Lucretia has quit [Read error: Connection reset by peer]
crazybyte has quit [Ping timeout: 480 seconds]
<emersion> some links:
<emersion> with Go, you would be able to just compile with CGO_ENABLED=0 to get this behavior
<emersion> anyways, this dives into a Rust discussion not really related to Wayland
<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.
<pq> I don't know why simply reading wouldn't work.
<emersion> indeed
<emersion> use pread over read
<pq> I have no idea how that translates to Rust though.
<pq> I'd expect Rust APIs to not rely on the shared file offset to begin with.
<pq> but I don't know
Lucretia has joined #wayland
<emersion> pq, be it mmap or read, i think the Rust stdlib just calls libc
<pq> but pread vs. read?
<emersion> i don't know how/if the stdlib exposes this
<pq> I'd expect read without p to not be exposed at all
<emersion> doesn't seem to be in the stdlib https://docs.rs/positioned-io/latest/positioned_io/
<pq> d'oh
<emersion> read without p is exposed in the stdlib, but not with this name of course
<emersion> File::open then read_exact for instance, i'd expect that results in a libc read() call
<pq> I would have expected a Rust file wrapper object to keep track of the position itself instead of relying on the kernel.
<pq> oh well, doesn't matter what we expect
<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.
sozuba has joined #wayland
Cyrinux94 has quit [Ping timeout: 480 seconds]
Cyrinux94 has joined #wayland
<emersion> hm, i should stop getting myself into such rabbit holes
jess has quit []
<pq> haha
<pq> looks like read_at uses pread
<emersion> yes, so maybe that crate linked above was from a time when the stdlib was missing this feature
crazybyte has joined #wayland
<emersion> hm, this is specific to Unix though
<emersion> yeah, the crate provides the functionality on more platforms
<emersion> alright, time to stop now :P
mbalmer has joined #wayland
mbalmer has quit []
jess has joined #wayland
jbit has quit [Quit: Quitting]
jbit has joined #wayland
<narodnik> pq, emersion: it's fine, I will use libc library for mmap
<narodnik> i realized it's already being used in my ffi bindings for wayland
<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
<vyivel> unless i'm mistaken, xdg-shell doesn't really forbid remapping xdg_popups, but then mutter/kwin behavior seems strange
<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
<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
<emersion> jadahl: what about attaching a NULL buffer to unmap, then doing an initial commit?
<jadahl> emersion: only meant to work with xdg_toplevel IIRC
<jadahl> get_popup()+grab() needs a serial
<emersion> right, but that would be without a grab
<jadahl> seems only xdg_toplevel defines what happens if you attach null
i509vcb has quit [Quit: Connection closed for inactivity]
<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.
<jadahl> this was discussed during the time when we decided whether to allow attach(null) at all
<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?
<jadahl> thats my interpretation - only send a configure to an unmapped popup in response to get_popup
<vyivel> a configure isn't sent in response to get_popup, that would be too early
<vyivel> it's sent in response to an initial commit
<jadahl> sure, I mean on a new xdg_popup, not a reused one
<jadahl> sorry for the confusion
<pq> what's a good phrase for "B must be after A, and only once after each A" without implying "immediately"?
manuel1985 has joined #wayland
sozuba_ has joined #wayland
sozuba has quit [Ping timeout: 480 seconds]
na[m] has quit [Quit: Client limit exceeded: 20000]
<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]
anarsoul|2 has quit [Remote host closed the connection]
anarsoul has joined #wayland
gallo has quit [Quit: Lost terminal]
gallo has joined #wayland
cmichael has joined #wayland
<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
heapify has joined #wayland
jmdaemon has quit [Ping timeout: 480 seconds]
nerdopolis has joined #wayland
manuel_ has joined #wayland
heapify has quit [Ping timeout: 480 seconds]
<kennylevinsen> pq: "each A must eventually be followed by exactly one B"?
<kennylevinsen> or "by a matching B"
manuel1985 has quit [Ping timeout: 480 seconds]
<pq> kennylevinsen, there cannot be B for a different A in between.
<kennylevinsen> So you can have multiple A's, and each needs to have a B, and the B's must be in order?
<pq> only ABABABAB is allowed. AA cannot happen, BB is not allowed.
<kennylevinsen> Would "ABA" be technically be allowed with no further traffic? (no answered B but also no further A)
<pq> yes, because it's a transient state
kts has joined #wayland
<pq> a necessary transient state
<kennylevinsen> "each A must be acknowledged by B before further A"?
<pq> that's from server perspective, how about from client perspective?
<kennylevinsen> to clarify, A is client-to-server, B is server-to-client? or other way around?
<pq> the other way around
<pq> I presume there is no good phrase for this, like there is "iff" for "if and only if".
<kennylevinsen> Hmm. I think the mentioned description works fine for both server and client.
fmuellner has joined #wayland
heapify has joined #wayland
<kennylevinsen> In my head, the "before further A" implies that the answer is not required immediately
<pq> sure, but it also implies that "further A" is expected; it's not
<pq> further A is possible only after restarting sequence
<kennylevinsen> True. "... can occur" perhaps? You might also have an idea of whether a B *should* occur, which is not currently communicated.
<pq> too difficult in abstract :-)
<kennylevinsen> Indeed, and I assume it's abstract for good reason. :)
<pq> yeah, I was curious if there is a generic phrase
<kennylevinsen> No silver bullet without extra words to describe the exact phrase you mentioned - my main ideas is to use a less complicated phrase :)
<kennylevinsen> e.g., the client has less requirements: "A must eventually be acknowledged by B" fits the abstract, with server having more words.
<kennylevinsen> client does not care about ABAB ordering as that's enforced by the server
<pq> but ABB would be wrong
<pq> or B without A
<kennylevinsen> I feel that "acknowledge" in the B description implicitly excludes ABB and B.
<narodnik> is this code still the correct way to implement this function?
<kennylevinsen> Otherwise, clarify: "B acknowledges a pending A. B without pending A is an error."
<kennylevinsen> (also implied if A change state from pending to active, but being explicit can be good.)
nerdopolis has quit [Ping timeout: 480 seconds]
<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]
<emersion> narodnik: no, need MAP_PRIVATE iirc
<emersion> also completely missing error handling
<narodnik> ok ty
iomari892 has joined #wayland
kts has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
iomari891 has joined #wayland
<wlb> wayland/main: Simon Ser * protocol: fix whitespace https://gitlab.freedesktop.org/wayland/wayland/commit/72da004b3eed protocol/wayland.xml
<wlb> wayland Merge request !324 merged \o/ (protocol: fix whitespace https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/324)
iomari892 has quit [Ping timeout: 480 seconds]
Company has joined #wayland
iomari892 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<wlb> weston Issue #780 closed \o/ (Toytoolkit window minimum size no longer respected https://gitlab.freedesktop.org/wayland/weston/-/issues/780)
<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)
<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
<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?
<pq> while being able to easily have simple widgets like buttons, sliders, and non-editable text
<emersion> *crickets*
<emersion> more seriously, maybe one of these GL mini-toolkits?
<pq> hmm. Would they let me pick an arbitrary EGLConfig? Particularly 16F.
<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.
<pq> hmm, but GUI widgets in OpenGL could help...
<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. >_<
<kchibisov> gui toolkits exposing details is a rare thing I'd say.
<pq> this was supposed to be a fun side-project, but not *this* fun
<pq> indeed
<kchibisov> Like I know that with winit you can do most of it, it'll just take a bit of time.
<kchibisov> And your custom protocol will be handled on your own, but you have wl_display/wl_surface and such.
<pq> I imagine the Rust raw_window_handle etc. smithay toolkit ecosystem might come really close, after you bolt ICED widgets on it
<kchibisov> For your case egui could be more or less what you want.
<pq> which is something I want to do, but... later
<kchibisov> if you want to have 1-2 buttons and such.
<pq> hmm
<pq> and text?
<pq> simple text
<kchibisov> Yeah, very simple text with egui as well.
<kchibisov> it's like imgui.
<pq> alright
<kchibisov> I just know that you can achieve what you want with glutin + winit under like 10-20 mins.
<kchibisov> If we rule out buttons.
<kchibisov> Because glutin exposes all the EGL config picking on you.
<pq> yeah, I've occasionally typing a glutin+winit app at home for a few months now
<kchibisov> I've been doing that for like 5 years.
<pq> but I will also be needing direct Wayland access
<kchibisov> You can do so.
<kchibisov> You take the display, create a queue out of it and you're good to go.
<kchibisov> And dispatch the queue inside your `run`.
<kchibisov> alacritty does that for a long time.
<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.
<pq> I see
<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.
<kchibisov> (unless it's wl_surface exposed by winit)
<kchibisov> Though, nothing stops winit from exposing the role objects.
<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)
<wlb> weston/main: Derek Foreman * xwayland: Fix assert with some parented windows https://gitlab.freedesktop.org/wayland/weston/commit/123e921871c8 libweston/desktop/surface.c
<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
<kchibisov> it's just, if there's a direct need to expose some internals, we can make it.
<wlb> weston Merge request !1305 merged \o/ (xwayland: Fix assert with some parented windows https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1305)
fallenchromium[m] is now known as PavelNasevich[m]
<bl4ckb0ne> pq im working on a window toolkit oriented on buffer handling specially for that kind of opengl use case
<kchibisov> window toolkit or gui?
<kchibisov> Because for example window toolkit shouldn't even care about buffers, it's al on users.
<pq> cool, what project is that?
<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
<bl4ckb0ne> window toolkit
<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?
<bl4ckb0ne> https://git.sr.ht/~bl4ckb0ne/hel/ very wip, i get about an hour every other day to work on it
<bl4ckb0ne> basically its vk wsi but rendering api agnostic
<bl4ckb0ne> not similar to glfw/sdl, it doesnt touch the rendering part
<bl4ckb0ne> i started it because i was getting annoyed at the lack of gl flexibility from sdl
<kchibisov> Ah, so you do similar to what miniquad does in rust.
<kchibisov> Well, not exactly though.
<bl4ckb0ne> im still thinkering event processing, if i do full async like wayland or queue everything then dispatch
<kchibisov> queue won't work cross platform.
<kchibisov> callback based will work.
<kchibisov> But I don't think you care?
<bl4ckb0ne> why?
<kchibisov> I mean, I doubt you care to support macOS/Windows.
<kchibisov> Because on macOS queue can't work due its design.
<bl4ckb0ne> i do plan on that yeah
<kchibisov> And on ios queue also won't really work.
<bl4ckb0ne> what i mean is some kind of event buffer like openxr does
<kchibisov> you can't buffer on macOS.
<kchibisov> At least, not all events.
<kchibisov> Are you familiar with how macOS windowing works?
<bl4ckb0ne> not at all
<kchibisov> You basically inherit their default window stuff and must implement methods.
kts has joined #wayland
<kchibisov> macOS calls you back to the methods it expects to be implemented.
<kchibisov> Some methods require sync handling.
<kchibisov> As in they must do certain action without any buffering right away.
<kchibisov> Winit was queue based in early days, but then we moved to callbacks because how macOS/Windows works.
<kchibisov> And Wayland/X11 you can make whatever.
<kchibisov> You can't even have a good js like event loop with macOS windowing system, because it's not even kqueue.
rv1sr has joined #wayland
<kchibisov> You also can't really make wsi like interface on macOS either.
<kchibisov> Unless you go full metal or ANGLE.
<kchibisov> where ANGLE is basically does that on top of metal.
<kchibisov> With their GL you won't go far.
<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
<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
<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
<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
<wlb> weston Merge request !1278 merged \o/ (Rework 2D coordinate handling part 7 https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1278)
<kchibisov> Though, you have a corresponding name for that project, so have fun.
<bl4ckb0ne> i see, thanks for the tips
<bl4ckb0ne> yeah, im very happy with the naming
iomari891 has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
Net147 has quit [Quit: Quit]
Net147 has joined #wayland
kts has quit [Quit: Konversation terminated!]
<narodnik> kchibisov: lol i was just adding wayland input support to miniquad
<kchibisov> I think miniquad is still in beta with Wayland?
<kchibisov> Or was it merged?
<narodnik> yeah but it's usable
<kchibisov> Yeah, I use winit because miniquad has a different scope.
nerdopolis has joined #wayland
<kchibisov> Oh, it's using raw libwayland, that's impressive.
cmichael has quit [Quit: Leaving]
cmichael has joined #wayland
eroc1990 has quit [Quit: The Lounge - https://thelounge.chat]
sozuba has joined #wayland
sozuba is now known as Guest6431
sozuba_ has quit [Ping timeout: 480 seconds]
kts has joined #wayland
Satan2 has joined #wayland
Cyrinux94 has quit []
manuel_ has quit [Ping timeout: 480 seconds]
Cyrinux94 has joined #wayland
iomari892 has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
eroc1990 has joined #wayland
iomari891 has joined #wayland
tent405 has joined #wayland
iomari892 has quit [Ping timeout: 480 seconds]
iomari891 has quit [Ping timeout: 480 seconds]
<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
<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
<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)
shankaru has quit [Remote host closed the connection]
shankaru has joined #wayland
<orowith2os> @kchibisov impressive, and weird
<orowith2os> Wayland bindings exist for Rust, why is miniquad using the raw stuff? @narodnik
<kchibisov> orowith2os: dunno, rust has really weird ecosystem wrt windowing.
<orowith2os> Fair enough
<kchibisov> It's like everyone knows how to do everything and literally no-one tries to cooperate.
<kchibisov> So instaed of helping with winit, subpar solutions are borned sometimes.
<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
<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.
<kchibisov> still simpler than doing raw pointers.
<emersion> smithay contained quite a lot of magic last time i tried to look
<kchibisov> smithay yes.
<emersion> i never managed to wrap my head around it
<kchibisov> I also have no clue what is going on in it.
<kchibisov> But the client side is rather simple.
<kchibisov> And I write clients, so I don't mind what they do on the server.
<orowith2os> Maybe qtile is more my style, though then I have to learn python :D
<kchibisov> Though, from what I understood it got better in smithay recently.
___nick___ has joined #wayland
Moprius has joined #wayland
<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. 😅
<emersion> good to know!
<drakulix[m]> In general you matrix chat is very active and welcoming. 🙂
___nick___ has quit []
cmichael has quit [Quit: Leaving]
___nick___ has joined #wayland
___nick___ has quit []
<drakulix[m]> Also regarding miniquad, Fedor (dev of it) has quite some opinions regarding wayland: https://mastodon.gamedev.place/@fedor/110724678396369995
<drakulix[m]> I don't agree with them and this is not an invite to argue with them, but I find the perspective interesting.
heapify has quit [Quit: heapify]
<drakulix[m]> But the goal for miniquad seems to be cross-platform, all dynamically loaded, small footprint.
<kchibisov> I don't care about arguing with anyone about Wayland in rust, I just write code for myself mostly.
<drakulix[m]> Given these design goals, they are quite hesitant to use any common libraries for this sort of thing.
___nick___ has joined #wayland
<kchibisov> ¯\_(ツ)_/¯
<drakulix[m]> Though I would also prefer everybody to spent time making winit better instead. Well...
<kchibisov> They could make sctk/wayland-rs better, winit needs more work on anything other than Wayland.
<drakulix[m]> Clearly they don't see an incentive in doing that.
i509vcb has joined #wayland
<drakulix[m]> s/you/our/
jmdaemon has joined #wayland
Moprius has quit [Quit: bye]
<bl4ckb0ne> kchibisov: i went through SDL cocoa code to see what you were talking about and its horrible
<kchibisov> That's one of the reason I do drink.
<kchibisov> Each time I go through either cocoa or X11 code we have in winit, I don't want to live.
<kchibisov> it got better, but it's really depressing.
<kchibisov> And when it comes to cocoa, it's like that in every lib I've checked.
<kchibisov> Maybe except some really small ones.
<bl4ckb0ne> mmh
<bl4ckb0ne> callback seems like the way to go indeed
<kchibisov> Like wrapping objective-c is not a rust way of doing things.
<bl4ckb0ne> i just have to fix the wl frame kickstart
<kchibisov> Instead, let's use obj-c runtime internals from pure rust.
<kchibisov> much fun.
<kchibisov> At least we're close to have a swift lang alternative, our bridging is getting better and better.
<kchibisov> bl4ckb0ne: also, be aware that window on macOS must be created while the event loop running.
<kchibisov> You can do that without much issues when you have it blocked, but it could dismiss some features from it.
kts has quit [Quit: Konversation terminated!]
Guest6431 has quit [Ping timeout: 480 seconds]
<kchibisov> The main issue is that you can't really have a buffer.
<kchibisov> Unless your buffer is something else.
<kchibisov> The thing about buffering though, is that user can buffer themselves.
<kchibisov> But they can't do direct callback handling with buffering.
<bl4ckb0ne> event buffer or pixel buffer
<kchibisov> event buffer.
<kchibisov> Like you can cleary do your own buffering from the callbacks by passing growable buffer around.
<kchibisov> Though, you could try, I made a choice in winit with doing callbacks.
<bl4ckb0ne> callback seems to be the sanest indeed
pbsds is now known as Guest6456
pbsds has joined #wayland
Guest6456 has quit [Ping timeout: 480 seconds]
<kchibisov> How wl_data_device::enter's wl_data_offer is expected to be handled?
<kchibisov> Is it the same as wl_data_device::selection?
<kchibisov> It has the same nullable offer, but it doesn't say what I should do with null.
iomari891 has joined #wayland
rasterman has quit [Quit: Gettin' stinky!]
glennk has quit [Read error: Connection reset by peer]
glennk has joined #wayland
mvlad has quit [Remote host closed the connection]
___nick___ has quit [Ping timeout: 480 seconds]
kenny has quit [Quit: WeeChat 4.0.2]
kenny has joined #wayland
Brainium has joined #wayland
<kchibisov> I guess it doesn't say anything because you have a `must destroy` in leave?
glennk has quit [Remote host closed the connection]
glennk has joined #wayland
rv1sr has quit []
nerdopolis has quit [Ping timeout: 480 seconds]
dongle has joined #wayland
carlos_ has quit [Remote host closed the connection]
psykose has quit [Remote host closed the connection]
sima has quit [Ping timeout: 480 seconds]
psykose has joined #wayland
nerdopolis has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
nerdopolis has quit [Ping timeout: 480 seconds]
_DOOM_ has joined #wayland
nerdopolis has joined #wayland
carlos_ has joined #wayland
_DOOM_ has quit [Quit: WeeChat 4.0.2]