Again, the reason this isn't supported is intentional. TabPane defines the APIs that all tab pane skins must adhere to, and TerraTabPaneSkin defines what all tab panes in the Terra theme look like. It isn't meant to be any more flexible than that.
However, you can easily "roll your own" tab pane using other components. For example, you could create a row of custom tab buttons using a BoxPane and a button group, and you could place your tabs in a CardPane. This may be closer to what you are looking for. On Jul 12, 2010, at 12:43 PM, aappddeevv wrote: > Yes consistent. But it would be nice as an objective to allow the tab to be > specified more in BXML. Most tabs for tab panes, and I suspect other things > like this, are really compositions of smaller objects already in the pivot > library. The objective of this approach would be to allow the specification > of the tab all in BXML (or code) and with less class inheritance imposition. > Some simple approaches allows you to customize elements of themes and > components (like tabpane) with less direct java coding and allows you to > customize skins. Since skins are just views in MVC, I don't see any reason > why this would not be a target of robust customization but I understand your > point. With some tweaks, Terra could be the last skin you ever need to > write. > > It will be different so I'll skip posting. Regardless, I'll add it to my > pivot-aspects library which focuses heavily on declarative pivot. I've > attached a description of things I have been collecting in a library, most > of it is focused on increasing declarative "programming" with BXML and > covering the last mile to the application. I needed an > objectives/requirements document to keep track of things and this is sort-of > it. > > > > -----Original Message----- > From: Greg Brown [mailto:[email protected]] > Sent: Sunday, July 11, 2010 7:41 PM > To: [email protected] > Subject: Re: [jira] Commented: (PIVOT-564) Configurable Tab text orientation > >> I think that a very small amount of plumbing, all using standard pivot > idioms (which means none of my usual tricks) could create simple templates > for components. If a look at TabPane, tab button creation is buried in the > skin. > > This is actually by design. We did it this way so that the skin can decide > how best to implement itself. We don't want to impose too many assumptions > or restrictions at the Component level. > >> You could also write a new skin or an extension of the skin (although with > the creation and instantiation buried in the skin, it's still hard to > override). > > Components in Pivot are meant to be overridden, but the same isn't > necessarily true for skins. Where applicable or beneficial, yes - but skins > are often part of a theme, and a theme is a consistent unit that, aside from > style properties, is largely transparent to an app developer. So we haven't > generally designed the Terra skins for extensibility except within the theme > itself. > >> At the very least it would provide a contrasting implementation around > 570. > > True, but the proposal in PIVOT-570 would make TabPane and Accordion more > consistent with the rest of the framework, which is nice. > > > > <Pivot-Aspects Readme.zip>
