11:32 dubiousness: I would like to prefix this by saying I am absolutely not trying to provoke a flame war, but I wondered if someone could shed some light on what might be required to restore the functionality mentioned in this XFCE report: https://gitlab.xfce.org/panel-plugins/xfce4-whiskermenu-plugin/-/issues/112
11:34 emersion: dubiousness: can you explain what is the issue for someone not familiar with XFCE?
11:36 dubiousness: emersion: previously, the panel menu was resiazable with a click and drag in X, but according to Graeme, this same functionality isn’t possible with Wayland
11:36 dubiousness: he undoubtedly explains it better than I can
11:37 emersion: what is the "panel menu"?
11:37 emersion: do you have a screenshot?
11:39 dubiousness: Specifically the whisker menu: https://docs.xfce.org/panel-plugins/xfce4-whiskermenu-plugin/start
11:39 dubiousness: the “fancier” “start” menu for XFCE
11:40 emersion: so it's possible to resize it by dragging the edge?
11:40 emersion: the right edge?
11:42 emersion: i think it should be possible to implement right now, unfortunately would require a roundtrip to the compositor i think
11:43 emersion: on drag, the client can request to resize the layer surface
11:44 kchibisov: you certainly can, but some developed extra protocols based layer shell for that.
11:48 dubiousness: emersion: correct on the drag question, so at the top or the right of the window, with the menu open, I can “easily” resize it
11:51 dubiousness: Is it fairer to say that it’s a symptom of using GtkLayerShell for this purpose?
11:53 kchibisov: Do they write their own compositor?
11:55 kchibisov: Like you can sort of drag resize with layer shell (use transparency and span the entire output, then offset, and when drag ends you drop invisible regions), but if they write their own compositor, they could just write a custom protocol.
11:56 dubiousness: I’m on my phone atm so a bit tricky to look up code, but this page suggests wlroots: https://wiki.xfce.org/releng/wayland_roadmap
11:57 mjt: wow, xfce goes wayland! nice
11:57 kchibisov: they can just write their own protocol then.
11:58 kchibisov: The standard layer shell is not fun for that, but it's possible.
11:59 dubiousness: Okay, so technically possible but perhaps requiring more granularity than the developer hoped for?
11:59 dubiousness: I will try and get my head around it this weekend
11:59 kchibisov: nothing stops you from spanning all the output and offseting in it.
12:00 kchibisov: like you can slide animations that way.
12:00 kchibisov: it's just not that fun.
15:43 wlb: weston Issue #860 opened by paiusco (Paiusco) Qt app to take its own screenshot https://gitlab.freedesktop.org/wayland/weston/-/issues/860
15:49 mjt: what's the way to prevent the "window attempts to grab input, allow/deny?" question? There are quite some legitimate uses of this and such question is definitely unwanted. For example, I run a mini-pc who's sole purpose is to log in to another computer using rdp or vnc and display the remote desktop.
15:58 kennylevinsen: which compositor?
16:54 mjt: several, - sway and gnome at the very least
16:55 mjt: I thought it doesn't depend on the compositor?
17:04 kennylevinsen: mjt: sway would not ask such a question, so it's coming from the client (or maybe a nosy proxy)
17:16 mjt: now I'm confused
17:17 mjt: there's nothing besides sway and - in this case - wlfreerdp (or sdl-freerdp). Lemme double-check..
17:21 mjt: yes, I confused this terminal client and my desktop. Indeed, sway doesn't ask this question, gnome does
17:44 q234rty: it's a portal thing
17:45 q234rty: on gnome you can just use gnome-remote-desktop which uses mutter's dbus api directly instead of the portal
20:08 mjt: when you have to build freerdp3 from source in order to fix bugs in there (which are numerous).. using gnome-remote-desktop isn't an option :)
20:10 mjt: it's still interesting to know where the prob is. rdp isn't the only problem user here, - eg, qemu-system has the same prob. What we should do in qemu in order for gnome to stop asking the user if it's okay for qemu to grab input or not, - it is very annoying
20:14 mjt: what is "portal" anyway?
20:22 kennylevinsen: mjt: there's nothing the client can or should do to bypass compositor enforced permission checks. It's gnome you'd have to configure to not ask, if possible. Or use a compositor more suitable to your kiosk-esque use case.
20:23 mjt: for kiosk (rdp) I already use sway which - as I confirmed - does not ask this. But qemu is a different matter, it is not about kiosk
20:24 mjt: so since gnome-remote-desktop avoids this question, it's possible to implement this avoidance in qemu too, or ship gnome configuration for qemu to do that
20:25 mjt: it would be really nice to add such option to qemu
20:28 kennylevinsen: That's not how security configuration should work. Asking is not inappropriate, even if it may seem obvious that the permission is needed.
20:28 kennylevinsen: How it works in gnome, in particular UX and alternate gnome APIs, is a gnome question for a gnome channel though
20:29 mjt: yeah, I see
20:30 mjt: I'd not implement alternative gnome-specific APIs in qemu. But it's really annoying thing. More so once we stopped forcing sdl to x11 only
20:33 kennylevinsen: Regardless, I'd consider it a bug if gnome implements a prompt and had a way to bypass it. The better discussion isn't how to get around it, but how to improve the UX. Remembering the choice for example, and qemu avoiding grab unless necessary or selected by the user.
20:55 bwidawsk: when/why might a compositor emit wl_output::scale = 0?
20:59 vyivel: sounds like a compositor bug
21:09 bwidawsk: The spec specifically doesn't disallow it afaict
21:12 bwidawsk: Similarly surface scaling
21:15 bwidawsk: actually, just fractional scaling
21:15 bwidawsk: wl_surface has: "If scale is not positive the invalid_scale protocol error is raised."
21:48 kennylevinsen: bwidawsk: 0 is technically a positive value, but that's a bug
21:51 vyivel: should've used "strictly positive"
21:59 kchibisov: kennylevinsen: that's depends who taught you math though.
21:59 kchibisov: And which type it's.
22:00 kchibisov: because positive means with-out zero, and when you want to use with zero you say "non-negative" or "non-positive".
22:25 fluix: wiki says 0 is either both positive and negative or neither positive nor negative. what convention you use depends on field or class
22:25 bwidawsk: I learned neither...
22:26 zzag: "is either both positive and negative" this makes no sense
22:26 zzag: if 0 is negative
22:26 zzag: then 0 < 0
22:27 zzag: although are we talking about integers?
22:27 zzag: because floating point numbers are different
22:27 kchibisov: That's what I said, +- zero makes sense only for real numbers.
22:28 kchibisov: For naturals/integers it's without a sign.
22:28 Arnavion: Anyone who defines zero as being negative would also define negative numbers to be <= 0, so 0 < 0 would not happen
22:28 kchibisov: I mean, in math when it comes to integers it's 0 without sign.
22:29 kchibisov: So you have, Z-, Z+, Z, N+ sets.
22:29 kchibisov: but maybe EU/US math is way different from what I was taught.
22:31 Arnavion: Indeed, Wikipedia's citation for "both positive and negative" is a book that says >A rational number is positive (>= 0) or negative (<= 0); only 0 is both
22:31 kchibisov: well, yeah, rational, real, the sets when you get floats.
22:31 Arnavion: But yeah I (Indian / British education system) also learned 0 is neither
22:32 kchibisov: N+ is just a common way to refer positive ints, since N is with zero...
22:32 Arnavion: Actually :)
22:32 Arnavion: The world is not consistent on whether natural numbers includes 0 or not
22:33 kchibisov: Well, I was taught that 0 is a part of N.
22:34 Arnavion: Yeah, and some systems (like mine) say natural numbers start from 1 and whole numbers are natural numbers plus 0
22:34 Arnavion: So basically just always use "integers"
22:42 bwidawsk: so afaict, there are a few protocol bugs here if 0 is never allowed to be specified for output or surface scaling
22:49 bwidawsk: I can try to write an MR for this
23:27 kennylevinsen: bwidawsk: not sending a scale is fine, but sending 0 is at least unexpected
23:33 kennylevinsen: As for clarification, I would suggest an explicit "greater than zero" to avoid further math debates. :)
23:34 fluix: I think "strictly positive", "non-zero positive", or what you suggested are all fine. I imagine at least one of these is already present somewhere and should be copied
23:46 bwidawsk: does buffer scale = 0 have a valid usage?
23:46 bwidawsk: seems no, also
23:59 wlb: wayland Merge request !357 opened by Ben Widawsky (bwidawsk) protocol: clarify scale expecations https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/357