Re: sodipodi ...

[Lauris Kaplinski <lauris ariman ee>]

Hi Michael!

On Mon, 17 Apr 2000, Michael Meeks wrote:

> 	I'm extremely interested in your sodipodi app. There are also a
> number of pipedreams I have had floating around for a while not getting
> done. Just so they can be trialed by flame I cross-post here.
> 
> 	a) How is document / view done in sodipodi ?
> 
> 	IMHO doing document-view with the canvas is currently evil and
> involves writting a load of but-ugly, inflexible support code that is
> somewhat error prone. I see no reason why with a tad. of cunning logic
> that we cannot implement a thin and generic canvas_mv_ set of functions
> that would proxy each item and distribute arguments and events as
> neccessary, giving trivial doc/view support to all canvas users ( which
> will I think be increasingly neccessary in future ) ( this was one
> requirement of the dia people to move to the canvas ).

Hmmm... actually I think that CanvasItems should be and remain the view
part of model-view architecture. The reason is simple - multiple
inheritance (the lack of it).
Days ago I derived all sodipodi objects from CanvasGroup (i.e. to derive
SPGroup from SPItem, I had to derive SPItem from CanvasGroup). But if the
model part growed fatter, there was growing need of simple common
ancestors, from which derive completely non-graphical objects. Forcing the
base object to be anything other than GtkObject (GObject) seems evil to
me...

On the other hand - model should not depend on initialized Gtk+, because
initializing Gtk+ requires running X - but I'd like extremely, if as much
program functionality as possible is present without X running. Sodipodi
currently can print from console - I'd like to extend that to SVG->bitmap
conversion ant other things.

Currently I cannot say about program, started as bonobo component, which
X display (the container's one or local) it uses for Gtk+ initializing.
But theoretically bonobo component shouldn't also need local X running.

Multiple views will also break current group hierarchy model - think
about bonobo component embedded into another applications canvas (and into
other applications whatever group), but at the same time edited in
separate window, being in its own applications canvas and its group.
I.e. object can be part of several trees with different topology.

> 	b) Printing; does sodipodi print ?
> 
> 	Another balmy project I envisage is a bit of code to traverse a
> canvas hierarchy, and render the a group scaled do a certain width/heigh
> to a GnomePrintContext. Clearly this will only work well for standard
> canvas components, but I suppose the single print method neccessary could
> be hooked into the object data for exotic itmes [ I know, class data in an
> instance sucks ]. Presumably if printing is not implemented, and this is
> thought to be a good idea it would be extremely helpful for other people
> to genericise it ( and come GTK 1.4 each canvas object can have a print
> interface ).

My vision:

Canvas should have its own set of imaging functions - usually wrappers
around libart or Gdk drawing functions. Then we can fool canvas item to
render itself to every media we have those wrappers implemented - simply
replacing these on (whatever serves as drawing root object) - the way
similar GnomePrintRGBP fools canvas items to draw themselves into RGB
buffer.
For more serious projects the printing functionality of CanvasItems
probably is not sufficent anyway (think of color separation etc.)

Just my thoughts...

Regards,
Lauris