There has been a modification in the "Options for Project" dialog with the latest svn version..

I think it was a good idea to move the Widget Type selection from the "Compiler Options" to the "Build Modes" page.

OTOH, the blue text "Select another LCL Widget Set (macro LCL Widget Type)" on the "Compiler Options" page looks a little bit weired and the Term "Widget Set" IMHO is misleading, maybe the newly introduced term "Platform" would be more appropriate..

It looks like if no "LCLWidgetType" macro is selected, the default is used. To allow for not setting a "LCLWidgetType" macro at all might or might not be a good idea.

Why is there setting " fpGUI" for the "LCLWidgetType" macro and additionally a macro "fpGUIPlatform" that can be set ?

I think the term "Platform" is was really good idea here !

If the plan is to split the selection between "WidgetType" for GUI related stuff and "Platform" for not GUI related stuff, this of course is exactly what I would like to see.

As fpGUI does not use an external Widget Set but locally implements the controls' look and feel, I think it is good that the name "WidgetType" stayed (to make a difference between an external "Widget Set" such as gtk)

I see that fpGUIPlatform selects the graphical API fpGUI uses. OK.

A similar "platform" setting might be usable to select (e.g.) the APIs the event queue is supposed to use (and thus how it is implemented). Here "Linux" and "Windows" might be future choices (if it is planned to implement the event queue based on the Windows Message Queue when using fpGUI on Windows).

This in place, other widget Types could make use of "platform" settings as well. E.g, the NoGUI Widget set could allow for "noEventQuueue", "Linux", "Windows", ...

Generally I feel that it is a good idea to allow for configurable Widget Types instead of doing a lot additional ones.

Thanks for your work,
-Michael

The word platform is already used at many places in the documentation for TargetOS+TargetCPU. So IMO the "LCL platform" is more like the triple OS+CPU+WS. OTOH the makefiles use the macro LCL_PLATFORM.

It looks like if no "LCLWidgetType" macro is selected, the default is used.

Correct.

To allow for not setting a "LCLWidgetType" macro at all might or might not be a good idea.

?

Why is there setting " fpGUI" for the "LCLWidgetType" macro and additionally a macro "fpGUIPlatform" that can be set ?

See my other mail about the LCL package.

[...]

Mattias

Mattias Gaertner wrote

The word platform is already used at many places in the documentation for TargetOS+TargetCPU. So IMO the "LCL platform" is more like the triple OS+CPU+WS. OTOH the makefiles use the macro LCL_PLATFORM.

I still would like to see a more strict way to separately select the GUI (Widget) and the non-GUI functionality, so that it is possible to do a GUI-free, but event-queue enabled application (e.g. on Linux and on OSX). I don't know if providing "Widget Type" selections for future things like remote GUI (e.g. ExtJS, Silverlight or "ifi" based.) is the best way do go.

> To allow for not setting a "LCLWidgetType" macro at all might or > might not be a good idea. ?

Not making clear that in fact a macro (here hidden) is used. So doing a dropdown selection control (that maybe also provides '-' for command-line applications) and pre-select the appropriate default, seems less confusing to me.

-Michael

GUI-free is not the goal of the LCL.
The nogui widgetset was added, because its maintenance cost is near zero, it is optional and some users think it is useful.

but event-queue enabled application (e.g. on Linux and on OSX). I don't know if providing "Widget Type" selections for future things like remote GUI (e.g. ExtJS, Silverlight or "ifi" based.) is the best way do go.

I kindly ask you to put the main contribution for non gui code to the FCL and keep additions to the nogui widgetset at a minimum.

I will add an empty value.

Mattias

Mattias Gaertner wrote

GUI-free is not the goal of the LCL.

Meaning that embedded applications is not the goal of Lazarus.

This would be a very sad decision, regarding that Lazarus (other than Delphi) is able to create application for small embedded devices e .g. based on Linux and ARM.

I kindly ask you to put the main contribution for non gui code to the FCL and keep additions to the nogui widgetset at a minimum.

I (partly) disagree, as currently several event queue implementations are provided in the LCL. Of course it would be best to move those parts of them that can be based on the same code, out of the LCL and into the FCP. but as discussed already several times I don't have any hope that this can be done (due to political reasons).

The second best ways to go would be to enhance the existing Widget Types (e.g. noGUI) or provide new ones.

I will add an empty value.

Great.

And auto select the default ..... :)

-Michael

This is non-logic. LCL Lazarus and embedded doesn't necessarily mean gui-free.

This would be a very sad decision, regarding that Lazarus (other than Delphi) is able to create application for small embedded devices e .g. based on Linux and ARM.

And how is that going to change?

Henry

