Hi all,

I'm testing fpGUI on Lazarus and following the link: http://wiki.lazarus.freepascal.org/fpGUI_Interface#Creating_your_first_LCL_application_with_fpGUI (step 3.1)

It installed "like a charm" and projects build well.

Projects start with Win9x-like theme, but I read that I can make working current OS theme (XP -> 7, "Ubuntu", etc)... how can I do this?

Is there a tutorial to learn how to use more deeply fpGUI with Lazarus (but starting from the basics)?

I noticed that GLScene ( svn co
https://glscene.svn.sourceforge.net/svnroot/glscene/trunk GLScene ) hasn't the "widget" part to work. I don't know where to start, but maybe for Graeme or lot of you is a trivial thing...

This is the part (I think) of GLWidgetContext.pas that should be modified, at my eyes it seems that it simply needs to add some unit, but I really don't know:

_____________________
  //Widgets
{$IF  DEFINED(LCLwin32) or DEFINED(LCLwin64)}
  Controls, WSLCLClasses, Win32Int,
  Win32WSControls, Win32Proc, LCLMessageGlue;
{$ENDIF}
{$IFDEF LCLGTK2}
gtk2proc, gtk2, gdk2, gdk2x, gtk2def;
{$ENDIF}
{$IFDEF LCLGTK}
gtkproc, gtk, gtkdef, gdk;
{$ENDIF}
{$IFDEF LCLQT}
QT4, QTWidgets;
{$ENDIF}
{$IFDEF LCLfpgui}
{$MESSAGE Warn 'LCLfpgui: Needs to be implemented'}
{$ENDIF}
{$IFDEF LCLwinse}
{$MESSAGE Warn 'LCLwinse: Needs to be implemented'}
{$ENDIF}
{$IFDEF LCLcarbon}
//    {$MESSAGE Warn 'LCLcarbon: Needs to be implemented'}
{$ENDIF}
_____________________

Thank you,
Kjow

OK, but is the implementation status at
http://wiki.lazarus.freepascal.org/Roadmap#Status_of_components_on_each_widgetset up to date? I did earlier say that the situation was unclear, and that table hardly helps matters.

2011/1/5 Mark Morgan Lloyd :

OK, but is the implementation status at http://wiki.lazarus.freepascal.org/Roadmap#Status_of_components_on_each_widgetset up to date? I did earlier say that the situation was unclear, and that table hardly helps matters.

I think that this link is not updated... I made a stupid app with some buttons, MainMenu, PaintBox, etc and it worked... so I think that the link is not updated. Maybe Graeme could update the wiki. :)

Now, I don't know if and what is missing... but it seems to be a real good "GUI".

Regards,
Kjow

I think that Graeme could usefully devote some of his sound and fury to maintaining that, rather than gitting upset when he thinks his endeavours are under-appreciated :-)

I for one have been keeping an eye on that table, because I think that fpGUI would potentially be useful in conjunction with FluxBox which I already use on low-resource systems. But it appeared so under-featured that it was unclear it deserved more detailed investigation.

Hello Lazarus-List,

Wednesday, January 5, 2011, 5:23:01 PM, you wrote:

MML> OK, but is the implementation status at
MML> http://wiki.lazarus.freepascal.org/Roadmap#Status_of_components_on_each_widgetset MML> up to date? I did earlier say that the situation was unclear, and that MML> table hardly helps matters.

I think I was the last one that commit something to LCLfpGUI 6 months ago. Controls in standard tab should work (with some problems maybe) but the components in other tabs could or could not work because I started working from the standard ones. There are still some bugs in the standard ones but stopped updates mainly because fpGUI does not have a graphics support defined (I think it is ready now) and many controls needs some kind of graphics, so pause the update.

I'm pretty sure that I did some bad decisions in the update, so please if somebody see an implementation design bug post a bug in the tracker, or even bugs in the standard tab components.

Kjow wrote

I'm testing fpGUI on Lazarus and following the link: http://wiki.lazarus.freepascal.org/fpGUI_Interface#Creating_your_first_LCL_application_with_fpGUI (step 3.1)

That would be for using LCL-fpGUI (LCL with fpGUI as the backend widget set). I don't maintain that simply due to time constraints, but some other developers do. As far as I know all the components on the Standard palette in Lazarus IDE work.

My suggestion now would be to or help implement the remainder of LCL-fpGUI, or use fpGUI directly (no LCL involvement). I do the latter, and simply use Lazarus IDE as my editor.

Projects start with Win9x-like theme, but I read that I can make working current OS theme (XP -> 7, "Ubuntu", etc)... how can I do this?

I have started work on theming again, but haven't implemented all the "standard" OS themes yet. For an example of how to implement your own theme, see the <fpgui>/examples/gui/customstyles/ demo.

Is there a tutorial to learn how to use more deeply fpGUI with Lazarus (but starting from the basics)?

Yes there are, by using fpGUI directly (not via LCL). All the demos in the <fpgui>/examples/ directory are kept simple and only explains one feature per demo, to help with learning fpGUI. Michael van Canneyt also wrote an introductory article on fpGUI (available from http://opensoft.homeip.net:8080/articles/ for download). Keep in mind Michael wrote that two years ago, so things might have changed a bit since then. Then there is also the usual FAQ, README, INSTALL, Class Design etc text files in the <fpgui>/docs/ directory.

Mark Morgan Lloyd wrote

OK, but is the implementation status at http://wiki.lazarus.freepascal.org/Roadmap#Status_of_components_on_each_widgetset up to date? I did earlier say that the situation was unclear, and that table hardly helps matters.

Those tables only relate to what has been implemented in LCL (in this example, using fpGUI as a backend). In our earlier discussion (about ARM development) I was talking about using fpGUI directly (no LCL involvement), in which case most used features are all implemented.

On the wiki page you mentioned, above each table it also clearly states that it only lists the LCL implemented features, and not the features of each individual gui toolkit itself. So it should be clear what the tables are referring too.

As for the question about if those tables are up to date, I have no idea. I'm not involved with LCL development. The job of updating those tables will fall onto the persons developing LCL.

Mark Morgan Lloyd wrote

I for one have been keeping an eye on that table, because I think that fpGUI would potentially be useful in conjunction with FluxBox which I already use on low-resource systems.

I fully agree. I think it will be great having a fully implemented LCL-fpGUI, and many have mentioned that as well. I can list many benefits. Unfortunately my plate is already very full with my family responsibilities, my daytime job, fpGUI, tiOPF and DUnit2 development.

Graeme Geldenhuys wrote

use fpGUI directly (no LCL involvement). I do thelatter, and simply use Lazarus IDE as my editor.

Which I suspect is not a viable option for comparative beginners (at least as far as Lazarus is concerned) such as Bo and myself, and which potentially makes it far more difficult for other users to help with problems.

Graeme, please excuse my not quoting your entire message for context but for some reason your postings are appearing without line breaks, i.e. each para is on a single long line.

Thanks Jos?, I really must find time to try it out since it looks extremely useful.

Op 2011-01-06 10:41, Mark Morgan Lloyd het geskryf:

Which I suspect is not a viable option for comparative beginners (at least as far as Lazarus is concerned) such as Bo and myself, and which potentially makes it far more difficult for other users to help with problems.

Not quite sure why you say "more difficult"? To write applications for LCL or fpGUI, you need to type text into the source editor. :) For UI Designing, do it via code, or the easy way, using a UI designer. Both LCL and fpGUI has visual UI designers (and fpGUI's one integrates well with Lazarus IDE): click to select a new widget, click on designer form to place it, drag and resize the widget to desired location and size, then save form. That's all pretty easy to me. Yes fpGUI has differences, just like LCL has differences to VCL - but overall, things work much the same (same programming language, similar components, similar events, etc).

Here is a short animated gif showing form designing with fpGUI's UI Designer. 1 minute screencast, 1.1MB download.

http://opensoft.homeip.net:8080/~graemeg/editform.gif

for some reason your postings are appearing without line breaks, i.e. each para is on a single long line.

That's weird. I use Mozilla Thunderbird, and sometimes Gmail web - both very common email clients. Maybe your email client (Icedove?) doesn't support flow-wrapping (text gets auto wrapped by email client - no hard line breaks). Flow-wrapping (or whatever it is called) is quite common these days, and used by most email clients.

Regards,
- Graeme -

Icedove is Thunderbird without the non-free bits, basically. I use it too, and it seems to work fine with your emails. Perhaps I have a later version than Mark.

Henry

Op 2011-01-06 12:15, Henry Vermaak het geskryf:

Icedove is Thunderbird without the non-free bits, basically. I use it too, and it seems to work fine with your emails. Perhaps I have a later version than Mark.

Thanks Henry. I see you are using v3.0.11 of Icodove. Mark is using Icedove 1.5.0.14eol (X11/20090106) - which seems rather old (2 major version back) compared to yours, so that is probably the problem then.

Regards,
- Graeme -

[OT] Thanks for that Henry. I must say however that (looking back over the last day in this ML and elsewhere) it's only Graeme's postings that appear to be causing problems, and the reader I'm using is from Debian "Etch" on my desktop machine which for various reason's isn't going to be upgraded in the short term.

The problems are happening when the body of the message looks like this

Op 2011-01-05 15:05, Mark Morgan Lloyd het geskryf:> > Right, so you're saying that [...]

but not when it looks like this

Op 2011-01-05 15:23, Bo Berglund het geskryf:

So basically a widget set is a definition on what kind of graphics environment is used on the target system then?

Please excuse the micro-rant but I that the fewer people who feel mis-understood and under-appreciated the better, and making sure that posts are readable by everybody is a good first step :-)

Op 2011-01-06 12:48, Mark Morgan Lloyd het geskryf:

Op 2011-01-05 15:23, Bo Berglund het geskryf: > So basically a widget set is a definition on what kind of graphics > environment is used on the target system then?

Not sure how this is going to look at your end, but your second example of quoted text, is exactly how I see it on my side, when I reply to any message. Even if the original message was in HTML format, my email client (Thunderbird) is setup to only use plain/text emails (I personally hate HTML emails).

Attached is a screenshot of what I see, when I wrote this message.

Regards,
- Graeme -

Very good! I had not seen yet.
It has more components?

Marcos Douglas

Op 2011-01-06 13:39, Marcos Douglas het geskryf:

It has more components?

Yes there are a few more visual components that I haven't registered with the UI Designer yet. I also don't register non-gui components (eg: Timer, FileDialog, FontDialog etc) with the UI Designer, because they are very easy to use from code anyway, and with better control over lifetime & memory management. eg: I don't like having a TFileDialog instance created and using memory when I might not need it every time I run my app, so I rather create it at runtime, only when I need it, and free it when I'm done.

Regards,
- Graeme -

Hi Graeme

Graeme Geldenhuys wrote

Here is a short animated gif showing form designing with fpGUI's UI Designer. 1 minute screencast, 1.1MB download. http://opensoft.homeip.net:8080/~graemeg/editform.gif

Other than the obvious use of free pascal (fp ide, I think) what software did you use to capture the screen images and save them as an animated gif image? Was there any extra work for you to make it a self repeating/looping animated gif ?

Regards, - Graeme -

Pew :-)

The "IDE" you saw was the fpGUI uidesigner. To try it yourself you can download a 2-3 MB zip from this page:
http://www.turbocontrol.com/easyfpgui.htm

Pew wrote

Other than the obvious use of free pascal (fp ide, I think) what software did you use to capture the screen images and save them as an animated gif image? Was there any extra work for you to make it a self repeating/looping animated gif ?

I documented it a while back on the FPC wiki site.

http://wiki.freepascal.org/Creating_animated_gifs_for_wiki

XVidCap to capture the screenshots (10fps is a good speed). I then use GIMP to optimize for differences between images and then save it as a gif. In the save dialog there is a checkbox you can toggle to loop the animation or not.

GIMP is available for most platforms. I don't know what software you can use to capture many screenshots as screencast on other platforms, sorry. I only use Linux.

mine, too... i always do plain text as it makes things a lot easier to read... especially source code snippets... i also forced a mono-width font to be used... generally one of the OCR ones... OCR-B i think ;)

(I personally hate HTML emails).

i don't mind them when they are necessary but for the most part, no thanks :)

[ONTOPICIZER]
fpGUI is in my toolbox and is one of the items i'm making time to work with... i like what i've seen but have very limited time to play "coder" these days... i've numerous projects on my list that i'm aiming to port from perl and old TP6 stuff ;)
[/ONTOPICIZER]

What I should have written is that the examples I pasted were from the unformatted source of the emails, rather than what was rendered on the screen. So when Graeme sends something out without a line break after the "het geskryf:" I at least get a screwed display.

I guess that's my problem if it affects nobody else, but it does mean that I'm inclined to hit the "Next" button without lingering.

> (I personally hate HTML emails). i don't mind them when they are necessary but for the most part, no thanks :)

I agree. We send tabular reports to customers- generated by lots of custom Delphi- as HTML, but that's a special case.

Op 2011-01-07 10:30, Mark Morgan Lloyd het geskryf:

I send a LOT of emails per day, and you are the first to complain about my emails not wrapping. I have no clue what can cause that.

Interestingly, I checked the source of your message I am replying to, and it seems even your version of Icedove supports flowed wrapping (which was the feature I mentioned before).

Extract from you previous message:

Content-Type: text/plain; charset="us-ascii"; Format="flowed"

I agree. We send tabular reports to customers- generated by lots of custom Delphi- as HTML, but that's a special case.

That is a special case indeed, and I can live with that too. HTML formatted message definately don't belong in mailing lists though. I think we all agree on that.

Regards,
- Graeme -

Does this mean that _currently_ fpGUI projects' look and feel can't be designed with Lazarus, but needs to be done separately with a dedicated "fpGUI designer" software.

I suppose this will create a resource file that can be integrated in a Lazarus project to create the pascal code and to do debugging. Correct ?

I suppose to do a full integration in Lazarus each FPGUI control would need an additional - say - qt-compatible design-time implementation. Seems like a lot of work.

Any chance (for me) for doing this on a per-control basis when working with a newly started project ?

-Michael

Yes.

I suppose this will create a resource file that can be integrated in a Lazarus project to create the pascal code and to do debugging. Correct ?

No. It creates code in a 'AfterCreate' procedure to create the layout of your form. (Well, partially. Not all properties can be set).

I suppose to do a full integration in Lazarus each FPGUI control would need an additional - say - qt-compatible design-time implementation. Seems like a lot of work.

It is. Doubly so because fpGUI is very sensitive to the order in which you do things.

Michael.

No. It creates code in a 'AfterCreate' procedure to create the layout of your form. (Well, partially. Not all properties can be set).

Hmm. I understand from your words that "AfterCreate" is called as an event of the (main-) form. So some LCL based form creating code is run before. I suppose that the "AfterCreate" code reads some data (supposedly from a resource) when running and this resource will be created from some file generated by the fpGUI form designer.

