<dviola>
would it be possible to add sx compatibility for wayback-session? some of us use sx rather than startx (xorg-xinit): https://github.com/Earnestly/sx
<dviola>
the config for that is in XDG_CONFIG_HOME/sx/sxrc
<dviola>
or maybe something similar that uses XDG_CONFIG_HOME
<dviola>
doesn't have to be sx
<dviola>
the latter would be better I think
weirdtreething has quit [Ping timeout: 248 seconds]
weirdtreething has joined #wayback
<axtlos>
dviola: there's no point, once Xwayback is a full replacement you'll just be able to use sx
<dviola>
cool!
<dviola>
this project has such a cool vibe to it, can't explain... can't wait to run my i3 with xscreensaver haha
<axtlos>
if you don't need multi monitor support you can already do that !
<dviola>
playing some retro games for extra nostalgic points on top
<f_>
I want to do some coding style fixes today, I've seen some inconsistentness in that area
<f_>
this one's not going to be long
<f_>
I want to list available packages for various distros, all I know are the alpine one and the AUR one. Anything else?
<Achill[m]>
i heard the copr exists for fedora
<axtlos>
I'm not sure if its a good idea to list packages yet
<axtlos>
we haven't had a stable release yet and there are still a bunch of changes we're adding very rapidly, debugging will be harder when people open bug reports on an older commit
norwoodites has joined #wayback
pinskia has quit [Ping timeout: 245 seconds]
<f_>
axtlos: yeah I know, we could tell people to not report bugs on these packages and to reproduce the bugs they get on latest git
<axtlos>
sadly thats very commonly ignored, we will still get a lot of bug reports from these packages
<f_>
speaking of bug reports I would like to add an issue template people can fill
<axtlos>
oh yeah true
<f_>
I'll do that
<f_>
like I said like days ago I want to work on a lil website as well :)
<f_>
and I think some labels would be good too
<f_>
e.g. type::feature type::bug env::windowmaker etc, stuff like that
user0thenyancat_ has quit [Ping timeout: 252 seconds]
arraybolt3 has quit [Ping timeout: 276 seconds]
<axtlos>
f_: shouldn't the issue templates be in a separate MR?
<f_>
axtlos: hm, I figured that given that MR is pretty small that adding a few doc stuff wouldn't hurt
<f_>
but I can split those
<axtlos>
my main concern is that the MR also adds a new feature
<f_>
and it is a valid concern
<f_>
I'll split the docs thing
<f_>
and the coding style stuff
<axtlos>
alright, thanks
<f_>
you're welcome, thanks for being so quick in reviewing in the first place :)
<f_>
as for issue labels I obviously can't do it, but I can bring a list of things I think would be interesting to have
<axtlos>
I'm mostly neutral regarding what labels we have, though I'd really like it if we used the good-first-issue label for bugs that can be easily fixed
<axtlos>
it can be intimidating for people seeking to contribute to a project when they dont know where to start, having that label helps a lot
<f_>
yep 100% agree
<ConanKudo[m]1>
I'm not planning on merging the code style MR
<ConanKudo[m]1>
I'd rather us have a clang-format definition to use and then apply it to the codebase and pipelines
<axtlos>
the XWAYLAND_PATH MR you merged is broken
<axtlos>
as I said in the review, the envvar isnt actually used
<f_>
oops
<f_>
I will fix it
<f_>
ConanKudo[m]1: the MR is not something about establishing some actual coding style guidelines, I had just found some small inconsistencies that I thought I'd fix
<f_>
but yes a clang-format definition would definitely help
<ConanKudo[m]1>
axtlos: lol oops I misread the diff
<ConanKudo[m]1>
GNOME folks do this and I don't really like the GNOME coding style
<navi>
mozilla seems to be like linux but without braceless-single-statement
<navi>
bit annoying but fine for me
<f_>
hmm yeah braceless-single-statement would be good to keep
<f_>
but not a big deal eithe
<f_>
+r
<axtlos>
We can just overwrite that in our config
<f_>
yep, that too
<whitequark[cis]>
"similar to linux" good enough i don't care what the details are
<whitequark[cis]>
as long as you don't require me to mix tabs and spaces like it's fucking 1980, or use that editor-breaking abomination of braces that i can't really use unless i jump through some hoops, i don't care
<ConanKudo[m]1>
I don't particularly like braceless single statements :P
__0x1eaf has quit [Quit: leaving]
<f_>
ConanKudo[m]1: wow you're quick
<ConanKudo[m]1>
trying to get the clang-format CI check right still :/
<f_>
some thoughts on !51: I really like it, just nitpick that I prefer "char *something" to "char* something" but this shouldn't block it
<whitequark[cis]>
yeah, char *something is how the compiler sees it anyway :p
<f_>
also there's no 80char limit? But eh who cares
<ConanKudo[m]1>
oh hey TIL of git-clang-format
<navi>
`type *variable` is more correct for c, imo
<f_>
why not use actual monospace on irc while at it /s
<ConanKudo[m]1>
f_: I don't think an 80 char limit makes sense
<f_>
ConanKudo[m]1: ok that makes sense
<navi>
100 softlimit 120 hardlimit is more standard now a days i think
<f_>
I mean you thinking that an 80char limit doesn't make sense, makes sense
<navi>
than 80
<f_>
hmm yeah
<ConanKudo[m]1>
hmm, I'll set 120 for the column limit
<ConanKudo[m]1>
err 100
<ConanKudo[m]1>
f_, Catherine: changed it to pointeralignment: right
<ConanKudo[m]1>
mostly because I don't care enough even if I consider that style a footgun
<whitequark[cis]>
wait, the right one is a footgun?
<ConanKudo[m]1>
when you're thinking of label -> data, yes it can be
<whitequark[cis]>
what do you mean by that?
<whitequark[cis]>
i'm mostly just curious
<f_>
let's just say that both can be a footgun depending on usage lol
<ConanKudo[m]1>
reading variable definitions right to left, having the label stand alone and then the data type be grouped after the space means it's obvious that the label is for a data type
<ConanKudo[m]1>
e.g. foo is a typed pointer when void* foo
<ConanKudo[m]1>
that tells you that foo is not data in itself, but a reference to data
<whitequark[cis]>
i don't see a label here? I'm confused
<ConanKudo[m]1>
label is the variable name
<whitequark[cis]>
oh, the identifier
<ConanKudo[m]1>
again this is mostly how I was taught and read code
<whitequark[cis]>
wouldn't you still be able to see that either way? since void isn't in itself a valid type
<ConanKudo[m]1>
I'm using void as a substitute for arbitrary types
<ConanKudo[m]1>
it could be char, it could be a struct or something
<whitequark[cis]>
right okay
<ConanKudo[m]1>
the idea is that you group the data classification identifiers separately from the label
<whitequark[cis]>
i think both of the following styles are equally unambiguous and robust: star-on-the-right, or star-on-the-left and never having more than one identifier declared per line
<navi>
my issue is that i've seen many people going `char* foo, nya;` and trying to use nya as a string
<navi>
then wondering why things segfault
<whitequark[cis]>
yeah that's the usual objection
<whitequark[cis]>
it's not actually a big deal these days since even the default complement of warnings in gcc or clang will catch this in nearly every case
<ConanKudo[m]1>
yeah
<navi>
c-decl works by going "what do you write to get <type>", so "char *foo" is "you write `*foo` and get a `char`"
<ConanKudo[m]1>
though this thing is the reason I don't like C and typically write C++ :P
<whitequark[cis]>
as a compiler / PL person i like having the style of a declaration reflect how it's parsed by the compiler
<ConanKudo[m]1>
that's fair
<ConanKudo[m]1>
I generally prefer how a human should interpret it rather than the compiler interpreting it
<whitequark[cis]>
it's fundamentally an aesthetic choice since the cost is so minimal either way
<ConanKudo[m]1>
yup
<whitequark[cis]>
i don't think those are different
<ConanKudo[m]1>
and like I said, I don't care enough to fight one way or another
<ConanKudo[m]1>
it's a twiddle either way
<whitequark[cis]>
or, rather: if those are commonly different you've failed at language design
<whitequark[cis]>
both humans and compilers must operate on a shared syntactic and semantic model, or the collaboration won't work
<ConanKudo[m]1>
a lot of newer languages do fail at this :P
<whitequark[cis]>
nah
<f_>
like I said I don't want to start a fight on coding style :p
<whitequark[cis]>
a language cannot fail at this in the same way as a speaker cannot fail to make something comprehensible to an audience of 0
<f_>
If it were to stay "char* foo" it would not be the end of the world either
<whitequark[cis]>
even at the most basic level, you have "knowledge embedded in individual compilers", "knowledge embedded in individual humans", and "culture that shapes both, primarily seen in how languages are taught"
<whitequark[cis]>
you yourself have pointed out the latter!
<whitequark[cis]>
the change in any of the three can make a previously functioning human/machine collaboration fall apart
<whitequark[cis]>
e.g. if a few people got used to C compilers which were basically glorified macroassemblers (have you ever looked up how struct fields were originally implemented in C, or was it in B? it's wild), the change in the compilers will be catastrophic even if the standard hasn't differed one bit
* ConanKudo[m]1
learned C originally on the old Borland compilers for DOS
<ConanKudo[m]1>
I'm pretty sure I still have a copy of Turbo C for DOS somewhere
<whitequark[cis]>
(a field was just a fully global name that was more or less an alias for a number. the number got added to the pointee. this is why we're stuck with shit like st_ino and the like in POSIX)
<whitequark[cis]>
ConanKudo[m]1: me too, actually
<ConanKudo[m]1>
f_: I already changed it because y'all prefer it the other way
<ConanKudo[m]1>
so we're basically arguing for nothing
<whitequark[cis]>
oh, i wasn't arguing
<whitequark[cis]>
you were just the first person who i've seen have an issue with it, so i wanted to understand how you comprehend code
<ConanKudo[m]1>
ah
<ConanKudo[m]1>
yeah
<ConanKudo[m]1>
it's mostly down to I like to have grouping of data and labels
<ConanKudo[m]1>
it also makes it easier to match with diagnostics since they only print out data
<whitequark[cis]>
my background in language design (and most of my career has been spent as a professional language designer), so it's a topic of interest
<whitequark[cis]>
i avoid writing C and when i do i just match the style of whatever the codebase is, so i couldn't care less what it is so long as it doesn't break my editor
<navi>
i actually always wondered why some posix/unix fields had the weird prefix
<navi>
neat to know, and also, that's cursed
<ConanKudo[m]1>
but C is already somewhat confused about this since you initialize arrays on the other side of the label
<whitequark[cis]>
i think it might also be related to the use of anonymous unions
<navi>
ConanKudo[m]1: it's the c-decl thing i mentioned
<ConanKudo[m]1>
yeah
<whitequark[cis]>
initialize arrays, or specify array dimensions?
<navi>
`int foo[2];`, how do you get an int? you type `foo[1];`
<ConanKudo[m]1>
yeah, I already knew this
<ConanKudo[m]1>
I just sort of handwave it for my code
<ConanKudo[m]1>
but meh
<navi>
declaration matches access, people often don't realize that -- after i learnt it a lot of it clicked
<navi>
even the weird function-pointer decl clicked
<ConanKudo[m]1>
yeah
<navi>
it may not be ideal now a days, but it's neat to know that it was made with some intent behind it
<whitequark[cis]>
it's kind of a "right idea in the wrong place" thing
<whitequark[cis]>
with ML-style pattern matching, you write the pattern in the same shape as you would write the constructor. that works exceptionally well
<whitequark[cis]>
doing this for types has just served to confuse people
<ConanKudo[m]1>
hmm, I wonder if I can set c++23, since that is a C/C++ harmonization level
<ConanKudo[m]1>
we also need criteria for an initial release
__0x1eaf has joined #wayback
<f_>
hmmm yeah
<whitequark[cis]>
(selfishly) "can run startplasma-x11"
<f_>
Ariadne said she would be fine releasing wayback v0.1 in its current state
<f_>
But maybe could use gitlab's "milestone" feature thing for an eventual "v1.0" release
<ConanKudo[m]1>
I don't really want to aim for "plasma x11" given I expect that session to continue to rot
<axtlos>
Yeah our test targets should mainly be towards X only desktops
<whitequark[cis]>
that's literally the only thing i want to use wayback for
<f_>
I mean
<axtlos>
well no ones stopping you
<f_>
would be cool to have plasma-x11 running in wayback
<ConanKudo[m]1>
that's fine if you want to use it for that, but I don't think troubleshooting kwin-x11 and wayback and xwayland is not going to be fun
<axtlos>
but i dont think thats something we should test for, since plasma is moving towards a wayland session
<axtlos>
wayland only*
<f_>
^ yep
<f_>
or, at most, not test too much
<ConanKudo[m]1>
lol, double negatives
<whitequark[cis]>
that ... sucks?
<f_>
of course if someone wants to work on debugging them when they have problems they're welcome
<ConanKudo[m]1>
distracted while solar panels are being installed
<whitequark[cis]>
if it's supposed to be a Xorg drop-in replacement then it should run startplasma-x11
<f_>
yes
<axtlos>
we're not saying it doesn't
<axtlos>
or wont
<ConanKudo[m]1>
right, but that's different from us qualifying things for release
<f_>
we're just saying it might not be well-tested for now
<whitequark[cis]>
(it doesn't, i tested it)
<f_>
For now I think we should start with simple requirements
<ConanKudo[m]1>
yeah
<ConanKudo[m]1>
I'm thinking a couple of X11 only window managers
<axtlos>
i do all testing with xfce, mate and i3
<f_>
Then as development continues aim for gradually more and more support, (eventually plasma-x11 if you want)
<ConanKudo[m]1>
I personally like fiddling with jcs/progman and I think some flavor of fvwm is probably a good candidate
<f_>
fvwm works perfectly
<f_>
but I don't have it installed on my laptop right now anymore, I do my testing with WindowMaker now
<f_>
because I actually kind of like its look and feel
<ConanKudo[m]1>
heh
<ConanKudo[m]1>
I'm a sucker for Program Manager, hence progman
<f_>
:D
<axtlos>
i love wmaker, cant wait for wayback to get multi monitor support so i can switch to it
<ConanKudo[m]1>
my first GUI was Windows 3.1
<f_>
I remember installing like 10-15 desktop environments on my computer years ago
<navi>
xwayback should run anything xorg can
<navi>
i think it's less "it should do this" and more "can we trust kde to keep kwin-x11 functional over time"
<ConanKudo[m]1>
yup
<axtlos>
yeah
<navi>
or startplasma-x11 fwiw
<ConanKudo[m]1>
and as a KDE developer, I can basically say the answer is "maybe"
<ConanKudo[m]1>
with a tendency to "no"
<whitequark[cis]>
yep, i'm aware of that
<whitequark[cis]>
but so long as it runs on xorg it should run on wayback as well
<navi>
^ i also say so
<navi>
if something works on Xorg and not on Xwayback, it should be considered a bug to try to fix
<whitequark[cis]>
the question becomes murkier if/when xorg gets entirely deprecated
<whitequark[cis]>
i assume that by that point startplasma-x11 will not exist anymore
<axtlos>
yes, no one denied that, the point is that with plasma x11 losing support over time our priority should be with X only desktops
<whitequark[cis]>
but who knows
<navi>
if Xorg is fully deprecated things don't change much for us tbh
<axtlos>
because with plasma x11 becoming less maintained it means that we may encounter bugs that are actually on the plasma side
<navi>
the functionally target is there
<ConanKudo[m]1>
yeah
<ConanKudo[m]1>
and I know this is already an issue today
<navi>
and if we hit it, then when somethign breaks on Xwayback i'd also break on Xorg and so, not our problem
<navi>
(hit the functionality target)
<ConanKudo[m]1>
my concern about plasma x11 as a milestone is that it's a hell of a lot to troubleshoot to identify where the problem is when upstream KDE isn't interested
<axtlos>
either way plasma 6.3 just launched perfectly fine for me on wayback
<whitequark[cis]>
but wayback isn't made for KDE developers, it's made for KDE users (among others)
<ConanKudo[m]1>
I also might be the odd one out here in that I mostly like Wayland, I just want wayback for classic wms
<axtlos>
(6.3 because void hasnt updated to 6.4 yet)
<axtlos>
ConanKudo[m]1: Oh no its the same for me lol
<whitequark[cis]>
axtlos: i think it might be related to multiple monitors and how the second one has a like 0x0 visible area or something
<navi>
ConanKudo[m]1: i'm never going to use wayback myself, so i'm also odd
<navi>
i'm here purely to help write good code
<whitequark[cis]>
i haven't tried it with a single monitor because i don't think there's any way to do that with wayback
<navi>
and help the ecosystem work for more people
<whitequark[cis]>
it finds both my external monitor and the internal laptop one
<ConanKudo[m]1>
navi: that's... kind of me too?
<ConanKudo[m]1>
aside from futzing with progman :)
<f_>
17:01 <ConanKudo[m]1> I also might be the odd one out here in that I mostly like Wayland, I just want wayback for classic wms
<f_>
oh you're not the only one
<f_>
I like wayland too
<whitequark[cis]>
i have absolutely no interest in historical x11 desktops or applications, i find them ugly and usually too broken on hidpi displays (even tk, which seems to do better than many), i just want my desktop to continue running
<f_>
in fact I'm typing from sway
<ConanKudo[m]1>
Plasma Wayland here :)
<navi>
i'm typing from sway, and working on my own compositor from scratch
<navi>
(well, not right now, but ykwim)
<f_>
but I do want to use a classic wm from time to time :)
<ConanKudo[m]1>
tbh, if I had the skill and time, I'd make a progman wayland compositor like the guy who made a windowmaker wayland compositor
arraybolt3 has joined #wayback
<f_>
whitequark[cis]: to be clear, none of of is saying to not support plasma
<f_>
none of us*
<whitequark[cis]>
the main reason i might eventually migrate to wayland would be to design a compositor from scratch which melds two desktops over a high-latency link into a single virtual desktop where any participant can use windows of any other participant in sync
<axtlos>
the windowmaker wayland compositor is sadly kinda lackluster
<whitequark[cis]>
it should also share USB devices over usbip
* ToyKeeper
wakes at mention of TK ... oh, wrong TK. :P
<ConanKudo[m]1>
Catherine: that would be very neat
<whitequark[cis]>
f_: yeah, i realize that
<f_>
whitequark[cis]: but we should first start with simple requirements
<whitequark[cis]>
Conan Kudo: yes. goes hand in hand with experiments with distributed consciousness
<whitequark[cis]>
(which is in fact the entire motivation for that compositor)
<f_>
and I can imagine running plasma-x11 in wayback to be a good way to check that wayback is mostly working as intended for a given full DE
<axtlos>
actually, is there any desktop/wm that *doesn't* run in a simple single screen setup?
<whitequark[cis]>
wayland makes it quite a bit easier than x11 but the amount of surface area to learn has been daunting even for me
<axtlos>
every one i tried so far kinda just worked
<f_>
(provided there aew no bugs on plasma's side)
<f_>
s/aew/are/
<ToyKeeper>
I love lots of old X11 programs. Hell, I still use John Bradley's "xv" from 1994 on a daily basis, because I still haven't found anything which is better at what it does.
<ConanKudo[m]1>
Catherine: at least nowadays there are compositor libraries that make it easier: wlroots, mir, louvre, libweston, etc.
<axtlos>
uhh who's Catherine? is my client hiding messages?
<whitequark[cis]>
so i've heard. but it's still a massive amount of surface area to learn, with its own complex quirks and impedance mismatches
<f_>
axtlos: It's a matrix-appservice-irc bug
<whitequark[cis]>
axtlos: me
<axtlos>
ohh ok
<f_>
whitequark[cis]'s displayname on Matrix is not "whitequark" but "Catherine
<axtlos>
right
<f_>
and the bridge fails to properly replace pings
<f_>
er, doesn't fail to do it
<f_>
it doesn't even make an attempt at doing it at all
<f_|cat>
@libera_f_:catircservices.org: which is why this ping looks ugly
<f_>
Anyway.
<ConanKudo[m]1>
f_: it does it if you log into IRC through the bridge
<ConanKudo[m]1>
I've seen this on the OFTC one
<ConanKudo[m]1>
when you set the nick and log in on the bridge it works
<whitequark[cis]>
is there even a wayland compositor library for rust? i loathe the idea of developing new software in c++ when it is designed to operate on potentially-untrusted networks and has essentially root privileges
<ConanKudo[m]1>
they even finally started doing releases recently
<f_>
ConanKudo[m]1: nah it never does
<f_>
regardless of if you're logged in to nickserv
<whitequark[cis]>
there's a really interesting challenge in doing proper low-latency streaming of audio/video data. i would probably do webrtc but "do webrtc" is a very "now draw the rest of the owl" type of statement
<navi>
i would honestly write the networked part as a separate daemon
<navi>
and proxy things
<f_>
on oftc I see matrix users mentioning you as saying "Conan Kudo: " so .. :p
<navi>
than to do it in the compositor itself
<f_>
except when using reply-to
<whitequark[cis]>
navi: one could consider a few choices for the architecture, yeah. but in general i just don't think writing new c++ code, especially security-adjacent c++ code, is a great call
* ConanKudo[m]1
shrugs
<whitequark[cis]>
as the author of the first (to my knowledge) memory-safe and no-heap tcp/ip stack you might expect me to have a fairly hardline position on this :p
<ConanKudo[m]1>
I don't like Rust much and still prefer C++ for my stuff
<whitequark[cis]>
my moderate dislike for rust is far overshadowed by the intense hatred for c++ that increases with every bit of c++ experience i get
<f_>
std::cout << "hi" << std::endl;
<whitequark[cis]>
i can write good c++ code. i just think it is a societal failure that i have to
<f_>
I started learning C++ before but then I wrote C code instead and never publicly wrote C++ (IIRC)
<f_>
and I didn't learn all of C++ anyway
<ari[m]>
i enjoy compiler/tooling that stops me from doing overly stupid things
<whitequark[cis]>
it is exactly *because* i can write good c++ code that i think nobody else on the planet should be subjected to the same experience
<navi>
i stay away from discussions to which language "should" or "should not" be used -- i never have good experiences talking about that, and would like to not have mh issues -- i personally use c for every systems software i write and that's it
<navi>
i pointed out the network thing bc
<navi>
regardless of language
<navi>
it's a better choice to not do too much in the compositor
<f_>
At the end of the day each programming language has usecases where it shines
<f_>
end of story :p
<whitequark[cis]>
as a language designer i don't have the freedom of shying away from the question of "which language should be used", because the languages i build would be the ones that should be used
<whitequark[cis]>
(i suppose i should clarify that i build languages for others to use, with myself happening to be in that group of others. it's not a personal endeavor)
__0x1eaf has quit [Quit: Lost terminal]
<navi>
making the question is one thing, dicussing with it online with people i'm not close to is what is not good for my mental health
<navi>
anyway
<navi>
i'll move on
<whitequark[cis]>
before i found rust i was building something quite similar in concept (although much more primitive) that i deprecated in favor of "just using rust"
<whitequark[cis]>
re: networking: most of what this compositor would be doing is multiplexing concurrent event streams. i could put the part where it literally puts data into sockets into another process but i don't see what this achieves. you still have to do deserialization and processing somewhere close to the state of the compositor
<navi>
the compositor has the whole job of driving input and output, if it freezes not even switching ttys work
<navi>
keeping it minimal is for simplicity, and the wayland protocol is easy to proxy with a client
<whitequark[cis]>
yes, it's a soft-realtime application
<whitequark[cis]>
the things i'm concerned about perhaps even more than serialization or buffer overrun bugs are logic errors, of the sort "i'd like keyboard input into a local window to not be sent remotely". i'm still undecided whether it's even feasible to deal with that in a way where it would provide a meaningful reassurance that it works as designed
<whitequark[cis]>
would you be putting a lot of trust into a counterparty with this compositor? yes, of course. but also, right now i'm using vscode's liveshare and i usually enable the terminal. vscode disables sudo somehow (i think it intentionally breaks every suid application inside its terminal or something?) but that's not a serious deterrent
<whitequark[cis]>
so there's a balance between "you are basically doing the internet equivalent of letting someone use your physical mouse and keyboard and monitor. of course it's sketchy" and "but can we do even slightly better?"
<navi>
and having the networked windows be spawned by a client also solves that, in ways of, the compositor only sends input to the focused client (bar extension protocols that say otherwise)
<navi>
not sending anything to the networked client == local only
<whitequark[cis]>
(even if you have absolute trust in every counterparty you're using this compositor with, which you really should, their machine could be compromised without their knowledge)
<navi>
then you sync only the buffer and window state with the other parties
<navi>
no actual input, unless you're typing in a window from them
<whitequark[cis]>
navi: sure, i think "only the focused client receives input" is a wayland staple that's not going anywhere no matter the architecture. but one thing you need to make sure you do right is to clearly and unforgeably mark networked windows as such
<whitequark[cis]>
that sounds like it would imply server-side decorations, actually
<navi>
was about to say
<navi>
xdg-toplevel-tag + s-s-d
<navi>
ssd*
<navi>
niri has a similar-ish thing where it highlights any window that is being recorded by the portal
<navi>
so you never record something you shouldn't accidentally
<whitequark[cis]>
i think one issue with this discussion is that i'm not yet sure what the basic architecture of the project would be, due to not knowing enough about wayland still
<whitequark[cis]>
a basic requirement is the ability to have the same window be focused by both a local and a remote party, with the input being combined into one stream
<f_>
and thought it'd be cool to have a windowmaker-esque window on the main page
<whitequark[cis]>
e.g. if one holds "a" and another holds "b" you just get a stream of "ababab" interleaved in some up-to-network-latency way entered
<whitequark[cis]>
as opposed to e.g. taking an exclusive lock on the input whenever you focus a window
<navi>
focus and cursor position sync is easily doable with an extension protocol
<whitequark[cis]>
with mice you'd effectively have two cursors, which i think is something that wayland can do
<navi>
mixing keyboard events sounds doable too
<whitequark[cis]>
ok, but i actually don't want to have focus sync
<navi>
oh i misread
<whitequark[cis]>
because it's perfectly sensible for me to work in window A (remote or local) and my counterparty on window B (remote or local)
<navi>
but still, doable the same
<whitequark[cis]>
i'm actually not sure what the extension protocol would be for
<whitequark[cis]>
doesn't the compositor itself sit between the applications and the input devices?
<navi>
(i'm still thinking of having a client do the network integration to avoid mistakes)
<whitequark[cis]>
it already has the position that lets it capture and interpose whatever it wants
<navi>
so the extension woudl be for it
<whitequark[cis]>
how would the client get a hold of the GL surfaces for each window?
<navi>
anyway doing keyboard mixing is also easy, input to local windows stay local, input for remote windows is sent over the wire
<whitequark[cis]>
this is something that i want to shove into an on-GPU h.264 encoder without copies, ideally
<whitequark[cis]>
copies of framebuffers at 4K really bite
<whitequark[cis]>
i realize i could use one of the existing video capture extensions to make it essentially do a screencast, but that kind of barely works as it is, without any additional requirements like "it also needs to be reasonably snappy under input"
<navi>
you'll need to serialize the buffers in ram to send them over the wire anyway, so you can use the image-copy protocol or similar, and do damage tracking
<ConanKudo[m]1>
f_: that looks great
<whitequark[cis]>
i wouldn't be sending buffers, i would be sending h.264 streams
<navi>
waypipe has solved that
<axtlos>
f_: Like it a lot, though i'm personally more a fan of the default wmaker window borders
<navi>
and it was low latency enough for me to play high fps games comfortably
<navi>
(it does stream a video, dunno the code specifically)
<axtlos>
waypipe is a video stream? i thought it forwarded wayland messages to a shared buffer
<whitequark[cis]>
right, i should play with waypipe a bunch first, i've seen it before. i suspect it might not work well enough for what i'm targeting based on the "technical limitations" in its README, but it's worth understanding the tradeoffs it does
<whitequark[cis]>
it does use libva for video encoding/decoding
<f_>
axtlos: hm how do they look like actually?
<whitequark[cis]>
which implies it's a video stream
<whitequark[cis]>
well it also serializes wayland messages
<ConanKudo[m]1>
navi: there's some fanciness about wayland socket redirection and proxying
<whitequark[cis]>
navi: the next thing i'm thinking about is bridging audio and networking. networking is easy, i'm not sure about audio
<axtlos>
f_: I mean im fine with either one tbh, both portray the same message
<navi>
whitequark[cis]: audio it would be something like a pipewire or pulse proxy
<navi>
i have no idea about that though
<navi>
never touched it outside of an end-user context
<whitequark[cis]>
yeah i think it would involve getting a monitor channel from pipewire for a specific window (which KDE knows how to do, so there must be an API for it), then encoding it together with the video for that window, and sending it over
<whitequark[cis]>
which sounds like a giant pain in the ass
<whitequark[cis]>
but doable
<f_>
axtlos: "hey you can run good ol' WindowMaker with this :D"
<whitequark[cis]>
navi: one thing i've been thinking about is: let's say i want to continue using i3 and my counterparty wants to continue using plasma, rather than replacing both of our system compositors with this thing i write, which won't ever satisfy everyone
<navi>
ConanKudo[m]1: i'm not finding anything about not using any video streaming at all in the docs
<navi>
whitequark[cis]: another case where a proxy client even makes more sense
<whitequark[cis]>
in this context, it seems like it would make sense to wrap around a wayland application
<navi>
it can do the keyboard mixing, use ext-virtual-keyboard to insert remote key events locally
<whitequark[cis]>
yeah, i think a proxy client (assuming we're thinking of the same thing) in this case is basically the only reasonable way to implement it
<navi>
and send over any local key event to the remote
<navi>
it would be basically a two-way waypipe
<navi>
the only thing that can't be done (without that input-observer protocol) is having two mice
<navi>
aka be able to see local and remote mice at once
<navi>
but otherwise, it seems perfectly doable to do that as a client, in a plug-and-play way under any compositor that isn't gnome
<navi>
wait kwin doesn't have virtual-keyboard either
<navi>
well to hope they implement ext-virtual-keyboard when the upstream version is merged
<whitequark[cis]>
it's described as kde-internal but i don't massively care
<navi>
which is supported on wlroots and friends
<navi>
so you can just support both easily
<navi>
by changing based on globals announced
<whitequark[cis]>
fwiw, if it's just for input, i could always do input via uinput
<whitequark[cis]>
actually hold on
<navi>
that'd require root (or input group), which is eh
<navi>
but works
<whitequark[cis]>
i can feed any events i want into the application i'm wrapping, right?
<navi>
yes
<ConanKudo[m]1>
yup
<whitequark[cis]>
so why'd i need fake-input?
<navi>
you just can't feed things into local/not-wrapped programs
<navi>
so if you want a remote user to type in a local program
<navi>
you need fake input
<whitequark[cis]>
oh! i'm thinking that if i'm going the proxy client route, what i could do is just launch everything under the proxy client. it would still not proxy anything by default (without user consent), but if you wanted to really be sure you opt out of it, you launch outside of the proxy
<whitequark[cis]>
this means it works under basically any compositor
<whitequark[cis]>
which is desirable
<navi>
that works too
<navi>
you'd be writing basically a rootless embedded compositor
<whitequark[cis]>
what the proxy would do is to add a little bit of ui chrome (somehow, not sure how) that lets you configure things like "allow/forbid remote input, allow/forbid remoting, mute/unmute remote audio"
<whitequark[cis]>
maybe just a keybinding that replaces the client's own surface with a settings panel, steam-style
<navi>
applications running under the proxy will basically see it as their compositor
<navi>
so the usual csd/ssd things apply
<whitequark[cis]>
yes
<navi>
so with "proxy ssd" you add the chrome
<whitequark[cis]>
ohh, i guess everything must support csd, so if i'm running under e.g. kwin, i could just tell kwin that i really want to draw the chrome myself, and then i do that
<whitequark[cis]>
ha, i dislike csd generally but this one time it works out in my favor
<whitequark[cis]>
i think being able to have properly synchronized audio would be huge, it would mean never having to fiddle with syncplay again (and all the workarounds you need to watch youtube in it)
<whitequark[cis]>
but that's not really a wayland problem
<navi>
i was thinking of something different
<navi>
you announce ssd to the client, add your chrome but not full decorations
<navi>
and then the compositor proper can also do ssd on top
<navi>
ofc this kind-of breaks if the wrapped client doesn't support ssd
<whitequark[cis]>
can you do this without increasing the effective client area?
<whitequark[cis]>
i.e. is it possible to "draw over" or "draw under" ssd
<navi>
nop
<whitequark[cis]>
if you have to shrink the surface to account for the size of the proxy chrome i expect it to break in some cases, mainly fullscreen applications
<whitequark[cis]>
although how fullscreen would even work in this use case is fuzzy anyway: full which screen
<navi>
you as the proxy compositor can tell whatever size you want to the inner client
<whitequark[cis]>
leaving wayland model aside, imagine collaborating with someone on 16:10 when your monitor is 16:9 (an actual problem i've encountered before)
<whitequark[cis]>
yes, i understand
<navi>
so like, get the side from the proper compositor, minus your chrome
<navi>
could even make a keybind to toggle chrome visibility
<whitequark[cis]>
what i'm trying to understand is how seamless i can make it when its chrome is not actively needed
<navi>
you can make the chrome go away when not needed
<navi>
stop drawing it, send new geometry to client
<whitequark[cis]>
yeah, that's kind of where i started with it
<whitequark[cis]>
ah i see what you mean
<whitequark[cis]>
also works
<f_>
ConanKudo[m]1 axtlos Do you want an actual news feed thing on the website or something
<f_>
to.. announce releases and such
* navi
would appreciate rss
<whitequark[cis]>
clipboard sync is interesting because you generally don't want to sync the clipboard at all times
<f_>
with rss too
<navi>
i'll package it for gentoo asw
<ConanKudo[m]1>
f_: most fdo projects have it, so probably yes
<f_>
ack
<axtlos>
f_: Yes
<axtlos>
also rss, like navi said
<navi>
whitequark[cis]: clipboard in wayland is request-based
<f_>
is hugo fine for y'all? :^)
<navi>
so you could dely sending it until something wants to paste
<ConanKudo[m]1>
f_: I'm not a fan of go based stuff, but if you're maintaining it, sure
<axtlos>
f_: your choice, hugo is the one ive heard of the most but idk if its good
<f_>
yeah I'd be fine maintaining the website
<ConanKudo[m]1>
I generally prefer things like nikola, but Idc enuf
<f_>
well it's either hugo or one of the crappy ssg's I wrote and don't use anymore :^) because I don't know the rest
<f_>
ack
<whitequark[cis]>
am i blind or is clipboard not on wayland.app
<f_>
whitequark[cis]: wdym?
<navi>
whitequark[cis]: it's on wayland core
<navi>
one moment
<ConanKudo[m]1>
Catherine: ext-data-control and primary-selection
<navi>
whitequark[cis]: i mean it's used for more than just copy paste
<navi>
but also drag-n-drop
<f_>
ConanKudo[m]1: yeah I'm setting it all up
<ConanKudo[m]1>
f_: looks like hugo is packaged in fedora too, so as long as it's compatible with that, I'm fine with it
<f_>
The entire landing page is mostly hand-written html anyway
<axtlos>
huh why does fedora compatibility matter in this case?
<f_>
I'd only use hugo for its blog/articles/newsfeed/etc stuff, and I don't use hugo themes
<ConanKudo[m]1>
axtlos: because most hugo sites use rando binaries which are not buildable after the fact
__0x1eaf has joined #wayback
<axtlos>
oh
<f_>
ah
<axtlos>
that makes sense
<f_>
....yyyyeah no
<whitequark[cis]>
navi: right, so i could do something like "the moment a proxied application wants something to be pasted, i look up who last sent it input and paste from that clipboard"
<ConanKudo[m]1>
so as long as I can build and run the site locally from the fedora package, I can at least hack/update the site
<f_>
yeah no lol I don't want that
<whitequark[cis]>
presuming that a paste request is always in response to ctrl+v or menu selection or something
<f_>
Else it's a whole mess trying to figure out which hugo binary works
<f_>
keep it simple
<navi>
if you want to limit the pasting for wrapped clients, you just keep track of who was the last to do a data offer
<navi>
or rather, create a data source
<navi>
and call ->offer
<navi>
that propagates data_offer events to other clients that have a data manager object
<whitequark[cis]>
i think that has the same issue. like, let's say a proxied app creates a data source. whose data source it now is? does it go to local clipboard or remote clipboard?
<whitequark[cis]>
if i ctrl+c in a proxied window i want a new entry to appear in my desktop's clipboard manager and all
<whitequark[cis]>
and if my counterparty does a ctrl+c, in any sort of window, proxied or not, this shouldn't suddenly mess up what's stored in my clipboard
<navi>
it'd need to go to both
<navi>
clipboard management is a priviledged protocol, and can even be private to the compositor
<whitequark[cis]>
sure, but "copy" clearly isn't
<whitequark[cis]>
and since i'm proxying the app, i could tell the local compositor that i've copied something only when the input that caused this to happen originated locally
<navi>
oh, yea
<navi>
yep
<whitequark[cis]>
this also naturally makes copy/paste work across local-only vs possibly-remote windows
<navi>
when a local client does a data offer, you proxy it to the local compositor, and to the remote proxy
<navi>
tho
<navi>
problem, remote paste is an issue
<navi>
i think
<whitequark[cis]>
i think you have to send a data offer to exactly one of local compositor or remote compositor
<whitequark[cis]>
this isn't related to wayland but is just a consequence of the user expectations around the clipboard
<navi>
yea
<whitequark[cis]>
i guess in the model i want to build, a clipboard is a part of the seat (split), not of the session (partially shared)
<navi>
problem is if you want to paste on a remote client
<navi>
say you copy something locally, and want to paste there, so the proxy proxies the offer
<navi>
but before you paste, the other person triggers a data-offer on their end
<whitequark[cis]>
i think you would basically have to "refresh" the offer following a change in whose input comes to the application
<navi>
oh
<navi>
nvm
<navi>
the data device is per-seat
<navi>
you can just have two wl_seat
<navi>
then programs need to handle which seat is pasting
<navi>
non-issue
<whitequark[cis]>
nice
<whitequark[cis]>
it's things like this which make me like wayland
<navi>
basically pointer, keyboard, touch, data device, and other extensions
<navi>
are per-seat
<navi>
though i don't know how well programs handle multi-seat currently
<navi>
because i don't know of many compositors that do support multi-seat
<whitequark[cis]>
i'm willing to tolerate needing to submit patches for that, at least at first (if it proves difficult in the end)
<navi>
but yeah since keyboard is per-seat, the application would go "seat X send the paste keybind, look up the lastest data-offer made from seat X's data device"
<navi>
this is so neat, solved at the protocol level
<whitequark[cis]>
it would be exceptionally cool to have multiplayer games that take advantage of this
<ConanKudo[m]1>
the copr now tracks the rawhide package
<ConanKudo[m]1>
once we have an actual release, I can ship it to stable releases
<ConanKudo[m]1>
for now, it sits in rawhide
<navi>
whitequark[cis]: i now really want to build that, though it'd need to wait until we have wl_gamepad
<navi>
currently gamepads are not handled via wayland, but games open /dev/input nodes
<whitequark[cis]>
navi: i'd be open to collaboration
<navi>
i don't think it'd work on wine
<navi>
but it surely can work with sdl games
<navi>
native games so
<whitequark[cis]>
there is just so much stuff in wayland that i don't have the faintest idea of how it actually works
<whitequark[cis]>
what the hell is a fifo manager
<navi>
the moment wl_gamepad is merged i'll work on that for sdl and friends
<whitequark[cis]>
more generally i don't really understand how DRM works in the context of wayland
<navi>
then write a simple p2p client for remote seats
<whitequark[cis]>
navi: by "that" do you mean wl_seat support?
<navi>
yeah, remote seats for coop in games
<whitequark[cis]>
nice
<navi>
i have no idea of what a fifo manager is either tbh
<navi>
seems to be a thing for mesa to use
<navi>
fifo and barriers look like the vulkan concepts of the same name
<whitequark[cis]>
basically the part that scares me is doing all the GL-adjacent bits and the video-adjacent bits, because those are two topics i've basically not done before (i mean i wrote GL apps, i've never worked with Mesa or DMA-BUF or...)
<whitequark[cis]>
is there a wayland wireshark?
<navi>
yesn't? WAYLAND_DEBUG can be used to log all protocol messages back and forth
<navi>
but not really to look at buffer contents
<whitequark[cis]>
oh ok that's enough
<whitequark[cis]>
how would i go around building such a proxy? does basically any wayland library offer serialization and deserialization functionality sufficient to build both server-side and client-side halves? how does a wayland application even decide what to connect to, actually?
<navi>
yes, libwayland
<navi>
rather, libwayland-server and libwayland-client
<navi>
for connecting, there's 3 ways (well 4) ways
<navi>
WAYLAND_DISPLAY with a relative path, that path is then looked up inside $XDG_RUNTIME_DIR for a socket
<navi>
WAYLAND_DISPLAY with a absolute path, libwayland connects to a socket in there
<navi>
WAYLAND_SOCKET with a file descriptor, libwayland uses that number as an open file descriptor, and expects it to already be connected to the server
<navi>
special clients (e.g. us with Xwayback) can also get the socked fd some other way and create clients directly
<whitequark[cis]>
oh okay, easy
<navi>
and lastly, if neither WAYLAND_ variable is set, and the application didn't pass a specific name, `wayland-0` is assumed
<navi>
a lot of compositors now a days avoid opening wayland-0 as their socket because of that, random apps outside the session accidentally connecting
<whitequark[cis]>
so i guess a good way to start would be to write a proxy that intercepts the bare minimum set of protocols and forwards them to the local compositor
<navi>
sgtm
<whitequark[cis]>
by design it would know the buffer for each wl_surface, which could then be grabbed and compressed
<whitequark[cis]>
huh, wl_shm lets you avoid GL at all?
<navi>
wl_shm is for cpu rendering
<whitequark[cis]>
yeah
<navi>
and yes, though there's clients that might not support it
<navi>
(i doubt any simple desktop program doesn't tho)
<navi>
mostly games will require drm-lease or similar for hw accell
<navi>
or stuff like allacrity because yes a gpu-accelerated terminal is needed
<navi>
(damage tracking is so awesome that foot can be just as fast with only cpu rendering)
* navi
pats foot
<whitequark[cis]>
yeah, it would just accelerate early development because no need to deal with dmabuf
<f_>
ConanKudo[m]1 / axtlos: should some of the stuff in the README be moved over to the website you think
<ConanKudo[m]1>
probably? esp once we have initial releases
<f_>
ack
<axtlos>
i dont see anything we have right now that should be moved
<ConanKudo[m]1>
at the moment there isn't anything because we don't have supported releases
<f_>
Well things like CoC and maybe distro stuff
<ConanKudo[m]1>
once we do, then it should be on the website
<axtlos>
yes, releases would be on the website
<ConanKudo[m]1>
the Code of Conduct should be on both
<f_>
but probably should be on some docs thing.
<f_>
Okay
<axtlos>
i mean id keep the readme like that for a while now, nothing that should be added or removed
<f_>
Alright
<f_>
also, we don't really have docs at the moment, do we?
<f_>
(apart from the small scdoc manpages)
<axtlos>
only the manpages
<f_>
yeah
<axtlos>
i was going to propose enabling github wiki when we were still on github
<f_>
any thoughts? I haven't yet implemented the docs stuff
<ConanKudo[m]1>
lgtm
<f_>
also cc Ariadne ^^
<f_>
and btw the "X" button hides/shows the window
<f_>
so it's not completely useless :p
<whitequark[cis]>
this looks cool
<f_>
ty!
<Ariadne>
i will check in a little while, running errands atm
<f_>
okay, no rush
<f_>
I still need to implement the docs part :rofl: (haven't yet setup emoji picker on this new install)
<dramforever[m]1>
i suppose it's hardly news by now but i just got wayback working on asahi-linux nixos
<f_>
nice still
<dramforever[m]1>
there are some minor things that don't seem to work like multi monitor being the major one? and keyboard and touchpad config not working (but it's kde's config anyway so maybe it shouldn't work)
<axtlos>
yes multimonitor is a known thing
<f_>
multimonitor is known
<axtlos>
what do you mean with keyboard and touchpad config
<f_>
keyboard/touchpad not working is not
<dramforever[m]1>
it's working
<f_>
ah
<dramforever[m]1>
but like i set ctrl position to "caps lock as additional control" in kde and whatever kde did doesn't get passed through
<dramforever[m]1>
i forgot what the technical term for those xkb map or whatever settings are
<axtlos>
interesting
<axtlos>
setxkbmap does work for me
<dramforever[m]1>
so it's just kde settings not really liking it
<dramforever[m]1>
this should be right? setxkbmap -option caps:ctrl_modifier
<axtlos>
probably
<dramforever[m]1>
caps is still caps
<axtlos>
wait let me see if caps is backspace for me
<dramforever[m]1>
it's like when you're in a virtual machine and everything is by red hat
<axtlos>
do you mind creating an issue for this?
<axtlos>
like general input management
<dramforever[m]1>
which
<axtlos>
just generally that input isnt properly handled
<dramforever[m]1>
okay "Handle input better"
<axtlos>
yeah taht works :p
<dramforever[m]1>
oh re: touchpad, it is the current situation that you can't easily set libinput flags like scroll direction and tap to click, and not that i'm doing it wrong right?
<dramforever[m]1>
is there any hack i can do to put wayback on the display that's not this one
<dramforever[m]1>
unless the docs are lying wayback seems to have, like, zero configuration
<f_>
apart from .xinitrc it has zero config
<f_>
actually you gave me an idea
<dramforever[m]1>
yeah it would be great if i can put this on the external monitor
<axtlos>
dramaforever[m]1: You'd have to modify the code
<dramforever[m]1>
that's fine by me
<dramforever[m]1>
just hack in an environment variable to select display by index or something? not now but i can try
<axtlos>
it currently just takes the first output it detects, in xwayback.c:197 you can additionally check the name of the output and then set it to first_output if its the right one
<axtlos>
yes i was planning on adding an envvar to select a monitor based on the name
<axtlos>
but havent gotten to it yet
<thomas_adam>
Oooh, I wouldn't suggest you do so based on the name...
<axtlos>
i mean name as in monitor label or whatever its called
<axtlos>
not identifier like eDP-1
<whitequark[cis]>
how do i even get the thing that's not "eDP-1"
<f_>
LVDS-1
<axtlos>
assuming you have another compositor running you'll be able to get the recognized outputs
<axtlos>
in sway for example with swaymsg -t get_outputs
<axtlos>
itll show the human readable name for the output
<f_>
e.g.
<f_>
Output VGA-1 'Hewlett Packard HP v220 CNT7506018' (focused) Current mode: 1680x1050 @ 59.954 Hz Power: on
<whitequark[cis]>
i do not
<whitequark[cis]>
also that's a mouthful
<axtlos>
its a mouthful but its the most reliable way
<f_>
I think that can be done with x11 alone?
<axtlos>
yeah probably too
<f_>
I mean it's certainly not something wayland-only
<f_>
like you can do it easily by going into some display settings gui and there you go
<whitequark[cis]>
do you expect to make a release without working multi-monitor support?
<whitequark[cis]>
(otherwise you presumably wouldn't need this feature to be good)
<axtlos>
yeah i would
<axtlos>
idk if the others agree
<dramforever[m]1>
would it be a problem if you have two identical monitors
<dramforever[m]1>
i remember getting kde extremely confused by that once because my usb c dock has edid "stuck" in it
<axtlos>
dramaforever[m]1: I don't know honestly
<dramforever[m]1>
> if i plug the monitor (hdmi cable) into my dock, unplug the monitor from the dock (without unplugging the dock from my laptop), then plug in the monitor into my laptop's own hdmi port, then i can't log in on sddm
<dramforever[m]1>
that's what i found last time
<dramforever[m]1>
i... i don't know if that dock is still working
<dramforever[m]1>
like it might have just died
<f_>
20:57 <axtlos> yeah i would
<f_>
I would too
<dramforever[m]1>
but it is possible to get into a situation where at least your computer thinks you have two identical monitors plugged in
<axtlos>
I mean really this is just a temporary solution mainly meant for testing wayback, so I dont think we should get hung up on edgecases like this
<whitequark[cis]>
it'd be rather easier to use "VGA-1" than "Hewlett Packard HP v220 CNT7506018" for testing >.>
<axtlos>
those arent predictable
<whitequark[cis]>
i'm aware
<dramforever[m]1>
can you just have 0 and 1 also work
<dramforever[m]1>
for testing purposes
<whitequark[cis]>
eth0 isn't predictable either, but you know what it is? not a pain in the ass to actually type
<axtlos>
what do you mean
<dramforever[m]1>
like you want to have "WAYBACK_OUTPUT=Hewlett Packard HP v220 CNT7506018" wayback-session right
<axtlos>
yeah
<dramforever[m]1>
and i'm saying for testing purposes can we also allow WAYBACK_OUTPUT=1 wayback-session
<axtlos>
thats even less predictable than something like VGA-1
<whitequark[cis]>
i dont care i just dont want to type "Hewlett Packard HP v220 CNT7506018" every time i want to pin it to a specific monitor
<whitequark[cis]>
something breaks because the numbering changes? who cares, it's testing
<dramforever[m]1>
but is it 1) actually likely to change every time you run w-s? and 2) would enable testing in cases where you have identical monitors
<dramforever[m]1>
like for my thing i would concede that it's probably not if it actually is random every time you run wayback-session
<axtlos>
itll accept the full name and the adaptar name
<axtlos>
not just an arbitrary index
<dramforever[m]1>
if it changes for every reboot it is good enough for testing
<whitequark[cis]>
if it accepts "eDP-1" it's good enough
<dramforever[m]1>
i also think that's good enough
<f_>
I agree that accepting e.g. "eDP-1" might lead to that id changing everytime
<dramforever[m]1>
i just think 1 would give users less of an expectation that it's stable, if stability is your concern
<f_>
but given that it would be a stop-gap measure and ideally multimonitor support should be implemented it's not a big deal
<whitequark[cis]>
the ID only really changes if you swap GPUs or GPU drivers i think
<axtlos>
nope, it can change between reboots
<dramforever[m]1>
it could depend on load order on boot
<whitequark[cis]>
ah
<thomas_adam>
It's not just that, it could depend on monitors disconnecting/reconnecting.
<dramforever[m]1>
oh, yes, of course
<axtlos>
yes that too
<f_>
axtlos: depends on the setup I suppose
<f_>
for me DP-2 has always been DP-2 and VGA-1 has always been VGA-1
norwoodites is now known as pinskia
<f_>
but I have like one DP port and one VGA port
<f_>
this is a (thick) laptop
<dramforever[m]1>
on the same graphics card?
<axtlos>
for me the displays can randomly change between seemingly random DP numbers
<thomas_adam>
That ordering is not guaranteed.
<f_>
dramforever[m]1: yes, HP thought it would be a great idea to disable the integrated GPU
<f_>
so everything goes through my nvidia card
<axtlos>
thomas_adam: yes, that was my point why i didnt want to allow only specifing the identifier
<thomas_adam>
Especially, if you're using things like DisplayManager as well.
<ConanKudo[m]1>
I've reopened the issue to ask for the website setup
<f_>
Oh, I didn't mean to ask you to ask them for the website
Pixi has joined #wayback
<f_>
just wanted to know, but thanks anyway ^^
<thomas_adam>
Well, something I did in fvwm recently was to map monitors to positions, to give them reference numbers: 0, 1, 2, 3, etc., which would be true regardless of name. You could do something similar, abstracting away the other stuff...
<f_>
Okay I think I'm done with the website, let me send screenshots
<dramforever[m]1>
so full screenshot idea: a laptop border, with a rootful xwayland inside, running some x-only desktop environment, with the settings page showing display settings and the display is xwayland0
<dramforever[m]1>
just really cementing in the idea that this is xwayland rootful running on your computer as the whole thing
<f_>
ConanKudo[m]1: I think I setup CI but I can't actually test it at the moment because CI is restricted
<ConanKudo[m]1>
when you send the MR I can check it
<Ariadne>
looks like MR 53 is blocked by lack of CI approval
<Ariadne>
is there anyone around who can help with that?
<axtlos>
you should be able to trigger it again
<Ariadne>
ah okay
<axtlos>
i think it checks if the user is part of the org
<f_>
yes
<f_>
Only you and ConanKudo[m]1 can use the CI
<f_>
everyone else will get that blockmessage
<Ariadne>
i would like to stop using BUFSIZ, because it's not a portable define
<f_>
(more generally, only people in the wayback gitlab group can use CI)
<Ariadne>
if someone wants to clean that up, it's an easy MR
<axtlos>
oh i thought it is portable, thats like the only reason i used that lol
<f_>
I think I had enough Wayback for today :)
<f_>
Maybe tomorrow if no one gets to it by the time it is morning again for me.
* Ariadne
also, for constant strings, they should be `const char *` rather than `const char[BUFSIZ]`. the compiler will place the string in `.bss` and instantiate a pointer to the string in `.bss`.
<Ariadne>
erf, no /me intended there
<f_>
irccloud moment
<axtlos>
right that makes sense
<f_>
or phone keyboard
<axtlos>
i'll go over the code and clean that up
<axtlos>
oh btw, would it be possible to add me to the wayback repo, so that we dont have to wait for someone to approve the CI everytime I open a MR
<Ariadne>
yeah i can do that
<f_>
for CI access "Guest" is enough
<Ariadne>
you're not going to use freedesktop CI to mine crypto right? :p
<axtlos>
now after you mention it.. no guarantees /j
<f_>
honestly really like the windowmaker-esque window I put too
<f_>
it's in both the frontpage and will be in any news posts that will be there
<Ariadne>
axtlos: added to CI group btw
<axtlos>
thanks
croissant` has quit [Quit: Leaving]
<f_>
Oh yeah I think I'll submit some more MRs so it'd be nice to have access to ci too
jvvv has quit [Quit: WeeChat 4.6.3]
jvvv has joined #wayback
Oroanyall[m] has joined #wayback
<Oroanyall[m]>
Ariadne: question: would you be interested in hosting a wayland-on-x11 server within the wayback org?
<Oroanyall[m]>
I've been attempting to get Wayland working (at least in a partial state) on top of SDL3 and it seems like something wayback could make use of.
Oroanyall[m] is now known as orowith2os[m]
<orowith2os[m]>
I'd like to eventually get it on top of Quartz as well, but that's Later (and I don't have a macOS system right now)
<orowith2os[m]>
I'm doing it in C++ 23, and having lots of use-after-frees and other fun stuff, but I know where to go, vaguely :)
<ConanKudo[m]1>
<orowith2os[m]> "I'd like to eventually get it on..." <- this was already done