[Interest] Design idioms for QtCore applications

Jason H scorp1us at yahoo.com
Fri Feb 8 17:12:09 CET 2013

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: "
>"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) 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. 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. 

 From: K. Frank <kfrank29.c at gmail.com>
To: Qt-interest <interest at qt-project.org> 
Sent: Friday, February 8, 2013 10:15 AM
Subject: Re: [Interest] Design idioms for QtCore applications
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

> ________________________________
> From: K. Frank <kfrank29.c at gmail.com>
> ...
> Hello List!
> I am playing around with non-gui, "QtCore" applications,( i.e., applications
> that have #include <QtCore> rather than #include <QtGui>).
> ...
> I'm looking for general advice on the design philosophy for QtCore
> apps, how to use events, and design idioms for simple QtCore
> apps.
> ...
Interest mailing list
Interest at qt-project.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20130208/fef83a5d/attachment.html>

More information about the Interest mailing list