[xinf] progress report: unified mouse events, first RealSimple widget

[hank williams]

Dan,

will xinfony require openGL? The reason I ask is that I would probably
be interested in using xinfony if it were capable of working in a
small footprint. This might mean a small footprint profile that didnt
have all of the bells and whistles, but that could fit in an embedded
envirinment. I am already including neko, so this would really be
about what would be required, at a minimal level, to draw stuff to a
display. I know openGL does alot of stuff that I would never need, and
I dont know if its possible to compile it into a small footprint, but
perhaps that is  solution.

In any case, I was just curious because as I continue to think about
how to do my embedded stuff, the thought of dealing with garbage
collection and pointers for significant chunks of work send chills
down my spine. The further I can push that stuff away from the
application logic, the better.

Hank

On 6/13/06, daniel fischer <dan at f3c.com> wrote:
>
> hey,
>
> this was originally to be a rant/cry for help about the broken Events in FP (and JS, for that matter). But thanks to the wonders of opensource (or, more specifically, the hard work put into actionstep) i found a method how we can basically bake our own mouse events in what seems to be a relatively efficient manner: by using a "mouseTracker" clip, an empty movieclip that is constantly being "dragged". Dragged movieclips, for the uninitiated, carry a special property "_droptarget" that denotes a text path to the clip the mouse is above of.
>
> this, and some globalization of JS events (yet to be adapted to IE), enabled me to throw out a whole bunch of ugly event plumbing in Element: mouse event generation is now done globally in runtime-specific EventMonitor classes. This enables us to decide a lot about how we want it to behave- like- are we only MOUSE_OVER one element at a time (or above parents, too?), what events bubble (currently all), and the like- i'll have a look at the W3C DOM Event model to get some guidance at some time.
>
> note that this all is unrelated to my call for review about the event model- it's just about how we get mouse events *into* that model, whatever it'll be.
>
>
> more high-level, i've devised a first xinful widget- a ListBox. it's RealSimple, meaning it will change a lot, but doing this kind of stuff surely helps me to get the basics right-- a lot of things (like consistent mouse events) were simply not needed before. having a go at widgets, if nothing else, helps me identify these gaps.
>
> in related news, there's now a (also RealSimple) VScrollbar, and ony.Pane got a "crop" property which, when set to "true" results in what DHTML people would call "overflow:hidden", or flash people "rectangular mask". It needs more work in xinfinity: the cropping doesnt apply to mouse events, and in fact it will fail if a cropping Pane contains another such.
>
> but progress, nevertheless. it's sure nice to develop a widget on xinful and then "sigh, now for the other runtimes" - but then finding that it Just Works(TM). also, a rather funny thing is when a "bug" occurs consistently across runtimes...
>
> take care (and a look at the event code :),
> -dan
>
> --
> http://0xDF.com/
> http://iterative.org/
>
> --
> xinf is not flash
> http://xinf.org/
>