2008/7/4 Michael van der Gulik <mikevdg at gmail.com>:
> Hi all.
>
> I'm about to start work on a project called "Subcanvas", which will be a
> refactoring of the Canvas class. The intention is that this forms a platform
> for other GUI projects, including a possible future version of Morphic. It
> will be a general 2-D drawing API and event handling system.
>
> Is anybody interested in this? Does anybody have any comments on any of the
> following? Are there any annoyances with the current Canvas class that
> people want to rant about?
>

I have a big interest, but lack in time to get deeply with it :(

> Current "design sketches" are at http://gulik.pbwiki.com/Canvas.
>
> This API will be the main graphics / event-handling API for my SecureSqueak
> project (http://gulik.pbwiki.com/SecureSqueak). It is likely that Morphic
> will be ported to it at some stage. The code will be written using
> Namespaces and my own Package system, and it will be the first real trial of
> my Namespaces architecture.
>
> Features of it are:
> * Some canvases can have child canvases, each with a z-index. These could be
> used, e.g., to implement movable windows, sprites, clipped scrollable areas,
> or flyweight graphics. This will use the underlying graphics system's
> capabilities.
>
mmm.. i like this idea in general, but please, lets make it more
general: no z-index (or any early binding to coordinate system).
Simply child canvas concept.

> * The Canvas will be a general abstraction for underlying 2-D vector-based
> or raster-based drawing APIs - e.g. Forms/BitBlt, OpenGL, VNC.
>
+1

> * An event handling system will also be part of this package. Mouse events
> will have a canvas (or sub-canvas) coordinate; keyboard events will be sent
> to the canvas that has the "keyboard focus".
>

Please don't. An event subsystem should not be connected directly with canvases.
It should be a separate layer for applications.
Any coordinate translations should come this way: Event ->
morph(widget) -> canvas.
But never Event->canvas.

Suppose you moving a scrollbar knob. For this you would need 2
different coordinates in result:
- one to update hand position
- second to update knob position

Or, suppose you dragging something in 3D space. You may move mouse to
the left or right, but movements will be translated in different way
(dragging object(s) closer/farther from eye).

It is up to morphs/UI how to deal with events and then how to update
themselves on screen as a reaction on such event.

> * Canvases must be "secure"; as this will be part of SecureSqueak.
> Specifically:
>    * Canvas methods must be locked down so that users cannot gain
> unauthorised access to anything or cause destructive behaviour.
>    * Drawing operations will be clipped. Having access to a canvas only
> allows the user to draw in that particular area.
>    * Stalled event handlers or drawOn: methods will not affect the operation
> of other Canvases on the screen.
>
> * The coordinate system will use micrometers; 0 at 0 will be at the bottom left
> corner of the canvas. Each Canvas will provide a "pixelPitch" method to
> return the number of micrometers in each pixel (if that Canvas has pixels
> :-) ) so that pixel-based operations are possible.
>

Surely, but only if pixel-based operations is possible at all :) I
would suggest you to make it as possible as you can to abstract the
media type of canvas, or principles, how it performs drawings - be it
pixel based or vector based or curve-based.

> I don't know how to handle fonts - I don't know what the pros/cons of having
> a font API built in to the canvas is, or whether it is better to have the
> font drawing done externally by each application.
>

Lets discuss that a bit, before you going to start implementing it.
Recently, we discussed a lot of ideas with Gary about canvases/events.
I think you should be aware of what conclusions we had, at least.
Gary, can you refresh my memory about ordinates & events ideas we discussed? :)


-- 
Best regards,
Igor Stasenko AKA sig.