This is great Rick and libpapyrus-devel ppl. I'm cc'ing the Inkscape-devel list, Bryce Harrington and Mental, both core developers on Inkscape, as they can more adequately ask/answer questions.

More below...

On Mon, 2007-01-29 at 22:51 -0700, Rick L Vinyard Jr wrote:

Jon Phillips wrote:

...

Message body follows:

Hi, have you considered using Inkscape's canvas for your project (http://inkscape.org).

When I thought about restructuring glcanvasmm (an OpenGL based canvas) as the cairo based (and then later cairomm based) papyrus I looked all over for a library that would make it easy to do research in diagrammatic reasoning... more specifically visual programming languages (not Visual C++)... and even more specifically rule-based visual languages.

I looked at GnomeCanvas, GnomeCanvasmm, Evas, DiaCanvas, Zinc, FooCanvas (GooCanvas didn't exist then), et. al with the thought of just using the library or writing a wrapper for the non-C++ libraries. I also looked at several apps such as Dia, Inkscape, Sodipodi, et. al. with the thought of extracting the drawing canvas. I even looked at pure vector drawing libraries as well as 3D scenegraph libraries (such as Ogre and OpenSceneGraph) that also had decent support for 2D primitives.

Specifically, several things I was looking for:

• A standalone object-oriented C++ library with a minimalist set of

dependencies... to paraphrase Einstein... as few dependencies as possible, but no fewer.

• Easy to extend the canvas items either through inheritance or

through new drawing primitives

• Easy to modify the behavior of objects in the canvas, either through

external controllers and events or through user interaction

• Because of the above reasons, I really wanted something that

returned to Smalltalk's concept of a Model-View-Controller as separate concepts

So, I suppose to bring a long answer to your question to a conclusion... yes, I did consider Inkscape's canvas but I really wanted something that didn't tie the geometrical structure (model) to Gtk or the display (view and controller), and at the time it looked like more work to extract the canvas from Inkscape (or any of the other apps) and rewrite it as a cairo based canvas, as opposed to rewriting glcanvasmm as a cairo based canvas.

But, I'm always open to either: (1) Using sp_canvas if it makes sense (2) Looking to sp_canvas as a model for improving the papyrus canvas

Great! Ok, I hope we can work towards a model of collaboration.

With respect to (2), I know there are many aspects of the papyrus canvas that are ripe for improvement. In particular, I've been looking for an easy to use API first and speed second. That doesn't mean I'm not concerned about speed... just that it is currently second in priority.

This seems to be the same strategy for cairo.

...

We are trying to modularize our code more so that we can help other projects and get more contributors.

That sounds great. I think there are many pieces of Inkscape that could be reused all over the place if they were structured into libraries.

Yes, we are working towards this. Maybe you could recommend pieces you would like that we could work to box up :)

...

Plus, we want the benefits of Cairo on our app.

Which is a huge benefit. That's another reason for the separation between papyrus and papyrusmm. Papyrus renderables only require a cairo context to draw into, and thus only has a dependency on cairomm.

Wow, cool!

Also, just browsing through the Inkscape repository, it looks like there is a lot of duplicative effort between the Inkscape codebase and cairo. For example:

88 void sp_curve_reset(SPCurve *curve); 89 90 void sp_curve_moveto(SPCurve *curve, NR::Point const &p); 91 void sp_curve_moveto(SPCurve *curve, gdouble x, gdouble y); 92 void sp_curve_lineto(SPCurve *curve, NR::Point const &p); 93 void sp_curve_lineto(SPCurve *curve, gdouble x, gdouble y); 94 void sp_curve_lineto_moving(SPCurve *curve, gdouble x, gdouble y); 95 void sp_curve_curveto(SPCurve *curve, NR::Point const &p0, NR::Point const &p1, NR::Point const &p2); 96 void sp_curve_curveto(SPCurve *curve, gdouble x0, gdouble y0, gdouble x1, gdouble y1, gdouble x2, gdouble y2); 97 void sp_curve_closepath(SPCurve *curve); 98 void sp_curve_closepath_current(SPCurve *curve);

From a cursory scan it looks like these and other methods could be eliminated by moving to cairo. And, if there is some optimization you have that cairo doesn't, I'm sure Carl would gladly accept patches.

Yes, agree. He sits in our channel all the time, so we are all buddies :)

...

If you get a chance, please check out sp-canvas.cpp which is our main canvas code. It works really well:

http://inkscape.svn.sourceforge.net/viewvc/inkscape/inkscape/trunk/src/displ...

I have... along with many of the canvas items as well. There are some great things there.

...

Also, please forward this onto your project list so others can see.

Not a problem.

Great Rick, lets keep the dialogue happening and hopefully great collaboration we can aim towards :)

Jon

---

Rick