On Fri, Jul 4, 2008 at 12:10 PM, Igor Stasenko <siguctua at gmail.com> wrote:

> 2008/7/4 Michael van der Gulik <mikevdg at gmail.com>:
>
>
> > 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.



A parent canvas could have multiple children. When the Canvas architecture
wants to render these, it needs to know the distance each child is from the
shared parent. You also need to know the distance between child and parent
if you want to add relection, shadows and lighting in the OpenGL version
:-D.



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



Every Canvas has it's own coordinate system; they can be positioned anywhere
on the screen, but still have (0 at 0) in their bottom-left corner. This means
that mouse-based events with a position are relevant only for a particular
Canvas.

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

I've implemented a scroll bar using this kind of system. The scroll bar just
needs to remember where the original mouseDown event was. I don't understand
what your point was here.

As with dragging things in 3-D space, I'll need to invent some way of making
mouse capture secure.

Do you still think this is a bad design?



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


This is why I posted here :-).

IRC logs would be good, if they can be found.

Gulik.


-- 
http://people.squeakfoundation.org/person/mikevdg
http://gulik.pbwiki.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20080704/4cdd1688/attachment.htm