Le mar, jun 12, 2001, à 12:47:18 -0500, Lars Clausen a écrit:
> > Both these functions pointers would be members added at the end of struct
> > RendererOps, and would be totally optional (ie, diagramdata.c's routines
> > will check for NULL members, and either repeatedly check, or fill the
> > renderer->ops with stubs. Hmmm. Fill with stubs, that makes the code
> > easier, costs as much cycles and one less prediction entry).
>
> Sounds like a good implementation plan. Only the FEATURE and SHAPE groups
> don't really solve the problem, as all you can really do at this level is
> group.
FEATURE is to say something like "these four segments and these four arcs
are really a rounded rectangle, here's the corresponding Rectangle and
corner radius (ie, gpoint hints in fact is a pointer to struct {Rectangle
rect; real corner_radius). SHAPE is an alias for OBJECT (dunno if that
specialisation is really necessary).
> Somebody (I forget who) suggested having some more complex shapes (arrows,
> rounded rectangles etc) have their own rendering function, but have a
> default that uses the more primitive functions. Of course, we only want a
> limited amount of these, or the renderer structure becomes rather large,
> but at least having them for the basic shapes would be good.
OTOH, we could have have FEATURE_ARROW etc. Both options are open (I'd think
have renderers give NULL ops pointers for optional functions, and have
something in diagramdata fill in stubs & helpers, so we don't need to test
for the presence of this or that function, could be a very nice simplification,
however. renderer->ops->predraw_string() is an obvious candidate... ).
-- Cyrille
--
Grumpf.
_______________________________________________
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
