On Oct 13, 2005, at 1:15 AM, Ben Fowler wrote:
I think, though I may be wrong, that someone would have to decide what goes into the group of callbacks available a "knowledge of View classes in general, or knowledge of a putative View base class", and probably someone will have had to design the architecture so that it was available when the list of callbacks required was originally made.
Not so much.
That's a bit like putting the cart before the horse. Or letting the tail wag the dog.
The key is not View classes and knowledge of View classes. Rather, one should start with the Model classes. Get those defined to perform their abstract behaviors and such. Focus on the functionality.
Then it's easy to hook up either View classes or *other* Model classes. Since the Model is very agnostic and unaware of what is calling it and listening to it, there really is no need to start from the other side. Start from defining the actual functionality of the "work" that's needed to be done.
for the benefit of grep, and perhaps re-arrange the code and/or the namespaces and/or the directory structure and/or the Makefiles, so that those files could be compiled and linked without GTK+ and without GDK.
Some work might get in that direction. However, you have that Inkscape is primarily an Editor, so UI is a key part and GTK+ use is very prevalent. And we like to be able to make it do drawing in a cross-platform manner, so GDK is used heavily. Just take a peek at the GDK API and you'll see there are a few handy things in there, including pixmap support. And remember that even in command-line mode, Inkscape's main purpose is to "draw" a graphic for output.
(Obviously I would also like to tag other files as VIEW and CONTROLLER, but this is far less important, and from comments above, I guess not sustainable).
Again, I don't think we'll ever have need of a separated Controller class. Patters other than MVC give us more payoff. Focusing on using the Facade pattern, for example, gives much more of the main benefit.
Also, is there (or should there be) an Inkscape API?
Depends what you mean by "Inkscape API".
The main plan at the moment is to get things setup with exposure as a full DOM tree, with UI and functionality as DOM also. Then exposing the standard DOM trees and events and such via language bindings (probably SWIG).