08:50 <novakane> so I make removing border works, but now I need to add it back when there is more than one window

08:50 <novakane> is there a way to get the border-size from the config?

09:09 <ifreund> novakane: no, I'd probably implement that as a CLI arg for your layout generator

09:13 <novakane> ifreund: thanks, I'll try that

09:15 <novakane> I'm gonna try with a hard coded border size before I think, to see how well it works

13:43 <ifreund> urgh, we get a crash on output destroy with the cursor fix

13:49 <leon-p> huh, I actually saw the segfault in the terminal, I just assumed it was some client that couldn't handle a sudden connection loss...

13:52 <ifreund> I also found another bug when I went to remove the checks blocking toggling e.g. fullscreen for a view currently being moved

13:52 <ifreund> I've got a fix in the pipeline though

13:53 <ifreund> also decided to take some time today to improve the consistency of the rendering code

14:24 <novakane> ifreund: why the -version flag should be a build option?

14:25 <ifreund> novakane: we shouldn't expose it as a zig build -Dfoo flag, but it should be defined in a single place in the build.zig

14:25 <ifreund> does that clear things up?

14:27 <novakane> oh ok yeah, like just the function would be in build.zig but that's not intended for a user interaction

14:27 <ifreund> yep

14:29 <novakane> I was confused when I saw build options I thought you want a flag to build river to a specific version

14:30 <ifreund> I was just talking about the @import("build_options") thing

14:31 <novakane> yeah makes sense now

14:35 <ifreund> pushed out some refactoring that should thoretically fix things but who knows if I screwed it up :D

14:35 <ifreund> won't fix that crash the cursor reset state thing introduced yet

14:35 <ifreund> I got sidetracked when I saw other wrong stuff

14:38 <leon-p> ifreund: "including the git commit hash in dev versions would be nice" if done wrong can break if river is distributed. In LavaLauncher, I currently have a check that if the build is done in a git repo, the commit hash is used as version, otherwise a predefined string, which I thought would work because packagers ususally download release tarballs, but in reality breaks because some packaging systems

14:38 <leon-p> unfortunately have the build-root inside the git repo of the package build script.

14:42 <leon-p> and it breaks in a very unfortunate way: it shows the git commit has of the repo the build script is in, not the project repo

14:42 <leon-p> So maybe instead of automatically detecting it, we should have a `release: bool` variable in build.zig?

14:46 <ifreund> hmm, yeah that doesn't sound good

14:47 <ifreund> I just realized that our pointer constraints implementation is flawed though so I'm going to go fix that real quick

14:59 <novakane> zig use the commit hash in `zig version` command though so it should be possible no?

14:59 <ifreund> anything's possible

14:59 <ifreund> and yeah, looking at the build.zig for zig itself might be a good place to start

15:02 <novakane> yeah that what I was reading, I guess we could make something similar and see if everything break or not :P

15:04 <ifreund> copying blindly isn't going to get us very far

15:06 <novakane> hmm there is another way to write code? :P

15:09 <ifreund> ok, I'm not fixing pointer constraints today, I don't care enough about it :D

15:09 <ifreund> I opened an issue though

15:40 <novakane> so I'm trying river -version, wouldn't it makes sens to use '-v' for consistancy?

15:50 <ifreund> novakane: I think I want -help and -version for everything, removing any inconsistencies that currently exist

15:50 <ifreund> no more bare -h

15:50 <ifreund> but we should always print the usage string on an unrecognized argument

15:51 <novakane> ifreund: what about -l and -c?

15:52 <ifreund> -c should stay as-is for sure

15:53 <ifreund> I've been considering exposing fewer log levels (only debug, info, warn, error) so the argument of -l might change. -log-level wouldn't hurt either

15:53 <ifreund> -c is consistent with sh -c which I like

15:54 <novakane> allright, well that's could be change after, anyway I kinda make it works like zig version, though I'm not sure git hash works without a first tags

15:59 <ifreund> git rev-parse HEAD

16:00 <ifreund> or git rev-parse --short HEAD

16:01 <leon-p> if we have the hash in the version string, we probably also want the branch

16:01 <ifreund> branch doesn't matter

16:02 <ifreund> branches are literally just names for a specific hash

16:02 <leon-p> git rev-parse true, but it makes it possible to see from what branch a binary was build without having to look at the repo

16:02 <leon-p> oops, I mixed a command and a message :P

16:03 <ifreund> the branch doesn't matter though, only the commit hash does

16:03 <ifreund> even if you can see that they built from whatever their branch called master was, it could be a wildly different commit that the current head of your master

