00:08 <tleydxdy[m]> hmm the vulkan extension needed requires hardware support?

07:15 <pinpoxIRC> how do you people get the app-id of specific window? Keep finding answers related to swaymsg, but not sure how to do it on river

07:15 <pinpoxIRC> I want to create rules for a tiny window that should not be tiled

07:19 <angry_vincent> there is lwst

07:19 <angry_vincent> https://git.sr.ht/~leon_plickat/lswt

07:22 <pinpoxIRC> angry_vincent: perfect, thanks

07:25 <pinpoxIRC> @NeckerPaddler: I'm using river-luatile from nixpkgs. In fact, I have packaged it recently there but it has not yet reached the unstable channel I think. Should be accessible as soon as unstable advances

07:25 <pinpoxIRC> Oh seems he is not here anymore

09:10 <pinpoxIRC> Is there any way to get `focus-follows-cursor` to work per-output? Use-case: I have some outputs tiled, some outputs with a stacktile-like layout. focus-follows-cursor is handy on tiles, but not very usable on stacktile layouts

13:23 <NeckarPaddler> pinpoxIRC I've read the recent log, I've gotten luatile by now. I'm back working today, but I'll dig into it later. It looks like it makes my horrible fullscreen-hack yesterday obsolete (by making fullscreen itself obsolete for my usecase). Thanks for packaging!

14:08 <pinpoxIRC> NeckarPaddler: In case you are interested, this is my layout.lua https://github.com/pinpox/nixos/blob/wayland/home-manager/modules/river/layout.lua It has two layouts: tiled (simplified rivertile version) and stacked (copied from stacktile) that you can cycle through on per-screen basis

14:08 <pinpoxIRC> Still playing around with it though, might change in the future

14:33 <NeckarPaddler> Thanks, I'll look at it. My plan is instead of multiple layouts to tile up to 4 windows. 5 or more will just maximize all windows.

14:38 <pinpoxIRC> Thats also nice. I tought about tiling up to a certain number, then putting the rest of them behind the last one. Would be interested to see if you come up with something cool. I went for stacked instead of fullscreen because I kept forgetting what windows are behind the current one in fullscreen. Credits to leon-p for the idea

14:39 <pinpoxIRC> A taskbar with all the windows seems to be not possible currently

14:53 <NeckarPaddler> A taskbar isn't something I'd personally want anyway. :D

14:54 <NeckarPaddler> What is the difference between stacked and fullscreen?

14:56 <NeckarPaddler> (I assume we don't destinguish fullscreen and maximized in the context of coming up with layouts)

15:22 <ifreund> NeckarPaddler: fullscreen is part of the xdg-shell protocol and is communicated to clients

15:23 <ifreund> some clients (e.g. firefox) may change appearance while fullscreen

15:26 <NeckarPaddler> Thats why I said "maximize" above. And why I am confused about what "fullscreen" means in the context of luatile.

15:33 <leon-p> the term "maximize" is also already taken by the xdg-shell, although we don't implement that feature

15:33 <ifreund> NeckarPaddler: fullscreen and maximized are two separate states in the protocol

15:34 <ifreund> river intentionally doesn't support maximize or minimize requests

15:34 <leon-p> yeah, it's unfortunate something so desktop specific managed to sneak its way into xdg-shell

15:34 <ifreund> they only really make sense in a more traditional desktop paradigm

15:35 <ifreund> leon-p: we have wm_capabilites though now, which is nice

15:35 <leon-p> oh, did that land already? nice!

15:35 <NeckarPaddler> Oh ok. s/maximize/"sized to the whole screen by the layout manager"/ then

15:36 <leon-p> s/manager/generator, to be super nit-picky, but yes

15:40 <NeckarPaddler> BTW, I love rivers modularity. Guess how often I messed up my Lua code in the last hour (this is my first day with lua) and set the output layout to rivertile until I got luatile back running properly.

15:41 <leon-p> you can also use it completely without any layout running, a basic floating window management mode is supported

15:42 <NeckarPaddler> I'm aware, but I need to be able to find my manpages, lua tutorials and vim instances somehow xD

15:42 <ifreund> yeah, one of my major goals with river it to make experimenting with window management ideas as easy as possible

15:43 <ifreund> maybe I'll get my lispy hot code swapping pipe dream working someday xD

15:44 <leon-p> I have a list with about ~40 things to try once layout generators have more power :)

