Hi,
First of all, thank you for all the hard work that has been put in darktable.
It's an incredible tool and I have no complains when it comes to its use.
Also excuse me if the subject has already been discussed, happy to read past
discussions if someone can point me to them.
I'm writing today, because I have concerns for the future of the project when
it comes to code maintenance in the long run after spending some time going
over the code these past few weeks. I can understand the motivation of using C
for the performance critical code paths or at a time were the convenience
provided by C++ had a significant cost. However, the lack of OOP and
encapsulations makes looking at the sources a painful experience for a new
comer. I see that as a pretty serious risk for the health of the project, were
the current developers to move on to other things.
Could someone please enlighten me on what are the motivations for sticking to C
and GTK? Is it simply because moving to something is at this point too
difficult or are there other reasons?
In the current state, just following the flow of the init function, the hundred
lines long functions, the use of glib, ifdef everywhere, lack of general unit
testing make the barrier of entry for any one willing to contribute really
high. Possibly adding a new module is not too hard but digging into the core
is....
It seems to me that moving to C++ and doing a refactoring would improve lots of
areas:
* properly enforce a Module API with an abstract classes or interface
* leverage the stdlib to make use of proper containers (not GList) / regexp
/ filesystem / smart pointers / strings and all the other convenience that it
provides
* use RAII to avoid all the goto all over the place
* use namespaces and classes to get rid of all the prefixes like dt_iop ...
* make use of properly defined enums and flags
* separate the logic from the UI code
* in turn this would make going for alternative UI libraries possible
* start adding unit tests to get a minimum of code coverage over the core
* make the overall flow and readability of the code a lot better (which
should lower the barrier to entry for new contributors)
* potentially target new platforms and new compilers without too much
trouble
Obviously not a sexy or fun task but I feel this is something that needs to be
done at some point for the sake of being able to maintain the project, not
depend on potentially outdated libraries and be able to adapt to a new
processing pipelines if needed.
I can see how tempting it is to disregard that aspect in favor of adding new
modules and making minor cosmetic UI changes that users can immediately see.
This kind of work no one sees but the ones looking at the code.
I also saw the vkdt project but IMHO it looks like a lot of the same mistakes
that were made for darktable were repeated but with some extreme decisions like
not allowing decent UI libraries like Qt (which could be done properly in a
decoupled way). ImGUI can only get you so far. That being said, I agree that
having a Vulkan and a node graph based pipeline is a good move.
Is there any plan to refactor darktable so that 1) code base is cleaned up and
critical part properly unit tested and 2) ready for a pipeline overhaul /
decoupled UI? And don't take me wrong, I' m not just stating what I would like,
I'm willing to dedicate time and get my hands dirty.
I'll be starting work towards getting everything to compile as C++ sources on
my own fork for the time being (lots of void * to remove ...), just to see how
far I can get. Happy to contribute and discuss this further if others are
interested.
Paul
___________________________________________________________________________
darktable developer mailing list
to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
