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
