leopoldek has quit [Remote host closed the connection]
fitrh has joined #river
fitrh has quit [Remote host closed the connection]
tiosgz has joined #river
<tiosgz>
lordmzte: nope, any window is limited to a single output as of now (this will be left up to the wm when the new protocol lands)
<tiosgz>
topsykrets: that systemctl command sets the env variable for (newly started user) systemd services. to have it in your whole session, it's recommended that you also make a wrapper script that sets up your env before running river
<tiosgz>
aviva: this falls into the wm-redesign category
fitrh has joined #river
<leon-p>
huh, I know it won't survive, but I really like that recent wayland-protocols proposal for embedding server side buttons (close, minimize, maximize, etc.) inside client-side drawn decoration
<Nickli>
i have a feeling gnome wont like that, for some reason
<leon-p>
gnome can ignore it, that isn't the issue. it'll just die in review purgatory since there likely won't be active interest from both client and server developers
fitrh has quit [Remote host closed the connection]
<Nickli>
not sure what/how that fixes things
<leon-p>
it would make visual coherency more achievable
<leon-p>
and allows the server to put more exotic actions into window buttons. i.e. you could have a river-specific "tile to the right" button in a gtk headerbar
<leon-p>
this is actually the reverse of an old KDE proposal of doing the opposite: server-side headerbars with a special protocol to allow clients to put buttons into that, but that was of course more limited and arguably not very useful
fitrh has joined #river
<leon-p>
(why do I remember such things instead of something important is a mystery I still haven't solved)
<Nickli>
maybe the important things werent that important
<leon-p>
oh they were
<Nickli>
do you have a link to the proposal?
<leon-p>
I'd rather not open the flood-gates of brigading wayland-protocols by posting a link in a >100 members channel, sorry
<leon-p>
especially since window decorations always invites unkind comments by people who really should think before they type
fitrh has quit [Remote host closed the connection]
* tiosgz
wondered about leon-p's notion of 'recent' (then found a 'mentioned this in xxx yyy hours ago' at the bottom)
<tiosgz>
dunno how well that would work (also cos buttons are too button-y for me) but i suppose it's something gtk would be willing to accept
<Nickli>
reminds of the row of buttons at the top of default AwesomeWM windows
Guest9 has joined #river
<Guest9>
hi, did anyone else have the problem that small floating windows are hidden when they are spawned by an application in fullscreen like gimp? Is there a way to show those windows even in fullscreen?
<Guest9>
is there way to use riverctl rule-add to solve this? just noticed this now
<tiosgz>
unfortunately there's currently no way in river to work around it
<leon-p>
should be WM policy in the future
<Guest9>
maybe the issue could be mitigated by a setting that blurs the fullscreen window, when a small hidden window takes the focus? so you know why, it isn't responding
<Guest9>
sorry, messed up the commas
<leon-p>
that is actually more complicated than just showing the small window above the fullscreen one :)
<Guest9>
:D
<leon-p>
FWIW I think this will be solved eventually, the issue is known
<leon-p>
there are multiple ways to solve it: un-fullscreen the current window if another window takes focus, place focused windows above fullscreened windows, force full-screen windows into their own separate single-window workspace, etc.
<leon-p>
#1100 will open up quite a few possibilities
<Guest9>
Okay, thanks. I can live with it, I have no gaps defined and only a small bar at the top, so I just use a tab with a single view and rarely use fullscreen. But I think an application like blender in fullscreen looks nice.
<Guest9>
#1100 looks neat
fitrh has joined #river
mohan43u has joined #river
mohan43u has quit [Client Quit]
mohan43u has joined #river
tiosgz has quit [Quit: nyaa~]
Guest9 has quit [Quit: Client closed]
fitrh has quit [Remote host closed the connection]
kotto has joined #river
kotto has quit [Ping timeout: 255 seconds]
Guest89 has joined #river
mtm has quit [Ping timeout: 244 seconds]
mtm has joined #river
Guest89 has quit [Quit: Client closed]
autisticshark has quit [Remote host closed the connection]
<kraem>
hey! i'm integrating cliphist into my env and it's working as intended with "wl-paste --watch cliphist store". i'm looking into filtering what goes into the clipboard history (specifically pw:s copied by gopass). i've found that one should be able to set "CLIPBOARD_DATA="sensitive"" when using "wl-copy" and can subsequently see if the env var is set to sensitive during "wl-paste --watch" and in that case skip persisting the data in the history.
<kraem>
i'm testing if that approach is viable by running "wl-paste --watch sh -c "env | grep CLIPBOARD_STATE"" and "CLIPBOARD_STATE=sensitive wl-copy "x"" but CLIPBOARD_STATE is always data. am i holding it wrong or is CLIPBOARD_STATE of kind sensitive not impled in river?
<kraem>
oh "currently wl-clipboard only ever sets CLIPBOARD_STATE to data or nil"
trav91499 has quit [Remote host closed the connection]
travankor has joined #river
hej has joined #river
<hej>
What paths does river search for cursors? I installed some cursors in /usr/local/share/icons but it did not pick up on them, but when I put the same folder in ~/.icons it worked?
<hej>
another issue is the keyboard mess that happens after I close down river. i can not get consistent input to console after i shutdown river and I have to reboot the computer. Previously, but I don't know where, I was advised to look into sysrq settings in the kernel, but I forgot about the precise details and on this new computer it does not work
<hej>
again.
hej has quit [Quit: Client closed]
kotto has joined #river
leopoldek has joined #river
<__toor__>
(that was me)
<__toor__>
It seems to work if I use tty1 and exec river
<__toor__>
but not on tty2
<__toor__>
that is, I do not get the issue if I use tty1.
<__toor__>
the only difference I can see is that I launch openvt with -s on tty1 and not on tty2
<noha_boat>
can anyone please tell me how to access more than 9 tags. I am not a programmer, I tried everything but everywhere I find accessibility to only 9 tags through keyboard shortcuts. how do we use 31 tags
<noha_boat>
I spent a whole day trying to figure this out looking at wiki and at documentation. I understood the logic behind but not any practical way to access more than 9 tags.
noha_boat40 has joined #river
<leon-p>
noha_boat: do you understand the tag bitfield?
<leon-p>
if yes, your next step is understanding what the $((1 << ($i - 1))) syntax in the init means
<leon-p>
basically it uses shifting to construct an integer number which binary representation equals a tag state where only the i-th tag is active
<leon-p>
the example init uses i from 1 to 9
<noha_boat>
i read the documentation and from it I understood that there are 32 bits in every tag which means 32 on and off positions. 1000000000000000000000000000000001 this would mean 1st and last tags are selected
<leon-p>
correct
<leon-p>
the tricky thing however is, that 100...001 is not the number you provide to the riverctl commands
<leon-p>
imagine the tag state 0...010. that would require the number 2
<leon-p>
0...100 would be 4
<noha_boat>
yes I saw this but couldn't understand how it works. I just replaced 9 with 30 in the variable range butnothing worked
<leon-p>
of course not, because you don't have number keys for 10 to 30
<leon-p>
only 0 to 9
<leon-p>
if you just extend the range of the loop, the commands will try to assign to non-existent keys
<leon-p>
what you could do is copy the loop and in the copy have it run from 10 to 20 and change $i to F$i, so it would bind tags 10 to 20 to F1 to F10
<leon-p>
for example
<leon-p>
FWIW you already understood the hardest part about tags :)
<noha_boat>
but i think the number of tags did increase because when I was trying to do "riverctl set-focused-tags 1...7" and then did 200 and 100001101 multiple tags were selected even upto the tag number 25 in sandbar.
<leon-p>
all tags always exist, regardless of configuration
<leon-p>
what you want is a keybind to access them
<noha_boat>
thanks for the f1 to f10 trick it will increase by tag range to 20
<leon-p>
if you want to understand this clearer, I think you'll want to read the documentation on mappings (man riverctl)
<noha_boat>
oh ok I have not read the mapping section very well. I will try
<noha_boat>
oh ok I have not read the mapping section very well. I will try
<noha_boat>
oh ok I have not read the mapping section very well. I will try
<noha_boat>
oh ok I have not read the mapping section very well. I will try
<noha_boat>
oh ok I have not read the mapping section very well. I will try
<noha_boat>
oh ok I have not read the mapping section very well. I will try
<leon-p>
The most important bit for you I think is what the $i field means in this loop
<noha_boat>
but thanks to sandbar I can access all 31 tags with mouse. I just put this line in its configuration option - "-tags 25 '01' '02' '03' '04' '05' '06' '07' '08' '09' '10' '11' '12' '13' '14' '15' '16' '17' '18' '19' '20' '21' '22' '23' '24' '25' and then with mouse I have access to 25 tags. I am so thankful to the developer for it and for GOD to
<noha_boat>
give me wisdom to apply this method
<noha_boat>
can you please explain to me what the $i field means or do I need to read it from somewhere?
noha_boat15 has joined #river
noha_boat15 has quit [Client Quit]
noha_boat40 has quit [Ping timeout: 256 seconds]
noha_boat has quit [Ping timeout: 256 seconds]
proycon has quit [Ping timeout: 244 seconds]
noha_boat has joined #river
noha_boat has quit [Quit: Client closed]
leopoldek has joined #river
vimproved has quit [Remote host closed the connection]
vimproved has joined #river
noha_boat has joined #river
<noha_boat>
sorry i couldnt get it to work not even F1 to F10 method