Jim Grandy wrote: > Is an entire shadow div hierarchy really necessary? That sounds > expensive, and potentially hard on the slower/less robust browsers.
I just sent a change package that fixes the issue. It is more expensive to have the shadow tree, but it's not as bad as you might think. Suprisingly, I can't tell the difference in DHTML startup time with this on or off and it's on par with SWF startup time! This is the only way I can think of to do this simply and fix the problem across all browsers. It's conditionalized in LzSprite.quirks so it can easily be turned off. We can certainly optimize it later to only build parts of the tree that have clickable divs inside. But for now, it works! > Here's another potential option. Is the inversion of visible/clickable > views only local? That is, do the visible and clickable views share a > close parent? Because if so you could use event capturing (or bubbling) > in the common parent to redirect the event. Yes, but how do you know which view to direct it to? Remember, _all_ mouse events are snarfed by the div on top, so we can't rely on mouseover and the like... > Here's code that creates a mouse event and dispatches it to a particular > event. You could do the same with a nonsynthetic mouse event, passing it > to the one known clickable view in the subview hierachy. (This would > require adding the concept of the "one known clickable view", of course.) > > http://developer.mozilla.org/en/docs/DOM:document.createEvent > > And here's another sample that redirects a click event from one view to > another: > > http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/createeventobject.asp > > > > As for whether there is a single well-defined shared parent, if there > isn't perhaps we should make one up? Something like the focustrap > attribute may signal a place to redirect, for example -- the idea of > hierarchical focus is in some ways connected with what we're discussing > here. The document is the single well-defined shared parent for us. These are all fine ideas, but they'll require the developer to change symantice/LZX code - and we really want to minimize breakage for folks moving to DHTML. -Max > On Sep 13, 2006, at 4:33 PM, Max Carlson wrote: > >> 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
