Hi, Starting on such high note is ambitious to say the least. To familiarize yourself with the code and stuiff - please help with unit testing, which as you say is important. Here: https://github.com/darktable-org/darktable/tree/master/src/tests/unittests
as for everything else - if that's your position, then all power to you! And why stopping at C++ when there's Rust? But if you'd like to actually discuss and have open mind you can join darktable irc channel or discuss forums on pixls.us :) niedz., 6 cze 2021 o 12:37 Paul Lemire <paullem...@hotmail.com> napisał(a): > 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 > -- Pozdrawiam, Hubert Kowalski ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
