I don’t think running the build without installing it is supported. Why won’t you build a deb file with your changes? You can even use the GitLab CI to do that for you.
1 Like
Multiple reasons. I’m not too much of a fan of these build systems so I always try to keep it as simple as possible and omit whatever I can to lean the process.
In this case millipixels is build after the “ninja” command, hence the only thing I had to do was to figure out where to place the config-file and postprocess-file. Difficult enough, but luckily you could help me out. 
I do not know the ninja build system, but the “install” command if I understand correct will overwrite my version of millipixels installed by default? I would really like this not to be the case, then I could end up with a version not being able to take pictures and it would also not be possible to test multiple versions at the same time when the “hanging-bug” occurs.
With the current setup I can compile “my” version of the millipixels in the cloned git folder and I can therefor have two completely distinct versions. I can make adjustments on the go and compile it on the phone. Takes a couple of seconds and I’m ready to test. No need for Gitlab, no deb-files to be installed, and no overwrites of the mainline apps.
Maybe I missing some smart parts of ninja? but it seems that I have all I need so far.
BTW, one observation I have made is that when the hanging-bug occurred for me last time within the millipixels I’ve compiled, I tried the mainline version and it hang there too. So it seems to be a more “global” problem. But I think that this was already suspected. So maybe no new knowlegde.
1 Like
You can install into a specified prefix and leave the system-wide version intact.
BTW, one observation I have made is that when the hanging-bug occurred for me last time within the millipixels I’ve compiled, I tried the mainline version and it hang there too. So it seems to be a more “global” problem. But I think that this was already suspected. So maybe no new knowlegde.
The hanging problem has been fixed in Millipixels 0.22 released 3 days ago.
3 Likes
Nice, trying it out now.
1 Like
I’ll try to look at that.
Very nice. I’ll still be playing around to integrate our trace event iterator, but I don’t expect it to contribute to anything. However it is a cool case to test it out.
I can confirm that I have experienced one case where the old version hang and the new version could take pictures. 
@dos said: „The hanging problem has been fixed in Millipixels 0.22 released 3 days ago.“
I‘m on 0.21 and I do not get offered this update with sudo apt update, why?
The release was created on May 9, it has to undergo the usual cycle like every updated packet: Come to landing, migrate to Byzantium main. Takes two weeks or so.
note I have compiled it from source myself
You can download the latest artifact from the Millipixels repo and install the .deb files manually.
1 Like
Side fact: Note the latest MR draft in the Millipixels repo. It seems flash is beeing worked on. 
Correct; I do test it as installed into a prefix, but not in any other way.
Something like this: meson -Dprefix=$HOME/projectbin build ?
Or?
Yes, that’s exactly it.
1 Like
Not sure if this is covered anywhere, but one very helpful feature to have would be a small(er) and tiny resolutions. This would make sending pics via slow (or expensive) connections and services more quicker and convenient (no hand editing afterwards).
1 Like
Or such resolution controls within Chats or Geary.
Perhaps you can get multiple resolutions in the postprocess script by using the mogrify command.
Note that iPhone handles this a different way, namely asking you at the time you send whether to scale the image down to a lower resolution copy and send that.
I have tried mogrify on the L5, but unfortunately it is rather processing heavy and, albeit, rather slow in rescaling images.
2 Likes