Here is a task needed for the gtkmm codebase.
Requires good knowledge of C++, ok knowledge of XML, and at least passing knowledge of the Inkscape codebase.
Preferences =========== Design an Inkscape::Preferences class that wrappers an SPRepr. It must provide the following public interface as a minimum:
gboolean save(const gchar *filename); gboolean load(const gchar *filename); SPRepr* getRepr(const gchar *key);
Look in inkscape.* for the C-versions of the above routines.
* Hook up the preferences functions in ui/dialog/dialog.cpp
To learn more, check out the gtkmm codebase like this:
$ cvs -d:pserver:anonymous@...54...:/cvsroot/inkscape login (hit enter for password) $ cvs -z3 -d:pserver:anonymous@...54...:/cvsroot/inkscape co experimental/bryce/inkscape_gtkmm $ cd experimental/bryce/inkscape_gtkmm $ make $ ./inkscape
Also look in the PLAN file for more todo's and projects' in the gtkmm codebase.
Bryce
Jon Cruz has added an XML parser to the inkscape_gtkmm codebase, along with functions to use it for loading/saving units.
I think Jon's new code could make doing the Preferences XML load/save outlined below quite straightforward.
Bryce
On Fri, 31 Dec 2004, Bryce Harrington wrote:
Here is a task needed for the gtkmm codebase.
Requires good knowledge of C++, ok knowledge of XML, and at least passing knowledge of the Inkscape codebase.
Preferences
Design an Inkscape::Preferences class that wrappers an SPRepr. It must provide the following public interface as a minimum:
gboolean save(const gchar *filename); gboolean load(const gchar *filename); SPRepr* getRepr(const gchar *key);
Look in inkscape.* for the C-versions of the above routines.
- Hook up the preferences functions in ui/dialog/dialog.cpp
To learn more, check out the gtkmm codebase like this:
$ cvs -d:pserver:anonymous@...54...:/cvsroot/inkscape login (hit enter for password) $ cvs -z3 -d:pserver:anonymous@...54...:/cvsroot/inkscape co experimental/bryce/inkscape_gtkmm $ cd experimental/bryce/inkscape_gtkmm $ make $ ./inkscape
Also look in the PLAN file for more todo's and projects' in the gtkmm codebase.
Bryce
The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt _______________________________________________ Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
I must have missed something, but what's wrong with libxml that we're already using for reading svg?
On Tue, 18 Jan 2005 00:43:33 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:
Jon Cruz has added an XML parser to the inkscape_gtkmm codebase, along with functions to use it for loading/saving units.
I think Jon's new code could make doing the Preferences XML load/save outlined below quite straightforward.
Bryce
This code uses libxml.
On Tue, 18 Jan 2005, bulia byak wrote:
I must have missed something, but what's wrong with libxml that we're already using for reading svg?
On Tue, 18 Jan 2005 00:43:33 -0800 (PST), Bryce Harrington <bryce@...260...> wrote:
Jon Cruz has added an XML parser to the inkscape_gtkmm codebase, along with functions to use it for loading/saving units.
I think Jon's new code could make doing the Preferences XML load/save outlined below quite straightforward.
Bryce
bulia byak wrote:
I must have missed something, but what's wrong with libxml that we're already using for reading svg?
Actually, that stuff I did uses libxml's SAX interface.
The main thing is that the housekeeping of interfacing with it has been abstracted in a nice C++ manner. For the simplest parsing, just override the single _endElement method and there you are.
:-)
Bryce Harrington wrote:
Jon Cruz has added an XML parser to the inkscape_gtkmm codebase, along with functions to use it for loading/saving units.
I think Jon's new code could make doing the Preferences XML load/save outlined below quite straightforward.
Just be aware that the one in now is a bit limited. I'll need to get comments in on stuff, but it's mainly only good for flat/shallow XML. The main thing is that the start of a new element clears out the single shared buffer, and the end of an element wraps it on up. There's also no simple way to track the current depth in a hierarchy. (a version that handles those is forthcoming).
So... all said, if the use is appropriate, all you'd need to do is subclass FlatSaxHandler, override _startElement if you'll need to setup anything at the start of any tags, and override _endElement to get the content at the close tag.
participants (3)
-
Bryce Harrington -
bulia byak -
Jon A. Cruz