<mathstuf>
off to bed…hopefully ill see someone on the PR
mathstuf has quit [Quit: leaving]
waleee has joined #river
waleee has quit [Ping timeout: 246 seconds]
<sewn>
ever since moving to river, dbus services seem to kill themselves immediately upon startup, could river do something in relation to this?
<sewn>
maybe it could be related to WAYLAND_DISPLAY not being exported by dbus but that doesn't make sense because this didn't happen on another compositor
<ifreund>
sewn: river doesn't touch anything releated to dbus itself
<ifreund>
you indeed need to ensure that WAYLAND_DISPLAY is set for graphical service launched by dbus activation or whatever
<ifreund>
that's unrelated to river though
<sewn>
weird
<sewn>
didn't have this issue on another compositor
<sewn>
ifreund: how can I ensure the env
<sewn>
I'm running river normally with dbus-run-session
tiosgz has joined #river
<tiosgz>
yikes, how much happened in the few days that i was offline!
leopoldek has quit [Ping timeout: 252 seconds]
<tiosgz>
sewn: you need to run dbus-update-activation-environment ENV_VARS from somewhere the env vars are present (e.g. the init)
<sewn>
awesome thanks
<sewn>
still concerned how this didn't happen with another compositor
<tiosgz>
maybe the other compositor did it for you /shrug
<sewn>
I
<sewn>
t is worse than river so I dont think so
angry_vincent has quit [Remote host closed the connection]
tiosgz has quit [Quit: nyaa~]
hush has joined #river
hush has quit [Quit: WeeChat 4.3.3]
hush has joined #river
hush has quit [Client Quit]
hush has joined #river
Guest39 has joined #river
Guest39 has quit [Client Quit]
_2Kaleb has joined #river
<_2Kaleb>
Can I move a window from anywhere to the focused tag on the focused monitor?
<sewn>
_2Kaleb: dont you have to be on the focused monitor and on a focused client to be able to perform actions on it?
waleee has joined #river
_2Kaleb has quit [Remote host closed the connection]
hush has quit [Ping timeout: 255 seconds]
hush has joined #river
spurgis has joined #river
spurgis has quit [Client Quit]
leopoldek has joined #river
catman has quit [Quit: WeeChat 4.3.0-dev]
catman has joined #river
hush has quit [Quit: WeeChat 4.3.3]
<leon-p>
I can't wait for the WM protocol so that we can do a sweep on the issue tracker and close basically all feature requests
<leon-p>
another WM protocol idea: I would really like it, if the WM could instruct river to render previews of windows to arbitrary positions in arbitrary dimensions
<leon-p>
possible use cases based on real-world examples: alt-tab menu with window previews, a task-bar where you can hover on minimized windows to get a preview, a gnome-like overview feature
<ifreund>
that's a reasonable feature request, but not something I'd consider working on before the wm protocol is usable and 0.4.0 is released
<leon-p>
I'll put it on the list
<andyrtr>
is anybody running claws-mail either wayland or xwayland mode using GDK_BACKEND=x11? I can't access the msg content/preview window using "V" key.
Guest12 has joined #river
<Guest12>
Question about the 0.4.0 plans. I've read that river will no longer have a concept of tags/workspaces. So I would have to implement something like the ext-workspace protocol myself to get that information displayed in eg waybar?
<leon-p>
no
<leon-p>
because ext-workspace will not work with the architecture of an external WM
<leon-p>
(and IIRC the ext-workspace implementation in waybar is completely cooked anyway, since they decided to implement the protocol before it was finalized without vendoring it, which shows a concerning lack of understanding of how wayland works and basically doomed the protocol to an incompatability hell for all eternity)
<leon-p>
instead, WMs will likely either have a built-in bar for such things or expose some other IPC mechanism
<Guest12>
Oh yeah right, didn't think that through. I think it would be great to have a standardized way to expose that information though.
<leon-p>
in theory yes
<leon-p>
however, different WMs will likely have vastly different ideas about what workspaces/tags/etc. are and how they will work
<Guest12>
Yeah was about to write that.
<leon-p>
I suspect that eventually there will be some popular WMs with explicit support in popular bars, and that the more niche ones are on their own. exactly as the situation is right now anyway w.r.t. to wayland compositors or X11 WMs
<leon-p>
or that WMs will tend to be more like desktop shells and implement widgets like bars themselves, which has other benefits
waleee has quit [Ping timeout: 268 seconds]
<Guest12>
maybe smaller wms could just reimplement the IPC of more popular wms if their workspaces work in a similar way and get support that way. So let's see how this goes then. Thanks.
<leon-p>
I kinda hope WMs won't get too similar. we don't need twenty dwm clones
<leon-p>
I really want to see unique and experimental ideas
Guest12 has quit [Quit: Client closed]
kotontrion has joined #river
Guest12 has joined #river
Guest12 has quit [Client Quit]
kotontrion has quit [Quit: Quit]
kotontrion has joined #river
alexherbo2 has joined #river
kotontrion has quit [Read error: Connection reset by peer]
angry_vincent has joined #river
<sewn>
why is it impossible to move windows from a monitor to another using only the mouse
<sewn>
the window can't sit inbetween, and only can reach the monitors edges
enova has joined #river
<enova>
Is there any way to create grouping functionality in river like Sway or Hyprland?
<leon-p>
enova: I don't know what you mean by that, but likely no (perhaps in the future)
angry_vincent has quit [Ping timeout: 272 seconds]
<leon-p>
sewn: at first primarily implementation reasons (before the screne graph API, you'd have to manually make the window render at both outputs. I decided to avoid that). Moving a window out of the output bounds without it appearing on the adjacent output would be unexpected, so I decided to straight up not allow moving windows outside output bounds. Also kinda out of principle: I always considered it a UX failure if someone moved a window out of output bounds, s
<leon-p>
o forbidding it also seemed right in that aspect as well
<enova>
leon-p: multiple windows on top of each other, cyclable with a command/action. When they're grouped they act as essentially one window with an extra thing on the top that indicates what windows are there
<leon-p>
enova: ah, makes sense. Yeah that one isn't possible (yet)
<leon-p>
you could fake it, by using cage, but it's not ideal
<enova>
can i pin a window? have it stay on screen across all workspaces/tags
<leon-p>
yes, by asigning it to all tags
<enova>
yeah i just got that working
<enova>
ok thats good
<leon-p>
there are some issues with focus order however, which may make that a bit annoying
<enova>
I was going to ask if you can make it always-on-top
<sewn>
leon-p: this is inconvenient because everyone who still uses a mouse transfer windows using the mouse
<sewn>
I understand this is to make river simpler but in the end it is still inconvenient for the end user
<leon-p>
FWIW since we have the scene graph API now, we have more possibilites in this regard
<leon-p>
also it never was about keeping river simple, it was about me not wanting to spend time writing that code :)
<leon-p>
and it kinda just stuck around, as in no one cared enough to change that
<leon-p>
though restricting windows to output bounds will definitely live on in whatever WM I'll end up writing
<sewn>
there was an issue made but no one had addressed it
<sewn>
or atleast its last comment
<enova>
I also find the restriction on moving windows out-of-bounds kind of annoying but in the default circumstances of river I kind of get it.
<leon-p>
I do think moving between outputs should be possible, but moving a window completely outside of all output geometry just does not make any sense to me
<enova>
however, in Hyprland you can move tiled windows around with the mouse to change how theyre tiled and for that letting the user move the windows out of bounds makes sense because its jarring to have the window stop when you're trying to quickly move it. this functionality seems impossible? move-view toggles the window to floating and keeps it that way sadly
<leon-p>
if you feel the need to do that, it's a good indicator someone good their UI wrong
<enova>
so if you dropped a window out-of-bounds it gets retiled as close to where you dropped it
<enova>
-as
<leon-p>
resizing layouts via pointer is indeed not possible right now
<leon-p>
it will be in the future
<enova>
resizing is not needed, just tiling the window based on where it's let go when moving it
<leon-p>
that should be covered by the WM protocol as well, I think
<enova>
wdym?
<leon-p>
the plan is to move basically all window management to the layout generators, turning them basically into window managers
<leon-p>
that requires a new protocol, which is currently being drafted
<sewn>
leon-p: so is handling input part of the protocol
<sewn>
so resizing windows with mouse is possible
<leon-p>
in a way
Guest39 has joined #river
<sewn>
awesomely
waleee has joined #river
alexherbo2 has quit [Remote host closed the connection]