Hi Oliver!
On Sat, Feb 9, 2013 at 9:13 AM, Till Oliver Knoll
wrote:
> Am 08.02.2013 um 17:27 schrieb "K. Frank" :
>
>> Hello Jason!
>> ...
>> 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 complicat
Am 08.02.2013 um 17:27 schrieb "K. Frank" :
> Hello Jason!
>
> ...
>
> 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.
To give you some ideas you might run into trying
On sexta-feira, 8 de fevereiro de 2013 11.27.53, K. Frank wrote:
> 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.
You coined the term "Qt-approved". :-)
If you hadn't,
Hello Jason!
On Fri, Feb 8, 2013 at 11:12 AM, Jason H 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
Hi Thiago!
On Fri, Feb 8, 2013 at 10:53 AM, Thiago Macieira
wrote:
> On sexta-feira, 8 de fevereiro de 2013 10.15.39, K. Frank wrote:
>> 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 th
tion 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
To: Qt-interest
Sent: Friday, February 8, 2013 10:15
On sexta-feira, 8 de fevereiro de 2013 10.15.39, K. Frank wrote:
> 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 migh
Hi Jason!
On Fri, Feb 8, 2013 at 9:20 AM, Jason H 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 e
Hello Karl!
On Fri, Feb 8, 2013 at 9:37 AM, Karl Ruetz wrote:
> My company has been writing server type applications in Qt for about 10
> years. While these do not involved acquiring data from the command line,
> they do have to detect "work to do" in some fashion through the event loop.
> In yo
My company has been writing server type applications in Qt for about
10 years. While these do not involved acquiring data from the command
line, they do have to detect "work to do" in some fashion through the
event loop. In your case, it seems as though your "to do" list is coming
through the co
to need some way to
acquire work (socket maybe?) and then do that work. Look at a QTcpServer
example.
From: K. Frank
To: Qt-interest
Sent: Friday, February 8, 2013 8:02 AM
Subject: [Interest] Design idioms for QtCore applications
Hello List!
I am pla
On 8 February 2013 13:02, K. Frank wrote:
>
> I think part of what I'm missing is the connection between the event
> loop, "a.exec()", and processing console input without blocking.
At least under Unix systems, QSocketNotifier on stdin is the glue
you're looking for.
--
Giuseppe D'Angelo
___
Hello List!
I am playing around with non-gui, "QtCore" applications,( i.e., applications
that have #include rather than #include ).
(To date, I have been using Qt for gui's. If an app hasn't had a gui, I
didn't use Qt, and I would write the non-gui "business logic" in my
gui apps in Qt-independ
13 matches
Mail list logo
