The inkscape object and the inkscape_application_init( ) function
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)?
I might not have brought this up now, but my memory was jogged by the comment at the top of page 2 http://www.thedailywtf.com/forums/48173/ShowPost.aspx (and elsewhere).
inkscape_application_init( ) is called in three places, in main.cpp, exactly once at application start-up; by SVGPreview::SVGPreview() when we want to provide a preview of an SVG file in a File->Open dialogue and by ImageIcon::init(), probably for similar reasons.
I am assuming that the code is not wrong (the new-gui is intended to run with inkscape being NULL), but I suspect that it need to be better commented documented. If this is worth doing, could some kind soul post a few hints and I will do it
Ben
Ben:
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)?
Intended by whom? And why didn't he use a singleton pattern? I think answering this is moot, the code is as it is, and what could be better than my rewrite not only as singleton, but also with separation between app-wide and gui-wide code in the two singletons Application and Editor?
inkscape_application_init( ) is called in three places, in main.cpp, exactly once at application start-up; by SVGPreview::SVGPreview() when we want to provide a preview of an SVG file in a File->Open dialogue and by ImageIcon::init(), probably for similar reasons.
And what does the inkscape object do? It provides preferences info for all apps, and desktop/document info/GUI services for GUI apps.
I am assuming that the code is not wrong (the new-gui is intended to run with inkscape being NULL), but I suspect that it need to be better commented documented. If this is worth doing, could some
Again, intended by whom? I might even suspect Bryce/Derek intended to use the inkscape object in new-gui. However, I no longer rely on it, and even not on it being 0 in new-gui, to not introduce unwanted behaviour, as already seen once but quickly steered away from.
ralf
On Nov 4, 2005, at 10:01 AM, Ralf Stephan wrote:
Ben:
inkscape_application_init( ) is called in three places, in main.cpp, exactly once at application start-up; by SVGPreview::SVGPreview() when we want to provide a preview of an SVG file in a File->Open dialogue and by ImageIcon::init(), probably for similar reasons.
And what does the inkscape object do? It provides preferences info for all apps, and desktop/document info/GUI services for GUI apps.
It might also be doing a little too much.
I think some of what needs to be done is to put in a few models behind the scenes to act as mediators between sections.
One way is how The GIMP has a GimpContext between tools and documents instead of hooking up things directly. If, for example, we have the "current color widget" hooked up to a Context instance, it then could be completely ignorant of even the existence of documents. Then each document could have it's own Context that hooks to the application's Context as it comes forward. As far as the "current color widget" would be concerned, all that is going on behind the facade of the interface. It knows colors and only colors and is not concerned with other complex things such as documents, UI and such.
So... take a eye out for how things might be broken down more. Instead of keeping with a single "application" instance that's a catch-all glob for everything, try to see if there are lines to have things broken down logically. Ask yourself "does this *really* belong as part of the essence of the Application, or is it perhaps is it more the essence of the current Document, or something new abstract concept?"
Hey, thanks for having this discussion on the list.
Very interesting from all points of view. I keep on trying to do part of the gtkmmification and running into issues that have more to do with my lack of knowledge about where things are at rather than the actual change I might be considering. The other problem I have is when I try to C++ify a concept from the existing code I get most of the way there and then there is some gotcha, some pointer tucked away in some gobject pointer somewhere. Bryce or Ralf has recently given me other ways to deal with this issue to some extent. Now what I really need is what we all need, more time.
Anyway, thanks again for a few more insights into the code, both as it is and as people are changing it for the gtkmmification.
Jon A. Cruz wrote: and so did Bryce and Ralf and Ben.....
Jon Cruz:
So... take a eye out for how things might be broken down more. Instead of keeping with a single "application" instance that's a catch-all glob for everything, try to see if there are lines to have things broken down logically. Ask yourself "does this *really* belong as part of the essence of the Application, or is it perhaps is it more the essence of the current Document, or something new abstract concept?"
In fact, having a single Inkscape::Preferences object (neither part of Application nor the inkscape object) looks just like the way to go...
ralf
On Nov 7, 2005, at 2:40 AM, Ralf Stephan wrote:
In fact, having a single Inkscape::Preferences object (neither part of Application nor the inkscape object) looks just like the way to go...
Maybe not.
I believe that in The GIMP they have a 'context' that takes care of saving preferences as one of it's duties, but it's not required to be one and only one.
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
participants (5)
-
Ben Fowler -
Bryce Harrington -
inkblotter -
Jon A. Cruz -
Ralf Stephan