[Interest] Design idioms for QtCore applications

[K. Frank]

Hello Jason!

On Fri, Feb 8, 2013 at 11:12 AM, Jason H <scorp1us at yahoo.com> wrote:
> You can split it anyway you want. It may not be so clear cut.
>
> You have many choices:
> Use STDIN/OUT as a synchronous QTextStream, as in
>>"hello, enter your name: "
> <"World"
>>"Hello World!"
> ( > is output; < is input)
>
> Or you can get fancier and create a stream reader QObject that emits
> commands to processing objects (this would be the way to go if you are
> multi-threaded, as the signals/slots would cross thread boundaries)

Yes, if I decide -- against Thiago's sage advice -- to try to integrate
console input with the event loop, I'm thinking my best choice might
be to introduce a console-reader thread that does blocking reads on
cin, and uses (queued-connection) signals / slots to inject the results
of those reads into the Qt event loop.

Obviously, that would add a bit of a layer of complications, but as
Thiago said, using console input is not "Qt-approved," so some
level of complication is to be expected.

> This
> however would become asynchronous. If you didn't make it multithreaded, it
> would be synchronous as the slot call would be directly invoked.
>
> the exec() means you're using an event loop and if you don't need anyc
> events, then you don't need an event loop.

(My thinking is that I might have a server-style application that does
make use of async events, but also wants plain-vanilla console input.
Again, all of this is hypothetical, because I'm just playing around.)

> Though, I would write it to use
> one anyway do you don't busy-wait in an idle loop. An empty event loop will
> not cause your application to be scheduled, thereby being much friendlier to
> other processes on the system. Though, if you have a read() loop this would
> also yield the processor if there is nothign to read.
> ...


Thanks for your insight.


K. Frank

> ...
> From: K. Frank <kfrank29.c at gmail.com>
>
> Hi Jason!
>
> On Fri, Feb 8, 2013 at 9:20 AM, Jason H <scorp1us at yahoo.com> wrote:
>> I've written a number of server applications.
>>
>> They work the same, you just inherit from QCoreApplication and make sure
>> you
>> have events.
>
> Ah, okay.
>
> To make sure I understand the suggestion:
>
> Rather than instantiate separately (for example in my main()) both an
> actual (non-subclassed) QCoreApplication and a business-logic class
> that (presumably) inherits from QObject, are you saying that I should
> inherit my main business-logic class for QCoreApplication, instantiate
> that, and then call its exec()?
>
> So this idiom is a little different that the gui idiom in the example in my
> original post where I instantiate a QApplication and a MyMainWindow
> class separately.
>
> Is there a gui idiom analogous to what you are suggesting where I
> inherit my main window class somehow from QApplication, and call
> its exec() directly?
>
>> It would help to know what you're trying to do, but as long as you're not
>> just processing command line arguments and exiting, you're going to need
>> some way to acquire work (socket maybe?) and then do that work. Look at a
>> QTcpServer example.
>
> Well, truth be told, I'm not trying to do anything.  Or, more seriously,
> I'm trying to learn, so that I get a sense of the Qt-approved way of doing,
> so that I get a sense of what one can do with non-gui Qt apps and
> when I might want to use them.
>
> That is, I'm just playing around right now.
>
> The kind of thing I'm thinking of, hypothetically, is some kind of server
> that responds to events coming in over a socket (maybe sometimes
> writing to that or another socket), but also responds to commands
> typed into the console.  (These might be more along the lines of
> management-control commands.)  So the first thing I thought I might
> try is to build a toy app that uses the event loop, but responds initially
> only to command-line input.
>
> Thanks for your thoughts.
>
> K. Frank
> ...