I am finding the NoGUI option useful in converting projects using TDataModules to Linux, but there is some talk about phasing it out.

Can anyone clarify the original purpose behind its existence and whether it is problem free so long as no forms or controls are activated within the App?

I am finding the NoGUI option useful in converting projects using TDataModules to Linux, but there is some talk about phasing it out.

There are no plans to phase it out.

Can anyone clarify the original purpose behind its existence and whether it is problem free so long as no forms or controls are activated within the App?

Its purpose is to create non gui tools from gui
applications.

Mattias

Can you expand on that ?

Because to me, that sentence sounds like someone scratching his nails over a blackboard... If an application is well-designed, the back-end has no GUI dependencies and can be re-used in any environment, GUI or not.

In the use case of the original code:
When using a TDatamodule, there is no GUI, hence there should be no need for the nogui module ?

Michael.

Op 2011-01-25 11:18, het geskryf:

Because to me, that sentence sounds like someone scratching his nails over a blackboard... If an application is well-designed, the back-end has no GUI dependencies and can be re-used in any environment, GUI or not.

I have to agree with Michael. I also can't understand the point of the 'nogui' widgetset. An application is or GUI or non-GUI (latter requiring no widgetset at all).

Regards,
- Graeme -

Graeme Geldenhuys wrote

I have to agree with Michael. I also can't understand the point of the 'nogui' widgetset. ?An application is or GUI or non-GUI (latter requiring no widgetset at all).

Does it need to have a point? Some people find it useful, so there is no harm in including it. It has zero effects on the code of people that don't use it.

It must somewhere have a point, because it certainly has lots of disadvantages:

a) It deceives people. You'll get run-time errors if at any point you try to do something GUI related such as showing a dialog or getting a font metric.

b) It encourages people to write bad code. Example: the well-known EpikTimer.

It is a perfect example of a badly written component. It includes Forms, Dialogs and whatnot in the uses clause, when there is absolutely no need for them. But by doing so, it creates a dependency on a GUI when there is no need for one.

c) It creates larger binaries.

d) The widget set - like any other - requires maintenance. If it isn't there, there is no work needed.

Plenty of reasons for not having it.

Michael.

Op 2011-01-25 11:36, Felipe Monteiro de Carvalho het geskryf:

Does it need to have a point? Some people find it useful, so there is no harm in including it.

Of course it needs to have a point, why else was it created. The more important question is rather: Useful for what?

Regards,
- Graeme -

Op 2011-01-25 11:45, het geskryf:

BTW:
I have already fixed that by submitting a patch some months ago. I split the package in two. One runtime package (totally non gui), and a design time package (which registers with the Lazarus IDE - thus gui dependant).

Regards,
- Graeme -

Yes, a well design is the preferred solution.
But redesigning an existing GUI app costs time. The nogui widgetset can be a step to that redesign.
For example:
Some users wanted to compile a lazarus project at command line (with packages, po files, lrs files, resource files, ...). The Lazarus Team took a week to create a basic tool from the IDE. A complete redesign would take much longer and there are other priorities. Since then we gradually redesign the code. Using hooks instead of directly calling LCL functions and splitting units. So eventually we well get a well design not needing the nogui widgetset for lazbuild anymore. But it has low priority, so the change is slow.

Without the nogui widgetset there would be no lazbuild, because the task would be so big, that no one would have started it.

In the use case of the original code: When using a TDatamodule, there is no GUI, hence there should be no need for the nogui module ?

The LCL provides some useful methods for non gui apps too. There are plans to split the LCL and IDEIntf into the gui and nongui parts.
But that does not make the nogui widgetset obsolete.

Mattias

The same could be said for the cocoa, android or fpgui widgetset. There are always users with wrong expectancies.

EpikTimer existed before the nogui widgetset.

c) It creates larger binaries.

Yes. There are better solutions, but they cost more time.

d) The widget set - like any other - requires maintenance. If it isn't there, there is no work needed.

The maintenance is far less than one promille.

Plenty of reasons for not having it.

Mattias

This is IMHO a fallacy.

As we say in dutch: Soft doctors make stinking wounds.

