possible functionality?

pureist

I am hoping someone will know whether if for a frame (specifically left frame) that displays tabs, it is possible to have an input field/control before the tabs component itself begins, as per att. pic.
Obviously a tab pane can have multiple panels and such a field could be in the 1st panel of a tab, but the input field in question does not relate to any one tab itself, hence why it should not appear on any tab.
I am aware it is possible to have an input field as a menu item (albeit not with 2 buttons as subject input field requires), though this is not the desired solution.
Thank you,

BenHayat

pureist wrote
I am hoping someone will know whether if for a frame (specifically left frame) that displays tabs, it is possible to have an input field/control before the tabs component itself begins, as per att. pic.
Obviously a tab pane can have multiple panels and such a field could be in the 1st panel of a tab, but the input field in question does not relate to any one tab itself, hence why it should not appear on any tab.
I am aware it is possible to have an input field as a menu item (albeit not with 2 buttons as subject input field requires), though this is not the desired solution.
Thank you,

Last year I had requested for a a Tab Page (with multiple tabs) within a page section and each tab page can have several input fields in there. But I never got any replies.

pureist

BenHayat wrote
Last year I had requested for a a Tab Page (with multiple tabs) within a page section and each tab page can have several input fields in there. But I never got any replies.

Yes, a tabs component within tabs of a frame is something which is missing.
i don't think it needs to go deeper in terms of nesting (ie. a tabs component in a tab of a tabs component in a tab of a frame).
just one nested tabs component deep would be sufficient.
Thus, the obvious implementation is to extend DISPLAY LAYOUT to DISPLAY LAYOUT AS TABS, where the content panels of the tab of the VP from which the layout is sourced are displayed as tabs.
OR, preferably, simply modify DISPLAY LAYOUT so that if no tab of the VP is specified, then instead ALL the tabs of the VP specified are displayed. ie:
current:
DISPLAY LAYOUT SomeTab FROM_VP SomeVisualPerspective

displays all content panels of the tab of the VP
extended1:
DISPLAY LAYOUT AS TABS SomeTab FROM_VP SomeVisualPerspective
would instead display all content panels of the tab of the VP as tabs
extended2:
DISPLAY LAYOUT FROM_VP SomeVisualPerspective
would instead display all tabs of the VP and their content panels as tabs/content panels
--------
Another separate useful feature would be to be able to display content panels of a tab as tabs, just like they can currently be displayed as an accordion (although this dedicates an entire tab of a frame to displaying only a tabs component, just like it does for accordion layout). tabs are infinitely more useful and user friendly than an accordion. in essence, an accordion is just a variation of a tabs component in a way.
--------
And another further separate enhancement I can envisage thanks to Vladimir's devising of the Responsive Grid - Nested tree based layout configuration, is for AIM to morph into a totally flexible development tool in terms of layout.
Using his tree concept implemented in the Responsive Grid - Nested, he could actually develop that concept so as to use it as the one-stop solution for designing screen layouts with total flexibility.
As you add nodes to the tree you could specify what they are - panel; tabset; tabpane; accordion; accordiondrawer, etc.
if you add a subnode of a node which was designated as a tabset, then the node would be a tabpane, a subnode of a node designated as an accordion would be an accordiondrawer, etc.
in my scenario, in the layout configuration tree for the left frame, it would have a node designated as a panel, and then a node designated as a tabset.
the panel node would have a subnode of type inputfield and its properties could be set to the right just like happens now for content panels.
and of course the tabset node would have various subnodes, being the tabpanes
if you look at this concept from the 'helicopter', then the concept of frames could become obsolete, because they could just be nodes themselves in the single master tree which contains the configuration for the entire screen layout