(copied conversation I started in the wrong place) 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.
Comment 6 by j...@google.com, Today (18 minutes ago)
The code review page would be more appropriate, but I'm fine with
discussing here for the time being.
The reason we have both LayoutPanel.setWidgetVisible() and
Widget.setVisible() is, like so many things, a side-
effect of the mess that is HTML/CSS. The Layout/Layer code *has* to
create container elements to work
around various design flaws in the CSS layout model. But if you just
call Widget.setVisible() on one of the
children, its container element must be hidden as well. But
Widget.setVisible() has no way of doing this
sensibly. I don't particularly like this fact but we're stuck with it
as long as we have to target HTML/CSS.
Also, I have not looked at issue 4694 yet, but will see if there's a
similar issue at fault.
Comment 5 by kozura Apart from whether this works to solve the issue, I'm always nervous
to see multiple
public methods that to a normal user appear to do the same thing, so
setWidgetVisible
gives me pause. As a user, why is there this function, and
setVisible? Are they
just different ways to do the same thing? If not, which do I call?
Do I need to
call both? There are already a number of these ambiguous functions
throughout GWT
code (and here too - should I be posting these comments here on the
issue page, or on
the code review page...), so can this be done logically without
having to create a
separate but similar public function?
Also, will this address the slightly different but similar issue I
posted with IE8,
http://code.google.com/p/google-web-toolkit/issues/detail?id=4694 ?
I don't think so
as it is, but maybe if the solution is similar it can be expanded?
http://gwt-code-reviews.appspot.com/153820 -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
