Hello Jason! On Fri, Feb 8, 2013 at 11:12 AM, Jason H <scorp...@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 <kfrank2...@gmail.com> > > Hi Jason! > > On Fri, Feb 8, 2013 at 9:20 AM, Jason H <scorp...@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 > ... _______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
