A map of darktable code?

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?

1 Like

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.

1 Like

I used to code in Visual C using the Microsoft IDE.

Any suggestions for a modern, free IDE compatible with Windows?

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 :slight_smile:

1 Like

Oooh, sounds so much better than the “hack software” moniker I’ve been using… :smiley:

1 Like

Really, there’s nothing like the backtrace from a segfault to show you the biblical “Genesis”, what begat what…

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. :smiley:

3 Likes

In fact I found several main()… :frowning:

A starting point of where to find gui actions (which do not appear to be in gui… too easy :smiley: ) so that I can track them until I become disheartened and turn to drink, that is all I’d like, really :smiley:

2 Likes

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

Precisely.

1 Like

Can you do some kind of article/writeup on how to do that? It’d considerably help others :slight_smile: (me included)

1 Like

Yes, why not ?
It will take some time, as I happen to be on vacation.

3 Likes

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 :wink:

1 Like

(Currently digging)