[squeak-dev] Subcanvas

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?

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.

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

* 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".

* 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@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.

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.

Gulik.


--
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/

2008/7/4 Michael van der Gulik <[hidden email]>:

> 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.

> * 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.

> 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? :)

2008/7/4 Michael van der Gulik <[hidden email]>:

> What I was considering doing was making the Canvas the source of events.
> Every Canvas has a model which must implement event handling methods and a
> #drawOn:bounds: method. A Canvas can ask the model to redraw itself when the
> Canvas becomes dirty (e.g. when sub-canvases move and the canvas has no
> cached state).
>

A dirty/clean is a not a basic canvas capability.
Needless to say, that for some devices (including GL) sometimes its
easier and faster to redraw everything from scratch rather than care
about dirty areas.  Some devices (like printers) have nothing to do
with dirty/clean approach.
Don't let a premature optimizations influence the basic model! :)

Right, also, don't forget about relative mouse pointer motion. A good
illustration of capturing a relative mouse movement is 3D first person
shooter game :) It is not interesting where mouse cursor is, its only
interested in amount of mouse movement along its two axises.
And in fact, mouse, as device generates relative events, is knows
nothing about screen size , or where mouse cursor are allowed to be.
So, binding mouse to a screen space is wrong by its nature. Event
should generate a relative movement, and then World (or top-level
handler) can translate such events to absolute coordinates in its own
space (if it cares).