If you would have bitten the bullet from Day 1, you would not be in the situation where you are now. It will linger forever, exactly because it is no longer a priority. If there was no nogui, you would now have a good design. Yes, it would have been a painful 2 weeks or even a month. But the end result would be better.

You need Marco van de Voort on your team; He's a proponent of radical changes for the good. One day you would simply find yourself with a complete new API ;-)

This is definitely a good thing and a step in the right direction.

Michael.

Op 2011-01-25 11:58, Mattias Gaertner het geskryf:

Without the nogui widgetset there would be no lazbuild, because the task would be so big, that no one would have started it.

What does lazbuild do that it must require the 'nogui' widgetset? If a simple 'make' can compile the IDE, or 'fpc @extrafpc.cfg <project-unit>' can compile any of the fpGUI projects or 'fpmake' could be used to do exactly the same, then why require lazbuild (or at least it's gui dependency)?

What Michael and I are saying, the 'nogui' widgetset gives this false pretence to developers wanting to develop a real console application. Giving way to much leeway for errors.

The LCL provides some useful methods for non gui apps too. There are plans to split the LCL and IDEIntf into the gui and nongui parts.

I would suggest that...or move such code into the FCL or RTL, or simply take advantage of "Lazarus packages" feature and create a runtime only (non-gui) package that LCL.lpk (if something like that exists) depends on.

Regards,
- Graeme -

I don't think one case in 13 years proves that :-)

In most cases it was more replacing an evolutionary grown api to something with some design behind it.

I usually draw the line when people start to layer new APIs over broken code.

True.
I didn't need it and I hardly use lazbuild, so I would spend the 2 weeks (probably more) on other things. There would be no lazbuild.

It will linger forever, exactly because it is no longer a priority.

Then why there is progress? The progress is slow, but the task gets smaller, not bigger, even though the project is growing.

If there was no nogui, you would now have a good design.

The nogui widgetset came after lazbuild. The nogui widgetset simply avoids linking to a widgetset and reduces the binary size. Absent of the nogui widgetset does not prevent people from making a GUI app a command line tool. It does not make it easier and thus I doubt that it encourages users to do that.

Yes, it would have been a painful 2 weeks or even a month. But the end result would be better.

The end result would be that there would be no lazbuild. Better a soft doctor than no doctor.

You need Marco van de Voort on your team; He's a proponent of radical changes for the good. One day you would simply find yourself with a complete new API ;-)

;)

[...]

Mattias

For example: make can not find needed packages and find out if they needs compiling.

What Michael and I are saying, the 'nogui' widgetset gives this false pretence to developers wanting to develop a real console application. Giving way to much leeway for errors.

You can write console apps using the LCL even without the nogui widgetset.

That's the idea, yes.

Mattias

Better a soft doctor than no doctor.

Here I strongly disagree.
If you don't want to spend the time to do something right then don't do it. It makes the life of everybody much easier. All these anoying workarounds and bugs cost more time then they save (maybe not for the code writer but in sum of all people which are affected by it).

Better follow the slogan:
Small is beautiful!

J?rgen Hestermann wrote

> Better a soft doctor than no doctor. Here I strongly disagree.

-1 on the disagree

lazbuild is a very important tool. Plus for the user it's internal structure is completely irrelevant.

As the original poster I have to say it serves my immediate need, of being able to gradually separate out the non GUI parts of an app and run them standalone. The data modules need to send the output to the GUI and I am now making the linking of the data modules with GUI conditional with preprocessor directives.

I can't say I am familiar with the LCL structure, lazbuild etc, so I say let NoGUI remain to ease the reorganization of existing GUI apps.

My main concern now is how the GUI part of an app can expose an interface to data modules that do not require the data module to link with GUI libraries. The first thing that comes to mind is to use internet sockets for the interprocess communication, but it feels rather awkward as the presence of the necessary ports cannot be guaranteed on any system.

Is that where stuff like interfaces, COM, and CORBA etc come into play, or are there simpler alternatives?

Why do you think you need 2 processes and interprocess communication ?

Michael.

Felipe Monteiro de Carvalho wrote

lazbuild is a very important tool. Plus for the user it's internal structure is completely irrelevant.

