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]> 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]> 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]
>> > 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]
>> 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]
>>
>>
>> _______________________________________
>>
>> Internal-Dev mailing list
>> [EMAIL PROTECTED]
>> 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]
> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
