06:20 <NickH> I'm having a problem reading/unpacking data from view_tags in python. The tag data for each view seems to only have the first 8 bits.

06:21 <NickH> I don't suppose anyone here has python code that correctly reads this?

06:47 <LarstiQ> NickH: I haven't tried. Do you have it available for a look somewhere?

07:00 <NickH> LarstiQ: I think I've worked out what is going on.

07:01 <NickH> The way I'm unpacking the tag data for each view seems to end up in 4 adjacent 8 bit uints, instead of a single 32 bit uint

07:01 <LarstiQ> sound plausible. struct.unpack?

07:02 <NickH> No, just a dumb loop. See https://github.com/NickHastings/riverwm-utils/blob/feature-skip-empty/riverwm_utils/riverwm_utils.py#L245-L252

07:03 <NickH> I did start looking at struct.unpack, but wasn't able to get it to work.

07:03 <NickH> Now that I under stand what is happening I should be able to work out how to fix it.

08:22 <NickH> Managed to get it working with struct.unpack 😀

08:22 <NickH> LarstiQ: thanks for prompting that the struct.unpack approach was approriate

08:56 <LarstiQ> NickH: np, glad to be of help :)

09:22 <ThatGuestAgain> Hi. With 0.3.0 I've adapted my configs and workflow. Before, I've rarely resized with the keyboard (riverctl resize horizontal/vertical n)and now I resize all the time.

09:22 <ThatGuestAgain> Unfortunately, it seems a bit quirky. Shrinking and growing a window a few times lets it drift left/up, and growing it to the maximum works horizontally, but leaves a gap at the bottom vertically. My keymapping regarding resizing is as the example init says, just different modifiers. Can I fix that or is it an issue within river?

09:24 <ThatGuestAgain> I just realized the drift is app-dependent. Foot goes left and up, qb down and right. I am so confused.

14:41 <leon-p> ThatGuestAgain: likely a bug in the code that centers the view on resize, since it probably assumes the new size instead of using the actual commited buffer size

14:42 <leon-p> arguably not worth fixing before the WM protocol IMO