<Consolatis[m]1>
maybe the whole thing could be turned around. instead of adding custom wayland protocols and teach xwayland to use them one could also make the compositor open a unmapped X11 window and then listen to property changes and/or client messages there
grufwub has quit [Remote host closed the connection]
grufwub has joined #wayback
wezm has quit [Remote host closed the connection]
cow has quit [Remote host closed the connection]
<whitequark[cis]>
does it matter what the upstream wayland security philosophy is?
<whitequark[cis]>
whatever it is, they're clearly not very good at making it, or making it happen. and a private extension doesn't have to be approved by anyone
<ConanKudo[m]1>
only if we want to have something standardized or need to adapt xwayland
<whitequark[cis]>
right
_whitelogger has joined #wayback
jvvv has quit [Quit: WeeChat 4.6.3]
ThinkT510 has quit [Quit: ThinkT510]
__0x1eaf has joined #wayback
weirdtreething has quit [Remote host closed the connection]
weirdtreething has joined #wayback
jvvv has joined #wayback
<dramforever[m]1>
why is there a SIGSEGV handler in xwayback and xwayback only
<navi>
(why was my VLA question thread auto-resolved)
<navi>
(gitlab???)
<f_>
oh it's just gitlab being very smart as usual
<navi>
i don't know what criteria it has to "resolve" a thread automatically on push
<f_>
it autoresolves if the line referenced changed
<f_>
assuming the line has been fixed
<f_>
TBH it would be really awesome if someone went to pick the best of sourcehut and the best of gitlab and merge them together
<f_>
would be interesting to see the result
<navi>
i want to do that
<f_>
if only we all had infinite time, right?
<navi>
yeah
<dramforever[m]1>
in case anyone was wondering about me my troubles with trying to run wayback on my other laptop, it's notourbug, i can repro it on "normal" xwayland, gonna start knocking on other doors starting from mesa (which is the thing that's different) https://gitlab.freedesktop.org/mesa/mesa/-/issues/13564
<f_>
both good and bad news
<ConanKudo[m]1>
f_: I could turn off the autoresolve on diff change
<f_>
ConanKudo[m]1: oh that'd be awesome
<ConanKudo[m]1>
in general I usually don't because people forget to resolve discussions all the time
<f_>
also would be nice to give the ability for people to resolve threads
<ConanKudo[m]1>
but if we want it switched off, I can
<ConanKudo[m]1>
f_: that is not possible
<ConanKudo[m]1>
only project members and the MR creator can resolve threads
<f_>
Oh, so anything higher than Guest I suppose? Or something
<ConanKudo[m]1>
yeah
<ConanKudo[m]1>
developer or higher I think
<dramforever[m]1>
wait, does unresolved threads block merge now?
<f_>
yes, they do
<ConanKudo[m]1>
it always has
<dramforever[m]1>
can we turn this off
<ConanKudo[m]1>
it's a setting, but fdo gitlab defaults to it
<f_>
why?
<f_>
I find it useful
<f_>
(threads blocking merge that is)
<ConanKudo[m]1>
I would probably not disable autoresolve alongside maintaining thread blocking merge
<dramforever[m]1>
yeah
<f_>
hmm fair enough
<dramforever[m]1>
that's what i was thinking as well
<f_>
usually autoresolve kinda works I guess
<ConanKudo[m]1>
yeah, it's rare that it doesn't
<ConanKudo[m]1>
and tbh, a new thread should be made for new diffs anyway
<f_>
ok, then I guess it's reasonable to keep it on
<ConanKudo[m]1>
fun fact, long ago at $dayjob[-2], my team contributed that feature (toggling autoresolve)
<f_>
cool fun fact :)
<ConanKudo[m]1>
almost 8 years ago I think
<dramforever[m]1>
i think autoresolve is fine
<f_>
time flies fast
<dramforever[m]1>
it's not perfecft
<ConanKudo[m]1>
nothing really is
<dramforever[m]1>
neither is my typing apparently
<ConanKudo[m]1>
pobodys nerfect inded
<dramforever[m]1>
but yeah it does its job, mostly, and it's easy to override anyway
<f_>
neither is my fullscreen not actually fullscreen lxterminal
<dramforever[m]1>
f_: what was the good and bad news again
<f_>
dramforever[m]1: good news = not our bug, bad news = someone else's bug
<dramforever[m]1>
ah, my news, haha
<f_>
yes :)
<dramforever[m]1>
thought you had news to report
<f_>
nah I don't at the moment
<dramforever[m]1>
bad news = it still just doesn't work
<dramforever[m]1>
i was going to ask to block 0.1 if it's ourbug, because then we might have a rush in of users finding their kde crashes actually
<f_>
oh 0.1 doesn't have to be perfect
<dramforever[m]1>
well it still crashes, but we can blame someone else now
<ConanKudo[m]1>
and kde isn't going to be blocking criteria
<f_>
right now the main thing is getting wayback to a point where 'simple' environments works just fine
<f_>
stuff like icewm, windowmaker, etc
<ConanKudo[m]1>
and progman :)
<f_>
fvwm3... and obviously also progman, yes :)
<dramforever[m]1>
sure, but i was thinking like, well who knows what else might be broken
<dramforever[m]1>
turns out, other software
<f_>
Then we can progressively raise requirements
<f_>
to bigger DEs
<dramforever[m]1>
fwiw kde works completely fine on asahi linux for me
<dramforever[m]1>
like it really just works
* ConanKudo[m]1
shrugs
<dramforever[m]1>
i find this very impressive honestly
<f_>
dramforever[m]1: you mean, KDE works in Wayback in Asahi? Or s/in Wayback// ?
<dramforever[m]1>
in wayback, on asahi
<f_>
oh that's cool
<dramforever[m]1>
which has a different gpu and different driver, obviously
<dramforever[m]1>
do images go through to irc? like as a link?
<ConanKudo[m]1>
they show up as a link
<dramforever[m]1>
yeah that's the entire kde x11
<dramforever[m]1>
i'm not sure what i expected when i put startplasma-x11 in .xinitrc and did wayback-session, but it definitely wasn't "it just works, it turns out, especially if i use my docked setup with mouse and separate kb"
__0x1eaf has quit [Quit: Lost terminal]
<whitequark[cis]>
nice
<f_>
That's really cool
<f_>
I remember whitequark brought up that it's not working
<whitequark[cis]>
i believe the reason it seems to not work is that i have two monitors
<whitequark[cis]>
it most likely has nothing to do with startplasma-x11 specifically
<f_>
I guess it might be how it's setup there? Not to say you should change anything when it works on regular Xserver
<whitequark[cis]>
i created a new user just to be sure i don't have some detail of my setup mess things up
<f_>
whitequark[cis]: I mean, your setup, if it works in Xserver, should definitely work in wayback
<f_>
wayback is supposed to be Xserver-compatible
<f_>
If something works in Xserver and doesn't in wayback that's a bug
<whitequark[cis]>
ah yes. but the multi-monitor issue is a known one
<f_>
yes
<dramforever[m]1>
you could set the monitor now
<dramforever[m]1>
it's a hack but it ... kinda works to pick one monitor
<dramforever[m]1>
<whitequark[cis]> i believe the reason it seems to not work is that i have two monitors
<dramforever[m]1>
this was back before $WAYBACK_OUTPUT
<dramforever[m]1>
because that's where it crashes and iris vs asahi one of the two variables that changed (well, the other is x86_64 vs aarch64 but i have no other computers)
<dramforever[m]1>
ugh
<dramforever[m]1>
i wonder if they'll blame it on nvidia
<dramforever[m]1>
i'm fairly sure this happens without nvidia, it's not even remotely involved
<f_>
whitequark[cis], dramforever[m]1: does regular wlroots/TinyWL/wayland work on your hardware?
<whitequark[cis]>
how do i test this?
<whitequark[cis]>
dramforever: i think i don't even have the nvidia drivers installed
<whitequark[cis]>
wait, do you have the same dell laptop as i do?