On 01/27/2011 04:38 PM, Mattias Gaertner wrote: > > GUI-free is not the goal of the LCL. Meaning that embedded applications is not the goal of Lazarus.

GUI free embedded applications are not the goal of the LCL - the Lazarus component library.
Of course it is goal of the Lazarus IDE to help creating embedded applications written with FPC.

IMHO this and many other threads about this topic gave another conclusion: Those who needs it don't want to do it.

The second best ways to go would be to enhance the existing Widget Types (e.g. noGUI) or provide new ones. > I will add an empty value. Great.

On a second thought:
If a macro is defined, then the IDE should use it. The list contains the valid values.
I will add a note that to use the default you should delete the macro from the list.

And auto select the default ..... :)

Mattias

Michael Schnell wrote

Meaning that embedded applications is not the goal of Lazarus.

Isn't the WinCE widgetset targetting an embedded platform?

That's not how things work. You don't write something only if it gets included into library X.

Just implement your idea, you can open a free repository for it in source forge and put the code there, or put in the lazarus-ccr.

If it is good enough, it might be included in the FCL and then after some years Lazarus might use it.

On 01/27/2011 04:38 PM, Mattias Gaertner wrote: > > GUI-free is not the goal of the LCL. Meaning that embedded applications is not the goal of Lazarus.

Not a primary goal. IMO embedded systems and platform independent applications are somewhat contrary, resource wise.

DoDi

Henry Vermaak wrote

embedded doesn't necessarily mean gui-free.

You are (increasingly) right, As memory and CPU resources get cheaper, including a GUI in embedded projects gets more common. (In fact this is why I gave up active development for the "active noGUI" Widget Type I had been planning and already did a test-implementation of.)

OTOH regarding the discussed issue, gui-free just means "without a local, directly linked GUI". There are projects that ask attaching for non-local GUI, using some dedicated interface to attach the GUI e.g. (1) CGI with HTML, ExtJS or Silverlight, or (2) a daemon that can be monitored by a configuration program, (3) an Android app that is attached to a fully integrated Android-style GUI done in Java.

This is all about separating the GUI and the "business" logic - as recently discussed here.

-Michael

IMHO, It's not a good idea to prevent "Delphi-style" event driven programming, using TTimers and "normal" Event-based Worker-Thread to Main-Thread-signaling for embedded project.

IMHO this and many other threads about this topic gave another conclusion: Those who needs it don't want to do it.

Maybe "they" (like me) currently don't need it, but just found a class of applications (see the other mail) that ask for it and that they and others might want to do at a later point in time, so that it might be useful to offer some help if anybody feels like doing the plunge.

-Michael

Hans-Peter Diettrich wrote

Not a primary goal. IMO embedded systems and platform independent applications are somewhat contrary, resource wise.

Quite obviously, Linux is getting stronger in the embedded world. This is possible because of to cheaper memory and CPU resources and driven by the great success of Linux with mobile devices. So using Lazarus for mobile and industrial embedded projects is not a bad idea. OTOH the cheaper memory and CPU resources often allow for implementing a local GUI even if same is useless for the productive use of the software.

-Michael

Agreed, and I'm wary about having a UI- in particular a GUI- on something that should run silently and reliably: far better to have two programs. However with Linux it's possible to boot a system with the dummy X driver, and it's also possible to run GUI apps in a VNC session which in my experience is reliable.

I wonder whether I could ask a silly question: is there any feasible way that an app using the LCL can "re-skin" itself, i.e. switch to a different widget set such as nogui, without restarting?

Mark Morgan Lloyd wrote

Agreed, and I'm wary about having a UI- in particular a GUI- on something that should run silently and reliably: far better to have two programs.

IMHO, the optimum design is to adhere to the "separation of business logic and GUI" paradigm (that in fact is not even created with embedded applications in mind) and do the program in a way that it has a switch to compile it with and without the GUI. So at best the version without the GUI should use an infrastructure ("Interfaced" / "Wideget Set" / "Platform") that does not force a GUI binding.

However with Linux it's possible to boot a system with the dummy X driver, and it's also possible to run GUI apps in a VNC session which in my experience is reliable.

This is exactly what I have been planing regarding the bad luck regarding any kind of active NoGUI Widget Set.

I wonder whether I could ask a silly question: is there any feasible way that an app using the LCL can "re-skin" itself, i.e. switch to a different widget set such as nogui, without restarting?

I don't think so, and I don't see the point. For me the question is whether an application can start without an interface to a GUI infrastructure (such as "X") is found in the system.

-Michael

It was a general question prompted by discussion elsewhere. Basically, could a computer switch its role from being attached to a large desktop monitor to using an internal PDA-type screen, with running apps tracking the change and adjusting their UI appropriately.