Yep, I put in tooltips, was annoyed by the behavior, so I put in a couple of things:
app.tooltip property, 0 turns it off, 1 turns it on. Set this to 0.
One of the keyboard command recognized by the panes that do tooltips is ‘t’, toggles tooltips on and off.
Sooo, specifically you expect sized the same as when the program was last used? Or, sized per a property? Whatever you expect, I can probably accommodate it, just need to understand the specifics.
Centered zooming was a bit of a challenge as I refactored the display pipeline, I don’t do a lot of vertical images so I’m not surprised at any regression there. I’ll look at it…
I’m organizing my dev workflow now, to support bugfix, minor, and major releases. I think Qt is probably going to be an anchor change in 2.0; however, I’m going to also want to support HDR displays, so that’ll apparently present its own challenge…
Thanks for picking at it Silvio; it’s good to have eyes on these thing past the “one-man-band” hunkering down in the Butcher casa basement…
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…
