mekeor has quit [Quit: towards emacs as interface to cybernetic council communism]
pixavi has joined #river
pixavi has quit [Ping timeout: 272 seconds]
Snetry has quit [Ping timeout: 252 seconds]
Snetry has joined #river
Szadek724 has joined #river
kansei has quit [Ping timeout: 252 seconds]
Szadek72 has quit [Ping timeout: 252 seconds]
Szadek724 is now known as Szadek72
NickH has quit [Ping timeout: 245 seconds]
kansei has joined #river
rossabaker has quit [Remote host closed the connection]
rossabaker has joined #river
NickH has joined #river
pixavi has joined #river
pixavi has quit [Ping timeout: 272 seconds]
pixavi has joined #river
pixavi has quit [Ping timeout: 272 seconds]
user21 has quit [Ping timeout: 260 seconds]
pixavi has joined #river
pixavi has quit [Ping timeout: 272 seconds]
angry_vincent has joined #river
pixavi has joined #river
pixavi has quit [Ping timeout: 272 seconds]
pixavi has joined #river
pixavi has quit [Ping timeout: 272 seconds]
pixavi has joined #river
catman has quit [Quit: WeeChat 4.6.3]
catman has joined #river
user21 has joined #river
user21 has quit [Ping timeout: 252 seconds]
ramblurr has quit [Remote host closed the connection]
pixavi has quit [Read error: Connection reset by peer]
pixavi has joined #river
andyrtr has quit [Ping timeout: 265 seconds]
twelve has joined #river
pixavi has quit [Ping timeout: 276 seconds]
<lordmzte>
I refuse to use opentabletdriver because not only do I not like the concept of userspace drivers but also, it's written in C# and that's just completely insane. I think libinput has a way to set a transformation matrix for an input device. We should probably add a control command for this.
catman_ has joined #river
catman is now known as Guest7525
Guest7525 has quit [Killed (lithium.libera.chat (Nickname regained by services))]
catman_ is now known as catman
user21 has joined #river
ramblurr has joined #river
catman has quit [Client Quit]
catman has joined #river
andyrtr has joined #river
pixavi has joined #river
mekeor has joined #river
apoorv569 has quit [Ping timeout: 252 seconds]
pixavi has quit [Ping timeout: 276 seconds]
mekeor has quit [Ping timeout: 272 seconds]
apoorv569 has joined #river
twelve has quit [Ping timeout: 272 seconds]
apoorv56- has joined #river
apoorv569 has quit [Ping timeout: 245 seconds]
apoorv56- is now known as apoorv569
pixavi has joined #river
apoorv569 has quit [Ping timeout: 244 seconds]
apoorv569 has joined #river
pixavi has quit [Remote host closed the connection]
mekeor has joined #river
apoorv569 has quit [Ping timeout: 265 seconds]
apoorv569 has joined #river
apoorv569 has quit [Ping timeout: 260 seconds]
<gochujang>
Is there a simple way to get the currently focused tag via cli with river?
<gochujang>
Because going through the hassle of installing riverwm-utils seems like such a hassle for being able to do prev-tag next-tag.
aimixsaka has quit [Remote host closed the connection]
aimixsaka has joined #river
apoorv569 has joined #river
apoorv569 has quit [Ping timeout: 272 seconds]
<leon-p>
Franciman: the river protocols are Wayland protocol extensions. To speak to river, connect to the Wayland socket and bind the needed globals via the registry
<Franciman>
ty
<leon-p>
although I wouldn't spend any time with the current protocols, since they'll all be deprecated by #1100
<gochujang>
And there'll be no reference implementation like rivertile once that lands right?
mekeor has quit [Quit: towards emacs as interface to cybernetic council communism]
Franciman has quit [Ping timeout: 260 seconds]
Franciman has joined #river
<leon-p>
no idea
<leon-p>
maybe in a separate repo?
<leon-p>
although that will take some time still
<leon-p>
we haven't solved input configuration yet, f.e.
<leon-p>
maybe we really should have a very simple C or Zig WM
<leon-p>
something that isn't a magic lisp/zig/wayland amalgam
<leon-p>
maybe à la "here is the most basic WM you can imagine. It works, but I've left some blanks for you, have fun filling them in"
<leon-p>
I did that for the layout protocol, it currently lives in the contrib/ directory in the river repo. no idea if anyone ever looked at it
<leon-p>
ok I just looked if it's still there (it is) and I wish flaming acid death to the entire "AI" industry for forcing codeberg to use anubis, which sometimes takes more than 10 seconds on my laptop to finsh the PoW</rant>
user21 has quit [Ping timeout: 252 seconds]
<gochujang>
I'm asking because, although I get the idea behind the new architecture, from a user perspective, not everyone wants to build their own window manager
<gochujang>
Personally I do like what river offers as an alternative to dwm/bspwm on wayland
<gochujang>
But having to resort to community maintained libs is a pain imo.
<gochujang>
For one, they're often not packaged for your distro of choice. And secondly, are usually not that high quality
<gochujang>
So it's a bit of a pain point that harms what I otherwise feel is good software
<gochujang>
I think a reference implementation could be both high quality and shipped as a default (if potentially a separate package)
<gochujang>
It'd offer a good implementation to develop against as well
<gochujang>
Plus would still allow others to extend river in different ways if they so choose
<gochujang>
Basically, don't forget about the part of your users who like river and want to come along with the new architecture, but don't have the time to code their own wm
<gochujang>
Otherwise you're just fragmenting your ecosystem for the sake of modularity, which seems like a shame
<leon-p>
we don't plan to have any ecosystem at all, nor will river carry any kind of distinguishable identity into the future
<gochujang>
how do you mean?
<leon-p>
basically we want the WMs to directly "compete" with other desktops. that they depend on river would be just an implementation detail
<gochujang>
ok, so you're intending for it to become a framework, in a way
<gochujang>
like a framework to build a wm?
<vyivel>
a framework to build a compositor by providing your own wm
<leon-p>
we want to get to the point where you install fooWM and river is pulled as a dependency without the user needing to care. instead of a user thinking "I want to use river, let's look at available WMs", we want users to just choose a WM based on it's own merrits compared not amongst river WMs, but other wayland desktops like sway, hikari, etc., so that river is really just a dependency
<leon-p>
vyivel: honestly I don't like the name "compositor" here, it's just confusing and loaded by a load of very bad blog rants about wayland. river == display server, WM == the thing you care about
<vyivel>
eh, compositor is the term widely used for display servers, blog rants aren't worth reading anyway
<gochujang>
hmm. I think that's too bad really. I just want a wm that works like river
<gochujang>
I suppose it's your right to shift focus of course
* vyivel
is thinking about potential "river-like" servers which implement the same wm protocol but provide e.g. eye-candy stuff
<gochujang>
Until someone picks up that goal, I'm kind of out of options
<gochujang>
What I'm saying is, although it's a lofty goal, it's a loss for the part of your userbase that just wants the wm
<gochujang>
Again, not saying that you have to care. But if it's supposed so simplify development of a wm, why not continue maintenance/development of a wm component and not alienate that part of your userbase?
<leon-p>
I don't understand what you are trying to communicate with that sentence, sorry
<leon-p>
note that the current state of river has always been considered a stop-gap. even before we had the idea of the WM protocol, there were pretty severe breaking changes planned
<leon-p>
also current river will not go away. if you don't like the WM stuff, just use an older release 🤷
<gochujang>
Yeah no I know
<leon-p>
also "simplifying WM development" is a misunderstandment. If you have a set design, going straight to wlroots isn't hard. It's about simplifying /experimenting/ with WM and UI concepts
<gochujang>
But do you see my point about alienating part of your userbase?
<gochujang>
The river-classic branch is nice to have, but I can imagine it won't see as much active development
<leon-p>
yes. and to be frank, i don't care? Like I don't mean that in a mean way, but you can't assume pre 0.1 software has any kind of feature stability. We have always made clear that we want to do more and different things
<gochujang>
I'm not assuming stability though
<gochujang>
I'm talking about supporting certain usecases
<leon-p>
all use cases we currently support can be catered too with a WM
<gochujang>
Yes
<gochujang>
Built by someone else
<leon-p>
yes
<gochujang>
My point exactly
<leon-p>
so what?
<gochujang>
Well it seems like I'm not getting through
<gochujang>
Point is that in all likelihood it'll suck because it won't see as much development effort, because it'll be fragmented more
<gochujang>
Like the community layout generators are nice. But they're not really great tbh.
<gochujang>
So you're throwing out a nice solution because you're laser focused on having a nice abstraction.
<elagost>
I've been using 'filtile' the entire time I've been using river. It's like the builtin rivertile but just a little better. Having community layout generators is really nice, and I wouldn't miss rivertile being gone.
<leon-p>
gochujang: you seem to think that this will just split the current river user base. that is most likely wrong
<gochujang>
Well. We'll see. Maybe a really nice alternative will come along
<gochujang>
Not necessarily split. Divide attention among multiple alternatives.
<gochujang>
Anyway. We'll see
<gochujang>
I've made my case
<leon-p>
that's already the case though. look at the wider picture. many people work on many different wayland servers with wlroots. maybe they'll write a river WM once that is a viable alternative
<leon-p>
despite, fragmentation has always been a myth. developers working on an alternative aren't a workforce taken away from the original. without the alternative, they ofnte wouldn't contribute to the original either
<gochujang>
Sure
<leon-p>
and the reason current community layouts suck is because the layout protocol just isn't an interesting target to develop against. It's not very fun.
<gochujang>
I had just hoped it'd stay a complete package
<leon-p>
river isn't and was never supposed to be a complete package
<gochujang>
Maybe it wasn't supposed to be. And it's modular. But it sure as hell can be installed as a complete package
<leon-p>
🤷
<gochujang>
We can argue semantics, but you know what I mean
<leon-p>
I do, but I don't know why you'd care
<gochujang>
Well it's fine. You do you. It's not like you have to see it the same way
<gochujang>
Although I do get the idea my point hasn't come across at all either
<gochujang>
But I tried
<leon-p>
but let's be very realistic here: rivers current window management is fairly trivial. you could implement that on top of the WM protocol in less than a week, likely less than 2k lines of C depending only on libwayland. Someone will do that. Maybe I will do that, just because I can. Would that be enough for you?
<gochujang>
If that happens and it's stable then sure
<gochujang>
Especially if it ends up popular enough to be packaged and shipped by the major distros
<robertgzr>
couldn't the current layout generator protocol be implemented on top of the new wm protocol?
<robertgzr>
if river 0.3 is maintened then rivertile will be, letting you package the current ux with the shiny new features from river 0.4+
<leon-p>
robertgzr: yes you could. although that is a bit more complicated than just packing current river+rivertile behaviour into a WM
<leon-p>
or, in other words, rivertile is the simplest part of how rivers current window management works
<LarstiQ>
leon-p: fwiw, yes I did look at the contrib/ contents
<LarstiQ>
mostly used the layout.py to build my own layout generator but still looked at the rest
<robertgzr>
i see, well i for one would love to use a wm client that behaves somewhat like river today but is implemented in some scripty language that makes hacking on it easier
<leon-p>
robertgzr: that's basically the goal. both isaac and me are throwing some lisp and zig together to build a WM
<leon-p>
isaac is using janet
<leon-p>
I use chicken scheme and plan to make it emacs-esque, i.e. have lots of hooks users can add functions into
<robertgzr>
out of curiosity, since it sounds like you both dont really care about the current ux what mechanisms do you like your wm to have?
<leon-p>
honestly? it won't tile. basically all programs I regularly use have their own internal window management (firefox, emacs, gimp, etc...) or don't need it (foot). No workspaces or tags. But powerful rules for showing/hiding and arranging windows based on current task
<leon-p>
and it's UI will be inspired by motif and CDE
<leon-p>
there are actually no "modern" desktops that have this kind of style, which is a shame. I personally can't stand the current trend of round corners, transparency and blur
<LarstiQ>
I'm a bit sceptical I won't like the lack of tiling but I'll definitely try it out
<robertgzr>
ouu i didnt know it would also let you do ui stuff
<robertgzr>
/me has not looked at the wm proto stuff or kept up with it whatsoever
<leon-p>
the custom UI stuff is also what gets me the most excited :)
<leon-p>
I'll plan on adding window-maker / next-step like block widgets
<leon-p>
LarstiQ: ideally the hook system will be powerful enough that you can just implement tiling and workspaces and what not on top of it
<LarstiQ>
leon-p: aye, that will be the fallback. But maybe your paradigm is superior despite my scepsis :)
<leon-p>
maybe, not sure myself either, but it's the challange I've set myself :)
pkap has quit [Ping timeout: 272 seconds]
cfebs has quit [Ping timeout: 248 seconds]
cfebs has joined #river
Ireozar has quit [Ping timeout: 248 seconds]
Ireozar has joined #river
<leon-p>
I also think the custom UI stuff will be what makes people interested in writing river WMs
siaal has quit [Ping timeout: 272 seconds]
gochujang has left #river [#river]
notzmv has joined #river
siaal has joined #river
gochujang has joined #river
<gochujang>
I'm back
<gochujang>
> I also think the custom UI stuff will be what makes people interested in writing river WMs