Re: GTK+ 2.0 widget for dia

[James Henstridge <james daa com au>]

On Wed, 27 Jun 2001, Cyrille Chepelov wrote:

> Le mer, jun 27, 2001, à 08:44:36 +0200, Xavier Ordoquy a écrit:
>
> > I just looked a bit in diagramdata.c and dia-newcanvas looks pretty
> > similar. I think Jamesh would explain better than I can do how this
> > fits, but looks like it's fine.
> > dia canvas has items (line, rectangle, ...) with some properties
> > and member functions. Amoung them, you can find
> >
> > void (*render)      (DiaCanvasItem *canvas_item, DiaRenderer *renderer,
> >                      DiaRectangle *rect);
> >
> > which looks pretty the same as:
> >
> > (*obj_renderer)(obj, renderer, active_layer, data);
> >
> > The (dia canvas) render is an interface that enables to set width,
> > color, .. and draw points, lines, ....
> > Again this is pretty similar to the dia render.
>
> [snip]
>
> > Hope this will answer your question.
>
> It doesn't completely. One uses of renderers in dia is not only to talk gtk,
> but also talk EPS, PS, PNG, XFIG, LaTeX, and I forget some (like DPS which
> has always been experimental).

While there is currently only a single renderer implementation in
dia-newcanvas (DiaCanvasViewGdk implements the interface), there is
nothing limiting it to just that renderer (and renderers don't have to be
tied to a view, so it should be able to handle export filters).  The
renderer interface is sort of a cross between what is in Dia now and the
GDK drawing primitives.

> Some targets need a pre-rendering of strings (to compute a custom encoding).
> This requires a predraw_string member function (or operation), next to
> draw_string (which, IIRC, dia-newcanvas does have). Actually, predraw_string

Well, the text handling is still not complete for dia-newcanvas.  It is
going to use Pango for rendering, although I am not sure how much will
show through the renderer interface.  It will be interesting to see how
gnome-print handles these things.

> is used about once, in the function of lib/diagramdata.c which checks all
> objects and tells them to draw themselves: it first iterates through all
> objects, gives them a dummy renderer (which uses predraw_string instead of
> draw_string) and ask them to draw themselves into that dummy renderer (this
> isn't really done if the real renderer doesn't need string predrawing). Once
> this is done, the normal processing (ask all objects to render themselves)
> is done.

Well, it is always possible to have two renderer implementations (one
that just does text, and one that does everything else) and call one after
the other for these kinds of cases.  In the case of export filters, you
are just passing an object implementing the Renderer interface to the
canvas's render() method.  There is nothing stopping you from doing this
twice with different renderers.

For the interactive case, you can easily override the expose_event handler
in the derived canvas view, which is responsible for rendering to the
window.

> What I was asking for is to have similar capabilities (perhaps in a saner
> way) included in dia-newcanvas.

One of the aims of dia-newcanvas was to take the best features of Dia's
current canvas (abstract renderers, model/view split, etc), and
GnomeCanvas's best features (a simple canvas item heirachy, simple API).
So far, it feels like a nice clean, extensible system (although there are
still areas that need work).

James.

-- 
Email: james daa com au
WWW:   http://www.daa.com.au/~james/