00:51 <mfxarc-> Hey folks, I'd like to contribute to River, but I don't even know how to start, do you have any tips of what to do?

01:17 <snakedye88> Uploaded file: https://uploads.kiwiirc.com/files/494037a1c83247a9370e31a393c281d1/swappy-20210928_211139.png

01:17 <snakedye88> more clones :)

07:12 <novakane> is the title of the focused view send by river-status is the same as the title send by the foreign-toplevel-management protocol?

07:14 <novakane> because as far as I can tell you can't have the focused view with the toplevel protocol so I could compare the title of both to see which one is the focused toplevel in all toplevels

07:20 <leon-p> novakane: it should be the same. The foreiggn toplevel protocol does show you which toplevel is focused, it's just called "activated". Careful: Technically mulitple toplevels can be activated at once, but not currently as river does not yet implement multiple seats. Just something to look out for in the future

07:22 <novakane> leon-p: oh thanks I didn't understood activated was this, it's better then

07:30 <novakane> leon-p: btw why you don't use display_roundtrip in river-tags-overlay? How is it possible?

07:31 <leon-p> novakane: Instead of calling roundtrip, I use sync. I personally find it a bit nicer.

07:31 <leon-p> nicer because it allows you to stay in the main event loop all the time and enter it faster during startup.

07:32 <leon-p> that makes exiting on failure a bit cleaner

07:34 <novakane> leon-p: allright, thanks for the explanation!

07:38 <leon-p> it's also worth considering if you have multiple event sources. If you send a Wayland request, there could be some other message coming in before the Wayland response. If you roundtrip, you first wait for the Wayland response and handle that before handling the other message. If you sync and fall back to the main event loop, it's first come first served, which can be faster.

07:41 <novakane> hmm I see that's interesting, I need to look more at it, thanks

12:29 <novakane> does it makes more sense to use [2]Buffer or std.Tailqueue(Buffer) for current/pending buffers?

12:34 <leon-p> novakane: depends on how many buffers should be able to exist simultaneously. In my projects I only allow two, because it is usually enough. More might be handy when you are rendering more often, like f.e. with animations and want better frame timing.

12:36 <novakane> leon-p: hmm ok I'm trying to investigate why the square colors doesn't update, I use Tailqueue which looks like it works fine but maybe I'm rendering on the wrong buffer

12:37 <novakane> although it could be totally not related to this lol

12:46 <snakedye> Do you do double buffering?

12:49 <novakane> yeah or at least it should if I didn't fucked up

12:56 <snakedye> Can you show WAYLAND_DEBUG?

12:58 <snakedye> Also kinda unrelated but how do you destroy or hide the surface on timeout? I spawn an os threads on each focused tag event but I imagine async would be better.

13:00 <novakane> snakedye: https://paste.sr.ht/~novakane/728a0a387f0697114a70ae39997d1fae17e682e0

13:22 <novakane> without toplevel so its more clear https://paste.sr.ht/~novakane/ceb64c70e467123bcd8db3a1d992776aaec56bab

13:27 <ecocode_> hmm.. how can I find the app-id of an application ?

13:28 <novakane> ecocode_: https://git.sr.ht/~leon_plickat/lswt

13:31 <ecocode_> @novakane thx !

14:04 <snakedye> novakane: the last 2 focus events cause a draw on the same buffer

14:05 <novakane> oh right thanks, then I guess my function to chose the buffer is wrong

14:14 <dnkl> Heads up (will post bug later); moving a fullscreened toplevel to another output (send-to-output) doesn't resize the window.

14:17 <ifreund> indeed, that shouldn't be too hard to fix though

14:19 <dnkl> ifreund: we're you able to reproduce? Or would you still like me to include debug logs in the bug report? (Will be a couple of hours before I can open it...)

14:26 <ifreund> dnkl: I was able to reproduce yeah, so just an issue to track it is all we need