Yaaay great idea !
However, I do a lot of film scan using my Nikon D700 and there are some things to be done before that module position because it should be placed after all the camera corrections and matrix. 
hmm so just place negative after the colour module. maybe i should update the docs accordingly. didn’t think very deeply about this to tell the truth. just fiddling with my one single example image this seemed to make sense, but maybe it doesn’t. i wanted to have the exposure + messing with colours controls after the inversion. might require two instances of colour.
please be accurate. will definitely not implement all the many ways dt has to achieve the same. in particular not if it’s about gui dialogs. (selective copy can be achieved by a temporary preset, has very similar ui to select history entries)
an update will not write to the version in your home, which takes preceedence.
i disagree. on the other hand doing fs_copy in code behind a button instead of copying your example .cfg to the default.<input module> config files isn’t introducing a whole lot of ui complexity and clutter.
now that would be overwriting your stuff upon update. i see how it will make the place of config files more obvious, but the solution doesn’t seem so easy.
i think i agree here.
shows it where? under the histogram or in the metadat expander? there are three sources of common metadata: rawspeed (black/white/matrix), exiv2 (orientation, shutterspeed etc, dng matrices), and exiftool (configurable metadata expander).
You’re the driver. I only provide some (quite subjective) feedback here…
IMHO you don’t need to. I also think that dt’s UI is overly complicated in some aspects. Yet having an opportunity to do things with clear and convenient UI is a big advantage.
Won’t checking the mtime do the trick?
Both. After the last update vkdt seems to pick up the metadata properly. If I get the history shown and press “reset” button the orientation gets right now. I think it is solved.
Thanks!
now instead of 200k font file, this requires a 4.4MB one (and that’s not a complete set for all languages). since including this would triple the release tarball size i don’t think i’ll include it. might code my way around it so it works in theory and make the loaded font a config option, along with the obligation of the user to actually download it.
Wouldn’t it be simpler to provide opportunity to pick up fonts that are already in the system and leave builtin fonts as a backup?
try this. pull, build, and in your ~/.config/vkdt/config.rc set
strgui/font:NotoSansJP-Regular.otf
or something similar (otf or ttf). if the filename after the : starts with a /, it’ll be interpreted as an absolute filename (see /usr/share/fonts/truetype/…). if not, it’ll look in the vkdt data/ directory. if the file doesn’t exist, it probably just crashes 
startup times suffer notably when loading a large font. certainly don’t want to make this a default for everybody.
It’s Roboto-Medium.ttf Tried other .ttf font with the same result…
And, I still can’t understand how to exit gracefully. vkdt still truncates config.rc to 0 upon exit.
I also see
corrupted double-linked list
message…
these need to be at least 4MB of size or else they will not contain your charset. for instance enter something esoteric here: Roboto - Google Fonts
make clean ?
hm. mine works, doesn’t speak japanese though:
had to download a specific character set of roboto and point vkdt to that file though.
this is the line in my config.rc
strgui/font:/tmp/Roboto-Regular.ttf
and got the ttf from here.
exit: ctrl-x or nowadays also the callback from your window manager should be followed.
Probably copy/pasted path introduced something unprintable somehow?? Or it’s a bug in parsing the string?? The file contained strgui/font:^R4^? upon closing. The manually typed-in path worked fine, but not every time. Tried few times, results are mixed bag. Weird.
Me neiter 
Also, Ctrl+x does not stop vkdt properly, either. Well, not every time:
$❯ pgrep vkdt
13256
…truncating config.rc to 0 again.
I’m not sure which signal Compiz sends on Alt+F4, and can not look because it seems that if I start vkdt from a command line, it does not stop it properly at all, so echo $? gives 0 all the time. You don’t process SIGTERM/SIGHUP, do you?
okay i think the main problem is actually the shutting down thing. i am catching abort/segfault, but not term. maybe i’ll have to do something more with glfwWindowShouldClose() to make compiz happy.
2 Likes
(@hanatos, slap me if I mis-state)…
vkdt is firstly about a radical change to the pixelpipe. It’s all in the GPU from ingest to export, and it’s crazy fast. No need for threading or tiling shenanigans; really, I think only needs one core to manage the data and shaders in the GPU. And, @hanatos knows well the darktable scene-referred ordering, and the current default network of operations reflects that.
Really, the current UI is just about presenting this concept. Took me a bit to figure it out, but I really don’t mind it. Again, I wanted at that pixelpipe, so whatever, UI…
One of the things I’m considering doing with my new-found time is poking around at a more-encompassing UI. Yeah, probably Qt/whateverversion, needs to do the basics like localization and language support, but I’m thinking it should look/work like rawproc… 
1 Like
hah, yeah that probably describes my approach this time around. for darktable it was the opposite: i started with a cannibalised libufraw0.so (never mind the processing, i want a combined user interface …).
bloatware 
but yes, should be relatively straight forward to compile vkdt into a library. basically the command line interface does this, but without the library part (just compiles everything in). at least i could then always point to you if i get user interface feature requests 
3 Likes
I don’t see users asking for a UI/UX anytime soon
Oh wait !
1 Like
Oh, and I’m still finding most sliders too sensitive
1 Like
…and the mouse wheel is idle…