<ifreund>
I've been wondering whether it wouldn't make more sense to fork and release the rwm branch under a new name
<ifreund>
I feel pretty unmotivated to work on a complete reimplementation of river 0.3 behavior for backwards compatibility purposes
<ifreund>
One idea would be to fork off the 0.3.x branch and rename that to river-classic or something
<ifreund>
though that still has the issue of the theoretical river 0.4 release being wildly incompatible with 0.1-0.3
<ifreund>
We could probably manage some kind of message that tells people to switch to river-classic, but breaking everyone's setups when distros update the river package to 0.4 seems inevitable
<ifreund>
Therefore I think leaving river in its current state in "maintenence mode" and moving the rwm branch to a hard fork with a new name would be better for river's users
<ifreund>
I still need to come up with a good name though, here's my best attempt so far:
<ifreund>
jawc - Just A Wayland Compositor, Window Manager not included
<LarstiQ>
riverbed?
<ifreund>
A short made up word with no prexisting meaning could also be good
<ifreund>
no river related naming suggestions please
<Nickli>
floodplain /S
<Nickli>
... because it planes out
<TheAnachron>
riwm? =D sounds like rhythm.
<TheAnachron>
but probably too similiar to river?
<TheAnachron>
I haven't followed the discussion a lot lately, what is the plan for 0.4? What will that look like? Do we have any of the layout engines which will be ready on the river 0.4 release? How will bindings work? Is there any blogpost about this?
<TheAnachron>
maybe flexwm, dynwm or alike, as it will probably one of the most flexible WMs
<ifreund>
its not a wm though
<ifreund>
TheAnachron: the rwm branch is just a compositor that implements a window management protocol, all window management policy will be handled by a separate program
<ifreund>
that includes keybindings and everything else
<ifreund>
"Just a wayland compositor, window manager not included"
<TheAnachron>
jawc sounds fitting then
<vyivel>
finally x12
<TheAnachron>
there is no binary in my distro with that name either ;)
<ifreund>
vyivel: I'm going to have to deal with a lot of X11 truthers on my issue tracker aren't I?
<vyivel>
personally marking 0.3 as -classic and leaving some note for packagers would be ok too
<TheAnachron>
X11 truthers^^ nice one
<ifreund>
vyivel: do package managers generally have a way to handle that kind of transition atomically?
<TheAnachron>
Will there be a layout engine available with the first 0.4 release?
<ifreund>
i.e. if installed river version is <0.4 replace with river-classic
<vyivel>
dunno tbh
<TheAnachron>
ifreund Void Linux package manager can do it, but we try to avoid such a thing
<ifreund>
I guess renaming to river classic now and tagging a bug-fix release would give people enough time to migrate
<ifreund>
I don't expect the window management protocol to be release-ready for quite some time yet
<TheAnachron>
How do you imagine the transition though?
<ifreund>
TheAnachron: I expect users to use river-classic until they see a window manager for the new window management protocol they would like to try
<ifreund>
or just use river-classic for years
<ifreund>
(assuming they are happy with the current feature set)
<TheAnachron>
Got it, 0.4 is just for package managers to prepare for the future, nothing for end-users yet :)
<LarstiQ>
jawc looks a bit close to labwc to me, but maybe that's ok
<ifreund>
well, by the time the window management protocol is released I will certainly have been daily driving a window manager using it for a while
<ifreund>
LarstiQ: yeah, I don't like jawc being halfway between jay and labwc
<ifreund>
If I can convince myself that the river-classic path can be handled well by distros, I think I'd prefer that path though
<Nickli>
if you go with the oxen-team route you could keep it GNU themed
<ifreund>
I don't really want it to be gnu themed
<Nickli>
WindowTrow
<Nickli>
cant think of a substitute for window
haliucinas has joined #river
Guest72 has joined #river
Guest72 has quit [Client Quit]
aktina has quit [Remote host closed the connection]
notchoc has quit [Remote host closed the connection]
aryak has quit [Remote host closed the connection]
aktina has joined #river
notchoc has joined #river
aryak has joined #river
notchoc has quit [Remote host closed the connection]
aktina has quit [Remote host closed the connection]
aryak has quit [Remote host closed the connection]
aktina has joined #river
notchoc has joined #river
aryak has joined #river
notchoc has quit [Remote host closed the connection]
aryak has quit [Remote host closed the connection]
aktina has quit [Remote host closed the connection]
<LarstiQ>
ifreund: partly this is about what kind of timeframe you have in mind for the transition. One could e.g. do river -> river-classic in one distro release and then reintroduce river in the next but people who skip the intermediate would be broken that way
<LarstiQ>
Debian has a slower release cycle but then we're in luck with river not being formally packaged yet
<LarstiQ>
(and it being too late for the current release process)
<LarstiQ>
so yeah tagging river-classic now sounds like a good plan
<TheAnachron>
I dont think we should ever switch back from river-classic to "normal" river
<TheAnachron>
this opens up a can of worms that we dont really want to touch
<LarstiQ>
Juolua and lúbloch for Oxbow_lake in two other languages if one fancies an extra level of indirection
<leon-p>
ifreund: pacman can handle changing package names as well, so a river -> river-classic switch would be possible on arch an friends
<leon-p>
although I must say that I personally don't have an issue with just having a breaking release still under the river name
<leon-p>
river is pre 1.0 software, we never promised feature stability
<leon-p>
as for alternative names, we could use the name of a river, f.e. danube, as a nod to its "heritage"
<ifreund>
I think package renames are generally easy, what I imagine isn't handled as cleanly is a package rename while also adding a new package with the old name
<TheAnachron>
^ 100% agreed.
<ifreund>
though now that I've written it out like that it certainly seems like a case that would have come up before
<ifreund>
I wonder if Wayland MA has a river
<TheAnachron>
I think for a rolling-release distro (like Arch/Void, etc) a grace period would be okay, like wait one year and put a "replaces=river<=1.4.0" inside the template. But some distros take a long time, not sure how one would handle those
<ifreund>
looks like the sudbury river is closest to wayland, not a fan of that name though :D
<leon-p>
another issue with a fork: who will maintain river-classic? river in it's current state has some rough edges and given a few years will fall behind development of wayland-protocols
<leon-p>
I think if a distribution wants to offer river in it's current form, it can package 0.3.x alongside current river. that isn't uncommon
flower_ has joined #river
<leon-p>
although I am not sure how high the demand is for a river-classic anyway
<leon-p>
from what I can gather, most people use river for it's tiling model and I think it's realistic that some dwm clone will appear sooner rather than later once the WM protocol is merged
<LarstiQ>
I don't suppose there are any stats for how many river users there are? More than just the people in this channel I guess
<ifreund>
leon-p: I know we haven't promised stability. The fact of the matter is that we have barely broken things since 0.1.0 though and I suspect there are many quiet river users who are more or less satisfied with how things work now
<ifreund>
I think it would be kind to them to not break things if possible
<leon-p>
I think we can offer a river-classic, if one of them steps forward and offers to maintain it
<ifreund>
It would be much less effort for me to update river-classic to new wlroots and zig versions every now and then than write a fully featured window manager equivalent
<ifreund>
it would be feature frozen though
<ifreund>
and if someone wanted to take over maintainership I would be happy to hand things over
<leon-p>
that still leaves the question of logistics: what would be the fork: rwm or river-classic? do we need a new name and what will that be?
<ifreund>
yep, splitting off river-classic as the fork has the advantage of not needing a new name (and I'd also be sad to lose our nice logo)
<ifreund>
the downside is the less straightforward upgrade process for distros and users
<leon-p>
I am not sure how sophisticated you want the reference WM to be, but we can always just display a message in a pop-up like "breaking changes, if you want the old behaviour, install river-classic"
<ifreund>
If I could come up with a name I like more than river, I'd be very tempted to take the new name route
<ifreund>
leon-p: that may also be a fine path to take
<ifreund>
I do envision a small window manager manager thing shipped with river that allows to switch/start window managers, recover from window manager crashes, and whatnot
<leon-p>
pretty sure most popular package managers do support displaying a message on package update. and we can just spawn "foot -e less message.txt"
<ifreund>
details very TBD, but printing a "consider installing river-classic" message would be in scope
<leon-p>
does that mean we can outsource text rendering into river itself? /s
<ifreund>
I'd like to rely on distro packagers handling the upgrade process smoothly as little as possible
<leon-p>
I think we still have enough time to think about that. the split can happen once rwm is ready to merge
<leon-p>
and we might even get some feedback until then
<LarstiQ>
detect presence of ~/.config/river/init (and proper XDG places etc) and warn that it looks like a river-classic setup?
<leon-p>
yeah, that could work
<leon-p>
although I probably won't be involved in that anyway; I am mostly interested in the WM thing and my time doesn't really allow me to care about that kind of infrastructure; I'll take whatever decission will materealize itself
<TheAnachron>
LarstiQ: that would break the 2nd you have someone use the -c argument
<ifreund>
I think I'm happy with the river-classic plan for now, I think we should be able to offer a smooth enough transition process with some thought
<ifreund>
For example, river 0.4 might require a `-wm foowm` arg to start the window manager
<ifreund>
(and only expose the window management protocol to that process)
<leon-p>
that would also allow having dedicated session files for each WM, so that you could switch between them in a display manager
<leon-p>
ideally, a user just installs a WM and never needs to think about river itself
<ifreund>
indeed
Guest11 has joined #river
Guest11 has quit [Quit: Client closed]
Szadek has quit [Quit: off]
Szadek has joined #river
elshize has joined #river
aryak has joined #river
notchoc has joined #river
aktina has joined #river
flower_ has quit [Quit: Lost terminal]
waleee has joined #river
deadcade has quit [Ping timeout: 244 seconds]
deadcade has joined #river
deadcade has quit [Remote host closed the connection]
deadcade has joined #river
deadcade has quit [Remote host closed the connection]
deadcade has joined #river
Guest4 has joined #river
Guest4 has quit [Client Quit]
user21 has joined #river
notchoc has quit [Remote host closed the connection]
aktina has quit [Remote host closed the connection]
aryak has quit [Remote host closed the connection]
aktina has joined #river
notchoc has joined #river
aryak has joined #river
ramblurr has quit [Remote host closed the connection]