[Lazarus] repaint method on Darwin/Carbon

[Brad Campbell]

Mattias Gaertner schrieb:

>>> There is no question, that such a big
>>> change is Delphi incompatible.
>> Not at all.
> 
> Do you mean: 
> 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
> ?

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 managers at all. If 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