Re: [Development] [QIODevice]How to correctly treat/understand of the documentation?
Hi Carlos. Look at the read/write calls in Unix. If you use the asynchronous mode of operation you will get an error if the data cannot be read/written. No data is lost, unless you explicitly delete the data you pass to those functions. And from your point of view there is no way to tell if read/write failed because of a empty/full OS buffer or if it is because of a device buffer that is empty/full. 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. Of course, the user shall take responsibility for processing in Unbuffered mode. But I think that Unbuffered mode isn't necessary. What sense in it? What advantages? So, I think, that the Buffered mode it is sufficient way. When all data reads from FIFO and stored into internal buffer of class, then no exists data loss. There is so much you can do to prevent a user to misuse your class. If the user wants to use three separate calls to send data that is time sensitive, then so be it. On the other hand, even if the class does not allow the user to do bad things, the OS might introduce delays that are beyond your control. As long as you use the layers provided by the OS, there is always the chance that data might not be sent when you expected it to be sent. Then class implementation significantly becomes complicated (and maybe impossible). Probably, the way with separate write() for the minimum time delay can be implemented for Unbuffered mode. i.e. using of Unbuffered mode will be recommended if the User want to use minimal delays and direct I/O. I think you should separate the implementations. Most Unixes are able to handle asynchronous operations without much fuzz, so you could have your own qserialport_unix.cpp and have a different one for windows qserialport_win.cpp. Do what's right on Unix and do what's right on Windows. If for some reason there are things that cannot be done on both, be honest and document those. Please see QtSerialPort sources.. BTW: The asynchronous I/O in Unix (POSIX) has a big problems against Windows. Maybe it is make sense to use aio_read/aio_write instead of read/write syscalls for *nix. I think you are making things too complicated. There is no reliable way to know that the data was sent by the device, unless the device explicitly raises a signal after the data is sent. This is dependent on the driver, at least on Linux (and probably other Unixes too). It seems to me that the best course of action for you would be to use asynchronous IO at the OS level and use wait for the OS signals. This will work at least on Linux and most Unixes. On Windows things might be different but I doubt that Windows does not offer something similar in one way or another. 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. PS1 Where could I take a look at your code? https://qt-project.org/wiki/QtSerialPort PS2 Do you have an internal mailing list for the QSerialPort project? No, we don't have it. BR, Denis 22.04.2014 22:13, Carlos Duclos ?: Hi Thiago, Kuba, It should support the same waitForBytesWritten() and waitForReadyRead() that QAbstractSocket and QProcess have. Those are blocking. Yes, QSerialPort does it (at least tries to do). :) Let's make sure we distinguish blocking from buffered. It's quite ok for QSerialPort to be unbuffered -- there's a QIODevice flag for it. But it should still be non-blocking. Yes, in the future we will try to add this opportunity. But I don't see advantage of Unbuffered mode against Buffered. Because in Unbuffered a mode is probable loss of data, because the FIFO can be overflowed and so on. At least this can be occured at reading of data. If the implementation is sane, there should not be any loss of data regardless of the presence of a buffer or not. Notice that it involves the user of the class too, since the ultimate decision about how to use the class is with him/her. Look at the read/write calls in Unix. If you use the asynchronous mode of operation you will get an error if the data cannot be read/written. No data is lost, unless you explicitly delete the data you pass to those functions. And from your point of view there is no way to tell if read/write failed because of a empty/full OS buffer or if it is because of a device buffer that is empty/full. Acceptable. It's not how QAbstractSocket and QProcess work, but they could
Re: [Development] Question about Qt's future
On 24.04.2014 21:15, Attila Csipa wrote: solutions to cross platform mobile development :( After playing a bit with Xamarin (yes, I know, but put aside the C# hate for a minute), it's quite striking what different approaches can result in (and it also made it quite clear what Qt is doing better - but also worse than other cross platform solutions). Recently I also has to write some non-GUI code in C# (a simple class to connect to a server written in C++/Qt using Google's protobuf). First I was a bit annoyed about this, but after putting away the C# hate it wasn't that bad. He some impressions: - for my use case it was cross-platform out-of-the box (Windows/Linux) - you don't have to care about the build system, just use the .sln files - you have the feeling to write code in a hurry because everything is placed in the headers - you realize that C++ compilers/language is much more powerful, especially when using generics - you've lost the contact to the real hardware, all feels so smooth - you don't see what's going on because of all the stuff in the background (ok until there are problems) As said I didn't build a GUI, what are your experiences with the GUI part C#? Cheers, Peter ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 25.04.2014 12:18, Joerg Bornemann wrote: Yep, I hear people keep repeating the mantra QML is declarative. It's just QML/JS that isn't. I think the declarative-mantra is a good idea, especially when used for _specifying_ (not programming) the GUI. At Adobe they tried it with pure C++ http://stlab.adobe.com/group__asl__overview.html#asl_overview_adam_and_eve_architecture which consequently ended up in a template/boost massacre. Looks like is is dead now. QML is also a nice try, but it got messed up with the imperative part. Maybe because the temptation was too overwhelming to use the already integrated JS engine for more stuff than running declarative part. 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. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 26.04.2014 17:39, André Pönitz wrote: You could have made the point declarative structures are good for GUI description for Qt Widget's .ui files, after all, .ui files contents pretty much _is_ declaring layout nesting and property values. Just an idea: Declarative-only QML files could be translated to C++ by a tool similar to uic, and then used by a C++-only successor of QtWidgets. Or are there any technical reasons why all the state-of-the-features provided by QML v2 could not be implemented on the C++ side assuming there is a QML-to-C++ code generation step? Having a clear cut between declarative and imperative QML would also improve visibility of specification- and implementation-parts of a QML file. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 21.04.2014 13:39, Roland Winklmeier wrote: - Memory consumption: Even a mini example took about 70 MB of memory, QtWidgets need a lot less. This is not a complain, I know the JS runtime needs its initial memory. It was just one factor, because our application is running as an addon to Flight Simulators and they usally consum a lot memory. This is especially a major problem with MS Flight Simulator since it is only available as 32 bit application. Therefore every any MegaByte is important. Especially on non-fat embedded systems this is a problem: When you wanna use Linux you need some MBs Ram for the kernel, some to get a running system, and some MBs for your application. So you end at minimum 5-32MBs. Then adding 100MB just to run QML really hurts, and you start looking for alternatives, like using only QWidgets with very limited OpenGL support or not to use a Qt-GUI at all. Maybe such systems are also interesting from a business perspective. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 27/04/2014 12:55, Peter Kümmel wrote: 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. +1 -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On Sunday 27 April 2014 12:55:58 Peter Kümmel wrote: 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. +1 Frank ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
Hmm, but why don't you use Qml like that then? The language doesn't force you to use inline js code, does it? A lot of the work that has gone into the engine lately also enables this to work better and reduce the use of JS. For example bindings that just consist of a qsTr don't actually end up creating any js bindings. Simon Opprinnelig melding Fra: Yves Bailly Sendt: 16:52 søndag 27. april 2014 Til: development@qt-project.org Emne: Re: [Development] Question about Qt's future On 27/04/2014 12:55, Peter Kümmel wrote: 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. +1 -- (o | Yves Bailly | -o) //\ | Linux Dijon : http://www.coagul.org | //\ \_/ | | \_/` ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
Em dom 27 abr 2014, às 13:31:33, Peter Kümmel escreveu: Then adding 100MB just to run QML really hurts, and you start looking for alternatives, like using only QWidgets with very limited OpenGL support or not to use a Qt-GUI at all. Of those 100 MB, 30 MB are taken by QtCore and QtGui (including ICU data). The rest, I'm guessing you pulled the numbers out of thin air without a benchmark. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu: On 26.04.2014 17:39, André Pönitz wrote: You could have made the point declarative structures are good for GUI description for Qt Widget's .ui files, after all, .ui files contents pretty much _is_ declaring layout nesting and property values. Just an idea: Declarative-only QML files could be translated to C++ by a tool similar to uic, and then used by a C++-only successor of QtWidgets. Or are there any technical reasons why all the state-of-the-features provided by QML v2 could not be implemented on the C++ side assuming there is a QML-to-C++ code generation step? It's possible, but there's no API in the C++ side to create the graph. Until such an API exists, you can't write the generator. Care to contribute the C++ side, including passing all the reviews? Note that this is a major undertaking and will probably take two or three releases to get a minimal functional API out there. Plus the maintenance effort. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
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. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [QIODevice]How to correctly treat/understand of the documentation?
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. Of course, the user shall take responsibility for processing in Unbuffered mode. But I think that Unbuffered mode isn't necessary. What sense in it? What advantages? So, I think, that the Buffered mode it is sufficient way. When all data reads from FIFO and stored into internal buffer of class, then no exists data loss. True. We don't offer unbuffered mode for QTcpSocket or QProcess either. 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. PS2 Do you have an internal mailing list for the QSerialPort project? No, we don't have it. Well, yes you do. It's this one :-) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On Sun, Apr 27, 2014 at 10:37 PM, Thiago Macieira thiago.macie...@intel.com 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 Actually, you can.. http://css-tricks.com/a-couple-of-use-cases-for-calc/ And even Internet Explorer has support for it: http://caniuse.com/#feat=calc The moment you start adding some math, you need stuff like Math.random() and you end up again in JS. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 27 April 2014 22:31, Mark Gaiser mark...@gmail.com wrote: Actually, you can.. http://css-tricks.com/a-couple-of-use-cases-for-calc/ And even Internet Explorer has support for it: http://caniuse.com/#feat=calc It's a variant of the expression() facility that IE has offered to CSS since IE6. It's extremely useful for bypassing XSS filters. :-) Rich. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
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. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On Mon, Apr 28, 2014 at 6:53 AM, Thiago Macieira thiago.macie...@intel.comwrote: Em dom 27 abr 2014 15:01:10 você escreveu: It's not the only available choice. Widgets are available. They just look horrible because no one has done any work to make them look native. Is my understating correct that: 1. at least QML apps in iOS already have a native look? Any examples beyond the most basic? The point I was trying to make is that they will have a native look, if they don't already. I don't know if they do. I don't do iOS development and don't care to follow the development there. However, QtWidgets will never have native look on iOS. 2. there are any Qt-related benchmarks demonstrating opengl versus i.e. raster performance advantages for iOS and Android? Any links? That's pretty basic information. OpenGL always beats, hands down. Try to do nice effects in raster and you'll see a huge CPU spike, eating battery, or not able to finish at all. I don't have links for this. it should be easy to find on Google. 3. opengl issues on Android have been addressed and it is stable? I'm not aware of any issues. But I don't follow Android development closely either. 4. memory footprint, particularly on iOS devices with 1GB of RAM, best case, for QML is reasonable and does not cost a foot and leg? Any data? I don't know either. Like I said, I don't follow iOS development. I don't have an SDK for it installed and don't care to try it. If you had asked for 256 MB, I'd be worried. For 1 GB, it shouldn't be a problem, but I can't give you data. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center Sorry, but the above is not helpful. I'd never jump to conclusions and statements without in-hands knowledge of the subject to talk about. Thank you. Regards, Robert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Question about Qt's future
On 27.04.2014 22:40, Thiago Macieira wrote: Em dom 27 abr 2014, às 13:09:50, Peter Kümmel escreveu: On 26.04.2014 17:39, André Pönitz wrote: You could have made the point declarative structures are good for GUI description for Qt Widget's .ui files, after all, .ui files contents pretty much _is_ declaring layout nesting and property values. Just an idea: Declarative-only QML files could be translated to C++ by a tool similar to uic, and then used by a C++-only successor of QtWidgets. Or are there any technical reasons why all the state-of-the-features provided by QML v2 could not be implemented on the C++ side assuming there is a QML-to-C++ code generation step? It's possible, but there's no API in the C++ side to create the graph. Until such an API exists, you can't write the generator. I know that currently there is no support for this in Qt, also no plans to add it, all I wanted to hear is It's possible. I assume it would be only a community-driven long-term project, which takes years until it is on par with QtWidgets. But hey, I'm fascinated by the idea, and maybe I'm not alone. ATM the problem is to get started because I don't know much about the current architecture of the graphic stack. Any hints where to start for a first hello world? Care to contribute the C++ side, including passing all the reviews? Note that this is a major undertaking and will probably take two or three releases to get a minimal functional API out there. Plus the maintenance effort. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
