Hi,

Would it be possible to build the Form Designer used in Lazarus IDE as an external / stand-alone application? Something like Glade for GTK, Qt Designer for Qt or UI Designer for fpGUI.

Graeme Geldenhuys wrote

Would it be possible to build the Form Designer used in Lazarus IDE as an external / stand-alone application? Something like Glade for GTK, Qt Designer for Qt or UI Designer for fpGUI.

Do you mean, you want Lazarus to change pascal source code, based on some intermediate designer format file, that is modified by the external designer?

thanks,
dmitry

dmitry boyarintsev wrote

Do you mean, you want Lazarus to change pascal source code, based on some intermediate designer format file, that is modified by the external designer?

Not sure what you mean, but let me rephrase what I asked. Can the existing Forms Designer code used in Lazarus IDE be extracted to make a stand-alone forms designer like fpGUI's UI Designer?

So that way you can take any editor that supports external tools, and simply add the stand-alone LCL Forms Designer as an option and still be able to edit forms (*.lfm and *.pas) without using the Lazarus IDE?

Lazarus creates the forms and their content with pascal-generated code, as well in the design phase as when the program executes. The only difference is that when running in the design phase the component's code sees the "designing" flag set. It's just the same (pascal) code that runs. So there is not that much difference between the visual components' definition in the code designer and the running program.

-Michael

Would it be possible to build the Form Designer used in Lazarus IDE as an external / stand-alone application? Something like Glade for GTK, Qt Designer for Qt or UI Designer for fpGUI.

That application should include descriptions and property editors for all components, including custom components, manage unit and resource files, and more. It may be difficult to separate these parts from the remainder of the IDE, but it may be desireable to have according IDE interfaces(s) for these tasks. A step into a more modular IDE?

DoDi

Zitat von Hans-Peter Diettrich :

Some notes:
To load a form you need to register all component classes. When you want components of lazarus packages, then you need the package system. The IDEIntf provides methods to open packages and iterate the open packages.
If the form uses a datamodule, you must find the datamodule. So you need the unit search path, so you need the project system. The IDEIntf provides methods to get the project and its settings. To support visual form inheritance you need an unit graph (in lazarus this is in the project system) and some special reader parts (in lazarus: form editor). The IDEIntf allows to setup inherited forms. Nested frames is not a module of its own because it "only" makes the other parts more complicated and requires more connections between the modules.
The object inspector is an independent module in the IDEIntf. Property editors and component editors are quite independent, but if they are in a package you need the package system. They are in the IDEIntf.
Code creation: The codetools are independent and provide all stuff needed. Of course you have to setup the unit/include paths. For license reasons they are not in the IDEIntf. But they are an independent package, so you have full access.
Translations: writing the TTranslateStrings to po files (or whatever) is currently a few methods but is planned to become a module of its own. It is already on the wiki page for IDE projects. Error handling: This is the tricky part. The more modules work together the more difficult it is to create good error messages. For example when a property can not be read, there could be several reasons and can fail to load any of the above. A lot of code in the IDE is only for handling errors. Not bomb the user with successive error messages and provide all needed info.
Lazarus uses some special readers/writers in the unit lresources in the LCL. You can use them to get more detailed errors. The selected components can be found in the IDEIntf. The designer is accessible via the Form.Designer and the IDEIntf. The designer supports non LCL graphical components. See the designermediator in the IDEIntf.

IMO the fun thing about the delphi/lazarus designer is that it is integrated into all the rest.

Mattias

2010/5/7 Mattias G?rtner :

IMO the fun thing about the delphi/lazarus designer is that it is integrated into all the rest.

So the short answer is "no", a stand-alone forms designer is not feasible. Thanks for the detailed info.

Mattias' explanation is what I meant with 'there is more than the editor to lazarus'.

The IDE is a pretty awesome piece of work, of a complexity which few people realize, let alone grasp.

Michael.

I see no problems building external form designer. All you need is to read and write .lfm format. :)

And since .lfm writting/reading is based on RTTI, any FPC program should support it, natively.
as Hans-Peter has already noted, the biggest problem would be supporting custom (non LCL standard) controls, since in Lazarus they're rendering themselves. So either external Form designer must be LCL based, or must provide some way to render custom controls.

thanks,
dmitry

Zitat von dmitry boyarintsev :

Reading/Writing is done by TReader/Writer in unit Classes, which uses a "driver" to input/output the real format.
lfm is just one possible format. There are other formats: You could use lrs, binary and xml.
Graeme prefers pascal. If someone would write a driver for pascal statements, the IDE would be able to read/write the form data directly to the unit. I guestimate it needs a few days including testing. Then we could compile a special LCL without published properties to create smaller executables.

as Hans-Peter has already noted, the biggest problem would be supporting custom (non LCL standard) controls, since in Lazarus they're rendering themselves. So either external Form designer must be LCL based, or must provide some way to render custom controls.

AFAIK all designers mentioned by Graeme only supports their own widgetset. Maybe they have some interfaces like Lazarus to allow foreign components.

Mattias

2010/5/7 Michael Van Canneyt :

Mattias' explanation is what I meant with 'there is more than the editor to lazarus'.

Yes I understood that. My point about "not being feasible" is that the forms designer is way to integrated into the rest of the IDE, that it's not simply a job of moving some units into new project and compile as a stand-alone app (process simplified for this message). Meaning the IDE is not that modular.

This is ok, I was just curious if it would be possible - with relatively little effort, which it clearly is not.

The IDE is a pretty awesome piece of work, of a complexity which few people realize, let alone grasp.

Just like 'fpdoc'. :-)

Oh, fpdoc is child's play in comparison :/

But since my mental age is about 5 - according to my wife - that makes me extremely suitable to be it's maintainer :-)

Michael.

On the contrary, it seems very modular, but for a complex goal you need more complicate integration. If you were forced to use the designer wholesale, and depend on Lazarus package format, etc, then it wasn't modular ;-)
I would infer from Mattias' post that if you don't use external form references, frames or visual form inheritance, it's feasible and relatively easy/straight-forward.

Best regards,
Fl?vio

Zitat von Graeme Geldenhuys :

The designer drawing, mouse selection and aligning code is in a single unit designer/controlselection.pp. The code is one of the oldest units in lazarus and need some clean up. It contains several optimizations that are no longer needed.
Copy/Paste is almost as complicate as load, so you need big parts of the IDE.

> The IDE is a pretty awesome piece of work, of a complexity which few people > realize, let alone grasp. Just like 'fpdoc'. :-)

Mattias