That is a very good point, because for beginners and new people (Free) Pascal and Lazarus are very attractive, because the learning curve is not so high compared to other high level languages.

So, the more newbie friendly it gets, the better for the whole project, because of potentially young talents who might join us in the future.

Thorstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110126/3ba5b97f/attachment.html>

Op 2011-01-26 11:37, Thorstein Beyer het geskryf:

...because of potentially young talents who might join us in the future.

:-) Well... if they are "talented", then hopefully they knew from the start how to separate non-GUI code from GUI code in the first place, and not rely on some Lazarus specific features to help them out with a temporary fix.

Regards,
- Graeme -

Most new programmers introduction to programming don't involve concepts such as separating non GUI from GUI parts, a lot of tutorials don't focus on such 'industrial' 'engineering' issues.

The person wants to program and see the output immediately and the beginner tutorials simply focus on that.

Programming talent does not necessarily imply foreknowledge of programming organization.

Why do you think you need 2 processes and interprocess communication ?

A friend wants to do graphics (diagrams), using BGI, and wants to see the results while debugging. Some time ago I wrote for him an TCP/IP server in Delphi, that presents the diagrams. But it looked to complicated to him, with too many libraries involved. I had the problem that the TCP/IP libraries (Indy...) are either aimed at single transactions, or at least lack any examples for continued communication betweeen the server and a client.

I can imagine that more such client-server apps can make life easier, for specific use cases.

DoDi

Graeme Geldenhuys wrote

:-) Well... if they are "talented", then hopefully they knew from the start how to separate non-GUI code from GUI code in the first place

I strongly disagree with that, because many people might be seen as talented at some point in time, but they do not necessarily learn programming in school the main point here is that you are required to have experiences which lead to a general overview, so you can take that decision whether you strictly seperate the data display from the rest...

Thats why you give the least experienced user the best defaults, at least in my humble opinion.

Thorstein
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110126/78386c78/attachment.html>

Graeme Geldenhuys wrote

I also can't understand the point of the 'nogui' widgetset.

In fact its "Widget Type". (Not that I like this name, but somebody did name it so.)

An application is or GUI or non-GUI (latter requiring no widgetset at all).

Yep, but as the Timers, the Event Queue handling (and AFAIK the Exception handling) is implemented in the "Widget Type" code a noGUI Widget Type that provides such things does make sense (the current version of the noGUI Widget Type does not provide Timers and Event Queue).

-Michael

But is "RAD" not really encouraging to drop the separation ? (Not that I really think this is a good idea on the long run....)

-Michael

Frank Church wrote

My main concern now is how the GUI part of an app can expose an interface to data modules that do not require the data module to link with GUI libraries.

