[Lazarus] creating a Lazarus package "NoGUIApplication"

[Michael Schnell]

On 03/12/2010 03:10 AM, Hans-Peter Diettrich wrote:
> Mattias Gaertner schrieb:
>
>> 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?

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.