<busy_beaver>
I took a look at the example config after having used my own for a while.
<busy_beaver>
I noticed it maps Super+Shift 0 to set all tags on a window/view.
<busy_beaver>
I thought 'oh great, basically a sticky window' and copied the line (and the all_tags one too)
<busy_beaver>
Such sticky windows don't even need to be floating.
<busy_beaver>
But unfortunatly when I change the focused tags, and change them back
<busy_beaver>
then river doesn't remember what was focused.
<busy_beaver>
Instead it always focuses the sticky window.
<busy_beaver>
If one exists.
<busy_beaver>
Did I mess up something in my init regarding focusing?
<busy_beaver>
Or is this a river bug?
<busy_beaver>
I do have stuff set up like cursor warping and focus following the cursor etc. so I'm not sure where the issue is
angry_vincent has joined #river
angry_vincent has joined #river
angry_vincent has quit [Changing host]
aryak has joined #river
Guest9629 has quit [Remote host closed the connection]
talismanick has joined #river
dbuckley has quit [Ping timeout: 248 seconds]
Ordoviz has joined #river
Ordoviz has quit [Quit: WeeChat 3.8]
leopoldek has quit [Ping timeout: 260 seconds]
busy_beaver has quit [Ping timeout: 260 seconds]
Szadek has joined #river
Ordoviz has joined #river
Ordoviz has quit [Ping timeout: 240 seconds]
tiosgz has joined #river
zdykstra has quit [Read error: Connection reset by peer]
Ordoviz has joined #river
tiosgz has quit [Quit: tiosgz]
Ordoviz has quit [Ping timeout: 248 seconds]
Nulo has quit [Read error: Connection reset by peer]
Nulo has joined #river
dbuckley has joined #river
zdykstra has joined #river
muirrum has quit [Ping timeout: 248 seconds]
busy_beaver has joined #river
<busy_beaver>
I tested a bit and I can't find a way to fix the behaviour I described earlier. Does anyone know if a workaround exists?
<busy_beaver>
Because unfortunatly, sticky windows are unusable like this.
tiosgz has joined #river
<tiosgz>
busy_beaver: it happens cos river always focuses whatever the last focused visible view is, which happens to always be the sticky one
<tiosgz>
a workaround could be (untested) to show all tags and focus all views but the sticky one each time this annoys you
<tiosgz>
(but that means basically every time you happen to focus the sticky view, even if accidentally)
<busy_beaver>
Well then it is easier to just not use a sticky window and go to the one tag it is on in the first place.
<tiosgz>
a way river could perhaps possibly maybe prevent this is to ignore views that have all tags, but i don't think that would be accepted (but i can be mistaken)
<tiosgz>
* ignore them when deciding what to focus
<busy_beaver>
I realized meanwhile it is not just sticky windows, but any window I toggle on multiple tags. At that point, why even have tags when they are only usable when using them strictly like basic workspaces? :/
angry_vincent has quit [Ping timeout: 250 seconds]
<leon-p>
busy_beaver: IMO having per-tag focus order is more akin to basic workspaces than the current behaviour. A global window list and global focus order are the canonical thing to do for tags
<busy_beaver>
tiosgz think I understand what you described about the "last focused view". River somehow treats windows being focused by the user and windows being focused by river the same. Even if I never focus the sticky window myself, river pretends I did because it did so itself. So it focuses it over and over without me wanting it to.
<busy_beaver>
*I thing
<busy_beaver>
k
<busy_beaver>
leon-p But why does river pretend I focused the window when I didn't when switching tags? That makes no sense.
<tiosgz>
how exactly would you then define when /you/ focus a view and when /river/ does?
<tiosgz>
switching tags means focusing whatever view is focused in the new tags
<busy_beaver>
I mean it does need to focus some window, I get that, but pick one I focused recently.
<tiosgz>
moving the cursor (with ffc on) means focusing the view
<tiosgz>
etc
<leon-p>
busy_beaver: it makes a lot of sense. there is a list of focused windows in chronological order. when tag focus changes, river goes through that list and focuses the the first window that is currently visible
<busy_beaver>
Yes but the action I did was switching tags. Not focusing a different window. That was done by river for me.
<tiosgz>
it's always done by river for you, heh. but anyway, can you make a list what actions mean that /you/ focus a view & what don't?
<tiosgz>
i don't think it can be done unambiguously, but i'd be interested what you can come up with
<leon-p>
busy_beaver: having a difference between explicitly focusing a window and implicitly focusing a window would in fact not work better. As an example, a window may be implicitly focused, the user uses it and then later after a few tag-switches, it does not get focused again, which will be pretty weird from a UX perspective
<tiosgz>
s/unambiguously/to always fit your expectations/
<busy_beaver>
That is easy. Focus-view next/previous from riverctl : that was me. The riverctl command to focus other tags talks about focusing tags, not views. It is indirectly, so it should not count.
<leon-p>
that will lead to unpredictalbe UX weirdness
<leon-p>
"do what I mean" is an insanely hard thing to design in programs, usually not possible
<leon-p>
what I think could maybe work is an option to try focusing tiled windows first before floating ones
<leon-p>
busy_beaver: an an example why your proposol would not work: you focus tag 1, focus-move next, that window is explicitly focused. you focus tag 2, don't switch focus, that window is implicitly focused. no you focus both tags 1 and 2. the window on tag 1 will steal focus because its the last explicitly focused windows, which is bad UX because you were just working in the other window
<leon-p>
you can add a bunch of rules for special cases of course, but then you just add behaviour a user has to learn and remember
<busy_beaver>
It would be more predictable than right now. Right now I could have 5 windows in a tag. 4 of those have received dozens of clicks and hounderds of keystrokes in the last 30 minutes. the 5th not a single one, but it gets focused just because it happens to be on multiple tags (which I cant even see right now). Conclusion: If I switch to a different
<busy_beaver>
tag, don't interact with the sticky window, but immediatly use other ones, then the sticky window should not be treated as if I used it like the others.
<leon-p>
TBH I think you are focusing on your specific use case and ignore the wider picture here
<busy_beaver>
'Immediatly' here meaning next thing, not a timer.
<tiosgz>
if you don't use the sticky view for hours, then i don't see why you couldn't use the suggested workaround tbh
<leon-p>
you are talking about how it would improve UX for having a window on multiple tags (which IMO is questionable), but it will absolutely worsen UX of focusing multiple tags at once
<leon-p>
chronological focus ordering is the most predictable across all use cases
<busy_beaver>
If having one window on multiple tags is questionable then why is it so prominently suggested?
<leon-p>
its not. the wiki isn't "official" documentation
<leon-p>
I personally think that the opposite, focusing multiple tags at once, is the more common use case
<busy_beaver>
@tiosgz It was an extreme example, actual usage is more mixed of course
<tleydxdy[m]>
I don't remember if my sticky tag thing still have this problem or not
<tleydxdy[m]>
after the focus stack update
<tleydxdy[m]>
I have one tag designated as sticky
<busy_beaver>
leon-p Are the manpages official? They too explain how to do this "questionable" thingpt
<tleydxdy[m]>
and all the keybinds will select them
<tiosgz>
btw regarding what's questionable, i believe it was "improve UX for ... on multiple tags", not just "having a window on multiple tags"
<tleydxdy[m]>
I used to have it on wiki but seems that page is gone
<busy_beaver>
I have a laptop screen, focusing multiple tags doesn't make sense for me personally since that would be too squished
<leon-p>
busy_beaver: yes, they are. they explain it because it is a possible thing to do. however they certainly do not say anything about trying to mimick "sticky" windows with that feature
<busy_beaver>
You didn't say sticky windows where questionable, but having a window on multiple tags ...
<leon-p>
nope, never did
<busy_beaver>
"having a window on multiple tags (which IMO is questionable)"
<leon-p>
that was about your proposed changes, not about windows with multiple tags
<leon-p>
there are multiple use cases for having a window on multiple tags. emulating sticky windows is just one of them. while your proposed changes might improve UX for the sticky window thing, I think its pretty questionable whether they would improve things for windows with multiple tags in general and am convinced it would worsen things for focusing multiple tags at once
<busy_beaver>
Oh, I see. I misunderstood that. I think without specifying it was easy to misinterpret. Sorry
<leon-p>
busy_beaver: either way, there are plans to move more windowing logic, including the focusing thing, to layout generators. maybe in two or three releases. so eventuall you can have what you want, given you know how to write some code. but for now river windowing behaviour is unlikely to change
<busy_beaver>
If I remember correctly (I might be wrong), awesomewm does this differently though and it works quite intuitively. I would have to check that again though...
<leon-p>
you'd need a different focus-order list for each focused tag combination, which is a pretty massive complexity explosion
<busy_beaver>
So for small screens it is best to ignore the tags functionality entirely and use them like workspaces, and for big screens tags are useful for the combinging thing you described...
talismanick has quit [Ping timeout: 260 seconds]
<busy_beaver>
Sorry, gotta go now, I might have time later, thanks people!
busy_beaver has quit [Quit: Client closed]
<leon-p>
I mean, if you have at most one or two windows per tag, screen size won't matter much
tiosgz has quit [Quit: tiosgz]
Ordoviz has joined #river
angry_vincent has joined #river
angry_vincent has quit [Changing host]
angry_vincent has joined #river
notzmv has quit [Ping timeout: 265 seconds]
Ordoviz has quit [Ping timeout: 250 seconds]
Ordoviz has joined #river
angry_vincent has quit [Remote host closed the connection]
leopoldek has joined #river
Ordoviz has quit [Ping timeout: 260 seconds]
waleee has joined #river
waleee has quit [Ping timeout: 256 seconds]
notzmv has joined #river
awesomerly has joined #river
<awesomerly>
does anyone know where I can get ideas for my configuration file? e.g. shortcuts, etc
<leon-p>
awesomerly: you could ask to see some examples
<leon-p>
(not quite up to date, haven't pushed the changes I made on my workstation yet)
<awesomerly>
thanks for that article you made about river 0.1.0
<leon-p>
glad you found it helpful
<leon-p>
should probably update it eventually
<awesomerly>
one thing that's inherent to using Linux is that like it is impossible to not have overlapping keybinds. maybe I should use alt instead bc I can reach it with my thumb
<awesomerly>
what would you update about it?
<awesomerly>
because doing win shift q for example is awkward
<leon-p>
There were a few breaking changes since 0.1.0
<awesomerly>
yesterday I was having stuff break randomly when I did plain exec but doing riverctl spawn worked
<awesomerly>
what's that about
<leon-p>
exec replaces the shell, meaning every line below that line in your init will never be executed
<awesomerly>
I was doing exec blah &
<awesomerly>
bc some YouTube video guy did it that way
<awesomerly>
lolp that's wrong
<leon-p>
exec is a shell builtin, not a program, the & does not affect it
<awesomerly>
dang
<awesomerly>
thanks
<awesomerly>
also one thing I've noticed when on Wayland is that the cursor doesn't feel as smooth as on x
<leon-p>
don't trust random youtube people with shell things, I have seen some serious horrors on there
<awesomerly>
it feels like there's a lot of ways to write horrible bash scripts
<leon-p>
the cursor thing could be because river falls back to software cursors, some platforms can be wonky
<awesomerly>
but yeah the cursor thing: I am only using Wayland/river on my laptop because I can't rely on mouse
<awesomerly>
but when I was using sway or gnome Wayland on my desktop I noticed this almost imperceptible lag that managed to throw me off in games that I play
<leon-p>
probably due to Xwayland
muirrum has joined #river
<awesomerly>
hmmm
<awesomerly>
I also have it on the desktop too I think
<leon-p>
as I said, software cursor probably
<awesomerly>
doesn't wlroots support hardware cursors?
<leon-p>
yes, but some hardware is weird
<awesomerly>
hmmmmmmm
<awesomerly>
my desktop has a 5700xt, which is an amd graphics card
<awesomerly>
or is that irrelevant
<leon-p>
can't help much graphics stuff, the wlroots people can likely help better in that regard
<awesomerly>
hmmm. I'm not as experienced with working on software stuff as I want to be so it's intimidating to talk to ppl writing graphics stuff as a mere layperson
<leon-p>
a start could be to look at the river logs, maybe you find something to point at
waleee has joined #river
waleee has quit [Ping timeout: 250 seconds]
Szadek has quit [Ping timeout: 248 seconds]
Szadek has joined #river
waleee has joined #river
waleee has quit [Ping timeout: 265 seconds]
awesomerly has quit [Read error: Connection reset by peer]