I see an inconsistency in the naming conventions for style methods at the API and Shape levels. eg - strokeWidth(4) vs shape.strokeWidth = 4
> You mean it should be shape.strokeWidth(4)?

I was referring to the consistency of the 'style' of the setter methods at the API and Shape levels.
API.strokeWidth = 4 and shape.strokeWidth = 4 etc
OR
API.strokeWidth(4) and shape.strokeWidth(4) etc

They obviously need to set colors and stroke widths, but maybe if they need to know what the colors etc are they should keep track of it themselves?

That sounds reasonable. Attribute readers can always be added later if they seem justified based on actual usage.
Update - and it seems like you can read style attributes at the Shape level anyway!

Personally, I don't want anything that is provided by the standard Scala library inside the Staging API

That also sounds reasonable. It also makes the API smaller, which is good.

programmer friendly code completion

Certainly. I see that as a post-feature freeze, pre-release task.

hand-cursor for the SpriteCanvas

Yes. I didn't intend to hi-jack the mouse cursor for Staging, so I was going to make it a settable feature (still on my to-do list). If you want to make it the default cursor, go ahead.

Stroked Shape Styles (this is maybe an area of work-in-progress?)

Yes, it is. The trait wasn't exactly planned and is mostly the result of the Piccolo implementation leaking out, but I think I will keep it.

fill is missing?

It's inherited from Shape.

strokeWidth(4) vs shape.strokeWidth = 4

You mean it should be shape.strokeWidth(4)? I find that more confusing; (API.)strokeWidth changes the global state, and shape.strokeWidth changes the shape's state.

I'm not 100% sure about the strokeWidth / strokeWidth_= shape methods, though. They might be taken out for 1.0 and later be replaced by some other kind of mechanism.

There seem to be no style attribute read methods at the API level?

I'm waffling a bit between making the API convenient for the programmer and forcing the programmer to pay attention. They obviously need to set colors and stroke widths, but maybe if they need to know what the colors etc are they should keep track of it themselves? Maybe not?

Do we want to fill out the Calculation/Trig functions to match Processing API? Are there other areas of the API that we want to emulate?

Personally, I don't want anything that is provided by the standard Scala library inside the Staging API, including sin, cos etc (PI, HALF_PI etc may be OK, though), but if you want it I'm flexible.

Thread issues etc noted. I've been more busy than I thought I would during the Midsummer celebrations, but I hope to be working again soon.

• We could provide programmer friendly code completion for the Staging API by adding templates for all the Staging methods to CodeCompletionUtils.MethodTemplates. How does that sound?
• I was thinking that we could maybe set the cursor to the hand-cursor for the SpriteCanvas as a whole (it seems to indicate better than the default arrow cursor that you can do stuff (pan/zoom) with the mouse inside the Canvas) . In that case we would not need to push and pop the cursor in the PBasicInputEventHandler inside Input. Thoughts?
• Here are some Issues with Stroked Shape Styles (this is maybe an area of work-in-progress?):
  • Setting of stroke does not repaint correctly
  • Setting of strokeWidth does not work (plus Swing thread issue)
  • fill is missing?
  • I see an inconsistency in the naming conventions for style methods at the API and Shape levels. eg - strokeWidth(4) vs shape.strokeWidth = 4
  • Swing thread issue in the Shape level stroke and strokeWidth methods
• There seem to be no style attribute read methods at the API level?
• Do we want to fill out the Calculation/Trig functions to match Processing API? Are there other areas of the API that we want to emulate?

In particular, the mouse handling: should I thread-capture the registering of the listener, or the insides of the callbacks, or all of it, or… hmm.

My take on things:

• You should run Inputs.init() in the Swing Thread
• the PBasicInputEventHandler callbacks already run on the Swing thread, so you should be fine
• The Staging animation loop runs in the Swing thread, so calls to the mouseX() etc methods from within the animation loop (the most likely case) should be fine
• Calls to the mouseX etc from outside the animation loop would be on the interpreter thread. This should be fine if the vars in Inputs become @volatile vars (@volatile will ensure visibility of the latest mouse positions in the interpreter thread)

I've many times been very grateful for having Kojo/Staging around during this ordeal.

That's very good to hear.

Is there anything else that seems off to you?

Nothing in particular, just an uneasy feeling that there are probably areas that to my eyes are safe but in reality only work by coincidence. In particular, the mouse handling: should I thread-capture the registering of the listener, or the insides of the callbacks, or all of it, or… hmm.

Also, an afterthought:

The stuff that you have done in the past few weeks, despite this major event on the personal front

Dealing with chemotherapy, especially when the outcome is as uncertain as this was initially, means that you really, really need something else to turn your mind to. It should be something that is complicated enough to require concentration, but not so complicated that it frustrates you. It should also be worthwhile but not all-important. If it gives you something to talk about in the hospital room it's a bonus. I've many times been very grateful for having Kojo/Staging around during this ordeal.

Do you have any good links/documents?

Unfortunately no. I just look at the Source (mostly Piccolo, sometimes Swing) when in doubt, and rely on my knowledge of threading to deal with issues of this nature.

I remember that the book: Swing, 2nd Edition by Matthew Robinson, Pavel Vorobiev - had a good explanation of Swing internals in the first or second chapter.

There is of course also the 2.8 deadline to consider. If the transformations aren't done by then, at the very least the current features must be made safe and sound

That sounds sensible.

Once this gets done, basic transformations (translation of shapes, and rotation and scaling of shapes about their origin and the stage origin) seem to be low hanging fruit that could be quickly added without adversely impacting anything else - or so it seems to me.

I'm beginning to suspect that some of it, e.g. the mouse handling, isn't.

It looks fine to me, other than the fact that the vars that are accessible in multiple threads (the swing thread and the Kojo interpreter thread) need to be made volatile. Is there anything else that seems off to you?

