SleepBg has quit [Remote host closed the connection]
waleee has quit [Ping timeout: 268 seconds]
waleee has joined #river
Guest95 has joined #river
leon-p has quit [Quit: leon-p]
Guest95 has quit [Client Quit]
waleee has quit [Ping timeout: 268 seconds]
waleee has joined #river
waleee has quit [Ping timeout: 268 seconds]
waleee has joined #river
ext0l has joined #river
waleee has quit [Ping timeout: 268 seconds]
waleee has joined #river
waleee has quit [Client Quit]
waleee has joined #river
snakedye has quit [Ping timeout: 245 seconds]
novakane has joined #river
snakedye has joined #river
notzmv has quit [Ping timeout: 268 seconds]
dbuckley has quit [Ping timeout: 245 seconds]
dbuckley has joined #river
leon-p has joined #river
qyliss_ has joined #river
zxtx has joined #river
ext0l_ has joined #river
ext0l has quit [Ping timeout: 260 seconds]
qyliss has quit [Ping timeout: 260 seconds]
zxtx_ has quit [Ping timeout: 260 seconds]
neo has joined #river
<neo>
is there ipc protocol for river?
<neo>
I want retrieve the active window title in river
<neo>
^ to
<novakane>
neo: you need to use either river-status-unstable-v1.xml or wlr-foreign-toplevel-management-unstable-v1.xml
<neo>
for where i can get river-status-unstable-v1.xml or wlr-foreign-toplevel-management-unstable-v1.xml?
<neo>
also can these files allow me to know the current workspace number?
n3o has joined #river
neo has quit [Remote host closed the connection]
<n3o>
are those files included in the river git repository?
<novakane>
that's some wayland protocols that you need to use to make a client that do what you want, river protocols are in river repo src/protocol wlr protocols are on wlroors repo
<n3o>
so that means that river needs to be configured or built using those protocols?
<n3o>
in order to have support to retrive current window title
<n3o>
and the active workspace number?
<novakane>
no you don't need to make anything in river for this, that your application that need to support it
<leon-p>
no. Those protocols are always available. They are in fact how riverctl communicated with river
<leon-p>
*communicates
<n3o>
which means that the application i want to retrieve the title data from
<n3o>
should support the mentioned protocols?
<n3o>
or it just works?
<n3o>
i want to retrieve title for: rofi (xwayland), alacritty and firefox
notzmv has joined #river
<n3o>
do these packages support the protocols?
<leon-p>
it means that river uses Wayland for IPC
<n3o>
ok
<novakane>
if you just want title use lswt
<n3o>
and what about the workspace number (active)?
<leon-p>
the windows of which you want to retrieve the title do not need to support those protocols. They just set their window names and river will make that available to you
<leon-p>
for tag status, use the river-status protocol. for setting the tags, use the river-control protocol
<n3o>
lswt.c:(.text+0x1899): undefined reference to `backtrace'
<n3o>
is this something that provides additional commands to riverctl?
<n3o>
or river?
<n3o>
or there's a specific command for this
<novakane>
I never used it but I guess this is a executable that you run
<novakane>
yeah `./target/release/ristate --help` to see
<n3o>
i'm able to get the focused window title
<n3o>
but what i'm supposed to pass to the -o flag
<n3o>
it says output
<n3o>
does it mean my "DVI-I-1" output?
<novakane>
probably
<novakane>
snakedye: ^
<n3o>
how do I setup ristate with waybar?
<n3o>
to display tags and focused window title
<novakane>
I don't think you need it, waybar already support river-status protocol AFAIK
<n3o>
will it work from the package manager's binary or i need to build it from source?
<novakane>
sorry no idea, I don't use it
<n3o>
aww man
<n3o>
np i'll ask snake on discord
<n3o>
thank you so much for all the help
<n3o>
have a good day/noon/afternoon/evening/night/midnight
n3o has quit [Remote host closed the connection]
<leon-p>
ok, lswt hopefully builds fine now on musl
<Danacus>
I would like to try to add tablet support to river, but I'm wondering how "correct" it should be. In principle you should be able to use multiple tablets and tablet tools and they should each have their own cursor (this is how GNOME does it). But when looking at sway, they just hacked something on top of the existing cursor... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/706003defc25fe3d0dff0cda40b508d470b15a21)
<Danacus>
s///, s/(/(I should maybe make an issue about this on github?)/
<leon-p>
Danacus: I think the only person who can answer this question is someone who actually uses drawing tablets. I am personally fine with a tablet pen moving the main cursor, but I do not use tablets daily and I am also not an artist...
<leon-p>
I propose you do it the simpler way right now. We can always improve it later on.
<snakedye>
I prefer the way GNOME does it
<Danacus>
I'm not really an artist either, but I do find it hard to imagine using multiple pens at once.
<Danacus>
I also prefer the way GNOME does is, the only thing annoying about it is that they don't hide the main cursor when using the pen or touch.
<Danacus>
At the end of the day it's only a few lines to change it from single to multiple cursors in river, so I guess it doesn't matter that much.
<snakedye>
If you're the sole user, it doesn't make sense but I found it plausible multiple people could draw on the same canvas at the same time. I agree on the cursor not being hidden being an issue
<leon-p>
snakedye: how realistic is that scenario? Because drawing tablets supporting multiple pens at once are not exactly common and I don't believe application support is quite there yet either
<Danacus>
snakedye: I tried that by plugging in an old drawing tablet while also using the touchscreen. GNOME handled it fine, but Xournal++ (GTK) and Krita (Qt) didn't understand it at all which created interesting results.
<Danacus>
so as long as no applications support it there's no real reason for the compositor to support it I guess
<leon-p>
I think you maybe need to use multiple seats for that, but I am not really an input device expert, so don't quote me on that
<Danacus>
Using multiple seats is probably out of scope, at least for now
<snakedye>
leon-p: It's definitely rare but I don't see why it shouldn't be feasible. Since no client supports this behaviour it's not feasible anyway
<Danacus>
I was reading the docs from wacom and apparently many complicated things are possible. This is what they say for example:
<Danacus>
> Note that it is possible for multiple tools to be in proximity at the same time – both on different surfaces and on the same surface. This may occur if a user has multiple tablets plugged in, or if a single tablet supports multi-tool operation (e.g. an electronic whiteboard).
<leon-p>
Danacus: maybe only the first tool that gets into proximity should move the main cursor and the others just get their events forwarded to the application
<snakedye>
One instance where multi pointer is probable is if you want to zoom into a canvas or shift it with your hand while drawing with your pencil
<Danacus>
snakedye: Touch input gets disabled when the pen is in proximity, at least on my device. Not sure if this is specific to hardware or to certain programs or whatever.
<Danacus>
It's a feature to prevent your palm from interfering