groknull has quit [Remote host closed the connection]
groknull has joined #river
groknull has quit [Remote host closed the connection]
vipulogmx has joined #river
snakedye_real_ has joined #river
snakedye_real has quit [Read error: Connection reset by peer]
snakedye_real_ is now known as snakedye_real
vaivis has joined #river
vaivis has quit [Read error: Connection reset by peer]
lxsameer has quit [Ping timeout: 272 seconds]
mon_aaraj has quit [Ping timeout: 272 seconds]
lxsameer has joined #river
mon_aaraj has joined #river
snakedye_real has quit [Ping timeout: 268 seconds]
mon_aaraj has quit [Ping timeout: 248 seconds]
mon_aaraj has joined #river
lxsameer has quit [Ping timeout: 248 seconds]
groknull has joined #river
groknull has quit [Remote host closed the connection]
tleydxdy[m] has joined #river
groknull has joined #river
groknull has quit [Remote host closed the connection]
<tleydxdy[m]>
Hi everyone, what would be the preferred method to adding functionalities to river? should I send it as a pull request or would it be more appropriate as patches just like dwm
<tleydxdy[m]>
e.g. I saw that someone had the monocle layout as an separate fork, but it seems like that would be way to hard for people to "gather" the features they like in their own build
<leon-p>
tleydxdy[m]: river does not keep a patch collection like dwm. We either officially support a feature or we don't at all. You are of course free to keep your own private patches. However, as far as layouts are concerned, you don't need to patch river, you can just write your own layout generator.
<tleydxdy[m]>
yeah, I wanted to add the "sticky" function
<tleydxdy[m]>
I already coded it, just wonder how I should push it
<leon-p>
"sticky" as in a window is always active, regardless of which tags are active? That is already supported. Simply add the window to all tags.
<tleydxdy[m]>
then I can't unstick it
<leon-p>
of course you can, assign it just the tag you want to move it to
<tleydxdy[m]>
yeah, that would mean I need to think about where I need to put it
<tleydxdy[m]>
rather than just "go away"
<tleydxdy[m]>
and it would went back to where it was
<tleydxdy[m]>
yeah I thought maybe this wouldn't be something river wants to include
<leon-p>
Well, TBH I don't think a patch adding an explicit sticky feature is likely to be accepted. It adds an additional condition that works weirdly with tags, makes everything awkward and is redundant.
<tleydxdy[m]>
sure, but I find it useful myself
<tleydxdy[m]>
yeah, ig I'll just go and have it in a patch myself then
<NickH>
How is it different to just making a view visible on all tags?
<tleydxdy[m]>
the difference is unsticking it
<tleydxdy[m]>
one I have to think about which number I need to press to not ruin my tags
<tleydxdy[m]>
the other I just press super s and it will go to the right place
<NickH>
Just make a key binding that removes the view from all but one tag.
<tleydxdy[m]>
NickH: which tag tho
<tleydxdy[m]>
the use-case for me is kinda like this, say I was in a conference call, so I want to keep that window visible when I'm doing other things
<tleydxdy[m]>
but after then call is done I want the window to go back to the tag with all my office stuff (email, etc)
<tleydxdy[m]>
which would be the tag before the window becomes sticky
<tleydxdy[m]>
aka go back to where it was
<NickH>
Hmm...
<leon-p>
I mean, it's not an invalid use case, I just don't like how its implemented. River already supports a way to have a view visibale on multiple / all tags and I don't think it's a good idea to add a second one. Having only one obvious way to do things is generally the better idea.
<tleydxdy[m]>
yeah, which is why I kinda like the way dwm have patches, since the features I use are very different from the next guy and so on
<tleydxdy[m]>
and even incompatible features can coexist
<tleydxdy[m]>
since people that want one probably doesn't want the other anyway
<NickH>
You could probably cludge it have the binding that makes it "sticky" also write the current tag to number to a tmp file. Then the binding that makes it unsticky read it back from the tmp file.
<leon-p>
having a wiki with patches is probably the worst way to distribute software I have ever encountered, TBH. Pretty much everything about it is annoying in some form. Also it effectively prevents distributions packaging your software.
<tleydxdy[m]>
oh, yeah I agree
<ifreund>
Nothing stops you from maintaining your patch for that, this is the beauty of open source
<ifreund>
we're not trying to promote patch sharing as the primary method of using river though
<tleydxdy[m]>
personally I would perfer them having it as different branches in the git repo
<tleydxdy[m]>
so I can just use git to merge from different branches
<ifreund>
I would like river to be flexible enough to support your use-case without patching the compositor process eventually though
<tleydxdy[m]>
that's how I maintain my own dwm build anyway
<leon-p>
that would increase the maintenance burden substantially
<tleydxdy[m]>
ideally people that use the feature would own the branch
<tleydxdy[m]>
and if no developer uses the branch it would just go stale
<leon-p>
(if you haven't already noticed, I think the cathedral is a considerably better model for FOSS than the bazaar :)
<tleydxdy[m]>
haha
<tleydxdy[m]>
yeah, np
<tleydxdy[m]>
the code is super clean tho, huge props
<leon-p>
again, I do think it's a valid use case. Would just be nice to solve it inside the framework of tags
<tleydxdy[m]>
I suppose I can have a special tag that's the sticky tag
<tleydxdy[m]>
and it would always be selected
<tleydxdy[m]>
oh, speaking of. I have one problem with the sticky solution I got that I'm not happy with
<tleydxdy[m]>
and I'm not smart enough to come up with a solution
groknull has joined #river
groknull has quit [Remote host closed the connection]
<tleydxdy[m]>
basically since the sticky windows are less important, I don't want them to be the first window on the stack (by default)
<tleydxdy[m]>
I should still be able to zoom it if need be of course
<leon-p>
I don't know how you implemented your sticky feature; But there is only a single stack per output which all windows on that output are part of. So if you don't want a sticky window to be the first in the stack regardless of whatever other windows are active, you'll have to just move it to the bottom of the stack. Easiest would probably be to detach and then append it.
<tleydxdy[m]>
I basically copied floating/fullscreen
<tleydxdy[m]>
yeah, I still want to keep the layout for the tags the window is selected
<tleydxdy[m]>
it would go to the bottom only when it was displayed just because it was sticky, if that makes sense
<leon-p>
possible, but probably super hacky. You'd have to skip the window in all stack iterations and then special-case it afterwards..
<tleydxdy[m]>
yeah
<tleydxdy[m]>
basically I can't find a good solution
<tleydxdy[m]>
tho I did notice that the "filter" functions are duplicated all over the place
<tleydxdy[m]>
also many functions loops over the list many times
<tleydxdy[m]>
s/list/stack/
<tleydxdy[m]>
I wonder if that can be improved a bit
<tleydxdy[m]>
oh, is having different layout per tag a thing?
<leon-p>
it can be, if the layout generator implements it. rivertile does not, but mine does
<tleydxdy[m]>
ah, right
<tleydxdy[m]>
I mean different layout generator per tag
<leon-p>
You can switch layout generators manually at runtime. But river provides no feature to automate it. You could hack it by listening for the active tags and then sending the necessary commands.
<tleydxdy[m]>
the main difference being that if I need to keep hacking rivertile to have more layouts or just write different layout generators and use them all
<tleydxdy[m]>
yeah, so probably best to have it handled in the generator then
<leon-p>
I think it's overall better to have a single layout generator with many different layouts
<tleydxdy[m]>
ic
snakedye has joined #river
<tleydxdy[m]>
hmm, weird
<tleydxdy[m]>
sticky_tag=$((1 << 31))
<tleydxdy[m]>
riverctl map normal Super S toggle-view-tags $sticky_tag
<tleydxdy[m]>
riverctl map normal Super $i set-focused-tags $(($sticky_tag + $tags))
<tleydxdy[m]>
I did this
<tleydxdy[m]>
basically treating the highest tag as the sticky one
<tleydxdy[m]>
but for some reason all the new windows I open automatically becomes sticky
<tleydxdy[m]>
is the msb of the tag automatically selected?
<tleydxdy[m]>
* automatically selected when a view is created?
<leon-p>
tleydxdy[m]: check out the github wiki. It has a page on tags, where you'll find a section called "scratchpad", which is effectively what you are doing here.
<tleydxdy[m]>
oh, it was scratch pad
<tleydxdy[m]>
ha, I never used scratch pad
<tleydxdy[m]>
wait no
<tleydxdy[m]>
what I mean is when I spawn a new window, it would behave like it already have the tag set
<leon-p>
a window gets all active tags when it spawns
<tleydxdy[m]>
ah
<tleydxdy[m]>
I see
<tleydxdy[m]>
thx
<leon-p>
but you can control this with the spawn-tagmask
<leon-p>
which is why I mentioned the wiki section on scratchads, as that is explained there :)