16:04 <novakane> ifreund: what I mean is zig use git describe, and use an ancestor tags variable, so currently like that without a 0.1.0 release it only display 0.1.0 but after the release it should display 0.1.0-dev.xxxx

16:05 <ifreund> git describe won't work without any tags

16:05 <ifreund> git rev-parse --short HEAD is far simpler too

16:05 <ifreund> just hardcode the version in a constant in the build.zig, far simpler than parsing git describe output

16:05 <leon-p> ifreund: actually my proposal was a bit more selfish than knowing what version other people use. I want to know from what branch _I_ build :D But I agree it isn't strictly necessary

16:06 <emersion> note, tarballs don't have .git

16:07 <leon-p> not only that, but depending on how a distribution builds packages, the tarball might be downloaded into a git repo and the git command will pick up that repository

16:07 <emersion> eh, fun

16:07 <ifreund> so what, we check for .git in the build root?

16:08 <emersion> GIT_WORK_TREE might come in handy

16:10 <leon-p> or we just have a `release: bool = true;` in build.zig.

16:10 <leon-p> anyway, brb, gotta walk the dog

16:13 <ifreund> emersion: thanks for th tip

16:14 <ifreund> novakane: looks like passing --git-dir and --work-tree arguments to git will be foolproof

16:15 <ifreund> git --git-dir $BUILD_ROOT/.git --work-tree $BUILD_ROOT rev-parse --short HEAD

16:15 <ifreund> where $BUILD_ROOT is b.build_root in our build.zig

16:23 <novakane> allright I'll use rev-parse then

17:07 <ifreund> leon-p: found and fixed that crash by the way, it was destruction order of course

17:18 <novakane> so hmm how should I format this so the git command works https://zigbin.io/517788

17:19 <novakane> like this there is space between b.build_root and '/.git' if I understand correctly

17:20 <ifreund> novakane: yeah, you'd need to pass them a single argument there

17:20 <ifreund> see std.path.join

17:22 <novakane> thanks I'll look into it

17:23 <ifreund> alright, I think I'm done for the day. Feeling a lot better about the cursor and rendering code now

17:24 <ifreund> pointer constraints are still incomplete and there's that issue with super high dpi mice as we use integers for view location not f64s

17:25 <ifreund> but overall it feels a lot more solid

17:25 <ifreund> maybe I should fix that DPI thing though, it would be cool to release river 0.1.0 with 0 known bugs

17:25 <ifreund> well, aside from xwayland BS that is

17:26 <ifreund> but I consider perfect xwayland support out of scope

17:26 <ifreund> and nobodies reported any issues with it in a while somehow

17:32 <leon-p> ifreund: do you have a high-dpi mouse to test the code?

17:32 <ifreund> nope :D

17:33 <leon-p> well I have one, I just would not know how to approach this :D Also I could never reproduce...

17:33 <ifreund> but I can see why our current approach might be problematic

17:34 <ifreund> if the delta motion of pointer events causes the moving/resizing view to move less than a pixel we effectively round that down to 0 movement

17:35 <leon-p> Ah, makes sense

17:35 <ifreund> and so if your mouse sends a lot of really tiny delta events, it won't move the view at all

17:35 <ifreund> anyhow, I'm off for the day and probably won't have much if any time for river tomorrow, if you want to work on it feel free to give it a shot

17:36 <leon-p> I'll have a look

17:36 <ifreund> :)

17:46 <novakane> ifreund: what do you think? https://zigbin.io/cc0eb1

17:49 <leon-p> novakane: is there a reason the version string isn't just a hardcoded []u8 ß

17:50 <novakane> no you're right that's was for the first version based on zig itself

18:01 <leon-p> novakane: what do you think about https://zigbin.io/62c1c6 ?

18:03 <leon-p> with os.access you can check if .git exists before calling the git command

18:06 <leon-p> actually, b.execAllowFail() in my example should not be try'd, but rather `catch return b.fmt("{s}-dev", version);`

18:06 <leon-p> it is certainly possible that .git exists, but the git command is not available, in which case we should still have `-dev` in the version string

18:07 <novakane> yeah it look good, it make it more safe

18:08 <novakane> though how you would have .git without git command since you need to init the submodules

18:09 <leon-p> that's a good point

18:10 <leon-p> huh, how do distributions build projects using submodules when the policy usually is to download release tarballs instead of cloning repos?

18:12 <novakane> no idea

19:06 <leon-p> ifreund: one of your recent commits re-introduced the bug that caused me to work on cursor state resetting :D

19:07 <leon-p> the cursor image once again only updates when the pointer is moved