02:17 <leon-p> the rest of the layout article is up now: https://leon_plickat.srht.site/blog/explaining-river-window-layouts/article.html

02:17 <leon-p> elshize: ^

02:21 <elshize> leon-p: nice

02:23 <leon-p> If I can figure out how to do something fun mathematically with layouts, there'll be a follow up article. My guess is commutative ring or group, but that will have to wait till tomorrow, I need some sleep now :D

02:23 <leon-p> night o7

02:54 <ext0l> ifreund: yeah, that makes sense. full damage support is probably what interests me the most but that seems more involved, so... maybe something smaller

02:56 <ext0l> i think idle-inhibit seems doable though!

05:27 <ext0l> (a lot of my desires revolve around cosmetic stuff, but given your [understandable] response to my borders issue that's not what i'm going to work on lol)

07:52 <novakane> add a border-color-urgent that wroks perfectly now :D

08:08 <ifreund> dagle: that's infuriating :/ Maybe we don't need github's bloated way to clone git repositories though. We probably only need a few lines of bash...

08:10 <ifreund> ext0l: yeah, full damage tracking will be quite tricky, I have some hope that the wlroots scene graph API may solve that problem for us though before I get around to solving it myself

08:10 <ifreund> glad you undestand about my current hard stance on cosmetic features

08:11 <ifreund> and idle inhibit would certianly be nice to have!

08:14 <ifreund> leon-p: nice blog post!

08:14 <ifreund> I did see that you'd added more details on the python layout PR but haven't had time to take a look yet

08:14 <ifreund> I think I'll try to give the -repeat PR some much needed attention first

08:17 <novakane> ifreund: any idea on what you want for urgent views?

08:25 <ifreund> novakane: a border color and river-status event so they can show up in status bars would be great

08:26 <ifreund> e.g. add a urgent_tags event to zriver_output_status_1 and bump the version number of all interfaces

08:31 <novakane> ifreund: yeah it's the most useful IMO, what about a focus-urgent always|never|only-when-no-fullscreen as leon-p said?

08:33 <novakane> that's not something I would use but maybe some people want it

08:34 <ext0l> i'd be surprised if people want it, considering how many different things can set themselves urgent

08:37 <novakane> yeah it sounds annoying for me but you never know with what people want :P

08:52 <novakane> anyway I'll do border color and urgent tags, focus could be added later in case, when ifreund got more free time to think about this

09:34 <ifreund> novakane: Maybe we can add something in that direction in the future, I don't think it belongs in the initial PR though

09:34 <ifreund> I personally probably wouldn't use it

10:27 <bfiedler> leon-p: great article! doesn't load on my phone (iOS) for some reason, am I the only one? works fine on a conventional PC

10:32 <dnkl> Works fine on Android/Firefox

11:15 <novakane> in the xdg_activation branch I have `-> wl_display@1.error(wl_display@1, 1, "invalid method 3 (since 4 < 5), object wl_seat@8")`, how do I find where this comes from exactly?

11:16 <emersion> the client needs a more recent version in wl_global_bind for wl_seat

11:17 <novakane> emersion: thanks I'll check this

13:36 <leon-p> bfiedler: Thanks. No idea why it does not load on iOS. Phone browsers are generally pretty weird (and the "mobile mode" Firefox has in the developer options does not come close). I don't have any iOS device, so I can't really test it. Generally I kinda neglect mobile for my own websites.

13:37 <leon-p> on the bright side, it works prefectly in w3m. So if you can have some sort of terminal on your phone (does termux work on iOS?) then you can read it that way :)

13:49 <novakane> ok I think I have everything working for xdg_activation

13:50 <novakane> probably some optimization to do but it looks like everything works as intended

13:57 <dagle> ifreund: Well, checkout@v1 works, but it seems to do it different and I get different errors. I think it's possible but I will look into later when "weird github fuckery" feels funny enough.

14:05 <novakane> leon-p: ah nice you explain true gaps in your article, I really need to take the time to add this to rivercarro

