00:51 <leon-p> we could do what mutter/gnome does: focusing a window auto-focuses its most recent dialog (if any) and dialog stacking order is defined by creation time and not user changeable

00:51 <leon-p> it's opnionated but IMO works quite well in practice

00:55 <NickH> Is this for the sort of sitution where there is a popup dialog eg to save a file, and then there is second popup eg a confirmation window that is hidden by the first popup?

01:02 <leon-p> I assume so

01:20 <NickH> Ok. I see that sort of thing *very* often when using mainstream gui programs like libreoffice or images editors etc

02:42 <leon-p> arguably it's bad ui design, at the very least the new popup could just re-use the previous ones surface / "window", but that's a lost cause...

04:23 <tiosgz> leon-p: how does the gnome thing work with gimp? (or how would it given focus-follows-cursor)

04:26 <leon-p> you mean those weird floating toolbox windows? They are not dialog windows in the strictest sense. IDK, never tried it

04:28 <leon-p> for focus follows-cursor, it would focus the dialog window when the main window is cursor'd over, without warping

04:28 <leon-p> either way, the obvious solution is for multi-window UIs to die

07:41 <ifreund> there's a new xdg-dialog protocol that just got merged that should allow us to make this more robust

07:42 <ifreund> afaik mutter previously has been using a gtk-shell private protocol for this not the creation time of the windows

09:16 <pinpoxIRC> Heyho, maybe a slightly controversial feature request but would it be possible to implement (optional) window decorations/titlebars in river?

09:16 <pinpoxIRC> Asking because I'd like to have something like sway's tabbed layout. I have tried using stacked, but keep loosing windows

10:04 <leon-p> I'd love that too

10:05 <leon-p> I think maybe we can have that in some iteration of the upcoming WM protocol, perhaps

10:05 <leon-p> some specialied shell to place "decoration" surfaces relative to toplevel surfaces

10:06 <leon-p> keeping it in an external client both makes it a lot more flexible (both design and feature wise) and keeps things like font rendering out of rivers code base

10:06 <leon-p> not sure how well synchronization for interactive resize would work though, since you'd need to wait for two clients to respond

10:07 <leon-p> pinpoxIRC: for now you can try using my version of the stacked layout, where the windows are offset slightly so that you can always see the entire stack

12:37 <ifreund> leon-p: It should actually be pretty easy to support that in the window management protocol and I definitely intend to

12:38 <ifreund> I know how it will work in my head, I won't take the time to write a proper draft until after 0.3.0 though

12:39 <leon-p> looking forward to it :] my next two semesters are just my bachelors thesis and some mild research work, so I'll have plenty of time to play with all of that hopefully