02:11 esotericwarfare: hi all
02:11 esotericwarfare: hi all
02:12 esotericwarfare: I cannot play videos with mpv in tinywl wayland
02:12 esotericwarfare: [vo/wlshm/wayland] Compositor doesn't support the required wp_viewporter protocol!
02:12 esotericwarfare: [vo/dmabuf-wayland/wayland] Compositor doesn't support the required wp_viewporter protocol!
02:12 esotericwarfare: is there any way to fix this?
02:12 Ermine: not a bug, use actual compositor, not the educative material
02:13 Ermine: tinywl can't do a lot of things because it enables only a few protocols
02:14 karenw: wp_viewporter is pretty basic, if your compositor doesn't have it at all, it's really minimalist and not suitable for general use.
02:14 Ermine: but the purpose of tinywl is to show how to use wlroots library, not to be a full-fledged wayland compositor
02:16 Ermine: (you can notice btw that you can't switch out of tinywl by using e.g. ctrl-alt-f3 if you run it on a tty)
02:17 esotericwarfare: yes I notice that
02:18 Ermine: But if you're looking for an excercise on compositor development, wp_viewporter protocol is enabled by one line of code in wlroots, try to figure out which one
02:19 esotericwarfare: okay thannks
02:21 Ermine: and if you're looking for a compositor for your daily needs, there is a list of wlroots-based compositors: https://gitlab.freedesktop.org/wlroots/wlroots/-/wikis/Projects-which-use-wlroots
02:22 esotericwarfare: Nice. I will look into that.
02:24 Ermine: and, since we're on #wayland and not #wlroots, there are also Weston, Kwin (part of Plasma), Mutter (part of GNOME) and whatever Cosmic uses
02:26 esotericwarfare: I used dwm for a long time then I got tired and only use the framebuffer (I can watch videos with mpv --vo=drm) and run QT apps like falkon and qutebrowser. But now I wanna try wayland lol: dwl is wayland version of dwm, but I'm tired of tiling window manager LOL
02:26 esotericwarfare: from the framebuffer I can run games like 0ad, gzdoom, I think diablo too
02:27 esotericwarfare: or maybe its not framebuffer I don't know, from the tty
02:27 esotericwarfare: Ermine: Thank you so much!
02:59 soreau: Wayfire FTW - https://streamable.com/chmhn4
02:59 soreau: zzag: ^^
03:02 soreau: see y'all next year..
03:10 zzag: speaking for kwin, we would like to know the title bar rect in order to confine a window during interactive move better, e.g. to avoid placing the title behind a panel. regarding window shade, I think more is needed in order to support it properly (e.g. a shade request in xdg_toplevel), but then again, speaking for kwin, we're considering dropping support for it
03:13 soreau: zzag: AFAIU, you already can get the shadow margins for CSD toplevels, so you should be able to use this to avoid placing it somewhere undesired (like a panel)
03:15 zzag: it's not enough. we also need to know the height of the headerbar
03:16 zzag: ... or the width of the headerbar depending on its orientation
03:16 soreau: I don't really see why..
03:16 soreau: if you know the shadow margins, you can just use these values to compute where to put it (or not)
03:19 soreau: because you know where the input region/rect is, within the buffer (which is larger by the size of the margins)
03:22 zzag: soreau: the confinement algorithm in kwin attempts to keep the titlebar in the workarea. there must be visible at least some part of the titlebar so the user can still initiate an interactive move, etc
03:22 soreau: zzag: yes, I understand this - perfectly reasonable
03:23 zzag: if the shadow margins work for you in wayfire, great, but in kwin, we need to know the titlebar rect to keep the confinement algorithm working the same way as for ssd windows
03:23 soreau: ah, ssd...
03:23 soreau: now that sounds like you're trying to involve personal problems ;)
03:24 soreau: if you want it to work the same, you need to adjust whatever algorithms to be conditional for ssd/csd most likely
03:25 zzag: well what I'm trying to say is that if somebody proposes a set_title_rect request, kwin would be on board :)
03:25 soreau: meh..
03:25 soreau: it's a problem solvable in kwin ssd impl
03:25 soreau: or the assumptions thereof
03:26 zzag: soreau: there are no issues with server side decorations, we need to know the titlebar rect when a client uses client side decorations
03:26 soreau: maybe this would mean huge changes because it still supports x11 or something?
03:26 soreau: zzag: my argument is that you simply do not
03:26 soreau: except for stuff like shade effect, which is quite niche
03:27 zzag: soreau: no, we need it and we would support adding such a hint
03:27 soreau: zzag: you get the buffer geometry, and the input rect/region extents and compare these two to get l/t/r/b margins and work from there
03:28 soreau: this can especially work for ssd since you know everything, including titlebar height
03:29 soreau: https://github.com/soreau/filters/blob/master/src/filters.cpp#L191-L193
03:29 soreau: bg is the buffer geometry and vg is the view geometry
03:32 zzag: soreau: as I said it already, we need to know the headerbar height in order to keep certain amount of pixels vertically in the work area when the user tries to push the window down
03:32 soreau: zzag: you mean during a titlebar move drag?
03:33 zzag: yes, during interactive move, i.e. after calling xdg_toplevel.move, etc
03:34 soreau: you could use some sort of clamping to achieve this AFAIU
03:34 soreau: but anyway, if you can write some MR/issue with enough information to get others on board, maybe it will make more sense :)
03:37 soreau: don't get me wrong, I'm all for more information about CSD to the compositor like titlebar height, I just don't think kwin needs this infomration for the purpose you describe
03:42 soreau: zzag: if you get a wild hair, maybe shoot a video of the problem that you want to solve
03:44 soreau: aside from getting a call into xdg protocol, the other half of the battle is getting clients to actually use the call and set it correctly ;)
03:45 soreau: would be nice if they called a function on scroll-on-titlebar too, like the menu function expected to be called on titlebar right-click
04:33 Consolatis: zzag, why not just treat everything outside of shadows as titlebar? do you want users to allow moving a few pixels of the headerbar out of screen as long as $some amount is still onscreen?
04:34 Consolatis: having the titlebar rect could be interesting though, some random compositor could theoretically use that information to simply cut it off from the client buffer and replace it with an SSD :)
06:52 zzag: Consolatis: "why not just treat everything outside of shadows as titlebar" then you won't be able to move the window partially offscreen
07:18 pavlushka: any gui image viewer suggestion other than swayimage?
10:37 llyyr: pavlushka: mpv
10:38 llyyr: https://github.com/guidocella/mpv-image-config/
10:54 soreau: llyyr: nice, I just use `mpv -loop=inf screenshot.png`
16:36 iomari891: quit
19:16 wlb: wayland-protocols Merge request !372 opened by () Draft: staging: Add xdg-occlusion protocol https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/372