In my experience it is not just the code takes a "long time" but is the lack of specific useful inline documentation and a need for a really good IDE/debugger workflow. So I started making my own code docs when I figured out coding techniques. The code in general is also not usually modular and has some unusual conventions so it is a hard read the source without a full debug and trace environment to watch it execute.
Then I started working on my IDE/debugger workflow. So mapping out the pointer usage, call backs and variable naming patterns speeds up the "long time to learn" process considerably for me. I also have a strong background as a programmer in proprietary code from scratch, maintenance code and some experience with other FOSS projects. So part of the challenge in my experience is not assuming things known from these other experiences but rather watching Blender code execute so you can see its assumptions and patterns. So cycling very fast through the debugger to see how the window management code blends in with the other code has been very helpful to me in speeding up seeing Blender's assumption picture. You will need to set key breakpoints then rapidly step out of the functions to watch the call list. Once you can recognize and ignore the window management code, then there is less code to understand. Once you recognize the callback code and variable naming and pointer code patterns then you start getting to the algorithmic code. The algorithms will make much more sense more quickly. Reading the header files also helped speed things up for me. They sometimes have the only documentation for that section of code. So that's where personal notes come handy to remember key variable names and defines when in the executing or algorithmic parts of the code. Also folding the code levels in your IDE helps see the big picture of each individual file. Then expand the functions that look relevant. This really cuts down on the noise and helps focus. The relevant DNA files to the area you are working in help with understanding the data. So always glance at those relevant files. They are formatted DNA_[name].types.h "They are your friend" I was told by a dev. Tracing the symbols in the debugger helps out tremendously. Also, as in QT Creator, "Follow symbol under the cursor" will show you where it came from and there may be some insight there. Also the wiki contains some prefix definitions that help sort things out so you can recognize a prefix as belonging to a specific part of the code. Some of the code intertwines very heavily, so it is important to sort that out and learn what code to ignore. Also there is still some unused code that has not been removed that can be confusing. So beware of that dead end. So the pattern here is a good workflow and coding/debugging environment speeds up things considerably more than just reading the code in a simple editor and trying to wrap you mind around it manually. So in my experience a good working environment and tools, memorizing a few key techniques and making some notes mapping and defining things can reduce the "it just takes a long time" down to something manageable with Blender's particular code base. So hopefully you more quickly get to where you can achieve some usable results. After that, when adding to the code, make sure to keep in line with the wiki guidelines. Also check out the dev's personal pages for information on coding. I think Sergey/Nazg-gul and Cabpbell/Ideasman42 both have some useful information on their personal pages. Other devs may also. So to recap: Once you get the technique and workflow down the time is reduced substantially In the debugger watch and learn the code flow in the function call window rapidly several times by stepping out repeatedly Check the header files and DNA_[name]_types.h files Follow the symbols back to where they came from in the code to start seeing that patern Take notes to map things out and as reminders Spend some time identifying window management and call back code so you can learn to ignore it when needed. Keep refining your techniques and things speed up. Good luck! JT _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
