I didn’t mean for my comment to sound harsh. I appreciate all you guys do, and certainly darktable is a great application. There are some things that lack polish, but it’s not the end of the world. You said that some are quite hard to improve or fix, and I believe you. Some are arbitrary, and that’s fine with me, since I’m not the one working on the theme. Unfortunately, because of my work, I don’t have the time at the moment to learn how to code and contribute fixes, so I have to rely on the work of others, and all I can give is my feedback. As I mentioned, switching to the dark theme improves the experience for me, so it’s not a big deal.
That is the very definition of arbitrary, though. Fine with me.
Seems like it isn’t though, or you’d accept the explanation and move on. Again, you can change it if you wanted to, same for all the “unpolished” things.
Already moved on. Just thought of replying, since nilvus took the time to write such a thorough response.
1 Like
I wonder if there is a need for this though…so why could you not have module groups with the modules listed for selection in alphabetical order if you wanted…as long as the active modules group kept the pipeline order for review why is is necessary to have the modules in each group also organized that way. I can see how it would be the default but I think on at least two occasions someone asked about being able to have a custom order…not sure why that would matter.
I frankly don’t care one way or the other, as I have <10 modules per group (active module list excepted, of course). Keep in mind that after a while, you don’t search the groups anymore, as you know where the module is in such a small group, whatever the order within the group is…
But: I really prefer the order to be the same in all module groups (in the right sidebar). That is related to having learned the order in the other groups. If that order is completely changed for one (less often used) group, then that’s going to feel clumsy.
So I wonder if those requests for custom order came from beginning or experienced users. An inexperienced user will be looking through the list anyway (whatever the order is), an experienced user will have learned the interface
Final point: if only the group of active modules reflects the pipeline order, then that’s the only place where you can change the pixel pipe order of modules. But that group only shows active modules. That may not be an obstacle in practice, but it is an extra limitation.
Many of the same thoughts here but new users that don’t have the positional memory for where the modules exist in a group might want to start out with something that works for them. Its not a big deal as you say. I was more commenting on the fact that I think it could be changed without much impact. Modules that you pull in from a search might not even be part of any of your current module groups and then get applied to the pipeline correctly so I don’t think having the ability to reorder things would affect the pipeline and you could add an up and down arrow in the module manager along with the plus sign that would allow you to select them and move them up or down in the group…
It gets back to if someone wants or needs it bad enough they will have to figure out how to code it…
Don’t forget that you can also have multiple instances of a module that can occur in different parts of the pipeline, and order the processing is significant – not sure how you are proposing to properly manage the processing order of modules if you decouple it from the ordering of the modules appearing on the screen?
My point was this, for sure it should be shown in the active modules groups in the pipeline order but why is it absolutely necessary in other custom module groups that you create to have them displayed in pipeline order rather than a custom order of your choosing. The order in the other module groups does not impact the pipeline order does it or maybe that is the issue. I have only ever evaluated and move modules using the active module tab.
Again, are you sure it’s a good idea to have a different order in different module groups?
For an experienced user that would only make the interface more complicated (in my opinion), as you get an apparently gratuitous change in behaviour between tabs.
To be clear I don’t need it or don’t want it . I am just saying if you offer the possibility to create a custom module group the user has already put some thought into doing so. If they wanted to order the modules (for display only) in that group why would that be an issue. You can add a module from the search with out it being in any of your groups or knowing where it goes and it will get put in the right place and displayed correctly in the active modules group… Clearly I am missing something about why this could not be done fairly easily. We obviously can track each of modules to place them in custom module groups and so adding their order should not be a big deal. Again I don’t need this feature but you could argue a custom group is a custom group. My DT PC is down so what I don’t know is can you move modules in a way that affects the pipeline from groups other than the active module group and if so perhaps that is the reason things are the way they are…
LOL. No.
Module order in GUI is defined by the order of the pipeline. This makes sense beyond cosmetic concerns.
Then, we use Gtk as a GUI lib and it’s really less flexible than KDE regarding user customizations. Notice that most of the widgets (like sliders) are not even standard Gtk but actually custom drawings inside Cairo.
darktable is also close to end of life. Many issues we face now are grounded into core design, like the GPU/CPU multi-pipeline that is super slow, yields I/O penalty and leads to branching inconsistencies. The contortions we have to make around that design to keep extending features are more and more ugly as times goes by and at some point, the product will be impossible to extend some more while staying compatible with older edits and keeping some stability.
Not to mention, the GUI has to be drawn single-threaded on CPU because Gtk, the file I/O are done on CPU, but then we try to make as much as possible in-between on GPU through OpenCL (which, anyway, is controlled from the CPU), so this messy design leads to image buffers being exchanged several times between memories just to comply with third-party libs.
So it’s really not worth redesigning the UI now. Just rewiring the Gtk to CSS stylesheet took me 3 months full-time-ish, back in 2019. Re-writing it for Qt or making it fully customizable is not a realistic task, in addition to being not worth the trouble at this stage. Meanwhile, Hanatos processes a full-resolution image on Intel eGPU in a matter of milliseconds with vkdt.
I’m personaly only using dt now as an R&D platform/proof of concept, but ultimately I’m looking forward to translating my modules to Vulkan and switch to vkdt.
6 Likes
Also, it baffles me that LittleCMS2 at darktable’s output actually never worked (there is no gamut mapping in there, it’s actually useless) and nobody seems bothered, but somehow borders and shadows in the UI make people talk for weeks.
I mean, seriously, we are making an EXIF reader here ?
LOL. Yes, I think the difference in perspective here is what is fascinating. I was talking about a UI Skin approach as an abstraction layer above the pixel pipeline to empower developers to create their own UI alternatives. That would make the UI truly open source.
You responded with a developers perspective on the pixel pipeline and the utility of the way things have been done in the past, how it operates today, and what you, as a developer, would like to do in the future. I do understand your frustrations with Gtk, CSS stylesheets, Qt, and the desire to move on to Vulkan and vkdt. As as user, I appreciate the extraordinary solutions you have come up with to advance the capabilities of darktable.
Darktable has fulfilled its mission as a fantastic open source photo management and editing tool and I look forward to your next project with Vulkan.
Thanks for all the amazing work you have done to make darktable so great.
Erm, no. The code is already “truly open source” in that anyone can take it, and change it. Nothing there is hidden.
What you propose is another way to organise the code so that third parties can modify the user interface. That does not make it more (or less) “open source”.
Semantics aside (although they are pretty important here), any program has design decisions baked into it. Those decisions can be implicit or explecit. Anything that goes against those decisions will be very hard to implement; whether the original decisions were good or bad doesn’t change that. For me, that’s basically what @anon41087856 was saying above…
The hard link between display order and pixel pipe order of the modules appears to be one of those design decisions.
@anon41087856 , @hanatos : would a successor to darktable (like vkdt?) be able to read the darktable processing metadata?
LittleCMS2’s effects aren’t visible while working with dt, the UI is… And perhaps they think that LitteCMS2 is not darktable, complicated, and “everyone knows” that changing a UI is simple 
1 Like
This might be a separate thread, but what does that mean for darktable in the long run and is there a vision to transition VKDT into a multi-platform application in its place?
I know that FOSS developers are under no obligation to make commitments on their efforts, but some insight into where things are headed would help guide the DT user base.
I’m not aware of any plans to stop darktable development or move it to vkdt, so rest assured it’s all still being supported / actively developed for (though I guess at some point @anon41087856 might start working on vkdt instead?). The vkdt project has been running independently of darktable for a while and people can contribute to either. At the moment vkdt entirely GPU based so it’s not capable of running on CPU. Unless that changes, I think darktable will still have an audience for a while.
1 Like
All CPU have an embedded GPU since 2012 or so, this is really not the problem.
This means that darktable will continue to get polish but things like multi-picture blending/HDR stacking/focus stacking/panorama stiching/nodal UI will never make it to darktable because the core architecture is not suitable. And as picture resolutions keep increasing, the software will become increasingly less responsive with nothing we can do.