[Grace-core] Cross platform graphics library

[Kim Bruce]

On Jan 28, 2014, at 5:03 AM, James Noble <kjx at ecs.vuw.ac.nz> wrote:

> On 28/01/2014, at 20:00 PM, Kim Bruce <kim at cs.pomona.edu> wrote:
> 
> 
> 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?

I think we do.  We have components that are themselves not containers.  Canvas/Drawable
are different things with drawables going in a canvas
> 
> 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. 

I prefer having the separation as we might wish to have multiple canvases in a container (interspersed with other objects).  We can always define new classes that give you a window with a canvas built-in.  I do that in objectdraw.  The key here is to provide primitives that can be used to build a higher-level library.
> 
> 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. 

I'd prefer not to do this as the full variety of mouse actions make sense on a canvas, but if you are working with a button or a pop-up menu then only a subset of those actions make sense
> 
> 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?

I think this does make sense for these basic operations as it makes life simpler all around.
> 
> 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. 
>