On 2010/03/03 18:32:18, kozura wrote:
Sure, I understand completely how hard it is to work a coherent layout
system
into the hack we call CSS/Html, same reason there's setHeight() and
setCellHeight().  But adding this creates a new non-symmetry, where a
child must
be aware of its parent context, which should be considered with care..
 Using
setVisible on the child will now work fine in some contexts, but not
in others.
Possibly it may only break in one particular browser.  So the
developer must be
aware of this.  If this could be made an internal function, it would
address
this concern by limiting the need to know to LayoutPanel implementers,
unfortunately LayoutPanel is instantiated not inherited so this is not
an
option.

Another solution is to add a VisiblityHandler to widgets.  A
LayoutPanel would
add a handler for this on its children, and do the proper thing.
Seems like
overkill for this problem but...

It could also solve the much more general problem that we cannot find
out when a
particular widget becomes truly visible on the page, without knowing
its
parentage.  If I want to do delayed rendering on a widget, I can only
get that
information from, say, a tabSelection handler, something in the parent
that can
trigger something in a child.  If I also instantiate that widget in a
StackPanel, I need another mechanism to tell it when it becomes
visible.  So
it's difficult to write a context-free widget that can do delayed
rendering of
itself.  A propagated visibility event would decouple the two,
allowing parent
to detect when its children change visibility, and any widget to
detect this
about itself.  Whether it is really possible to reliably detect this,
and
economical code-size and performance-wise to implement it, I don't
know.

Trust me, I'm all for finding a better general solution to the problem
of finding out when widget's become shown and/or hidden (and resized,
for that matter). My experience so far tells me that this is impossible
to do in an even remotely efficient way, though I would *love* to be
proven wrong on that subject.

The problem with determining when an element (and consequently its
widget) becomes shown/hidden is that it can happen in so many different
ways. It is primarily affected by the display: and visibility: CSS
properties, both of which apply hierarchically, and the latter of which
can be *unapplied* to a child via CSS. These can be affected by any
arbitrary CSS selector, which means that we'd have to recalculate
visibility on any change to any parent's style object, class name, etc.
-- which of course can happen via Javascript, user style sheets, and so
forth. Those cases are a bit obscure, but even capturing changes made
only through Java code looks impossible to implement efficiently.

That said, if you have any ideas on how to deal with this, please let me
know -- it would allow us to clean up a *lot* of nasty bits in the code.

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

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

Reply via email to