I don't have a great suggestion about this. The best thing to do would be
to create a grid of close together rollover views, and make sure that all
the views receive the rollover event (if the runtime is running slowly,
you'll miss mouse events.)
But I don't know that that's necessary -- if people like your proposal the
additional test is probably not a big deal. I think I personally still
prefer a mouseview class.
Now that I think of it, the right way to implement properties without an
extraneous method call is this:
if ( eventStr == "onmouseover" ){
view.mouseisover = true;
if ( view.onmouseisover ) view.onmouseisover.sendEvent( true );
}
A
On Dec 20, P T Withington wrote:
> I don't know of a good test case. Perhaps Adam has some benchmarks.
>
> On 20 Dec 2005, at 08:05, Oliver Steele wrote:
>
> > What is a good test case for seeing the extent of the slowdown in
> > applications which don't use the new feature?
> >
> > I tried some of the demos and didn't measure a change, but I'm not confident
> > of my methodology.
> >
> > (Assuming it doesn't slow down applications that don't use the feature, that
> > just means that's not an automatic showstopper. There's still the question
> > of whether to add another construct that is concise and readable but would
> > need to be rewritten to optimize the application for performance.)
> >
> > On Dec 20, 2005, at 7:56 AM, P T Withington wrote:
> >
> > > If you really wanted to slow things down, you would make it really
> > > abstract:
> > >
> > > <view bgcolor="${mouse.over == this ? blue : red}" />
> > >
> > > The constraint system would have to be really sophisticated to realize
> > > that if only had to evaluate the constraint on mouse.over on the views it
> > > was leaving and entering, rather than every view.
> > >
> > > I actually like that abstraction, but we have to be practical.
> > >
> > > Your straw implementation introduces an additional layer of events, so
> > > will slow things down. That could be crushed out by sending the event
> > > directly in the mouse handler with only the overhead of an extra call.
> > >
> > > On 19 Dec 2005, at 21:55, Oliver Steele wrote:
> > >
> > > > I'd like to be able to write rollover effects more declaratively. For
> > > > example, instead of writing something like this:
> > > > <view bgcolor="red" onmouseover="this.bgcolor=blue"
> > > > onmouseout="this.bgcolor=red"/>
> > > > I'd like to be able to use a constraint:
> > > > <view bgcolor="${this.mouseisover ? blue : red}"/>
> > > >
> > > > Or more realistically, for a view that has a more radically different
> > > > appearance in its rollover and non-rollover states, I'd like to be able
> > > > to do something like this:
> > > > <view>
> > > > <state apply="${!this.mouseisover}">
> > > > ...normal state...
> > > > </state>
> > > > <state apply="${this.mouseisover}">
> > > > ....rollover state...
> > > > </state>
> > > > </view>
> > > >
> > > > I can get this if I add these lines to LzModeManager.handleMouseEvent:
> > > > if (eventStr == "onmouseover") view.setAttribute('mouseisover',
> > > > true);
> > > > if (eventStr == "onmouseout") view.setAttribute('mouseisover',
> > > > false);
> > > > if (eventStr == "onmousedown") view.setAttribute('mouseisdown',
> > > > true);
> > > > if (eventStr == "onmouseup") view.setAttribute('mouseisup', false);
> > > >
> > > > Does this sound reasonable? I don't want to write a performance test to
> > > > see if this is credible, so I thought I'd run it by your intuition
> > > > instead.
> > > >
> > > > ---
> > > >
> > > > Notes:
> > > >
> > > > LzView.mouseover would be a better name for this, but for the constraint
> > > > system to work, onmouseover would have to be sent when it changed its
> > > > value from true to false, which would be an incompatible (and confusing)
> > > > change.
> > > >
> > > > LzView.mouse.over and LzView.mouse.down would also be more elegant names
> > > > than LzView.mouseover and LzView.mousedown, but this would require an
> > > > extra node for each view, to register the delegates on, and I was
> > > > worried about the effect on memory footprint and instantiation time if I
> > > > added an extra Object to every LzView.
> > > > _______________________________________________
> > > > Laszlo-dev mailing list
> > > > [email protected]
> > > > http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> > >
> >
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