Do you want to dig into this? Or do you want me to take an initial stab at identifying and resolving potential problems of this nature within Staging (I can't imagine that there'll be very many, but there could be a few).

I need to understand how it works, so I should at least try to get it working myself. Still, I'll probably need some pointers. For one thing, there doesn't seem to be very much documentation on the web, apart from the Piccolo2d site. Do you have any good links/documents?

There is of course also the 2.8 deadline to consider. If the transformations aren't done by then, at the very least the current features must be made safe and sound, and I'm beginning to suspect that some of it, e.g. the mouse handling, isn't.

I'm still a bit distracted as well. The week after I signed the agreement my father was diagnosed with acute leukemia

I'm very sorry to hear that.
The stuff that you have done in the past few weeks, despite this major event on the personal front, is pretty amazing!

This week he's riding out the aftereffects of his third round of chemotherapy and the prognosis is really good

That sounds great. All the best to him in this battle!

but many times I catch aspects of modern stuff like concurrency and GUI lowlevels too far down the neck and they twist around and bite me.

It happens to the best of us. That's why STM and Actors are all the rage these days!

Do you want to dig into this? Or do you want me to take an initial stab at identifying and resolving potential problems of this nature within Staging (I can't imagine that there'll be very many, but there could be a few).

Some things to take note of:
- all Piccolo writes should be on the GUI thread
- all reads of Piccolo attributes should also be on the GUI thread! Otherwise, if you write an attribute and then read it, you get a different value. Utils.runInSwingThreadAndWait() can be used for this (see Figure.apply() for an example).

Hope you see what's going on here?

Yes. This kind of thing still gets me.

I'm quite intelligent, and an experienced, skilled programmer iissm, but many times I catch aspects of modern stuff like concurrency and GUI lowlevels too far down the neck and they twist around and bite me.

Case in point, I had noticed occasional leaks from withStyle, but couldn't see anything wrong with the code inside Style and thought I'd eventually find the bug somewhere else. My line of reasoning was that I was just calling Figure methods (setFillColor, setPenThickness etc) and they are running in the swing thread, so that's OK. After some more careful testing I realize that yes, I really need to bundle the whole save/restore operation into the swing thread.

I'm determined to learn, however. I wouldn't have minded much if programming had stayed with single-thread 7-bit text applications, but I'm going to follow where programming goes.

