[Lazarus] fpGUI
Mattias Gaertner
nc-gaertnma at netcologne.de
Sun Jan 16 11:30:10 CET 2011
On Sun, 16 Jan 2011 07:29:56 +0100
Martin Schreiber <mse00000 at gmail.com> wrote:
> On Sunday, 16. January 2011 01.21:01 Marcos Douglas wrote:
>
> > I do not understand why Delphi and Lazarus were made like this. Would
> > be more easy to write Forms and Widgets just with Pascal code...
> >
> The separation of code and user interface definitions has advantages.
> For example it is possible to edit and update the form layout without touching
> and parsing the code. The form layout can be modified language specific by
> resource dll's/so's. There is no danger that one destroys the the definition
> structure in source by accident. There is no danger that the IDE destroys the
> source code by accident.
> With a streaming mechanism the components have
> better possibilities to specialize and optimize their behaviour without aid
> of the IDE.
True.
Although these points are valid for both formats: lfm and pascal.
I think the advantages of the lfm format are:
- the format is very simple, everyone immediately knows what it does
and how to edit it. AFAIK the only questions about its format were
about encoding of strings.
- they are stored compressed in the executable
- allows to hook into the string reading, so that translations can be
loaded automatically while reading
I think the important point for the "stream pascal" is that it makes it
possible to run without the streaming code, so smart linking
could produce smaller executables.
> Graeme must write for every component dedicated IDE integration
> code AFAIK.
Not dedicated IDE, but dedicated streaming code. The LCL must do the
same, for example TBitmap.Data.
> Graeme probably will encounter the limitations of his approach when he tries
> to implement more sophisticated RAD possibilities into fpGUI. Visual form
> inheritance and submodules (TFrame) come to mind for example.
The complicated part of VFI/frames and modules is the writer and the
reading at design time. The runtime reader is pretty simple, except
for circle dependencies.
Graeme, how does the fpgui writer support circles?
For example:
object Edit1: TEdit
AnchorSideLeft.Control = Label1
end
object Label1: TLabel
AnchorSideTop.Control = Edit1
end
Mattias
More information about the Lazarus
mailing list