By simply moving open, save, etc buttons to the right you’ll gain a bit of precious extra vertical space… I doubt anybody would be opening more than 4 or 5 files in a single session. Just my 2c
I’ve put the buttons array back on the left of the layers list. The top open/save/etc… buttons will eventually be replaced by menu entries with shortcuts…
@phweyland I found the problem with your preset: it is the presence of the “&” character in the layer names that breaks the parsing of the preset file. I have to find a fix for this…
Not yet, but I am currently working on the windows package and I will look into that in the next days. Currently my main goal is to prepare a reliable 64-bits win version (the old ones are 32-bits), which might also fix the problem you reported here.
Just tried the today ppa photoflow-git: 20170716 Photoflow stable.txt (44.4 KB)
My last working install has been done on 30/05/2017.
Before installing a new version, I save the entire VM. Is there an quicker way to revert back to the previous PF install ?
Not to my knowledge… maybe @Dariusz_Duma knows a way to revert to an older package version from his PPA?
@phweyland the crash you are reporting looks very much like the same issue I have under windows… and seems to have been introduced by the last update of the RawSpeed library from Darktable.
Could you maybe give the AppImage package a try? You can get the latest one from here (grab the package with the most recent date, 20170702 at the time of writing). I do not have a good internet connection at the moment, so I cannot do any debugging before a couple of weeks…
@Dariusz_Duma would it be possible for you to provide a debugging version of the photoflow-git package in your PPA? The cmake build configuration provides a standard RelWithDebInfo target for this purpose. That would greatly help to debug this kind of issues.
@phweyland if the debug package becomes available, then a GDB backtrace would be really helpful.
@phweyland short update: I think I have found the place where the RawSpeed library sets the target architecture, and how to tell it to compile for a generic one. It seems one needs to set
BINARY_PACKAGE_BUILD=ON
in the cmake configuration (@houz might be able to confirm this) .
Consequently, you should grab the latest AppImage package from today (20170718) if you have the possibility to run some tests, as all the previous ones were most likely compiled with -march=native for the RawSpeed part (and this would explain the illegal instruction crashes you got).