Inkscape as console application
(This may be off-charter for Inkscape Devel, in which case I apologise).
I was stepping through inkscape under gdb (on BSD without X) and found that the "sp-console-main( )" seems to have a code path that calls gdk_devices_list() (whilst loading preferences).
Is this intentional?
It is possible that I am talking nonsense, and I have somehow messed up the sources, but there are a number of concerns if there is any merit in what I am saying.
I would certainly like to have an X-free or no-X command-line or console version of Inkscape, and I would be interested in any thoughts.
Ben
You wrote
I would certainly like to have an X-free or no-X command-line or console version of Inkscape, and I would be interested in any thoughts.
Moving GUI code out of non-GUI classes is one method for moving towards an Inkscape that is not tied to a specific UI.
ralf
On 10/10/05, Ben Fowler <ben.the.mole@...400...> wrote:
(This may be off-charter for Inkscape Devel, in which case I apologise).
I was stepping through inkscape under gdb (on BSD without X) and found that the "sp-console-main( )" seems to have a code path that calls gdk_devices_list() (whilst loading preferences).
Good point. The console main definitely does not need to load the tablet preferences. But it needs the regular preferences, and as far as I remember they are all loaded in one function that also calls the tablet prefs loader. Can you try to separate them, so that tablet prefs are only loaded for GUI?
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 10/10/05, bulia byak <buliabyak@...400...> wrote:
On 10/10/05, Ben Fowler <ben.the.mole@...400...> wrote:
I was stepping through inkscape under gdb (on BSD without X) and found that the "sp-console-main( )" seems to have a code path that calls gdk_devices_list() (whilst loading preferences).
Good point. The console main definitely does not need to load the tablet preferences. But it needs the regular preferences, and as far as I remember they are all loaded in one function that also calls the tablet prefs loader. Can you try to separate them, so that tablet prefs are only loaded for GUI?
Well, yes and no.
I was looking here http://www.inkscape.org/doc/doxygen/html/inkscape_8cpp.php#a38 , where inkscape_load_preferences( ) calls sp_input_load_from_preferences() .
A 'quick and dirty' way round would be to make that call conditional upon the value of use_gui.
(Is this what you meant?)
This looks a little baroque.
Are you sure that the console application should load user preferences? User preferences are often pertinent to a user sitting in front of the application and interacting with it, this is why Gnome has a desktop-wide way of loading/saving defaults and preferences (at least I assume it does!).
i need to write about this from an architecural point of view, because I want to check first that Inkscape is a Gnome Application within the meaning of the Act,
(See http://developer.gnome.org/doc/tutorials/gnome-libs/gnome-libraries-overview... for my picture of how Gnome sits on GTK which sits on GDK).
and second that Inkscape does (or will in the future) use the Model-View-Controller pattern exempli gratia: "The 'model-view-controller' paradigm introduces the controller object in between the view (the GUI class) and the model (the object) to communicate between the other two objects. The actual implementation of the controller object can vary quite a bit, but the idea of an object to 'transform' events to changes in data and execution of methods is the essence of this pattern." http://en.wikipedia.org/wiki/MVC .
These are matters for the future, maybe not so far off, but for today, do you agree that it is the functions that I named above that need looking at, and that there exist an approach which is acceptable to you?
Ben
On 10/11/05, Ben Fowler <ben.the.mole@...400...> wrote:
On 10/10/05, bulia byak <buliabyak@...400...> wrote:
On 10/10/05, Ben Fowler <ben.the.mole@...400...> wrote:
...
I was looking here http://www.inkscape.org/doc/doxygen/html/inkscape_8cpp.php#a38 , where inkscape_load_preferences( ) calls sp_input_load_from_preferences() .
Incidentally, at the head of that function is code like:
Inkscape::XML::Node *devices = inkscape_get_repr(INKSCAPE, "devices"); if (devices == NULL) return;
Now, the variable devices after the call to inkscape_get_repr is not NULL, but the repr within it is.
Does this code properly express the intentions of its author ...
Ben
On Oct 11, 2005, at 2:38 AM, Ben Fowler wrote:
and second that Inkscape does (or will in the future) use the Model-View-Controller pattern exempli gratia: "The 'model-view-controller' paradigm introduces the controller object in between the view (the GUI class) and the model (the object) to communicate between the other two objects. The actual implementation of the controller object can vary quite a bit, but the idea of an object to 'transform' events to changes in data and execution of methods is the essence of this pattern." http://en.wikipedia.org/wiki/MVC .
Personally, I think the MVC pattern is a bit overblown and unwieldy.
A modified M-VC approach is more often better.
The key difference being no required separation between view and controller.
On 10/11/05, Jon A. Cruz <jon@...18...> wrote:
On Oct 11, 2005, at 2:38 AM, Ben Fowler wrote:
... and second that Inkscape does (or will in the future) use the Model-View-Controller pattern ...
Personally, I think the MVC pattern is a bit overblown and unwieldy.
It may be 'blown', but like the possibly apocryphal "Too many notes, my dear Mozart" http://www.guardian.co.uk/arts/fridayreview/story/0,12102,1230395,00.html , maybe not to excess.
A modified M-VC approach is more often better.
The key difference being no required separation between view and controller.
At this stage, all I am looking for is a complete separation between the model (producing an inkscape API) and 'everything else'. It would not surprise me if the inkview and inkboard projects need this.
A bigger problem is that some people and I am in this camp, probably wrongly, call the thin layer that mediates between the model and the view, or represents tools acting between them, the controller.
I have no objection to this layer being called the 'mediator' or 'arbitrator' (I think that this term is used in hot-plugging), or 'toolbox' or similar, particularly if this results in greater clarity or understanding.
The purpose of this layer is to ensure that there are no dependencies between the model and the view, and it may be quite complex. Some applications, and this could well be the case for inkscape will have the User preferences in this layer; Also 'Undo' can be thought of as something under the User's control rather than part of the data model.
Certainly when I speak of the 'View' layer I am thinking not just of the display, but the display, the mouse cursor, keyboard and extended input.
A full MVC architecture (perhaps I was on thin ice to speak of it as a pattern) may be unwieldy but it is not always unncessary!
Ben
On Oct 12, 2005, at 1:01 AM, Ben Fowler wrote:
A bigger problem is that some people and I am in this camp, probably wrongly, call the thin layer that mediates between the model and the view, or represents tools acting between them, the controller.
I have no objection to this layer being called the 'mediator' or 'arbitrator' (I think that this term is used in hot-plugging), or 'toolbox' or similar, particularly if this results in greater clarity or understanding.
The purpose of this layer is to ensure that there are no dependencies between the model and the view, and it may be quite complex.
Then it sounds like you're not actually talking about MVC here.
In classic MVC, the View would be bound directly to the model, with no layer in between. Also, that connection would be one-way (from model to view only).
Then the Controller is bound to a model, but with a one-way connection from controller to the Model.
In general the Controller and the View would both have tight dependencies on the Model. The Model, on the other hand, would have no clue as to what was actually connected to it.
The "mediator" is a different pattern altogether, though as with most patterns you will often get several in play at once with real software.
I've found this site to have a good, quick overview of some common patterns: http://www.dofactory.com/Patterns/Patterns.aspx
"Bridge", "Facade", and "Mediator" are some that are often quite helpful.
On 10/12/05, Jon A. Cruz <jon@...18...> wrote:
On Oct 12, 2005, at 1:01 AM, Ben Fowler wrote:
A bigger problem is that some people and I am in this camp, probably wrongly, ...
Then it sounds like you're not actually talking about MVC here.
i have no difficulty in accepting that I may be mistaken! See http://c2.com/cgi/wiki?ModelViewController : I guess that a lot of people are mistaken, to the annoyance of those who actually grasp the 'impressive lineage'.
In classic MVC, the View would be bound directly to the Model, with no layer in between.
Are you actually advocating that for Inkscape (or any other Gnome or GTK Application)? To me it seems to have the fatal drawback that the Model has a dependency on the View and must know how to drive each and every View that interested developers come up with.
[ snip ] In general the Controller and the View would both have tight dependencies on the Model. The Model, on the other hand, would have no clue as to what was actually connected to it.
Again, this would have the very large problem that cross-platform applications would be impossible, as a given View (GUI) would mate with only one Model.
I am looking for an architecture where the Model can drive any reasonable View.
[ snip ]
At this stage, I am not trying to tie down the meaning of these terms, I accept that similar words like Control and Controller are used in different and various contexts and often are used in unrelated senses, and quite possibly my internal understanding of 'Controller' is simply wrong, when checked against http://st-www.cs.uiuc.edu/users/smarch/st-docs/mvc.html (possibly the best tutorial on MVC, but entirely Smalltalk), and of course, http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html . Now I don't claim to understand every last detail, and I would also suggest careful reading of the relevant pages in the Portland Repository, which shows that the MVC has been re-invented several times (at least once independently).
Note that http://www.object-arts.com/EducationCentre/Overviews/MVC.htm has pictures which may be guide as to what I am thinking (even if I am wrong, and even if it doesn't lead to any benefit to Inkscape).
(I would be unhappy if an architecture gratuitously allowed the User Interface to update itself, its concrete View, without going through the Model).
All I am asking is for there to be Model, an API for Inkscape.
Note that whilst this may seem to be common sense, it is hardly ever seen in practice, see "Attempting to stitch these two worlds together in a hand coded method without architecture is very common, and results in the model object being polluted with knowledge of the interface, and vice-versa. This makes the code very inflexible and difficult to maintain. For this reason (among others), many programming shops develop the user interface design early in the process of design, and freeze the interface early. The unfortunate side effect of this is that the domain of the problem often isn't clearly understood by the programmers until late in the implementation process. Thus, just at the time that the developers are finally competent to create a good interface, they are kept from changing it. MVC models allow the code to be more flexible later in the development process, allowing for changes that make sense at the time it makes sense to make them."
http://www.absoluteastronomy.com/encyclopedia/m/mo/model-view-controller.htm
and yet this is nearly universal when using PHP in which user interface, presentation and data manipulation are intermingled in the same file!
Ben
This thread is very academical. Ben, why don't you have a look at inkscape's branch named CXXIFICATION_VIEW_AND_WIDGET and discuss that?
There, the model (SPDesktop) is quite happily using a second view (EditWidget) without knowing details, and without a circular dependency, because EditWidget (as well as your usual SPDesktopWidget) adheres to EditWidgetInterface, and SPDesktop only needs a reference to that.
Why?
Because one and the same SPDesktop now drives Gtk+ and Gtkmm. Software reuse par excellence.
Please use this as concrete example and contribute to the code.
ralf
On 10/12/05, Ralf Stephan <ralf@...748...> wrote:
This thread is very academical.
Not meant to be.
Ben, why don't you have a look at inkscape's branch named CXXIFICATION_VIEW_AND_WIDGET and discuss that? [ snip]
Because one and the same SPDesktop now drives Gtk+ and Gtkmm.
I will take a look. That is very much what I am interested in. Would it work as Gtk+ and QT?
Ben
You wrote
Ben, why don't you have a look at inkscape's branch named CXXIFICATION_VIEW_AND_WIDGET and discuss that? [ snip]
Because one and the same SPDesktop now drives Gtk+ and Gtkmm.
I will take a look. That is very much what I am interested in. Would it work as Gtk+ and QT?
Yes, concerning SPDesktop only. Unfortunately, inkscape GUI code is distributed widely within the source (grep --recursive -l gtk_ gives >100 files), mostly different dialogs, widgets, and then the initialisation/window and the canvas widget are the other big chunks. This does not mean there is a full set of gtkmm modules, as gtk+ code also works when called from gtkmm. So you will only see the odd file cleanly separated[sic] into M/V.
ralf
Quoting Ben Fowler <ben.the.mole@...400...>:
In classic MVC, the View would be bound directly to the Model, with no layer in between.
Are you actually advocating that for Inkscape (or any other Gnome or GTK Application)? To me it seems to have the fatal drawback that the Model has a dependency on the View and must know how to drive each and every View that interested developers come up with.
No, it just means that the View would use callbacks or an Observer-ish interface to receive notifications from the Model. The Model need have no knowledge of the specific View class whatsoever.
The View, of course, is aware of the Model class and manipulates it directly.
-mental
On 10/12/05, mental@...3... <mental@...3...> wrote:
Quoting Ben Fowler <ben.the.mole@...400...>:
In classic MVC, the View would be bound directly to the Model, with no layer in between.
... To me it seems to have the fatal drawback that the Model has a dependency on the View and must know how to drive each and every View that interested developers come up with.
No, it just means that the View would use callbacks or an Observer-ish interface to receive notifications from the Model. The Model need have no knowledge of the specific View class whatsoever.
1. I had actually decided that it was time to let others have the last word here, but just in case I had somehow got under your skin, let me repeat my initial comment, that if I am off charter, I apologise.
Some of this is wiki material, that is for sure.
I agree that "The Model need have no knowledge of the specific View class whatsoever", and this should be regarded as a valid correction to the excerpt you quoted.
2. Perhaps my comment was naive, but it is not altogether wrong; in an open source project (this is discussed towards the end of the Red Bean book) interfaces and the territory between components should be regarded as mobile and changed whenever necessary (meaning when the alternative is ugly or unmaintainable code or code that is bad match to the projects medium or long term goals). Just think what would be going through your mind if someone suggested that all the user interface should go though callbacks (see http://wiki.inkscape.org/cgi-bin/wiki.pl?Coding_Style for the phrase 'summarily shot').
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.
I quoted a URL above which has a take on how difficult it is for coders to do this in a timely fashion; and in any case this is a skill which is nearly non-existent on Sourceforge.
To come back (briefly) to my point: I was hoping that it would be possible to designate some files as being part of the Model, tag them with a line like
/* This file is part of the Inkscape MODEL */
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.
(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).
Also, is there (or should there be) an Inkscape API?
The View, of course, is aware of the Model class and manipulates it directly.
Yes
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.
No, I took SPDesktop, separated it from SPDesktopWidget, and wrote down the interface from the former to the latter (with hindsight to abstraction). No design. Just indirection. Let the code itself tell you what it needs. I admit there was some aimful optimizing taking part, and there will be more.
ralf
On 10/13/05, Ralf Stephan <ralf@...748...> 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", ...
No, I took SPDesktop, separated it from SPDesktopWidget, and wrote down the interface from the former to the latter (with hindsight to abstraction). No design. Just indirection. Let the code itself tell you what it needs. I admit there was some aimful optimizing taking part, and there will be more.
If I understand that correctly, then I agree - you worked from an exisitng list/listing of the interface capabilities.
It seems to me that that list either evolved as functionality was added to Inkscape (which I think is the natural way to work), and is what I meant by claiming that the Inkscape engine, if not the Inkscape Model has insight/knowledge of the most usual View - the GTK+ one; or had to be created up front. I think that the latter would need magic and/or one of Professor Brook's Silver Bullets. I haven't thought about this very much, and I may be on the wrong lines.
Ben
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).
On 10/13/05, Jon A. Cruz <jon@...18...> wrote:
On Oct 13, 2005, at 1:15 AM, Ben Fowler wrote:
[ snip ]
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.
Thanks for the reply. I am now very well informed on these aspects of Inkscape's design.
Ben
On 10/11/05, Ben Fowler <ben.the.mole@...400...> wrote:
I was looking here http://www.inkscape.org/doc/doxygen/html/inkscape_8cpp.php#a38 , where inkscape_load_preferences( ) calls sp_input_load_from_preferences() .
A 'quick and dirty' way round would be to make that call conditional upon the value of use_gui.
(Is this what you meant?)
Yes, approximately.
Are you sure that the console application should load user preferences? User preferences are often pertinent to a user sitting in front of the application and interacting with it, this is why Gnome has a desktop-wide way of loading/saving defaults and preferences (at least I assume it does!).
You may be right, but I'm not prepared to guarantee that the console code never ever uses the prefs. It may still rely on something in some cases. This needs investigating. But in general I agree that it is annoying when a console app has something else that may affect its behavior, apart from the command line params that I give it.
-- bulia byak Inkscape. Draw Freely. http://www.inkscape.org
On 10/11/05, bulia byak <buliabyak@...400...> wrote:
On 10/11/05, Ben Fowler <ben.the.mole@...400...> wrote:
I was looking here http://www.inkscape.org/doc/doxygen/html/inkscape_8cpp.php#a38 , where inkscape_load_preferences( ) calls sp_input_load_from_preferences() . A 'quick and dirty' way round would be to make that call conditional upon the value of use_gui. (Is this what you meant?)
Yes, approximately.
I'll commit this during 0.44 cycle, alternativley, if you have a plan for the 'right way', I'll do that instead.
ben
participants (5)
-
unknown＠example.com -
Ben Fowler -
bulia byak -
Jon A. Cruz -
Ralf Stephan