On 2010/03/03 22:20:16, kozura wrote:
Well, I've seen your arguments on resize/visibility events in other
forums, and
must defer to your judgment on what is possible in the various
browsers and GWT
infrastructure!  Just annoying to have to add another nasty bit,
especially one
that creates new confusing user visible API.

No need for deference -- like I said, I'm always glad to be proven wrong
about these things :)

My parting thought is, how bad performance-wise was something like the
resize
setup that was done in the incubator awhile back, that used timers and
a list of
widgets of interest?  Something like that could instead work through
the event
handler - when you add a handler for resize/visibility to a widget,
it's added
to the watched list and checked every so often.  My application is
completely
dynamic, with lots of computations being done to update all of it, and
performs
smoothly; this would just be a simple check on all the elements in a
list.  Not
perfect, but it bypasses all the various ways things can be
visible/resized at
the expense of a bit of polling - and if any browsers like Chrome do
ever
implement these events, using those would be transparent to the user.
Would
that expense be worth getting rid of all the internal and user-visible
pains?

The incubator's ResizableWidgetCollection had two problems:
1. It was a performance minefield: It would be perfectly fast for small
collections, but exacted a subtle toll on your application's complexity
and would eventually become intractable. And once that happened, it
would be impossible to back out.
2. It ultimately doesn't produce stable behavior. Using a timer to catch
changes to size/visibility/etc has the unfortunate property that you
can't predict precisely when it will "notice" changes. This is nasty,
because the more complex your application gets, the more "jiggly" the UI
becomes.

Ultimately I'd like to get something like the onresize() event (from IE,
believe it or not) implemented in Gecko and WebKit, preferably with the
ability to catch changes to visibility (and perhaps other styles) as
well. It's pretty trivial to implement in WebKit, though getting
everyone to agree on the standard is a much bigger challenge.

http://gwt-code-reviews.appspot.com/153820

--
http://groups.google.com/group/Google-Web-Toolkit-Contributors

Reply via email to