Re: [Lazarus] Docking and Layout managers
On Tue, Feb 10, 2009 at 12:07 PM, 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 ). 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/ ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
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 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
On Mon, 09 Feb 2009 23:03:47 +0100 Hans-Peter Diettrich wrote: > Mattias Gärtner schrieb: > > > 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. > > 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 ? > > 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). > > When a GUI is made of traditional components, then the parents will > be TWinControls, of course. A form will continue to inherit from > TWinControl... I didn't doubt that. Maybe you can give more details how the gt protected props/methods of TWinControl should change? Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Mattias Gärtner schrieb: > 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. Not at all. > 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). 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 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
On Mon, 9 Feb 2009, Mattias Gärtner wrote: > Zitat von Hans-Peter Diettrich : > > > Mattias Gärtner schrieb: > > > > > 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. > > 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. I don't think this is a very good idea. Michael.___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Zitat von Hans-Peter Diettrich : > Mattias Gärtner schrieb: > > > 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. 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 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Mattias Gärtner schrieb: > 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 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Zitat von Hans-Peter Diettrich : > Mattias Gaertner schrieb: > > >> 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. > > It only won't work if the old checks are used together with the new > controls. 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? What about TControl.Parent? Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
Mattias Gaertner schrieb: >> 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. It only won't work if the old checks are used together with the new controls. DoDi ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
Re: [Lazarus] Docking and Layout managers
On Sun, 08 Feb 2009 07:50:50 +0100 Hans-Peter Diettrich wrote: > 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. > 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. Mattias ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
[Lazarus] Docking and Layout managers
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 ___ Lazarus mailing list Lazarus@lazarus.freepascal.org http://www.lazarus.freepascal.org/mailman/listinfo/lazarus