So it seems to be no great problem to integrate the runtime code for this in the LCL's "fpGUI" Widget Type code so that it is not visible for the user any more (while of course integrating the fPGUI form designer into Lazarus seems a lot more work, as each control needs it's dedicated design time code.)

-Michael

No, you're wrong. "AfterCreate" is a virtual method of TfpgForm which is overwritten by the designer. It uses fcl-passrc to parse the code and recreates code again. No LCL involved in that process anywhere.

Ahm... in the LCL's fpGUI widget set the usual resource system of Lazarus is used already. But a LCL-fpgui application pure fpgui application (for the second one it's unimportant whether you use Lazarus as "source editor" or not).

Regards,
Sven

Op 2011-01-10 12:37, Michael Schnell het geskryf:

Does this mean that _currently_ fpGUI projects' look and feel can't be designed with Lazarus, but needs to be done separately with a dedicated "fpGUI designer" software.

That's correct for pure fpGUI projects (no LCL involvement).

I suppose this will create a resource file that can be integrated in a Lazarus project to create the pascal code and to do debugging. Correct ?

No, fpGUI's UI Designer generates actual source code (no external resource files or extra *.lfm type files). The generated source code for the UI is placed in a Form's method called AfterCreate(), that is automatically called from the base Form's overridden AfterConstruction() method - as the first line in that implementation.

So the UI initialization happens after the Form's constructor, but before the form is shown.

I suppose to do a full integration in Lazarus each FPGUI control would need an additional - say - qt-compatible design-time implementation. Seems like a lot of work.

Lazarus does seem to have a relatively new feature in it's form designer, where non-LCL form designers can be created, but I have no idea how that works, or what is required to make it work.

Any chance (for me) for doing this on a per-control basis when working with a newly started project ?

I guess you can, but I would simply use the existing form designer included with fpGUI. I've been using it for two years with great success.

Regards,
- Graeme -

Op 2011-01-10 12:41, het geskryf:

... fpGUI is very sensitive to the order in which you do things.

That's simply because the UI is defined as actual source code (just like Qt Creator, any Java form designer, MS Visual Studio etc), and gives the developer a guaranteed creation order of components. I don't see that as a bad thing, just different to Lazarus and Delphi's UI designers, which use external "object form file" to load the UI.

Regards,
- Graeme -

Here is a rather short excerpt about this topic:
http://wiki.lazarus.freepascal.org/Extending_the_IDE#Writing_a_designer_mediator

There also was an article in a Toolbox last year (or the year before?) about this feature (I can look up the issue if you want).

I already thought about working on that for fpGUI, but my priorities are currently more with FPC features.

Regards,
Sven

Op 2011-01-10 13:09, Michael Schnell het geskryf:

event of the (main-) form. So some LCL based form creating code is run before.

Yes, I think so (though not 100% sure how LCL works).

I suppose that the "AfterCreate" code reads some data (supposedly from a resource) when running and this resource will be created from some file generated by the fpGUI form designer.

The code inside AfterCreate is pure object pascal code, there are no external resource files. The fpGUI UI Designer generates source code.

For the LCL-fpGUI widgetset in LCL, you simply do what the LCL always does, read the UI from the *.lfm file. In the case of LCL-fpGUI widgetset, there is no need for using the AfterCreate can test this yourself, by creating a LCL-fpGUI based application and using any of the Standard Component Palette components. LCL's form designer generates a *.lfm file, like normal.

Regards,
- Graeme -

Sven Barth wrote

,,,

At this point I'd need to do some testing myself before I can understand what is happening.

I'll do so once I get a current Lazarus from the svn going :(.

-Michael

Graeme Geldenhuys wrote

The fpGUI UI Designer generates source code.

