This afternoon I spent some time cleaning up the code for the Outliner. Since its inception back in 2004 for 2.35, it has practically all resided in a single file: outliner.c
While back then, this was pretty "normal" (well, if can call a single directory, with some many files that you end up having trouble linking it sometimes on some platforms). However, now with the 2.5 code layout, we can afford to have code spread out in far more files, as each editor has its own little module now.
Which brings us to the core reason for this whole cleaning up.
While working on some additional features for the Outliner last week, the weight of recent growth over the past few years started catching up with it. You see, by having everything in a single file, we had a file that was 160 kb.
Typically, most other rather large files in our codebase are around 80kb, and even then, they are starting to get on the "could be hard to manage scale" (BTW, there's another even riper candidate for refactoring in a similar fashion: readfile.c, which on last check weighs in at over 300 kb - mostly due to the version patching code, which only ever gets longer with each release we make). I've heard/read in the past about some religious types who jump up and down when any single code file gets larger than ~20 kb IIRC, and I don't think that figure was for py code either ;)
The main issue when a single file contains this much code, is that it starts getting hard to navigate the file. Working on it may start even getting slow (BTW, readfile.c is reaching that point). In the case of outliner.c, the sheer volume of functions and number of long functions was taking its toll. Some developers had (I'm assuming) gotten to the point where they couldn't see the structure of the layout of the functions anywhere, and wound up sticking code in weird places (i.e. right in the middle of a chunk of related functions) making it bloody hard to actually find what you're hunting for, as certain functions started having a "knack" for managing to hide amongst their murky surroundings. Not to mention the cases where spaghetti was emerging and/or prototypes needing to get used to avoid weird linking order issues imposed by having only a single way to order everything.
Unravelling some of the mess this afternoon was quite hellish actually. Doing an initial split: no problem. Getting that to compile: aarrrrrggggh!!!!!!
I always wondered if the Outliner code could be massively simplified by making it RNA-based, rather than all the old stuff hard-coded to DNA like it is now. Seems like the code that handles the datablocks section is so tiny in comparison. Not really your task at hand here, but hey :)ReplyDelete
Aligorith look here:ReplyDelete
There is already Scuey working on the Outliner.
Nice chance to collaborate :)
Hopefully this can one day lead to having basic features like folders/sets, and not relying on groups for this type of ad-hoc organization, as in Maya and other 3D apps. Thank you for your hard work to bring the world a better blender :-)ReplyDelete
Which reminds me, have you found why the character limit for scene-items/objects is so small, could this pave the way for objects in the outliner to have a larger character limit for their names.
This is a bit off topic, but it made me hope that such a re-factor could assist in allowing(in the future) one of my all-time top-feature-requests for blender: the ability to have longer file-name paths than the current character limit(for a blend itself, or a linked/appended item), around 240-ish character or somewhere around there. It's so absurd, for teams working on LANs or using certain cloud-services; it ends up being a dynamic-link mess for larger (team-based) projects, with notes to remind anyone, in case drives get upgraded mid-project, etc. Fingers crossed, one day.... ;-)
Anywho, thanks for chronicling your word as you make progress. Do you have a twitter accnt, and/or G+?
I can only second what 3duaun said. A better outliner is what blender needs urgently :)ReplyDelete
Someone had a great idea for the Outliner in Blender. When working on large scenes with 100s of objects this would be awesome:ReplyDelete