[Development] [QIODevice]How to correctly treat/understand of the documentation?
Carlos Duclos
carlosduclosv at yahoo.com
Mon Apr 28 11:53:18 CEST 2014
>On Sun, Apr 27, 2014 at 01:34:52PM -0700, Thiago Macieira wrote:
>> Em dom 27 abr 2014, ?s 11:08:44, Denis Shienkov escreveu:
>> > Here I am a little disagree. Because in Unbuffered mode, loss of data is
>> > exists. For example, in a case when the port accepts a data stream. And
>> > when the user ignores readyRead() signal, i.e do not reads nothing from
>> > port. In this case FIFO of device/driver will be overflowed, that will
>> > cause overrun/overflow errors, and part of stream will be lost.
>>
>> Doesn't happen with pipes, sockets and other devices with flow control.
>>
>yeah, but serial ports can be operated without flow control. if the
>kernel does not buffer indefinitely (which seems plausible, as otherwise
>one could DoS it), data could be discarded indeed.
That is why I suggest that when in Unbuffered mode, write/read should behave as their Unix counterparts in non blocking mode. If the data cannot be written at once, then refuse to write it (or to read it).
Discarding data is more or less always a possibility, unless it is stopped by the device itself by using flow control. The moment flow control is disabled, buffering data will protect it for a little while until the buffer is full. If nobody empties the buffer, then the data will be discarded at some point (or the app will be killed by the OOM). And even using flow control, if the flow control is automatic and the data is copied by QtSerialPort to its own buffer, there is risk of filling that buffer if the buffer is not emptied. At some point a line needs to be drawn, it is impossible to prevent misuse in all cases. If the user of QtSerialPort never empties the buffers by reading from them or the buffer cannot be emptied because the device is never ready for writing, then we need to signal the error and let the user take the corrective action.
>> > As I wrote above, the only Windows has an "true" async I/O. The Unix has
>> > not this feature, he has only "non-blocking" approach, but it is not an
>> > "async" I/O. So, implementation of completion of I/O operation is
>> > problematic on any Unix's. We only can judge about operation completion
>> > indirectly, e.g. for writing - wait for the Tx-empty event.
>>
>> By the way, what is that tx-empty event? Note that sockets and pipes don't
>> have that, so please don't make QSerialPort use that by default. You can add
>> an extra signal to QSerialPort to indicate this, but bytesWritten() must mean
>> the same as QTcpSocket and QProcess.
>>
>a separate signal would be redundant, as checking byteToWrite() == 0 in
>the slot called from bytesWritten() is sufficient.
That seems indeed a good option. Although, it is device independent to emit a signal (SIGIO|POLLOUT) if the data was written. We might not be able to find out if the data was written by the device or if it is being held in some internal buffer on the driver.
El Lunes, 28 de abril, 2014 11:32 A.M., "development-request at qt-project.org" <development-request at qt-project.org> escribió:
Send Development mailing list submissions to
development at qt-project.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.qt-project.org/mailman/listinfo/development
or, via email, send a message with subject or body 'help' to
development-request at qt-project.org
You can reach the person managing the list at
development-owner at qt-project.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Development digest..."
Today's Topics:
1. Re: Updating JIRA components relating to events. (Paul Olav Tvete)
2. Re: Question about Qt's future (Hartmann Thomas)
3. Re: Updating JIRA components relating to events.
(Blasche Alexander)
4. Re: Updating JIRA components relating to events. (Paul Olav Tvete)
5. Re: Question about Qt's future (Nils Jeisecke)
6. Re: [QIODevice]How to correctly treat/understand of the
documentation? (Oswald Buddenhagen)
7. Re: Question about Qt's future (Hartmann Thomas)
----------------------------------------------------------------------
Message: 1
Date: Mon, 28 Apr 2014 10:19:50 +0200
From: Paul Olav Tvete <paul.tvete at digia.com>
Subject: Re: [Development] Updating JIRA components relating to
events.
To: <development at qt-project.org>
Message-ID: <1450848.oMjyDEmEbG at neverwhere>
Content-Type: text/plain; charset="us-ascii"
On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> I've just noticed that the "GUI: Input methods" component in JIRA has got
> an update now saying "(Non-Latin languages)". That is, it seems the
> purpose of that component has changed to mean complex input methods only.
>
> I've been reassigning to that component anything that is related to *any*
> input method, especially mouse, keyboard and touch, which bug reporters
> often submit to "Core: Event System".
>
> Can I ask that we create a "GUI: Basic Input Method (keyboard, mouse,
> touch)" component? Does anyone feel like being the default assignee?
> Please reply in QTJIRA-258.
As I commented in the task, I would like to request a reversal of the "Non-
Latin languages" renaming. On Android, we use exactly the same infrastructure
for input of Latin-based languages. (Also, there are several non-Latin scripts
that can use simple keyboard input on a desktop computer.) If we have to
rename, I support Thiago's suggestion of "Complex input methods", possibly
with a "text" or "language" thrown in.
[Apology in advance for small rant.]
In the future, could we please not rename components silently without warning?
This renaming effectively edited several of my tasks, making them misleading.
As a bonus it also messed up my filters.
- Paul
------------------------------
Message: 2
Date: Mon, 28 Apr 2014 08:29:24 +0000
From: Hartmann Thomas <Thomas.Hartmann at digia.com>
Subject: Re: [Development] Question about Qt's future
To: Thiago Macieira <thiago.macieira at intel.com>,
"development at qt-project.org" <development at qt-project.org>
Message-ID:
<1380CEABC81B604BBD1CBDE7C61F9401CF0A05 at IT-EXMB01-HKI.it.local>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
while (at least for me) it is not really clear where exactly the boundary between declarative and functional programming lies, we could/should at least rule out control flow statements and anything with side effects in bindings.
The statement "width: Math.floor(height)" could be considered declarative (enough), if we limit the allowed functions to a well defined subset.
But currentlty one can do this: width: { Any imperative code one can imagine, including loops, while(true) and side effects. } This clearly is not declarative anymore.
Another issue with QML is that some parts of the API of Qt Quick are not accessible through a declarative API (e.g. setting a state). While this is not a problem in principle (since we could extend the API), it is a problem in practice.
Until now nobody (including me) found the time to fix it.
>From my point of view many of these problems are caused by the fact that Qt Quick allows very fast prototyping
(And Qt Quick is an excellent UI prototyping tool.), but is also used in real production code.
While certain features (Like inlining .js code everywhere all over the place and no clear split between declarative UI and logic) are nice for protoyping, they can become a burden in larger production code.
To give a concrete example: While things like width: Math.max(someId.width, someOtherId.width) + magicNumber
are nice to achieve certain complex layouts and to circumvent limitations of the "declarative layout system", they create a huge maintenance burden, because this kind of code is hard to read and does not play nice with tooling.
The only solution I see is to create a well defined QML/QtQuick (sub)set that is more suitable for production code/larger projects. Such QML would be more rigid, enforce more structure on the developer and would be as declarative as possible.
Such a QML "dialect" could forbid any inline js code. All Java Script could would be part of .js files.
Another idea is to allow C++ companion objects, that would take the place of any Java Script code for people who prefer C++. A companion object would be a QObject paired with the QML object, that has access to the QML context. The QObject would then define a couple of signals/slots that can be used from QML as Java Script is used today.
Kind Regards,
Thomas Hartmann
________________________________________
From: development-bounces+thomas.hartmann=digia.com at qt-project.org [development-bounces+thomas.hartmann=digia.com at qt-project.org] on behalf of Thiago Macieira [thiago.macieira at intel.com]
Sent: 28 April 2014 02:34
To: development at qt-project.org
Subject: Re: [Development] Question about Qt's future
Em seg 28 abr 2014, ?s 00:55:12, Andr? P?nitz escreveu:
> On Sun, Apr 27, 2014 at 01:37:33PM -0700, Thiago Macieira wrote:
> > Em dom 27 abr 2014, ?s 12:55:58, Peter K?mmel escreveu:
> > > Having imperative code on the JS side is also the root of the rejection
> > > of
> > > QML for many C++ developers. If QML would have been just a improved .ui
> > > nobody would have complained.
> >
> > We'd end up with one of the problems of CSS which is that you can't do
> > calculations in the bindings. I can't do
> >
> > width: 50% - 10em
> >
> > The moment you start adding some math, you need stuff like Math.random()
> > and you end up again in JS.
>
> Not true. Some (basic) math fits the "declarative" needs, and would
> be toolable. Math.random() does obviously not fit the bill.
Math.floor() then.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
------------------------------
Message: 3
Date: Mon, 28 Apr 2014 08:42:48 +0000
From: Blasche Alexander <Alexander.Blasche at digia.com>
Subject: Re: [Development] Updating JIRA components relating to
events.
To: "development at qt-project.org" <development at qt-project.org>
Message-ID:
<D0AE864289F56A48A1B9DA6FA7E3239AEAE6DF at IT-EXMB01-HKI.it.local>
Content-Type: text/plain; charset="us-ascii"
Hi,
I renamed it on request. It was such a minor change that I didn't see an issue especially since the component doesn't have a default assignee. Obviously that is not the case.
Paul, you have to rename your filter again. Filtering on the name string is rather stupid but that's what jira does. It should really filter on component ID which does internally exist. Not Paul's fault though but I need to remember this.
On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> I've been reassigning to that component anything that is related to *any*
> input method, especially mouse, keyboard and touch, which bug reporters
> often submit to "Core: Event System".
I hope you reassigned it to another person? Otherwise they just end up in a virtual dead end considering that their is no ownership in the component.
I changed it back for now. Before we create any new components I would like to see some ownership. Otherwise this is just an exercise in moving from one bucket to the next without any purpose.
--
Alex
________________________________________
From: development-bounces+alexander.blasche=digia.com at qt-project.org [development-bounces+alexander.blasche=digia.com at qt-project.org] on behalf of Paul Olav Tvete [paul.tvete at digia.com]
Sent: Monday, April 28, 2014 10:19
To: development at qt-project.org
Subject: Re: [Development] Updating JIRA components relating to events.
On Friday 25 April 2014 17:27:23 Thiago Macieira wrote:
> I've just noticed that the "GUI: Input methods" component in JIRA has got
> an update now saying "(Non-Latin languages)". That is, it seems the
> purpose of that component has changed to mean complex input methods only.
>
> I've been reassigning to that component anything that is related to *any*
> input method, especially mouse, keyboard and touch, which bug reporters
> often submit to "Core: Event System".
>
> Can I ask that we create a "GUI: Basic Input Method (keyboard, mouse,
> touch)" component? Does anyone feel like being the default assignee?
> Please reply in QTJIRA-258.
As I commented in the task, I would like to request a reversal of the "Non-
Latin languages" renaming. On Android, we use exactly the same infrastructure
for input of Latin-based languages. (Also, there are several non-Latin scripts
that can use simple keyboard input on a desktop computer.) If we have to
rename, I support Thiago's suggestion of "Complex input methods", possibly
with a "text" or "language" thrown in.
[Apology in advance for small rant.]
In the future, could we please not rename components silently without warning?
This renaming effectively edited several of my tasks, making them misleading.
As a bonus it also messed up my filters.
- Paul
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
------------------------------
Message: 4
Date: Mon, 28 Apr 2014 10:59:29 +0200
From: Paul Olav Tvete <paul.tvete at digia.com>
Subject: Re: [Development] Updating JIRA components relating to
events.
To: <development at qt-project.org>
Message-ID: <2441161.FSKxQZWCL6 at neverwhere>
Content-Type: text/plain; charset="us-ascii"
On Monday 28 April 2014 08:42:48 Blasche Alexander wrote:
> I renamed it on request. It was such a minor change that I didn't see an
> issue especially since the component doesn't have a default assignee.
> Obviously that is not the case.
No worries :) I may be using the components in a slightly non-standard
fashion, but I do like to add additional components to tasks, instead of using
one component and several labels. In this case, I used the combination of
"QtPorts: Android" and input methods to track the input method issues on
Android.
- Paul
------------------------------
Message: 5
Date: Mon, 28 Apr 2014 11:00:31 +0200
From: Nils Jeisecke <njeisecke at saltation.de>
Subject: Re: [Development] Question about Qt's future
To: Hartmann Thomas <Thomas.Hartmann at digia.com>
Cc: "development at qt-project.org" <development at qt-project.org>
Message-ID:
<CANh_-9dOkhoHLK9AkYDO4ga1Py95Vx5h3=C-7sdKANtzM7rjoA at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> Another idea is to allow C++ companion objects, that would
> take the place of any Java Script code for people who
> prefer C++. A companion object would be a QObject
> paired with the QML object, that has access to the
> QML context. The QObject would then define a couple
> of signals/slots that can be used from QML as
> Java Script is used today.
I really like this idea. Maybe one could even write C++ code
directly in the QML file and let a preprocessor generate
a proper C++ class containing this code. So, no more JavaScript,
data conversion and garbage collection. Or just another tooling
nightmare?
Nils
------------------------------
Message: 6
Date: Mon, 28 Apr 2014 11:16:27 +0200
From: Oswald Buddenhagen <oswald.buddenhagen at digia.com>
Subject: Re: [Development] [QIODevice]How to correctly
treat/understand of the documentation?
To: <development at qt-project.org>
Message-ID: <20140428091627.GA5431 at troll08.it.local>
Content-Type: text/plain; charset="iso-8859-1"
On Sun, Apr 27, 2014 at 01:34:52PM -0700, Thiago Macieira wrote:
> Em dom 27 abr 2014, ?s 11:08:44, Denis Shienkov escreveu:
> > Here I am a little disagree. Because in Unbuffered mode, loss of data is
> > exists. For example, in a case when the port accepts a data stream. And
> > when the user ignores readyRead() signal, i.e do not reads nothing from
> > port. In this case FIFO of device/driver will be overflowed, that will
> > cause overrun/overflow errors, and part of stream will be lost.
>
> Doesn't happen with pipes, sockets and other devices with flow control.
>
yeah, but serial ports can be operated without flow control. if the
kernel does not buffer indefinitely (which seems plausible, as otherwise
one could DoS it), data could be discarded indeed.
> > As I wrote above, the only Windows has an "true" async I/O. The Unix has
> > not this feature, he has only "non-blocking" approach, but it is not an
> > "async" I/O. So, implementation of completion of I/O operation is
> > problematic on any Unix's. We only can judge about operation completion
> > indirectly, e.g. for writing - wait for the Tx-empty event.
>
> By the way, what is that tx-empty event? Note that sockets and pipes don't
> have that, so please don't make QSerialPort use that by default. You can add
> an extra signal to QSerialPort to indicate this, but bytesWritten() must mean
> the same as QTcpSocket and QProcess.
>
a separate signal would be redundant, as checking byteToWrite() == 0 in
the slot called from bytesWritten() is sufficient.
------------------------------
Message: 7
Date: Mon, 28 Apr 2014 09:32:12 +0000
From: Hartmann Thomas <Thomas.Hartmann at digia.com>
Subject: Re: [Development] Question about Qt's future
To: Nils Jeisecke <njeisecke at saltation.de>
Cc: "development at qt-project.org" <development at qt-project.org>
Message-ID:
<1380CEABC81B604BBD1CBDE7C61F9401CF125A at IT-EXMB01-HKI.it.local>
Content-Type: text/plain; charset="us-ascii"
Hi,
yes, writting C++ inline in QML would be another "tooling nightmare". Also what is the problem with:
MouseArea {
onClicked: companion.mouseAreaClicked();
}
If tooling creates the companion object for you (In a wizard) and code completion and code naviagtion (F2) works as expected?
Kind Regards,
Thomas Hartmann
________________________________________
From: Nils Jeisecke [njeisecke at saltation.de]
Sent: 28 April 2014 11:00
To: Hartmann Thomas
Cc: development at qt-project.org
Subject: Re: [Development] Question about Qt's future
Hi,
> Another idea is to allow C++ companion objects, that would
> take the place of any Java Script code for people who
> prefer C++. A companion object would be a QObject
> paired with the QML object, that has access to the
> QML context. The QObject would then define a couple
> of signals/slots that can be used from QML as
> Java Script is used today.
I really like this idea. Maybe one could even write C++ code
directly in the QML file and let a preprocessor generate
a proper C++ class containing this code. So, no more JavaScript,
data conversion and garbage collection. Or just another tooling
nightmare?
Nils
------------------------------
_______________________________________________
Development mailing list
Development at qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
End of Development Digest, Vol 31, Issue 91
*******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20140428/b681fe91/attachment.html>
More information about the Development
mailing list