I see. I understand that the Lazarus `form designer creates a resource that is interpreted by the runtime Form creating process (an at design time by the design time Form creating process in a very similar way).

Why does fpGUI go the other way ?

You can test this yourself, by creating a LCL-fpGUI based application and using any of the Standard Component Palette components.

Once I happen to get Lazarus running again ;)

LCL's form designer generates a *.lfm file, like normal.

But I suppose they are not used at all, so using the Lazarus Form designer for an fpGUI project does not make any sense. Correct ?

-Michael

Sven Barth wrote

Here is a rather short excerpt about this topic: http://wiki.lazarus.freepascal.org/Extending_the_IDE#Writing_a_designer_mediator

"This can be used to design webpages, UML diagrams or other widgetsets like fpGUI <http://opensoft.homeip.net/fpgui/>"

Looks like the way to go on the long run...

Besides fpGUI they already did think about remote GUI stuff like "Webpages".

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110110/221e4f97/attachment.html>

If I recall correctly, Graeme dislikes the "resource form" approach used by Lazarus and Delphi. (@Graeme: please correct me, if I'm wrong here)

Wrong.

Let's try this another way:
LCL applications don't need to use resource components can be created at runtime by overriding the constructor (Create) of TForm. Normally the constructor searches a resource file, creates all child classes that are found in there and assigns the properties/events found in the resource file.

Now a pure fpGUI project only does the first: create components at runtime in a "special" method.

An LCL-fpGUI application does the same as other LCL applications: it searches a resource, creates the child components and assigns the properties. This works, because a TButton from the LCL IS NOT a fpGUI button (TfpgButton), but a class that (basically) WRAPS a TfpgButton (it's the same with the other widget sets btw.). This wrapping code is located inside the lcl/interfaces/<widgetset> directories. Only there is widgetset specific code used (e.g. only in lcl/interfaces/fpgui units from fpGUI are used). The other parts in lcl directory are widgetset independant.

Is it more clear now?

Regards,
Sven

This approach is only needed if you want to design pure fpGUI applications (and don't want to use the external designer provided by fpGUI). This is not needed when using fpGUI as a LCL widgetset.

Regards,
Sven

Sven Barth wrote

Is it more clear now?

Yep. Thanks a lot for your patience.

I'll do so tests as soon as I get Lazarus to create working empty GUI project....

-Michael

Sven Barth wrote

This approach is only needed if you want to design pure fpGUI applications (and don't want to use the external designer provided by fpGUI). This is not needed when using fpGUI as a LCL widgetset.

Right now (not having done any testing) I don't see for what a mixed fpGUI and - say- gtk would make sense.

-Michael

Op 2011-01-10 13:42, Michael Schnell het geskryf:

On 01/10/2011 12:30 PM, Graeme Geldenhuys wrote: > The fpGUI UI Designer generates source code. Why does fpGUI go the other way ?

The reason the fpGUI's UI Designer follows a different design is simple: I like having less files around. Object Pascal is not C, so why mimic the C header files idea. Also, I can quickly search & replace components or properties, because the whole UI is defined as normal source code. I can quickly modify a property value without having to switch to a form designer, I am guaranteed a specific creation order, less "behind-the-scenes" magic and much clearer change logs in the source code repository.

Now just to through a spanner in the works. ;-)
Just because the current fpGUI UI Designer generates source code to describe the UI, doesn't mean fpGUI can't use the [external or internal] resource method like Lazarus. Indeed it is possible to have say external *.frm files describing the UI (in the same object format as the *.lfm files of Lazarus), and you can even modify the *.frm files at runtime, that ship with your application so you can tweak the UI without recompiling your application. I believe some other widgets like GTK2 and Qt have the same ability, but they use XML files to describe the UI instead. I have already created a demo showing this ability, but need to neaten it up before I commit it to the public repository.

Regards,
- Graeme -

Interesting stuff, indeed,
-Michael

Such explicit source code is also easier to debug, in contrast to debugging the processing of the resource strings.

DoDi

You shouldn't mix IDE and Runtime here. Qt as well as some Java UI Designers (at least Matisse) use separate form files. Qt generates the C++ code out of those during the build process, Netbeans afaik updates the Java source while editing. But the designers in both cases rely on the external files to manage the forms.

I guess it wouldn't be too hard to write a similar preprocessor for Lazarus too, that converts the lfm into actual code, but there doesn't seem to be enough benefit.

Best Regards,
Andreas

What are you talking about? I think you still don't understand what the LCL is.
Imagine the LCL as a frontend. It has several backends it can choose from - but only one at a time. One of them is GTK, another is GTK2, yet another Win32 and in the future maybe fpGUI. That has nothing to do with mixing anything. fpGUI would operate on a whole other level than the LCL in that case.

I'd like to do a test on fpGUI but my state is this:

Interstingly, I only can run a new gtk2 project when I activate smart linking (I checked that with old projects that I seem to still be able to compile and run with the new svn versions of Lazarus and fpc, smart linking is not activated).

When I create a new "Application" and set the Widget Type to fpGUI I get

/tmp/project1.lpr(1,1) Fatal: Can't find unit Interfaces used by Project1

(while with gtk2 it can be compiled.)

What am I doing wrong ?
Thanks,
-Michael

You first need to build the lcl for fpgui before you can build a project that uses fpgui.

Henry

Henry Vermaak wrote

You first need to build the lcl for fpgui before you can build a project that uses fpgui.

I did not know that the LCL only supports one Widget Type at the time...

So I set the LCL widget type to FPGUI and did "LCL clean and build"

This results in:

"Clean Lazarus Source" completed
/home/mschnell/Downloads/svn/lazarus/trunk/lcl/xmlpropstorage.pas(25,20) Warning: Unit "XMLCfg" is deprecated
fpguiint.pp(42,12) Fatal: Can't find unit fpg_main used by fpguiint

Thanks a lot,
-Michael

Have you read lcl/interfaces/fpgui/README.txt?

Henry

Once you've built the lcl with fpgui interface, you can switch between gtk and fpgui (and whatever other interfaces you've already built) without rebuilding the lcl.

Henry

Michael Schnell wrote

I did not know that the LCL only supports one Widget Type at the time...

That's not true, it supports multiple widgets types at the same time, it just doesn't automatically build the LCL, you need to do this manually. And you need to have a build LCL for the target widgetset to use it in your project. All builds are stored in separate directories, so you can have any number of widgetsets built at the same time and further uses of the same widgetset wont require a LCL rebuild unless you change your LCL source code or your compiler.

Op 2011-01-11 13:38, Michael Schnell het geskryf:

What am I doing wrong ?

As Henry said, you need to compile LCL-fpGUI first, before you can build a LCL application that uses the fpGUI backend.

Menu:
Tools > Configure Build Lazarus

But before you can build LCL-fpGUI, you obviously need the fpGUI Toolkit source code as well. Read the following wiki page

http://wiki.freepascal.org/fpGUI_Interface

...or the readme file in

<lazarus>/lcl/interfaces/fpgui/readme.txt

The wiki page explains it all in detail.

NOTE:
Recently I introduce a new include file in fpGUI, and Lazarus's repository has not been updated accordingly. When you try and build LCL-fpGUI you will get a compiler error "can't find include file VERSION_FILE.inc". Go to the fpGUI 'src' directory and simply copy that file into the 'corelib' directory. LCL-fpGUI will then compile without problem.

Regards,
- Graeme -

But fpgui is not in the lazarus repository, so why isnt the file already in corelib?

Op 2011-01-11 14:05, Michael Schnell het geskryf:

So I set the LCL widget type to FPGUI and did "LCL clean and build"

You don't need to do a "LCL clean and build", simply select "LCL build", otherwise when you want to switch back to LCL-gtk, you need to rebuild LCL again.

The LCL output files are in separate directories of each backend, so you can have multiple LCL backends compiled and read to use.

Regards,
- Graeme -

Adding to this, the compiled units end up in
lcl/units/$cpu-$os/$widget_set/, so you can switch seamlessly from e.g. i386-win32 with the win32 widgetset to arm-linux with gtk2. You only need to build each combination once. Don't do a clean, though, otherwise you will have to rebuild them all!

Henry

Op 2011-01-11 14:18, Felipe Monteiro de Carvalho het geskryf:

But fpgui is not in the lazarus repository, so why isnt the file already in corelib?

I'll create a patch for Lazarus shortly. The VERSION_FILE.inc is located in the 'src' directory of fpGUI, and Lazarus IDE doesn't have an include path set for that.

I'll improve the Lazarus search paths for LCL-fpGUI so you would only need to create one symlink to fpGUI instead of the current two (corelib & gui).

Regards,
- Graeme -

Op 2011-01-11 14:18, Felipe Monteiro de Carvalho het geskryf:

> Recently I introduce a new include file in fpGUI, and Lazarus's > repository has not been updated accordingly.

By that I meant, Lazarus's search paths has been updated accordingly (via a patch).

Regards,
- Graeme -

Great. So I was not misled by the source code that does complex inheritance and registering of the GUI Objects.

-Michael

Henry Vermaak wrote

Don't do a clean, though, otherwise you will have to rebuild them all!

Thanks for that hint !

-Michael

Graeme Geldenhuys wrote

http://wiki.freepascal.org/fpGUI_Interface

"git clone git://fpgui.git.sourceforge.net/gitroot/fpgui/fpgui"

seemingly I can't access this git.

The git protocol is forbidden by the firewall, the server does not seem to support http:

Is it possible to access the files via svn (like the fpc and Lazarus sources) ?

-Michael

Op 2011-01-11 15:09, Michael Schnell het geskryf:

The git protocol is forbidden by the firewall, the server does not seem to support http:

That is strange. Most firewalls track the initial outgoing packets of traffic, and allow return packets back in without problems. Maybe not all firewalls are made equal. :-/

And no, SourceForge has very limited support for Git - rather annoying.

Is it possible to access the files via svn (like the fpc and Lazarus sources) ?

No, but I've done the next best thing. I'm really getting annoyed by SourceForge and there lack of cool git features (like what Github or Gitorious has).

Anyway, I created a new mirror repository of fpGUI Toolkit on Github. There you can use the git:// or https:// protocols to clone. You can even download the whole repository (or a Branch or a Tag) as a .zip or .tar.gz archive file.

eg:
Run the following command...

git clone https://github.com/graemeg/fpGUI.git

This will clone the repository into a 'fpGUI' directory, and check out a remote tracking branch called 'master'. Now you should be good to go.

To browse the repository online you can use the following URL in your web browser.

https://github.com/graemeg/fpGUI

Regards,
- Graeme -

I did encounter this problem with other gits as well. In fact AFAIK, it's a well known problem that the pure git protocol nearly always is blocked with company firewalls, while http (which git servers can be enable to support) does of course work. Another option is using the git protocol via ssl. I did enable this for a git server that I am, allowed to do uploads to. It does work, but setting it up is rather complex.

Great ! Thanks !

eg: Run the following command... git clone https://github.com/graemeg/fpGUI.git

Nice ! Works !

Now lets see what I can do with this.

Thanks again,
-Michael

Don't forget that a "firewall" is a concept, not a program or server. In the company I work for, they don't route any outgoing traffic at all. Everything that wants to get outside has to go through a HTTP proxy. That automatically gets rid of most custom protocols like git.

Michael Schnell wrote

Now lets see what I can do with this.

Works like charm !

Just changing the Project's Widget Type from gtk2 to fpGUI toggles the Widget set and both create working application with just a slightly different look.

Thus the Lazarus Form designer does work for fpGUI including visually creating TTimer instances.

GREAT !

So what do I need the external dedicated / additional fpGUI designer for ? Can it do additional tricks ?

Additional questions:

Can I hope for some thinks that are broken in the gtk2 Widget set to be working with fpGUI ? Such as
TThread.synchronize (that is said to drop events when system load is high), SendMessage -> Procedure ..Message (AFAIK, not working in the current svn version of gtk2)
TThread.Queue (not implemented yet :) )

Thanks,
-Michael

Hello Lazarus-List,

Wednesday, January 12, 2011, 12:18:41 PM, you wrote:

MS> Thus the Lazarus Form designer does work for fpGUI including visually MS> creating TTimer instances.

It works for LCLfpGUI, not for fpGUI ;)

MS> GREAT !
MS> So what do I need the external dedicated / additional fpGUI designer for MS> ? Can it do additional tricks ?

You need external designer to work with pure fpGUI.

MS> Additional questions:
MS> Can I hope for some thinks that are broken in the gtk2 Widget set to be MS> working with fpGUI ? Such as
MS> TThread.synchronize (that is said to drop events when system load is high), MS> SendMessage -> Procedure ..Message (AFAIK, not working in the current MS> svn version of gtk2)
MS> TThread.Queue (not implemented yet :) )

Maybe better make TImage, TBitmap and many other basic things work. In most cases LCLfpGUI will not deliver/handle some, how to call them... maybe advanced, messages like WM_ERASEBGRD because the widgetset does not have such concept, or at least I had not found it :-?

What you are using now is the fpgui lcl interface. This is why the lazarus form designer works. This interface is not complete, so less things will work than using the fpgui designer.

How does a widgetset make a difference to TThread.Synchronize? Is there a bug report for this?

SendMessage -> Procedure ..Message (AFAIK, not working in the current svn version of gtk2)

I believe postmessage works in gtk2 now.

Henry

Henry Vermaak wrote

What you are using now is the fpgui lcl interface. This is why the lazarus form designer works. This interface is not complete, so less things will work than using the fpgui designer.

I see. So I need to find the docs how to do a "pure" fpGUI project.

How does a widgetset make a difference to TThread.Synchronize?

(Unfortunately,) the Event ("Message") Queue code is done in the Widget Type source code, so it it does work, at all, fpGUI needs to feature it's own implementation of same. (The reason is that "system-type" messages like TTimer Events and Thread generated Events needs to be mixed in a main-thread event queue together with GUI generated messages).

Thus the fpGUI implementation might be better than the gtk2 implementation.

Is there a bug report for this?

I seem to remember that I found one in the bug tracker.

> SendMessage -> Procedure ..Message (AFAIK, not working in the current > svn version of gtk2) I believe postmessage works in gtk2 now.

That would be great news. I'll give it another try. (And of course I'll try it with fpGUI, once I was able top create a "pure" fpGUI application to be sure that I in fact use the fpGUI based code)

-Michael

Op 2011-01-12 12:59, Andreas Schneider het geskryf:

all. Everything that wants to get outside has to go through a HTTP proxy. That automatically gets rid of most custom protocols like git.

Ah yes, I forgot about the proxy access. That will indeed block all other protocols. In our company a select few (myself included) have internet access without the need of a proxy. It's the "Programmers Bill of Rights" - which I take very seriously. :)

If you are a programmer, then make sure your employer reads the following:

http://www.codinghorror.com/blog/2006/08/the-programmers-bill-of-rights.html

Regards,
- Graeme -

Op 2011-01-12 13:18, Michael Schnell het geskryf:

TThread.synchronize (that is said to drop events when system load is high),

I don't know the LCL internals, but I would expect that to be a FPC issue and not a GUI toolkit issue.

SendMessage -> Procedure ..Message (AFAIK, not working in the current svn version of gtk2)

Pure fpGUI does support sending messages - fpGUI standard ones, or application specific/custom ones.

TThread.Queue (not implemented yet :) )

again, that is a FPC issue.

Regards,
- Graeme -

Op 2011-01-12 14:15, Michael Schnell het geskryf:

I see. So I need to find the docs how to do a "pure" fpGUI project.

Take a look at any of the demos in the 'examples' directory. They are kept small and simple for a reason. You can also read Michael article/review regarding fpGUI at the following URL:

http://opensoft.homeip.net:8080/articles/

For anything else fpGUI related, please post questions to the fpGUI support newsgroup:

http://fpgui.sourceforge.net/#Newsgroups

There is also a web interface to those newsgroups:

http://opensoft.homeip.net:8080/webnews/

it's own implementation of same. (The reason is that "system-type" messages like TTimer Events and Thread generated Events needs to be mixed in a main-thread event queue together with GUI generated messages).

Again, I don't know the LCL or LCL-fpGUI internals, but I can't imagine that it would be difficult to add to LCL-fpGUI. After all, fpGUI already has a Object Pascal based event queue and allows PostMessage and SendMessage, and fpGUI widgets understand the object pascal construct of 'somemethod....message;'

Regards,
- Graeme -

Access to "Homeip" - of course - is disabled by out firewall (i.e. proxy) as it can be abused to work for home from the office :)

-Michael

Op 2011-01-12 14:57, Michael Schnell het geskryf:

Access to "Homeip" - of course - is disabled by out firewall (i.e. proxy) as it can be abused to work for home from the office :)

Don't you just hate proxies! :) I'll send you the article in private.

..... you have mail!

Regards,
- Graeme -

Graeme Geldenhuys wrote

After all, fpGUI already has a Object Pascal based event queue and allows PostMessage and SendMessage, and fpGUI widgets understand the object pascal construct of 'somemethod....message;'

That is the main reason why I am that interested in fpGUI. I suppose it is the less complex Widget Type that has this feature, and maybe we can extract the code, that is not requiring a GUI at all, into a common directory tree and construct a very simple "active noGUI" Widget set that also uses same, thus allowing for "headless" embedded applications that don't have a GUI but feature TTimer and decent "standard" inter Thread communication.

On top of this more advanced "remote GUI" applications can be planned such as "ifi" (according to Martin, using a remote control GUI program done with Lazarus, coupled via a byte stream), Android (using a remote control GUI program done in Java), Silverlight/Moonlight (using a remote control GUI program done in Java or in Prism), HTML (a restricted HTML based remote GUI), ... you name it.

-Michael

Henry Vermaak wrote

I believe postmessage works in gtk2 now.

I did a test and it does not seem o work for me, while Application.QueueAsyncCall(), that essentially is an enhancement of same, does work fine

-Michael

In fact with GTK2 neither PostMessages (queued) nor SendMessage(direct call) seems to work for me, while Application.QueueAsyncCall does work.

With (LCL-) fpGUI none of the three seems to work for me.

-Michael

Well, posting an LM_PAINT worked fine for me, but I use QueueAsyncCall myself. Also see here:

http://bugs.freepascal.org/view.php?id=13120

Henry

More funny stuff:

TThread.Synchronize seems to work fine with fpGUI, but with gtk2 I only see events when I (e.g.) move the move around on Form.

-Michael

Henry Vermaak wrote

http://bugs.freepascal.org/view.php?id=13120

Supposedly this introduces the problem with TThread.Synchronize.

Would it not be possible / more appropriate to implement PostMessage(), TThread.Synchronize, and TThread.Queue (which is not yet implemented at all, but provided by e.g. Delphi 2007), on top of TApplication. QueueAsyncCall ?

-Michael

Hello Lazarus-List,

Wednesday, January 12, 2011, 4:13:16 PM, you wrote:

MS> More funny stuff:
MS> TThread.Synchronize seems to work fine with fpGUI, but with gtk2 I only MS> see events when I (e.g.) move the move around on Form.

Check my comments in: http://bugs.freepascal.org/view.php?id=18191

Op 2011-01-12 17:13, Michael Schnell het geskryf:

TThread.Synchronize seems to work fine with fpGUI, but with gtk2 I only see events when I (e.g.) move the move around on Form.

@Michael van Canneyt
Now I don't feel so bad. ;-)

[Michael and Luk will understand this email]

Regards,
- Graeme -

Jos? Mejuto wrote

Check my comments in: http://bugs.freepascal.org/view.php?id=18191

I did see it. and I feel that it really is time to redesign the thread communication infrastructure (PostMessage, TThreadSynchronize, TThread.Queue) in a (more) Widgetset independent way on top of TApplication.QueueAsyncCall.

Am I correct assuming that any decent Widget Type code is supposed to nicely mix GUI events with the TApplication.QueueAsyncCall Events ?

-Michael

Graeme (or anybody): is it possible to build Lazarus+fpGUI completely from source, i.e. without having a working Lazarus as described at http://wiki.lazarus.freepascal.org/fpGUI_Interface

Yes, I thought this would cheer you up :-)

I suspect the GTK2 issue has to do with the changed glib main loop behaviour. It also messes up D-BUS stuff, but I'm still trying to debug that one; I need to recompile the LCL each time with a different define (USE_GTK_MAIN_OLD_ITERATION) to compare main loops :/

Seems like TThread.Synchronize should wake up the GTK main loop. The WakeMainThread handler is set for this to happen, but somehow nothing happens.

Michael.

I don't think so: LCL-fpGUI lacks way too much controls for the Lazarus IDE to be able to run.

Michael.

You won't be able to compile lazarus itself using fpgui, but you can certainly compile the lcl fpgui interface with make lcl LCL_PLATFORM=fpgui.

Henry

The following code in gtk2winapi.inc wakes up the main loop when a message is posted from a different thread (needs -dusecthreads):

   {$IFNDEF USE_GTK_MAIN_OLD_ITERATION}
   if GetCurrentThreadId  MainThreadID then
   begin
     // old glib versions needs another way to wake up.
     if (glib_major_version = 2) and
       (glib_minor_version < 24) and (FMainPoll  nil) then
       FMainPoll^.revents := 1;
     g_main_context_wakeup(g_main_context_default);
   end;
   {$ENDIF}

This seems to do the right thing for me when doing a postmessage from an external thread.

The main loop should be woken up like this after QueueAsyncCall, too, imo.

Henry

Seems like TThread.Synchronize should wake up the GTK main loop.

Hmm. So why does TApplication.QueueAsyncCallwork nicely ?

IMHO it should use the same interface to the underlying Event Queue implementation (and thus this code should be independent of the Widget Type).

-Michael

Yes. So you say on a regular basis.

But I must still see your first patch with even a start of an implementation.

Looks like I will be dead and burnt before that happens. (in which case I will care little one way or the other - luckily)

Michael.

I just tested again here, and using postmessage with gtk2 from an external thread (from a library) works perfectly.

Have you built your project with -dusecthreads?

Henry

Michael Van Canneyt wrote

Looks like I will be dead and burnt before that happens. (in which case I will care little one way or the other - luckily)

I did many days of research on that issue once when we (company) really intended to use FPC/Lazarus in an embedded design. Right now these efforts are on hold, as the "Delphi team" right now is not very interested in starting to port their stuff to Linux. So I just hope to be helpful with some testing and providing my research results when possibly appropriate,

From my researches I do know that the Widget set code is very complex and distributed in many places of the source tree, thus it's not a good Idea for a newcomer to try to restructure it.

OTOH, now that I finally have been able to get Lazarus up and running (nearly nicely) I might be able to take a deeper look in what is happening, but I will not dedicate much pointless research effort in order to create a patch that will anyway be rejected due to the political decision that we will not dare to do a change to all Widget sets and risk that something will be broken in one of them, even if it runs with some others. (Even though exactly this is the current state as we just saw.) And I am not able to do any tests with the Mac based implementations, anyway.

So maybe fpGUI could be a starting point for the move, as it seems to feature the fewest dependencies on external and legacy stuff. Moreover it's still bleeding edge anyway and Graeme seems to be interested in these issues, so my research results and suggestions might be not completely in vain,.

-Michael

Why don't we use g_main_context_wakeup(g_main_context_default) in the WakeMainThread handler?

Henry

Henry Vermaak wrote

I just tested again here, and using postmessage with gtk2 from an external thread (from a library) works perfectly.

As taken from some example code, I just created a user thread with TMyThread.create(). It does run and does

   while not Terminated do begin
      sleep(2000);
      PostMessage(Handle,  LM_MY_MESSAGE, 2, 0);
   end;

in TFom1 I have:

     procedure MyThreadMessage(var MyMessage: TMyMessage);
message(LM_MY_MESSAGE);

and

procedure TForm1.MyThreadMessage(var MyMessage: TMyMessage);
begin
   Memo1.Lines.Add('MyMessage' + InttoStr(MyI));
end;

MyThreadMessage is never called, even though the hread is verified to call PostMessage.

What am I doing wrong ?

Have you built your project with -dusecthreads?

Not really. As I did not find where to set this, I deleted the appropriate $ifdef in the project source code. Could this be a problem ? (How to define the -dusecthreads in the Lazarus IDE ?)

Thanks for your answers,
-Michael

Henry Vermaak wrote

Have you built your project with -dusecthreads?

I found ho to set this in the Lazarus IDE (and verified that this does work),

But no call to the message handler nonetheless.

-Michael

You have said this before.

But this does not alter the fact that you want to implement a message queue that does not depend on a GUI. From this it inevitably follows that you don't need to wait for Graeme, Lazarus, mseIDE or any other team.

Whether or not your queue will be used is not relevant to the matter: YOU would presumably use it, since you seem to have an interest ?

Once implemented, maybe we could be convinced that such an approach may bear fruits. An implementation works - or not, but at least we'll know then. As it is, it is just idle talk and opposing opinions.

You don't honestly expect sceptical people to invest time and work in such a scheme ? That's not how it works. People need a convincer. Repeatedly stating "this or that is better" gets you nowhere. An actual implementation, on the other hand, might.

Your refusal to come up an implementation that works is strange (to put it mildly) and certainly does not encourage anyone to believe or trust your opinion(s).

Michael.

Are you really posting the message to the _thread_ handle? You probably want to post it to e.g. Form1.Handle.

Henry

Hello Lazarus-List,

you wrote

> Graeme (or anybody): is it possible to build Lazarus+fpGUI completely from > source, i.e. without having a working Lazarus as described at > http://wiki.lazarus.freepascal.org/fpGUI_Interface

mvwb> I don't think so: LCL-fpGUI lacks way too much controls for the Lazarus IDE mvwb> to be able to run.

And only around 15-20% of non complete WinAPI (with workarounds to make it just work with controls).

Thanks Michael and Henry. I suspected that that would be the case but was slightly confused by my recollection (perhaps erroneous) that the widget set used by the IDE tracked the last one that was built. [Looks carefully at options] OK, I think I see how things work. I just thought I'd try in case it furnished a way of getting Lazarus working on Solaris.

Reverting to Linux and trying to build with fpGUI from inside the LCL, I get stuck at

fpguiint.pp(42,12) Fatal: Can't find unit fpg_main used by fpguiint

Symlinks (3x) appear OK- have I missed something obvious like a prebuild stage?

Michael, you know that I am also *very* interested (for non-GUI embedded stuff) in what you propose. I'm also involved a bit with fpGUI so if I can help you and Graeme I'd like to do what I can (especially if you need any minimal FPC & fpGUI distros to test/demonstration things :) ).

TApplication is not available in the RTL where TThread is implemented (not even TCustomApplication is, btw).

Regards,
Sven

Ok, I forgot about the WakeMainThread handler, but the statement is still true ^^

Regards,
Sven

Mark Morgan Lloyd wrote

Graeme (or anybody): is it possible to build Lazarus+fpGUI completely from source,

No, you can't build Lazarus IDE with LCL-fpGUI yet. As Michael said, there are still way to many unimplemented functions or components in LCL-fpGUI. Hence it is marked as 'alpha' in Lazarus.

Graeme.

So if I did that and also make lazbuild I might possibly get somewhere on Solaris 10 despite missing libraries which appear to preclude building the IDE.

I guess you'd be able to build a project that you've designed on another machine that lazarus actually runs on. Just using fpgui directly with the fpgui designer is better, surely?

Henry

Mark Morgan Lloyd wrote

So if I did that and also make lazbuild I might possibly get somewhere on Solaris 10 despite missing libraries which appear to preclude building the IDE.

On a side note:
I have never tested "pure" fpGUI on a Solaris system. If Solaris runs X11, it might just work. Platforms I have tested fpGUI on are: Linux, DesktopBSD, FreeBSD, Mac OS X, Windows, WinCE, and others have tested on ReactOS and Embedded Linux (Arm).

I'll see if I can get anywhere at all with it, but strictly in the context of the LCL- at as mentioned earlier I
seem to be having problems getting it going even on Linux/x86.

FPC runs pretty well on Solaris 10, it's got X with GTK2 but is missing things that we're used to on Linux like libcairo. I'm not going to get involved with grafting bits onto 10, I might investigate whatever version OpenSolaris is at but only when some of the Oracle dust has settled.

Well, it could have something to do with the fact that I've only been poking fpGUI for a couple of hours and so far it's not moving :-)

On a more serious note, in general I'd prefer to design with Lazarus even if initially I had to artificially constrain my choice of components, in anticipation of a wider range becoming available eventually.

Well, you're alone there again. Synchronize works perfectly for me on gtk2.

Henry

Funny thing: a few weeks ago I wrote some code that did database lookups etc. in a background thread, updating the (foreground) using TThread.Synchronize. Nothing happened until I added a timer to the form, updating a time display every second.

No idea. I just updated my Lazarus (trunk) and fpGUI (master) on my home laptop. I used FPC 2.4.3 (32-bit).

Here are the steps I took:

1) $ cd ~/programming/lazarus/lcl/interfaces/fpgui/
2) $ ln -s /home/graemeg/programming/fpgui/src/corelib/ corelib
3) $ ln -s /home/graemeg/programming/fpgui/src/gui/ gui
4) This is a temporary work-around until Lazarus is updated:

   $ cd /home/graemeg/programming/fpgui/src
   $ cp ./VERSION_FILE.inc corelib/

5) Run Lazarus, then "Tools > Configure build lazarus" In the "Parts" set all radio buttons under the "none" column.
6) Set LCL under the "build" column.
7) Select "fpgui" in the LCL Widget Type combobox.
8) Click the "Build" button.

Done!

I created a simple test project with some of the Standard components, selected fpGUI as the widget type and it compiled and run successfully.

NOTE:
There is no need to "pre-compile" the fpGUI source code. When compiling LCL-fpGUI, Lazarus finds and compiles the fpGUI code too.

Added your step (4) which isn't in the instructions I'd used.

Still doesn't work on a clean system (good FPC 2.4.2, good Lazarus 28907). Below is the last few lines of console output:

make[1]: Entering directory `/usr/local/share/lazarus-trunk/lcl/interfaces' /usr/bin/make -C fpgui all
make[2]: Entering directory
`/usr/local/share/lazarus-trunk/lcl/interfaces/fpgui' /bin/rm -f ../../units/i386-linux/fpgui/interfaces.ppu \ ../../units/i386-linux/fpgui/interfaces.o
/usr/local/bin/fpc -gl -dfpgui -Fu../../units/i386-linux -Fu. -Fucorelib -Fugui -Fucorelib/x11 -Fu/usr/local/lib/fpc/2.4.2/units/i386-linux/rtl -Ficorelib -Ficorelib/x11 -FE. -FU../../units/i386-linux/fpgui -di386 interfaces.pp
Free Pascal Compiler version 2.4.2 [2010/11/16] for i386 Copyright (c) 1993-2010 by Florian Klaempfl
Target OS: Linux for i386
Compiling interfaces.pp
Compiling fpguiint.pp
Fatal: Can't find unit fpg_main used by fpguiint
TExternalToolList.Run Exception:
/usr/local/share/lazarus-trunk/lcl/interfaces/fpgui/fpguiint.pp(1,1) Fatal: Can't find unit fpg_main used by fpguiint
TMainIDE.DoBuildLazarus: Building standard components (LCL, SynEdit, CodeTools) failed.

Alternatively make LCL_PLATFORM=fpgui lcl does appear to succeed, but trying to build a test project (button and label on form) fails.

Op 2011-01-13 10:44, Mark Morgan Lloyd het geskryf:

/usr/local/share/lazarus-trunk/lcl/interfaces/fpgui/fpguiint.pp(1,1) Fatal: Can't find unit fpg_main used by fpguiint TMainIDE.DoBuildLazarus: Building standard components (LCL, SynEdit, CodeTools) failed.

I have no clue what could be wrong with your setup. I just tried the same instructions I listed here on my work PC, and it too compiled LCL-fpGUI without troubles. I could also create a simple LCL-fpGUI test project.

At work I'm using latest Lazarus 0.9.30 (fixes branch) and FPC 2.4.3 on a 64-bit system.

Regards,
- Graeme -

YOU would presumably use it, since you seem to have an interest ?

Not really. I did have personal (company) interest for this when I started the research, right now I'm only trying to learn more about the topic and to help improving the (IMHO) obvious shortcoming of the (generally really amazing) project. I feel that right now the evolving fpGUI Widget Type might offer a platform for a n implementation in a less legacy-orientated way.

Thinking about your comments, yesterday in the evening I have been thinking about how I might be able to really provide a patch, to make me feel a little bit better. So I did plan to do a patch that provides TThread.Queue (as requested in a bugtracker article). This could easily be based on TApplication.QueueAsyncCall.

But even that small patch (some 10 lines) is impossible to do due to political reasons:
the TThread class is defined not in Lazarus but is part of the fpc distribution and humble me can't hope for a simultaneous change in both projects, and I can't be sure about the implications when using the changed TThread class in non-Lazarus projects.

Maybe we could do something like
TThread = class(classes.TThread);
but I don't know if this is not a depreciated style or even impossible.

Once implemented, maybe we could be convinced that such an approach may bear fruits.

Yep . This is why I do hope for Graeme to do an fpGUI Widget Type implementation according to theses lines (to which I maybe can offer some help) and this is why I feel like discussing this here.

Your refusal to come up an implementation that works is strange (to put it mildly)

Sorry that you think this, I tried to explain, why I think that it's just impossible for me to start this project on my own.

-Michael

Sven Barth wrote

TApplication is not available in the RTL where TThread is implemented (not even TCustomApplication is, btw).

I know (see my other mail). This is one of the "political" obstacles that prevent a smooth improvement of the said situation.

-Michael

Sounds great,
Let's see whether Graeme is inclined to do this move.

-Michael

Henry Vermaak wrote

Well, you're alone there again. Synchronize works perfectly for me on gtk2.

Funny. This problem is described in the bugtracker.

-Michael

OK, I'll delete it. Pity, it might have been one way to push things forward on Solaris but as it is I've got more than enough on my plate.

Op 2011-01-13 11:09, Michael Schnell het geskryf:

I'm not promising anything, since yesterday I was dumped with a whole bunch of code changes and new feature to our legacy products - what joy! :-(

Anyway, I have read bits and pieces of what you said regarding the non-gui event system and TThread changes. Would you mind creating a wiki pages on wiki.freepascal.org outlining your thoughts on the subject. I'm not about to waist 2-3 hours sifting through old emails looking for answers. Use the wiki page as a design proposal, and I'll take another look. The wiki site has been used numerous times before to summarize or outline some design proposal - so the FPC or Lazarus team should not mind this.

Regards,
- Graeme -

Henry Vermaak wrote

Are you really posting the message to the _thread_ handle? You probably want to post it to e.g. Form1.Handle.

Grrrr. Silly me :-[ .

This does work,

Thanks a lot !
-Michael

Sven Barth wrote

TApplication is not available in the RTL where TThread is implemented (not even TCustomApplication is, btw).

Maybe we could do something like
TThread = class(classes.TThread);
but I don't know if this is not a depreciated style or even impossible.

-Michael

I did this with symlinks yesterday and it did work without any problems.

Maybe an access rights issue ?

-Michael

Michael Schnell wrote

On 01/12/2011 10:00 PM, Henry Vermaak wrote: > Well, you're alone there again. Synchronize works perfectly for me on > gtk2. Funny. This problem is described in the bugtracker.

Can you give me the number so I can comment? I can't find anything relevant when I search for synchronize.

Henry

Graeme Geldenhuys wrote

non-gui event system and TThread changes. Would you mind creating a wiki pages on wiki.freepascal.org outlining your thoughts on the subject.

This is a great idea. Finally I can actually _do_ something :) .

Thanks for your interest,
-Michael

Henry Vermaak wrote

Can you give me the number so I can comment? I can't find anything relevant when I search for synchronize.

Sorry I can't find it right now, too, but I'm sure that I did see it yesterday :-( .#

-Michael

Not that I can find.

OK, let's try another tack: if I wanted to build fpgui for entirely standalone operation what should I do and what executable should I end up with (i.e. what's an adequate test that it's worked)?

Michael Schnell wrote

This does work,

In fact it seems to work with gkt2 but not with fpGUI :(. -Michael

Op 2011-01-13 13:06, Mark Morgan Lloyd het geskryf:

OK, let's try another tack: if I wanted to build fpgui for entirely standalone operation what should I do and what executable should I end up with (i.e. what's an adequate test that it's worked)?

There are a few options using "pure" fpGUI (no LCL-fpGUI involvement). Here I list two of them...

1) Build fpGUI from the command line. You might be able to use the script available in the <fpgui>/src/ directory. Then build the UI Designer or DocView projects. In each case you can use the following command line syntax

cd <fpgui>/uidesigner
fpc @extrafpc.cfg uidesigner.lpr

2) Build fpGUI using Lazarus IDE. Run Lazarus IDE, open the fpgui_toolkit.lpk package located in:

<fpgui>/src/corelib/x11/fpgui_toolkit.lpk

Then simply open the UI Designer or DocView projects and click compile.

There is also a INSTALL and README file in the <fpgui>/docs/ directory explaining it in more details and even instructions using FPC's Text IDE or MSEide.

Regards,
- Graeme -

Op 2011-01-13 13:13, Michael Schnell het geskryf:

On 01/13/2011 11:03 AM, Michael Schnell wrote: > > This does work, In fact it seems to work with gkt2 but not with fpGUI :(.

With pure fpGUI (not LCL-fpGUI) it works fine. I tried your PostMessage from thread example last night, and could successfully update the UI every two seconds with a thread, while the main application thread does other things like processing resizing, modal dialog management etc.

Regards,
- Graeme -

Graeme Geldenhuys wrote

With pure fpGUI (not LCL-fpGUI) it works fine. I tried your PostMessage from thread example last night, and could successfully update the UI every two seconds with a thread, while the main application thread does other things like processing resizing, modal dialog management etc.

OK. I in fact do use the LCL-fpGUI flavor (I did not yet try to do a "standalone" fpGUI application).

I thought for the issue in question the same code should be used, anyway. Am I wrong ?

-Michael

Hi,

as already mentioned there are recently a lot of "SPAM"-Accounts created to place their things in the WIKI or in the Forum.

How can I help to fight this?
Who can delete these user accounts?

Regards,

Sam

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110113/1c9e2058/attachment.html>

That works.

That works.

Building for LCL still doesn't work.

Op 2011-01-13 14:12, Mark Morgan Lloyd het geskryf:

Building for LCL still doesn't work.

Then it seems the issue must be in the Lazarus IDE, in the codetools search paths or something.

Mattias or Vincent, any of you have ideas?

Regards,
- Graeme -

It compiles here too, just as described in the wiki.

It is a very long mail thread. Maybe you can summarize the problem?

Mattias

I think it might be related to compiler path expansion. Above was on x86 Linux, Debian "Lenny" or "Squeeze".

If I try compiling on SPARC Solaris, again using your fpc @extrafpc.cfg uidesigner.lpr plus FPC's -vt option, then I again get

Fatal: Can't find unit fpg_main used by uidesigner Fatal: Compilation aborted

i.e. similar to what I see when trying to build LCL+fpGUI.

Mattias or Vincent, any of you have ideas?

If nobody has any blinding revelations at this point I'd really rather not push it. FPC appears to be working on Solaris 10 but Lazarus with the standard LCL won't due to missing libraries. I'll investigate a later Solaris presently but not immediately.

This is a compiler message. It has nothing to do with the codetools.

fpg_main is in lcl/interfaces/fpgui/corelib/.
Have you created the symlink?

Mattias

Op 2011-01-13 14:50, Mark Morgan Lloyd het geskryf:

path (-Fu parameter) by using the FPC macro $fpctarget. It will point to a directory inside <fpgui>/lib/xxx-yyy/ using a relative path.

I have the following directories in my '<fpgui>/lib' directory:

i386-linux
i386-win32
x86_64-linux

Obviously on a SPARC Solaris system the TargetCPU and TargetOS will have different values to those listed above. So make sure the appropriate directory exists inside the <fpgui>/lib directory. I think the <fpgui>/src/build.sh script should have created it for you, but then again, I have never tested it under Solaris.

ummm, then again, if the directory did not exist, then the initial compilation of the framework should have failed too... :-/

Regards,
- Graeme -

I'll start a new thread just in case the problem turns out to have an easy solution when stated in one place.

Graeme Geldenhuys wrote

Would you mind creating a wiki pages on wiki.freepascal.org ...

I already did some additions to existing pages in this wiki, but silly me does not find out hot to create a new page.

-Michael

Op 2011-01-13 16:24, Michael Schnell het geskryf:

I already did some additions to existing pages in this wiki, but silly me does not find out hot to create a new page.

Just type the name in the URL edit box of your browser. Try and load the page. The wiki will prompt you with 'page does not exist, do you want to create a new page'. Say yes and start editing.

Regards,
- Graeme -

Thanks a lot

I started here:

http://wiki.freepascal.org/Lazarus_improved_Event_Queue

-Michael

2011/1/13 Michael Schnell :

I added a warning to prevent false assumptions and some comment on the talk page.

Vincent

Vincent Snijders wrote

I added a warning to prevent false assumptions and some comment on the talk page.

Thanks !

I modified and enhanced the warning.

I do agree that the title is due to improvement.

I used the "Lazarus:" prefix to make known tat this is (right now) a Lazarus issue and not (primarily) a free pascal issue , even though this is the "free pascal wiki". Maybe this precaution is not really necessary.

My suggestion would be

"Proposal of a Widget Set independent Event Queue implementation"

or something like this.

But how to change the title of the page, given that there already are some links to same. ( Wiki - experts anywhere ? )

-Michael

Op 2011-01-14 15:47, Michael Schnell het geskryf:

But how to change the title of the page, given that there already are some links to same. ( Wiki - experts anywhere ? )

Go to the page, click Edit. Then or the right hand column there is a option Move. Click that and give it a new name.

Regards,
- Graeme -

Michael Schnell wrote

Proposal of a Widget Set independent Event Queue implementation

Graeme Geldenhuys wrote

Go to the page, click Edit. Then or the right hand column there is a option Move. Click that and give it a new name.

Thanks,
Done.
-Michael

Andreas Schneider wrote

I guess it wouldn't be too hard to write a similar preprocessor for Lazarus too, that converts the lfm into actual code, but there doesn't seem to be enough benefit.

Just like I don't see any benefit in using *.lfm files. Just let the visual forms designer generate the source code from the word go. It works well for me. ;)

Andreas Schneider wrote

I guess it wouldn't be too hard to write a similar preprocessor for Lazarus too, that converts the lfm into actual code, but there doesn't seem to be enough benefit.

Someone of the devs (either Martin or Matthias, I don't know which one) told some time ago that there is a primitive writer that writes code instead of an lfm. It's just that this writer does not yet support everything needed and also reading is not supported. For the interested: it's located in
$lazarusdir/examples/pascalstream/componentstreampas.pas

Regards,
Sven

I've found one of the mails where this is mentioned (for the record: the dev was Matthias):
http://lists.lazarus.freepascal.org/pipermail/lazarus/2010-September/055380.html

Regards,
Sven

"Mattias" in both mails without the "h" of course ^^

Regards,
Sven

I agree.
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...

Is it more easy code with .lfm files?

Marcos Douglas

But Graeme do that in fpGUI project. What about Graeme help Lazarus team about that? =)

Marcos Douglas

Because:
- A lfm parser can be easier to code/maintain than a pascal code parser.
- It is easier to deal with properties appearing and disappearing.
- It just works (tm) (there are other brands using this slogan with great success :)

Paulo Costa

Is it more easy code with .lfm files?

A form designer can read .lfm files easily, but can have problems to locate and decipher equivalent source code. What if a user modifies the generated code, so that the designer cannot determine its meaning any more?

How would you make a form-under-design reflect the current settings, without compilation of the source code?

DoDi

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. Graeme must write for every component dedicated IDE integration code AFAIK.
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.

Martin

Marcos Douglas wrote

But Graeme do that in fpGUI project. What about Graeme help Lazarus team about that? =)

My code is not based on the TWriter or TPersistent (streaming classes) and neither does it use the passrc FPC parser. I have implemented my own basic parser and code writer. This gives me the ability to support components or property types the fpGUI UI Designer doesn't know yet - without raising any errors.

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...

Maybe it has to do with coding styles. Borland would have had to force there coding style into non-Borland applications. Just a guess, though I don't think that would have been the end of the world.

Martin Schreiber wrote

The separation of code and user interface definitions has advantages.

Huh? The code describing the UI is just that UI code. My businsess objects and businesses rules are not located in Form units either. One of Borlands bad design ideas with RAD - as far as I'm concerned. Embedded business logic inside form units - something Delphi and Lazarus IDE's promote.

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.

I already support the "frame" idea without problems. I can even have multiple forms in a single unit - something neither Delphi, Lazarus or MSEide can do.

So there is [as usual] pros and cons for each design.

Same with fpGUI UI Designer's design. Also, if it was such a great idea to separate the UI code into another file, why is Borland the only company to do that. .NET, Qt GTK etc all use embedded source code describing the UI. :)

This is not inherent to using resources, that is simply a design decision. Keep it simple is a good thing.

What makes resources a good idea is
- Easy Visual Form Inheritance.
- Translation.
- Memory use.

When translating, you typically not only translate strings, but also shift controls (texts in dutch tend to be longer than their english equivalents). When using resources, this is done in 1 go, and you overload the original resource with the new one.

The code to construct the form is always in memory as soon as the binary is loaded. Resources are left on disk till you explicitly need them. They can even be in a DLL that is loaded on the go (as done for translations). You cannot do this with "code constructed" forms.
(maybe it could be done with packages).

All design decisions have their reasons.

Michael.

It is not correct that they are the only one. There are others:
* VB
* XUL
* Windows itself. (prior to .Net)

And maybe Borland is the only one to have done it right. They don't need to change, why would they ?
The system as it is works just fine.

Michael.

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

Paulo Costa wrote

Because: - A lfm parser can be easier to code/maintain than a pascal code parser.

I forgot to mention. The pascal code describing the UI is rather simple. You DON'T need a full object pascal parser. Hence the reason I rather use my own simple parser than something heavyweight like the passrc parser in FCL.

Hans-Peter Diettrich wrote

A form designer can read .lfm files easily, but can have problems to locate and decipher equivalent source code.

Not if you give the UI Designer a place in the code to start looking. This is exactly what I have done. I have comment markers/tokens and the UI Designer *only* works with code between the comment markers - it totally ignores everything else.

What if a user modifies the generated code, so that the designer cannot determine its meaning any more?

I think fpGUI's UI Designer is a lot more resilient to user errors that Delphi, Lazarus or MSEide. fpGUI's UI Designer has a "future / feature proof" built in. Whatever it doesn't understand gets added to the "Unknown settings" memo in the Object Inspector. The user can also place any code in there while designing a form. The UI Designer simply inserts that code after it created the component code.

Is this correct:
Every line your parser does not understand is put into the "unknown settings" and wrote back on write?

Mattias

Ehm... in Windows Presentation Foundation (WPF) for .NET you use XML files... and that is the current "standard" for Windows .NET applications.

Regards,
Sven

You can postedit resources in a binary, or overlay them with translated resource DLLs. You can't do so with generated code.

Also, Borland's Java product, JBuilder is very close to a Delphi that does that.

Problem is that the interaction between design and writing code in handlers gets lost, unless the system can also parse the code. And then it must be very hardened so that editing by users doesn't kill the parsing.

JBuilder failed that test. The designer constantly broke if you touched generated code, and if you didn't, the system was less flexible than Delphi.

If you can't edit it, and must maintain the designer data outside the main unit source, I fail to see the advantage of this approach.

Graeme Geldenhuys wrote

Same with fpGUI UI Designer's design. Also, if it was such a great idea to separate the UI code into another file, why is Borland the only company to do that. .NET, Qt GTK etc all use embedded source code describing the UI. :)

Android application UI is stored in XML files.

Best regards,
Paul Ishenin

Sven Barth wrote

Ehm... in Windows Presentation Foundation (WPF) for .NET you use XML files... and that is the current "standard" for Windows .NET applications.

Thanks for the update - I'll take your word for it. The last time I used .NET was when .NET 1.0 was released. At that time Visual Studio's UI designer generated C# code inside a InitializeComponents (or some name like that) method.

That was WinForms which is basically deprecated today. In contrary to the C WinAPI world the .NET GUI world changes very fast and very radically ^^

Here two Wikipedia articles about WPF and XAML (the XML variant used for the GUI elements):
http://en.wikipedia.org/wiki/Windows_Presentation_Foundation http://en.wikipedia.org/wiki/XAML

(I know all that, because at work we are currently switching slowly from Delphi to .NET :( )

Regards,
Sven

Marco van de Voort wrote

If you can't edit it, and must maintain the designer data outside the main unit source, I fail to see the advantage of this approach.

Sorry, I don't understand your statement or how it relates to what I wrote.

Maybe some code example will help reduce confusion with what fpGUI's UI Designer does.

Lets say the Form unit is called frm_main.pas, it will have a structure as follows:

----------------[ frm_main.pas ]------------------------
unit frm_main;
interface

uses
...

type
  TMainForm = class(TfpgForm)
  private
     MainForm}
    Button1: TfpgButton;
     MainForm}
  public
    procedure AfterCreate;
  end;
implementation
procedure TMainForm.AfterCreate;
begin
  {%region 'Auto-generated GUI code' -fold}
   MainForm}
  WindowTitle := 'My Test Form';
  SetPosition(10, 10, 400, 300);
  Button1 := TfpgButton.Create(self);
  with Button1 do
  begin
    Name := 'Button1';
    SetPosition(50, 50, 80, 24);
    Text := 'My Button';
    ImageName := 'stdimg.quit';
  end;
   MainForm}
  {%endregion}
end;
end.
--------------------------------------------------------

The fpGUI UI Designer *only* parses and edits the code between the comment markers. That's those comments that start with

Only property with non-default values have generated code. Any user-defined code from the "unknown lines" memo in the Object Inspector are added to that specific component's source code, just before the final 'end;' block of code.

AfterCreate is a virtual method that gets called in a base form class in the AfterConstructor method.

In the case of images, they are handled quite easily as well. fpGUI allows you to register images per project, but it also includes a set of default images as standard. Whenever you want to use or set a image, you simply reference it by its registered name (any text string). So if I wanted to add the standard 'quit' image to the Button1 above, I simple set the ImageName property to 'stdimg.quit'

For the above code you will also notice that fpGUI's UI Designer takes advantage of Lazarus's code folding via the region markers. So by default all the code managed by the UI Designer is folded (not visible by the developer, unless they expand it themselves). If you don't want the code folding, simply delete those lines, the UI Designer will not add them back in.

You will also notice that the UI components are placed inside the Private section of the Form class. You can move it to any other pricacy section if you please. I simply apply standard OOP practises here, just like what you would do in business objects... Only make visible what you really want visible. In the case of a Form, I would rather introduce some public property to extract whatever info it needs from the GUI components - instead of having the developer go Form.Button1.Tag.... Why? What happens if I remove that button, or rename that button? The developer would then have to fix there code. Using dedicated properties instead, reduces this problem.

Sven Barth wrote

That was WinForms which is basically deprecated today. In contrary to the C WinAPI world the .NET GUI world changes very fast and very radically ^^

Does Microsoft know this? :) Last time I heard Microsoft was saying that the whole OS was going to be written in .NET bla, bla, bla. Something like 10 years later, MS Office was still not written in .NET (no idea if it is today, I don't use Windows).

In the case of Microsoft, they should really practice what they preach. They promoted MFC so high, yet they never wrote any apps using it. What a lot of faith they have in there own products. Again, no idea if things have changed.

- A lfm parser can be easier to code/maintain than a pascal code parser.

Was I thought.

- It is easier to deal with properties appearing and disappearing.

What is that mean?

Marcos Douglas

Mattias Gaertner wrote

Is this correct: Every line your parser does not understand is put into the "unknown settings" and wrote back on write?

Yes, but that is done per component obviously. For example, say I wanted to set some property that was not visible in the Object Inspector, I could add it into the "unknown lines" memo, and it will be written to file in the same code block for that specific component. I mainly set event handlers using that memo. Then when I am back in the Lazarus editor, I use code completion to fill in the rest.

I also have a "Unknown Widget" [green square with a question mark in it] on the component palette (the last icon). So if I have some custom component that the UI Designer doesn't know about, I simply drop a Unknown Widget on a form, it prompts me for the class name and component name. Now I have a component on the form which I can size and position etc... To set any of its properties, I use the "Unknown lines" memo. I find this actually very handy.

fpGUI's UI Designer is meant as a "visual forms designer" - nothing more. It's not an IDE, so I don't want it to generate event handler code etc. Yet it must not crash on loading a form either, so it can handle unknown properties or components gracefully.

Like I mentioned before, fpGUI doesn't use the built-in streaming features of the RTL. fpGUI's property editors each know how to read or write it's data. fpGUI handles images differently, so there is no need for a Image1.Data property. In fpGUI you register images with framework, then simply reference those images by name. This also has the benefit that it reuses images (reducing the memory footprint).

fpGUI doesn't have such properties, so those would fall under the "unknown lines" memo and simply get ignored by the UI designer. Then when you compile your project, any forward declaration will have to be added in code.

But the users have know what they do, right?

How would you make a form-under-design reflect the current settings, without compilation of the source code?

Reading the source code instead of lfm... but if is more easily to read lfm, ok.

Marcos Douglas

This is very interesting...

Marcos Douglas

Marco van de Voort wrote

You can postedit resources in a binary, or overlay them with translated resource DLLs. You can't do so with generated code.

fpGUI can also load translations at runtime - we do that for all our products. Admittedly the UI Designer doesn't have support for this yet (it's on my todo list). What we have done in the mean time is introduce a base form class that has virtual methods like ApplyPreferences, ApplyTranslations etc..

Then in each form we override those methods. In the case of translations, we set the widgets captions or text using the resource string constant.

As for resizing and repositioning components due to various languages having longer or shorter text. I believe that is the job of the layout manager, not the form designer.

Graeme Geldenhuys wrote

Does Microsoft know this? :) Last time I heard Microsoft was saying that the whole OS was going to be written in .NET bla, bla, bla. Something like 10 years later, MS Office was still not written in .NET (no idea if it is today, I don't use Windows).

A bit like Wordstar (or was it Wordperfect?) was about to be rewritten in Java. Like so many of these industry initiatives: ultimately just vapourware.

Okay, that I didn't know... pros and cons for each design.

Marcos Douglas

Marcos Douglas wrote

- It is easier to deal with properties appearing and disappearing. What is that mean?

I think he means when the value gets set to the default values, it isn't needed to output that property code to the .lfm file. Well, I have that same ability in my ui designer. If a property is set to a default values, no object pascal code is generated for that property.

Anyway, how did we get to this LCL designer vs fpGUI designer topic. :)

Well... this discuss do part of subject this thread: "fpGUI", I think.. =)

Marcos Douglas

What about other custom data, that can not be represented as published property?

That is a big show stopper.
A pascal writer for lazarus forms must handle this automatically.

Mattias

I don't understand what you don't understand :-)

Anyway, one can indeed use pseudo directives for this. But the parser still needs to be hardened against accidental edits.

Moreover, I still fail to see the advantage at all.

You will also have to review that extra property and related code, so while .tag is not the nicest solution (and I rarely use it), the problem is IMHO exaggerated.

The whole point of the windows design is to not become hopelessly stuck if a formdesigner or programmer hasn't foreseen any possible problem in advance.

Layoutmanagers can suddenly react badly to new screen resolutions etc.

Lets say the Form unit is called frm_main.pas, it will have a structure as follows:

[...]
This code is not very compatible with the new AutoSize, and may cause other problems.

But this should not be a problem, as long as the code generator and LCL is provided and maintained by the same "authority".

AfterCreate is a virtual method that gets called in a base form class in the AfterConstructor method.

What about code in FormCreate?

A reasonable point! :-)

Nonetheless the visibility of the component properties cannot be reduced much. It must stay public, so that the properties are accessible in AfterCreate. The same with Frames...

DoDi

- It is easier to deal with properties appearing and disappearing. What is that mean?

Did you realize that some controls have a Caption, where others have Text? All foreign code will not compile any more, when a replaced component does no more publish the same properties as the old one. Even worse when it has the same properties, but with different meaning and effects...

DoDi

Same question: how does LCL streaming support this?

Circular references are something what never should be allowed, IMO. To me it suggests a bad design of AnchorDocking, and of AutoSize as well.

DoDi

You are aware that Graeme talks about fpGUI and not the LCL?

In fpGUI there is no "new AutoSize" and also there is no "FormCreate", because in fpGUI the convention is to create controls in "AfterCreate" which is a virtual method and not an event. Also fpGUI does not rely on component streaming and thus the visibility of component fields can be as low as private without problems.

Regards,
Sven

?

Mattias

Any dependency between components can create this problem. From the layout pov the above is not a circle, because one dependency is horizontally and one is vertically.
Forward references happen quite often in lfm files. For example the form's ActiveControl property references a control that is streamed after the properties.

How does TReader do it:
It keeps a list of open references and sets them as soon as the component is created.

One simple solution for the pascal writer could be: first create all components and then set the properties. But then the code is somewhat harder to read.

TReader can even load multiple root components with circle dependencies. The IDE supports this too, but I guess this is hardly used and only a minor limitation for the pascal writer.

Graeme, how have you solved the problem?

Mattias

TForm/TDatamodule dependencies are in this category, and not so uncommon.

Graeme, how have you solved the problem?

He has not.
I don't know of any inter-component property in fpGUI, except parent (which must be equal to Owner anyway).

Michael.

Normally only the form references the Datamodule, so you can simply create the module before the form.
I meant, that TReader and IDE even support bidirectional references. AFAIK not many programs use this.

Ah, well, that is a simple solution. ;)

Mattias

Marco van de Voort wrote

Anyway, one can indeed use pseudo directives for this. But the parser still needs to be hardened against accidental edits.

Why must I harden the UI Designer's parser. The UI Designer generates source code and reads ui source code - it's been good enough for the last 2-3 years. If there was accidental edits or invalid object pascal code, the FPC compiler will detect that. As I said, the UI setup code is rather basic - not nearly as complex as other business object rules etc. I've created quite complex UI's in our products over the last 2-3 years and the fpGUI UI Designer coped just fine with it.

Moreover, I still fail to see the your emails :) There are pros and cons for both options, I get

that. I simply find the pros more to my style of working.

* UI is in private section of a form class by default. A rather basic OOP principle - only make public what you need public.
* I can search and replace properties or components very easily. eg: Lazarus and MSEide default to searching *.pp and *.pas files - which is where my UI code lives.
* I can tweak a property value without having to switch to a UI Designer
* Lazarus IDE codefolds the AfterCreate method by default, so as not to obfuscate my hand-written code. Thanks to whoever implemented regions.
* I have less files to manage in a project or a VCS.
* Tracking the history in a VCS is much simple. Code and UI in one unit.
* All related code is in the related unit - not split over multiple files. This goes hand-in-hand with the previous point.
* I can use code templates to quickly generate parts of my UI that normally have a consistent layout. This is great for quick demos etc. It like having code templates in the visual designer (I think Delphi actually had such a feature)
* Multiple forms in a single unit.
* I'm able to use new or "unknown to the ui designer" components. No extra install required [which could lead to a bugy UI designer]. Seeing that I have created so many gui components already, this is very handy while developing those components.
* A guaranteed creation order of components

...for more see my previous messages, I can't remember everything now.

Hans-Peter Diettrich wrote

> AfterCreate is a virtual method that gets called in a base form class in > the AfterConstructor method. What about code in FormCreate?

Mixing where you create UI components is your problem. The UI Designer uses AfterCreate (though I should probably give this a better name some time). If you create components before of after that method - well see what as in LCL.

The fpGUI UI Designer on the other hand will only load and edit what is between the @VFD_ comment markers. And yes, you can move those comment markers to a form's constructor or OnShow event handler etc, and it will work as normal when you edit the form visually.

Nonetheless the visibility of the component properties cannot be reduced much. It must stay public, so that the properties are accessible in AfterCreate. The same with Frames...

Components are a different point - I was referring to Form class (eg: TMainForm) only.

Sven Barth wrote

which is a virtual method and not an event. Also fpGUI does not rely on component streaming and thus the visibility of component fields can be as low as private without problems.

I don't use streaming, but I do use the RTTI to set and get component property values in the UI Designer - so in the case of components, properties must still be Published.

Mattias Gaertner wrote

> [...] > This code is not very compatible with the new AutoSize, ?

I wanted to ask the same, but didn't want to sound stupid. ;) My knowledge of LCL is limited.

[...] * I can tweak a property value without having to switch to a UI Designer

OTOH: you have to write some code, instead of a few mouse clicks with wysiswyg.

* Lazarus IDE codefolds the AfterCreate method by default, so as not to obfuscate my hand-written code. Thanks to whoever implemented regions.

Mostly Martin.

[...] * Multiple forms in a single unit.

OTOH you have to select every time you open the designer which form to edit. And multiple forms in a unit leads faster to bigger (unreadable) units.

* I'm able to use new or "unknown to the ui designer" components. No extra install required [which could lead to a bugy UI designer]. Seeing that I have created so many gui components already, this is very handy while developing those components.

This has to take extra care for references, otherwise you will loose them without noticing.

* A guaranteed creation order of components

Means?

...for more see my previous messages, I can't remember everything now.

Mattias

Just replace the old code...

Marcos Douglas

That is very important and a good point.

Marcos Douglas

Mattias Gaertner wrote

What about other custom data, that can not be represented as published property?

Could you give an example of such custom data? I guess if I can't create some custom property editor for it, I'll simply load it after the last comment marker, but still in the AfterCreate method.

It's not impossible to add, but I think I should reiterate what the fpGUI UI Designer was designed to be... Simple. I did not want it to be a full blown IDE, so I didn't want it to generate code outside what relates to building the UI. When I started fpGUI, there was no ui designer, and I had to build a lot of forms by hand - totally non-visual. This made me realise quickly I needed something better, but still simple because I'm time constrained. For generating all the other fancy code - well, that is what CodeTools, Code Completion, Code Templates and whatever other fancy features Lazarus IDE has.

I would like to see some UI, if possible =)

Sounds very good for me. I always wanted widgets private, e.g.

Marcos Douglas

Mattias Gaertner wrote

> * I can tweak a property value without having to switch to a UI Designer OTOH: you have to write some code, instead of a few mouse clicks with wysiswyg.

I type fast. Use Dvorak. :) I said "tweak" for a reason. eg: simple little changes like changing an anchor or image name etc..

Not in fpGUI's UI Designer. There all forms are shown at the same time.

> * A guaranteed creation order of components Means?

I think Michael and yourself told me the streaming used in VCL and LCL cannot guarantee any creation order or the order in which properties are set. I can't remember the example we talk about, but it was important at the time.

For example TStrings.Data.

That's ok for your personal needs.
But when discussing pascal stream on this lazarus list, you have to come up with a solution for common needs. If you think that storing components as pascal has advantages help to solve the remaining problems of the pascal streamer and Lazarus will write pascal code.

One of the fancy features are component editors, allowing to do many things with a few mouse clicks. The result needs to be streamed to/from the pascal code.

Mattias

Maybe you misunderstood something.

There is no random element in TReader.

I remember some discussions where people got crashes in an event handler, because a component was not yet created. This is because some events in the LCL come earlier than in the VCL. If you create some components in those events, then of course creation order is not the same as well.

Mattias

Marcos Douglas wrote

I would like to see some UI, if possible =)

I'll take some screenshots tomorrow and email your in private.

Mattias Gaertner wrote

Maybe you misunderstood something. There is no random element in TReader.

OK, thanks for explaining.

Mattias Gaertner wrote

For example TStrings.Data.

I've never used that before... I'll read up on what that property does or mean.

That's ok for your personal needs. But when discussing pascal stream on this lazarus list, you have to come up with a solution for common needs.

Personal needs always come first - even in the Lazarus project. I was told that many times here. :)

One of the fancy features are component editors, allowing to do many things with a few mouse clicks.

Component editors or property editors? If the first, can you explain more. I just loaded Lazarus, started a LCL project and then started dropping component on the form. Which components have "component editor" support, and what fancy features? I searched the wiki and found the "Extending the IDE" page mentioning Component Editors, but doesn't give concrete examples of what they can do.

If you meant property editors well... those default editors for collection/item etc... They are quite horrible to use, even under Delphi. Just the other day I used tiOPF's MGM design time support that Michael introduced. It uses the default collection/item editors. It was awful and I couldn't localize the text properties of the items because they were stored only in the lfm files (nowhere in my *.pas unit). I went straight back to instantiating my mediators via code templates and resource strings.

But if you talk about more customized property editors, then yes many things could be done quick and easy with a few mouse clicks. Even fpGUI's ui designer has customized property editors for just that reason.

Mattias Gaertner wrote

Ah, well, that is a simple solution. ;)

I did say that fpGUI's UI Designer was simple. :) I will also say that the difference between Owner and Parent is highly overrated in VCL and LCL. Yes I fully understand the difference between them in the context of VCL and LCL. I just don't see a need for that in fpGUI, or even VCL/LCL. So fpGUI treats Owner = Parent. I would have loved to get rid of Owner, but unfortunately that is hardwired into TComponent (which is a base class I use in fpGUI). So when you create a component and set the Owner, fpGUI will automatically set the Parent for you, to match that Owner.

Marco van de Voort wrote

Layoutmanagers can suddenly react badly to new screen resolutions etc.

Not if you implement a descent layout manager. The one I'm working on is a port of the MiG Layout Manager for Java. It was designed from the start to be a all-purpose layout manager - meaning there is no need to embed for example a horizontal layout inside a vertical layout inside a grid layout etc.. MiG layout is intelligent enough to cope with complex UI's[1]. It was also designed from the start to work with different dpi resolutions and various units values for describing the UI (eg: pixels, mm, meters, cm, inches, etc).

For more on MiG Layout, download their demo. It is rather impressive to see, and quite easy to use. http://www.miglayout.com With such a layout manager you don't even need a visual forms designer.

BTW:
Even Lazarus's form designer chokes on differing dpi values. Nowhere does it store the DPI value the form was designed in, thus running such an app on a differing DPI value system, and you have a complete UI mess [last time I tested it]. At least Kylix 3 used to store the DPI setting inside the .xfm file, so this helped a bit. Why doesn't Lazarus do that?

[1] They actually ran a competition or something to see if there was a UI design MiG Layout couldn't handle. There was none.

Both.

Property editors are for rows in the object inspector. Component editors are for menu items in the designer. Some share code.

Yes, translating collection items needs improvement. There is already a bug report.
I didn't tried the tiOPF's MGM, so I can't say how to do it better.

But if you talk about more customized property editors, then yes many things could be done quick and easy with a few mouse clicks. Even fpGUI's ui designer has customized property editors for just that reason.

I will start another thread.

Mattias

The "simple solution" was about not supporting references between components. The Owner/Parent was just one example.

Mattias

You are aware that Graeme talks about fpGUI and not the LCL?

Yes, at least am I ;-)

In fpGUI there is no "new AutoSize" and also there is no "FormCreate", because in fpGUI the convention is to create controls in "AfterCreate" which is a virtual method and not an event.

So fpGUI has no Delphi compatible FormCreate handlers?

Also fpGUI does not rely on component streaming and thus the visibility of component fields can be as low as private without problems.

This is what FPC disallows. When the code in AfterCreate sets a property of a child control, then that property must be at least public.

DoDi

Provided that we want to use such a model in the LCL...

...I wonder how much of the AutoSize and AnchorDocking related properties must be implemented in a designer and the generated code, in order to make the forms behave reasonably realistic at both design and run time.

...When we now have CreateNew and DisableAutoSize everywhere, then the code generators/parsers of separate designers must be updated with every such change in the LCL.

...I just try to imagine how somebody sits and makes the IDE and designers work again, when some such change prevents the old forms from working properly ;-)

DoDi

Op 2011-01-17 04:50, Hans-Peter Diettrich het geskryf:

By FormCreate, I assume you mean TForm.OnCreate event and FormCreate (which can actually have any name) being the event handler for OnCreate? Is so, obviously yes, fpGUI does have the OnCreate event.

I think he worded it wrong. I assume he meant that "component fields" being the componens dropped on a designer form. Under Delphi and Lazarus those field variables must be located in the Published section of a Form. In fpGUI they are by default Private and in fact can be in any visibility section of a Form.

Regards,
- Graeme -

The creation is ordered by the z-order of widgets and the order of child components in the components list. There is a mechanism in streaming to restore the order after component loading (ffChildPos flag). The streaming order of properties is the order of the definition in source.

Graeme, - please, no offending meant -

fpGUI has implemented at the moment probably less than 50% of a good RAD development environment like Lazarus, Delphi or MSEide+MSEgui. You will encounter problems when you are finishing your product because the bigest difficulties are in the step from 90% to 100% and the current fpGUI architecture is too simple to allow to solve all the problems as far as I can see. When it is finished, fpGUI probably will be equally complex as its competitors.
I think potential users of fpGUI should know that. It will have a better endurance than Lazarus because there is no need to adapt to new versions of the used widgetsets, MSEgui has this advantage too.

The component streaming is one of the good things of VCL. It is difficult to handle in the IDE, maybe it could be done better if rewritten from scratch, but is usable. Outside of the IDE it works very well. There is a limitation in Delphi, it is not possible to add components to submodules. In MSEide I was able to overcome that limitation with some hacks.

fpGUI fits well your needs, as soon fpGUI will be used by more users in production there will be many, many wishes, nobody will understand and accept the limitations. I know what I write about, I encounter it daily. ;-)

Martin

Thanks for explaining my bad wording. :)

Regards,
Sven

Op 2011-01-17 09:33, Martin Schreiber het geskryf:

Graeme, - please, no offending meant -

None taken.

fpGUI has implemented at the moment probably less than 50% of a good RAD development environment like Lazarus, Delphi or MSEide+MSEgui.

RAD is overrated (marketing speak) and only good for prototyping. And no, the difference is that the fpGUI project is focused on the GUI toolkit itself, not on the whole development toolchain (ie: IDE etc...). When using fpGUI, you are free to use whatever development toolchain you prefer. The only requirement for using fpGUI thus far, is FPC itself.

As for the UI Designer - that was a quick fix for myself, because it's quicker to put together a form layout visually, than writing everything by hand. Once I completed the port of the MiG layout manager to fpGUI, a visual form designer will probably not even be needed any more (try the MiG Java demo to see why I say that) - bringing me back to focusing more on the GUI toolkit itself.

production there will be many, many wishes, nobody will understand and accept the limitations. I know what I write about, I encounter it daily. ;-)

I think we should rather say "different designs" than "limitations". If not, then any VCL or LCL developer will say MSEgui is very limited - simply because they are _not used to_ how MSEgui works, or lack of understanding your thinking behind its design. Hell, I couldn't even figure out how to use the StringGrid component in MSEgui - and I would like to think of myself as an experienced desktop application developer. That doesn't mean MSEgui is limited, just that I don't understand your design and thinking - thus MSEgui is not logical for me. [no offence meant, simply pointing out the different design ideas]

Regards,
- Graeme -

Marcos Douglas wrote

Is it more easy code with .lfm files?

I suppose when a huge lot of controls are to be created in a large application, storing streams of control codes and handling them by a single central interpreter would result in smaller files and memory footprint than controls each having its own creation code sequence.

-Michael

HTML :)

-Michael

Sven Barth wrote

switching slowly from Delphi to .NET :( )

Delphi and .NET is not a contradiction. .Net does not force and programming language. There are lots of .NET (and/or Mono, Silverlight, Moonlight, etc) enabled languages / IDEs.Delphi Prism being one of them.

-Michael

Let me rephrase that a bit:

switching slowly from Delphi to C#

Is now my ":(" reasonable? :D

Regards,
Sven

I beg to differ. When used properly, RAD is just that: RAD. But it takes someone who knows what he's doing to properly set it up.

Out of the box, Delphi (or lazarus) needs a lot of work if you want to use it for large applications. But with the right subclasses, properties, wizards and component editors, RAD is the best you can do to create applications quickly. Doubly so if your development team consists of people of various skill levels.

It takes good care of the boilerplate work for you, and leaves you to concentrate on the actual business logic.

Michael.

Graeme Geldenhuys wrote

The fpGUI UI Designer *only* parses and edits the code between the comment markers. That's those comments that start with

So it looks like a very small step on top ff this to (optionally) move the Delphi code interpreting these into the the runtime executable, too, and manage just theses lines in the designer files and for runtime compilation load them in a resource.

FWIW:

I shortly explained the "ifi" idea ( (c) Martin ) in another message. Here a "remote GUI" for an (locally headless) embedded would be provided by a Lazarus program (or - in an even more "far fetched" design a Silverlight/Moonlight application done in Delphi Prism) that allows for all necessary controls to be displayed. A stream of control codes is sent from the "embedded" application to the remote "head" for creating and managing the controls. This - at best - could be designed in sync with the control code stream used for form creation.

-Michael

Out of curiosity: what would Lazarus need according to you to be a good RAD IDE?

Regards,
Sven

constructor TForm1.Create(TheOwner: TComponent);
begin

  inherited Create(TheOwner);
  {%region 'Auto-generated GUI code' -fold}
  {%formdata automatically added by Lazarus}
  ...
  {%formdata}
  {%endregion}

end;

...I wonder how much of the AutoSize and AnchorDocking related properties must be implemented in a designer and the generated code, in order to make the forms behave reasonably realistic at both design and run time.

Nothing.

...When we now have CreateNew and DisableAutoSize everywhere, then the code generators/parsers of separate designers must be updated with every such change in the LCL.

The constructor is already enclosed in Disable/EnableAutoSizing.

...I just try to imagine how somebody sits and makes the IDE and designers work again, when some such change prevents the old forms from working properly ;-)

It will be optionally.

Mattias

Martin Schreiber wrote

the bigest difficulties are in the step from 90% to 100%

AKA version 0.9x to version 1.0 ;-)

-Michael

Sven Barth wrote

switching slowly from Delphi to C#

I already saw such projects fail ;-) .

-Michael

Graeme Geldenhuys wrote

Maybe some code example will help reduce confusion with what fpGUI's UI Designer does.

I found that fpGUI _can_ be used with the Lazarus GUI designer. How does this work related to your explanation here.

Seemingly fpGUI already does include the possibility to interpret resource based Form design control codes (I supposed this is "streamed components").

-Michael

You still/again confuse or mix up fpGUI and LCL-fpGUI. The last one is still 100% LCL, just using fpGUI for actual controls, just like it does for GTK, GTK2, QT, Win32, etc.
So in other words: fpGUI couldn't care less how the controls are streamed, managed, whatever.

True.
But so far no one has measured how much.

Mattias

Andreas Schneider wrote

You still/again confuse or mix up fpGUI and LCL-fpGUI.

I just try to learn more about the differences and this is why I) asked this question. As the same fpGUI name is used I suppose that at least _some_ code is shared.

The last one is still 100% LCL, just using fpGUI for actual controls, just like it does for GTK, GTK2, QT, Win32, etc.

I (think I) do understand this.

So in other words: fpGUI couldn't care less how the controls are streamed, managed, whatever.

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.

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.

-Michael

Michael Schnell wrote

On 01/17/2011 10:13 AM, Sven Barth wrote: > > switching slowly from Delphi to C# I already saw such projects fail ;-) .

Although I'm not that a big fan of the move, I won't be pessimistic about it. :P

Regards,
Sven

It takes good care of the boilerplate work for you, and leaves you to concentrate on the actual business logic.

Exactly. And for often used tasks there can be made components or component families which integrate into the existing framework, later this tasks are boilerplate work done by the framework for you too. :-)

Martin

Nothing. It has all it needs.
Maybe more controls in the style of TButtonPanel: specialized controls.

Each project/firm/team has its own design goals. Lazarus (or Delphi) cannot cater for all these goals. But they do allow you to extend the IDE so you can keep working in a RAD way and still follow your design goals with a minimum of effort.

I have an application with 1500 forms. It would be madness to have to set over and over again the same set of properties and event handlers to save/restore formlayout, ask to save unsaved data, sort grids and whatnot. So
- You create a descendent of TForm (or TCustomForm)
- You add all 'common' functionality to this descendant, plus lots of extra properties to control this functionality.
- You register this form in the IDE under File/New
- You do the same for common controls. Grids, date edits, whatnot. You register them on the component palette.
- Create a wizard that creates an initial layout for the form, based on the data you'll be editing in that form. (we use 3-tier data, but you can do exactly the same for a persistence framework)

After that, you create new forms extremely fast without losing RAD functionality: a pure point-and-click environment, which is always faster than coding, and which is understood by people of many skill levels.

Many forms in my applications don't have any form-specific code associated with them whatsoever: just the class declaration and form file. Yet they offer a lot of functionality out of the box.

Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone. Hence RAD and point-and-click.

Michael.

Graeme Geldenhuys wrote

Huh? The code describing the UI is just that UI code. My businsess objects and businesses rules are not located in Form units either. One of Borlands bad design ideas with RAD - as far as I'm concerned.

+1

There should be an automated way to create calls and properties in a Form unit to have external business units attach to it.

-Michael

[...] There is a limitation in Delphi, it is not possible to add components to submodules. In MSEide I was able to overcome that limitation with some hacks.

It also works in Lazarus, but is disabled, because of TWriter. Why does TWriter forbid it?

[...]

Mattias

Exactly, 100% agreed !
... And all this without compromising on the RAD aspect.

Michael.

Let me explain this a bit differently. When using fpGUI as a LCL widgetset the flow is like this:

1. LFM files contain streamed LCL controls (TButton, TLabel, etc)
2. LCL controls are created according to the LFM files and their properties are populated
3. those LCL controls now create fpGUI controls (TfpgButton, TfpgLabel, etc) and convert there own properties and assign them to the fpGUI controls in a way that the fpGUI controls behave as expected by the user of the LCL

When you use the designer of Lazarus you design LCL controls, not fpGUI controls. The fpGUI controls are created at runtime by the widgetset "glue" code.

Regards,
Sven

Check out the FormMediator in tiOPF.
Designed with RAD in mind.

Michael.

[...] I have an application with 1500 forms.

Every time you mention this application the number of forms grows by hundreds. I wonder, do you add one form per day?

Are these normal forms, each with a whole unit of code?

Mattias

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.

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.

Thank you for the extensive explanation.

Regards,
Sven

Graeme Geldenhuys wrote

Even Lazarus's form designer chokes on differing dpi values.

What is the dpi value useful for ? If you want to deal with screen dpi, you also need to know the physical monitor size and the eye-screen distance to do any useful calculations on it.

-Michael

It depends.
Adding a simple form costs at most 2 hours, so I alone could do 4 a day. Often this happens exactly so.

Depending on the form of course, there are also complex forms which take much more time, up to a week.

I ran a quick count:
The exact count of client-side forms is currently 1566. The server contains 450 datamodules, and over 2300 'exposed' queries. (there are 400 tables in the database).

A second application has 1359 client-side form files, and 216 server datamodules.

Both counts are without counting the 134 'framework' forms, common to all our applications.

Are these normal forms, each with a whole unit of code?

Yes. But as said, many simple forms need almost no code. All do need a single line to register them in the form factory.

Michael.

In fact I don't yet fully understand the two different incarnations of fpGUI. (Seeming one supported by the Lazarus GUI designer, one coming with it's own GUI designer) but I'm learning.

( In fact the LCL is lots of different things at the same time :). )

-Michael

Sven Barth wrote

Let me explain this a bit differently. When using fpGUI as a LCL widgetset the flow is like this: ...

Thanks. That exactly matches what I hoped I had learned in the last few days.
-Michael

Andreas Schneider wrote

Eventually the LCL only uses widgetsets as a means to an end.

Yep. The Lazarus GUI designer (based on the "set of GUI controls" (might be called Lazarus internal widget set) the LCL provides) only allows to design according to the material included in the LCL, that for portability is required to be compatible with all decent "Widget Types" implemented. An external GUI designer can do more, as it uses and know an external widget set it attaches or internally does all widgets at its own will.

So I myself am more interested in an fpGUI Widget Type that is as much compatible / portable regarding the other "decent" widget Type, but I do see that the other fpGUI incarnation might be very viable, as well.

-Michael

Op 2011-01-17 12:03, het geskryf:

I have an application with 1500 forms. It would be madness to have to set over and over again the same set of properties and event handlers to save/restore formlayout, ask to save unsaved data, sort grids and whatnot. So

[...snip...]

After that, you create new forms extremely fast without losing RAD functionality: a pure point-and-click environment, which is always faster than coding, and which is understood by people of many skill levels.

And our company does exactly that, but without the need of a specific IDE's RAD functionality. Every heard of code templates? ;-) I'm a self-confessed code templates junkie! There, I said it! :) I can slap together stax of usable forms or code, with functionality like mediators, auto save/restore form positioning, localization etc all enabled, simply by using a few of our designed code templates - and a lot faster than anybody can drop components on a form & double clicking to set event handlers etc.

Clearly each development team has their own way of working. There is no right or wrong. I'm simply stating that "RAD" can mean many things to many development teams. And the "RAD" Borland was marketing, by writing a crap load of business logic inside form units, is NOT the way our company works.

I learnt my lesson at a previous employer, after having to help maintain a *huge* Delphi "RAD based" project. See my favourite URL of that "brilliant Borland RAD idea" in action.

http://opensoft.homeip.net:8080/~graemeg/datamodule.png

Just looking at it, makes my eyes tear. :)

Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone.

Why error-prone? If you use well tested and developed code templates, you end up with having consistent looking and tested code. eg: Taking the tiOPF's MGM functionality as an example: We use StringGrid's a lot in our products, but all the developer needs to do is drop a grid on a form. No need for tweaking the grid's property settings etc. Then simply create an instance of our StringGrid mediator, and the grid is done. Instantly that grid gets all our preferred settings and event handlers setup, plus customized painting etc... all my hooking up one mediator to a stock standard grid component. Now if we wanted to update the look of all our grids in our project, we simply have to modify our base stringgrid mediator class, and recompile our project. Quick, easy and consistent!

Hence RAD and point-and-click.

Which could result in one form's Grid not quite behaving like the other form's grid in the same application - because the developer forgot to set all the right properties for the 100th time.

So RAD can have many meanings and implementations, depending on the team. The mouse-style developer is not the begin-all, end-all of software development.

Regards,
- Graeme -

Exactly not.

That's why I subclass and re-register each control on the component palette, and this subclass has set all relevant properties correct in advance. No need for code the grid, and it's correctly configured for 99,99% of all cases.

If, additionally, you set the 'Default' modifier for these properties to these values, nothing is stored in the .LFM/.DFM either, keeping size small.

RAD works, if done right.

Someone putting more than 50 datasets on a Datamodule is clearly doing something wrong and needs to rethink his design. Such a person will equally well manage to mess up things when creating code. (and is likely to create wrong code, to boot).

Any system can be abused. That says little about the system, but lots about the abuser.

Michael.

Hello Lazarus-List,

you wrote

> What are you talking about?

MS> In fact I don't yet fully understand the two different incarnations of MS> fpGUI. (Seeming one supported by the Lazarus GUI designer, one coming MS> with it's own GUI designer) but I'm learning.

There aren't two different ones, only one fpGUI. Lazarus LCL can use fpGUI as a backend. LCL does not known which engine draws controls, or how they are being painted, it only request some operations to be performed and the backend is performing them (fpGUI, Windows, GTK, ...). There is a widgetset glue code API that both, the backend and the LCL must conform as a common language.

When you are in a conversation with another people of other country you may need a translator, so in example, you speaking english wish to talk with smoebody that speak spanish so hire a translator which speaks both of them so:

You (english) - Translator (English/Spanish) - Other (Spanish)

Or in Lazarus fpGUI terms:

LCL (LCL) - LCLfpGUI (LCL/fpGUI) - fpGUI (fpGUI)

In Windows terms:

LCL (LCL) - LCLWin32 (LCL/Win32) - Win32 (Win32)

In Linux/GTK2 terms:

LCL (LCL) - LCLGTK (LCL/GTK2) - Linux (GTK2)

In Windows/GTK2 terms

LCL (LCL) - LCLGTK2 (LCL/GTK2) - Win32 (GTK2)

In MacOS terms:

LCL (LCL) - LCLCocoa (LCL/Cocoa) - MacOSX (Cocoa)

The man in the middle just translates the requested operations by the LCL to the desired widgetset.

You have some problems with this approach:
- You can not predict functionalities for ALL forms decendents;
- If you try predict all, you will have a BIG class (Custom Form);
- The Forms decendents not will use all features of the CustomForm;
- Imagine you have a CRUD Custom Form. You have buttons to insert, update, delete, save, cancel, whatever. You decide make a new Form (inherite of YourOwnCustomForm). Every thing works, but you need 2 news buttons... The buttons shoud be sincronized with the buttons state of CustomForm. But the method that make this is in CustomForm. What you do? The method is modified to 'virtual' and you add more code lines in NewForm to treat 2 new buttons... because the CustomForm not predict everything... Exists others examples: the Save method should do more things in
the NewForm, before save data... you have to create, in CustomForm, the BeforeSave method (as virtual and your implementation is nothing) just to have a entry point to descendent classes make your own configurations... at the end, you have a BIG CustomForm class, don't you?

Since it is simply OOP, You could do all of this in code, but code is slower to create and is more error-prone. Hence RAD and point-and-click.

Slower? Not realy. You take a time to developer all widgets in your company... so, the same time would be used to developer all code without widgets, as Graeme did, e.g.

Marcos Douglas

Op 2011-01-17 12:58, het geskryf:

RAD works, if done right.

Fair enough. That then tells me that 99% of the developers using Delphi (and probably Lazarus) are doing it wrong - your team being in that 1% exception. I'm basing this on my work experience in multiple companies over the years. It seems Borland's RAD marketing was so good, most developers are now mouse click junkies, and forget to think about design.

Someone putting more than 50 datasets on a Datamodule is clearly doing

As bad as that screenshot looks, and considering the size and complexity of that product, I was incredibly impressed at how stable it was. Needless to say, the company in question had some of the best QA I have seen.

Regards,
- Graeme -

The breaking difference is the object model, including memory management, that makes Delphi (or C++) different from .NET, Java etc.

Furthermore .NET (or Java...) come with their own widgetset (and RTL), which are incompatible with the VCL. Look how badly VCL.Net failed, after years of development - a .NET widgetset for Lazarus would fail for the same reasons.

BTW I gave up my second try with .NET, after I couldn't find an equivalent for ShowMessage after searching for several hours. This shows that a language (syntax) is the least important part of a development system.

DoDi

Op 2011-01-17 13:08, Jos? Mejuto het geskryf:

Excellent explanation, you should add this to the wiki. :)

And here are the various layers in a vertical form.

application code
----------------------
LCL
----------------------
LCL widget type
(LCL-GTK2, LCL-fpGUI)
---------------------- vs application code toolkit --------------------
(GTK2, Qt, Cocoa, fpGUI) fpGUI
---------------------- -------------------- Windowing system Windowing system ---------------------- -------------------- OS OS

Regards,
- Graeme -

I don't have to. But 80% of the functionality returns. This 80% is taken care of. The rest is business logic.

- If you try predict all, you will have a BIG class (Custom Form);

Not really.

Totally wrong approach.

You create a form Save() method, NOT virtual, and add a OnSave event. That is the RAD way. If you add hooks in the right places, there is no need for endless descendants. We have 2 forms:

TAppForm
TDBAppForm (DB-Aware)

That's it. 95% of all forms descend from TDBappform. The rest descends from TAppForm.

That depends on your definition of big.

The form class together with all it's 8 auxiliary classes takes 2300 lines. I don't think this is big.

And you make a common mistake: you try to do everything in OOP in the parent class.

I don't propose to do take the recurring tasks, and make sure we don't need to spend time on them, so we can focus on the tasks which are specific in each form. Furthermore, each of these tasks can be customized by some event handlers to take care of special situations.

Never. Not with 4000+ form files. I suggest you try it.

What is more, if now we need a new functionality in all our forms, I introduce it in the form class, and all our forms now automagically have this functionality. This has happened numerous times in our application.

If your application has only 20 forms, all this is not worth it.

But when I started, I knew that there would be lots of forms, and an application that would evolve over 10 years.
I did as I described here, and this has saved us huge amounts of time. The whole team and management here agree on that. (one of the few things management and developers agree on ;-) )

Michael.

Not only Borland. RAD was the word at the beginning of the 90-ies. VB, WinDev, Forte: you name it. All RAD.

RAD is generally very good for small apps, quickly thrown together. (less than 20 forms)

But before starting on a large project, think first. Don't start blindly using RAD.

I said it: Any technology can be abused. This does not mean the technology is bad.

> Someone putting more than 50 datasets on a Datamodule is clearly doing As bad as that screenshot looks, and considering the size and complexity of that product, I was incredibly impressed at how stable it was.

No doubt. One does not exclude the other.

Michael.

AFAIK and IIRC, there is means to get that information under Windows/Delphi, some WinAPI calls do it.

And this can matter because in the times of CRT monitors, you'd get situations like a 150dpi setting on the developers' machine and 72 dpi on customers' machine. (hint: I was once in a team writing an app for touchscreen POS terminals, with cheap LCD screens).

That information can be fetched from the monitor (provided it has EDID) by the system automatically.

It matters e.g. for a full-screen application that needs to have all its labels in the correct places when run on different screens, without recompiling. (not that I particularly love that kind of usage but I can understand where it's come from)

Lukasz

All that is included in the single dpi value.

But AFAIK (from Windows) the dpi factor only affects font sizes, while graphics still are bound to the physical screen resolution. That's why VS measures everything in "twips", not in pixels as Delphi does. On my CRT monitors I used this Windows model to shrink graphical items down to a minimum, by specifying a high screen resolution, and then adjusted the text size for readability, by increasing the dpi value above the 96 dpi standard. On nowadays digital monitors this is no more an option :-(

Other screen managers (Ubuntu...) may have a different idea of the use of the dpi value, of course. But all models should result in equivalent text/graphics proportions, when a document is output to an printer, with a much higher dpi resolution. This certainly is not the case with pixel-based coordinates and image sizes in forms, and may explain the text size jumps as recently reported by Linux users.

DoDi

The absolute amount can be reduced by subclassing or similar means (mediators?). As already mentioned, a consistent look across many forms requires identical settings of common properties, what discourages any repetition in either explicit code or streams.

DoDi

2011/1/17 :

I don't have to. But 80% of the functionality returns. This 80% is taken care of. The rest is business logic.

Business logic in the Form class?

Okay, the RAD way is create Save() method and OnSave event, to configurations of child Forms...
These are beautiful and organized names... but is the same what I said, no?

Never happen to you have a child form (inherited of TDBAppForm) but with special features such that it did not fit well with the routines of TDBAppForm? So what did you do? Maybe you skipped some TDBAppForm's methods having to implement them again, otherwise, only for this particular Form, no?

That depends on your definition of big. The form class together with all it's 8 auxiliary classes takes 2300 lines. I don't think this is big.

Well... 2300 is not so big.

And you make a common mistake: you try to do everything in OOP in the parent class.

Just when I use OOP.
I have Forms RAD and Forms OOP (but just in Delphi... in FPC, I'm a newbie for now).

I believe, sure. But my point is that can be done with code/classes without RAD approach too.

Marcos Douglas

Ehm... in Windows Presentation Foundation (WPF) for .NET you use XML files... and that is the current "standard" for Windows .NET applications.

Android uses xml, too.

R.

Michael Schnell wrote

In fact I don't yet fully understand the two different incarnations of fpGUI. (Seeming one supported by the Lazarus GUI designer, one coming with it's own GUI designer) but I'm learning.

IIUC, there is only one fpGUI... the LCL-fpGUI is only a wrapper to "convert" LCL "data" to fpGUI "data"...

i use the term "data" to cover all possibilities of components, controls, the settings for each and anything else that has to pass from LCL based to fpGUI based...

On Mon, 17 Jan 2011, Marcos Douglas wrote:
2011/1/17 :

> I don't have to. But 80% of the functionality returns. This 80% is taken care of. The rest is business logic. Business logic in the Form class?

We work 3 tier.
Most important business logic is on the application server. Clients contain mostly presentation logic.

No. The 'extra' functionality is just never used in such a case. (in 3000 forms, there are 2 such cases)

And remember: I do not try to foresee all possible situations.

I try to make sure that 99% of all cases are covered. The remaining 1%, the programmer is free to use his imagination.

I know that, I do not dispute this.

I just want to point out that RAD does not mean one has to make compromises. It is a good concept, which really allows to work fast.

Michael.

We work 3 tier. Most important business logic is on the application server. Clients contain mostly presentation logic.

What protocol they do use? JSON?

Ok. I agree.

I know that, I do not dispute this. I just want to point out that RAD does not mean one has to make compromises. It is a good concept, which really allows to work fast.

So, I think everything depends of the good programmers! =)

Marcos Douglas

Not only yours O.o

Regards,
Sven

For e.g. webapps it is IMHO perfectly fine.

Marco van de Voort wrote

> Although I'm not that a big fan of the move, I won't be pessimistic > about it. :P For e.g. webapps it is IMHO perfectly fine.

But Delphi Prism would be just as fine and still be preserve some Object Pascal competence.

-Michael

It's still important (as a company) to think about the future. Yes, it may be better/easier for your current employees who worked with Delphi to switch to Prism and have .NET with a slightly lesser learning curve. But what about new employees? What if you need external consultants etc.? It's a *lot* easier to find C# (Java, C++ ... even Python) developers than Delphi developers. Does that say anything about their quality? Ofcourse not, but for an HR department it's important to have a huge pool of candidates, otherwise their (often strict and nearly blind) processes fail.

Also: C# isn't that huge of a step from Delphi. You really can see that a former Borland designer was responsible for the initial language and IDE.

IMHO .NET is all about conforming to what clients/market/industry demands. And the bit resemblance that Prism offers is not worth explaining each time again to a client why you use it.

To make it worse, I'm actually a Prism licensee. Twice even (at work and my license at home)

Op 2011-01-19 13:47, Andreas Schneider het geskryf:

But what about new employees? What if you need external consultants etc.? It's a *lot* easier to find C# (Java, C++ ... even Python) developers than Delphi developers.

[off-topic to the thread, but relevant to your comment]

I used to think the same as you described. But a few months ago, we needed to outsource the beginning development work of a new product, and it had to be written in Object Pascal. I also thought we were going to strugle to find developers for Object Pascal.

I posted the ads in the FPC and Lazarus mailing lists. I got about 30 responces in 3 days, and about another 20 or so over another 7 day period. I could pick and choose who I wanted. There is NO shortage of Object Pascal developers as far as I'm concerned.

We are living in a "global environment", where you can outsource work to anywhere, or work remotely with no hassles. It's time HR starts thinking outside the box (or should I say outside the Office)!

Regards,
- Graeme -

But it isn't that easy if you don't want to outsource something, but need a new employee in the company...

Regards,
Sven

Op 2011-01-20 15:17, Sven Barth het geskryf:

But it isn't that easy if you don't want to outsource something, but need a new employee in the company...

I worked for a long time as a fulltime employee for a small company (<20 employees), yet I lived in a different country. I didn't see a problem with that, neither did the company. That same company had developers based in Canada, UK, South Africa and Thailand. The owner of that company thought it was GREAT, because that meant he had 24hrs a day, developers working on the projects. So turn-around time for anything was really quick! Client reports a bug at 15:00, company schedules the task for the employee where the sun is rising and by 08:00 the next morning, the client has the bug solved. :)

Regards,
- Graeme -

Sven Barth wrote

But it isn't that easy if you don't want to outsource something, but need a new employee in the company...

A good developer can learn the appropriate language. It should be easy for C and C++ developers to migrate to Object Pascal because the paradigm is similar, just Pascal is easier to read.

But if the company searches for "Delphi developers" then nearly no one will answer... sigh... (well... I'm still working on a Windows Mobile application using Lazarus at work, so it will take some time till I'm not getting money for developing Pascal anymore :P )

Regards,
Sven

Sven Barth wrote

But if the company searches for "Delphi developers" then nearly no one will answer... sigh... (well... I'm still working on a Windows Mobile application using Lazarus at work, so it will take some time till I'm not getting money for developing Pascal anymore :P )

They can hire someone who is good at C/C++ and then train the guy to use Object Pascal. When searching for a developer they should make it clear that they accept people with experience in C/C++ if they are willing to learn Object Pascal. In other words they should search for a "developer".

could, should, might...

The decision was done and part of our development team is happy about that move (myself not included). So this says it all...

Regards,
Sven

Sven Barth wrote

That was WinForms which is basically deprecated today. In contrary to the C WinAPI world the .NET GUI world changes very fast and very radically ^^

Huh? WPF has been advocated for ages (and is indeed Microsofts prefered technology), but afaik WinForms 2.0 is still the more used tech?

Prism is such a small market, and it would require much more than a little dialect similarity to go there.

Andreas Schneider wrote

But what about new employees? What if you need external consultants etc.? It's a *lot* easier to find C# (Java, C++ ... even Python) developers than Delphi developers.

We always target both C++ and Delphi devels. In our experience you can easier retrain a good C++ programmer than have a beginning programmer with delphi knowledge gain experience.

Of course this is not an official statement from Microsoft, but the article on WinForms on Wikipedia (
http://en.wikipedia.org/wiki/Windows_Presentation_Foundation ) writes this: Windows Forms has been in effect superseded by Windows Presentation Foundation

Regards,
Sven

[OS/2 experience rearing its ugly head]
i have to wonder if and how much of the above may be related to the original OS/2 Presentation Manager stuffings or if it is simply a name that is close to what was once shared by m$ and IBM ;)
[\OS/2 experience rearing its ugly head]

NOTE: i smile and wink all the time... emoticons or their lack in my messages are not to be used to convey any quantity of seriousness... almost everything i post is serious with some humor and joking also conveyed... i think ;)

I'd say that Microsoft has long forgotten its OS/2 past with IBM... after all they've removed the OS/2 subsystem from Windows after Windows 2000.

Regards,
Sven

That's because WPF is the base of Silverlight, which they wanted to push, also for applications.

As far as I know it only grabbed a small market share.

Just like .NET (and so Windows Forms) "superseded" Win32.

Meanwhile, Win32 is still around and functioning just fine. And as long as Microsoft supports Visual C++, win32 will be around.

It's mostly about marketing; very little about technology. Microsoft needs to make money, as any commercial enterprise.

Michael.