[Lazarus] fpGUI

[Andreas Schneider]

 On Mon, 17 Jan 2011 10:57:57 +0100, Michael Schnell wrote:
> Obviously. My interpretation is that the two GUI designers, that of
> course manage different types of control files and use different ways
> to include the GUI design information in the runtime executable, in
> the end use the same backend to paint the control elements.

 It's not about what the GUI designers manage. In both cases, they work 
 with completely different frameworks. If you use the LCL, you are 
 working with LCL controls (TWinControl etc.) no matter what 
 backend/widgetset is used. You will always work directly with the LCL 
 which essentially is "just" another abstraction layer.
 If you use the fpGUI Designer, you work with fpGUI as framework. In 
 that particular case, you directly interact with the fpGUI controls, 
 something you don't do when working with the LCL.


> I understand that the different provenience of the two "legacy" GUI
> designers can/needs to be handled when integrating fpGUI into 
> Lazarus.
> And I feel that "in the end" both should result in a similar level of
> perfection. This might mean that a rather large integration of them
> could be desirable.

 Eventually the LCL only uses widgetsets as a means to an end. It uses 
 widgets from a widgetset to build its own controls. That may be by 
 completely integrating a certain widget or by using other means, 
 depending on what a specific widgetset offers (for example a TLabel 
 could be a real widget on GTK and maybe owner drawn on Win32). It may 
 also be, that a widgetset provides for example a TreeView that could be 
 used to realize TTreeView, but doesn't offer all the features necessary 
 so you still end up building it from a bunch of simpler widgets and 
 owner drawing.

 So no, in the end you have two completely different results/goals 
 depending on what framework you use: fpGUI or LCL - no matter if the 
 widgetset you choose is fpGUI again. You will still end up with 
 different controls, different structure and different functionality.