[Grace-core] Cross platform graphics library

[James Noble]

On 28/01/2014, at 20:00 PM, Kim Bruce <kim at cs.pomona.edu> wrote:

> Again, thanks for doing this.  A good solid graphics library is crucial to the success of this project.

indeed! 

(Alex, I'll be in on Thurs & Friday, and perhaps we can go through the full lists then?
If you & David concentrate on the mechanics until we've thought through the interface...)



I'd like to pick on couple of higher-level things that may be particularly worth discussing more broadly.



First, what are the key interfaces / structures - do we need all of them ?

I think there's: 

 Component (has parent, draw with "display")

   Canvas (has drawables) 

   Container (has children)
      Window
      Vbox
      Hbox 

 Drawable (can be painted on a Canvas, via a draw(Canvas?) request)
   Arc, Text, Image, Line, Rectangle, etc, etc ...

There are two part/whole (Composite Pattern) relationships here:
Component / Container  and Canvas / Drawable.  Do we need both of these?

The current design means you have to make a window, add a Canvas (component)
to that WIndow, then add drawables to the Canvas.    Why not directly draw
(or add drawables) to the window  (as leaf nodes in the Component/Container Composite Pattern)?
That is, unify the two compositions by basically making all Drawables into Components,
unifying those two interfaces. 

Then there's the option to go one step further, to a "morphic"  (Morphix?) style design
(by John Maloney, used in Self and Squeak).  Basically this eliminates the Leaf (Component)
classes from the composite pattern: everything, even basic drawables, can have children added.
(I guess they are drawn positioned relative to their parent).  The model is that the various
primitives are "glued" onto each other like postit notes. 

This would mean that Component, Canvas, Container, and Drawable would be merged into 
just one interface - "Morph".  Most of the method implementations would pretty much stay the same. 
(have to work out how drawing works, typically there's a requirement you need a window object at the 
top of each instance hierarhcy that passes itself (or its canvas, or its graphics context)  down to the
drawing methods) 







> 13, page 21:  Why not put some of these operations in Number rather than in external GMath? 

What criteria should we use for questions like -   do we write foo.sin  or sin(foo)?

Note that if say sin is in a math module we'll actually have to write  "m.sin(foo)"
or at least have a dialect that imports math and redeclares a bunch of functions locally
so we can write "sin(foo)" if that's what we want to do.

It seems all these functions are going to be available on most backends we're likely to have:
why not then put them directly into the main Number type?

that then leads on to the vexed question of the "@" operator for forming points :-)    (1 at 3) 
which might take Point (or Vector2D) into the core library.