I think I know whatâs going on. My current setting here is:
ToolPanelsExpanded=1;1;0;0;0;0;1;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;0;1;0;1;0;1;1;1;1;1;1;0;1;1;0;0;0;1;1;1;0;0;0;0;1;0;0;0;0;0;0;0;0;1;
Whenever you introduce or shift a panel this sequence gets changed ⊠thatâs why it looks like it is unstable and unreliable âŠ
Did you untick the Automatically save ... checkbox in preferences, @agriggio mentioned in his comment?
of course, but I think my idea is right. If you Introduce a new 1st tool, then all other already existing tools are shifted by one place. So the wrong tools get opened âŠ
TestingâŠ
Still can not reproduce. I must miss some thing 
if you run on the bleeding edge, you have to accept the risk of getting cut 
That I donât have a problem with. 
Well, I tried again. I closed all tool panels. Then I clicked the button
And nothing got saved 
I tried it again and figured out, that ânowâ does not mean now. It means you also have to click the okay button in addition
Then it was still not okay. The wavelet tool insists in staying open âŠ
I will try tomorrow with installing the 5.3 and save the settings there and then try again with 5.4-rc2 âŠ
Confirmed
this looks like a bug, thanks for spotting 
well it would be weird if you clicked on âcancelâ and the options got saved anyway, wouldnât it?
IMHO, no! The text says save Now, it does not say ânow after clicking okay alsoâ But I know, that all the other options are saved on âokayâ. So may be that is just personal taste
Now I did more testing with the ToolPanelsExpanded.
I reinstalled the official 5.3 in an empty folder. I manually removed the line ToolPanelsExpanded from the options file using Notepad++. Then I run RawTherapee and enabled just the following tool panels (if i closed one, I did not care for subtools): Exposure, Retinex, Sharpening, Noise Reduction, White Balance, Film Simulation, Crop, Lens/Geometry, Rotate, Sensor with Bayer Matrix, Demosaicing.
This resulted in
ToolPanelsExpanded=1;1;0;0;0;0;1;0;0;0;1;0;0;0;1;0;0;0;0;0;1;0;0;0;1;0;1;1;1;0;0;0;0;0;0;1;1;0;0;0;1;1;1;0;0;0;0;1;1;1;1;1;1;1;1;1;1;
Now I reinstalled 5.4-rc2 into the same folder und run it. Now the following tool panels are open: Exposure, ToneMapping, Sharpening, Contrast by Detail Levels, White Balance, HSV Equalizer, Color Management, CIE Color Appearance Model 2002, Wavelet Levels (as already said this one insists in being open), Crop, Resize, Post Resize Sharpening, Dark Frame, Flat Field.
I changed the settings the way it was in 5.3 and saved.
This resulted in
ToolPanelsExpanded=1;1;0;0;0;0;1;0;0;0;0;1;0;0;0;0;1;0;0;0;0;0;1;0;0;0;1;0;1;1;1;0;0;0;0;0;0;1;1;0;0;0;1;0;0;0;0;0;0;1;1;1;1;1;1;1;1;1;1;
I do not agree non this statement. Well I did something similar like upgrading from 5.3 to 5.4 and I expect that my settings are kept. The new settings may of course have some default setting. If this would have been a real dev version, then may be okay⊠thatâs way I didnât say anything before
sorry I didnât understand this was the case. I agree that upgrading from official releases should work
Be aware that for the W64 builds:
%LOCALAPPDATA%\rawtherapee
%LOCALAPPDATA%\rawtherape5-dev as for development bulds.@Morgan_Hardwood shouldânt be better to locate the release candidates config folders in ..\rawtherapee?
@gaaned92 release candidates are not stable releases, they are meant for testing, not for production use, so Iâm inclined to say ânoâ.
According to RawPedia I can use an environment setting
RT_SETTINGS= LOCALAPPDATA\RawTherapee
which I did a long time ago.
In my opinion this still works as the correct path is used âŠ
Concerning LTO: This is not RTâs but binutilsâ fault. CMake uses stock /usr/bin/{ar,ranlib} and those donât use the LTO plugin, so the relevant sections get lost. To compile with LTO, employ these CMake arguments:
-DWITH_LTO=ON -DCMAKE_AR=/usr/bin/gcc-ar -DCMAKE_RANLIB=/usr/bin/gcc-ranlib
@Morgan_Hardwood We could add this to the CMake logic or should at least document it. Adding it to CMakeLists.txt would make LTO GCC specific (but is that a problem?).
HTH,
Flössie
@floessie does that apply to MSYS2 only?
I just compiled dev with -DWITH_LTO="ON" in Sabayon and it worked (for the first time ever)!
sys-devel/binutils-2.29.1-r1
sys-devel/gcc-6.4.0-r1
dev-util/cmake-3.10.2
What will LTO make faster in RT?
I read that newer binutils pick up the LTO plugin correctly, so that might already be the case with your setup. Iâm not referring to MSYS2 (Iâm Linux only).
Hm, we had a LTO vs. non-LTO shootout in a GitHub issue years ago, and LTO was some percent faster. This is mostly due to better inlining and de-virtualization at link time, I guess. This does not compete with Ingoâs optimization, but adds some speed-up on top.
@floessie something like this?
diff --git a/CMakeLists.txt b/CMakeLists.txt
index cb45c573..f73cf77b 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -334,6 +334,16 @@ if(WITH_MYFILE_MMAP)
endif()
if(WITH_LTO)
+ # Using LTO with older versions of binutils requires setting extra flags
+ SET(BINUTILS_VERSION_MININUM "2.29")
+ execute_process(COMMAND ar --version OUTPUT_VARIABLE BINUTILS_VERSION_DETECTED)
+ string(REGEX REPLACE ".* ([0-9.]+)\n.*" "\\1" BINUTILS_VERSION_DETECTED "${BINUTILS_VERSION_DETECTED}")
+ if("${BINUTILS_VERSION_DETECTED}" VERSION_LESS "${BINUTILS_VERSION_MININUM}")
+ SET(CMAKE_AR "/usr/bin/gcc-ar")
+ SET(CMAKE_RANLIB "/usr/bin/gcc-ranlib")
+ message(STATUS "Binutils version detected as less than " ${BINUTILS_VERSION_MININUM} " - setting CMake parameters to enable LTO linking:\n CMAKE_AR=\"" ${CMAKE_AR} "\"\n CMAKE_RANLIB=\"" ${CMAKE_RANLIB} "\"")
+ endif()
+
SET(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -flto")
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -flto")
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -flto")