Michael van der Gulik
mikevdg at gmail.com
Fri Jul 4 02:58:07 UTC 2008
On Fri, Jul 4, 2008 at 2:16 PM, Igor Stasenko <siguctua at gmail.com> wrote:
> 2008/7/4 Michael van der Gulik <mikevdg at gmail.com>:
> > 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
> > #drawOn:bounds: method. A Canvas can ask the model to redraw itself when
> > 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! :)
On reflection, yes, it is a premature optimisation. Hmm...
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).
IIRC, mouse pointer events normally contain absolute coordinates in most
windowing systems, including Squeak.
Mouse velocity could be passed as extra information in the event. Mouse
pointer capture could be done using some key combination, although this is a
"nice-to-have" feature that I won't implement in the first release.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev