To hopefully answer the comments of both Tom and Thomas -
I'm only raising this because there seemed to be some criticism of my
plans to do this previously.
This is nothing to do with replacing the PGML stored in the zargo with SVG.
It is actually only replacing one class in GEF but that replacement
adds several jar batik jar files to our download.
That class being replaced is the one called in ArgoUML when doing
File->ExportGraphics and chooisng a file type of SVG.
All other Java2D classes in the system use Graphics2D but GEF goes
back to such an old age that it only uses the Graphics class for its
SVGWriter.
As a result all methods in GEF of that use a Graphics class have to
assume that this might not be a Graphics2D class and contain
conditions like this in FigLine
public int drawDashedLine(Graphics g, int lineWidth, int x1, int y1,
int x2, int y2, int phase, float[] dashes, int dashPeriod) {
if (g instanceof Graphics2D) {
return drawDashedLineG2D((Graphics2D) g, lineWidth, phase, x1, y1,
x2, y2, dashes, dashPeriod);
}
// There follows from here lots of code to handle the (g
instance of Graphics) that is only applicable to SVGWriter
//.....
//.....
....
..
}
I think all modern Java code can assume Graphics2D is the Graphics
class being used and it is only the ancient SVGWriter that prevents
this in GEF.
Once we have that class replaced in GEF with the Batik equivalent then
the conditional code above can also be removed from many GEF classes.
This also fixes a few defects in GEF (e.g.
http://gef.tigris.org/issues/show_bug.cgi?id=339).
I had previously proposed using batik but it had been suggested that
updating the SVGWriter class would be a fairly simple task. So I held
back hoping that work would happen.
Nobody has chosen to do that work though. I'm not blaming anyone for
that but I want to do something to move forward. Even if batik is an
over the top solution I would prefer to move ahead with this to
simplify the rest of the GEF code, get some bugs fixed and give an
option of some better presentation in ArgoUML than wait for some work
that nobody is doing.
I would still drop my suggestion of someone will volunteer to fix
these things in GEF in some other way but I doubt anyone really has
time for this. The person I think can do this I would prefer
concentrated on work elsewhere anyway if they can :-)
Tom made a mention of replacing GEF. That's another reason I don't
want anyone spending too long in GEF finding the best solution and I
suggest the quick easy fix of Batik. There is no plan to push GEF out
at the moment but I am planning to try and separate the GEF knowledge
out of core ArgoUML and wrap it into a separate module (a common
diagram modules that all other diagram modules will rely on). Once
that is done it will be easier to explore options to swap GEF out for
something else.
Bob
On 16 May 2011 18:56, Tom Morris <tfmor...@gmail.com> wrote:
> On Mon, May 16, 2011 at 7:49 AM, Bob Tarling <bob.tarl...@gmail.com> wrote:
>
>> I'd like to return to an old thread -
>> http://argouml.markmail.org/thread/dnjazv53pp24yjgf
>>
>> It has been pointed out that GEF could be improved as it stands
>> (without batik) for better Java2d support but nobody is doing this. As
>> I'm sure you're aware I'm already fairly busy concentrating on UML2
>> functionality.
>>
>> If we use Batik it will add some amount of extra jar files to the
>> ArgoUML download but it will leave less code to be maintained in GEF,
>> remove any effort to fix SVGWriter in GEF and allow all the complex
>> code in GEF that tries to allow the ancient Graphics class to be
>> removed.
>
> I'm confused as to how Batik will have any effect on the
> Graphics2D-ness of GEF. Are you proposing that GEF be replaced with
> Batik? I didn't think it performed the same function.
>
>> From there we may be able to make use of sexier looking fill gradients
>> in Figs and plan for a better mechanism to use for line widths,
>
> This requires work in GEF (or its replacement), the ArgoUML
> application, and whatever component is used for SVG generation.
>
>> If someone says that they definitely will fix GEF to make it entirely
>> Graphics2D friendly then fine I won't bother with batik. However if
>> that is distracting anyone from UML2 then that is not really a good
>> thing either.
>
> I pushed a long time ago on replacing GEF, so I'm not opposed to that,
> but it's not clear to me how Batik can be used as a replacement.
> Taking advantage of the Graphics2D capabilities of Batik won't happen
> until GEF supports Graphics2D (or it's replaced with something that
> does).
>
> Tom
>
> ------------------------------------------------------
> http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2738279
>
> To unsubscribe from this discussion, e-mail:
> [dev-unsubscr...@argouml.tigris.org].
> To be allowed to post to the list contact the mailing list moderator, email:
> [li...@tigris.org]
>
------------------------------------------------------
http://argouml.tigris.org/ds/viewMessage.do?dsForumId=450&dsMessageId=2738330
To unsubscribe from this discussion, e-mail:
[dev-unsubscr...@argouml.tigris.org].
To be allowed to post to the list contact the mailing list moderator, email:
[li...@tigris.org]