(I'm still a bit distracted as well. The week after I signed the agreement my father was diagnosed with acute leukemia, which isn't good news at any age but really bad news if you're over 70 years old. This week he's riding out the aftereffects of his third round of chemotherapy and the prognosis is really good, so maybe I'll have more brain power available in the future :) )

You've called π Pi; maybe for convenience and consistency (for Processing programmers) we should call it PI and also add HALF_PI, QUARTER_PI, and TWO_PI.
Also, why not define radians as…

Done

Oops yes, style save/restore was a bit under-implemented. Should work now.

I still see the problem I encountered yesterday. You can trigger the issue by changing the order of the lines:

S.background(black)
S.stroke(color(228, 228, 228))

…in the Clock example. If the stroke is set before the background, the clock outline and hands are drawn in red instead of gray (on my system. There's a race condition here, so results could potentially be different on your machine).

After digging into this, I discovered an old friend! Instead of trying to describe the problem in a lot of words, I'll just show some code that fixes the problem:

object Style {
var savedStyles =
new scala.collection.mutable.Stack[(Color, Color, java.awt.Stroke)]()
def save {
Utils.runInSwingThread {
savedStyles push Tuple3(
Impl.figure0.fillColor,
Impl.figure0.lineColor,
Impl.figure0.lineStroke
)
}
}
def restore {
Utils.runInSwingThread {
if (savedStyles nonEmpty) {
val (fc, sc, st) = savedStyles.pop
Impl.figure0.setFillColor(fc)
Impl.figure0.setPenColor(sc)
Impl.figure0.lineStroke = st
}
}
}

The key is making this stuff run in the swing thread. Without that, in the following code:

S.stroke(color(228, 228, 228))
S.background(black)

the background call saves the old (red) color before the stroke call is able to change the pen color in the swing thread.

Hope you see what's going on here?

I haven't checked in the (very local) fix because this general issue needs to be taken into account at potentially other places within Staging (any time a Swing/Piccolo controlled attribute is being read or written).

Thoughts?

The line() method […] start x and y and the end x and y […]

Sure, done. That way fits better with SVG elements, too. The only reason for the x, y, w, h format was similarity to rectangles et al, and that was a weak argument.

I've also changed vector accordingly.

background() - clobbers the current stroke

Oops yes, style save/restore was a bit under-implemented. Should work now.

minute() - works incorrectly in my timezone (GMT + 5:30). I have fixed this (and checked in the fix).

Thanks, I had no idea.

I added some trigonometry functions

OK, I didn't bother with standard math functions since they can be used anyway, but maybe this is a good idea.

You've called π Pi; maybe for convenience and consistency (for Processing programmers) we should call it PI and also add HALF_PI, QUARTER_PI, and TWO_PI.

Also, why not define radians as

def radians(deg: Double) = deg.toRadians

Transformations

Yes, I haven't quite got the hang of them yet. I'm trying to come up with a simple API to use them, but they don't seem to work as they should even when I do it the standard way. Lack of repainting is probably just the tip of the iceberg of my misunderstandings. It would be good if you took a look at it.

Wiki syntax. How do you process it? Scaladoc2

Ah no, that's too advanced for me. I use an AWK script to collect lines starting with "\s*\/\/W" and dump them in a file, and then I use diff within gVim to patch in the changes. Documentation lines that I don't want on the wiki page get their "W" changed to "M", or the "//W" comment changed to a Scaladoc comment.

I've pushed the changes mentioned here now.

The first example that I have written is: http://code.google.com/p/kojo/wiki/StagingClockExample?ts=1277127014&updated=StagingClockExample

Here's some feedback based on my experience/work with Staging so far:

• The line() method takes a start x and y, and a width and height. This is different from the line() method in the Processing API, which takes the start x and y and the end x and y. To me the latter seems more natural. Plus if we stick with the latter, it makes it easier for Processing folks to migrate to Staging. Thoughts?
• background() - clobbers the current stroke and sets the stroke to the default stroke.
• minute() - works incorrectly in my timezone (GMT + 5:30). I have fixed this (and checked in the fix).
• I added some trigonometry functions (and I just realized that I got the spelling of trigonometry wrong inside staging.scala! Will fix this on the next checkin).
• Transformations - don't repaint and show the updated shape. I'll have more feedback on this after I experiment with this some more.

I noticed that a lot of your scaladoc is in Wiki syntax. How do you process it? Scaladoc2 or something?

How about p.onX / p.onY?

That sounds good.

How's stuff coming along with transformations and styles (I see from your repo that you've been working in this area)? Any complications?

Fyi - I'm gonna be off (this time for a about a week) again in a couple of days. I'll take a closer look at what you're upto after that, and will hopefully write a sample or two of my own (for Staging) at that point.

these seem like good candidates […]

Sure. I'll take transformations next.

Yup, the terminology doesn't sound right.

Meh. But yeah. How about p.onX / p.onY?

Well, later then. Have a good vacation!

Also: a new example on the wiki page, based on your own Sine of an angle example, but using Staging instead.

Looks great!

For this example I added two methods to Point. For a point p = point(x, y), p.abscissa returns the point (x, 0) and p.ordinate returns the point (0, y). It's not quite the right terminology, but close enough?

Yup, the terminology doesn't sound right. I would think that methods called abscissa and ordinate on a Point would return doubles.

From an earlier message:

(e.g. can you settle for stroke (which I prefer) or do you think it needs to be called setPenColor (which I can live with if it so be))?

setPenColor came from a desire to be kid friendly for the Turtle stuff. Stroke sounds fine for Staging.

Hmm, assert against a regex instead, set a locale in the source, or set a locale in the build?

'Assert against a regex' sounds the most straightforward. We could also use DecimalFormat (which seems Locale sensitive as per its Javadoc).

We probably need to define "ready".

I still need to dig into things, but off the top of my head, these seem like good candidates for the first release:

• Styles (with save/restore or push/pop)
• Mouse support
• Transformations at the shape or stage (or both?) level

Thoughts?

I'm off for a couple of days - so you won't hear from me for a bit…

The other bug didn't appear here with either RC2 or RC3. Hopefully it will stay fixed now.

Also: a new example on the wiki page, based on your own Sine of an angle example, but using Staging instead.

For this example I added two methods to Point. For a point p = point(x, y), p.abscissa returns the point (x, 0) and p.ordinate returns the point (0, y). It's not quite the right terminology, but close enough?

• PointTest.test1() - I could be wrong, but this seems related to the JVM Locale. The test seems to want to represent the decimal point as a comma (is that the Swedish way?), whereas on my machine/JVM (running with the default Locale), decimal points are represented as periods. That leads to an assertion failure.
• ComplexShapesTest.test1 - For this one, using Scala 2.8.0 RC3, I was running into the dreaded exception related to class dependencies not being found for edu.umd.*. I tracked this down to a bug in ScalaCodeRunner (an outdated jar name in the classpath string for the interpreter!). This has been fixed. Quite amazingly, the test (the test code run interactively via the Kojo App, to be precise) was working fine with Scala 2.8.0 RC2!!

Did you check in the tests? I did a pull, but didn't get any test changes…

Oops no. I have now.

I've changed the tests now, and it passes all tests without any change in the executing code.

Did you check in the tests? I did a pull, but didn't get any test changes…

There's no particular reason to 'release' Staging with the Scala 2.8.0-final build of Kojo (I mentioned it because it just happens to be a convenient build coming along in a couple of weeks). Let's see what definition of 'ready' we come up with. We'll then take it from there to determine when to 'release' Staging.

Sound Ok?

It could be. There is a lot I want to add which probably won't be ready in the next few weeks, but most of it isn't necessary for Staging to be useful.

We probably need to define "ready". Is there anything you find missing at this point? Is there anything you'd want to adjust (e.g. can you settle for stroke (which I prefer) or do you think it needs to be called setPenColor (which I can live with if it so be))? Will the examples on the wiki do for sample code, or should I write better ones?

In this case, however, it was the test data that was bad. Specifically, the dumping format changed from %.4g to %.2g when I moved tests from one file to another (note to self, I really need to move the dumping code to an external class so it will be consistent) but didn't change (all) the strings that are asserted against. E.g. "10,20" was compared to "10.00,20.00".

I've changed the tests now, and it passes all tests without any change in the executing code.

A couple of Staging tests are failing. Please take a quick look to see if you can spot what's wrong. Note - I'm running locally with Scala 2.8.0-RC3.

I'm FINALLY getting up to speed again. I've updated the wiki page with some examples and re-arranged the documentation some.

Good to see you chugging along (even as I take a little break at the start of the school summer vacations here in India).

Of course, some more stuff needs to be merged into Kojo now, if you don't mind.

No problems. Will do it today.

I'll publish another Kojo build when Scala 2.8.0 final comes out (most likely within a couple of weeks). Would Staging be ready for its first 'release' by then?

Of course, some more stuff needs to be merged into Kojo now, if you don't mind.

It seems fine so far.

Sounds good.

Also, a quick clarification for something I wrote in an earlier message:

And a multi-sprite animation toolkit (with collision detection etc, along the lines of Scratch/BlueJ) would also be great.

I meant Greenfoot when I said BlueJ.

I think it's better if you do it, both because it will most likely fit in better with your design and because it will probably expose any nasty gotchas in my design that way.

I have taken an initial stab at this. The code is checked it. It compiles. All the tests pass. It must be good ;)

Critical feedback is welcome. There were at least a couple of different ways to do this. I went with a pretty lightweight approach (which I have not been able to find fault with so far).

On a higher level, I'd very much like to see something like Karel the Robot to complement the Turtle approach (I think the Turtle is an ingenious tool, but Karel is pretty nifty, too). Perhaps even something like Scratch, but that's a long shot.

Sounds very cool. Karel the Robot would be a good next step for students who 'graduate' from the Turtle stuff. And a multi-sprite animation toolkit (with collision detection etc, along the lines of Scratch/BlueJ) would also be great. In fact, once you have the latter, you could build the former on it.

I think it's better if you do it, both because it will most likely fit in better with your design and because it will probably expose any nasty gotchas in my design that way.

No problem. I'll do it over the next couple of days.

please think of some 'impressive' samples that we can put under the Samples menu.

Um yes. I've written up quite a few samples but haven't shared them very much yet. This is mostly because I've tinkered with the syntax so much — I have to change the samples back and forth, and I fear that any samples I upload will become incompatible with what Staging actually can do. I will deliver, though.

What might the other stuff be?

Some of it has already been in StagingAPI (at least partially) but was taken out: color modes and settings, styles, time reading, loop control, mouse access. Some of it is pending: transformations, image dump, animations, keyboard access, web access, file access, text handling.

On a higher level, I'd very much like to see something like Karel the Robot to complement the Turtle approach (I think the Turtle is an ingenious tool, but Karel is pretty nifty, too). Perhaps even something like Scratch, but that's a long shot.

Do you want to go ahead and do this (making a package etc), then, before I do a merge?

I think it's better if you do it, both because it will most likely fit in better with your design and because it will probably expose any nasty gotchas in my design that way.

To begin with, it was because of I wanted to explore PVector-based shaping. Then, when we decided not to pursue that idea, I started looking at the existing shape classes to see how I could do Processing-style things with them. The way I see it, it would be very hard to write it, and every effort to develop Staging would risk clashing with future changes/extensions to the Kojo shape class system. A separate shape hierarchy is a way to 1) get around that problem, 2) allow complex shapes, SVG shapes etc to be added and share the same basics, 3) make Staging more cohesive.

