This is a continuation of a sidetrack discussion from #540.

I propose to pull all the graphics related classes out of fwt into a new pod. Classes to be moved:

• Brush
• Color
• Font
• Gradient
• Graphics
• Image
• Insets
• Pen
• Rect
• Size

I've used this separation in a previous system I designed and it works out well. For example the normalized graphics API can be implemented to model/draw CSS, SVG, PDF, as well to the screen via FWT. Most of these classes have already been designed to use string formatting based on CSS.

I didn't make the separation at first to keep things as simple as possible. But now that we are potentially talking about modeling graphical primitives for CSS with an API, I think it might make sense to future proof this API now. It does cause a little pain to have these classes be independent from an underlying technology like SWT or AWT, especially some of the more complicated geometry/polygon methods. But I half designed these classes with this in mind, so I don't think it should be too bad.

So my two questions:

• Do we want to make this breaking change?
• What should the new pod be called?

I wonder, how about g2d to cover standard graphics apis, maybe later with vector graphics stuff thrown in; maybe later a similar g3d pod for 3D openGL/directX wrapper APIs?

I sort of like gfx.

Either gfx or draw would be good.

I like draw.

I would also suggest separating out Size, Rect and maybe Insets into a separate geom pod. This is a little offtopic but it would be great if Fan supported Size literals e.g. 10in, 25.4cm, 254mm.

Do we want to make this breaking change?

Yes. This is a good change, assuming all the above objects are strictly data objects: i.e. their methods and attributes store, verify, and manipulate data, but they do not interact with the outside world. In this way, they can be used across multiple platforms with ease.

What should the new pod be called?

g2d correctly suggests 2d graphics, but may imply rasterization; gfx sounds like it might be something higher level, contain effects for graphics -- so I don't like it. draw is horrible, because it suggests this package contains drawing routines.

I'd suggest: gprim, gbase, base2d, etc.

model2d

draw is horrible, because it suggests this package contains drawing routines.

Actually it would. Assuming Brian and I are on the same page, this pod would have an abstract drawing interface, which would be backed by SWT on FWT, Canvas for HTML, and likewise for PDF, SVG, etc, etc. There's where you leverage all the power of separating all this stuff out.

Actually it would. Assuming Brian and I are on the same page, this pod would have an abstract drawing interface

Ah, OK, the Bridge design pattern. Beautiful!

In that case, any of the above names is fine with me, though I'd lean toward g2d because g3d is an obvious extension at some point in the future.

Really looking forward to this!

OK, I think I want to do this change.

Note sure I really love any of those names. The ones I like best:

• gfx
• g2d
• f2d
• fan2d
• art

I don't think a verb like draw is appropriate because often these APIs are used in a declarative manner.

art is probably too far-fetched - I'd vote for gfx since although I like fan, it doesn't have to be written / implied everywhere...

I like gfx best if it's going to include effects -- fades and blends and such as mentioned elsewhere. Then the name suggests either graphics or graphic effects, both of which would be valid.

I'll withdraw draw and vote for gfx.

What about gdi? It's the term Win32 uses to describe this functionality, but I'm not sure if it's a trademark or a generic term.

fig2d, for Fan Ima G ery

I vote g2d.

I vote gfx

Let's say the new package will be called gfx.

I will try to do the move for the next build.

In general I think it will work out pretty good. The only real issue is that the dispose methods on resource classes like Color, Font, Image can't be exposed anymore like they are today (since an instance may be used in multiple contexts such as FWT, SVG, or PDF). I already have an indirection between these classes and the actual SWT resources, so the dispose methods will probably migrate to Desktop which serves as kind of the Sys for FWT. Same for things like Color.sysFg, etc.

If anyone has an interest, an implementation of gfx to render PDF would be a really cool and useful side project.

If anyone has an interest, an implementation of gfx to render PDF would be a really cool and useful side project.

Based off experience, we probably just want a wrapper API around something like iText here, vs writing one from scratch.

Based off experience, we probably just want a wrapper API around something like iText here

And maybe an equivalent for .NET? (I haven't studied what that would be.)

And maybe an equivalent for .NET?

iText has a .NET port - though I'm not sure what the parity is to Java.

I've been looking for an excuse to migrate my PaperClips project to a more platform-neutral API--maybe this is an opportunity for that.

Promoted to ticket #544 and assigned to brian

Ticket resolved in 1.0.42

All the graphics related APIs have been moved into a new gfx pod.

This is actually a pretty cool change because it means we can have one API used to "paint things", but multiple implementations such as SVG, PDF, etc. At some point, Andy will implement this API for the Canvas when you are using Fan to JavaScript.

Plus now we have a normalized API for serializing things like colors and fonts which can be used outside of a Windowing system (such as a headless embedded system).

I left the convenience methods on classes like Font such as height which require a GfxEnv to work. They just route to GfxEnv.current which uses a thread local to associate with the SWT implementation.

System colors, system font, and dispose methods migrated to the fwt::Desktop class. Other than you just need to add using gfx to port to the latest code.

System colors and fonts can also apply somewhat to the web (see here and here) or perhaps other environments. Still, I'm willing to believe that's it's not necessarily easy to make that all work consistently. Maybe HTML/CSS and FWT are best handled differently.

Binding gfx to HTML canvas does sound cool, by the way.

Very clean, and takes Fan in a positive direction.

Maybe HTML/CSS and FWT are best handled differently.

I don't agree. A good abstraction can handle them both. In fact, I don't see any reason why a JS version of FWT cannot be developed (and this is of interest to me if we end up switching to Fan).

I don't see any reason why a JS version of FWT cannot be developed

If someone does accomplish that, then you'd get system colors again, anyway.

I was just meaning that I hadn't investigated deeply enough to complain officially about having system colors/fonts in fwt vs. gfx. I just think it's an issue to consider.

I was just meaning that I hadn't investigated deeply enough to complain officially about having system colors/fonts in fwt vs. gfx. I just think it's an issue to consider.

I am pretty sure system colors don't belong in gfx. For example a gfx implementation to render a PDF document doesn't have any notion of system colors. That is really a OS desktop abstraction (which is currently modeled in fwt). If we did a JS widget toolkit as JohnDG was saying, then that would probably be fwt too (or maybe some shared abstraction between gfx and fwt.

If we did a JS widget toolkit as JohnDG was saying, then that would probably be fwt too (or maybe some shared abstraction between gfx and fwt.

Sounds fine.