Re: [Development] No SSL on iOS ?
On 29 Apr 2014, at 00:16, Jeremy Lainé jeremy.la...@m4x.org wrote: On 04/28/2014 11:44 AM, Nichols Andy wrote: It is possible still in the packaged versions of Qt for iOS to make connections using SSL via QNetworkAccessManager as there is a backend that uses Apples crypto API, but without OpenSSL support you can’t use any of the API’s in Qt that use OpenSSL directly (like QSSLSocket). Ouch I just realised that most likely means QWebSocket on iOS does not support secure websockets! Yes, unfortunately. QWebSockets uses QSSLSocket and hence is not supported on iOS. What would the best course of action be to add support for secure websockets on iOS? Cheers, Jeremy ___ 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] Perceptions/Understandings of the QML language [was: Question about Qt's future]
-Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Andre Ponitz Sent: Monday, April 28, 2014 11:34 PM To: Alan Alpert Cc: development@qt-project.org Subject: Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future] On Mon, Apr 28, 2014 at 11:12:47AM -0700, Alan Alpert wrote: Yes, I agree that more rigorous and agreed definitions would be helpful. It also takes time, and impedes innovation, so I'm not sure if we're quite mature enough to nail down QML just yet. Should be soon though, in the next few years. To get this straight: After five years of development the Maintainer of the Qt Declarative module is neither able nor willing to give a simple definition of what QML is. Come on Andre, ad hominem attacks do not help. I'd expect better from you as a Maintainer yourself (quotes added on purpose). On to the topic: QML is what the QML parser accepts (that is, JSON like declarative syntax + JavaScript in certain places). No, there's no standard document for it (in case that's what you're after), but it has a well-defined grammar etc. Christian Kamm AFAIR planned a long time ago to add the grammar to the documentation, but I think that never was finished. And, as always, the documentation can be improved ;) The discussion so far was whether it makes sense to give the 'declarative' part alone a separate name (something we haven't done so far). I personally agree with Alan that it doesn't make much sense as long as the two parts are technically and practically inseparable. But I'm personally all for an experiment to come up with a more strict, declarative QML subset. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
Hi, On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz apoen...@t-online.de wrote: I think at least three modifications are inavoidable: For one, things that could be written in a declarative way but which currently are only possible using JavaScript, a declarative way should be added. Second, it should be stressed in the documentation (including the examples), that using inline imperative code is naughty. This can be supported by e.g. the QML Designer refusing to operate on such files. People can still do that, but would be on their own. And finally, and that's also acting as a proof that the first two items actually have been done, the JavaScript dependency should be _optional_. Can we turn this into action points we _all_ agree on? My personal favorites are (In no strict order): (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. setting states) (2) Document that inline Java Script and mixing declarative and imperative code in one file has its pitfalls in big projects and creates issues for tooling. Explain the difference between pure declarative QML and QMLJS and the impact on tooling. (3) Document that accessing ids from other .qml files without any interface (just relying on the fact that they are in the context) creates hard to maintain QML code. (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML. (5) Write refactoring tools that help to clean up existing code. (6) Fix/cleanup existing demos and examples. (7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects. As a second step the actual work has to be done of course. Kind Regards, Thomas Hartmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On 04/28/2014 10:51 PM, André Pönitz wrote: I am tempted to suggest to reload http://www.classnamer.com/ until it contains Q, M, and L. Don't waste your time. I've checked the source code and found that the first word will never start with a 'Q'. Maybe we should fork it? Christian ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt Contributors' Summit reminder
Hello, This is a reminder for everyone who has contributed to Qt in the past year to request an invite to the Qt Contributors' Summit. The event will be in Berlin, June 10-11th. It's a meeting for Qt contributors and developers. A time to look at where the project is and plan ahead for the future. A face to face meeting of the people who develop and design your favourite cross-platform toolkit. For more information see: http://qt-project.org/groups/qt-contributors-summit-2014/wiki To request an invite use https://www.webropolsurveys.com/S/7CB14527039843C9.par See you in Berlin to talk about where Qt is heading! Best regards, Tero ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Apr 28, 2014, at 8:12 PM, Alan Alpert 4163654...@gmail.com wrote:
On Mon, Apr 28, 2014 at 7:36 AM, Sze Howe Koh szehowe@gmail.com wrote:
On 25 April 2014 18:18, Joerg Bornemann joerg.bornem...@digia.com wrote:
On 25-Apr-14 04:21, Sze Howe Koh wrote:
I consider QML and JavaScript to be different languages. JavaScript
can be embedded into QML to extend QML's capabilities, just like how
it can be embedded into HTML to extend HTML's capabilities.
Yep, I hear people keep repeating the mantra QML is declarative. It's just
QML/JS that isn't. Does that buy us anything tooling-wise? No. Because,
even though this thought is true in essence, in practice you have to use the
JS part.
People throw handwritten QML files full of clever hacks at Qt Creator's
QmlDesigner and wonder why it doesn't fully understand the magic, even
though everything is deemed declarative (== toolable).
To check if I've understood you correctly: You've found that
classifying QML as declarative distorts developers' expectations of
the tools?
Do you think it will help if we rebrand QML as a markup language or
a multi-paradigm language, instead of a declarative language?
One of the original meanings of QML was Qt Markup Language. But markup
implies less interactivity, and multi-paradigm implies that you need
to read several more paragraphs to understand what it is. So while
declarative is not strictly accurate, I feel it captures the spirit
better (for humans, not tools. Tools should treat it as markup, and if
there are any tools reading this I'm sorry to confuse you ;) ).
Some user interface markup languages (e.g. XAML, MXML, HTML) allow
imperative code to be embedded within declarative code.
On 26 April 2014 23:39, André Pönitz apoen...@t-online.de wrote:
On Fri, Apr 25, 2014 at 10:21:04AM +0800, Sze Howe Koh wrote:
On 24 April 2014 00:35, André Pönitz apoen...@t-online.de wrote:
On Wed, Apr 23, 2014 at 10:50:23PM +0800, Sze Howe Koh wrote:
QML is a declarative language
Are you considering sequences of JavaScript statements, especially control
flow statements, as declarative?
Andre'
Of course not. :-)
Right. With the obvious consequence for .qml files containing such.
Within a .qml file, JavaScript is in no way an optional extension of some
declarative QML language. QML and JavaScript are _inseparably_ tied
together in the QML/JS hybrid contents of a .qml file.
A quick grep in qtdeclarative/examples/quick/demos e.g. finds the pattern
'if (' in 30 out of 88 .qml files. All nine examples are affected. And
that's not just an accident, as pure declarative QML features like
ScriptAction, or on{Triggered,Clicked,Loaded,...} handlers _require_
immediate use of JavaScript.
To clarify, I do agree with you that QML is extremely limited without
JavaScript for its intended role in Qt Quick.
It's just that the two of us had applied the label QML to different
parts of the language framework. This is addressed at the bottom of
this email.
I was highlighting the fact that their declarative
structures make QML or HTML+CSS good for describing a GUI's looks.
This is in contrast to imperative languages like C++ or JavaScript or
PHP -- I don't want to use any of these to describe a GUI's looks.
Not wanting to use imperative languages like [...] JavaScript [...] to
describe a GUI's look is fine with me, but how on earth is that an
argument _in favour_ of .qml?
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.
That was not my argument.
My original comment about declarativeness was in response to the
apples-to-oranges comparison between UnrealScript and QML. [1] Marius'
point was (I believe), Epic Games dropped UnrealScript for C++,
therefore we too should stay with C++ instead of moving to QML. I was
trying to say that they aren't comparable because UnrealScript is for
scripting games while QML is for crafting GUIs. I used QML's
declarative nature to justify my position that it is a GUI-crafting
language.
My actual argument in favour for QML was that it lets us express our
intent much more concisely than other languages. This argument was
made while we were on the topic of UI development efficiency, with
Android XML+Java and the Qt Graphics View Framework as the reference
points. [1, 2]
Note also, I contended that Qt Quick can now fully replace the
Graphics View Framework, but is not yet ready to fully replace widgets
[2].
Graphics View wasn't really made for UIs, and for it's intended use
(multi-view MDI CAD programs?) it's still better than QtQuick. Which
was made for UIs, so can replace Graphics View there.
It's the QtQuick Controls module which should fully replace widgets.
But I agree it's not yet ready (and anyone who complains that they'll
still need their C++ widgets
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Tuesday 29. April 2014 07.17.14 Koehne Kai wrote: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org [mailto:development-bounces+kai.koehne=digia@qt-project.org] On Behalf Of Andre Ponitz Sent: Monday, April 28, 2014 11:34 PM To: Alan Alpert Cc: development@qt-project.org Subject: Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future] On Mon, Apr 28, 2014 at 11:12:47AM -0700, Alan Alpert wrote: Yes, I agree that more rigorous and agreed definitions would be helpful. It also takes time, and impedes innovation, so I'm not sure if we're quite mature enough to nail down QML just yet. Should be soon though, in the next few years. To get this straight: After five years of development the Maintainer of the Qt Declarative module is neither able nor willing to give a simple definition of what QML is. Come on Andre, ad hominem attacks do not help. I'd expect better from you as a Maintainer yourself (quotes added on purpose). I agree. For example I decide to invest time into doing something in Qt if for example I had an idea myself and I'm excited about it. If somebody else wants me to fix a bug, then my motivation for sitting down and spending a day or two digging deep into the code base to fix that bug is pride and to some extend guilt: I want our users to enjoy using Qt and if I succeed in relating to the feeling of that user (based on a high quality bug report for example), then I'm compelled to fix it. If somebody else wants me to do something bigger that just a bug fix, then they need to inspire me. If they don't want to do all the work on their own, then they need to create excitement around their idea - they need to lead. In the Qt project - and many other open source projects naturally - the ability to inspire others is crucial in order to move things forward. Unfortunately a substantial amount of emails in this particular email thread do not exactly inspire me. Hence I'm less inclined to contribute. My suggestion is: If you'd like to change Qt in big ways, prepare yourself and your idea, come to the contributor summit, invite people to a discussion and create a movement. Excitement and inspiration is much better to get across in person, when you can see their face, their hands, their gestures and their smile. On to the topic: QML is what the QML parser accepts (that is, JSON like declarative syntax + JavaScript in certain places). No, there's no standard document for it (in case that's what you're after), but it has a well-defined grammar etc. Christian Kamm AFAIR planned a long time ago to add the grammar to the documentation, but I think that never was finished. And, as always, the documentation can be improved ;) The discussion so far was whether it makes sense to give the 'declarative' part alone a separate name (something we haven't done so far). I personally agree with Alan that it doesn't make much sense as long as the two parts are technically and practically inseparable. But I'm personally all for an experiment to come up with a more strict, declarative QML subset. I also like the idea of such an experiment. The fact we parse QML only once and have full control over the JS code generation should make it much easier nowadays to achieve this while preserving semantics at the same time. (Kai's approach is an example of something that inspires me :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Contributors' Summit reminder
Hi, Il 29/04/2014 09:56, Kojo Tero ha scritto: Hello, This is a reminder for everyone who has contributed to Qt in the past year to request an invite to the Qt Contributors’ Summit. When will the invitations be sent? It's only ~40 days before the summit and people would need to ask for leave, organize travels, etc. Thanks, -- Join us Oct 6-8 at BCC Berlin for Qt Developer Days 2014! Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions smime.p7s Description: Firma crittografica S/MIME ___ 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?
Hi Thiago, No, it isn't. The socket notifier activates when there's buffer available in the kernel, not that the buffer is empty. That means something got flushed, but it does not indicate that everything did. I will ask very specifically: what ioctl or fcntl do you need to enable to get the notification? If you don't know the answer to this, I assert that you don't have a tx-empty event. Hmm.. yes, in documentation it so. But actually it event triggered when FIFO is empty. Well, ok, it isn't important, lets skip this issue now.. :) The behaviour of QTcpSocket on all platforms and of QProcess on Unix. Well, thanks a lot. I will take these arguments into account and we will think what to do farther. UPD: Guys, many thanks BR, Denis 2014-04-28 20:25 GMT+04:00 Thiago Macieira thiago.macie...@intel.com: Em seg 28 abr 2014, às 17:04:31, Denis Shienkov escreveu: Hi Thiago, By the way, what is that tx-empty event? E.g., it is an signal of QSocketNotifier::activated(fd) for the Write type of notifier. No, it isn't. The socket notifier activates when there's buffer available in the kernel, not that the buffer is empty. That means something got flushed, but it does not indicate that everything did. I will ask very specifically: what ioctl or fcntl do you need to enable to get the notification? If you don't know the answer to this, I assert that you don't have a tx-empty event. For example, all classes using of the QPipeWriter (QProcess??, QLocalSocket) in Windows implement an true bytesWritten() signal. When the bytesWritten() is emitted after each I/O completion (at least, it got an numbers of transferred bytes after each completion and accumulate it). The Windows behaviour is only that because of either: a) a bug b) the Windows kernel keeps referring to our buffer and we can't completely flush it until we get the completion notification But on other platforms (on *nix) it isn't implemented by a similar method (since in principle there is no asynchronous I/O in *nix). Therefore there bytesWritten() signal is emitted without waiting for the fact of real sending of data. Thus, the same QProcess or QLocalSocket will behave differently on different platforms (I told it already in previous mails). This is the expected behaviour. So, what behavior should I take as basic for the the same as QTcpSocket and QProcess. ? Behavior of QProcess from the Windows platform, or behavior of QProcess from the *nix platform? :) The behaviour of QTcpSocket on all platforms and of QProcess on Unix. For me it is more pleasant, simpler, more logical, to implement a common behavior (for any platform) as in Windows. Because in other case, the bytesWritten() loses the sense; becomes a ballast which doesn't bear the useful sense. That rests on the requirement that the behaviour you want to implement can be implemented. I have not seen any indication so far that it is possible for serial ports, let alone for sockets and pipes. -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Contributors' Summit reminder
Coming right after 1st May. (or maybe even tomorrow, if I can squeeze my schedule) I will keep the registration open, and we will make fast decisions on late requests. Tero -Original Message- From: development-bounces+tero.kojo=digia@qt-project.org [mailto:development-bounces+tero.kojo=digia@qt-project.org] On Behalf Of Giuseppe D'Angelo Sent: 29. huhtikuuta 2014 11:04 To: development@qt-project.org Subject: Re: [Development] Qt Contributors' Summit reminder Hi, Il 29/04/2014 09:56, Kojo Tero ha scritto: Hello, This is a reminder for everyone who has contributed to Qt in the past year to request an invite to the Qt Contributors’ Summit. When will the invitations be sent? It's only ~40 days before the summit and people would need to ask for leave, organize travels, etc. Thanks, -- Join us Oct 6-8 at BCC Berlin for Qt Developer Days 2014! Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Software Engineer KDAB (UK) Ltd., a KDAB Group company Tel. UK +44-1738-450410, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
-Original Message- [...] On to the topic: QML is what the QML parser accepts (that is, JSON like declarative syntax + JavaScript in certain places). No, there's no standard document for it (in case that's what you're after), but it has a well-defined grammar etc. Christian Kamm AFAIR planned a long time ago to add the grammar to the documentation, but I think that never was finished. And, as always, the documentation can be improved ;) https://codereview.qt-project.org/#change,84256 is my humble attempt at it. Regards Kai ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
I don't need invisible inlines either but some of them - such as QModelIndex::row() - are visible. Is there any way to emit just the visible inlines? Dimitar On Monday, April 28, 2014 4:12 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em seg 28 abr 2014, às 11:15:23, Koehne Kai escreveu: -Original Message- From: development-bounces+kai.koehne=digia@qt-project.org Subject: [Development] Qt binaries with inlined functions Hello all, I'd like to start a discussion about .https://bugreports.qt- project.org/browse/QTBUG-32995. Please share your thoughts. To get some numbers I tried to add QMAKE_CXXFLAGS += -fkeep-inline-functions `-fkeep-inline-functions' In C, emit `static' functions that are declared `inline' into the object file, even if the function has been inlined into all of its callers. This switch does not affect functions using the `extern inline' extension in GNU C90. In C++, emit any and all inline functions into the object file. DO NOT pass that flag. There's no need to bloat our binaries with functions that cannot be called (remember, we pass -fvisibility-inlines-hidden). -- 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___ 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?
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). So, means it is possible to divide on main moments for possible I/O implementation for the serial port (the own requirements/specification of I/O behavior): 1) Buffered mode - reading and writing is carried out via the internal buffer of class - data transmission should be postponed and is carried out only on events from a notifier (when the FIFO of driver/device is ready for I/O operation). Similar with the current buffered QTcpSocket implementation... - bytesWritten() signal has to be emitted after an data transmission from the user space to kernel space (i.e. after a successful write(), WriteFile() syscall's). Similar with the any Unix implementation of QTcpSocket, QProcess... - data reading is carried out automatically when FIFO is ready for reading (by event from the read notifier). A data from the FIFO will be read into a internal read buffer of class. Similar with the current buffered QTcpSocket implementation... - the readyRead() signal should be emitted after successfully automatically reading from the FIFO into internal buffer of class. 2) Unbuffered mode - reading and writing is carried out directly to the device, by avoiding of the internal buffer of class - data transmission should be directly by means of calling the ::write(), ::WriteFile() syscalls. Similar with the current unbuffered QTcpSocket implementation... - bytesWritten() signal has to be emitted after an data transmission from the user space to kernel space (i.e. after a successful write(), WriteFile() syscall's). Similar with the any Unix implementation of QTcpSocket, QProcess... - data reading is carried out manually by user, when the FIFO is ready for reading (by the readyRead() signal or something else), by means of calling of the ::read(), ::ReadFile() syscalls. Similar with the current unbuffered QTcpSocket implementation... - the readyRead() signal should be emitted when the FIFO is ready to read. This is expected behavior? PS: I.e. we need to implement the general final option of use case, to adhere to the concrete course. :) BR, Denis 2014-04-28 13:53 GMT+04:00 Carlos Duclos carlosducl...@yahoo.com: 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.
Re: [Development] new Qt5.3 RC snapshot available
This bug still exists in qt-opensource-mac-x64-android-ios-5.3.0-RC_2014-04-29_02-22-23-53.dmg. iOS developing is blocked totally. On Mon, Apr 28, 2014 at 10:20 PM, Yang Fan missd...@gmail.com wrote: Yes, I see the JIRA status, but I tried qt-opensource-mac-x64-android-ios-5.3.0-RC_2014-04-27_10-54-10-50.dmg and all other snapshots later than qt-opensource-mac-x64-android-ios-5.3.0-RC_2014-04-16_06-16-00-40.dmg, this issue still exists. Is there any auto test case to verify this kind of issues on CI? On Mon, Apr 28, 2014 at 10:05 PM, Simon Hausmann simon.hausm...@digia.com wrote: On Monday 28. April 2014 22.01.32 Yang Fan wrote: QTBUG-38526 is not resolved, it should block the release. It's being worked on, as you can see if you look into JIRA. The fix is integrating at this moment. Have you tested it? Simon On Mon, Apr 28, 2014 at 3:51 PM, Heikkinen Jani jani.heikki...@digia.comwrote: Hi all, We have new snapshot available in http://download.qt-project.org/snapshots/qt/5.3/5.3.0-RC/2014-04-28_77/ These packages aren’t yet official RC candidate packages but pretty close so please test these verify your fixes! We are trying to put RC out during this week so please inform me immediately if you find something which Is blocking the release! Qt5 changes in this snapshot: https://codereview.qt-project.org/#change,84082 : Patch Set 2: * qtbase b0d996a...93c6976 (17): Un-export QSignalBlocker: its all inline Fix vcxproj generation on Windows Phone QPrintEngine - Fix alpha engine state sync QSqlError: Mark deprecated functiond with QT_DEPRECATED Cocoa: Make Qt::Tool windows hide on deactivate Android: Add unversioned_libname configuration document new QTPLUGIN magic Android input method fixes for SwiftKey QAbstractSocket: enable read notification for unbuffered sockets Dont crash on broken GIF images Deprecate setSharable in Qt containers QOpenGLFunctions: Compile on Mac OS 10.6 Update the changelog for 5.3.0 Document QStrings UTF-8 conversion behaviors Restore handling of BOMs in QString::fromUtf8 doc fixes deprecate import_qpa_plugin and qpa_minimal_plugin * qtdeclarative a885d10...a1eb134 (4): Getting the render window of an offscreen window V4 regalloc: fix register spill choice under high pressure. Fix crash when loading QML that tries to set non-existent group properties Fix parsing of JS imports from JS files * qtdoc 66ade86...2e30101 (5): Doc: List more platforms on Building from Sources page Doc: Sort Enginio link alphabetically Doc: List Qt Quick Dialogs on the Qt modules page. Doc: Removed the instructions to build from sources Doc: Mention OpenSSL in Qt for Windows requirements * qtenginio c7531f6...0db2d18 (1): Doc: Add QML Todo example to the list of highlighted examples * qtlocation f81aac0...2b7eebe (1): Remove unnecessary private export macro * qtquick1 c56f5d8...96c2c1a (1): Add 5.3 Changelog * qtquickcontrols 80c4404...cdbf664 (1): Correct positioning for popups in QQuickWidget * qtsensors 8a0da79...43e7f32 (1): Add QtSensor changelog for Qt 5.3.0 -- Jani Heikkinen Release Manager Digia Plc Elektroniikkatie 10, FI 90590 Oulu Finland Email: jani.heikki...@digia.com Mobile: +358-504-873-735 Visit us at: www.digia.com | Blog http://blog.digia.com/ | | Twitterhttps://twitter.com/digiaonline| LinkedIn http://www.linkedin.com/company/5119 | YouTubehttp://www.youtube.com/digiaonline| Facebook http://www.facebook.com/digiaonline | -- PRIVACY AND CONFIDENTIALITY NOTICE This message and any attachments are intended only for use by the named addressee and may contain privileged and/or confidential information. If you are not the named addressee you should not disseminate, copy or take any action in reliance on it. If you have received this message in error, please contact the sender immediately and delete the message and any attachments accompanying it. Digia Plc does not accept liability for any corruption, interception, amendment, tampering or viruses occurring to this message. -- ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Regards, Fan Yang -- Regards, Fan Yang ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
On Tuesday 29. April 2014 01.30.24 Dimitar Dobrev wrote: I don't need invisible inlines either but some of them - such as QModelIndex::row() - are visible. Is there any way to emit just the visible inlines? I think the pinvoke approach of creating bindings just won't work reliably with C++ APIs that have inline functions then :( But the ABI promise of Qt remains, so can't you create a library yourself that basically contains the inline functions you need and otherwise references the exported symbols from Qt? Your bindings will need to ship that library, but it should continue to work with newer versions of Qt. (It just needs an update when the inline functions change in a newer Qt version) On Monday, April 28, 2014 4:12 PM, Thiago Macieira [...] `-fkeep-inline-functions' In C, emit `static' functions that are declared `inline' into the object file, even if the function has been inlined into all of its callers. This switch does not affect functions using the `extern inline' extension in GNU C90. In C++, emit any and all inline functions into the object file. DO NOT pass that flag. There's no need to bloat our binaries with functions that cannot be called (remember, we pass -fvisibility-inlines-hidden). Ouch yeah, that makes it a no-go :) Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
Simon, In the description of the issue in JIRA I've pointed out why I don't like the solution with an additional C/C++ wrapper. In short, I would have to compile and pack such a lib for each OS, and then my users would have to deploy that different per OS lib. I'm not sure I understand your answer to my question. Why wouldn't the P/Invoke approach work if I have all necessary symbols? What I'm asking is if there's any way to emit only the exported inlines (for example, by combining -fkeep-inline-functions and -fvisibility-inlines-hidden). This way I would get my symbols and there won't be uncallable functions in the binaries. Dimitar On Tuesday, April 29, 2014 1:03 PM, Simon Hausmann simon.hausm...@digia.com wrote: On Tuesday 29. April 2014 01.30.24 Dimitar Dobrev wrote: I don't need invisible inlines either but some of them - such as QModelIndex::row() - are visible. Is there any way to emit just the visible inlines? I think the pinvoke approach of creating bindings just won't work reliably with C++ APIs that have inline functions then :( But the ABI promise of Qt remains, so can't you create a library yourself that basically contains the inline functions you need and otherwise references the exported symbols from Qt? Your bindings will need to ship that library, but it should continue to work with newer versions of Qt. (It just needs an update when the inline functions change in a newer Qt version) On Monday, April 28, 2014 4:12 PM, Thiago Macieira [...] `-fkeep-inline-functions' In C, emit `static' functions that are declared `inline' into the object file, even if the function has been inlined into all of its callers. This switch does not affect functions using the `extern inline' extension in GNU C90. In C++, emit any and all inline functions into the object file. DO NOT pass that flag. There's no need to bloat our binaries with functions that cannot be called (remember, we pass -fvisibility-inlines-hidden). Ouch yeah, that makes it a no-go :) Simon___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 29 Apr 2014, at 00:39, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 29 abr 2014, às 00:16:43, Jeremy Lainé escreveu: On 04/28/2014 11:44 AM, Nichols Andy wrote: It is possible still in the packaged versions of Qt for iOS to make connections using SSL via QNetworkAccessManager as there is a backend that uses Apples crypto API, but without OpenSSL support you can’t use any of the API’s in Qt that use OpenSSL directly (like QSSLSocket). Ouch I just realised that most likely means QWebSocket on iOS does not support secure websockets! What would the best course of action be to add support for secure websockets on iOS? Probably to add a new QSslSocket backend that uses the Apple API. QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make sure you are aware of the scope of the project and remember you have to maintain it :) Another option is to skip QSslSocket and implement a direct backend for QWebSocket using a native API, for example the SocketRocket project. I used this approach to implement an iOS backend for the QNAM rest API (using NSurlConnection). Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
On Tuesday 29 April 2014, Dimitar Dobrev wrote: I don't need invisible inlines either but some of them - such as QModelIndex::row() - are visible. Is there any way to emit just the visible inlines? Shouldn't be needed they are emitted by default. Only static inlines are omitted from the final binary. Note that you need to mark the methods exported due to -fvisibility-inlines-hidden (or remove that flag from your build). Regards `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
They are not emitted. I've opened QtCore with http://www.dependencywalker.com/ and the only symbols I can see for QModelIndex are: _ZNK11QModelIndex4dataEi _ZNK11QModelIndex5childEii _ZNK11QModelIndex5flagsEv _ZNK11QModelIndex6parentEv _ZNK11QModelIndex7isValidEv _ZNK11QModelIndex7siblingEii _ZNK11QModelIndexeqERKS_ _ZNK11QModelIndexltERKS_ _ZNK11QModelIndexneERKS_ Members such as row() or column() are missing. I don't know about other OS-es but on Windows these are all symbols for that class. Dimitar On Tuesday, April 29, 2014 2:17 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Tuesday 29 April 2014, Dimitar Dobrev wrote: I don't need invisible inlines either but some of them - such as QModelIndex::row() - are visible. Is there any way to emit just the visible inlines? Shouldn't be needed they are emitted by default. Only static inlines are omitted from the final binary. Note that you need to mark the methods exported due to -fvisibility-inlines-hidden (or remove that flag from your build). Regards `Allan___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 29 April 2014 12:13, Sorvig Morten morten.sor...@digia.com wrote: What would the best course of action be to add support for secure websockets on iOS? Probably to add a new QSslSocket backend that uses the Apple API. QSSLSocket/QSslCertificate/QSslCipher is a relatively large API - make sure you are aware of the scope of the project and remember you have to maintain it :) I actually started thinking about how a smaller API for some of this could look. Basically with the idea being that for many applications only a subset of the full QSslXX apis mattered. If you want me to post my notes (such as they are) then I'm happy to do so. Another option is to skip QSslSocket and implement a direct backend for QWebSocket using a native API, for example the SocketRocket project. I'm not sure that the design of the QWebSocket module really allows this kind of plugability. Perhaps Kurt can comment? Cheers Rich. I used this approach to implement an iOS backend for the QNAM rest API (using NSurlConnection). Morten ___ 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] Qt binaries with inlined functions
On Tuesday 29 April 2014, Dimitar Dobrev wrote: They are not emitted. I've opened QtCore with http://www.dependencywalker.com/ and the only symbols I can see for QModelIndex are: _ZNK11QModelIndex4dataEi _ZNK11QModelIndex5childEii _ZNK11QModelIndex5flagsEv _ZNK11QModelIndex6parentEv _ZNK11QModelIndex7isValidEv _ZNK11QModelIndex7siblingEii _ZNK11QModelIndexeqERKS_ _ZNK11QModelIndexltERKS_ _ZNK11QModelIndexneERKS_ Interesting. Note that all of those methods are also inline, so you have some inlines but not others. Have you tried without -fvisibility-inlines-hidden? (which marks normally visible inline methods invisible unless explicitly declared exported). Regards `Allan ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
Allan, I'm not talking about a custom build at all. This whole discussion I started is about how to avoid one. The results you see I've obtained from the Qt 5.2.1 MinGW binaries as downloaded from qt-project.org. On Tuesday, April 29, 2014 2:43 PM, Allan Sandfeld Jensen k...@carewolf.com wrote: On Tuesday 29 April 2014, Dimitar Dobrev wrote: They are not emitted. I've opened QtCore with http://www.dependencywalker.com/ and the only symbols I can see for QModelIndex are: _ZNK11QModelIndex4dataEi _ZNK11QModelIndex5childEii _ZNK11QModelIndex5flagsEv _ZNK11QModelIndex6parentEv _ZNK11QModelIndex7isValidEv _ZNK11QModelIndex7siblingEii _ZNK11QModelIndexeqERKS_ _ZNK11QModelIndexltERKS_ _ZNK11QModelIndexneERKS_ Interesting. Note that all of those methods are also inline, so you have some inlines but not others. Have you tried without -fvisibility-inlines-hidden? (which marks normally visible inline methods invisible unless explicitly declared exported). Regards `Allan___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] No SSL on iOS ?
On 29 Apr 2014, at 13:31, Richard Moore r...@kde.org wrote: I actually started thinking about how a smaller API for some of this could look. Basically with the idea being that for many applications only a subset of the full QSslXX apis mattered. If you want me to post my notes (such as they are) then I'm happy to do so. Please do. A specific question: Currently QNetworkAccessManager::sslErrors() is not implemented on iOS. How much of QSslError/QSslCertificate do we need for it to be usable? Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
Thomas Tero: There is no way that I can make it to the contributors summit, but Thomas' message might be a important discussion pience when you arrive in Berlin. Related to points 5,6,7 of Thomas' message Below: Is there a class diagram on the current code base? This would help newbies when trying to contribute to the refactoring strategy. The code supporting the QML, JS, and C++ must be layered and sensibly separated so that people can opt-in on various parts at compile/link time. When respected people like Thiago Macieira put forth the idea that there is no public API at the C++ level for Scene Graph and other QML locked in design pieces, that does not smell right. Where are the unit tests and test benches for the Qt code base? I have not seen a script that runs the test bench/unit tests for this large QT code base. Anybody have insights on that? Thanks, Marco On 4/28/2014 3:26 AM, Thiago Macieira wrote: Em seg 28 abr 2014, às 08:33:23, Peter Kümmel escreveu: 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? Maybe a translation from QML to a .ui file could be a first step? That could work if you use QtWidgets in the QML file. I think we should start on top of the C/C++ part of current QMLv2 stack (if such a thing exists), with some handwritten widget code. Otherwise we have a QPainter based system which we already have with QWidgets. Forget about QPainter. Your first step, it seems to me, would be to add the necessary C++ public API to QtQml so you can instantiate new items in the QML graph, then manipulate their properties and bindings, as well as set new JavaScript code and expressions. This simply replaces the QML parser, keeping all the benefits (and problems) of the QML language. In particular, it does not extricate the JS interpreter and engine. If you want to extricate the JS engine, you probably need to move the Scene Graph classes out of QtQuick and into a module that depends only on QtGui, bypassing the QtQml dependency. You'll need a way to insert generic items into the graph. But, at this point, I question: why don't you just use an existing OpenGL scene graph, like Ogle3D? Once you've got the base API, you can start thinking of writing widgets again, the platform look and feel. If the QtQml dependency was maintained, it might be possible to reuse the code from Qt Quick Components. If not, you'll probably need to start from scratch. On 4/29/2014 3:43 AM, Hartmann Thomas wrote: Hi, On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz apoen...@t-online.de wrote: I think at least three modifications are inavoidable: For one, things that could be written in a declarative way but which currently are only possible using JavaScript, a declarative way should be added. Second, it should be stressed in the documentation (including the examples), that using inline imperative code is naughty. This can be supported by e.g. the QML Designer refusing to operate on such files. People can still do that, but would be on their own. And finally, and that's also acting as a proof that the first two items actually have been done, the JavaScript dependency should be _optional_. Can we turn this into action points we _all_ agree on? My personal favorites are (In no strict order): (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. setting states) (2) Document that inline Java Script and mixing declarative and imperative code in one file has its pitfalls in big projects and creates issues for tooling. Explain the difference between pure declarative QML and QMLJS and the impact on tooling. (3) Document that accessing ids from other .qml files without any interface (just relying on the fact that they are in the context) creates hard to maintain QML code. (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML. (5) Write refactoring tools that help to clean up existing code. (6) Fix/cleanup existing demos and examples. (7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects. As a second step the actual work has to be done of course. Kind Regards, Thomas Hartmann ___ 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] [QIODevice]How to correctly treat/understand of the documentation?
Em ter 29 abr 2014, às 12:48:55, Denis Shienkov escreveu: This is expected behavior? Yes. Except that you're referring to non-existent unbuffered modes of QTcpSocket and QProcess... -- 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] Qt binaries with inlined functions
Em ter 29 abr 2014, às 01:30:24, Dimitar Dobrev escreveu: I don't need invisible inlines either but some of them - such as QModelIndex::row() - are visible. Is there any way to emit just the visible inlines? Still hidden: $ readelf -Ws --dyn-syms libQt5Core.so.5 | c++filt| grep QModelIndex::row 14630: 0028bdf616 FUNCLOCAL HIDDEN12 QModelIndex::row() const -- 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?
2014-04-29 19:13 GMT+04:00 Denis Shienkov denis.shien...@gmail.com: Yes. Except that you're referring to non-existent unbuffered modes of QTcpSocket and QProcess... Ok, then what is it This code is for the new Unbuffered QTcpSocket use case? https://qt.gitorious.org/qt/qtbase/source/eb211d74cc3dbf991093ad2e799370f006de8198:src/network/socket/qabstractsocket.cpp#L2453 :) BR, Denis 2014-04-29 18:52 GMT+04:00 Thiago Macieira thiago.macie...@intel.com: Em ter 29 abr 2014, às 12:48:55, Denis Shienkov escreveu: This is expected behavior? Yes. Except that you're referring to non-existent unbuffered modes of QTcpSocket and QProcess... -- 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 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
Em ter 29 abr 2014, às 13:43:00, Allan Sandfeld Jensen escreveu: On Tuesday 29 April 2014, Dimitar Dobrev wrote: They are not emitted. I've opened QtCore with http://www.dependencywalker.com/ and the only symbols I can see for QModelIndex are: _ZNK11QModelIndex4dataEi _ZNK11QModelIndex5childEii _ZNK11QModelIndex5flagsEv _ZNK11QModelIndex6parentEv _ZNK11QModelIndex7isValidEv _ZNK11QModelIndex7siblingEii _ZNK11QModelIndexeqERKS_ _ZNK11QModelIndexltERKS_ _ZNK11QModelIndexneERKS_ Interesting. Note that all of those methods are also inline, so you have some inlines but not others. Have you tried without -fvisibility-inlines-hidden? (which marks normally visible inline methods invisible unless explicitly declared exported). Inline functions that aren't used won't be emitted either. You need to *use* all of them. -- 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] Qt binaries with inlined functions
Em ter 29 abr 2014, às 04:45:37, Dimitar Dobrev escreveu: Allan, I'm not talking about a custom build at all. This whole discussion I started is about how to avoid one. The results you see I've obtained from the Qt 5.2.1 MinGW binaries as downloaded from qt-project.org. There won't be a change to the way we build. We're already doing it the right way. -- 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] Qt binaries with inlined functions
I understand. Thank you all for your time. Kai, I think you can close the issue as Won't Fix. Regards, Dimitar Dobrev On Tuesday, April 29, 2014 6:24 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 29 abr 2014, às 04:45:37, Dimitar Dobrev escreveu: Allan, I'm not talking about a custom build at all. This whole discussion I started is about how to avoid one. The results you see I've obtained from the Qt 5.2.1 MinGW binaries as downloaded from qt-project.org. There won't be a change to the way we build. We're already doing it the right way. -- 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___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On 29 Apr 2014, at 3:34 PM, m...@rpzdesign.com wrote: Is there a class diagram on the current code base? You can run doxygen on it and get the automatically-generated ones, but AFAIK there has never been any emphasis on doing internal documentation, only user-facing documentation. I don't know all the reasons why. For one thing we don't have an agreement on where to put hand-created internal docs in the git tree. Probably nobody wants to put a lot of time into doing it by hand anyway, and it would tend to stay out of date unless it was automatically generated. From experience I can say that they aren't quite as useful for everyday reference as you would think, unless they are integrated into your workflow interactively instead of just being a static diagram that you hang on the wall (even if you could find a big enough sheet of paper for a Qt class diagram). And diagrams generated by static code analysis don't show all the object relationships that will exist at runtime. It could be introspected at runtime though. Doxygen is good at generating class diagrams, but we can't use it for all docs because there has been so much divergence in the feature sets that doxygen cannot generate our user docs. But generating class diagrams automatically with some kind of tool (probably built on dot the way doxygen does it) ought to be doable. (And then where would we put them…) One big diagram would be too complex, but Doxygen does a good job of using just the relevant subtree on each doc page and letting you click to navigate docs. Another idea is maybe Creator could have dynamically generated diagrams which can be used to navigate the code, the way you can do in Eclipse. But a prerequisite would be better support for diagramming applications in Qt Quick 2. That's one of my long-term background tasks: it would be a good start to be able to draw connected-node diagrams by hand. (But that in turn depends on having a proper path element.) Automating it should then be doable too. This would help newbies when trying to contribute to the refactoring strategy. The code supporting the QML, JS, and C++ must be layered and sensibly separated so that people can opt-in on various parts at compile/link time. I would like that too; at least the scene graph should be separable from Qt Quick so that other language bindings become possible. The usual answers I've heard to that proposal are 1) the scene graph is documented public API (it's just that there is no way to link it without the JS engine and the rest of QtQuick) http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html 2) https://codereview.qt-project.org/#change,52682 will break that link to make a standalone scene graph (but the patch is out of date and doesn't apply cleanly nowadays). It has been claimed the patch can't be integrated because it's incompatible with building the whole integrated Qt the way we usually ship it. But I hope we get to a point where it can be. 3) you would lose so much functionality that it becomes uninteresting, or at least you have to redo a lot of work as part of the other language binding. Much functionality is implemented in the Qt Quick objects: input event handling (including gestures, since we don't have a centralized gesture recognition), bindings, animation etc. At the same time, if you intend to get rid of baggage, you cannot do without the qtcore and qtgui modules, even if your application doesn't need big parts of it. But qtgui gives you cross-platform windows and opengl and events, you just have to decide all over again what to do with the events (and from experience, this is tricky to say the least) Nevertheless, I still think it ought to be possible to build the scene graph without QtQuick, just for what it's worth. Trying to refactor and separate modules at other points to depend less on JavaScript will run into these issues: 1) the JS engine would get loaded into memory anyway, because QtQuick increasingly depends on the JS object model. 2) we value the efficiencies to be gained by tight coupling. JS objects are more efficient than QObjects and QVariants, so we expect the coupling to become tighter rather than looser. 3) QML and Quick implementation details are private so they can be free to evolve But can we separate the object model from the interpreter, and make a nice C++ API for that? I don't know, but it seems daunting, and doing it too early would limit the evolution too much. Anyway the hypothetical API would only give you a base on which to build applications (or alternative language bindings) in verbose C++ instead of clean-looking QML, and some useful functionality would be left behind. (disclaimer: much of the above is personal opinion and speculation about which others will disagree) When respected people like Thiago Macieira put forth the idea that there is no public API at the C++ level for Scene Graph and
Re: [Development] [QIODevice]How to correctly treat/understand of the documentation?
Em ter 29 abr 2014, às 19:16:51, Denis Shienkov escreveu: Yes. Except that you're referring to non-existent unbuffered modes of QTcpSocket and QProcess... Ok, then what is it This code is for the new Unbuffered QTcpSocket use case? https://qt.gitorious.org/qt/qtbase/source/eb211d74cc3dbf991093ad2e799370f0 06de8198:src/network/socket/qabstractsocket.cpp#L2453 It's not public API. It exists solely for QNAM and comes with the warning here there be dragons. :-) -- 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] Qt binaries with inlined functions
On Monday 28 April 2014 05:37:40 Dimitar Dobrev wrote: snip My problem (and, I'd say, any binding developer's) is that I can't tell users my binding is great, you just need to compile Qt yourselves because the binary downloads don't work well enough - nobody's going to use it. But whoever is going to use your bindings will also have to download some binary for the bindings, right? So why don't you add the missing functions in a wrapper there and compile it alongside your bindings? I.e. what Simon said: But the ABI promise of Qt remains, so can't you create a library yourself that basically contains the inline functions you need and otherwise references the exported symbols from Qt? Your bindings will need to ship that library, but it should continue to work with newer versions of Qt. (It just needs an update when the inline functions change in a newer Qt version) Why does this not work for you? Note that you could even make such a wrapper library official and share it with other bindings. Maybe it could even become an official Qt module! Then eventually consumers of bindings people would just need to download the additional binding-wrapper libraries and everything works as it should? Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
I'm not sure I understand your idea about compiling alongside. The binding is C# so I'd have to either use C++/CLI or translate the body of the inline to C# and compile that. The former works only for Windows, the latter is too much work - essentially a C++ to C# converter. What is your suggestion? Sharing with other bindings - now that's a great idea! I hadn't actually thought of the fact that such a wrapper is the same for any binding. If that could become a Qt module as you suggest, and presented as a binary download at qt-project.org, that would be great. Do you know of a tool that can generate such wrappers? The wrapper I used to make with my own code wasn't complete and when I tried to complete it, it proved quite a time-consuming task and I gave up for the time being. I've searched for such tools which I imagine should exist but I was unable to find any. On Tuesday, April 29, 2014 6:55 PM, Milian Wolff milian.wo...@kdab.com wrote: On Monday 28 April 2014 05:37:40 Dimitar Dobrev wrote: snip My problem (and, I'd say, any binding developer's) is that I can't tell users my binding is great, you just need to compile Qt yourselves because the binary downloads don't work well enough - nobody's going to use it. But whoever is going to use your bindings will also have to download some binary for the bindings, right? So why don't you add the missing functions in a wrapper there and compile it alongside your bindings? I.e. what Simon said: But the ABI promise of Qt remains, so can't you create a library yourself that basically contains the inline functions you need and otherwise references the exported symbols from Qt? Your bindings will need to ship that library, but it should continue to work with newer versions of Qt. (It just needs an update when the inline functions change in a newer Qt version) Why does this not work for you? Note that you could even make such a wrapper library official and share it with other bindings. Maybe it could even become an official Qt module! Then eventually consumers of bindings people would just need to download the additional binding-wrapper libraries and everything works as it should? Bye -- Qt Developer Days 2014 - October 6 - 8 at BCC, Berlin Milian Wolff | milian.wo...@kdab.com | Software Engineer KDAB (Deutschland) GmbHCo KG, a KDAB Group company Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ 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] No SSL on iOS ?
On 04/29/2014 02:39 PM, Sorvig Morten wrote: This aproach looks promising. If we can get basic QSslSocket working (enough for say QNAM and QWebSocket) then retiring the NSUrlConnection backend and focusing on QSslSocket is a possibility. OK I have moved my proof of concept code here: https://github.com/jlaine/qsslsocketios I provided a demo app : a very naive HTTPS client which fetches https://www.google.com and dumps it to standard out. You can run this on any OSX machine with Qt installed. I'll start looking how hard it would be to actually integrate this into qtbase. Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
Em ter 29 abr 2014, às 09:10:39, Dimitar Dobrev escreveu: Sharing with other bindings - now that's a great idea! I hadn't actually thought of the fact that such a wrapper is the same for any binding. If that could become a Qt module as you suggest, and presented as a binary download at qt-project.org, that would be great. Do you know of a tool that can generate such wrappers? Have you tried Smoke? Or the parser that PySide uses? -- 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] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Tue, Apr 29, 2014 at 07:43:09AM +, Hartmann Thomas wrote: I think at least three modifications are inavoidable: For one, things that could be written in a declarative way but which currently are only possible using JavaScript, a declarative way should be added. Second, it should be stressed in the documentation (including the examples), that using inline imperative code is naughty. This can be supported by e.g. the QML Designer refusing to operate on such files. People can still do that, but would be on their own. And finally, and that's also acting as a proof that the first two items actually have been done, the JavaScript dependency should be _optional_. Can we turn this into action points we _all_ agree on? My personal favorites are (In no strict order): (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. setting states) (2) Document that inline Java Script and mixing declarative and imperative code in one file has its pitfalls in big projects and creates issues for tooling. Explain the difference between pure declarative QML and QMLJS and the impact on tooling. (3) Document that accessing ids from other .qml files without any interface (just relying on the fact that they are in the context) creates hard to maintain QML code. (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML. (5) Write refactoring tools that help to clean up existing code. (6) Fix/cleanup existing demos and examples. (7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects. Looks good, and realistic. Andre' ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]
On Tue, Apr 29, 2014 at 12:43 AM, Hartmann Thomas thomas.hartm...@digia.com wrote: Hi, On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz apoen...@t-online.de wrote: I think at least three modifications are inavoidable: For one, things that could be written in a declarative way but which currently are only possible using JavaScript, a declarative way should be added. Second, it should be stressed in the documentation (including the examples), that using inline imperative code is naughty. This can be supported by e.g. the QML Designer refusing to operate on such files. People can still do that, but would be on their own. And finally, and that's also acting as a proof that the first two items actually have been done, the JavaScript dependency should be _optional_. Can we turn this into action points we _all_ agree on? My personal favorites are (In no strict order): (1) Identify non declarative parts of Qt Quick and add declarative API (e.g. setting states) Agreed. This is my personal favorite ;) . (2) Document that inline Java Script and mixing declarative and imperative code in one file has its pitfalls in big projects and creates issues for tooling. Explain the difference between pure declarative QML and QMLJS and the impact on tooling. Agreed. While I think that mixing declarative and imperative code in one file has it's advantages in small projects, there should be a clear line between pure declarative and toolable vs you're on your own. I'd like to see something like .pragma declarative which defines this line, such that if you add .pragma declarative un-toolable JS blocks or bindings become compile errors. (3) Document that accessing ids from other .qml files without any interface (just relying on the fact that they are in the context) creates hard to maintain QML code. Agreed (honestly, it should already be there, I guess https://bugreports.qt-project.org/browse/QTBUG-20453 was never finished...). Again, we have some rough plans for a .pragma strict. Which should ban this. (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML. Agreed, see .pragma strict comments. Speaking of which, this idea has been around for a while: https://bugreports.qt-project.org/browse/QTBUG-30069 (5) Write refactoring tools that help to clean up existing code. Kinda agree. If we have the two .pragma's mentioned then this is purely a convenience step (because they can find all cases by using the .pragmas). It's probably not worth writing a full refactoring tool that can turn anything into a .pragma declarative/strict file. Just do what's convenient to tool and users can do the rest (if they wish). (6) Fix/cleanup existing demos and examples. Agreed. This is probably a good step to do in conjunction with (1), so as to ensure that the added declarative APIs make sense. In most cases, the added declarative APIs should make more sense even for the primitive (non-tool) users and we can verify it here. (7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects. Agreed. Known issues: https://bugreports.qt-project.org/browse/QTBUG-33233 https://bugreports.qt-project.org/browse/QTBUG-23052 https://bugreports.qt-project.org/browse/QTBUG-19212 Can't find task: More powerful QJSEngine API so that C++ value-type-like objects can be exposed as JS objects when you want more control at the cost of convenience https://bugreports.qt-project.org/browse/QTBUG-21844 (in conjunction with above) But there's probably some additional research to be done too. As a second step the actual work has to be done of course. Yeah, that's always the biggest issue... Every time these discussions come up there's no major theoretical point of contention. It's just that the work still hasn't been done and we all like arguing. -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
I actually use https://github.com/mono/CppSharp . It has a parser and so on but what I was asking for is a tool for generating wrappers. What I've been doing so far is: get each inlined function - get where it's invoked - include the header of the latter in a source file - compile that with -fkeep-inline-functions. Obviously this only works for inlines that happen to be invoked within the same module and is therefore not good. The proper way I am aware of to get all inlines is to generate functions that call them and compile the result. This latter approach turned out more time consuming than I had thought and that's why I've been searching for a tool to generate those functions. Dimitar On Tuesday, April 29, 2014 8:42 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 29 abr 2014, às 09:10:39, Dimitar Dobrev escreveu: Sharing with other bindings - now that's a great idea! I hadn't actually thought of the fact that such a wrapper is the same for any binding. If that could become a Qt module as you suggest, and presented as a binary download at qt-project.org, that would be great. Do you know of a tool that can generate such wrappers? Have you tried Smoke? Or the parser that PySide uses? -- 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___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt binaries with inlined functions
Em ter 29 abr 2014 08:08:35 você escreveu:
Thiago,
Thanks for that piece. I am not that familiar with such details of C++ so
could you please explain why the function is public but compiled with
hidden symbols?
[with permission to reply to the list]
There are two things here at stake: 1) inline functions; 2) hidden symbols.
Inline functions are part of the C++ language; deciding how to inline
functions and how to export symbols is part of the specific ABI. I'm replying
referring to the portable C++ ABI, a.k.a. the IA-64 C++ ABI. MSVC behaves
similarly for most aspecs, but not totally. It's got some violations of the
C++ language due to the way it does inlining, so I'm going to ignore it and
hope its ABI dies (which won't happen).
On Tuesday, April 29, 2014 6:03 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
Still hidden:
$ readelf -Ws --dyn-syms libQt5Core.so.5 | c++filt| grep QModelIndex::row
14630: 0028bdf616 FUNCLOCAL HIDDEN12 QModelIndex::row()
const
By the way, on the above, note that it matched the symbol in the static
symbol table, not the dynamic one:
$ readelf -W --dyn-syms libQt5Core.so | c++filt| grep QModelIndex::row
$ readelf -W --syms libQt5Core.so | c++filt| grep QModelIndex::row
14630: 0028bdf616 FUNCLOCAL HIDDEN12 QModelIndex::row()
const
The static symbol table is stripped from the library by the /usr/bin/strip
command along with debug symbols; the dynamic symbol table stays there.
=== Inlines ===
A function is inline if it's either declared with the inline keyword or if
its body is inside the class/struct/union body.
A function gets *inlined* if the compiler thinks it's good idea. Any function
whose body is visible at compilation time can be inlined, even functions that
aren't inline. What's more, functions marked inline may not get inlined if
the compiler doesn't think it's a good idea. In particular, without
optimisations (-O0, but also with -fno-inline), no functions are inlined.
So the question is: how does the compiler resolve that issue?
A symbol for each function that is *not* inline must always be emitted. If I
have my sources as:
void f() { somethingElse(); }
void g() { f();}
The smart compiler will realise f() simply calls somethingElse() and will
inline it in g()'s body. However, since the function was not declared as
inline, the compiler will generate a full function f() and emit its symbol.
However, if the function is declared inline, the compiler need not emit it:
inline void f() { somethingElse(); }
void g() { f();}
If you inspect the .o file, you're going to see g(), but no f() for the above.
Now suppose that the compiler decides not to inline that inline function
above, what will it do? A good example is QString's constructor: it's inline
from qstring.h and almost every single .cpp will call it.
Here's the interesting thing: the compiler must *always* emit the required
code of all inline functions it used. It cannot assume that another .o will
provide it. But we don't want to bloat the binary because of that.
The compiler will emit the function f() but it will mark it as merge at link
time (nm shows it with type V). That way, all out-of-line copies of inline
functions get merged at link-time.
What's more, the dynamic linker does the same again: if two functions have the
same name, the dynamic linker will resolve to only one of the copies. That
allows us to take address of functions in two different ELF modules and still
compare equally.
=== Visibility ===
Now enter visibility. There are four visibility types in ELF: default,
protected, hidden, internal. Mach-O has two visibility types: default and
hidden. COFF-PE has three: dllimport, dllexport (protected) and none
(hidden). There's no direct equivalent to dllimport (it's similar to
default but not entirely). The types default and protected are visible:
other modules can see the symbol and link to them; types hidden and internal
are invisible: other modules do not see them at all.
When we're compiling statically, visibility does not apply. That means all the
Q_LIBNAME_EXPORT macros expand to empty, on all platforms.
When we're compiling dynamically, we switch between Q_DECL_EXPORT (dllexport,
default or protected) and Q_DECL_IMPORT (dllimport or default). Q_DECL_EXPORT
is used when we're compiling the library that should contain the symbol,
whereas Q_DECL_IMPORT should be used when just using the symbol from another
library. The names should be self-explanatory.
We use visibility to control what symbols get exported for other libraries to
see. We do not export private symbols and internal classes. This decreases
dramatically the symbol table in Qt, allowing for faster link times and load
times.
=== Visibility of inlines ===
The C++ standard requires the each function be defined only once. It's illegal
(undefined behaviour) for a function to have two
Re: [Development] Qt binaries with inlined functions
Em ter 29 abr 2014, às 08:06:37, Thiago Macieira escreveu: Em ter 29 abr 2014, às 04:45:37, Dimitar Dobrev escreveu: Allan, I'm not talking about a custom build at all. This whole discussion I started is about how to avoid one. The results you see I've obtained from the Qt 5.2.1 MinGW binaries as downloaded from qt-project.org. There won't be a change to the way we build. We're already doing it the right way. Here's also why we can't use -fkeep-inline-functions: $ cat main.cpp #include utility #include algorithm #include vector $ g++ -O3 -S -o - main.cpp .file .ident GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388] .section.note.GNU-stack,,@progbits $ g++ -O3 -fkeep-inline-functions -S -o - main.cpp | wc -l 2086 This would keep every single, minor and helper inline function from the Standard Library. We can't do that. On Windows, however, we could use the -fkeep-inline-dllexport, which would make GCC match MSVC behaviour, at the cost of bloating the libraries with code that is never called. I'd rather we didn't do it. -- 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] Qt binaries with inlined functions
Thiago, thank you very much for these explanations. About that option, it only works on Windows so it's no good either way. About generating wrappers for inlines, if you know of a tool that can do that - as I mentioned earlier - it would be of great help to me. On Tuesday, April 29, 2014 10:33 PM, Thiago Macieira thiago.macie...@intel.com wrote: Em ter 29 abr 2014, às 08:06:37, Thiago Macieira escreveu: Em ter 29 abr 2014, às 04:45:37, Dimitar Dobrev escreveu: Allan, I'm not talking about a custom build at all. This whole discussion I started is about how to avoid one. The results you see I've obtained from the Qt 5.2.1 MinGW binaries as downloaded from qt-project.org. There won't be a change to the way we build. We're already doing it the right way. Here's also why we can't use -fkeep-inline-functions: $ cat main.cpp #include utility #include algorithm #include vector $ g++ -O3 -S -o - main.cpp .file .ident GCC: (SUSE Linux) 4.8.1 20130909 [gcc-4_8-branch revision 202388] .section .note.GNU-stack,,@progbits $ g++ -O3 -fkeep-inline-functions -S -o - main.cpp | wc -l 2086 This would keep every single, minor and helper inline function from the Standard Library. We can't do that. On Windows, however, we could use the -fkeep-inline-dllexport, which would make GCC match MSVC behaviour, at the cost of bloating the libraries with code that is never called. I'd rather we didn't do it. -- 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___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] GridView
I get strange scrolling behavior with QML's GridView on OSX with with a touchpad doing the typical two finger scrolling gesture. Click drag seems to be doing what two finger click drag should be. Is this a bug or am I missing a step? Also I have a large data base (orm) of image assets that I display in the grid view and get periodic updates from the server with ‘windows’ of data about 1000 items long. Any tips on segmenting ListModels to allow for continuos scrolling of large datasets like this? Is it safe to just let the y displacement accumulate to very large numbers? Thanks, j ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] NO effect setAttribute(Qt::WA_X11NetWmWindowTypeDock, true) for Qt5?
Hi Qt developers, I migrated qtpanel from Qt4 to Qt5 but setAttribute(Qt::WA_X11NetWmWindowTypeDock, true) has NO effect for Qt5 https://github.com/xiangzhai/qtpanel/blob/master/panelwindow.cpp#L138 qtpanel-qt4 snapshot https://www.dropbox.com/s/nwebtd03fy4sght/qtpanel-qt4.png BUT qtpanel-qt5 https://www.dropbox.com/s/dxt7z5ya26fr6ss/qtpanel-qt5.png I need to setWindowFlags(Qt::FramelessWindowHint | Qt::CustomizeWindowHint) to act like a dock for Qt5? but there is no need for Qt4. Please someone give me some advice, thanks a lot! Regards, Leslie Zhai xiang.z...@i-soft.com.cn ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
