Good point as well, thanks. I've updated issue 4259 to capture this. On Tue, Jan 19, 2010 at 2:08 PM, dflorey <[email protected]> wrote:
> 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 <[email protected]> wrote: > > On Mon, Jan 18, 2010 at 6:17 AM, dflorey <[email protected]> > 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 >
-- http://groups.google.com/group/Google-Web-Toolkit-Contributors