Fair enough.

Based on your feedback - I think I'll just import your stuff into Kojo as-is. We'll let Staging and Canvas co-exist as separate 'modules' for now.

I'm not planning to work on Canvas in the near future. Let's see how Staging evolves, and then we can think about what to do with Canvas (we can just retire it if Staging does what it does, and more).

As you add more stuff to Staging, please think of some 'impressive' samples that we can put under the Samples menu.

As I've hinted before, shapes is only one part of what I want to put into Staging

Would you mind talking about this a little bit. What might the other stuff be?

That sounds good. As I've hinted before, shapes is only one part of what I want to put into Staging, and a package is much better than a humongous object. In fact, I would have made it a package myself but using an inner object seemed more appropriate for experimentation.

Do you want to go ahead and do this (making a package etc), then, before I do a merge?

The basic idea here is to make the StagingAPI object as simple as possible, while giving the various Staging classes/objects a place of their own to live in. How does that sound?

That sounds good. As I've hinted before, shapes is only one part of what I want to put into Staging, and a package is much better than a humongous object. In fact, I would have made it a package myself but using an inner object seemed more appropriate for experimentation.

Why two Rectangles - one inside core.shapes, and the other inside Staging?

To begin with, it was because of I wanted to explore PVector-based shaping. Then, when we decided not to pursue that idea, I started looking at the existing shape classes to see how I could do Processing-style things with them. The way I see it, it would be very hard to write it, and every effort to develop Staging would risk clashing with future changes/extensions to the Kojo shape class system. A separate shape hierarchy is a way to 1) get around that problem, 2) allow complex shapes, SVG shapes etc to be added and share the same basics, 3) make Staging more cohesive.

Why a separate draw method in the Shape trait (the core.VisualElement trait already has show and hide methods).

It is different because it creates and draws the shape, while show makes an already existing shape visible. Intuitively, all shapes should stem from a fundamental member of Shape, I think. Still, the way it's done now might not be the best way to do it.

• Looks very nice and clean overall.
• To me, the most natural way of merging this into Kojo appears to be - to move all the classes/objects inside the StagingAPI object into a new staging package. The 'facade' methods would remain inside StagingAPI. The basic idea here is to make the StagingAPI object as simple as possible, while giving the various Staging classes/objects a place of their own to live in. How does that sound?
• Some additional questions:
  • This one is a particular case of a more general question. Why two Rectangles - one inside core.shapes, and the other inside Staging?
  • Why a separate draw method in the Shape trait (the core.VisualElement trait already has show and hide methods).

Do some of the answers to the above relate to the desire to have a non-overlapping sandbox for Staging?

The comments and variable names for the ellipse-creating methods were misleading, so I changed them. There was also a bug in the translation from an SVG line element to the corresponding line-creating method.

I've pushed a changeset with these corrections, and updated both documentation pages.

In the file ScalaCodeRunner.scala, I've added the Staging namespace to the interpreter

+ interp.interpret("val Staging = predef.StagingAPI")

and, of course, the StagingAPI object

