ChanServ changed the topic of #wayland to: https://wayland.freedesktop.org | Discussion about the Wayland protocol and its implementations, plus libinput
Moprius has quit [Quit: bye]
sevz has joined #wayland
Leopold__ has joined #wayland
Leopold_ has quit [Ping timeout: 480 seconds]
co1umbarius has joined #wayland
columbarius has quit [Ping timeout: 480 seconds]
Nova[m] has joined #wayland
ongy[m] has joined #wayland
yshui` has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
ttancos[m] has joined #wayland
tent405 has quit [Quit: tent405]
ambasta[m] has joined #wayland
fmuellner has quit [Ping timeout: 480 seconds]
danburd[m] has joined #wayland
nerdopolis has quit [Ping timeout: 480 seconds]
Company has quit [Quit: Leaving]
Nico has joined #wayland
bindu has joined #wayland
NepNepdmsalwaysopen[m] has joined #wayland
sergi1 has joined #wayland
kts has joined #wayland
qaqland[m] has joined #wayland
botiapa[m] has joined #wayland
joantorres[m] has joined #wayland
Poly[m] has joined #wayland
RomanGilg[m] has joined #wayland
FbioPacheco[m] has joined #wayland
YHNdnzj[moz] has joined #wayland
sevz17 has joined #wayland
sevz has quit [Ping timeout: 480 seconds]
kts has quit [Ping timeout: 480 seconds]
Leopold__ has quit [Remote host closed the connection]
Shimmy[m] has joined #wayland
Leopold_ has joined #wayland
gspbirel5687340886706131448762 has quit [Ping timeout: 480 seconds]
mboudr35[m] has joined #wayland
tzx[m] has joined #wayland
tzimmermann has joined #wayland
systwi has quit [Ping timeout: 480 seconds]
orowith2os[m] has joined #wayland
sima has joined #wayland
sevz17 has quit [Quit: WeeChat 4.0.5]
sevz has joined #wayland
floof58 has quit [Ping timeout: 480 seconds]
junaid has joined #wayland
floof58 has joined #wayland
iomari891 has joined #wayland
leon-anavi has joined #wayland
iomari891 has quit [Ping timeout: 480 seconds]
<ambasta[m]>
Hi, I've been going through https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 Would compositors providing virtual resolutions to clients make more sense? i.e. clients request for a window with some value (or range of) for resolution and aspect ratio. Clients render what they like in this virtual window. Compositors can communicate updated resolutions/aspect ratios on resizing to the closest possible allowed
<ambasta[m]>
values. When a window is resized to an aspect ratio beyond its supported range, transparent black bars could be used to avoid breakage. Is this a sensible approach or overly complicated/infeasible? The only issue I can think of is click detection (i.e. detecting which window/component was clicked, specially w/ transparent window contents)
rgallaispou has quit [Read error: Connection reset by peer]
rgallaispou has joined #wayland
iomari891 has joined #wayland
<psykose>
can't applications do that already with a subcompositor
<ambasta[m]>
psykose: Well, if they can, then why is there an insistence on absolute positioning?
mvlad has joined #wayland
<psykose>
because they want to open windows at absolute positions being multi-windowed applications
<psykose>
what you're describing is "what if they rewrote their entire application to do this other thing", and in that case they could find a different way to approach it
<psykose>
maybe i'm misreading what you mean mechanically
<psykose>
in the end it all boils down to "nobody wants to rewrite anything in their application, but they want absolute positions", and then it goes in a loop of "try this instead" -> "nobody would do that" -> ...
<psykose>
i don't think there's a magic gotcha suggestion that gives absolute coords but actually doesn't and everyone is happy
<ambasta[m]>
I still don't see why they want absolute positions. Even in a multi window app, they can open multiple windows in a larger virtual window with some supported resolution/aspect ratio range
<ambasta[m]>
And then the user/compositor can decide where and how they want this multiwindow app to be positioned
<ambasta[m]>
As for nobody would do that, maybe implementing a playground app to highlight how this could work might be sufficient?
<psykose>
yes, and that "big window with things in it" is an embedded compositor and they would have to port to it, and nobody would do that
<ambasta[m]>
I see
<ambasta[m]>
Maybe a toolkit issue then
<ambasta[m]>
But I think the desire for applications to specify absolute positions, even on a desktop is not right. At least coming as a TWM user, who wants to play games that don't force fullscreen and crash when I resize them
<ambasta[m]>
In any case, thanks psykose
<psykose>
yeah, it would be a toolkit issue in some sense
<psykose>
that's touched on in the last link; nobody would change toolkits, but how would Qt suddenly allow this to be possible with minimal changes?
<ambasta[m]>
I think the toolkit approach is feasible (start everything in a virtual window by default). But I am not a gui developer to actually forsee the details
<ambasta[m]>
Or maybe, just start mutiple processes (one per window) and have them communicate w/ each other in a server/client model
<ambasta[m]>
I think embedded/toolkit/multi-process are all addressed in the MR (and thanks to this discussion, now the MR responses make sense)
<pq>
swick[m], you have access to ISO 22028-1? That Encoding Solutions is one of the few books I actually have.
<kennylevinsen>
ambasta[m]: GIMP is a good example of an application that went from old-fashioned multi-window to single-window btw
<kennylevinsen>
very much possible as is, and arguably quite the UX improvement...
<ambasta[m]>
Yep, I was so happy when it came out
<ambasta[m]>
Also, thank you for greetd
<kennylevinsen>
glad you like it :)
<swick[m]>
pq: eh, no, the summary paper of the standard
<pq>
ah
<JEEB>
I am sad ISO stopped N-Documents being accessible. they already had a setting per-document whether it was private or not :<
rasterman has joined #wayland
molinari has joined #wayland
kelnos has quit [Remote host closed the connection]
kelnos has joined #wayland
systwi has joined #wayland
rgallaispou has quit [Read error: Connection reset by peer]
<ManMower>
any1: commit-timing-v1 doesn't provide a queue
<any1>
If the compositor doesn't hold onto buffers until their pts passes, I don't really see the point.
<ManMower>
commit-queue-v1 will be an MR sometime next week ;)
<ManMower>
I just didn't think "protocol to add timestamps to pending commit state" and "protocol to make pending commit state a queue instead of a single entry" were things that must be in the same protocol
<ManMower>
(and I think the previous attempts to timestamp have died in part because they overreached)
<any1>
Smaller composable units are better than big things with knobs and dials
Moprius has quit [Quit: bye]
<ManMower>
yeah
mblenc has joined #wayland
navi has joined #wayland
vaxry has joined #wayland
shankaru has quit [Read error: Connection reset by peer]
shankaru has joined #wayland
aswar002 has quit [Read error: Connection reset by peer]
aswar002 has joined #wayland
shankaru has quit [Read error: Connection reset by peer]