TabbedHolder?

The recent thread on card container has reminded me.

In the Video library example, there is nice usage of tab control, that
maintains the list of the tapes, and selecting a tab, selects the editor for
the tape. This example nice show a situation where card view is not
appropriate since card expects its card collection to be more or less
static, and saved in the view. Also, card container has separate view for
each of the tabs, while in VideoLibraraShell there is a tab control view,
and only one view or all tapes. Everything fine up to now.

The problem is that in the Video Library example tab view is allocated a
fixed vertical size, and if there are more tabs than this view could hold,
the tab would not get resized, and some tabs would become unvisible, in
overflown area of the tab. (also there is no need for the tab to occupy a
space that is not needed).

The same thing is not happening with CardView, and CardLayout, the tab gets
resizedcorrectly. I have looked into the CardView and CardLayout, and they
seem non trivial, and somehow playing on the borderline of MVP scheme of
things.

So my options seem to be:

a) forget about the tab that would use amout of space that it needs and
return the remaining to the other views.
b) take a deep breath and try to pull similar kind of magic as CardView and
CardLayout are, and create some sort of TabbedHolderView,
TabbedHolderPresenter, and TabbedHolderLayout.

But before I choose any of those, I thought it would be wise to ask if I am
overseeing something trivial, which would solve the problem much more easy,
with existing classes.

Thanks,

rush

Rush,

I haven't got an answer for you but I'm not sure that this  ...

> The same thing is not happening with CardView, and CardLayout, the tab
gets
> resizedcorrectly. I have looked into the CardView and CardLayout, and they
> seem non trivial, and somehow playing on the borderline of MVP scheme of
> things.

... is right. The current CardContainer uses the same underlying
CommonControl and therefore suffers from the same problem.

s := Shell show.
s view extent: 300@300.
s view layoutManager: BorderLayout new.
s view addSubView: (c := CardContainer new).
c arrangement: #center.
150 timesRepeat: [c addSubView: ContainerView new]

This uses the standard MVP control and some of the tabs are still hidden.
It's also quite amusing to see what moves where when you select a tab -
there is some logic to it!

As regards your original question.  I obviously don't know what you are
trying to do but it sounds like the sort of situation where a fixed set of
PushButtons might be the solution. Something like a set of 10 buttons (2
rows of 5 maybe) along with an up/down navigation control.  When the up/down
is pressed you change the text on the existing buttons to refer to another
selection of items but don't actually change the button controls themselves
(I suppose this might also work well with a tab control?).  Just a thought
anyway.

Regards
    Ian

"Ian Bartholomew" <[hidden email]> wrote in message
news:OEme9.3874$571.355326@wards...
> Rush,
>
> ... is right. The current CardContainer uses the same underlying
> CommonControl and therefore suffers from the same problem.

well, I think we are actually close. CardContainer is not meant to be used
dynamically, to have cards added on the fly and to have a dynamic model that
would determine which tabs need to be shown. What I meant to say is that
view composer is able to perform add card operation reliably, resizing the
tab when necessary. I think it does a a few additional calls like
invalidateLayout (compared to your example) to achieve this.

But what I meant with borderline MVP is that in CardContainer, tab view is
not handled as a normal subview, it does not end in subview collection, it
is not layed out like a normal subview, it does not connect to the model in
normal ways, etc. (I am not beeing critical about this just noticing). What
CardContainer and layout do , they declare that the whole view for the
CardContainer is tab, then ask tab how much space it has actually used, and
then layout all of the other subviews in the remaining space. Since tab is
drawn first, the subviews cover the space not used (but occupied
nevertheless) by the tab.

> This uses the standard MVP control and some of the tabs are still hidden.
> It's also quite amusing to see what moves where when you select a tab -
> there is some logic to it!

As far as I understood when you click on the visible tab, it gets selected,
and the line containig it is brought to the top or bottom row (depending if
tab is on bottom or on top), efectively putting it in invisible area :)

> As regards your original question.  I obviously don't know what you are
> trying to do but it sounds like the sort of situation where a fixed set of
> PushButtons might be the solution. Something like a set of 10 buttons (2
> rows of 5 maybe) along with an up/down navigation control.  When the
up/down
> is pressed you change the text on the existing buttons to refer to another
> selection of items but don't actually change the button controls
themselves
> (I suppose this might also work well with a tab control?).  Just a thought
> anyway.

I am writing sort of project editor. Project has a number of pages
(dynamically changing), represented by the tab at the bottom. When clicked
on the tab, the editor displays the selected page:

http://www.templatetamer.org/icons-temp/ttsnapshot2.jpg

What I currently do is placing and editor and tab in Container, with
proportional layout manager, and with splitter between them. So when tab
overfills, one is at least able to move a splitter and see the whole tab
again. Anyway this seems bit ugly and unprofessional to me, and I would like
to get rid of it.

Thanks!

rush

rush wrote:

> I am writing sort of project editor. Project has a number of pages
> (dynamically changing), represented by the tab at the bottom. When clicked
> on the tab, the editor displays the selected page:
>
> http://www.templatetamer.org/icons-temp/ttsnapshot2.jpg

You might want to check out http://www.iarchitect.com/tabs.htm from the Isys
Information Architects Interface Hall of Shame. It includes some thought
provoking ideas and examples about the use (and abuse <g>) of tabbed dialogs
from a perspective of user usability.

My suggestion comes from just a quick impression of the screen shot, and so
could be rather uninformed. Your use of tabs _might_ be an appropriate solution
to the problem you're trying to solve -- it's hard to say without spending more
time thinking about it than I can really afford. Just thought you might find the
reference useful.

regards,
-Bill

-------------------------------------------
Bill Dargel            [hidden email]
Shoshana Technologies
100 West Joy Road, Ann Arbor, MI 48105  USA

"Bill Dargel" <[hidden email]> wrote in message
news:[hidden email]...
> You might want to check out http://www.iarchitect.com/tabs.htm from the
Isys
> Information Architects Interface Hall of Shame. It includes some thought
> provoking ideas and examples about the use (and abuse <g>) of tabbed
dialogs
> from a perspective of user usability.

Thanks, it is quite interesting site. Although, upon viewing it one wonders
if he could ever do a proper interface design :)

rush