Hi Experts,

I'd like to create an opens source Lazarus package "NoGUIApplication", that allows for creating a Linux "Application" that allows for event driven programming but avoids any binding to the GUI. Same can be used in GUI-Less embedded systems.

If that works, I'd like to add a Lazarus package "IFI" that allows for creating a "remote GUI" or such applications.

As discussed in the "fpc-devel" mailing list, I already have a running implementation of "NoGUIApplication, that I did by porting the code from MSEIDE (which provides "NoGUIApplication" as a standard choice when creating a new project).

Now I am not happy with introducing this huge amount of code into Lazarus (i.e. a Lazarus "package") and rather use what the Lazarus and FPC distributions offer.

So I took a look what we have in the RTL and the LCL. I did some steps to do do a "TNoGUIApplication = class(TCustomApplication)", but looking into the "Forms" code (that implements the LCL "Application = class(TCustomApplication)", I saw that the connection to the underlying Graphics system is not direct, but done by kind of dynamically linking to a "Widget Type", and looking in the project options, I see that the Widget Type can be selected independently of the source code and creation method of the Application. Here even we already have a selectable widget type "NoGUI (Pre-Alpha)". Obviously somebody already once started such a project.

Now I need to find out how the Widget Type selected in project options is linked to the code that implements the "controls" and how I can debug/edit the source code for the "NoGUI" Widget Type.

Thanks for any pointers.
-Michael

I found that I can link to the Widget Type I want to use by including the appropriate directory ("$(LazarusDir/interfaces/nogui") in the include path.

With that I was able to create an "Application" without doing "new->Application" but by "new->program".

So I suppose I can copy "interfaces/nogui" somewhere, set the files as managed by the project, and should be able to debug.

Right now my project stops with an exception as a handle (supposedly for Form1) is Zero. Can the be because I did not yet include any "lrs" resources ?

-Michael

The strange thing is, that every time I read your mails in the last weeks about nogui and lazarus, I thought you meant the nogui widgetset.

The "pre-alpha" is misleading.
The nogui widgetset is for applications, that uses the LCL, but doesn't use the widgetset functions. The nogui widgetset simply makes the compiler happy.
It does what it should, so you can say it is "beta". So far we didn't receive much bug reports, so maybe it is "stable".

Now I need to find out how the Widget Type selected in project options is linked to the code that implements the "controls" and how I can debug/edit the source code for the "NoGUI" Widget Type. Thanks for any pointers.

Just choose the nogui widgetset and press F9. Of course you can not create any TWinControl.

Mattias

I found that I can link to the Widget Type I want to use by including the appropriate directory ("$(LazarusDir/interfaces/nogui") in the include path.

include path???

With that I was able to create an "Application" without doing "new->Application" but by "new->program".

Means: no LCL.

So I suppose I can copy "interfaces/nogui" somewhere, set the files as managed by the project, and should be able to debug.

Yes, but not recommended.

Right now my project stops with an exception as a handle (supposedly for Form1) is Zero. Can the be because I did not yet include any "lrs" resources ?

nogui = no widgets = no handles. You can not create forms.

Mattias

There is also no event loop. So I don't think you want to use it.

Vincent

Yep. But by adding some include paths and ,making up the "project source file"appropriately I can create an "application" from scratch, (just to learn how this works and to allow for debugging the LCL components I want to modify)

How else debug a certain LCL component ?

nogui = no widgets = no handles. You can not create forms.

Right now with the pre-alpha nogui Widget Type that is true. This is exactly what I want to change. I'd like to create a "remote GUI". I am sure that this is possible, but right now I am investigating if that is possible by leaving forms (and thus Application) in place and only do a new "Widget Type" (finally renaming NoGUI to IFI or whatever). (My first - and working - try was doing an independent implementation of "Application", but I feel this is much less elegant.)

Thanks,
-Michael

Vincent Snijders wrote

There is also no event loop. So I don't think you want to use it.

Of course I do know that I need to enhance the nogui widget type greatly to allow for this. If somebody feels that the current nogui widget set is useful at all, I will call the new one differently.

As said I already do have a working implementation of a NoGUIApplication with a decent event loop implementation, but I feel that leaving Forms (and thus Application) in place and just doing a new Widget Type is a lot more elegant.

Thanks (I suppose I'll need more help on that later), -Michael

Mattias Gaertner wrote

It does what it should, so you can say it is "beta".

So I'll choose a different name...

-Michael

The strange thing is, that every time I read your mails in the last weeks about nogui and lazarus, I thought you meant the nogui widgetset.

AFAIR the wish was an application with message processing, but without a GUI. Is this feasable at all, on a non-Windows OS?

DoDi

Absolutely !

"Message processing" is just one kind of "event processing". Besides "GUI-events", such events can be "fired" e.g. by Timers, serial or TCP/IP drivers, other hardware drivers, Event handlers (to asynchronously start another event-handler), (worker-) threads within the same application (including TThread.Synchronize), other processes/programs, ...

You can use Lazarus/FPC to do software for embedded gadgets that don't have any graphical hardware and thus provide no support for GUI building in the installed System-software (Linux, but no X-Support, no Gnome, QT, KDE, GTK ... ).

In my special case I want to move a big program done in Delphi and now running on a PC to run on an embedded controller with Linux.

The beauty of Delphi-type programming is the "Event-oriented" paradigm: the user software is done as a number of "proglets" (Event handlers) that are started "on" Events. In fact the user does nothing but Event handlers and does not (need to) touch the "main program". The complete program never stops. If such a proglet is done, it just waits for the next event. To stop the program, a special call ("close") needs to be done within an event.

If you do a GUI base program, this is a perfect paradigm, and with Delphi and Lazarus GUI programs always should (and only can) be done in that way. Thus "Event-Programming" is necessary for GUI Applications.

But from a logical point of View a GUI is not at all necessary for doing an Application in an Event-oriented way. Viable examples are embedded applications (communicating via serial and TCP/IP connections, multithreaded if appropriate) and "persistent" CGI applications using AJAX / Comet.

To allow for Event-oriented programming, the RTL needs to implement an "event queue", that stores the events and schedules them one after the other. In the "common" runtime library code, same can (and IMHO should) be completely independent of the GUI support (see below). I would call a program, that has an event queue, an "Application". Thus a program that does not have a GUI but has an Event queue, is a NoGUIApplication. The "Application" code in the program's run time library needs to implement the event queue for the "main thread".

IMHO, its not a good idea that the LCL implements the "Application" code in "Forms", as Forms contains all the basic code to implement a GUI, as well.

This of course is a suboptimal heritage from Delphi. Delphi only creates applications for Windows, and here any version of same support as well the GUI as the event queue as OS service. The event queue is provided by the Windows message system, Linux on the contrary only provides GUI support if additional stuff is installed (e.g. GTK), and it does not provide a predefined event queue mechanism, so that the event queue best is implemented in the run time library using Pascal code, just needing OS-Support for waiting on events (e.g. using semaphores).

Now the LCL does define the "Application" stuff in "Forms", but much of the functionality (including the event queue) seems to be done in "plugins" called "Widget Type". This allows for providing the basic support independent of the operating system and graphical system to be used (we already have nine selectable "Widget Types": "GTK", "GTK2", "Win32/64", "wince", "carbon", "QT", "fp-gui", "nogui" and "cocoa").

All but "NoGUI" implement a graphical User Interface. I found that the "NoGUI" not only does not implement a GUI but also does not implement an Event queue.
I found that "Win32/64" implements the event queue using the Windows message system (working like Delphi).
I found that GTK2 implements the event queue in Pascal code. I did not yet take a look at the other Widget Types.

During my research I took a deeper look at MSEIDE/MSEGUI. Here the thing I want to use, already is provided in a perfect implementation: "TNoGUIApplication" that has no code whatsoever for implementing a GUI, but complete support for the event queue. So I ported this code to Lazarus and in fact now I have a perfectly working NoGUIApplication.

This is nice, as any code only necessary for GUI is avoided, but a lot of code needs to be introduced for functions that already are available in the LCL (or the FPC RTL) but just not decently selectable for me right now.

As long as "Application" is defined in the "Forms" unit and there only is a common plugin interface to do the message queue and the GUI, a more decent LCL-Type implementation of an event-enabled NoGUIApplication should be done as a "Widget Type". I think I'd rather live with that overhead instead of using/publishing a completely "outlandish" implementation of NoGUIApplication.

That is why I am now going to try to do a new "LinuxNoGUI" Widget Type for event enabled Linux Applications.

Question: (how) is it possible to add a new "Widget Type" to Lazarus using a Lazarus packet ?

-Michael

P.S.: another suboptimal heritage from Delphi is that only a single Event queue (for the main thread: Application) can be instantiated, while all other threads in the program can't benefit from event oriented programming. If the event queue code is done appropriately a TEventThread (or TThreadApplication ?) could be provided, that just creates another instance of the event queue to schedule events using the appropriate thread context. Besides simplifying the usage of threads for Delphi-trained programmers, this can be a viable way to have a program benefit from multi-processor machines. Here, the Pascal-code doing the event queue would be usable in a Windows application as well.

wasn't this one of the features and capabilities of Borland's TurboVision stuff? looking at my TP/BP6 stuff, i see TVISION/APP.PAS contains the following ;)

{ TApplication object }

   PApplication = ^TApplication;
   TApplication = object(TProgram)
     constructor Init;
     destructor Done; virtual;
   end;

and then below that is procedure RegisterApp with constants like

Application: PProgram = nil;
DeskTop: PDesktop = nil;
StatusLine: PStatusLine = nil;
MenuBar: PMenuView = nil;
AppPalette: integer = apColor;

the TVDEMOS directory contains code related to forms and dialogue boxes, too... and all this done in textmode... no graphical modes at all...

*wink*

It works perfectly. You can use it to compile any fcl-web application against. So that there are no dependencies on external gui-libraries (like gtk, qt etc)

Joost.

OK. "Works" here obviously means that it helps the application to be compiled, but it does not provide much functionality to the Application. Especially (other than the other 8 Widget Types) it does not implement an event queue (or attach to one provided by the OS). That is why a TTimer will not be usable.

The NoGUI Widget Type does allow for "fcl-web" applications, that are normal CGI program. I.e. started by the web server and is provided with information by same via environment variables, a web page is only transferred to the web server when the cgi program closes.

The NoGUI Widget Type does not allow for "persistent" CGI applications. I.e. the cgi program keeps running and is provided by the web server with informations via a pipe or TCP/IP connection. It send a web page to the web server via a pipe or the TCP/IP connection appropriately. (Not all web servers allow for this method; Apache does.

To do a decent "persistent" CGI applications you need to use timers, TCP/IP, threads etc: all this stuff creates asynchronous events that need to fire application "events" in the main thread, which keeps on waiting for such events independently of the CGI activity, On top of this, on the Web Client site there are methods (provided by Java script applets) that allow for monitoring the activity of such a program using a kind of polling on a kept-open HTTP connection. This is based on AJAX and is called Comet.

While doing a "persistent CGI program" is one application for an event-queue enabled NoGUI Application (that avoids any dependencies on external gui-libraries) my target is embedded devices which don't provide any hardware that could enable a GUI.

That is why I am planning to enhance it (supposedly calling the result "Linux-NOGUI" Widget Type)

-Michael

i'm very intrigued by your proposal and work on this... i'm very interested in it for a idea i've had for a long time but had no real pointer to how to accomplish it... especially when it comes to this persistent interface with a web server...

why limit your NoGUIApplication, by name or otherwise, to linux only? what would it have to do differently on other OS'??

Works means that I can use lazarus-resources and other lcl-stuff without dragging in any GUI-bindings.

The NoGUI Widget Type does allow for "fcl-web" applications, that are normal CGI program. I.e. started by the web server and is provided with information by same via environment variables, a web page is only transferred to the web server when the cgi program closes.

Fcl-web is a framework on which you can make 'anything' you want. You can use FCGI and your program will be persistent. You can use the webmodules. If you do, you can let the framework create a new webmodule for every call. (REST) But you can also make them persistent. You can even bind them to one session. So you have one Webmodule persistent in memory for every session.

It doesn't have a queue, though. Because the web-server handles that. (Each http-request is an event) But I've never tested that with session-persistent webmodules. Maybe that needs some more handling.

Using an HTTP connection which is kept open is not supported. You could try to add it, though. But maybe that you have to add more threading and polling code, indeed.

While doing a "persistent CGI program" is one application for an event-queue enabled NoGUI Application (that avoids any dependencies on external gui-libraries) my target is embedded devices which don't provide any hardware that could enable a GUI.

What's wrong with using remote-X?

Joost.

why limit your NoGUIApplication, by name or otherwise, to linux only? what would it have to do differently on other OS'??

I have no idea of cgi, but some comments suggest to me that cgi must be tailored to a number of new "platforms", e.g. Apache...

Perhaps a similar distinction could/should be made with window managers, so that TApplication could interact with Windows, Gnome, KDE, Apache etc. application or window management.

DoDi

Not really.

CGI is standardized since ages, and is independent of the server software. I programmed my first CGI apps for NCSA httpd server 15 years ago, and things haven't changed since.

Michael.

waldo kitty wrote

i'm very intrigued by your proposal and work on this... i'm very interested in it for a idea i've had for a long time but had no real pointer to how to accomplish it...

Same here. I have been discussing this issue in the fpc-develop mailing list already years ago. In fact I feel that support for an OS-independent event queue is better done in the RTL than in the LCL, but as traditionally - since Delphi - the event queue is done in the same units as the GUI basics, this would needs basic changes as well on the FPC as on the Lazarus site. Something I'm not able to initialize and manage. So I changed to this mailing list to discuss the issue.

I always did know how this could be done technically and in fact I do have a working version. But right now I am trying to create a decently integrated Lazarus package for the function.

especially when it comes to this persistent interface with a web server...

Here NoGUIApplication is only a basic tool to create a "persistent" CGI application.

The communication with the web server (via a byte stream - pipe or TCP/IP) is defined by the Apache people. AFAIK, most major web servers support this, as well, but many "small" web servers don't.

On top of the AJAX/Comet specification define the way the web client polls for updates of the web page the user watches. This is done by the CHI hanging the HTTP request until an update is necessary or a HTTP timeout is due. On the client site this usually is done by a standard Java script package. (See the topic "New version of WebDesign available" in this mailing list).

why limit your NoGUIApplication, by name or otherwise, to linux only? what would it have to do differently on other OS'??

On a Windows box a GUI API is available, anyway, so you can use a standard application do do a persistent CGI or any other daemon / service alike GUI-less programs just by ignoring the GUI. So a dedicated NoGUIApplication is not necessary. Of course it can quite easily be done if the Linux version is in place.

I learned that there are reasons to keep the pure "nogui" name in place, even though I think "dummy" would be more appropriate, as it only provides hooks for the compiler, but no function. Can you suggest a different name ?

-Michael

Absolutely true for "Standard" CGI. Here, with a HTTP request, the web server starts a "command line tool" type of program ("filter") providing information in the environment. The program creates a web page as its standard output ("writeln"). The OS transfers this output to the web server. When the program terminates the web server transfers the web page to the web client. Thus such a CGI program can't live longer than a single HTTP request.

Apache (AFAIK) some time ago defined a way to do "persistent" CGI programs. Here the information formerly placed in the environment is transferred via a byte stream (pipe or TCP/IP) and the web page is transferred in such a byte stream as well. AFAIK, other major web servers support this method, too.

The Windows IIS uses a different paradigm called ISAPI, that is based on the CGI program being a DLL (requiring a permanently running task in same to be done as a thread).

Persistent CGIs offer less overhead (AFAIK, this was the main purpose to define the paradigm) and more functionality: they support "states" simply as global variables instead of needing to save any state change in files or a database and permanently running tasks doing stuff independently of the HTTP request, i.e. allowing for an - otherwise normal - application with a "web" (browser) user interface.

-Michael

I don't understand how this can work.
If you install you CGI on a hired web server, same will not provide a GUI APi, so you can't do this program as a normal "Application" e.g. with GTK binding.
If you therefor use the "nogui" Widget Type, the program can't handle events and thus will stop as soon as the user code is done. Thus it is not "persistent".

It doesn't have a queue, though. Because the web-server handles that. (Each http-request is an event)

How are such events communicated from the web server to the CGI program ? What mechanism "fires" these events within the GCI code ? How is the program supposed to wait for such an event ?

Using an HTTP connection which is kept open is not supported. You could try to add it, though.

This is a different task from what I am up to. My intent is not CGI but embedded applications. But I'm sure that there are viable projects requiring this, including doing a web-GUI to an embedded application (but I decided not to go for this)

But maybe that you have to add more threading and polling code, indeed.

IMHO the way to go for that is using the said NoGUIApplication. You supposedly will use threads for the pipe- or TCP/IP-based connection to the web server needed by a persistent CGI (see my questions above)

What's wrong with using remote-X?

I feel, this overhead is not appropriate with a (small hardware) embedded device. NX seems to provide a more appropriate protocol, but still the widgets need to be handled on the embedded site.

Thanks,
-Michael

Why not ?
It just has to persist all variables it needs in the next request. The session takes care of that.

It just waits for a request on the socket.

Michael.

This is fastcgi, which is supported by FPC, see my other mail.

The Windows IIS uses a different paradigm called ISAPI, that is based on the CGI program being a DLL (requiring a permanently running task in same to be done as a thread).

Apache has the same, it's an apache module. You can create one in FPC.

Yes, and as I said, the fastcgi implementation of FPC supports this.

Or you could create an apache module.

Michael.

Michael Van Canneyt wrote

This is fastcgi, which is supported by FPC, see my other mail.

Ah "fastcgi". Thanks for the pointer. I already did come across this name during my researches. My old mind has no problem remembering concepts, but it has difficulties remembering their names ;) .

Or you could create an apache module.

For me the task is to create a free running application from this with no Apache binding (see my other mail).

Lets see if that is possible.....
-Michael