Sooo, specifically you expect sized the same as when the program was last used? Or, sized per a property?
I expect it to automagically guess the exact size of my HD display in order to cover it.
At present, I am forced to manually adjust its borders myself every time I open it.
It is a very minor issue. No big deal indeed
I have just pointed it out because it never occured to me in the past (except with SpatiaLite, another wxWdiget software). Therefore I have supposed it was a “glitch” with this toolkit. Perhaps it is not extremely optimezed on Windows which would be “normal” since, in general, the open source softwares usually are tested extensively by their creators only on Linux.
But again, it is really a minor issue and if rawproc was able to “remember” the last size I have manually adjusted its main window this would indeed fix my report.
Ah, not really wxWidgets, but my choices. I chose to just open rawproc with the same pane sizes from the properties, didn’t give thought to “last remembered”. But it’s not hard, so I’ll look at it for the minor release I’m assembling.
Of particuar note is that the AppImage now includes ALL of the dynamic dependencies; I disabled using the excludelist. If that causes a particular problem, let me know. Also, I am not responsible for melting your machine; use at your own peril.
Of the two problems I reported earlier one is solved and one has changed:
-Solved: I can now build/run rawproc-1.0.1.tar.gz without problems
-The appimage, however, does not run on my box:
[stasis] jade ~ $ ls -l $(which rawproc )
lrwxrwxrwx 1 root root 34 jan 6 19:16 /opt/bin/rawproc -> /opt/rawproc-1.0.1-x86_64.AppImage
[stasis] jade ~ $ rawproc
zenity: relocation error: /lib/x86_64-linux-gnu/libjavascriptcoregtk-4.0.so.18: symbol pthread_attr_init version GLIBC_2.2.5 not defined in file libpthread.so.0 with link time reference
Segmentation fault
I incorporated the first-time configuration/data setup thing yesterday, with some apparently mis-guided confidence in using Zenity for my dialog boxes.
Thanks, then I’ve made a dependency foo in the appimage that your zenity doesn’t like. I’m updating it now to just work with prompt at the command line…
For anyone following the appimage foo, I regenerated the appimage with the excludelist and posted it at about 4:30pm Mountain Standard Time. Not sure what I’m going to do about it…
Just tried the GUIs on Windows 10 and it works fine.
Is there some “manual” related to the syntax (for the CMD prompt)?
In essence let’s suppose I have this previous command:
“.NEF:rawdata=crop” subtract:camera whitebalance:camera demosaic:ahd blackwhitepoint:rgb,data colorspace:camera, assign rotate:180 “tiffs/.tiff:channelformat=16bit”
What about adding a further step that is:
add 1 step (compensation) in the exsposure
I have clumsily tried to mimic your code and I have added this piece of code but it doesn’t work…:
,exposure:compensation:1, #as regards the exposure, apply compensation 1(new code separated by 2 commas)
Oookay now, after a lot of ‘research’, I think I have a better AppImage. The appropriate version of glibc is now included (@Jade_NL, let me know if this works), and the ~/.rawproc population logic is now in a better place and better fleshed-out to support various invocations. Specifically, if ~/.rawproc doesn’t exist, the AppImage will offer to create and populate it with the packaged defaults for rawproc.conf, dcraw.c, camconst.json, and version_2 lensfun database.
@prokoudine, I really don’t have a clue as to why it’s not recognizing your RAFs. I don’t think this new AppImage will fix that, but I’m not giving up thinking about it…