+ object StagingAPI { ---etc etc---

In the file figure/Figure.scala, I added a method to let my testing code look at shapes added to the canvas:

+ def dumpChild(n: Int): PNode = { + try { + currLayer.getChild(n) + } + catch { case e => throw e } + }

and declaractions for shape classes I added:

+ type FRRectangle = FigRoundRectangle + type FPath = FigPath

and corresponding drawing methods:

+ def roundRectangle(p1: Point, p2: Point, rx: Double, ry: Double) = { + val rrect = new FigRoundRectangle(canvas, p1, p2, rx, ry) + Utils.runInSwingThread { + rrect.pRect.setStroke(lineStroke) + rrect.pRect.setStrokePaint(lineColor) + rrect.pRect.setPaint(fillColor) + currLayer.addChild(rrect.pRect) + currLayer.repaint() + } + rrect + } + def polyLine(path: kgeom.PolyLine): kgeom.PolyLine = { + Utils.runInSwingThread { + path.setStroke(lineStroke) + path.setStrokePaint(lineColor) + path.setPaint(fillColor) + currLayer.addChild(path) + currLayer.repaint() + } + path + } + def path(descriptor: String): FigPath = { + val path = new FigPath(canvas, descriptor) + Utils.runInSwingThread { + path.pPath.setStroke(lineStroke) + path.pPath.setStrokePaint(lineColor) + path.pPath.setPaint(fillColor) + currLayer.addChild(path.pPath) + currLayer.repaint + } + path + }

I added a few files:

figure/FigRoundRectangle.scala figure/FigPath.scala test/. . ./Staging/ScreenMethodsTest.scala test/. . ./Staging/ShapesTest.scala test/. . ./Staging/Shapes2Test.scala

In the file core/Figure.scala, I added declarations for the shape types and methods:

+ type FRRectangle <: RoundRectangle with VisualElement + type FPath <: Path with VisualElement + def roundRectangle(p1: Point, p2: Point, rx: Double, ry: Double): FRRectangle + def polyLine(path: net.kogics.kojo.kgeom.PolyLine): net.kogics.kojo.kgeom.PolyLine + def path(descr: String): FPath

In the file core/shapes.scala, I added some methods for Point:

 class Point(val x: Double, val y: Double) { + def +(that: Point) = new Point(this.x + that.x, this.y + that.y) + def -(that: Point) = new Point(this.x - that.x, this.y - that.y) + def unary_- = new Point(-x, -y) override def toString = "Point(%.2f, %.2f)" format(x, y) }

In the file core/shapes.scala, I added some methods for Point:

+class RoundRectangle( + override val bLeft: Point, + override val tRight: Point, + rx: Double, ry: Double +) extends Rectangle(bLeft, tRight)

and the class Path:

+class Path(val descriptor: String)

That should be it.

I suggest the following procedure:

1. I'm currently reverting/taking out all changes aren't directly coupled with the contents of StagingAPI
2. When that is finished (which should be later today), you should look it over and tell me which parts you find questionable, if any
3. I make changes as necessary and hand it over to you

ETA: finished step 1 and pushed the result.

1. have a single consistent class hierarchy
2. bring more kinds of shapes into it
3. make it testable
4. encapsulate more than just the dimensions of the shape
5. …

and at least 1—3 can be done with calls to Figure methods. When that baseline is stable and testable, we can discuss deeper implementation issues.

Note - I have pulled the latest changes from your clone/branch, so hopefully I will just need to plop in the modified ScalaCodeRunner to be up and running…

Currently, it looks like

 trait Shape { def draw: Unit } trait BaseShape extends Shape { val origin: Point } // snip several traits class Dot(val origin: Point) extends BaseShape { private val (x, y) = (origin.x, origin.y) def draw { tCanvas.figure0.point(x, y) } def toLine(p: Point): Line = Line(origin, p) } object Dot { def apply(p: Point) = { val shape = new Dot(p) shape.draw shape } }

But I wanted to make it even more self-contained and create PPath instances directly and add them to the canvas, like this:

 trait Shape { val ppath: PPath def draw { tCanvas.figure0.ppath(ppath) } protected val canvas = SpriteCanvas.instance net.kogics.kojo.util.Throttler.throttle() ppath.setPaint(style.fill) ppath.setStrokePaint(style.stroke) ppath.setStroke(style.strokeStyle.toStroke) def hide() { ppath.setVisible(false) canvas.repaint() } def show() { ppath.setVisible(true) canvas.repaint() } } trait BaseShape extends Shape { val origin: Point } // snip class Dot(val origin: Point) extends BaseShape { val (x, y) = (origin.x.toFloat, origin.y.toFloat) val ppath = PPath.createLine(x, y, x, y) def toLine(p: Point): Line = Line(origin, p) } object Dot { def apply(p: Point) = { val shape = new Dot(p) shape.draw shape } }

Which won't work, instead it gives me the exception I quoted earlier.

You can set this in nbproject/project.properties:
scalac.unchecked=yes

I forgot to mention - this needs to be done within the KojoEnv Module.

1. Can you tell me how to add the "-unchecked" flag when building?

You can set this in nbproject/project.properties:
scalac.unchecked=yes

2. Do you have any idea what the following problem is?

SEVERE [net.kogics.kojo.xscala.ScalaCodeRunner]: Interpreter Problem
java.io.IOException: class file needed by ScalaCodeRunner is missing.
reference value edu of package <root> refers to nonexisting symbol.

The only package in there that starts with edu is the Piccolo stuff. It looks like you're making use of something inside Piccolo that has a dependency which is not on the Classpath.

Some questions for you:
Are you using any Piccolo classes directly within your code?
Did you start seeing this problem after adding a particular chunk of code within Kojo?

1. Can you tell me how to add the "-unchecked" flag when building?

2. Do you have any idea what the following problem is?

When running the following script:

import Staging._
clear
Screen.size(250, 250)
val a = Point(15, 15)
dot(a)

I get:

SEVERE [net.kogics.kojo.xscala.ScalaCodeRunner]: Interpreter Problem
java.io.IOException: class file needed by ScalaCodeRunner is missing.
reference value edu of package <root> refers to nonexisting symbol.
at scala.reflect.generic.UnPickler$Scan.errorMissingRequirement(UnPickler.scala:755)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan.errorMissingRequirement(UnPickler.scala:44)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan.errorMissingRequirement(UnPickler.scala:29)
at scala.reflect.generic.UnPickler$Scan.readSymbol(UnPickler.scala:195)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.reflect.generic.UnPickler$Scan.readSymbolRef(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.readSymbol(UnPickler.scala:178)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.reflect.generic.UnPickler$Scan.readSymbolRef(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.readSymbol(UnPickler.scala:178)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.reflect.generic.UnPickler$Scan.readSymbolRef(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.readSymbol(UnPickler.scala:178)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.reflect.generic.UnPickler$Scan.readSymbolRef(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.readSymbol(UnPickler.scala:178)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readSymbolRef$1.apply(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.reflect.generic.UnPickler$Scan.readSymbolRef(UnPickler.scala:709)
at scala.reflect.generic.UnPickler$Scan.readType(UnPickler.scala:273)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readTypeRef$1.apply(UnPickler.scala:710)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readTypeRef$1.apply(UnPickler.scala:710)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.reflect.generic.UnPickler$Scan.readTypeRef(UnPickler.scala:710)
at scala.reflect.generic.UnPickler$Scan.readType(UnPickler.scala:283)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readTypeRef$1.apply(UnPickler.scala:710)
at scala.reflect.generic.UnPickler$Scan$$anonfun$readTypeRef$1.apply(UnPickler.scala:710)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.reflect.generic.UnPickler$Scan.readTypeRef(UnPickler.scala:710)
at scala.reflect.generic.UnPickler$Scan.readType(UnPickler.scala:304)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan.protected$readType(UnPickler.scala:59)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan$LazyTypeRef$$anonfun$1.apply(UnPickler.scala:59)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan$LazyTypeRef$$anonfun$1.apply(UnPickler.scala:59)
at scala.reflect.generic.UnPickler$Scan.at(UnPickler.scala:151)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan.protected$at(UnPickler.scala:59)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan$LazyTypeRef.complete(UnPickler.scala:59)
at scala.tools.nsc.symtab.classfile.UnPickler$CompileScan$LazyTypeRef.load(UnPickler.scala:64)
at scala.tools.nsc.symtab.Symbols$Symbol.typeParams(Symbols.scala:926)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$scala$tools$nsc$transform$SpecializeTypes$$normalizeMember$1.apply(SpecializeTypes.scala:607)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$scala$tools$nsc$transform$SpecializeTypes$$normalizeMember$1.apply(SpecializeTypes.scala:607)
at scala.tools.nsc.symtab.SymbolTable.atPhase(SymbolTable.scala:104)
at scala.tools.nsc.transform.SpecializeTypes.scala$tools$nsc$transform$SpecializeTypes$$normalizeMember(SpecializeTypes.scala:607)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$8.apply(SpecializeTypes.scala:571)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$8.apply(SpecializeTypes.scala:569)
at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:224)
at scala.collection.TraversableLike$$anonfun$flatMap$1.apply(TraversableLike.scala:224)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:62)
at scala.collection.immutable.List.foreach(List.scala:46)
at scala.collection.TraversableLike$class.flatMap(TraversableLike.scala:224)
at scala.collection.immutable.List.flatMap(List.scala:46)
at scala.tools.nsc.transform.SpecializeTypes.specializeClass(SpecializeTypes.scala:569)
at scala.tools.nsc.transform.SpecializeTypes.transformInfo(SpecializeTypes.scala:836)
at scala.tools.nsc.transform.InfoTransform$Phase$$anon$1.transform(InfoTransform.scala:36)
at scala.tools.nsc.symtab.Symbols$Symbol.rawInfo(Symbols.scala:809)
at scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:753)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14$$anonfun$apply$9.apply(SpecializeTypes.scala:833)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14$$anonfun$apply$9.apply(SpecializeTypes.scala:833)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:203)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:203)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:62)
at scala.collection.immutable.List.foreach(List.scala:46)
at scala.collection.TraversableLike$class.map(TraversableLike.scala:203)
at scala.collection.immutable.List.map(List.scala:46)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14.apply(SpecializeTypes.scala:833)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14.apply(SpecializeTypes.scala:833)
at scala.tools.nsc.symtab.SymbolTable.atPhase(SymbolTable.scala:104)
at scala.tools.nsc.transform.SpecializeTypes.transformInfo(SpecializeTypes.scala:833)
at scala.tools.nsc.transform.InfoTransform$Phase$$anon$1.transform(InfoTransform.scala:36)
at scala.tools.nsc.symtab.Symbols$Symbol.rawInfo(Symbols.scala:809)
at scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:753)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14$$anonfun$apply$9.apply(SpecializeTypes.scala:833)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14$$anonfun$apply$9.apply(SpecializeTypes.scala:833)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:203)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:203)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:62)
at scala.collection.immutable.List.foreach(List.scala:46)
at scala.collection.TraversableLike$class.map(TraversableLike.scala:203)
at scala.collection.immutable.List.map(List.scala:46)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14.apply(SpecializeTypes.scala:833)
at scala.tools.nsc.transform.SpecializeTypes$$anonfun$14.apply(SpecializeTypes.scala:833)
at scala.tools.nsc.symtab.SymbolTable.atPhase(SymbolTable.scala:104)
at scala.tools.nsc.transform.SpecializeTypes.transformInfo(SpecializeTypes.scala:833)
at scala.tools.nsc.transform.InfoTransform$Phase$$anon$1.transform(InfoTransform.scala:36)
at scala.tools.nsc.symtab.Symbols$Symbol.rawInfo(Symbols.scala:809)
at scala.tools.nsc.symtab.Symbols$Symbol.info(Symbols.scala:753)
at scala.tools.nsc.symtab.Symbols$Symbol.flatOwnerInfo(Symbols.scala:1294)
at scala.tools.nsc.symtab.Symbols$Symbol.companionModule0(Symbols.scala:1252)
at scala.tools.nsc.symtab.Symbols$Symbol.companionModule(Symbols.scala:1260)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.javaName(GenJVM.scala:1740)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.javaType(GenJVM.scala:1830)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.javaType(GenJVM.scala:1834)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.javaType(GenJVM.scala:1839)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genBlock$1$1.apply(GenJVM.scala:1136)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genBlock$1$1.apply(GenJVM.scala:1046)
at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:35)
at scala.collection.mutable.ArrayOps.foreach(ArrayOps.scala:35)
at scala.tools.nsc.backend.icode.BasicBlocks$BasicBlock.foreach(BasicBlocks.scala:138)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genBlock$1(GenJVM.scala:1046)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genBlocks$1(GenJVM.scala:973)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genCode(GenJVM.scala:1580)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genMethod(GenJVM.scala:649)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genClass$4.apply(GenJVM.scala:258)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator$$anonfun$genClass$4.apply(GenJVM.scala:258)
at scala.collection.LinearSeqOptimized$class.foreach(LinearSeqOptimized.scala:62)
at scala.collection.immutable.List.foreach(List.scala:46)
at scala.tools.nsc.backend.jvm.GenJVM$BytecodeGenerator.genClass(GenJVM.scala:258)
at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase.apply(GenJVM.scala:57)
at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase$$anonfun$run$3.apply(GenJVM.scala:53)
at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase$$anonfun$run$3.apply(GenJVM.scala:53)
at scala.collection.mutable.HashMap$$anon$2$$anonfun$foreach$3.apply(HashMap.scala:90)
at scala.collection.mutable.HashMap$$anon$2$$anonfun$foreach$3.apply(HashMap.scala:90)
at scala.collection.Iterator$class.foreach(Iterator.scala:627)
at scala.collection.mutable.HashTable$$anon$1.foreach(HashTable.scala:162)
at scala.collection.mutable.HashTable$class.foreachEntry(HashTable.scala:195)
at scala.collection.mutable.HashMap.foreachEntry(HashMap.scala:40)
at scala.collection.mutable.HashMap$$anon$2.foreach(HashMap.scala:90)
at scala.tools.nsc.backend.jvm.GenJVM$JvmPhase.run(GenJVM.scala:53)
at scala.tools.nsc.Global$Run.compileSources(Global.scala:729)
at scala.tools.nsc.Interpreter.compileAndSaveRun(Interpreter.scala:549)
at scala.tools.nsc.Interpreter$Request.objRun(Interpreter.scala:904)
at scala.tools.nsc.Interpreter$Request.compile(Interpreter.scala:927)
at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:616)
at scala.tools.nsc.Interpreter.interpret(Interpreter.scala:608)
at net.kogics.kojo.xscala.ScalaCodeRunner$InterpActor.interpretAllLines(ScalaCodeRunner.scala:294)
at net.kogics.kojo.xscala.ScalaCodeRunner$InterpActor.interpret(ScalaCodeRunner.scala:298)
at net.kogics.kojo.xscala.ScalaCodeRunner$InterpActor$$anonfun$act$1.apply(ScalaCodeRunner.scala:174)
at net.kogics.kojo.xscala.ScalaCodeRunner$InterpActor$$anonfun$act$1.apply(ScalaCodeRunner.scala:159)
at scala.actors.Actor$class.receive(Actor.scala:456)
at net.kogics.kojo.xscala.ScalaCodeRunner$InterpActor.receive(ScalaCodeRunner.scala:131)
at net.kogics.kojo.xscala.ScalaCodeRunner$InterpActor.act(ScalaCodeRunner.scala:159)
at scala.actors.Reaction$$anonfun$$init$$1.apply(Reaction.scala:30)
at scala.actors.Reaction$$anonfun$$init$$1.apply(Reaction.scala:30)
at scala.actors.ReactorTask.run(ReactorTask.scala:38)
at scala.concurrent.forkjoin.ForkJoinPool$AdaptedRunnable.exec(ForkJoinPool.java:611)
at scala.concurrent.forkjoin.ForkJoinTask.quietlyExec(ForkJoinTask.java:422)
at scala.concurrent.forkjoin.ForkJoinWorkerThread.mainLoop(ForkJoinWorkerThread.java:340)
[catch] at scala.concurrent.forkjoin.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:325)
INFO [net.kogics.kojo.xscala.ScalaCodeRunner]: CodeRunner actor doing final handling for code.
INFO [net.kogics.kojo.xscala.ScalaCodeRunner]: Interpreter Done notification received
BUILD SUCCESSFUL (total time: 3 minutes 43 seconds)

