16:05 <manuels2> Where is the best place to discuss about Wayland design decisions?

16:06 <bl4ckb0ne> is this about window position?

16:07 <manuels2> Funny

16:07 <manuels2> Yes

16:07 <manuels2> Why do you ask?

16:08 <bl4ckb0ne> its alwats about window position

16:08 <bl4ckb0ne> always*

16:09 <bl4ckb0ne> theres a very good email (i think from pq) on the wl mailing list about that

16:09 <bl4ckb0ne> it has all the answers you seek

16:09 <manuels2> I just wanted to note that it's pointless to enforce this.app devs now start to bypass this decision by full-screen transparent windows and a movable subwindon

16:10 <manuels2> Sorry. On mobile.

16:10 <YaLTeR[m]> lol

16:10 <vyivel> maybe they shouldn't bypass the decision

16:11 <bl4ckb0ne> ^

16:11 <emersion> xdg-shell doesn't allow transparent fullscreen windows

16:28 <kennylevinsen> manuels2: what "app devs" are doing this? as pointed out, that wouldn't work as fullscreen windows cannot be transparent

16:39 <zamundaaa[m]> It does kind of work on lots of compositors. And on the rest, it would work with maximized windows

16:39 <zamundaaa[m]> It would just result in a bad user experience, even more than normal absolute positioning would be

16:59 <Ermine> maybe that pq's email should be added to topic?

17:01 <kennylevinsen> zamundaaa[m]: does kwin allow top-level fullscreen transparency?

17:01 <bl4ckb0ne> i cant find it

17:03 <zamundaaa[m]> kennylevinsen: yes. So do labwc and wayfire

17:04 <kennylevinsen> wasn't aware, since the spec disallows it

17:05 <kennylevinsen> not that I have a strong opinion about the spec behavior

17:28 <Consolatis> manuels2: that sounds fun. good luck for those app devs to provide a consistent UX in that way. like snapping, compositor shortcuts to move the window around and so on. an application like that can't even have server side decorations. but I guess if they prefer their applications to be broken by design that is up to them.

18:01 <manuels2> Can someone please link the mail

18:01 <manuels2> I can't find it

18:08 <manuels2> I second that bypassing the rules I not going to be sustainable but is there any alternative at all? I am writing an app that needs this behavior and was checking how other project approach this issue and, as said, found that the are planning hacks like this.

18:09 <manuels2> The problem is that ultimately it's the users that have to suffer.

18:09 <manuels2> If at least Mutter hat some kind of window rules. Is there anything like this?

18:09 <manuels2> Had*

18:11 <bl4ckb0ne> theres a window placement protocol in the making

18:13 <zamundaaa[m]> There are multiple proposals, but zero compositors that want to support any of them so far

18:15 <nickdiego[m]> <manuels2> "I second that bypassing the..." <- could you describe your use case?

18:15 <zamundaaa[m]> manuels2: if you have a use case - meaning the actual thing you're trying to achieve, not "place window at x,y" - which can't be done right now, then feel free to make an issue describing that use case on the wayland protocols repository

18:16 <zamundaaa[m]> If for example that use case is restoring window state after restarting the app, that's already being worked on with a much better solution

18:18 <kennylevinsen> (not "I want to window to be there", but *why* you believe the window needs to be there)

20:14 <wlb> wayland-protocols Issue #253 opened by M. Stoeckl (mstoeckl) linux-dmabuf: do we need to specify maximum accepted dimensions for each (format, modifier) pair? https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/253

23:37 <Ermine> manuels2: the mail in question is https://lists.freedesktop.org/archives/wayland-devel/2024-April/043583.html

23:58 <Ermine> (the whole thread is a good reading though)