00:36 danieldg: riteo: I expect you treat it like any other surface: request fractional scale, make a viewporter scaled surface, and generally leave the hotpoint alone
00:38 danieldg: unless something else about cursors is different? They are more likely to need the compositor to scale them when they cross monitors that change scale, I guess
01:17 riteo: danieldg: shouldn't I also care about the new actual buffer size?
01:18 riteo: like, if the scaled result is 24 * 1.5 = 36, shouldn't I somehow load the proper theme size?
01:18 riteo: or should I just cache the biggest size I encountered yet and let it be downscaled?
01:20 danieldg: if your cursors are bitmaps, then you should probably grab the largest one and let it be scaled, or pick one that is the right size at the moment
01:21 danieldg: though I expect a bit of 'how does GTK do it' experimentation may be desired, because it's worse to be inconsistent
01:22 riteo: I think that they're always rasterized into constant-sized buffers
01:22 riteo: so if I don't somehow switch the buffers they're gonna get blurry
01:22 danieldg: yes, you switch the buffers
01:22 riteo: I suppose that there's gonna be overhead if I reload the theme with a different size every time, isn't there?
01:23 danieldg: you should really only need to reload it once? I guess you could cache sizes if you wanted to switch back and forth
01:23 riteo: mh
01:24 riteo: for some reason I feel like this is very convoluted
01:24 riteo: like, I blindly cache every size or just load the biggest size I've seen even if I'm not going to see it ever again
01:25 danieldg: the same is true for everything you draw, really
01:25 riteo: mhh I see, you're completely right
01:25 danieldg: fonts, icons, etc
01:26 riteo: I'm tempted to do what we're already doing with integer scaling, which is, well, keeping only the biggest size we've registered
01:26 riteo: so on a 1.25 we'd go to 2 directly and downsample it
01:26 riteo: are there going to be aliasing issues?
01:26 danieldg: depends on the compositor
01:27 danieldg: nothing in wayland specifies how scaling is done
01:27 riteo: mh I see
01:27 riteo: I'm a bit scared of caching every single size honestly. I'll probably go with the "update only when strictly necessary to not blur into the void for bigger sizes" route
01:27 riteo: thanks a lot for your clarifications!
01:28 danieldg: if it's a simple cursor theme it might only have a few (3-4) sizes in the first place, so that's all you could cache
01:29 riteo: can we even probe available sizes from wayland-cursors?
01:29 riteo: the API is just "load theme x with size y"
01:29 riteo: also animated cursors are a thing
01:30 danieldg: yeah, I basically ignored animation
01:30 riteo: btw regarding the GTK consistency thing I'll definitely take a look while testing (eventually), but I'm not too concerned since I recall seeing some GTK bug reports regarding frac scale of cursors
01:30 riteo: might be fixed though, can't recall
01:31 danieldg: just matching 'how does it handle scale=2' is probably good
01:31 riteo: uh that's probably already correct
01:31 orowith2os[m]: Standardize loading cursors as vector images, that way you don't have specific sizes :)
01:31 riteo: you still have to rasterize them though :P
01:31 danieldg: wouldn't that be nice
01:32 danieldg: sure, but you just reraster on scale changes, that's fairly sane
01:32 riteo: oh you mean like, client side?
01:32 danieldg: yes
01:32 riteo: that would be very interesting
01:32 orowith2os[m]: I'd imagine not too technically impossible
01:32 orowith2os[m]: Though a bit painful with animated cursors, like loading
01:32 riteo: yeah, we'd just have to define a somewhat sane vector format as I don't really see clients embedding a whole SVG renderer :P
01:32 danieldg: you already do that if your GUI is vector anyway
01:33 orowith2os[m]: Maybe it could even improve animated cursors? Currently it looks like you store 60 images of one animated cursor and loop over that, if vector formats improve on that, wonderful
01:33 orowith2os[m]: riteo: sounds like a fun side project I can hack on
01:33 riteo: That'd be great!
01:34 riteo: We seriously need better "embedded" vector solutions
01:34 riteo: heck, vector's the future! I wish there were more vector solutions in general!
01:34 orowith2os[m]: Toss me your discord, I'd also like to poke you about more Godot Wayland stuff too
01:34 riteo: oh that'd be great! Although I don't use discord much
01:34 danieldg: fonts are vector graphics already, so almost everyone has an engine to do that
01:34 riteo: I'll send that in private. If anyone else wants it, feel free to ask
01:35 danieldg: the funnier fonts can embed SVG
01:35 danieldg: and also PNG
01:36 riteo: mh yeah but most fonts are a bit domain-specific, aren't they?
01:36 riteo: that's the reason emojis had to get their own format
01:36 riteo: what was it, woff?
01:37 danieldg: there are still fonts with emojis
01:37 riteo: yeah but they embed as you said PNG/SVGs, which aren't really what normal fonts use
01:38 danieldg: true, but a font rendering engine kinda has to support them still
01:39 riteo: they're not accessible though. Godot, despite using Freetype/Harfbuzz had to import their own full-fledged SVG library
01:39 riteo: I think it was ThorVG
01:39 danieldg: I guess you can decide not to do that and just have the simple font support, which is a vector format but doesn't do colors so not really good enough for cursors
01:39 riteo: yeah that would still cover like 90% of fonts
01:41 danieldg: even the most boring cursor is black with white border, which is beyond a TTF file to represent
01:43 danieldg: making a new cursor format would be quite a long project; you have to get it in all the toolkits plus all the control-panel-type GUIs
01:44 danieldg: it would be nice to add a way other than dconf to specify a per-seat cursor choice, though
01:44 danieldg: (actually, can you even do that with dconf?)
01:45 danieldg: the normal setting is just "org.gnome.desktop.interface cursor-theme" no mention of seat
01:45 riteo: it's a bit funny that cursors were all the rage back then and now they're like an afterthought
01:46 riteo: I recall switching an awful lot of sketchy cursor themes on windows 7 when I was a kid
01:47 danieldg: windows 3.1 had really cool animated cursors too, so they're pretty old
02:56 wlb: wayland Issue #424 opened by M. Stoeckl (mstoeckl) Document that wl_display_connect() is not thread safe https://gitlab.freedesktop.org/wayland/wayland/-/issues/424
03:45 DemiMarie: I would much prefer for the system to provide a fixed list of cursors and for the client to have to pick one of them. This is an interface that Qubes OS (and other compartmentalized systems) can actually support. Arbitrary client-provided cursors isn’t, so the compositor I am working on for Qubes OS currently ignores the client-chosen cursor.
03:48 wlb: wayland-protocols Issue #166 opened by Dallas Strouse (orowith2os) Pointer confinement: wrapping https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/166
03:50 orowith2os[m]: Demi: client-provided cursors wasn't even brought up, I think?
03:51 orowith2os[m]: the client can provide cursors of their own, but they can't recommend them to other clients
03:51 orowith2os[m]: this is more for cursors when the client has to draw them
03:52 DemiMarie: Rika (she/her): in Qubes OS we explicitly do _not_ allow clients to draw arbitrary cursors, because this would allow them to hide the cursor.
03:52 orowith2os[m]: you can't disallow that, afaik. It's client opt-in behavior
03:52 DemiMarie: And since this was on #_oftc_#wayland:matrix.org, I assumed that it had to do with Wayland as a protocol, rather than being an implementation detail of a given client
03:53 DemiMarie: Rika (she/her): clients can set a cursor, but the compositor doesn’t have to use it, and the compositor that I am working on for Qubes OS simply ignores it
03:53 orowith2os[m]: do the clients have to set a cursor in that way? can they not skip wl_pointer and draw it themselves?
03:54 zamundaaa[m]: One more reason for all the clients to adopt cursor-shape-v1 :)
03:54 DemiMarie: Rika (she/her): yes, but that will be more likely to be noticed, or at least that is what I think the theory is
03:54 orowith2os[m]: my point is more that you simply can't stop a client from "faking" a cursor icon
03:54 DemiMarie: That said, strong anti-spoofing probably requires tinting all untrusted surfaces or something like that
03:55 DemiMarie: So that cursors, borders, and other trusted components have a color that no untrusted client can forge
03:55 orowith2os[m]: that seems like tons of unnecessary work, but you do you
03:55 orowith2os[m]: shouldn't be impossible to implement, in any case
03:55 DemiMarie: Right now Qubes OS doesn’t do it, and I don’t know if it is needed in any case
03:56 DemiMarie: Security is Hard 😆
03:56 orowith2os[m]: unnecessary security is Even Harder :)
03:56 orowith2os[m]: I doubt manipulating a client-local cursor image matters at all
03:57 DemiMarie: Ideally this would be determined via human interaction studies.
04:00 orowith2os[m]: in any case,
04:00 orowith2os[m]: issue 166
04:00 orowith2os[m]: do take a peek
04:00 orowith2os[m]: it sounds like, currently, clients wanting that behavior rely on UB
04:00 orowith2os[m]: so let's make it defined
04:14 orowith2os[m]: Demi: what's your gitlab username?
04:16 orowith2os[m]: nvm, got it
04:57 Company: playing around with pointer warping and mouse cursor offsets sounds like a fun way to learn information about the system
04:57 Company: by checking where the user clicks
04:58 Company: though I suppose it's easier to fake by doing a transparent fullscreen window
06:56 DemiMarie: Company: This is why Qubes OS does not support transparency.
06:58 Company: that's an easy workaround for that stuff at least
06:58 DemiMarie: Yup
06:59 DemiMarie: At least my personal expectation is that applications should work on Qubes OS, but some features may be missing.
07:06 DemiMarie: On the other hand, Qubes OS will require the desktop environment to support layer-shell, so it is expected that some desktop environments cannot be supported.
07:29 DemiMarie: Company: this is _not_ an anti-GNOME rant, FYI. GNOME being opinionated is perfectly okay, but it does make it unsuitable for Qubes OS.
07:40 Company: DemiMarie: why would you need layer-shell?
07:42 DemiMarie: Company: Qubes OS has custom desktop environment components and reimplementing them for each supported desktop environment isn’t practical.
07:43 Company: that sounds like you should just implement a compositor
07:44 DemiMarie: We don’t have the resources to do that, and besides not everyone will want to run the same compositor.
07:44 DemiMarie: Better to leave that to the people who actually know how to do that.
07:45 Company: you can't really enforce no transparency in that case though?
07:46 DemiMarie: Actually we can, by proxying the Wayland protocol and e.g. replacing ARGB with XRGB.
07:46 DemiMarie: If it turns out that we do need to write our own compositor, it will be a rootless nested compositor, so we will still need layer-shell support from the desktop environment.
07:47 DemiMarie: A Qubes-specific user-facing compositor isn’t going to happen.
07:49 Company: I would think this is a much more time-intensive approach
07:50 Company: trying to force external compositors into submission sounds a lot harder than just creating your own one
07:50 Company: that doesn't do the stuff you don't want to do
22:01 DemiMarie: Company: A nested compositor might be a good idea, but it won’t be user-facing.