I'd suggest a layout layer, between TControl and TWinControl, dealing with child controls (e.g. TContainerControl). As Paul pointed out, a TWinControl uses system resources (handles), which are not required for layout (and docking) managers.

Then it would be possible to have lightweight panels, where currently TPanel or similar TWinControl descendants have to be used for grouping controls together.

Delphi compatibility is not broken by such a layer. When the layout management is implemented by a LayoutManager hook, as is already used for DockManager, less (memory) resources are required for typical (button...) components, which do not normally have child controls, but inherit all the data members and other bloat from TWinControl.

DoDi

I'd suggest a layout layer, between TControl and TWinControl, dealing with child controls (e.g. TContainerControl). As Paul pointed out, a TWinControl uses system resources (handles), which are not required for layout (and docking) managers.

TWinControl has childs, TControl has not. This is usually tested with
if AControl is TWinControl then

If a TContainerControl that is not a TWinControl has childs this test will break.

Mattias

It only won't work if the old checks are used together with the new controls.

DoDi

An embedded and charset-unspecified text was scrubbed... Name: not available
Url: http://www.lazarus.freepascal.org/pipermail/lazarus/attachments/20090209/915bb908/attachment.pl

Maybe I misunderstood your proposal. What parts of TWinControl should be moved to TContainerControl? Do you want to move the ControlCount and Controls properties to TContainerControl?

Yes, all the child control related stuff. I'd move that into the LayoutManager, and redirect all related methods and properties to that helper object. Then the LayoutManager is as exchangable as the DockManager.

What about TControl.Parent?

It will be of type TContainerControl, of course. I admit that the tests for TWinControl have to be revised accordingly, but there remains more to do. E.g. it's nonsense when TWinControl redirects docking and other messages to TControl, which then again delegates the job back to its own TWinControl parent. All that docking and child control handling stuff should be entirely removed from TControl, and also from TWinControl, and instead should be moved into the layout and docking helper objects. I'm just about to find all that stuff, and to implement a direct connection between e.g. TDragManager, TDockPerformer, and the DockManager.

The legacy interface of all classes can survive that update, the revised methods only will redirect the tasks immediately to the final worker object. These are highly desireable changes, regardless of whether we introduce a new layout layer class or not. We might use conditional compilation, so that in case of trouble the old class tree remains intact, for debugging and as a last resort in case of trouble with legacy code.

IMO we should cut some of the old trees, in order to see the wood for trees again.

DoDi

Zitat von Hans-Peter Diettrich :

First of all: Yes, that would be better from object oriented point of view.

But:
At least 90% of TWinControl is about its child controls. The rest is mostly key, mouse and focus handling. I guestimate, TContainerControl will have about 1-3kloc code, 500loc will stay in TWinControl and the remaining 4-6kloc will go to the new docking/layout classes.
There is no question, that such a big change is Delphi incompatible. The question is how much:

- A lot of code (outside the LCL) relies on the fact, that AControl.Parent is a TWinControl and has a handle (exact: can have a handle).

The compiler will not find all places that needs to be fixed. For example:

procedure RecursiveCall(AWinControl: TWinControl);
begin
  for i:=0 to ControlCount-1 do
    if Controls[i] is TWinControl then
      RecursiveCall(TWinControl(Controls[i]));
end;

This recursive call won't find all children anymore.

So all users have to check every place manually, where TWinControl is used and maybe replace it with TContainerControl.

Mattias

I don't think this is a very good idea.

Michael.

Not at all.

When a GUI is made of traditional components, then the parents will be TWinControls, of course. A form will continue to inherit from TWinControl...

DoDi

a) There no question at all that it will be Delphi incompatible b) It will not at all be Delphi incompatible, because TWinControl will not change
?

I didn't doubt that.

Maybe you can give more details how the gt protected props/methods of TWinControl should change?

Mattias

Sorry for my bad Denglish :-(

[a] The intended changes will not break Delphi compatibility.

Maybe you can give more details how the gt protected props/methods of TWinControl should change?

"gt"?

Some of the suggested changes are mentioned in my recent bug report and patch, concerning the handling of docking. I'd appreciate if that patch would be applied soon, so that I have that list of ToDo items for my further work on this topic. Unfortunately my physical and virtual machines still suffer from hardware problems, so that I don't have at hand the tracker ID of that patch :-(

The layout related changes are only an idea at the moment, inspired by the intended implemenation and integration of e.g. a MiG layout manager. I have no concrete idea yet, about a usable general interface between controls and an separated layout manager. When I'm done with the docking changes, I can e.g. introduce a dummy TContainerControl=TWinControl class, and change all affected TWinControl references accordingly. Then we could identify the places, where the layout related changes changes would have an impact on existing code.

I have a couple of questions myself, about e.g. the many different control sizes in TControl (BaseRect...), and other layout related properties. Try to imagine the many new control properties, required for the implementation of the MiG layout manager. IMO it's impractical to add all these parameters explicitly to TControl, over and over again for every new layout (or docking) manager. Instead I'd introduce a somewhat unspecific property TControl.LayoutData, refering to a layout manager specific data object. The TDockZone data structure of the TDockTree manager already is kind of such a data structure, which could be attached to every TControl, so that FUndockedWidth etc. members could be moved into that data structure.

Consequently the primary question should be, whether we are *willing* to allow for different layout yes, we'll *have* to
design an according interface between controls and layout managers, and we'll *have* to update the control classes accordingly. The questions about Delphi and legacy compatibility only can be answered *after* the implementation of the new interface. When we *then* find layout managers absolutely incompatible with Delphi and legacy code, we have several options. My preferred option is a splitted LCL, similar to the VCL/CLX fork in Delphi, but in a better manageable way. I'd do that by conditional compilation of the LCL, steered by a project wide option. This would allow to have:
- a "slim" LCL version, almost a clone of the VCL,
- a "compatible" version, including support for anchored controls, and
- a "extensible" version, with support for layout managers and more. Only the extensible version might be not 100% compatible with Delphi and legacy code. It might become slim as well, by binding it to dedicated widgetsets (Win32, Qt...), if the users want such an option, or it might become fat when everything is done in the library, as IIRC is the approach of fpGUI. A slim version IMO would be nice for embedded devices, where available RAM (currently) imposes some limits.

I understand the value of Delphi compatibility, but I cannot accept that such compatibility should block forever the evolution of new features.

DoDi

Hans-Peter Diettrich wrote

widgetsets (Win32, Qt...), if the users want such an option, or it might become fat when everything is done in the library, as IIRC is the approach of fpGUI. A slim version IMO would be nice for embedded devices, where available RAM (currently) imposes some limits.

fpGUI might do everything itself, but it is a *lot* less bloated that binding to Win32, Qt, GTKx etc. By bloated I mean memory wise and hard drive space (install) size.

I understand the value of Delphi compatibility, but I cannot accept that such compatibility should block forever the evolution of new features.

This has been a battle between myself and LCL developers has well (the mailing list history will show that <smile>). For LCL developers, Delphi compatibility and native components are king. For my day-to-day work, that did not suite our company well - we needed more flexibility and hence the reason fpGUI exists.

Regards,
- Graeme -

_______________________________________________
fpGUI - a cross-platform Free Pascal GUI toolkit
http://opensoft.homeip.net/fpgui/