[Grace-core] Cross platform graphics library

[Kim Bruce]

Thanks for doing this.  It looks very complete.  A big test will be seeing if we can define objectdraw from it without much pain.

Here are some detailed comments/questions:

0.  Please list types so that supertypes appear before subtypces.  It is hard to understand the type for window when it is defined in terms of Component, which is defined 11 pages later.

1.  Don't bother with Circle, we already have ellipse.  I think we're better off without redundancy at this level.

2.  I'm not sure we need default geometric objects at (25,25).  Drop parameterless constructors.  

Can't tell if graphic objects are filled or framed.  I see later that this depends on a flag set on the canvas.  I'm not a big fan of this non-OO approach to graphics (I have similar issues with canvas, which seems to adopt something similar to writing with pens or Java's graphic context).  It's low level and we'll build higher-level OO graphics from this, so I suppose its not that important.  However, is there any reason to do it this way?  Is there an advantage for anything we want to do (turtle graphics?).

3. page 8, position is bad name for pair of width and height of window.  Location of upper left corner makes more sense.  Same for position :=

Also, as James and Andrew know, I'm not a big fan of using the same type for size and position.  However, I seem to have lost that battle and can program around it in objectdraw.

4. page 9:  Prefer to have mousePressed, mouseReleased, etc, be methods to be defined (overridden) by users rather than looking like instance variables to be assigned a block.  Novices will find it much easier to define a method than to define a block (I probably won't introduce first class blocks until very late in the term of a CS 1).  Also need methods mouseClicked, mouseMoved, etc.  (see Java, for example).

Also, it seems to me it would make more sense to have these defined on components rather than the window as a whole.  E.g., if my program has two canvases in a window, then each could have their own mousePress method.

As an example of this, I see that they are also defined on Canvas.  Why not on all components?

5, page 10, Canvas:  I'm not a big fan of add methods that return a boolean as they will be ignored (just like C I/O).  Instead throw an exception if there is an error.

6.  page 10, replace findDrawable by findFromTop and findFromBottom.

7.  page 15,16:  types Rectangle and Oval are identical and should be given a name like TwoDGeometric.  No need for Circle type.

8.  page 17:  Not sure why we have arc as opposed to sector.

9, page 17:  Line type should probably have methods "angle" and "length"

10.  page 18:  Text should have method to set fontSize (and prefer name fontSize to size)

11. page 20:  Need more components than just buttons.  Need pop-up menus (JComboBox), text fields, text areas, labels, etc.  Also not clear to me how button is located in container.  What control do we have?  Will there be a layout manager or just vertical and horizontal containers.

Don't see the need to discriminate between buttons being clicked, pressed, and released.  Simple buttonSelected should be fine.

12. page 21:  Why bother with half_pi and two_pi?

13, page 21:  Why not put some of these operations in Number rather than in external GMath?  I don'd understand "clamp".  Why fact?

14. page 22:  I'd prefer color components (red, blue, green, alpha) to be spelled out rather than just single letter.  Why have "+"?  Never heard of doge!

15, pg 25:  Not a big fan of <, > for vectors.  Already have magnitude and could compare magnitiudes.

16, pg 26:  Prefer zeroVector to zero as could confuse with Number.  Prefer to see projection operators rather then setVector3 and 4.

[Note that methods in types need not be (should not be?) labeled public, as they are by default.] 

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

Kim



On Jan 24, 2014, at 5:48 PM, Alex Sandilands <sandilands.alex at gmail.com> wrote:

> Forgot to put the utility modules into the api, here is the updated version.
> 
> 
> 
> On Sat, Jan 25, 2014 at 12:47 AM, James Noble <kjx at ecs.vuw.ac.nz> wrote:
> Alex - thanks for sending that out!
> I didn't expect it to be so long (and I hope you weren't working at this straight from 5pm)
> 
> hopefully we'll get some good feedback
> 
> J
> 
> 
> On 25/01/2014, at 00:10 AM, Alex Sandilands <sandilands.alex at gmail.com> wrote:
> 
> > This is a first draft of the graphics library we have been working on the last few weeks.
> >
> > Currently the GTK+3 backend is nearly finished, and we are working on getting the Javascript
> > backend done in the next week.
> >
> > I've attached a pdf draft of the API, and you can see implementations here:
> > https://github.com/AlexSandilands/grace-phix
> >
> >
> > <api.pdf>_______________________________________________
> > Grace-core mailing list
> > Grace-core at cecs.pdx.edu
> > https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core
> 
> 
> <api.pdf>_______________________________________________
> Grace-core mailing list
> Grace-core at cecs.pdx.edu
> https://mailhost.cecs.pdx.edu/mailman/listinfo/grace-core

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailhost.cecs.pdx.edu/pipermail/grace-core/attachments/20140127/46bb86a8/attachment.html>