You should do the "Business Logic" as number of Classes. They provide properties and functions/procedures that the GUI part can access. some of the properties would be QbjectPascal "Events" (aka callbacks, usually named On.... so that the GUI part can be triggered by Business Logic messages.

If not required by the functionality (e.g. long winding calculations or waiting for external events), doing separate threads for the business logic should be avoided.

If Threads are necessary you need to communicate between the two parts accordingly using critical sections, Synchronized Events and (e.g.) Application.QueueAsyncCall.

-Michael

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

But is "RAD" not really encouraging to drop the separation ?

Indeed, that is my opinion also, and seems to be the case in 99% of the projects I have worked on in the past. But as Michael van Canneyt pointed out, RAD doesn't exclude good design [but it sure hides it pretty well].

Regards,
- Graeme -

?
?

Michael Schnell hat am 26. Januar 2011 um 13:06
geschrieben:

It depends on the context.
Nowadays on this list "widget set" means a lcl backend, which depending on context includes or excludes the widgetset depending LCL interface code. For the lazarus devels the "LCL interface" is the code between the widget set and the LCL platform independent code. For some users the "LCL interface" is the set of functions/declarations in the unit LCLIntf, LCLType, InterfaceBase. 10 years ago, the term "widget set" was not used and I simply used the pascal word "type" for the macro. I think for compatibility it should be kept. Of course a second macro can be added, for example 'LCLWidgetSet' or 'LCLPlatform'. ?
?

Exception handling is done by the RTL. The LCL "Application" sets a hook to show a dialog.
TTimers and event queue are implemented by the widget set. Feel free to implement it for the nogui widget set.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110126/059a7405/attachment.html>

Mattias Gaertner wrote

It depends on the context.

Obviously.

But as "Widget Set" (as in "external Widget Ste Library") and "Interface" (this even is a Keyword in fpc) have at least one meaning that can produce confusion, both expressions are not a good idea to be used to name the "Graphical and Event handling" API provided by the LCL.

Feel free to implement it for the nogui widget set.

In fact (as you might know), for testing, I already did this some time ago, but I don't want to offer this code to the Lazarus project, as I took large chunks of source code from MSEGUI (which provides exactly this functionality), and by that re-implementing multiple functionalities that already as implemented (several times) in other Widget sets.

-Michael

MSEGUI uses the same license as Lazarus:

http://svn.berlios.de/svnroot/repos/mseide-msegui/trunk/lib/common/COPYING.MSE

The spirit of free software expressed in this license is encouraging people to copy and reuse code between similar projects.

In fact I did ask Martin and he did agree that I am allowed to offer his code to Lazarus, but I really consider it bad design and difficult to maintain to have multiple completely unsynced implementations of the same functionality in the same source code tree.(We did discuss this already some years go.)

-Michael

?
?

Michael Schnell hat am 26. Januar 2011 um 15:40
geschrieben:

[...] both expressions are not a good idea>[...] I don't want to offer this code to the Lazarus project?

Thanks.

Mattias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110126/047b2a25/attachment.html>

Mattias Gaertner wrote

Thanks.

=-O

If anybody really wants to check this code, I'll try to dig it out of the archive and send it in a private mail.

-Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20110126/30fbb2a2/attachment-0001.html>

Actually it is the opposite of what you are thinking. It's not a matter of being allowed to share. This question is never present in GPL/LGPL, sharing is always allowed. Not sharing is what might be prohibited, depending on what use you make of this software.

Felipe Monteiro de Carvalho wrote

On Not sharing is what might be prohibited, depending on what use you make of this software.

Regarding GPL you need to provide the source code to everybody you give the executable code. As this was just a "proof of concept" test with rather limited functionality, the absolutely unusable executable just stayed on my disk (together with the source code, so even putting the disk in the dust bin would not violate the GPL)

-Michael

On 26 January 2011 15:23, Felipe Monteiro de Carvalho <

I think what Michael is saying is he doesn't want to make a gift of something which will lead you down a path of twisty turning winding passages all of which will lead you to nowhere quickly.

It is the kind of code you don't want to attempt to unravel - better to start of with a clean slate.

The default already is a usual widgetset (win32, gtk or carbon, depending on the underlying OS). To use anything else, you have to know at least how to compile it which in turn requires some understanding of the LCL - otherwise you run into some problems as seen lately on this mailing list.

In other words: I don't see your problem/point. NoGUI is currently an *option* for people who know what they are doing. Everyone else has to learn anyway.

After having sparked a much longer thread than I expected, I need to get back to my problem, although it may belong in a different thread.

Now in most case data modules expose interfaces that the GUI parts of the app call to get data.

My problem now is the other way round, where the Data Module needs to connect with the GUI first, in that whether or not the GUI is running, the Data Module can make a call and send the data to it if it exists, but without having to compile in any GUI dependencies.

In effect I need the GUI to register something the Data Module or console app can use to notify the GUI in some way because I need to move to a model in which the GUI and Data Module/Console Program are running as separate apps.

Is there some Lazarus way of accomplishing this?

in this case, i would consider a pipe (named or otherwise)... create the pipe when the GUI unit starts up ... the data unit looks for the pipe... if it does not exist, it does not attempt to communicate with the GUI part... when the pipe comes into existence, then the data unit can start sending its data into the pipe...

seems workable ;)

Pipes are a new area for me, are there any Lazarus demos of their usage?

uncle google found this while searching for lazarus fpc "named pipe"

http://lazarusroad.blogspot.com/2006/12/only-one-instance.html

there are others that show up as well...

