On Fri, Nov 04, 2005 at 12:08:20PM +0000, Ben Fowler wrote:
I have been discussing this with Ralf off -list, and it is possible that these issues will be dissolved away when Gtkmmification is finished, but in the mean time, I have a question.
Is the inkscape object and the inkscape_application_init( ) which creates it intended to be a Singleton pattern, or a Factory pattern, allowing more than one Inkscape::Application object, perhaps parameterised (or something else)?
This is a piece in transition. Long ago there was a single C struct global variable for the inkscape object, that was referenced and used throughout the codebase. You accessed it via a C macro called (IIRC) INKSCAPE_APPLICATION.
However, as the codebase grew, it accumulated a lot of different application "run modes" such as the editor GUI, viewer GUI, command line, etc. One could argue that Inkboard adds yet another run mode, and we can expect that the introduction of animation may add a couple more. If you look in main.cpp you can still see a lot of it.
In the gtkmmification, Inkscape::Application was introduced. This is essentially intended to be an interface to allow abstracting of these various run modes. There is now a single lightweight access point, that other portions of the code can include and refer to. It includes some handling general things like preferences, options, etc. It also holds the appropriate object for the run mode; this is an object derived from the AppPrototype class.
Currently, only the editor run mode has been implemented as an AppPrototype class. Obviously, this is the largest one, and once it works, the rest should be simpler to bang out.
Thus, the design intent is that there should only be a single Inkscape::Application object ever instantiated. The fact Inkscape will run with it set to NULL is merely because the codebase is still in transition; the original INKSCAPE_APPLICATION C struct was set to NULL on start, and initiated after. A singleton approach would probably be better.
The AppPrototype instantiation is, as you've guessed, probably best modelled as a factory pattern. This could allow for a user to have multiple run modes going at the same time (e.g., editing something in the regular editor, while watching an inkview-like preview in a side window, an animation viewer in another window, and an inkboard instance going too.)
There's some additional documentation about all this in the inkscape/doc/ directory.
Bryce