Hello there,
I was wondering, is there any reason these are not check boxes for each kind of correction instead of a list of all possible combinations?
Everytime I want to disable vignetting correction, I have to look at the entire list and find the correct combination that only disables vignetting correction, whereas with check boxes I would only have to uncheck that single box.
But it looks like now it’s a drop-down list with selections. That is a single input object, which handles the dropdown and makes it easy to get the result (basically, all the logic comes with the list). With a group of check boxes, there’s a lot more coding to be done to get equivalent behaviour. Only worth it when it can be reused several times…
Given the limited amount of space, keeping the required checkboxes visible all the time doesn’t seem a realistic option.
Unfortunately, I don’t know if it’s possible to define a preset which takes the camera and lens parameters from the metadata, and allows to set the other parameters.
I don’t know the back end, so I might be wrong, but given my knowledge of coding, it would probably be easier, code wise, to use check boxes, as I would think that would map one to one to the parameters of the lensfun library.
I’m also not sure what you mean by
Only worth it when it can be reused several times…
The exact same set of check boxes would obviously only be used in that module, but it’s not as if the concept of check boxes is unknown in the Darktable GUI.
And I don’t think the amount of space needed would be that much more: the list and the verbose “corrections done: …” could then be removed, freeing up 2 lines in the module. I’m also not sure the “correction method” drop down list would still be needed, arguably freeing up one more line. And perhaps the options could be arranged in two columns, but I believe there are 3 types of corrections, so that look weird.
But that means the module would have to be at most 1 line higher than it is now.
As for your last point: that is a very good point, Darktable could really use partial presets, but it would not really be a solution: I would need to create a couple of “everything but …”-presets, making things even more confusing 
If I were you I’d make a preset with the selection I wanted.
Quite sure that’s impossible: a preset will also store the specific lens and settings, but let’s try it.
Yep, it does, so I would have to store a preset for every setting of every lens I use I’d rather browse through the list of correction methods.
Like I said: Darktable could really use partial presets, but as far as I know, those are impossible for now.
Also, I’m just genuinely curious about the design decision. Check boxes are invented for exactly these kind of situations, where you might want to turn on or off specific options.
A list of all possible combinations grows almost exponentially (factorially? is that a word?) with the number of specific options, so it really seems like a weird choice to me.
And that makes me think there might be a good reason that it is done this way.
But from a user perspective, it really is not a good interface.
combinatorially?
Yeah, that seems more logical to me
Personally I think I would put those options at the top, as those are probably the options most people will change most often.
It shouldn’t be too hard to change the UI. Options are to do what ART does (as someone showed above) or use still a menu but with three check menu items. It should be a relatively simple change to mock up both of these approaches.
Regards, Freddie.
So I took a look at the Darktable source code, and I think I found the right file, but… I’m afraid it looks like this is way out of my league for now 
I did seem to understand the separate correction options are also separate in the code, with another enum that has the list options by or’ing those correction options.
Other than that, I didn’t understand much of the code, but I must admit: I’m no C-programmer, I’m a bit tired today (HAH, toyear more like :/), and I didn’t look at it for too long.
It might be worth putting in a feature request. The checkboxes sound a reasonable suggestion, but I don’t know the difficulty of coding for this. I know I would also like a manual distortion option for when a lens is not in the database. The manual vignetting helps with some of my lens, including ones already in the database.