Wouldn't a clean "nogui" implementation allow to use this message loop stuff for other widgetsets as well? Instead of refactoring the other (in use) widgetsets first, start with a nearly unused widgetset and then refactor the other ones if that one works.

Regards,
Sven

Many Widget Types provide "Event Queue" implementations to provide inter-Thread-Notification like Application."TThread.Synchronize", "QueueAsyncCall" (plus the "Windowish" Message stuff), merging theses Main-Thread-Events with the GUI events generated internally by the Widget Type code.

Of course with Windows this needs to be done on top of the Windows Message API, but with other OSes a queue needs to be implemented in code.

I feel that additionally to the currently non-Alpha Widget Types (Windows, gtk2, qt, cocoa) several more Widget Types are useful and supposedly will be improved and/or created ("active NoGUI" being one of them, "fpGUI" is already on the run). And most will need an Event Queue (-Class) with a very similar functionality and implementation (using an OS or Widget set API and (if necessary) merging the events with the GUI events)

Thus, IMHO, a Widget Type independent central implementation of this class (servicing Application."TThread.Synchronize", "QueueAsyncCall", and the "Windowish" Message stuff <plus TThread.Queue, which we know from Delphi ) would make more sense than doing yet another implementation.

(Once this is done, the existing non-alpha Widget Type can be updated to use it - if somebody cares, which should be quite easy if the new centralized stuff is done by reusing the existing code from - say - gtk.)

-Michael

Frank Church wrote

Pipes are a new area for me, are there any Lazarus demos of their usage?

Pipes in Linux are very easy. You just write to a file in one program and read from it in another. If you create a pipe in the file system with that name before, the programs are connected.

If the pipe contains less bytes than the program tries to read, the read access blocks.

If you don't want that the complete program blocks, you need to do the reading in a thread. Here noGUI might be problematic as the usual Lazarus inter-Thread communication (e.g. TThread.Synchronize and TApplication.QueuAsyncCall) is not provided with this WEidget Set. (AFAIK, there even is no free running main thread, noGUI just starts, does it's thing and terminates. So you would need to implement your own Event mechanism directly using OS API calls. (That is why an "active" noGUI Widget type would be really nice.)

-Michael

I think this is a windows artefact, where Delphi "abuses" that widgetset and e.g. service api use the same message system, and thus compatible messageloops.

On a non Windows system, the implementation of nogui depends on what you want to use in whatever you build on top of it, since there is no one universal api. E.g. DBus vs trying to emulate Windows messages with pthreads. The same for ORB, XPCOM and al other message passing variants.

Marco van de Voort wrote

I think this is a windows artefact, where Delphi "abuses" that widgetset...

In fact IMHO it is a Lazarus artifact calling implementing some functionality that not necessarily needs a GUI (or widgets) in a source code section that is referred to as "Widget Type" (and sometimes "Widget Set" or "interface").

-Michael

^^

it is a Lazarus artifact calling implementing some functionality that not necessarily needs a GUI (or widgets) in a source code section that is referred to as "Widget Type" (and sometimes "Widget Set" or "interface").

All code in the LCL is written for graphical applications. The fact that something can be used for non gui applications is nice, but not the goal of the LCL. Non visual components can be part of the FCL.

Mattias

I agree that this might be a nice design rule, but unfortunately the FCL does not provide a message queue and thus a "TApplication" implementation, TTimer, Thread Synchronization and such things that (other than possibly their implementations) are not depending on a GUI but necessary for decent (headless, embedded) applications.

-Michael

I never said anything otherwise. However the failure is the assumption that such functionality would use the same functionality as the widgetset API.

This happens to be the case on Windows (where both plug into Windows message system, and thus have the same message loop), but not on other systems.

Marco van de Voort wrote

This happens to be the case on Windows (where both plug into Windows message system, and thus have the same message loop), but not on other systems.

I never said anything otherwise. But this does not require that there could be a central unit and class that provides an API for this: a common function (that could be just Application.QueueAsyncCall) used by Application.QueueAsyncCall, TThread.Synchronize, TThread.Queue, and PostMessage, that handles the the communication with the GUI implementation (id present). Thus, In Windows - other than in Linux - , this Class would not implement it's own Event queue, but just use use the Windows Message queue.

-Michael