Re: UrShapes coding update

[Cyrille Chepelov <chepelov calixo net>]

Le mar, jui 31, 2001, à 11:21:39 +0200, Andre Kloss a écrit:

> > it would be nice if that code was guarded by a --enable option in
> > configure.in ; with that detail, yes it'll be good to see it.
> Good idea, Cyrille. Do you mean that we could incorporate the stuff in
> the Dia cvs tree?

It's always easier, for testing purposes, to have a patch which integrates
into a known version (be it "recent enough" CVS or a release) with the
minimum hassle -- basically, piped through "patch -p1"). And, if the thing
(whatever the thing is) looks good, but looks to have disruptive abilities
(until wholly hashed, squashed and bugfixed) or is controversial, then it
can obviously ease acceptance if it remains an option (usually disabled by
default). When there's no more question that said module is really useful
and good, it's always time to reverse the default, or even to remove the
optionality (there are practical cases where making things optional is
difficult ; as John pointed out, in the case of UrShapes, it should be
trivial at least until UrShapes make themselves unavoidable).

I'm not in position to decide the inclusion of UrShapes, but shown with
working clean code and the configure.in machinery, and actual demonstration
of usefulness (even if the whole thing is not totally finished), I don't see
why I would oppose (even if, in the long run, I'd like to keep the number of
different ways to define an object limited. Something like keeping Classic
for building "ways to define objects" only, and for the objects/shapes
proper, Shapes, StdProp and perhaps some "disruptive technology" :-) )

	-- Cyrille

-- 
Grumpf.