One more issue:
Using LazyPanel does not work in the new TabLayoutPanel. I guess the
setVisible() method is no longer called on this widget (is it called
on one of the parent panels?)
On Jan 19, 5:07 pm, Joel Webber <j...@google.com> wrote:
> On Mon, Jan 18, 2010 at 6:17 AM, dflorey <daniel.flo...@gmail.com> wrote:
> > Hi,
> > I've been trying to usw the new TabLayoutPanel for different layouts.
> > Here are my findings:
>
> > 1. The .gwt-TabLayoutPanelTabs style gets applied to the wrapper
> > element with width set to >16000 px. This makes it impossible to
> > create a border around the tab bar.
> > As a workaround I had to apply a style to wrapper element like this:
> > ((Element) tabPanel.getElement().getChild(1)).setClassName(".gwt-
> > TabLayoutPanel-wrapper");
> > This is very ugly and will fail as soon as the TabLayoutPanel impl
> > changes.
> > Please consider applying the ".gwt-TabLayoutPanelTabs" style to the
> > appropriate wrapper element.
>
> This is a good point. I'll need to add another wrapper element around the
> tabs to make this work, but I don't think that will cause any problems.
> There *is* a wrapper created by the Layout class, but it's unsafe to apply
> arbitrary styles to it (in particular, decorations such as border, margin,
> and padding will confuse it -- it's actually there to work around
> measurement problems with such decorations). I've added a comment to issue
> 4429 (default TLP styles) to capture this.
>
> 2. The setStyle(Primary)Name methods will not change the substyles.
>
> > When using different TabLayoutPanels with different styles in the same
> > application you'll have to overwrite each css property as you'll
> > inherit all styles by default. It would be much better to change all
> > substyles as it has been the case with the "old" gwt widgets
>
> Actually, I can't think of any cases off the top of my head where we've
> automatically updated sub-styles like this. For example, the old StackPanel
> only modifies the top-most class name. The problem is that there are cases
> where we'd be forced to walk arbitrarily large numbers of children every
> time the style name is changed. We decided it was best to avoid this, and
> require the (admittedly somewhat uglier, and imperfect) use of descendent
> selectors. The right long-term approach is probably closer to what you
> suggest below.
>
> or - even better - to pass a ClientBundle defining all styles as an optional
>
> > argument to the cstr of the TabLayoutPanel.
> > A default style factory could provide default styles if no
> > ClientBundle is provided. Replacing the default style factory using
> > deferred binding could make the default styles themable.
> > I've used this approach in my own app and it works fine.
>
> Essentially, yes. Though it's a fairly complex design problem in the general
> case to do so in a way that ensures there's no unnecessary overhead, and
> supports all the common use cases. This is definitely a Q1 goal, and we'll
> make a point to share design docs as soon as we have a rough idea of what it
> should look like.
--
http://groups.google.com/group/Google-Web-Toolkit-Contributors