Well, it's not immediately obvious that tCanvas works with the turtle and figure0 works with the canvas :)

The part of Kojo where the default turtle, called turtle0, paints - is the Turtle Canvas (aka tCanvas). The default turtle is accessible as tCanvas.turtle0

Figures implement the Processing-like stuff within Kojo. The default figure, called figure0, shares window space with the Turtle Canvas. It is accesible via tCanvas.figure0. At the API level, the default figure is called the Canvas.

Out of the box, Kojo tries to make it as easy as possible (for kids) to work with Turtles, so tCanvas implements wrappers for all turtle methods, and delegates to turtle0.

Note to myself - this last step may no longer be necessary, given the Builtins object.

The shape class system is a bit complex too.

This was driven by the desire to keep the same shape hierarchy for both Figures and MathWorld, and the fact that method args cannot be covariant (this bites in the signatures for MathWorld).

Note to myself - would it be worthwhile to make the Figure method signatures a little simpler?

Fortunately your code is quite readable, so it's not very hard to figure out what it does or what goes where.

I'm amazed that you've figured out as much stuff as you have - without pretty much any documentation in the code!

I'm perfectly fine, even a bit flattered, if you bring the name "Staging" into Kojo,

Great.

but in that case I'll start a new API object with another name. I want to have a sandbox that is as disjoint from Kojo as it can be.

