[Lazarus] PageControl vs NoteBook vs TabControl

[Andreas Schneider]

Am Freitag 05 März 2010 22:20:51 schrieb Graeme Geldenhuys:

> Wouldn't it be better to simply have one tab-type component? All
> efforts placed on only improving one component?

Here's a problem: TNotebook is _not_ a tab-type component (well, actually it 
shouldn't be a tab-type component). The Delphi implementation is more or 
less just a page manager so you can have several layers on one form that you 
can switch between. That's why it would also be important to have no borders 
on it. IMHO it's a very useful component (if implemented like in Delphi) - 
at least for smaller self-contained dialogs where frames would be "too 
much".

> Say way you want, but LCL is *not* VCL (and will never be), and
> everybody has been using non Delphi compatible PageControl & Notebook
> control for 10 years now (how ever long Lazarus exists for). So nobody
> had issues until I mentioned the duplicated efforts. I think it's more
> important in directing the little resources Lazarus team has to make
> the components they have more stable. Start by removing duplicate
> components. PageControl, TabControl, Notebook - all duplicates one one
> or two minor differences. Not enough to justify 3 separate components
> which over all do the same thing.

A TabControl in contrast to a PageControl has _no_ pages. It really only 
consists of tabs, so it isn't a container in any way.
So a PageControl is essentially a TabControl+Notebook. The "problem" here 
is, that for PageControls there usually exists an implementation on the 
several widgetsets so we can't just use TabControl+Notebook if we want the 
platform specific look. That doesn't however negate the specific usecases 
for TabControl and Notebook (see above).
I think the current PageControl and TabControl implementations are right 
(and they really differ from each other). But as was said earlier in this 
thread, the Notebook is "wrong" (and therefore currently more or less 
useless). The consequence still shouldn't be to remove it, but to fix 
(rewrite?) it. Since it will be a custom control then anyway, the future 
maintanence should be rather low, since we don't have any widgetset 
dependence.

Best Regards,
Andreas