I have in the past written artisan-level code in C & C++. I’ve never managed or written for a large chunk of code like dt. When I go looking to find out what has gone wrong somewhere, I feel like I’ve been parachuted into some obscure corner of London without a map.
So has anyone created a map that indicates which code relates to which function? Where is the code that reacts to UI actions and sends information off into the mines of develop.c, for example, or controls the ordering of SQL labels in the Collections panel?
I’d love to re-learn C and contribute some actual code to darktable but this (the complexity of the pre-existing beast before me when I look at github) is just too big a hump for me to get over. I’ve got some vague ideas from ambling through the code but I’m miles away from anything approaching comprehension.
@GBB29 at least for linux there are tools that will draw you a chain of callbacks so that you can have at least some hint. Nonetheless moderns IDEs usually let you to see the chain of calls so you will be able to see what the flow is. Not sure if old tags or ctags allows for that.
I don’t think there is one and the right way for each of those project is to pick an easy bug and try to fix it. Ask developers where to look and fix it.
Here is one:
The “dots” for drawn maks are two small for my taste, especially on HiDPI display. They should be all a bit bigger. Like the dot and arrow for a gradient to pick and rotate it. All the dots in a path you created, etc.
The code for that is in src/dtgtk/paint.c
gdb is your friend. Set breakpoints and step through the code
I’ve tried producing such maps, either text or graphic, and I’ve found the endeavor to take more time that it was worth.
The most productive such endeavor I’ve personally found has been to find main() (not as obvious for GUI programs…) and working my way down the function calls and event handlers. Then, when you get to the image processing routines, you need to spend a few moments picking through the data structure (integer? float? contiguous memory? list of pointers?) so you can understand the logic that walks the image.
Try this with dcraw.c. That will be like beating your thumb with a hammer: it feels good when you stop.
A starting point of where to find gui actions (which do not appear to be in gui… too easy ) so that I can track them until I become disheartened and turn to drink, that is all I’d like, really
After some considerable struggle, I managed to setup DT in Eclipse, with cmake, GDB and everything, both Windows and Ubuntu.
Unless the fault is Windows specific, I prefer 100 times to work in Linux, as it’s so much faster to build and run the debugger
Eclipse will do. It’s good but memory eating IDE. I used to use it for linux kernel browsing. When code is indexed it’s fast.
Similarly to @ggbutcher I don’t find graphical call graphs useful. Usually it’s not worth it.
The best way to know the code is actually parachute oneself and start digging. At least from my years of experience. Or … ask for help for a particular problem. There is IRC and there is a mailing lists for that. Programming is not the easiest thing to do but I find it pleasing
I ended up biting the bullet and I’m slowly making my way through the source code. Started with src/main.c, reading up as I get to bits I don’t understand and making notes as I go along. I’m slowly getting my head round it.
After a couple of weeks of pulling out what little hair I have left, the thing that I’m most struggling with is tying what I know about the pixelpipe/modules as a user to how that information is represented in the many data structures that abound within the darktable code.
As an example, how would I find a representation of all modules (whether active or not, and including duplicates) and their associated widgets for the image I’m currently editing - what data structure(s) are those stored in and how do I determine what order they will be applied during processing? If I move a module up or down in the pipeline (/duplicate/delete a module), or change the parameters of a module, what data is changed? I feel like if I only had a handle on a few of the key data structures, my understanding of the rest of the code might fall into place.
Unfortunately, while some of these structures have comments against their member variables, none of them seem to have an overall description of what that structure represents, and I’m left trying to infer that information by looking at the operations performed on them.
Can anyone give me a quick summary of the key data structures I need to understand and how they relate to each other?
I hink most of the action happens in the develop directory, but with lots of things sent out to common. Somehow it’s all under the control of control, but I’m completely lost as to how…
I don’t know darktable, but that’s a challenge with most GUI programs. The event-driven mechanism serves to hide calling order, especially from us who grew up with main().
(me included)