14:06 <novakane> 3rd times I read this artcle, now it is finished at least :P Great article!

14:07 <leon-p> thanks!

14:55 <snakedye> That was a nice read :)

14:55 <nagy135> hi, if i press fullscreen and then run bemenu, it opens up bellow fullscreened view ...on X11 there was this "layer above" thing. Is possible to have this on river/wayland as well?

14:56 <snakedye> Yes, bemenu is probably configured to launch in the Top layer but you should be able to change it to Overlay

15:00 <nagy135> how would I do that? not sure what to look for :X

15:10 <snakedye> The man page or command line arguments

15:45 <leon-p> ifreund: did you not merge the PR making csd filter changes affect already existing windows? because It does not work for me

15:47 <leon-p> ok, it does work, but only for some views

16:18 <ifreund> leon-p: client bug maybe?

16:19 <leon-p> ifreund: perhaps, but river also does not update the border

16:30 <ifreund> leon-p: out bouldering now, if you think river's doing something wrong feel free to open an issue so we don't forget

16:31 <leon-p> sure

18:45 <leon-p> novakane: If I find some time, I'll add urgent view support to river-tag-overlay, that should make testing the PR a bit nicer.

18:46 <leon-p> btw, I haven't seen it in your PR: do you re-send urgent views if a view looses the urgent status? Status trackers need to know.

19:08 <novakane> leon-p: Yeah I thought about adding it to river-tag-overlay but didn't have the time

19:09 <novakane> and no it doesn't resend when views lose their urgency yet, I need need to think about

19:10 <novakane> since I'm not even sure it send the good things for now lol

19:47 <ext0l> leon-p: you wrote an article about river layouts? do you have a link?

19:48 <ifreund> ext0l: https://leon_plickat.srht.site/blog/explaining-river-window-layouts/article.html

19:48 <ifreund> (also can be found in the channel logs linked in the topic)

19:48 <ext0l> ah, ty!

19:54 <leon-p> novakane: river-tag-overlay now has POC urgency support, see the "urgent" branch.

19:56 <leon-p> although I think it will be non-trivial to find out when it should pop up and when not. T

19:56 <leon-p> river-toplevel will make that easier

19:56 <novakane> leon-p: well nice thanks, just when I made a patch for it too :P

19:57 <leon-p> :P

19:57 <leon-p> I rushed it, so you patch may very well be nicer

19:59 <novakane> looks like it almost the same, I just added the command for the urgent color

20:10 <ext0l> https://pastebin.com/dqLyxEb1 uh, gcc... are you okay?

20:20 <ext0l> @ leon-p ^^ gcc 10.3.0 doesn't like river-tag-overlay for some reason; i had to disable -Wmaybe-uninitialized to get it to build

20:22 <leon-p> ext0l: weird. I am using gcc 11.1.0 and that has no problem

20:24 <ext0l> possibly better control flow analysis?

20:25 <novakane> I have 10.2.1 with no problem

20:27 <ext0l> maybe it's something in my setup then, but i have no clue what

20:41 <Nulo> Is there a way to get lid events with seatd? :/

20:59 <ext0l> is it possible to get river to have different xkb options per hardware device? my external keyboard 'natively' outputs colemak, but my internal one needs xkb, and i don't want to have to worry about getting it into some weird 'double colemak' state

20:59 <ifreund> ext0l: not yet, but that's a feature we should have eventually

21:00 <ifreund> Nulo: I don't think seatd has anything to do with lid events

21:00 <leon-p> note that per-{device, window} xkb configs are a bit hacky AFAIK, since xkb options are global per seat per client.

21:01 <ext0l> yeah. i know sway and hikari support it but i have no clue how. not super high priority in any case

21:02 <Nulo> ifreund: I know, I mean by using any other component

21:02 <Nulo> I would use elogind but it randomly broke yay

21:02 <ext0l> wild guess: they swap xkb options based on the most recent input device

21:05 <ifreund> Nulo: river should probably allow you to bind things to lid events