The disjoint sandbox idea makes good sense.

I'll wait for you to polish off your shapes hierarchy and write some unit tests before I start doing the merge…

A single shape hierarchy is of course preferable, but whatever part of Kojo I tinker with, I will create my own counterpart of the standard item just to see if it can be done another way. And also to have a known baseline: I know what my code does, but sometimes your code doesn't do what I think it does.

My ShapeStyle goof is a case in point. I didn't use that code when writing/testing the shape classes, I just thought I needed it to accomodate SVG basic shapes later (and now I think there are better solutions), so I put the methods in and made them compile. Now, where is the Kojo style functionality? Oh, it's in SpriteCanvas, so I use tCanvas, right? Oops. Well, it's not immediately obvious that tCanvas works with the turtle and figure0 works with the canvas :)

The shape class system is a bit complex too. To add rounded rectangles, I need to put

• a RoundRectangle class in core/shapes.scala
• a FRRectangle type declaration and a declaration of the roundRectangle method in core/Figure.scala
• another FRRectangle type declaration and an implementation of roundRectangle in figure/Figure.scala
• a FigRectangle class in figure/FigRectangle.scala

Fortunately your code is quite readable, so it's not very hard to figure out what it does or what goes where.

I'm ready if you are, but I'd prefer to first:

* refactor the class hierarchy, for instance decouple style from shape and make polyline and polygon subclasses of an abstract polyshape

