Spending some time learning new corners of Juce, I have been hanging around in the DemoRunner a lot. The DemoRunner project is an extensive project with a lot of code and examples. I’m already way past the overwhelming nature of it, I can find my way easily.
I wanted to talk about the structure of the examples, they are all written in header files only. The consequence is that definition and declaration is folded into one file. I feel that for demo purposes this is less of a good idea. Usually when looking at a new topic I try to understand the basic concepts and global structure and after I’m interested in the coding details. In de current demo project its hard to separate these. If you want to see an exponent of this issue try to read and understand the “OpenGLDemo.h” file.
I would propose to go back to a header/source file written DemoRunner project to speed up understanding of the demos.
The point of the example files isn’t to show best practices for project structure - this is a complicated topic with lots of different, equally valid approaches. Instead, the demos are designed to showcase a short, self-contained snippet of code for a single purpose and the PIP format hides away a lot of the boilerplate code for things like setting up a desktop window so that the focus is just on the topic at hand.
Admittedly this isn’t a perfect solution for all situations and some of the demos can end up quite large (like the OpenGL demos) but generally it works well.
I’m not talking about the quality of the demo code, I’m talking about the understandability of the code.
Since there is (luckily) no thick manual of JUCE, one have to refer to the header files of the library for documentation and the DemoRunner project to see the library in action. The demos are the most important source of understanding JUCE.
What I’m saying is is that the PIP format of the demos makes it more difficult to come to the core of the demos. I feel that reading “conventional” headers (like the ones in the JUCE library) is an easy way to understand what is going on. The reading of the implementation is the next thing to do.
That would be a shame, since that was exactly the point to do the PIP in the first place: to focus only on that part of code, that is responsible for the thing it demonstrates, not demonstrating the library. Without that, someone who had already experience with JUCE and who found a new widget or technique in the DemoRunner, would have to browse through a lot of code, that he/she knows already, until finding the actual thing the demo is presenting.
For learning the library itself, there are the tutorials, that are written in the way the boilerplates are created.
I do understand, that not everything is covered in the tutorials, but given the infinite numbers of ideas and combinations the people using JUCE come up with, it would be an infinite task…
Exactly that’s is where I want to use the demo runner examples for.
What I’m saying is that in some cases that does not work anymore, specially for the openGL demos, since that is complex matter with lots of code needed to accomplish something.
I have to say that I do find the code in the DemoRunner quite confusing sometimes too, since the PIPs and the assets files are not available in the project structure, and because each PIP is basically one header file containing all the stuff available in one given demo. Some of these files are quite large, and my brain often has a hard time trying to understand what is going on in a single header with 90 kb of source code and classes all heriting from themselves + referencing to assets files.
