[Lazarus] gtk2 notebooks

[Hans-Peter Diettrich]

Felipe Monteiro de Carvalho schrieb:
> There is something, however, that I would like to clarify.
> 
> What exactly is wrong with the current TTabControl that you want to
> fix? What exactly does it do that you expect it to do differently?

I started with a test program in Delphi, and used it to test the Lazarus
TTabControl. And because the Lazarus component didn't pass the test, I
started to update the Win32 widget to behave like in Delphi.

The biggest issue is the container property of a TTabControl, that
allows to put any controls into its Tabs.Objects[], and to make one of
these controls visible by selecting its associated tab. This behaviour
is e.g. required for notebook docking. It also should be possible to put
a single control (memo...) into a TTabControl, and to update its content
according to the selected tab.

I could not yet achieve this compatible behaviour with gtk2, where child
controls of a TTabControl cannot be made visible by simply switching
their Visibility - i.e. by the procedure applicable to every container
control.

It seems to be possible, though, to have components added to the
TTabControl at design time, which stay visible when tabs are added
later. This behaviour is broken when pages (TTabSheets) are added for
every tab, or when components are added later, after tabs have been created.

IOW a TTabSheet should have a single client area, regardless of the
number of added tabs, and it should be possible to put components into
that area at runtime, by setting ctrl.Parent:=TabCtrl.


> I know that the class hierarchy is wrong, but I am not sure if this
> cannot be fixed by simply overriding for example the handle creating
> and making it create a TCustomControl Widget and then custom paint it
> like now.

Can you find solutions for the above scenarios (basic behaviour)?


> What I want to clarify is if you are really implementing TTabControl
> or a new component. If it is a new component, what exactly should it
> do? If it is TTabControl, is it 100% compatible with Delphi?

As you can see from above scenarios, I *only* want a TTabControl with
*full* Delphi compatibility - not less and not more. More can be added
at any time, while less is tolerable only when there exists no way 
around the different behaviour of other widgetsets.

> Will existing Lazarus code which uses TTabControl keep running?

That's another issue, depending on which implementation the code relies. 
When it relies on the old (Delphi incompatible) behaviour, the code 
should either be updated to use the old (Lazarus specific) control (easy 
way), or the code has to be modified to use the Delphi compatible 
control (may be harder, but also may result in less code with less 
workarounds). E.g. the handling of the Z-order of the pages can be 
removed from the LCL high-level code, because nothing like that is 
required for the Win32 widgetset, and can be moved into the other 
widgetsets, as far as it is definitely required there.

BTW the old TTabControl designer works perfectly with the new Win32 
widget, while it trashes or crashes with e.g. the gtk2 widgetset - 
either it crashes at design time, or the application will crash when the 
component is loaded at runtime. Consequently the widgetsets *should* be 
made Delphi/Win32 compatible, so that the designer stays independent 
from the widgetset.

DoDi