21:05 <ifreund> wlroots exposes them but we don't use them for anything yet

21:05 <ifreund> feel free to open an issue to track it if you like

21:06 <ifreund> ext0l: to figure out how all you need to do is read their source code :P

21:06 <leon-p> ext0l: i am pretty sure that is exactly what sway does

21:07 <emersion> an alternative is to put each device into its own wl_seat, and make all seats follow the same focus

21:08 <emersion> but… not all clients will be happy about it

21:08 <ifreund> lots of broken clients out there yeah :/

21:09 <ifreund> at least when it comes to multi-seat

21:10 <leon-p> while it's not particularly hard, they can get away with not correctly doing multi-seat because it is barely ever used.

23:11 <ino> leon-p hi! I was using a app called lavalauncher but didnt know you made it. its absolutely great! thanks for creating this amazing app :))

23:14 <leon-p> ino: glad you like it!

23:14 <leon-p> although i must say I have neglected lavalauncher a bit this year

23:17 <ino> no problem! i know it is always keep up with open source apps because often there is no money, and developers need to eat and live decent life. i am using lava with river and it lets me use custom background images which is absolutely wonderful :)). it also gave my DE a mac like look '=D

23:18 <ino> *is always hard

23:20 <leon-p> for lavalauncher it's mostly motivation. I have programmed myself into a corner with it. I want to eventually support widgets, meaning items drawn by external clients, but for that I need to first support changing the item list and the widtrh of individual items at runtime. My initial design did not support that at all and I have been very slowly working towards improving it, bit by bit.

23:21 <leon-p> I have a few (quite radical) ideas to improve it though, so maybe next year-ish I can release version 3.0

23:24 <ino> I wish you all the best with this project :) i will love to see the 3.0. and also hope more people will value your hard work.

23:26 <ifreund> you know, with river-toplevel we could probably move float filter client-side if we want

23:26 <ifreund> csd filter as well if we allow setting decoration state through the interface

23:33 <leon-p> ifreund: I had the same idea, but with tag filters

23:34 <leon-p> although for frame perfection we'd need a way for some clients to request some sort of "map lock", where river won't map a view until the client has set the views tags, floating state and csd state

23:35 <ino> will it be possible to add a feature in near future that lets us cycling thru occupied tags? :)

23:36 <leon-p> ino: it should be possible to script that already

23:37 <ino> owww.

23:37 <ifreund> leon-p: yeah, avoiding races for this will be hard :/

23:38 <leon-p> ino you just need to know a language with wayland bindings. clients can already get the currently focused tags and set them as well as know which tags are occupied.

23:38 <leon-p> ifreund: we could let only a single client bind that interface

23:38 <leon-p> and have a small timeout

23:39 <leon-p> river could then ship a small client that supports static rules, like f.e. `riverrules --floating firefox` and leave complex use cases up to user code

23:41 <leon-p> but we can't use toplevel handles for that

23:42 <leon-p> AFAIK they appear /after/ a view is mappde, we need to set rules /before/ it is map

23:42 <leon-p> ed

23:44 <ifreund> does the protocol actually say that? or is that just how we implement it

23:44 <ifreund> I'd like to avoid having multiple ways to do the same thing if at all possible

23:45 <leon-p> agreed

23:45 <ifreund> I don't really have the time to properly explore this design space though atm, I'm just focused on fixing any bugs I can and merging peoples PRs right now

23:46 <leon-p> the protocol does not specifically mention that the view has to be mapped (if I am not missing anything), but clients like task bars do not differentiate between "toplevel handle but not mapped" and "toplevel handle and mapped"

23:46 <leon-p> ifreund: no worries. The idea is good enough that I'll spend a few minutes on it. If I have anything interesting I'll open an issue or PR

23:47 <ifreund> we also shouldn't feel a strong need to tie whatever our solution is to the current wlr-toplevel-management protocol

23:48 <ifreund> though if part of what we develop can be upstreamed to wayland-protocols to improve the cross-compositor compatibility for tools that's great of course