15:44 <leon-p> like dynamic tags where focus is decided by AND, OR, NOT rules

15:45 <ifreund> I gotta fix all the bugs and release 0.3.0 before I can seriously get to work on that

15:46 <leon-p> I gotta finish my exams and lab reports before I can do anything anyway, so it's fine :)

15:46 <ifreund> all the refactoring work thats happening between 0.2.0 and 0.3.0 is stuff we need for the more flexible protocol ideas as well, so no time is being wasted

15:48 <leon-p> refactoring is rarely wasted time. quality needs time.

16:08 <NeckarPaddler> Yeah, it worked! I kinda recreated rivertile, but it switches to monocle (is that the correct word now?) when there are too many windows to tile and they would become to small :)

16:09 <NeckarPaddler> *the luatile creator recreated rivertile and I put an if else in front of it if I'm being honest...

16:46 <leon-p> huh, am I missing something or doess wlroots not allow to hook into the get_activation_token request?

16:46 <leon-p> was just looking at assigning tags to clients based on what tags were active when the token was granted

16:54 <ifreund> leon-p: I don't think that's how the protocol works? Can't a client pass the token to another client instead of using it itself?

16:55 <leon-p> yes

16:55 <leon-p> but the launching program could be f.e. fuzzel

16:55 <leon-p> or maybe even river itself

16:56 <leon-p> and I want programs that are slow to map their views to stay on the tags I launched them, even if I switch to another one in the mean time

16:56 <ifreund> I think the only point at which one could make any inference about the tags would be when a not yet displayed client is activates a token

16:56 <ifreund> oh, I think I see what you mean

16:56 <leon-p> true, I am just hoping most clients activate first, then map

16:59 <leon-p> at least it should be do-able from a spawn command by manually creating a token and inserting it. Probably even possible to encode the tag-info in the token string so no extra struct is needed

17:03 <leon-p> anyway, off to a magic round now, will be back later

19:43 <plumeus> Is there a way to check what the focused tags are in River?

19:43 <plumeus> I see https://github.com/riverwm/river/blob/master/protocol/river-layout-v3.xml#L193

19:44 <plumeus> I have no idea how Wayland protocols work and how to communicate with them, however. I guess I could peek the riverctl source code for stuff like set-focused-tags

20:00 <maxxv> river crashed when I clicked on telegram's title bar, but I couldn't reproduce it anymore: https://paste.rs/yKY

20:06 <maxxv> plumeus: check out ristate - https://gitlab.com/snakedye/ristate

20:08 <plumeus> I wondered if there's a general method that works with any Wayland protocol. Although I don't precisely know what I'm trying to do.

20:10 <maxxv> plumeus: wayland does not have a notion of "tags", although there is an attempt to create a protocol extension that is compositor agnostic: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/40

20:10 <plumeus> I mean, a general way to communicate with protocols.

20:11 <plumeus> or more like, how protocols work

20:14 <maxxv> I'm not sure I understand you. The general way to communicate with protocols is to write a program which... does what you want it to do.

20:16 <maxxv> If you want to learn more about wayland and how protocols work, you can look into https://wayland-book.com/

20:16 <plumeus> I guess I was looking for something like https://wayland-book.com/protocol-design/wire-protocol.html, seems like I could use this

20:16 <plumeus> yeah, thanks. The book seems nice.

23:40 <leon-p> plumeus: for getting tags you want river-status, not river-layout