Re: pending commit: GraphicsNodeRenderContext param in geom methods

[Thierry Kormann <Th...@sophia.inria.fr>]

> I hope to have the conversion done in my own codebase today, regression
> test it,
> and then commit.  But if someone else has a big commit today, either
> I would request that they wait and do an update, or else I can merge my
> changes later (probably not tomorrow, it could delay this into next
> week).

Before changing anything, I really would like to all others about this issue. I 
really prefer to change/clean the whole APIs and classes before changing code 
or add new features.

I am a bit nervous about modifing lots of files before cleanup is made. I know 
that's only an additional parameter but I *really* modify the dependencies 
between the package.

So, next week, I would like to start a discussion about the modifications I 
would like to do in Batik and the ones you would like and then start cleaning 
the API (without any new features or those that can be easily removed).

So, please, could you want before performing any changes?

And, if all of us can already think about the things they would like to clean 
or document or illustrate with examples... that would be great.

One of the bigest topic as far I am concerned is : "remove the refimpl packages 
and provide a nice, well documented set of concrete packages."

Any comment?
Thierry.

-- 
Thierry Kormann
email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
Koala/Dyade/Bull @ INRIA - Sophia Antipolis

Re: pending commit: GraphicsNodeRenderContext param in geom methods

[Thomas E Deweese <th...@kodak.com>]

>>>>> "TK" == Thierry Kormann <Th...@sophia.inria.fr> writes:

>> I think this should wait for after 1.0.  As I said, my opinion is
>> that we should make only incremental changes until 1.0 (mid-to-end
>> of January?)

TK> I really don't think so. The purpose of the 1.0 is to provide
TK> static features with a clean and well documented API. We already
TK> have many users (I do :) and we need give them an API on which
TK> they can rely on.

    Isn't this a good reason to do this now rather than wait?

TK> That's why we can wait. I don't want to release a major version
TK> with an API that will changed anyway. We can discuss about that
TK> next week I think.

    This change _must_ come, given that sooner is usually better than
later for this sort of thing.  Unless you have ideas on removing
GraphicsNodeRenderContext, which has been part of the design since
very early on.

Re: pending commit: GraphicsNodeRenderContext param in geom methods

[Bill Haneman <bi...@ireland.sun.com>]

Thierry Kormann wrote:
> 
> 
> Before changing anything, I really would like to all others about this issue. I
> really prefer to change/clean the whole APIs and classes before changing code
> or add new features.

I agree that an overhaul would be nice but I don't think that the
schedule
really allows it now: Vincent is talking about 1.0 in January, there are
some
key text features which we need but we must pick and choose which API
changes
to make.

I really think that there is no good alternative to my proposal with
respect
to TextNodes, we have to do this in order to provide the features we
need.

> I am a bit nervous about modifing lots of files before cleanup is made. I know
> that's only an additional parameter but I *really* modify the dependencies
> between the package.

I am not sure what your objection is here, I am doing clean compile
with extensive regression tests.

> So, next week, I would like to start a discussion about the modifications I
> would like to do in Batik and the ones you would like and then start cleaning
> the API (without any new features or those that can be easily removed).
> 
> So, please, could you want before performing any changes?

I really believe that I have to start this process immediately.  I will
not really be available after next Thursday and there will be
lots of other interruptions next week.  In short, I will have very
limited time before January, except in isolation (without CVS access).
And I can't do anything more until these changes are made.  I don't want
my own codebase to diverge too far in isolation!

The change I am making is not really architectural, is is an incremental 
change which will do no harm.  At this point I think incremental changes
are best, 
and the one I am doing now sets the stage for improvement of the text
support in
a way that will require no further changes to the rest of GVT and
bridge.

> And, if all of us can already think about the things they would like to clean
> or document or illustrate with examples... that would be great.
> 
> One of the bigest topic as far I am concerned is : "remove the refimpl packages
> and provide a nice, well documented set of concrete packages."

I think this should wait for after 1.0.  As I said, my opinion is that
we
should make only incremental changes until 1.0 (mid-to-end of January?)

> Any comment?
> Thierry.
> 
> --
> Thierry Kormann
> email: Thierry.Kormann@sophia.inria.fr  http://www.inria.fr/koala/tkormann/
> Koala/Dyade/Bull @ INRIA - Sophia Antipolis
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
> For additional commands, e-mail: batik-dev-help@xml.apache.org

-- 
--------------
Bill Haneman
+1 353 1 849 0495