Thanks for the feedback.
While I haven't prototyped it yet, I don't see any reason why adding or
removing tabs would not work with the proposed API. It should be a
simple matter of adding or removing children from the TabGroup.
E.g.
TabGroup { id: tg }
Component {
id: someTab
Page {}
}
Button {
text: "Add a tab"
onClicked: someTab.createObject(tg)
}
That should add an instance of "someTab" as a new tab in the TabGroup.
Peppe
On Tue, 2010-12-21 at 09:06 +0100, Thomas Hartmann wrote:
> Hi,
>
> from the tooling perspective (Visual Designer) this seems absolutely ok.
>
> There is only one thing I want to mention:
>
> The TabWidget example does not work properly with the Visual Designer
> (yet), because the example cannot handle adding pages/tabs
> dynamically. The reason is that some intial setup is done in onCompleted
> (only). The only way to fix this for visual editing is that we have to
> recreate
> the entire tab widget each time another tab is added or the order is
> changed (or to fix/change the example).
>
> Since adding tabs dynamically seems also to be a valid use case also for
> applications, I propose that the real components tab widgets should
> allow this (Adding a tab after the tab widget was constructed).
>
>
> Kind Regards,
> Thomas Hartmann
>
> Lundqvist Petrus (Nokia-MS/Helsinki) schrieb:
> > I'm requesting comments for a proposal for a common API for tabs, i.e. a UI
> > split into overlapping panes of content.
> >
> > The proposed API can be split into two parts both logically and visually.
> > The first part is the UI used to activate (switch) tabs. The second part is
> > the UI where the contents of tabs are contained.
> >
> > Tab activation (switching) can differ from platform to platform and thus I
> > propose to de-couple these two things from eachother in a way that still
> > makes integration in an application trivially simple. E.g. on one platform
> > tab switching may happen from buttons in a toolbar. In another platform a
> > special "tab bar" with visual notebook-tabs might be used. And on a third
> > platform a gesture might be employed.
> >
> > This portion of the proposal would thus not be defined in a common API.
> > However there would be platform-specific implementations for this e.g. for
> > MeeGo.
> >
> > For the tab contents I propose that any QML item would be allowed to define
> > a tab, with special support for Page and PageStack (landed in the
> > Qt-Components git master branch on Friday). The tab container would be a
> > QML item used as a common parent for the tabs. In addition there would be a
> > property "currentTab" that tracks the active tab (the one that is shown).
> > Tabs would be defined directly as child items for the container. The name
> > of the container is proposed to be TabGroup. A TabGroup would thus have the
> > following common API:
> >
> > TabGroup {
> > property Item currentTab
> > }
> >
> > Of course there is an implicit onCurrentTabChanged singal too.
> >
> > Typical usage would be as follows (layout-related properties are omitted)
> > e.g. in the main QML file of an application:
> >
> > TabGroup {
> > id: tg
> > currentTab: tabA
> > PageStack {
> > id: tabA
> > }
> > Page {
> > id: tabB
> > }
> > PageStack {
> > id: tabC
> > }
> > }
> >
> > Tab switching is done simply by changing the value of the currentTab
> > property, e.g. as follows from a hypothetical TabButton somewhere in the UI
> > (a tab bar, toolbar, or similar):
> >
> > TabButton {
> > text: "Tab B"
> > onClicked: tg.currentTab = tabB
> > }
> >
> > A trivial implementation of the TabGroup that does not implement animations
> > could be as simple as this:
> >
> > Item {
> >
> > property Item currentTab
> >
> >
> > onCurrentTabChanged: {
> >
> > for (var i = 0; i < children.length; i++) {
> >
> > children[i].visible = (children[i] == currentTab);
> > }
> >
> > }
> >
> >
> > Interested parties can listen to tab switches using the same
> > onCurrentTabChanged signal that is used internally to switch the visible
> > state of the tabs defined in the TabGroup.
> >
> > The above code is sufficient if PageStack's are used as tabs because
> > PageStack is implemented to emit activated and deactivated signals in a way
> > that is synched with the visibility of the PageStack (and thus the current
> > page in the stack). I.e. if you switch from tab A to tab C you will get a
> > deactivated signal in the current page in tab A followed by an activated
> > signal in tab C.
> >
> > In order to support Page's as well with activated and deactivated signals
> > firing appropriately the onCurrentTabChanged signal handler would have to
> > be slightly more elaborate and the TabGroup implementation could be
> > something along these lines:
> >
> > Item {
> >
> > property Item currentTab
> >
> >
> > onCurrentTabChanged: {
> >
> > for (var i = 0; i < children.length; i++) {
> >
> > var child = children[i];
> > var vis = (child == currentTab);
> > if (child.visible != vis) {
> > child.visible = vis;
> > if (vis && child.activated) {
> > child.activated();
> > } else if (!vis && child.deactivated) {
> > child.deactivated();
> > }
> > }
> > }
> >
> > }
> >
> >
> > In other words, when visibility changes and a tab has an activated or
> > deactivated signal, then these are emitted according to the visibility
> > state change.
> >
> > A back-button or other mechanism for back-stepping in an application UI can
> > easily be made to work globally between multiple tabs as follows:
> >
> > ToolButton {
> > text: "Back"
> > onClicked: tg.currentTab.pop()
> > enabled: tg.currentTab.depth > 1
> > }
> >
> > In addition to the proposed common API for TabGroup an implementation would
> > be made for the MeeGo -styled Qt-Components for a tab switching button for
> > use in tab/toolbars, as appropriate. The implementation and API of such a
> > button would closely mirror the current ToolButton.
> >
> > I have a working prototype / implementation of the proposed API that I'd be
> > more than happy to show. Just drop me an email if you want to try it out.
> >
> > Peppe
> > _______________________________________________
> > Qt-components mailing list
> > Qt-components@qt.nokia.com
> > http://lists.qt.nokia.com/mailman/listinfo/qt-components
> >
>
>
_______________________________________________
Qt-components mailing list
Qt-components@qt.nokia.com
http://lists.qt.nokia.com/mailman/listinfo/qt-components
