<ifreund>
leon-p: are you sure? I can't reproduce on the current master
<ifreund>
how exactly are you reproducing it?
<ifreund>
ah I think I see
<ifreund>
leon-p: fixed now :)
<ifreund>
I was too focused on handling move/resize modes properly when I wrote that commit that broke it again
<ifreund>
leon-p: as for how distributions build packages with submodules, I've usually just fetched the sources for the submodules as tarballs as well
<novakane>
ifreund: did you saw my implentation of river -version and the one by leon-p, do you have a preference?
<novakane>
I was thinking, does it really makes sense to have -verion for riverctl and rivertile too?
snakedye has joined #river
<ifreund>
novakane: I haven't taken a detailed look yet, if you think it's ready feel free to go ahead and open a PR
<ifreund>
and I think we definitely need -version for riverctl and rivertile as well, someone is going to end up with mismatched riverctl and river versions eventually
<novakane>
ifreund: ok no problem, do you want riverctl version command in a version.zig file?
<novakane>
I have some trouble to make it works for riverctl https://zigbin.io/36d46d -> 'err: Error: unknown command'
<ifreund>
novakane: I don't think it should be anywhere near enough code to justify a new file
<ifreund>
novakane: oh, this needs to be implemented in riverctl not river
<ifreund>
i.e. in riverctl/main.zig
<ifreund>
otherwise it's pretty useless as a version mismatch might mean riverctl can't communicate with river
<novakane>
oh ok
<novakane>
and since we talking about that, the help command should be implemented like that or in a help.zig?
<ifreund>
it should also be in riverctl.zig
<ifreund>
there's no reason to implement that in river
<novakane>
allright, well I'll implement riverctl -version and it should be good for a PR then
<ifreund>
cool, probably best to keep the -help thing in a separate PR
novakane has quit [Ping timeout: 265 seconds]
novakane has joined #river
waleee has joined #river
leon-p has joined #river
<leon-p>
huh, just discovered that my plans for river-toplevel won't really work: All our commands need to be able to have no target view, so that river knows to use the focused view
<leon-p>
probably the best approach is to have all the view commands in an upcoming version of river-control take a foreign toplevel handle that can optionally be null
<ifreund>
leon-p: couldn't we just use null to indicate that the focused view should be used?
<leon-p>
ifreund: It isn't really idiomatic to have requests of an interface allow that interface ptr to be null
<leon-p>
but I think it could work
<leon-p>
btw, finally submitted that issue about soft-locking river
<leon-p>
also if we want to keep river-control atomic as we have discuseed a few weeks ago, having those commands be part of a different protocol might make that more complicated
<ifreund>
leon-p: oh I meant requests in the river-control protocol, though it seems like you also reached that conclusion
<ifreund>
I think river-toplevel should only give information not allow control
<leon-p>
yes, that is my conclusion as well
<ifreund>
and should probably replace river-status
<leon-p>
AFAIK foriegn-toplevel already takes care of some of those information already, so this is a good solution I think
<ifreund>
yeah, though I would really like to get the split version of that protocol merged in wayland-protocols before merging river-toplevel tbh
waleee has quit [Ping timeout: 255 seconds]
<leon-p>
f.e. I don't think we really need to communicate which client is focused for a seat: foreign-toplevel handles already expose whether a client is focused and I don't think there are any plans to let river seats focus more than one view
<leon-p>
agreed on the split protocol
<leon-p>
btw, do you still need more implementations for that? I easiely could port lswt
<ifreund>
leon-p: um, it's been a while since I looked at it. I think I needed to make some changes based on the review to the management protocol but the info one was pretty much complete
<ifreund>
there are wlroots and river patches that probably need to be rebased
<ifreund>
I ported the wlroots foreign toplevel management example as a client iirc
<leon-p>
I could have sworn the policy was to have multiple clients, but I guess I was wrong.
<leon-p>
would be great to have that protocol standardized
<ifreund>
leon-p: I think for the ext namespace it's less strict
<leon-p>
well, I ported lswt anyway. can't hurt
<ifreund>
nice, feel free to drop a comment on the wayland-protocols MR with a link
<leon-p>
done
<leon-p>
I never miss a chance for shameless self-advertisement :P
<ifreund>
by the way, I just looked at that again and was considering whether we should get rid of the minimized state
<ifreund>
river doesn't have any such concept and I assume other compositors might not either
<ifreund>
oh, I guess xdg shell does though
<ifreund>
even if river doesn't use it
<leon-p>
Tiling compositors do not have that state and I personally also think it is nonesense, but stacking compositors may implement minimizing views and are commonly used with windows-esque task bars which need to know that state
<ifreund>
ah I see how I confused my self, minimized isn't part of the xdg_toplevel.state enum
<ifreund>
but there is a set_minimized request
<ifreund>
guess the xdg_shell client doesn't actually need to know if it is minimized
<ifreund>
I think the ext-toplevel-info protocol is fine as-is then
<leon-p>
as an example, if KDE wanted to port their window switcher in their panel to that protocol, they definitely need to know the minimized state
<ifreund>
I do need to update the naming scheme though
<leon-p>
and having one of the "big" desktops embrace such a protocol could be seriously great for the ecosystem
<ifreund>
for sure
<ifreund>
kde already supports layer shell doesn't it?
<leon-p>
kwin does, although not the newest version AFAIK
<leon-p>
they are generally one or two versions behind for the wlr protocols when I tested it
<leon-p>
not sure about kwinft
<ifreund>
to be fair river doesn't either, never got around to implementing the keyboard interactivity focus thing as I don't have a use-case
<ifreund>
looking at the layout thing you reported now by the way
<leon-p>
to be fair, I still think keyboard interaction is broken, as you can't just get the keyboard-modifiers without being focused. Control-clicking something is a valid use-case, but pretty damn annoying to do with the layer shell
<leon-p>
don't you need to prepare for an exam? I don't want to use up all your time today if you have more important things on your agenda :D
<ifreund>
uuuuh, yeah I should probably be doing that
<ifreund>
leon-p: fixed it, or at least I can no longer reproduce
<leon-p>
nice
<novakane>
well I think -version should be good now
<leon-p>
really love the direction and pace river is currently moving at. I am as excited about my current setup as I was back when I discovered tiling window management for the first time :D
<leon-p>
now I only need a better shell and everything is perfect
<novakane>
same, these last days with all the cleanup, it really looks good, and it's cool to saw a project you love growing like that :D
<novakane>
leon-p: you use bash right?
<leon-p>
novakane: yes, I am usually a bash user. I have tried fish and zsh, but they did not really impress me; all their features are not things I particularly care about.
<novakane>
well for me zsh it's mainly for the completion system, I could live without the others features
<novakane>
the problem is POSIX or not POSIX
<leon-p>
I am currently trying elvish, which has two things that intrigued me: a build-in file navigation mode when pressing control-n and a build-in fuzzy finding directory switcher when pressing control-l. THe interactive parts are the most important parts of a shell for me, so I find this really helpful. But something feels a little off about, not sure what yet.
<leon-p>
I don't care much about POSIX vs non-POSIX. I script in pure sh anyway, so as long as the language works well in a REPL I am fine with it.
<novakane>
yeah I would move away from a POSIX compliant interactive shell if I found a great one but I tried some of them but not too long
<novakane>
I found they often lack some basic features
<ifreund>
leon-p: What I want is an interactive shell that doesn't care at all about scripting and a separate scripting language for what I use shell scripts that doesn't care at all about interactive usage
<leon-p>
exactly
<ifreund>
I think trying to support both uses well with one language is fundamentally flawed, there are too many tradeoffs
<leon-p>
realistically all I want in an interactive shell language-wise is the typical `command | command` pipe syntax as well as a way to do a for-all on all files in the current directory
<leon-p>
that's neat!
<ifreund>
probably will start contributing to it at some point, I've already spent a good bit of time talking with marler about the design
<ifreund>
but yeah, I have a TODO list a mile long
<ifreund>
and I agree that I really don't need much from an interactive language
<leon-p>
does not even need to be turing complete
<leon-p>
some math stuff could also be nice, but just opening qalc isn't an issue either
<ifreund>
well, it probably will be unless you make an effor to avoid being so
<ifreund>
would definitely be a cool project, maybe I'll give it a try someday
<ifreund>
the scope of the language itself should be kept absolutely tiny IMO
<novakane>
stitch looks interesting, I'll keep an eye on it
<leon-p>
I would really like to see a shell with some file-manager functionality, the lines between those are pretty blurred already anyway
<ifreund>
the complexity budget should be invested in fuzzy completions and niceness
<novakane>
like 90% of my commands use fzf it would cool to have something like this in a shell
<leon-p>
novakane: see elvish for an example. it remembers all dired you cd to and when you press control-l gives you an fzf like selector to switch to the top 10 most visited dirs.
<ifreund>
leon-p: I've been using nnn as my only file manager for a while. have you tried it?
<leon-p>
ifreund: I tried, but I miss previews
<ifreund>
as in images?
<leon-p>
nope, text files
<ifreund>
ah
<novakane>
leon-p: I will try elvish, I think I already did but it was a long time ago
<leon-p>
just seeing ~10 lines from the top of the file is really helpful IMO
<novakane>
yeah nnn is great I use it since a long time, but I dont care much about preview
<novakane>
iirc there is some plugins for preview
<leon-p>
what I really need in a terminal file manager is that when you exit it, the shell cds to where you last where in the fm. elvish integrates a simple file manager for that purpose. Not sure if it is the right approach, but it works better than any external FM I have used so far for me
<novakane>
that's what nnn do
<novakane>
you can have a cd on quit function in it
<leon-p>
what I like about the elvish FM is that you are still in a shell, meaning you can type commands and use alt-enter to fill in selected file names
<leon-p>
novakane: I remember that not really working when I last tried it
<novakane>
leon-p: really? I use it all the time without any problem
<ifreund>
elvish looks neat, I should try it out sometime
<ifreund>
but yeah, nnn's cd thing works fine for me
<leon-p>
then I should try out nnn again
<novakane>
I even use nnn with kakoune and neovim when I can't fuzzy file because I'm not in the right folder
<leon-p>
interestingly in an editor I barely ever use a FM or fuzzy finding. I usually just have the exact path in my mind anyway
<ifreund>
same, but typing 3-5 characters is faster than typing the full path
<leon-p>
true
<ifreund>
I only use nnn when I don't know where something is/need to browse
<novakane>
I don't think I could live without fuzzy file in a editor now
<leon-p>
what I mostly use fzf for is as a dmenu replacement. I use it for opening files, books and browser bookmarks
<novakane>
fuzzy for openning file and for grep with preview is really something I use everytime
<leon-p>
"grep with preview" is something I have never thought about, but it makes sense
<novakane>
yep it's really great to see the code around when you search something
<novakane>
ah well I see I can close the `-help` PR and I was looking at the log level too but I see you're too efficient ifreund :D
<ifreund>
novakane: oh shoot, I should have communicated that I was working on those. Didn't have a web browser open for the past few hourrs
leon-p has quit [Ping timeout: 240 seconds]
<ifreund>
there's still some more to do on logging, I want to make the wlroots logging integration better
leon-p has joined #river
<novakane>
no problem, even if writing all description for riverctl wasn't great :p
<ifreund>
oh yeah, I just said to rtfm
<ifreund>
I don't like programs which have 1000s of lines of --help output
<novakane>
yeah how does it works currently, because there is the zig log and the wlroots log, it's kinda confusing
<novakane>
it's a good solution yeah
<ifreund>
what we need is to define our own wlroots log handler, but that requires using va_list which you can't do from zig without hacks currently
<ifreund>
so the idea is that we'll have a C function compiled into river that handles the va_list stuff and then calls into zig code to do the actual logging
<ifreund>
then we can have wlroots log messages formatted the same
<leon-p>
huh, that's the inverse of what I proposed a few months ago :P
<ifreund>
leon-p: If we were to do it the other way around, we wouldn't be able to do scope-based filtering
<ifreund>
which I intend to do for debug logs at some point
<novakane>
ah yeah scoped is really useful
<novakane>
to search in the 5000 lines of keysym :/
novakane has quit [Quit: WeeChat 3.2]
novakane has joined #river
<leon-p>
novakane: pretty sure the xkb keysm warnings come from XWayland
<novakane>
leon-p: yeah I wouldn't be surprised if that was XWayland that bother me
leon-p has quit [Quit: leaving]
snakedye has quit [Read error: Connection reset by peer]