<ifreund>
leon-p: I've pushed my refactoring/bug fixes to a branch on my repo, it currently runs without crashing but there are imperfect frames
<ifreund>
how do you want to do this merge? I can just continue to work on my copy of your branch an push to master when I've got the transactions fixed, or I can push my current work back to your branch if you want to hack on it some more
<ifreund>
I'm heading towards my bed now though, hopefully have more time to work on it tomorrow
<leon-p>
Do whatever works best four you
<ifreund>
alright cool
<leon-p>
although, if you push it back to the PR, I could see what you changed. Would be interesting to see, especially since I want to get my zig to be a bit more idiomatic
<ifreund>
Sure I'll push there then
<ifreund>
(warning, it's a force push because I rebased onto master independantly
<leon-p>
thanks
<ifreund>
the patch is a mix of minor bug fixes, cleanups, more idiomatic zig, and optimizations
<leon-p>
yeah, I see it makes the PR a few hundred lines slimmer :D
<ifreund>
alot of it is getting rid of .? access or the need for optional types altogether
<leon-p>
yeah i see i had the namespace optional. probably a relic from when that was a request.
<ifreund>
It did crash on me when I started a layout client while the output's namespace was null before this patch
<ifreund>
and so then I started fixing that and kept finding strings to pull
<leon-p>
interesting. Isn't null the default output namespace? It did not crash for me
<leon-p>
a separate listener for inert layouts is a pretty clever solution to get rid of the optional namespace
<leon-p>
we have a slight problem
<leon-p>
you force pushed a pretty old version
<leon-p>
and overwrote a ton of other things I did, like basically /all/ the river-options integration
<leon-p>
and since I just pulled your branch, I do not have that code anymore
<leon-p>
ok, damage-control. Things that are now missing:
<leon-p>
1) porting rivertile to river-options
<leon-p>
2) porting contrib/ to river-options (I have a copy out of tree, recoverable)
<leon-p>
3) remove "declare_dependency" from protocol and replace with "parameters_changed"
<leon-p>
4) have more default options per river output (and change default option creation function to not all call listener on initial set)
<leon-p>
and a few more things I can't remember right now
<leon-p>
shit
<ifreund>
leon-p: well shit, that was stupid of me
<ifreund>
i've got a4efdada6572ae82432a3a3b9a26460829fcd075 though
<leon-p>
would work if I had used git correctly. I haven't though.
<ifreund>
leon-p: I pushed a version with everything except your lastest rebase back to your branch
<ifreund>
sorry for the stress, I'm going to go sleep and rebase the refactoring I just did on top of the right commit in the morning
<leon-p>
oh hell, that was a minute of stress :D
<leon-p>
good night
<ifreund>
you probably have the latest commit locally as well
<leon-p>
nope,
<ifreund>
try git checkout 345b983
<leon-p>
tl:dr; I was always to lazy to learn git merging, so I usually delete the repo and clone it again
<ifreund>
lol
<ifreund>
ok yeah then you don't
<waleee-cl>
true "oh shit git" moment
<leon-p>
gonna put that high on my todo list now
<waleee-cl>
(sorry for the weak attempts at humor)
<ifreund>
your commit is still somewhere on github I'm sure, but I don't know how to get it
<ifreund>
it's only your latest rebase that is currently missing though I think, which is fine because I meant to overwrite that (but not the other stuff)
<leon-p>
trying to remember what I did the last two days, I think it only was the rebasing.
<ifreund>
the commit I saved was the one from just before your most recent force push
<ifreund>
before I fucked the branch
<leon-p>
Ah I see. That should only be the rebase
<ifreund>
so yeah, nothing really lost in the end, I love git
<ifreund>
(stop deleting your repos though, please)
<ifreund>
I'm happy to give a crash course in whatever git skills you are missing
<leon-p>
probably tons. I have a blog-posts saved somewhere which goes in-depth into git; That'll be my first read tomorrow.
waleee-cl has quit [Read error: Connection reset by peer]
waleee-cl has joined #river
_whitelogger has joined #river
waleee-cl has quit [Quit: Connection closed for inactivity]
yyp has quit [Read error: Connection reset by peer]
yyp has joined #river
<yyp>
Is there a way to reload river config without killing the compositor?
<leon-p>
"reload" is the wrong concept here. river's default config is a simple shell script and all options can be changed live.
<leon-p>
just run the script again
<leon-p>
just note that there are currently some objects which do not get overwritten/destroyed.
<yyp>
Okay, more correct question: how to reset all keybindings and configuration options?
<leon-p>
you can't.
<leon-p>
not yet anyway
<yyp>
Sad
<leon-p>
well, there is 'unmap', but it will require you to manually unmap all keybinds
<leon-p>
if you want something better, contributions are welcome :)
<yyp>
I know, but this will be very annoying as I need to add unbind to everything I define there
<yyp>
I'll probably just relogin
yyp has quit [Remote host closed the connection]
yyp has joined #river
<yyp>
Can I have multiple keyboard layouts on river or this is not possible?
<leon-p>
any advanced input configuration is not yet available.
<yyp>
That's fine, I mostly don't use other layouts
yyp has quit [Remote host closed the connection]
yyp has joined #river
<yyp>
I can rebind capslock to escape which is probably enough for my needs
yyp has quit [Remote host closed the connection]
yyp has joined #river
gspe has joined #river
yyp has quit [Remote host closed the connection]
st4ll1 has joined #river
<ifreund>
leon-p: so yeah whatever crash bug I hit before refactoring the old commit last night is gone on your lastest version
<ifreund>
still going to rebase the refactor over since it was a nice cleanup
yyp has joined #river
betawaffle has quit [Ping timeout: 240 seconds]
betawaffle has joined #river
ifreund1 has joined #river
ifreund has quit [Disconnected by services]
ifreund1 is now known as ifreund
betawaffle has quit [Read error: Connection reset by peer]
betawaffle has joined #river
skuzzymiglet has joined #river
<skuzzymiglet>
is there a wayland protocol for getting window names?
<yyp>
Probably not
<yyp>
River exports tags so it might export window title as well
<yyp>
I'll try to implement this, but it would be very hard as I've never worked with Wayland
<ifreund>
I'd recomment making a new waybar module for that, river/view-title or similar
<ifreund>
waybar's C++/gtk mess will probably be harder to pick up than the wayland part
<yyp>
At least I have sway/window as a reference
<ifreund>
and river/tags for the wayland part
<ifreund>
you can basically copy the river/tags wayland code and s/wl_output/wl_seat/
gspe has quit [Quit: gspe]
<yyp>
Okay, I'll try that once I come home
gspe has joined #river
skuzzymiglet has quit [Ping timeout: 272 seconds]
waleee-cl has joined #river
yyp has quit [Read error: Connection reset by peer]
yyp has joined #river
<leon-p>
ifreund: btw, have you already reviewed rivertile?
<ifreund>
no I haven't looked at it yet
<ifreund>
currently fixing some UB I caused in my refactor :D
<ifreund>
and getting sidetracked refactoring options
<ifreund>
I feel like when I come back to river after working on other things I always find way too many things I want to refactor
<ifreund>
I need to make server a global at some point, it would clean up code and be more optimal
<leon-p>
yeah, i found making the server/context global significantly cleans up basically all wayland code in any project :D
<leon-p>
goes a bit against the common "do not use global variables" mantra though, which is probably why few people do it
<ifreund>
"never use global variables" is BS
<ifreund>
just don't use them when they don't make sense
<leon-p>
that does not stop university instructors to still teach it as an unbreakable rule...
<ifreund>
they also tend to think java was a good idea
<leon-p>
true :D
<leon-p>
although I remember in my C crash course the professor spend half an hour in the introduction shouting at top volume why he thinks C is better than Java
<anthony25>
because it's true that global variables will catch you back if you don't know what you're doing
<anthony25>
but it's also true that they tend to teach that as a global rule
<anthony25>
like "never use goto"
<leon-p>
gotos probably depends on the language. I can understand not liking them in Java, but in C it is basically impossible to have clean error handling without goto
<anthony25>
exactly
<anthony25>
well I mean in a language where you don't have to deal with explicit memory allocation, you don't really need a goto, but I've been told when learning C to "never use gotos"
<ifreund>
They also don't teach error handling in general
<ifreund>
which is a nice way to sweep the primary valid usage of goto in C under the rug
<ifreund>
like check out the slides of nearly any OS course and you will not see the return value of a single syscall checked
<leon-p>
they can probably get away with it by not having real-world usage example. Like in that C course, all we'd do is write programs getting user input with getc(), like who does that irl?
<ifreund>
lol
<anthony25>
ifreund: hey, compared to languages with exceptions, there's no problem if you don't check it :<
<anthony25>
reworded: there's no problem until you check it
<ifreund>
leon-p: just saw the default bindings for main_amount/main_factor... I think we need riverctl mod-option
<ifreund>
if you're looking for something to do... otherwise I will get to it after transactions
<leon-p>
I'll have a look in a minute
<leon-p>
I definitely need a break from working on LavaLauncher: That codebase is utterly rotten and despite my best efforts it is probably not recoverable :(
<ifreund>
:/
<ifreund>
rewrite in zig when? :P
<leon-p>
not unrealistic.
<leon-p>
Although I am bit hesitant since it is already packaged and has users...
<ifreund>
honestly though unless you want more features I don't recommend rewriting it
<ifreund>
I have a screenlocker written in rust that people seem to use that I want to rewrite in zig
<ifreund>
before I touch that project again I'm going to work on a screenlocker protocol of some kind
yyp has quit [Read error: Connection reset by peer]
<leon-p>
the plan is to support widgets in the future. that would require a proper hotspot system and since I initially though it was a smart idea to support multiple bars per LL instance each widget updater needs some list of bars which need to be updated and that is not clean. Basically everything I'd want to do with it is a rewrite of some parts of the code anyway and if I ever want to have some form of
<leon-p>
modularity, large parts need to go...
<ifreund>
hmm, what's the benefit to having multiple bars per LL instance?
<leon-p>
having multiple configurations per bar, so if some condition changes (like the aspect ratio of the output) the config could automatically adapt. My initial implementation of that was that users could simple use "copy-bar" in the config, which would copy the last bar and let users overwrite the settings
<leon-p>
I now have a better system, but the legacy of that mess remains
<leon-p>
If I attampt a proper clean-up, that will probably the first thing to go.
<ifreund>
yeah, sounds like you'd need that breaking change to make more forward progress
<leon-p>
luckily users are already used to breaking changes :D
<ifreund>
:)
<leon-p>
RE: riverctl mod-option. maybe it can be done with `-increase` and `-decrease`? Probably a bit more intuitive
<ifreund>
so riverctl mod-option -increase main_factor 0.1 ?
<ifreund>
there's also the question of how this works for strings
<ifreund>
probably it just doesn't
<leon-p>
simple: it prints a message explaingin trying to increase string is nonsensical
<ifreund>
I think I'd rather have mod-option than increase/decrease flags, I'm wary of unbounded flag growth and I think a separate command is clearer
<leon-p>
sure
yyp has joined #river
<yyp>
Re: screenlocker rewrite. If it will have ^U to clean, I'm looking forward to it. Aside: now we have "Rewrite in Rust", are we going to have "Rewrite in zig" soon? :)
<yyp>
*to clear password
yyp has quit [Quit: have a great day]
<ifreund>
rewrite it in zig only valid when rewriting Rust or C++ software :D
<ifreund>
good C software is fine
<ifreund>
really though, nevere rewrite working software in another language soley to use that language
waleee-cl has quit [Ping timeout: 256 seconds]
waleee-cl has joined #river
yyp has joined #river
<ifreund>
yyp: if you don't know, escape works to clear in waylock
<ifreund>
(also I said stuff about "rewrite it in zig" while you were offline, check the logs of you like)
<leon-p>
"rewrite it in zig" is actually a nice thing if you have tons of little specialized helper tools around originally written in C and shell.
<leon-p>
turns out you can massively simplify some of them thanks to an extensive std lib
<yyp>
I might try Zig at some point
<yyp>
It looks like an awesome language
gspe has quit [Quit: gspe]
gspe has joined #river
snakedye has joined #river
<ifreund>
yeah, and it's not even stable yet :)
yyp has quit [Quit: bye!]
<leon-p>
ifreund: have PR'd a commit for adding mod-option. Not sure if its idiomatic, but it appears to be working fine.
<leon-p>
int, uint and fixed and be modified, the first two taking an int modificator, the last one a double one. uint is clamped to [0, +inf)
yyp has joined #river
<ifreund>
sounds good, I'll give it a look in a minute
yyp has quit [Quit: bye!]
yyp has joined #river
yyp has quit [Client Quit]
yyp has joined #river
yyp has quit [Client Quit]
yyp has joined #river
yyp has quit [Client Quit]
yyp has joined #river
<yyp>
Looks like I found a river crash when swapping a window on a lone tag
<yyp>
I'll debug this a bit further and at least try to fix
yyp has quit [Quit: bye!]
yyp has joined #river
<ifreund>
yyp: cool, feel free to ask for advice here if you get stuck
yyp has quit [Quit: bye!]
<ifreund>
though I can't reproduce it...
yyp has joined #river
<yyp>
I can definetly reproduce the crash but there is nothing in the logs, weird
<ifreund>
yyp: running with gdb in a nested session should help