Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / lazarus / 2015-12

"NoGui" or "Service Application"

4 messages · 2 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Michael Schnell
Show quoted text 33 lines
On Wed, 09 Dec 2015 12:17:55 +0100 Michael Schnell wrote: > On 12/09/2015 11:45 AM, Mattias Gaertner wrote: >>> Application QueuAsyncCall is implemented using TThread.Queue. >> What is wrong with the current implementation? > Nothing. But it uses another Queue. Queue handling needs OS calls for > waiting. I want to avoid to do any OS Calls so I simply use what the > RTL offers for exactly this purpose. Please take a look at the NoGUI widgetset. It does not use another Queue. > [...] >> NoGUi has already a dedicated mainthread, TThread.Synchronize, >> TThread.Queue, Application.ProcessMessages, >> Application.QueueAsyncCall. Only SendMessage and TTimer are missing. > [...] > In fact I would not like to try to re-use the NoGUI code, What code? It only contains the basic methods to let it compile. Any LCL interface must have at least that. > especially as > I seem to remember that I read about several shortcomings of same (I did > not yet check myself). Is there a documentation on what exactly NoGUI is > supposed to provide ? The NoGUI allows to compile a LCL application without a GUI. It has a few lines of code to connect the RTL. > (I suppose this "Service Application" might replace "noGUI", but of > course same should stay in place for legacy projects. ) I guess implementing TTimer and SendMessage only needs a few hundred lines. I see no problem adding that to the NoGUI widgetset.

As requested (and decent indeed), I herewith start a new thread and will answer tomorrow.

Thank for caring,

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

Reply by email

Michael Schnell
to Michael Schnell
On 12/09/2015 11:45 AM, Mattias Gaertner wrote: > Please take a look at the NoGUI widgetset. It does not use another > Queue.

If it does not use "another queue" but the one provided by the fpc RTL (i.e. does not install it's own queue), and (obviously) does not use a queue that is related to a GUI, it does not provide a queue art all.

So it does not provide an Event-Handling infrastructure and this (in according to my terms) means it is not a ("Delphi Style") application, hence not a "Service Application".

> What code? It only contains the basic methods to let it compile. Any > LCL interface must have at least that.

This is what I assumed (and heard from those who tried it): It only provides for compiling but does not offer any functionality.

> The NoGUI allows to compile a LCL application without a GUI. It has a > few lines of code to connect the RTL.

If your intention is to say that just using the name NoGUI and "silently" update it to something that is "active" (and with that a "Service Application") would be more sensible than creating a newly named Widget Type / Application Type, I don't have any problems with that. I just though of a new name to prevent the possibility to break any existing code.

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

Reply by email

Mattias Gaertner
to Michael Schnell
Show quoted text 8 lines
> On 12/09/2015 11:45 AM, Mattias Gaertner wrote: >> Please take a look at the NoGUI widgetset. It does not use another >> Queue. If it does not use "another queue" but the one provided by the fpc RTL (i.e. does not install it's own queue), and (obviously) does not use a queue that is related to a GUI, it does not provide a queue art all.

As I wrote: SendMessage is not yet implemented.
Add a queue and some specials for global Application handles and you got it.

So it does not provide an Event-Handling infrastructure and this (in according to my terms) means it is not a ("Delphi Style") application, hence not a "Service Application".

A service needs more than an event queue. See the lazdaemon package.

>> What code? It only contains the basic methods to let it compile. Any >> LCL interface must have at least that. This is what I assumed (and heard from those who tried it): It only provides for compiling but does not offer any functionality.

To be exact: it currently adds little to the functionality of RTL, FCL and LCLBase.

Show quoted text 8 lines
>> The NoGUI allows to compile a LCL application without a GUI. It has a >> few lines of code to connect the RTL. If your intention is to say that just using the name NoGUI and "silently" update it to something that is "active" (and with that a "Service Application") would be more sensible than creating a newly named Widget Type / Application Type, I don't have any problems with that. I just though of a new name to prevent the possibility to break any existing code.

CreateTimer and SendMessage are currently empty methods. The chance of breakage is small.

Mattias

Reply by email

Michael Schnell
to Mattias Gaertner
Mattias Gaertner wrote 5 lines
> So it does not provide an Event-Handling infrastructure and this (in > according to my terms) means it is not a ("Delphi Style") application, > hence not a "Service Application". A service needs more than an event queue. See the lazdaemon package.

The discussion here was about it *not* being a (Service-) *Application* if anything above making it an *application* makes sense (e.g. providing means to communicate with a corresponding GUI application or typical installation mechanism for configuration) this could be added independently.

The first step is to provide the infrastructure for "embedded" (not in the sense of "no-OS", as the term is used in the Wiki) Applications for e.g. headless Linux devices and Windows 10 IOT.

CreateTimer and SendMessage are currently empty methods. The chance of breakage is small.

OK.

I'll take a look if the working "interface" unit I already have somehow can be synchronized / merged with the NoGUI code in the svn....

-Michael

Reply by email