Please go ahead and do this, to take your current work to a logical finishing point. I'll then take your stuff and merge it into Kojo. I'll keep you in the loop as I do this, so that we can come up with something that both of us like (read on for more about this).

* know where you want to put it; as I understand it Staging isn't going into Kojo proper

I see at least two options:

• Pull Staging as-is into Kojo.
• Roll Staging into Figure and other support classes within the figure package, and maybe still call it Staging at the API level (I like the idea of people 'staging' animations with Kojo).

I'll get a sense of which option looks more promising as I start doing the merge and digging deeper into the code.

Some random thoughts based on a cursory look at the Staging code:

• I'll try to see if we can get by with just one Shapes class hierarchy (there's already one in the core package, and now Staging has another, independent one).
• ShapeStyle.withTempStyle looks like a method that probably does not do what you want it to do - because of the calls it makes into tCanvas. Most tCanvas methods delegate to turtle0 (the default turtle), and you probably want this method to call into tCanvas.figure0 (aka 'the Canvas').

* write some unit tests

That would be good. If they're high level tests against the Staging API (i.e. Staging.whatever) - they'll help me make sure that I didn't break anything.

Thoughts?

• refactor the class hierarchy, for instance decouple style from shape and make polyline and polygon subclasses of an abstract polyshape
• write some unit tests
• know where you want to put it; as I understand it Staging isn't going into Kojo proper

…and some more, but my wife is calling out dinner now!

Are you ready for me to merge this into the Kojo 'trunk'?

I've also updated the documentation to show SVG usage and the new API, link as above and before.

It doesn't support SVG's Basic Shape elements yet, but it should be straightforward to add them, calling the shape API from within a renderSVG method.

*phew…*

The latest revision now has support for all SVG path commands except elliptic arcs, and the code is fairly stable now.

That's very impressive!

but I hope to find some time to document SVG usage too.

Looking forward to that…

Tomorrow I have to work on tax returns, but I hope to find some time to document SVG usage too.

I usually don't write unit tests for experimental code, but I think I have to do that for the SVG code since there are so many permutations. I've tested it by running a few dozen scripts manually, but I still haven't even tried seriously malformed descriptors yet.

It doesn't seem to be very active?

I have not really looked at it in any detail or tried it myself. Just wanted to make sure that you had looked at this option.

but until and unless SVG support is added to Piccolo, it seems easier to make a lightweight implementation in Scala with Kojo in mind.

That makes sense.

Again, it's not my place to make policy or design decisions, but until and unless SVG support is added to Piccolo, it seems easier to make a lightweight implementation in Scala with Kojo in mind.

Well, that's what experimentation is for :)

Amen!

but it seems that there are good reasons to phase out the PVector class.

Hopefully, all the the good stuff in there will survive (in some form or the other). And hopefully the PVector class will also survive (to represent a mathematical vector, and the operations on vectors).

I think it would be nice to be able to load SVG shapes. Thoughts?

It would be very cool to be able to load SVG shapes. Have you seen this: http://code.google.com/p/piccolo2d/wiki/SvgSupport

Anyway, right now I'm working on support for SVG-style path descriptors. AFAICT Piccolo doesn't support SVG out of the box (but I might have missed something there), and I think it would be nice to be able to load SVG shapes. Thoughts?

also because it's more OO

Here's my take on how things might develop from an OO perspective:

We start with class Point(x: Double, y: Double)

We then work up class Line(p1: Point, p2: Point) , class Rect(p1: Point, p2: Point) etc

Now, the classical OO way of creating these guys would be via ctors - new Line(…), new Rect(…) etc
But we all know that constructors are evil! We prefer factories. In Scala land - that's done via companion objects.
So we create our shapes like this: Line(…), Rect(…)

Note - Why have OO artifacts for the different kinds of shapes? Because given a shape object, you can translate, rotate, scale it etc - during animations. This is relevant because we're sitting on top of a retained mode GUI toolkit (Piccolo) as opposed to an immediate mode toolkit like the Java2D API.

We might now want to put a Facade around the whole module - so we get to:
Staging.line(…) = Line(…) etc

Note - Within Kojo, a Facade helps big-time with code completion.

That does not support chaining, but I'm sure something nice could be cooked up (along the lines of a Builder, maybe).

Just some food for thought.

PS. Both Mathword and Figure follow this model (other than the fact that Figure still uses ctors rather than companion object factories).