That's right - and it almost sorta works now.  It fixes my testcase, but 
doesn't work in LzPix yet.  I'm going to keep going down this path 
because if we don't get this right a lot of things will break.  For 
example, the little animated focus rectangles prevent clicks to the 
underlying focused component...  And that's just one tiny example.  I 
really want to minimize the number of things people porting to DHTML 
have to think about...

-Max

Henry Minsky wrote:
> Max has already a done a bunch of work which implements an entire 
> "shadow" stack of invisible views
> which mirror the view hierarchy and sit above the visible apps in order 
> to catch mouse clicks. I believe it actually
> works.  I was worried that there would might be performance implications 
> to having to manage twice as many DHTML divs, but it may be necessary 
> and it might not be so bad for performance, for example maybe there 
> could be some kind of optimization to disable it maybe when you don't 
> need it or when you can declare for sure that a view is never going to 
> be clickable.
> 
> 
> 
> 
> 
> On 9/13/06, *Neil Mix* <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote:
> 
>     This is the problem I was trying to bring up a few months ago.  I
>     don't take issue with Henry's suggestion except for the fact that
>     it's highly backward incompatible.  As a data point, Pandora has at
>     times relied heavily on the current behavior.  (I'm not sure to what
>     extent it does at-this-moment.)
> 
>     FWIW, I've experienced general cross-browser flakiness when trying to
>     stack areas of different clickability on top of each other in DHTML.
>     It's a tough problem.
> 
>     An alternative suggestion to Henry's: place an invisible mouse-event-
>     catching div at the top layer in an application, and write your own
>     code for calculating where to deliver the events.
> 
>     On Sep 13, 2006, at 11:25 AM, Jim Grandy wrote:
> 
>      > Moving thread to laszlo-dev.
>      >
>      > On Sep 13, 2006, at 7:35 AM, Henry Minsky wrote:
>      >
>      >> Being naturally lazy and simple-minded I've thrown this out before
>      >> as an idea, what if we say that LZX uses the DHTML model of
>      >> click-handling, and modify SWF to act the same way (i.e., all
>      >> views clickable).  Not being a GUI designer, I don't really know
>      >> what the pluses and minuses are, but it seems to me like if the
>      >> app designer is going to put graphics on top of
>      >> clickable views which are in a different parent hierarchy, then
>      >> maybe it is incumbent upon them to explicitly forward
>      >> the mouse events to the area they are covering up?
>      >>
>      >>
>      >>
>      >> On 9/13/06, P T Withington <[EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>> wrote: I guess
>      >> this is no worse than the SWF case where we have to have two
>      >> movie clips for every view?  Still sucks though.
>      >>
>      >> On 2006-09-13, at 02:36 EDT, Max Carlson wrote:
>      >>
>      >> > It turns out any view physically on top of a clickable view (but
>      >> not a
>      >> > child) intercepts all mouse events.  We originally thought
>     this was
>      >> > restricted to text views
>      >> > ( http://jira.openlaszlo.org/jira/browse/LPP-2520 ) but it
>      >> applies to
>      >> > any
>      >> > view.  I'm making this my top priority.  I filed a new bug to
>     track
>      >> > this:
>      >> > http://jira.openlaszlo.org/jira/browse/LPP-2680
>      >> >
>      >> > I'm glad I left the fix in!
>      >> >
>      >> > -Max
>      >> >
>      >> > _______________________________________
>      >> >
>      >> > Internal-Dev mailing list
>      >> > [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
>      >> > https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev
>      >> >
>      >> > To search the dev list: http://lists.laszlosystems.com/intranet/
>      >> > finddev.cgi
>      >>
>      >>
>      >> _______________________________________
>      >>
>      >> Internal-Dev mailing list
>      >> [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
>      >> https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev
>      >>
>      >> To search the dev list: http://lists.laszlosystems.com/intranet/
>      >> finddev.cgi
>      >>
>      >>
>      >>
>      >> --
>      >> Henry Minsky
>      >> Software Architect
>      >> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
>      >>
>      >>
>      >> _______________________________________
>      >>
>      >> Internal-Dev mailing list
>      >> [EMAIL PROTECTED]
>     <mailto:[EMAIL PROTECTED]>
>      >> https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev
>     <https://hedwig.laszlosystems.com/mailman/listinfo/internal-dev>
>      >>
>      >> To search the dev list: http://lists.laszlosystems.com/intranet/
>      >> finddev.cgi
>      >
>      >
>      > _______________________________________________
>      > Laszlo-dev mailing list
>      > [email protected] <mailto:[email protected]>
>      > http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>     <http://www.openlaszlo.org/mailman/listinfo/laszlo-dev>
> 
> 
>     _______________________________________________
>     Laszlo-dev mailing list
>     [email protected] <mailto:[email protected]>
>     http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
> 
> 
> 
> 
> -- 
> Henry Minsky
> Software Architect
> [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
> 
> 
> ------------------------------------------------------------------------
> 
> 
> _______________________________________________
> 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

Reply via email to