Re: [Development] How to run Qt's auto-tests?
> What's the procedure for building and running Qt's auto-tests? I've > tried: > See Sergio's response. Note that 'make check' will stop at the first failure, and the QtNetwork tests require a test server to be set up. See here: https://qt.gitorious.org/qtqa/sysadmin/blobs/master/README.network_test_server.txt Alternatively you can skip the QtNetwork tests and the few QFile related tests that use this server if you not working on this part of the code. > > Also, can I configure + build the base libraries using "-nomake tests", > then just build + run the subset of tests that I'm interested in? > Yes you can - run qmake / make / make check in a subdirectory (e.g. tests/auto/network to run only the QtNetwork tests) This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QNetworkRequest: allow overriding connect host
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Justin Karneges > Sent: 10 May 2013 00:44 > To: development@qt-project.org > Subject: [Development] QNetworkRequest: allow overriding connect host > > Hi people, > > I discussed this feature with Shane and went ahead and made a patch. > Hi Justin, I meant to discuss the feature API on the mailing list. If your patch is ready for review, you should submit it to the gerrit code review site. See instructions here: http://qt-project.org/wiki/Setting-up-Gerrit -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QNetworkRequest: allow overriding connect host
> QHostInfo has a short-lived cache, so it should work. Yes, but relying on implementation details isn't a good idea. I thought the proposed feature could be more generally useful, for example using test live servers that are configured exactly as the live server so they have a DNS address not matching the SSL certificate. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version
Hi Tony, Thanks for working on this. I found some issues so far: You didn't add a bootstrap script for ubuntu 12.04 When using the 10.04 script, the file /etc/apt/sources.list.d/bootstrap-puppet.list is invalid, causing the script to abort. When using the 11.10 script, it fills the log with "Skipping because of failed dependencies", and "Could not evaluate: Could not retrieve information from environment production source(s)" README.network_test_server.txt needs to be updated too. The existing scripts have not worked for setting up network test server since the move from Nokia to Digia, so some of the failures may be due to this pre-existing problem. -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Sarajärvi Tony Sent: 24 April 2013 13:33 To: development@qt-project.org Subject: [Development] Network test server for Ubuntu 12.04 x64 available for Puppet - test version Hi For all you who have tried to install a network test server: a Puppet configuration for Ubuntu 12.04 x64 is now available. It's still in my personal Gitorious branch, as it still needs testing before pushed through to production. Also I will flag these 12.04 changes so that we still have the 10.04 configuration left there. All qtbase networkselftests passed with this, but there might still be something I missed in the configuration. Tomorrow I'll reinstall a server from scratch using this myself to see what I might have missed. https://qt.gitorious.org/~tosaraja/qtqa/tosarajas-sysadmin-nts Send any feedback straight to me :) Good luck! -Tony Tony Sarajärvi Senior Software Designer Digia, Qt Digia Plc Elektroniikkatie 10 FI-90590 Oulu Email: tony.saraja...@digia.com<mailto:tony.saraja...@digia.com> IRC: freenode - #qt-qa Mobile: +358 050 482 1416 http://qt.digia.com Qt Blog: http://blog.qt.digia.com/ Qt Facebook: www.facebook.com/qtcommercial<http://www.facebook.com/qtcommercial> Qt Twitter: www.twitter.com/qtcommercial<http://www.twitter.com/qtcommercial> -- 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. -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting a Minimum Support OpenSSL Version
> 1) We could say we'll set the minimum to the version macos bundles. If we don't support it, then people will need to include openssl with their application on Mac OS, in the same way they do on Windows. My (weak) understanding of Mac packaging is that the libraries should ideally be included in the app bundle. Unless Qt is configured with -openssl-linked, then the dependency is invisible to packaging tools, so it would need to be added manually by the app developer. Also we may need to do something with Qt's search paths to include the app bundle when searching for an openssl version to dlopen() Using Apple's library instead of openssl is a major development effort - I know you've looked into decoupling QSslSocket from qsslsocket_openssl with your GnuTLS prototyping. Decision on dropping support would need to be based on: Is it no longer secure? (i.e. if Apple stops providing timely security patches) Is it holding back development of Qt? (i.e. we can't support common features because of missing support in the old openssl) > 2) We could say 1.0.0 is the minimum. This would be a good cutoff from a technical perspective. 1.0.0 has a defined API and future versions should be BC with it, whereas 0.9.x had source and binary incompatible changes. > 3) We could pick another version as a minimum. > > This would have to be based on the versions used by the various long > term supported distributions such as rhel, suse enterprise etc. >From the responses so far in the thread, these look like some version of 0.9.8 >for the older distributions still in current support. We don't need to care about server distributions (which can have longer support periods). -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Setting a Minimum Support OpenSSL Version
On the topic of linux distribution provided versions Ubuntu 10.04 LTS has 0.9.8k-7ubuntu8, updatable to 0.9.8k-7ubuntu8.13 Ubuntu 12.04 LTS has 1.0.1-4ubuntu5.8 (I don't know the original release in the iso, but it was 1.0.x) This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
> > It fails for me, too; the tests are off by 1 hour, it seems. > > This is indeed a mystery. Is the CI in a "European" timezone? > > > > the CI log shows: > > -- > Testing tst_QDateTime > Totals: 350 passed, 0 failed, 34 skipped > -- > > for all the windows configurations (mingw47 and mscv2010 on Win7; > msvc2012 on Win8). > > As far as I understand, the CI is all in Finland, so GMT +2. > This test contains a number of test cases that are only run if the local timezone is CET. They are silently skipped otherwise (test rows not added, rather than QSKIP) It certainly used to fail around the times of year that DST changes happen, when the CI was in Oslo. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal - QtSerialPort graduation from the Playground
> > Where is the read only cts property with a ctsChanged signal to > monitor the input pin? > > Nowhere. Again, there is a impossible have a cross-platform > capabilities to notify about change of CTS pins. > In principle, this feature is available only for Windows, but POSIX > does not provide this. That is annoying :( > To obtain the status line uses the lines() method, where you can get > CTS status. If only polling can be supported cross platform then that will be ok. > > OK, but it would be immediately clear to anyone who previously > worked with serial ports what the API does. > > Ok, in principle, we can think about renamed from Rate to baudRate, it > is can possible. > OK. By the way, I agree with your decision to make it a QIODevice. The rest of the API looks reasonable to me. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal - QtSerialPort graduation from the Playground
>As I repeated the above, it can not be done, at least cross-platform. >On Windows there is a possibility, but not the fact that it is implemented >correctly. OK, that is a good reason to not include it. >>The UART has four control lines: RTS/CTS and DTR/DSR, two inputs and two >>outputs. >> >>Your API only represents RTS and DTR, and seems to use them as both the >>output - setRts(), and as the input - rts(), >>rtsChanged() >>You have included these signal lines in the API so they can be used for out >>of band signalling / GPIO as opposed to >>flow control which would be handled >>at the device driver level. I think the input signals and output signals need >>to >>be separated in the API. >Why divide by Input / Output? >So it is clear that you can only control the RTS and DTR, that goes without >saying. >Another thing, that also the OS for these outputs is provides interface to get >their condition, >so, why not use it? :) Let me put it another way: Where is the read only cts property with a ctsChanged signal to monitor the input pin? I expect rts() to return the value we are currently sending on the RTS output, and cts() to return the value we are currently receiving on the CTS input. >>For the rate property, what was the reason not to name it baudRate? >>That's probably a familiar term to people working with serial ports. >Besause baudRate is too long. :) OK, but it would be immediately clear to anyone who previously worked with serial ports what the API does. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal - QtSerialPort graduation from the Playground
QSerialPortInfo API looks mostly good. I would have expected to see a method to determine supported rates though. This would give a list of rates supported by a given port on the system. e.g. QList supportedRates() I have seen high speed UART used as a peripheral connection in embedded systems. You need to consider how data rates are reported for USB ACM classes and Bluetooth serial port profile connections that look like a (RS232) serial port to the system. On QSerialPort I have some small concerns. The UART has four control lines: RTS/CTS and DTR/DSR, two inputs and two outputs. Your API only represents RTS and DTR, and seems to use them as both the output - setRts(), and as the input - rts(), rtsChanged() You have included these signal lines in the API so they can be used for out of band signalling / GPIO as opposed to flow control which would be handled at the device driver level. I think the input signals and output signals need to be separated in the API. For the rate property, what was the reason not to name it baudRate? That's probably a familiar term to people working with serial ports. -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Laszlo Papp Sent: 10 January 2013 19:47 To: Thiago Macieira Cc: development@qt-project.org Subject: Re: [Development] Proposal - QtSerialPort graduation from the Playground API headers: http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.h http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialportinfo.h Docs: http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialport.cpp http://qt.gitorious.org/qtplayground/qtserialport/blobs/master/src/serialport/serialportinfo.cpp Examples: http://qt.gitorious.org/qtplayground/qtserialport/trees/master/examples On Wed, Jan 9, 2013 at 10:37 PM, Thiago Macieira mailto:thiago.macie...@intel.com>> wrote: On quarta-feira, 9 de janeiro de 2013 21.18.40, Laszlo Papp wrote: > Another try: can we reiterate this question for 5.1? Can you post the API headers and a link to the docs and examples, so we can do an API review? -- Thiago Macieira - thiago.macieira (AT) intel.com<http://intel.com> Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org<mailto:Development@qt-project.org> http://lists.qt-project.org/mailman/listinfo/development This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Preparing Qt 5.0.1 release
> Hi, > > All the repos part of the Qt 5.0.1 release were merged yesterday from > stable->release as announced. > > So changes for 5.0.1 need to be pushed to 'refs/for/release' with a > Task-number tag in the commit message pointing to a P0/P1 task [1]. > > The process should be that you get the change approved normally and you > add me as Reviewer (since only the release team can stage those > changes). > > NOTE: No cherry-picks this time !! > What about changes that are integrated to stable already but missed the branch due to unrelated test failures delaying the integration? This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] dist/changes-x.y.z (was: Re: Branches)
> If we're successful, this will be a non-issue once a few dozen entries > have been added (unless everyone tries to append instead of inserting > entries in some sorted order). If you sort by bug ID, the recently reported bugs will be appended at the end. So staging conflicts happen mostly for the high priority bugs. > > I'd suggest that bug fixes should not touch the changes file, only > new > > features. > > That would be a change from previous practice (changes-4.8.x, say; I've > understood changes-5.0.0 to be a one-time glitch), which probably > didn't include all, but at least some bug fixes. > We bulk added them using git log and searching for "task-number:". If they are added at the same time as the bug fix, staging conflicts will happen. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] dist/changes-x.y.z (was: Re: Branches)
> Hi Lars, > > On Monday December 3 2012, Knoll Lars wrote: > > Dev: > > > > Dev is the branch where you can land anything that's supposed to go > > into 5.1. The following policies apply: > > > > * Changes have to be source and binary compatible > > * You can add new method and classes given that they are fully > > documented and tested * Please do not add half finished features. > > Create your own branch for that, and only push your changes once the > feature is fully done. > > Should we add: > > * carries a change to dist/changes-5.1.0 if it's (Qt-)user-visible (bug > fixes, > new features, performance fixes)? > > Same for stable once 5.0.0 branches off? This would cause many more staging conflicts, as most changes would touch the same file. I'd suggest that bug fixes should not touch the changes file, only new features. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms
> There haven't been too much discussion about different Linux > configurations, But as you can see from list of currently CI tested > configurations there are quite many of them. Personally I'm thinking > that we should remove Ubuntu > 10.04 or at least reduce the number of tested configurations from 2 to > 1 and use that HW capacity to extended testing of different Windows > configurations and possibly static builds of Qt. That said my > suggestion for Qt 5 Linux CI configurations is: > > linux-g++-32_Ubuntu_10.04_x86 (possibly to be removed) > linux-arm-gnueabi-g++_Ubuntu_11.10_x86 > linux-g++_shadow-build_Ubuntu_11.10_x86 > linux-g++_developer-build_qtnamespace_qtlibinfix_Ubuntu_11.10_x64 > linux-g++_no-widgets_Ubuntu_12.04_x64 > linux-g++developer-build_static_Ubuntu_12.04_x64 (new) > 10.04 LTS is more important than 11.10, as it gives test coverage of a different window manager and the 0.9 openSSL libraries. I'd say to drop 11.10 if anything, since it is very similar to 12.04 LTS. If keeping only one configuration on a platform, keep the developer build since it has more test coverage than the production build. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: New list of Qt 5 reference / Tier 1 platforms
> Win8 support would be nice to add, but please do not drop WinXP. > MS may be dropping official, public support for WinXP in 2014; but it will > still be around for a very long time. > Ben Are you referring to XP for embedded? (which survives until 2016) I'd strongly advise anyone not to use a operating system for which there are no security updates on a general purpose machine. While you may need to continue supporting products based on XP embedded, would that include putting new releases of Qt on them? However, if & when we do decide to remove XP from the CI system it should be replaced with vista (as the oldest supported windows version). We shouldn't test only W7 and W8. My view would be that XP should not be a tier 1 platform for new releases when MS discontinues extended support. It should still be tested for patch releases of already released Qt versions. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QT5 Beta 1 & Android
On Android it is possible to handle display orientation by yourself, not using the default behaviour of destroying and recreating the UI. You'd use OrientationEventListener & Display classes to detect the orientation then. This would make sense for a QML application where the scene graph can handle rotation of elements. The android:configChanges element in the manifest file is used to specify what things the application can handle itself. See also http://developer.android.com/guide/topics/resources/runtime-changes.html -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Common base class for all socket types
> There is a ton of overlap between QIODevice and QAbstractSocket, but
> don't think too hard about it or else you'll drive yourself mad.
QIODevice is actually a superclass of QAbstractSocket.
> The most common functionality that is shared between QAbstractSocket
> and QLocalSocket is just the connect/disconnect functionality. Aside
> from that, yes they are both more or less just QIODevices. Lots of
> things fit the QIODevice abstraction.
Yes, and the connect functionality is different.
With a QAbstractSocket: you are connecting to an IP address (or DNS name), with
the service determined by the port number.
With a QLocalSocket: you are connecting to a named service on the local machine.
> With QAbstractSockets: aside from the contradiction that is UDP, you
> are connecting to a server, IO'ing to/from it, then disconnecting (udp
> emulates this). The IO stuff all exists in QIODevice already, so
> QAbstractSocket almost seems unnecessary.
QAbstractSocket exists only because there is common code & API in the TCP and
UDP sockets.
It doesn't need to be part of the public API, but it would be a fair amount of
work to remove it for marginal benefit & source incompatibility.
When it comes to users' IO code, QTcpSocket and QLocalSocket have more in
common than QTcpSocket and QUdpSocket
However, the signals and API for interacting with an already connected stream
(or indeed an open file/process) are all in QIODevice.
> Yes QProcess and even QFile can be used to communicate with a 'server',
> but in general they are not. QNetworkReply, however, has no 'connectTo'
> analog so doesn't really fit at all. QNAM is a different networking
> model. I find it strange that QNetworkRequest doesn't also derive from
> QIODevice, but eh I don't really use QNAM all too often so I don't
> really care to think about it.
QNetworkReply derives from QIODevice.
As you say, it's a different networking model, with the purpose of fetching
resources from URLs.
QNetworkRequest encapsulates the URL, and any header information to go with it.
QNetworkReply gives you the data stream from the server, and access to parsed
headers that were received.
> With further analysis between the similarities of
> QIODevice/QAbstractSocket, I've changed my mind and now think that
> QAbstractDataChannel (as a replacement to QAbstractSocket) is a crappy
> base name. It's too ambiguous with QIODevice. So how about
> QAbstractConnectionStream instead to replace QAbstractSocket?
QUdpSocket isn't a stream, so it wouldn't be a clean replacement.
> Without providing concrete examples, changing the design to specify the
> connect parameters in the constructor provides an obvious benefit with
> zero cost. The old empty constructor remains, and so does the
> overloaded/helper connectTo with all the argument still there. This
> wouldn't even break the API if we didn't change the name (but we
> should).
To be clear, you mean the same pattern as QFile?
e.g.
QTcpSocket socket("www.qt-project.org", 80);
socket.connect();
connect() is a problematic name because it hides QObject::connect()
> If you require concrete examples, think of any case that justifies the
> existence of the current QAbstractSocket. Why was it created? Why
> weren't QTcpSocket and QUdpSocket just derived straight from QIODevice?
> Your answer to that is the answer to 'provide concrete examples of why
> QLocalSocket should derive from QAbstractSocket instead of QIODevice'.
> It should also seem like common sense seeing as QLocalSocket has the
> word "socket" in it.
I think most of the issues can be solved by connecting the socket first, then
using QIODevice as your base class pointer. When you call QIODevice::close()
that
will disconnect the socket.
I'd like to see non blocking (or asynchronous) IO for files as well.
> All this chit-chat is worthless, but we should probably agree on a new
> base name at the very least. As for doing the same to QProcess's
> constructor: why not? Obvious gains, zero cost. QFile already has the
> filename optionally specifiable in the constructor :-), though it lacks
> an open(filename) overload (trivial to add).
You can call setFileName(filename) and then open() as normal.
Extra overloads are fine though if they make sense, they are generally backward
compatible.
As they're backward compatible, they can go in a minor release such as 5.1
This message is for the designated recipient only and may contain privileged,
proprietary, or otherwise private information. If you have received it in
error, please notify the sender immediately and delete the original. Any other
use of the e-mail by you is prohibited.
Where allowed by local law, electronic communications with Accenture and its
affiliates, including e-mail and instant messaging (including content), may be
scanned by our systems for the purposes of information security and assessment
of internal compliance with Accenture policy.
__
Re: [Development] Dependencies of Qt5
> This time we will need RUBY. What next? Webkit also requires bison. -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cleanup of QCoreApplication::watchUnixSignal
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Rafael Roquetto > Sent: 25 October 2012 15:17 > To: development@qt-project.org > Subject: [Development] Cleanup of QCoreApplication::watchUnixSignal > > Hello, > > Afaik QCoreApplication::watchUnixSignal() seems to be no longer used, > at least in Qt5. If that is really the case, would anyone object doing > away with it (and removing the overhead from > QEventDispatchUnix::doSelect() and co.)? > Otherwise, what are the possible use cases? > > Any thoughts? > > - Rafael The overhead is tiny (two integer comparisons) when it is not being used. Crash reporting is not a valid use case (since behaviour is undefined after returning from the signal handler) The most reasonable use case would be handling SIGHUP and SIGTERM, to save state and shut down the process cleanly. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposal: installation of QtWebkit helper processes
Background: QtWebkit in Qt 5 requires two helper processes: QtWebProcess & QtWebPluginProcess Applications using a web view component will not work if these executables are not in the path. These processes are an implementation detail of Webkit, and the interfaces may not be compatible between versions. Proposal: Include the version in the executable name, either the Webkit version or the Qt version will do. - to prevent running an incompatible version Install to the libexec path, e.g. $(libexecdir)/qt5 on linux I expect on windows each application will carry it's private copy, and on mac it will be inside the framework package. Use QLibraryInfo to locate the helper executable at runtime. (see Thiago's proposal on tools) Assumed that for developer builds this points to the right place in the build tree. -- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork: using system proxy by default
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Thiago Macieira > Sent: 15 October 2012 18:41 > To: development@qt-project.org > Subject: Re: [Development] QtNetwork: using system proxy by default > > On segunda-feira, 15 de outubro de 2012 16.33.39, > shane.kea...@accenture.com > wrote: > > When using the windows API, we can enable either DNS, DHCP or both. > > Using DNS only would be faster, but may not work for some users if > > their office network used DHCP only deployment. > > > > Also, I checked today and it looks like Chromium have now implemented > > DHCP autodetection by themselves as well. They are checking it on > > startup & caching the results. > > IIRC, DHCP requires binding to port 67 in order to send the request, > which requires root privileges on Unix systems. That means we can't do > it. Yes, that puts this outside our scope. I'd rather not be implementing this only for windows. > I'd create a (wall-clock) timer and enable the DHCP resolution on > Windows only once every 10 minutes. I'd also use it as a fallback if > and only if the DNS resolution failed. That doesn't help with the 12 second freeze, since both methods fail if you are on a network with no autoproxy. We need to be calling WinHttpGetProxyForUrl or WinHttpDetectAutoProxyConfigUrl in a thread, like we do for name resolutions. There is also the non blocking WinHttpGetProxyForUrlEx, but that is new in windows 8. > The only drawback is that we'll insist on a bad, cached result if the > user moves from a network with DHCP and no DNS, to a network with no > autoproxy. We could cache the host's IP addresses and discard the cache > if they have changed too. Since we'll do that only once every 10 > minutes, the overhead will be minimal. > Caching the result and having some ways to invalidate the cache makes sense. WinHttpDetectAutoProxyConfigUrl is the best thing to use, since it gives a pac file url, which is the same thing as the static configuration would give us. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork: using system proxy by default
Apparently not, I don't know why Microsoft implemented it this way.
The result is only cached if a PAC script is successfully downloaded.
The DHCP method doesn't serve the PAC url together with the IP address, it's a
separate query sent to the DHCP server by the browser (or us)
If autodetection fails, it returns "no proxy" for this request, but tries
autodetection again next time the API is called.
The autodetection procedure looks like this pseudocode (but is all one API call
to us):
for(tries=0;tries<2;tries++) {
send(DHCP_INFORM requesting option 252);
if (wait_for_response(6 seconds)) {
pac_url = response;
break;
}
}
if(!pac_url) {
pac_url = "http://wpad/wpad.dat";;
}
When using the windows API, we can enable either DNS, DHCP or both.
Using DNS only would be faster, but may not work for some users if their office
network used DHCP only deployment.
Also, I checked today and it looks like Chromium have now implemented DHCP
autodetection by themselves as well. They are checking it on startup & caching
the results.
From: Knoll Lars [lars.kn...@digia.com]
Sent: 15 October 2012 16:00
To: Kearns, Shane
Cc:
Subject: Re: [Development] QtNetwork: using system proxy by default
Hi Shane,
(adding the ML back in again…)
wouldn't Windows run the DHCP detection only once at startup (or when network
status changes) and cache the result? Why would we need to re-run this inside
the Qt app?
Cheers,
Lars
On Oct 15, 2012, at 4:00 PM, shane.kea...@accenture.com wrote:
> Hi Lars,
>
> It happens the first time only (because we have a workaround to disable
> autodetection if it fails)
> When I reproduced it, it was 12 seconds.
>
> The problem is windows sends a DHCP packet with a microsoft extension, and
> has a long timeout waiting for a reply.
> With good DHCP servers, they'll reply (negatively if they don't support that
> extension)
> With bad DHCP servers, there is no reply which triggers the problem.
>
> It seems like some wireless access points/home routers have a "bad" or
> incomplete DHCP implementation
>
> I agree that enabling system proxy by default is what most app developers
> would want.
> An option would be to always disable DHCP detection, which gets rid of this
> worst case.
>
> From: Knoll Lars [lars.kn...@digia.com]
> Sent: 15 October 2012 08:39
> To: Kearns, Shane
> Subject: Re: [Development] QtNetwork: using system proxy by default
>
> I'd agree with Simon that #4 would be the best default option from a user
> experience point of view. Most likely it's also what most app developers want.
>
> Is the windows problem purely something happening once when initiating the
> first connection, or does it happen with every connection? And what does this
> mean in a real use case (ie. how many seconds are we talking about)?
>
> Cheers,
> Lars
>
> On Oct 11, 2012, at 4:34 PM, shane.kea...@accenture.com wrote:
>
>>> IMHO #4 gives the best out-of-the-box experience.
>>>
>>> Is there a way to do the blocking winapi call in a thread on app start-
>>> up maybe?
>>
>> Doesn't help if the first thing an application wants to do is download
>> something from the network.
>> It would only help because of the workaround we already have to disable WPAD
>> if it fails (which is not ideal if you start an app at home, then take your
>> laptop to work)
>>
>>> How do other apps (i.e. Chrome) handle this without blocking the user
>>> experience?
>>
>> Chrome doesn't use the windows API, they make a request to "http://wpad"; and
>> interpret the pac script themselves.
>> Firefox is slow to load pages, but UI is not blocked (which points to using
>> the windows API in a thread)
>>
>> WPAD is inherently spoofable, but the Chrome method is worse than the
>> windows API, as you can't tell if the name came from DNS or multicast name
>> resolution.
>> In any case, we don't have a javascript interpreter available at the
>> QtNetwork level.
>>
>> Subject to local law, communications with Accenture and its affiliates
>> including telephone calls and emails (including content), may be monitored
>> by our systems for the purposes of security and the assessment of internal
>> compliance with Accenture policy.
>> __
>>
>> www.accenture.com
>>
>> ___
>> Development mailing list
>> Development@qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>
>
>
> This message is for the designated recipient only and may contain privileged,
> proprietary, or otherwise private information. If you have received it in
> error, please notify the sender immediately and delete the original. Any
> other use of the e-mail by you is prohibited.
>
> Where allowed by local law, electronic communications with Accenture and its
> affiliates, including e-mail and instant mes
Re: [Development] QtNetwork: using system proxy by default
> IMHO #4 gives the best out-of-the-box experience. > > Is there a way to do the blocking winapi call in a thread on app start- > up maybe? Doesn't help if the first thing an application wants to do is download something from the network. It would only help because of the workaround we already have to disable WPAD if it fails (which is not ideal if you start an app at home, then take your laptop to work) > How do other apps (i.e. Chrome) handle this without blocking the user > experience? Chrome doesn't use the windows API, they make a request to "http://wpad"; and interpret the pac script themselves. Firefox is slow to load pages, but UI is not blocked (which points to using the windows API in a thread) WPAD is inherently spoofable, but the Chrome method is worse than the windows API, as you can't tell if the name came from DNS or multicast name resolution. In any case, we don't have a javascript interpreter available at the QtNetwork level. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QtNetwork: using system proxy by default
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Peter Hartmann > Sent: 11 October 2012 14:12 > To: development@qt-project.org > Subject: [Development] QtNetwork: using system proxy by default > > Hello, > > I remember this has been discussed before, but yet again: How about > using the system proxy by default, at least on some platforms or by > configure switch? Right now every app developer has to call > QNetworkProxyFactory::setUseSystemConfiguration(true) in his code to > use the system proxies. > On desktop you might want to avoid this depending on your app, but on > mobile (e.g. Blackberry) it might happen that you just have to use the > system configuration and it will not work without it. Many mobile networks have a mandatory http proxy for the access point. System configuration is the only reasonable way to get this. > IMO there are 4 options: > > 1. leave as it is, tell everybody to call above method in their app 2. > just #ifdef for the platforms where it should be used automatically 3. > introduce a configure switch "-use-system-proxy" or so (default no) 4. > enable usage of system proxy globally > > > 1. sounds a bit cumbersome for me; I prefer 2. for pragmatic reasons. > If people think 3. is cleaner that is fine with me as well. As Shane > told me, using the system proxy on Windows might lead to several > seconds of delay until the synchronous method that determines the proxy > returns, so for now 4. seems too risky. A refinement of option 1 would be to include the setUseSystemConfiguration call in the SDK boilerplate code (along with using showFullScreen() instead of show() on mobiles). The windows issues are documented in https://bugreports.qt-project.org/browse/QTBUG-10106 - normally it's ok, but the worst case is terrible. - the worst case is reproduced with some consumer wlan routers, so affects many users. Nobody complained yet about performance on Mac, but it's a more recent feature and hasn't been tested for perf. Libproxy performance is unknown, I've only done functional testing. In all cases, the API is synchronous. For option 4, I think we need to make an asynchronous wrapper and use it internally anywhere we might block the UI thread with the synchronous version. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Co-installation & executable naming rules
> We just had a discussion in the Oslo office about this. We suggest to > basically follow your proposal, with an addon to hide some of the > uglyness it brings along. > > Let me try to summarize very shortly. The base proposal would be to > include the major Qt version throughout the project: > > 1) Prefix the libraries, i.e. libQt5Core, libQt5Gui, etc. > 2) Prefix the pkg-config files (Qt5Core.pc, etc.) > 3) Prefix the binaries (qt5designer, qt5moc, qt5make) (note that > this is referring to the binaries, not the user visible names or bundle > names) > > This allows for co-installation on all platforms (even on ones where > there exists no problem of co-installation :) > > > Now this has some ugly implications, everyone will have to change the > way they > develop with Qt 5. In this context we have another interesting > artifact: > People who have been developing Qt for a long time as part of company > efforts > such as Trolltech, Nokia or now Digia will know that by now pretty much > every > developer has their own set of shell scripts to deal with multiple > simultaneously installed Qt versions. We've had a few attempts at > consolidating these efforts, with varying success (devtools / qset). > Now one > thing we came up with in our local discussion here is that maybe it's > time to > bring this idea forward and use it to solve the "uglyness" of co- > installation > in production environments: > > We could have a tool (let's call it just "qt") that makes choosing > between > different versions/installations of Qt easier. The tool should read and > write > the existing Qt Creator Qt version registry (so that everything is > always in > sync). It could allow for forwarding calls to executables (qt --4 qmake > -> > call qt4's qmake; qt --6 qmake -> call qt6's qmake, same for moc, uic, > designer, etc.). > > It could also be a tool that's aware of defaults, so that just calling > "qt > qmake" would call qmake from the currently selected Qt version. It > could also > support changing your environment (if its front-end was a batch file > and shell > script), so that you could write "qt --set 5" and further invocations > of "qt > qmake" in the same shell/environment would automatically pick qt5's > qmake. > > If the tool used Qt Creator's registry of Qt versions, then it would > also be > suitable for Qt developers who may have different versions of the same > major > version installed on the same computer and want to often quickly change > between them within a terminal. > > > The Qt tool itself could be written using the internal Qt bootstrap > library. > > > What do you think? > > Folks from the Oslo discussion: anything I missed? > This is similar to the approach that java took. There you'd use: "javac " to compile using the default JDK "javac -version 1.5.33 " to compile using the 1.5.33 JDK The javac in the path was a thin wrapper that checked for the -version argument and forwarded to the appropriate version. I'd prefer qmake to work like that, rather than needing "qt qmake" This would mean we'd need to find and reserve a command line argument for selecting qt version that is available in all the qt tools that would be installed in the path usually. Another thing you need to consider is named versions. For example I might have "5.0.0" and "5.0.0-blackberry" co-installed. I think Qt Creator handles this just fine, but the "qt --5" examples above look like it wasn't considered. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] How to release critical fixes?
Since the major/minor/patch release is encoded into QT_VERSION, critical releases should increment the patch number. I suggest to use a short lived branch for just this release. e.g. check out previous patch release tag (e.g. v4.8.3) create a branch from it cherry pick the critical fix(es) onto the branch cherry pick the QT_VERSION update to the branch tag the head of the branch with the new release (e.g. v4.8.4) close the branch push a QT_VERSION update to the main branch (e.g. 4.8) to update the QT_VERSION to the next release (e.g. 4.8.5) The git history would look something like this: O | O-v4.8.3 |\ O O | | O O-v4.8.4 | ... | O-v4.8.5 -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Rafael Roquetto > Sent: 05 October 2012 15:33 > To: development@qt-project.org > Subject: [Development] How to release critical fixes? > > Hello all, > > Following the discussion concerning 4.8.3-1 vs 4.8.4, I think an > important gap on the workflow has been exposed: how to release critical > patches? I am not sure if this makes sense, since I am entirely not > acquitanted to the entire release process, but would anyone have any > suggestion or comments on how we could issue these exceptional releases > that should only include highly critical fixes (i.e. the SSL one)? > Feedback? > > Thanks, > Rafael > -- > ** Qt Developer Conference: http://qtconference.kdab.com/ ** > > Rafael Roquetto | rafael.roque...@kdab.com | Software Engineer > Klarälvdalens Datakonsult AB, a KDAB Group company Tel. Sweden (HQ) > +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - Qt Experts - Platform- > independent software solutions Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Preparing to release repackaged version of Qt 4.8.3 with Digia copyrights
> I see three critical things which must be released asap: > > 1. the (C) headers change > 2. MingW patch. > 3. d41dc3e101a694dec98d7bbb582d428d209e5401 - this is the SSL > workaround from Robin. > (Rich, not Robin) If the release is called 4.8.4, then the SSL security patch must be included, as we said 4.8.4 would include this in the security announcement. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Extending Visual Studio's display of Qt classes
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Tom Isaacson > Sent: 16 September 2012 11:08 > To: development@qt-project.org > Subject: [Development] Extending Visual Studio's display of Qt classes > > I understand why the Pimpl Idiom is being used here, but I'm wondering > if it's actually necessary. It's intended for when the source code of > the implementation isn't available so internal variables and function > names can be completely hidden. But in the case of Qt, where the source > code is available and can even be used to build your own binaries, it > seems excessive. It also means that useful displays of debugging data > aren't really possible and you have to resort to what I've done below. > > Can I suggest that going forward the Pimpl Idiom is dropped and we go > back to just using private member variables and functions to prevent > them being called from outside the class? Or is there some alternative > that would allow VS to see the layout it needs? Hi Tom, This is not the reason we use the idiom. It is used to ensure we can maintain ABI compatibility between releases. Changing the size of a c++ class is a binary incompatible change. Code compiled into the application could be dependent on the size of the class. So we could never add or remove variables even if they have private visibility. When using this idiom, the public class contains only a pointer to the private class. The private class can be freely changed between releases because it's explicitly not part of the API. The public class remains the same, just containing a pointer to the new private class. Except for QString / QByteArray which store offsets rather than pointer, you should be able to expand the d pointer in the MSVC debugger, as long as Qt was built with debug symbols. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Git commit hook keywords
The line: Change-Id: I9c239ff790a139c7820ef1aeced89d31320ae6b0 Is what identifies the code review. If you put that into the search box on gerrit, it gives the url: https://codereview.qt-project.org/#q,I9c239ff790a139c7820ef1aeced89d31320ae6b0,n,z Which shows the two reviews for this change (5.0 and 4.8 cherry pick) I think you could use that as a basis for generating urls to link to the code review from the commit message. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Experimental Qt 5 installers by Digia
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Olivier Goffart > Sent: 31 July 2012 08:54 > To: development@qt-project.org > Cc: Thiago Macieira > Subject: Re: [Development] Experimental Qt 5 installers by Digia > > On Tuesday 31 July 2012 09:18:13 Thiago Macieira wrote: > > On segunda-feira, 30 de julho de 2012 22.48.03, Leandro Melo de Sales > wrote: > > > My linux distribution is Ubuntu 12.04 and I have libicui18n > > > installed, > > > > > > but version 48 not 44. Any clue? > > > > That won't work. Because of the ICU dependency, our binaries no > longer > > work across many distros. They will work on one distro only, or at > > most the distros of the same era (e.g. Ubuntu 12.04 and Fedora 17, > > which were released close together; 11.10 and F16, etc.) > > Then we need to put ICU in our binaries. > (compile it statically for example) > Just like we do for libpng Or can we load it using dlopen like we do for openssl? Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Cherry pick fix from Qt5 to Qt 4.8.x
There are two ways to do it, using a cherry pick or using a patch file. The main difficulty is where files have moved around (e.g. tests/auto structure has changes or files moved from src/gui to src/widgets) In either case, edit the commit message to include the SHA1 of the change you cherry-picked. If there were non trivial changes, write "back ported from" so reviewers know it's not the same patch that went to qt5. 1. using a cherry pick: First you need to add the qt 5 submodule repository as a remote to your qt 4 clone, for example "git remote add qtbase git://qt.gitorious.org/qt/qtbase.git" If the patch is in a different submodule to qtbase, use that instead. Next fetch the latest changes and cherry pick "git fetch qtbase" Find the commit you need to cherry pick "git log --author= qtbase/master" "git log --grep= qtbase/master" Do the cherry pick "git cherry-pick -x " At this point you may need to resolve merge conflicts e.g. because autotest files have moved. 2. using a patch file Go to the submodule in your qt5 clone and find the commit you need to cherry pick "git fetch" "git log --author= origin/master" "git log --grep= origin/master" Create a patch file "git format-patch -1 " Go to your qt4 clone and apply the patch "git am -3 " If the patch does not apply, you can edit it (e.g. change the paths for autotests before applying the patch) -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Thiago A. Corrêa > Sent: 27 July 2012 17:35 > To: development@qt-project.org > Subject: [Development] Cherry pick fix from Qt5 to Qt 4.8.x > > Hi, > > I've sent a patch to Qt5 that's already integrated, and I would > like to cherry pick it for qt 4.8. I haven't found the process > documented anywhere, could someone point me in the right direction? > I must say I'm not very good with Git, so the more details the > better. Appreciate the help. > > Kind Regards, > Thiago A. Correa > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use static qt libraries
> On terça-feira, 24 de julho de 2012 15.17.23, Thiago Macieira wrote: > > Here we have a big problem. QNetworkConfigurationPrivate is not > > exported, so it can't be used from the plugins. It should be > exported > > and its virtual destructor should be de-inlined. > > Actually, since the class is not derived from, it should not have a > virtual destructor in the first place. I recommend dropping it and > leaving it unexported (all methods are inline). > In Qt 4, the symbian plugin derived from it to add two data members (with a constructor to zero initialise them) It doesn't look like any of the Qt 5 plugins do this. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Use static qt libraries
> > Thanks, are such undefined symbols normal ? And is there a way to fix > it ? > > Missing only the _ZTI ones is highly irregular. The typeinfo objects > are always emitted together with the virtual table and other objects. > Since the virtual tables are not missing, the only explanation I can > give is the same one that Rohan had: you're mixing -fno-rtti with code > that requires the RTTI. > Could this also be due to mixing no-exception and exceptions enabled code? I know that enabling exceptions enables some vtable & rtti exports in a dll too. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QHttpResponseHeader is obsolete and removed from Qt5
Look at the QNetworkRequest and QNetworkReply classes, particularly the header() and rawHeader() functions of QNetworkReply These APIs are also available in 4.6, 4.7, 4.8. Please write your code to use this API if at all possible, since it is still getting support. Those deprecated classes have been removed from QtNetwork and put in their own add-on modules. QtHttp contains the obsolete http classes QtFtp contains the obsolete ftp classes If for some reason you need to use them, build the add-on module if necessary and then include in your qmake pro file: QT += http -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Leandro Melo de Sales Sent: 06 July 2012 05:21 To: development@qt-project.org Subject: [Development] QHttpResponseHeader is obsolete and removed from Qt5 Hi, In my project I use QHttpResponseHeader that is obsolete and it isn't available in Qt5. What is the equivalent class of it in Qt5? -- Leandro Melo de Sales PhD candidate in Computer Science Pervasive and Embedded Computing Laboratory, UFCG Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 beta, MinGW: undefined reference to `WinMain@16'
Does the same problem happen if using qmake instead of qbs?
There is a qtmain.lib static library that should be added automatically to
windows executables, which provides the WinMain entry point.
--
From: development-bounces+shane.kearns=accenture@qt-project.org
[mailto:development-bounces+shane.kearns=accenture@qt-project.org] On
Behalf Of Loaden
Sent: 05 July 2012 04:15
To: development
Subject: [Development] Qt5 beta, MinGW: undefined reference to `WinMain@16'
main.cpp
#include
int main(int argc, char **argv)
{
QCoreApplication app(argc, argv);
return app.exec();
}
test.qbp
import qbs.base 1.0
Application {
name : "Test"
Depends {
name: "Qt.widgets"
}
files : [
"main.cpp"
]
}
MinGW-TDM32:
Found project file D:\qpSOFT\Projects\Test\test.qbp
loading project took: 79 ms
build graph took: 14 ms
for t86-tdm-mingw32-release:
- [hpp, application] Test as t86-tdm-mingw32-release
compiling main.cpp
linking Test.exe
D:\qpSOFT\MinGW\TDM-MinGW32\bin/g++ -O2 -Wall -W
D:/qpSOFT/Projects/Test/build/t86-tdm-mingw32-relea
se/.obj/Test/main.o -o
D:/qpSOFT/Projects/Test/build/t86-tdm-mingw32-release/Test.exe -LD:/qpSOFT/Pr
ojects/BuildQt5-t86/qtbase/lib -lqtmain -lQtCore5 -lQtGui5 -lQtWidgets5
d:/qpsoft/mingw/tdm-mingw32/bin/../lib/gcc/mingw32/4.6.1/../../../libmingw32.a(main.o):
In function
`main':
C:\MinGW\msys\1.0\src\mingwrt/../mingw/main.c:73: undefined reference to
`WinMain@16'<mailto:%60WinMain@16'>
collect2: ld returned 1 exit status
MinGW-w64
D:\qpSOFT\MinGW\MinGW32\bin/g++ -m32 -O2 -Wall -W
D:/qpSOFT/Projects/Test/build/m86-mingw32-release/
.obj/Test/main.o -o D:/qpSOFT/Projects/Test/build/m86-mingw32-release/Test.exe
-LD:/qpSOFT/Projects/
BuildQt5-m86/qtbase/lib -lqtmain -lQtCore5 -lQtGui5 -lQtWidgets5
d:/qpsoft/mingw/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.6.3/../../../../i686-w64-mingw32/lib/../li
b/libmingw32.a(lib32_libmingw32_a-crt0_c.o): In function `main':
/home/ruben/mingw-w64/toolchain/src/mingw-w64/tags/v2.0.3/mingw-w64-crt/crt/crt0_c.c:18:
undefined r
eference to `WinMain@16'<mailto:%60WinMain@16'>
collect2: ld returned 1 exit status
--
Please don't ask where I come from, It's a shame!
Best Regards
Yuchen
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Proposal: Remove QML from Qt's code base (OR: Should it be a requirement that Qt Modules are interoperable?)
> > So that is possible.
> > QtQuick3D for example just does:
> > "QT = core gui qml quick 3d"
> >
> > and there is no check anywhere in that repo that checks if QML should
> be built, so you get an error about missing qml and quick modules.
> >
> > I wouldn't mind fixing it, but I just missed how you can check for
> this stuff (and a quick Google does not find it).
> >
>
> contains(QT_CONFIG, qml):{
> # add qml stuff
> } else {
> # add other stuff
> }
>
Or to skip building if missing:
requires(contains(QT_CONFIG, qml))
Incidentally, QT_CONFIG isn't documented at
http://doc-snapshot.qt-project.org/5.0/qmake-variable-reference.html
Or at http://qt-project.org/doc/qt-4.8/qmake-variable-reference.html
This should probably be fixed?
A number of examples use it.
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from QtNetwork sessions
> > * Autotests > > * Non-significant > > * Not compiled > > What is meant by "not compiled"? Tests excluded from the parent .pro file (qnetworkproxyfactory used to be commented out, this has been fixed in 5.0 but not 4.8) Also use of contains(QT_CONFIG, private_tests) to exclude test cases in release builds Sometimes it's possible to exclude the individual test function(s) that require autotest exports rather than the entire test. > > * Dependency on the test server > > * eg. QNetworkReply has too many tests they should be broken up > > * Some tests should be recognised as possible to fail, unit tests > should not > > fail. CI can be smarter if it knows which is which. > > * Separate executables for each so they can have differing retry > strategies. > > > > Breaking up tests with a long runtime into smaller test executables > helps in several ways ... it allows each subtest to be retried > individually if necessary, and may allow them to be run in parallel as > well. > It's a good idea. > > I saw some chat on IRC about, I think, grouping the tests into > different directories to classify their expected stability. If you > want to go down that route then I think it would be better to introduce > a new hint to the CI system at http://qt- > project.org/wiki/CI_Autotest_Metadata , rather than making it depend on > the directory layout. Yes, that makes sense. The groupings we discussed were: Tests that don't depend on anything external Tests that depend on test server / DNS servers (may need retry due to network glitches) Slow tests (e.g. the connection timeout tests - these could run in parallel) For UI framework tests, there's a similar split between unit tests vs those that rely on sending mouse/keyboard events to widgets. The latter can be disturbed by system notifications taking focus away for example. Jason discussed the issue in the QtTest session too. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] 'Last week in Qt development' blogs
> Someone mentioned at the Qt CS that they'd like to see some weekly > digest of developments in Qt. For those unaware (at least someone at Qt > CS was unaware), I'm providing that on the KDAB blog: > > http://www.kdab.com/category/qtdevelopment/ > > (I'm aware that the content is not currently sorted by date. Looking > into it) > > I wouldn't mind crowdsourcing the content if we can find a way to do > that. > Will you post the QtCS session notes (or links to them in the mail archive) in the next weekly blog? Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from QtNetwork sessions
> > Multihoming is actually quite common if you consider VPNs. > > (e.g. intranet traffic goes to the VPN, and everything else goes to > > the real network adaptor by default) > > When I think "multihoming", I think different routes to reach the same > server. > Usually, that means two default routes. That happens when there's one > device that has two adapters connected to the Internet. > Straying from the core topic, but VPN software I've used exposes a virtual network adaptor which has an IP address belonging to the company intranet. And it's possible to route internet traffic via the VPN though normally you don't want to because of performance. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Notes from QtNetwork sessions
From: Xizhi Zhu [mailto:xizhi@gmail.com] > Do we have the mutex / blocking issues for the bearer tracked on Jira? I > guess it needs some design, > including the blocking constructor, before we really start to fix it. There have been a number of issues in JIRA, most have been P1 emergencies for a given platform. Over time it gives the impression that the bearer design is flawed, though I think we can live with the API. My design thought is that the bearer backends (plugins) should only be called from the bearer thread. That would mean having a proxy QObject in the bearer thread that communicates via signals with the public API classes that live in the user thread (e.g. QNetworkConfigurationManager) Decoupling in this way would remove the mutexes, and relax the requirement for the backend plugins to be thread safe. I think a problem has been that people implementing backend plugins haven't realised they needed to be thread safe until it starts crashing in system tests. (I wish we had a whiteboard for this - design discussions are where the mailing list & IRC are least satisfactory) The disadvantage is that the front end information can be out of date if the event loop isn't called to process queued signals. This is somewhat implied already due to the update API with a completion signal that already exists. >> * The API currently lists the available wireless lans, thiago thinks that it >> should not do this and should say that the device can do wireless. >IIRC, one background for this feature is that for Symbian the application can >choose AP it connects. But I guess it's >not the case for most other systems, >where the connection is chosen by the system. So, yes, +1 from me. At least linux/windows/mac work like that (and the last releases of Symbian encourage using AP groups like "internet" over specific APs too). I'd like input on what influence applications have (if any) on AP selection in Android / Blackberry Multihoming is actually quite common if you consider VPNs. (e.g. intranet traffic goes to the VPN, and everything else goes to the real network adaptor by default) >> * Should we simply say if we're connected. > QNetworkConfigurationManager::isOnline() is already doing this. But it's more > useful especially for mobile devices to > know which network type (3G or WLAN) it's using. (Or maybe I mis-understoodd > this?) The question was related to how much information needs to be available immediately after constructing QNetworkConfigurationManager. Currently the constructor blocks on the bearer thread doing an initial update. >> * We should let people know what type of connection it is. (e.g. roaming / >> home 3G networks / WLAN) > +1. There was some discussion before about merging some of the APIs exposed > from QNetworkInfo > (http://doc-snapshot.qt-project.org/5.0/qnetworkinfo.html) to the bearer > class, e.g. QNetworkInfo::NetworkMode > is more or less a duplicate of QNetworkConfiguration::BearerType. And > QNetworkInfo::NetworkStatus is what we need here. OK, so at least the information is available through another API for the common case where you have one 3G modem. It would make sense to get this information in QNetworkConfiguration as well. Unfortunately we have a dual meaning of "roaming" which is used for the QNetworkSession handover to another bearer as well as roaming on another 3G/GPRS data network. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Notes from QtNetwork sessions
Thanks due to Rich Moore for taking notes in the session, which I've edited my own into. * Built-in support for redirects (suggested by Yuval T.) * Flag on QNAM * Override on a per-request basis? * Set max count? (for avoiding redirect loops) * What about redirect from secure to non-secure? * Opt-in functionality * User needs to be able to determine original and final URL from the QNetworkReply * Yuval was interested in implementing this, but wants help with the API design (suggested to use development mailing list) * Autotests * Non-significant * Not compiled * Dependency on the test server * eg. QNetworkReply has too many tests they should be broken up * Some tests should be recognised as possible to fail, unit tests should not fail. CI can be smarter if it knows which is which. * Separate executables for each so they can have differing retry strategies. * Windows socket engine * has problems (unreliability of the blocking waitForXXX API) * there were no winsock experts in the session * QFtp * Request for a VFS * thiago suggests rewriting the whole io stack, so that the current one can be removed in qt6. * Short term, could add support for listing support etc. for QNAM. * Question if FTP is actually important? * dfaure pointed out we have kio and with frameworks it will be usable within qt. * Conclusion - add listing to QNAM. Nice to have, but not required. * Conclusion - FTP is less important these days so a full QFtp replacement isn't a good use of time * Proxy support on linux * use libproxy? * Fits quite well with our api. * Make it a build option * Can its engine load one of the many js engines we already have? * Should we use our own implementation? * Ideally should come from the bearer (eg. conman). * No api so who cares, lets use libproxy for now. * On windows/mac we already use the system. * Do we want pluggable scheme handlers in QNAM? * Isn't just the VFS question again? * Internally has some support for this. * LDAP is a step too far - not appropriate. * Hybrid apps should derive from QNAM and implement their own. * Possibly use kio in future if it is sufficiently abstracted. * Conclusion - no / not until there is a more convincing use case for an addon needing this. * QNAM instance. * Not thread safe. * What about bearer specific. * Nothing in the docs that say it should be a singleton. * QML has a QNAM hidden inside. * Should be able to share cookie jar etc. between threads / QNAM instances (though should not be required to). * What about making having a convenience memory cookie jar. * What about the disk cache. * There's one in boston. Can we get it? * Sharing the cache between processes. Probably works. * What about a persistent cookie jar? * QtWebkit have one using sqlite. * performance characteristics match sqlite. * SSL blacklist * Don't want to update qt each time a CA fucks up. * should be able to add to blacklist using data file / API * What else do people want? * WebSocket client. Even a subset. looks at libwebsocket. * Could integrate with qml so qml gets a signal. * Would it need exposing to qtwebkit? * Research project. * SPDY * Refactor the socket engines. SSL socket backend buffering. Part 2 == * Bearer * Does RIM implement the api? (unknown, Ben would need to check) * Does Necessitas implement the api? * Needed for VPNs etc. * Wasn't thread safe, so now has a mess of mutexes. * Can deadlock * Shane's suggestion is to have a model in the thread owning QNetworkConfiguration / QNetworkConfigurationManager QNetworkSession etc, which communicates with the backend. * Can we make the backends thread-safe? The system APIs may not be threadsafe (they weren't on symbian for example). * There is a dedicated bearer thread, but when you access the api it goes straight to the plugin right now. * Blocking constructors. Getting the list of configurations may involve a wireless scan. * The API currently lists the available wireless lans, thiago thinks that it should not do this and should say that the device can do wireless. * Should we simply say if we're connected. * We should let people know what type of connection it is. (e.g. roaming / home 3G networks / WLAN) * You don't need to get the proxy info until you're connected. * What about VPN and internet at the same time? * The application doesn't choose what to do, it should be told. * The proxy rules say which proxy to use, the application does not. * When we construct, we should just say 'there's wireless' to make this quicker. * Some apps do need to know if they're connected. * There should be a way to say "I'd like to connect, but it's ok to fail". * We want an api that says "connect silently". * We already have this, you can do it by the network session api. (ConnectInBackground) * Needs a couple of ne
Re: [Development] qtdeclarative CI
This looks like a null pointer crash on exit.* The main thread is processing global destructors. The render thread is presumably trying to use an object that has already been destroyed and set to null when QApplication was destroyed. (or destroyed by a global static destructor) It seems like the render thread needs to be shut down cleanly before / during QApplication destruction. *The fault address of 0x8 suggests a load with offset from the null pointer. This could be trying to access the virtual function table or the d-pointer of a class. (I'm used to seeing 0x4 for null pointer calls to d_func() on ARM - 0x8 could be the same thing on x64) -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Girish Ramakrishnan > Sent: 18 June 2012 16:41 > To: development@qt-project.org > Subject: [Development] qtdeclarative CI > > Hi, > AFAICT, no changes are getting past the qtdeclarative CI. The last > integrated change was 5-6 days back. It's crashing on the Mac. It's now > crashed many times with the same backtrace (in > QQuickRenderThreadSingleContextWindowManager). > > https://codereview.qt-project.org/#change,28741 > https://codereview.qt-project.org/#change,28676 > > Girish > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Can't switch submodules to master and Mac build still broken
You might be able to get the script working by changing the port in your ~/.ssh/config file Host codereview.qt-project.org Port 29418 User (your name) That makes "ssh://codereview.qt-project.org/..." expand to "ssh://(your name)@codereview.qt-project.org:29418/..." In case the script relies on this behaviour. (above configuration was in the gerrit setup wiki page) -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Rohan McGovern > Sent: 17 June 2012 23:41 > To: ext Stephen Chu > Cc: Development > Subject: Re: [Development] Can't switch submodules to master and Mac > build still broken > > Stephen Chu said: > > I still can't get Qt 5 build on OS X for the merged code > > (https://codereview.qt-project.org/#change,28604) hasn't showed up in > > Qt > > 5 git default yet. So I want to to try moving modules to master to > get > > the fixes by the instruction here: > > http://qt-project.org/wiki/Building-Qt-5-from- > Git#181b27e32ae791e987cb > > 19fced190543 > > > > With qt5_tool method I got: > > > > Examining: qt3d url: git://gitorious.org/qt/qt3d.git ### [qt3d] > > /usr/bin/git fetch --all Fetching origin Fetching gerrit > > ssh: connect to host codereview.qt-project.org port 22: Connection > > refused > > This last message indicates something is wrong with the configuration. > It should be attempting to connect to port 29418, not port 22. > > Maybe you can try with standard git commands instead of qt5_tool? > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Build error in bluetooth module on Mac OS X 10.6
> > Proposed real fix is here: > > https://codereview.qt-project.org/#change,28604 > > > > I see that the change has been merged. How long will it be before it > can be pulled from git? I can see it in qtbase master branch but not > yet in > qt5 pull. > These should be the same thing, have you tried 'git submodule update' ? I don't use the qt5.git repository, but that looks like the right command based on reading the git-submodule man page. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Proposed API addition to QTcpServer
Background: If accept() returns an error, QTcpServer may live lock. (QTBUG-24778) The problem as described is that accept() returns EMFILE when quota is reached. On returning to the event loop, select() triggers again because the incoming connection is still pending This prevents other sockets being handled because the server socket is always readable. Proposal: Add a new signal QTcpServer::acceptError When the socket engine's accept() returns an error, the QTcpServer disables read notifications and emits the error signal. Add a new function void QTcpServer::resumeAccepting() The application can call this to restart the server (e.g. after a client disconnects) Add a new function void QTcpServer::pauseAccepting() This allows the application to manually suspend processing of incoming connections. See https://codereview.qt-project.org/28526 Backward compatibility: It doesn't need to be "opt in", because where this situation occurs previously the application would live lock and need to be closed or killed. 5.0 vs 5.1: The issue seems like it should be rare under normal circumstances. (Qt is not a toolkit for high load servers, and the default quota is ~1k file descriptors) However the consequences are severe. It's also a "denial of service" vulnerability, mitigated by the fact that QTcpServer only accepts 30 connections without application interaction (by default) -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Another late API addition in QScreen
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Samuel Rødal > Sent: 05 June 2012 13:30 > To: development@qt-project.org > Subject: [Development] Another late API addition in QScreen > > Hello, > > the current QScreen API forces the platform to always have an > accelerometer sensor or similar running in order to provide > QScreen::orientation() updates, which might lead to wasted resources in > the case of handheld embedded devices. > > As a fix for this I've introduced a new function in QScreen, > setOrientationUpdateMask(), in order force the application to > explicitly have to ask for orientation updates. > > https://codereview.qt-project.org/#change,27981 > Late comment, but should the default have been updates on? Qt 4 behaviour on symbian/harmattan was to have screen rotation be automatic unless opted out from (which was unfortunately a different Qt API on each platform) -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] About the QtDir::currentPath
There are a number of places in src/corelib/io where "C:/" type paths are
handled specially under a windows ifdef.
(or in 4.8 windows/symbian ifdef)
If you want to use windows style paths, you have to add your OS ifdef there as
well.
If the native paths are unix style, i'd recommend to use unix style paths
everywhere though
--
> -Original Message-
> From: development-bounces+shane.kearns=accenture@qt-project.org
> [mailto:development-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of song.7@nokia.com
> Sent: 01 June 2012 09:05
> To: si...@omniqueue.com
> Cc: development@qt-project.org
> Subject: Re: [Development] About the QtDir::currentPath
>
> Ok, thanks... I am using the qfilesystemengine_unix under another unix
> like env, so I can make a change in the ::rootPath for my case...
>
> Thanks for your sharing ;)
>
> Thanks,
> Song
>
> -Original Message-
> From: siv...@gmail.com [mailto:siv...@gmail.com] On Behalf Of ext Sivan
> Greenberg
> Sent: Friday, June 01, 2012 4:02 PM
> To: Liu Song.7 (Nokia-MP/Beijing)
> Cc: development@qt-project.org
> Subject: Re: [Development] About the QtDir::currentPath
> Importance: High
>
> What's your windows version? I can see the code (in qt5) makes
> distinction between WinCE and the rest.
>
> Seeing this respective code:
>
> }
> 998
> 999 //static
> 1000 QString QFileSystemEngine::rootPath()
> 1001 {
> 1002 #if defined(Q_OS_WINCE)
> 1003 QString ret = QLatin1String("/");
> 1004 #else
> 1005 QString ret =
> QString::fromLatin1(qgetenv("SystemDrive").constData());
> 1006 if (ret.isEmpty())
> 1007 ret = QLatin1String("c:");
> 1008 ret.append(QLatin1Char('/'));
> 1009 #endif
> 1010 return ret;
> 1011 }
>
> I would take a wild guess that you're qt thinks it should return paths
> on WinCE instead of 'regular' windows.
>
> -Sivan
>
> On Fri, Jun 1, 2012 at 10:45 AM, wrote:
> > Hi,
> >
> >
> >
> > My QtDir::currentPath is /c_drive/ instead of C:/, so do someone know
> > the reason behind ?
> >
> > And how can it be as "C:/" ?
> >
> >
> >
> > Any information is appreciated ;)
> >
> >
> >
> > Thanks,
> >
> > Song
> >
> >
> > ___
> > Development mailing list
> > Development@qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development
> >
>
>
>
> --
> -Sivan
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] JIRA changes
[snip] > This builds a progressive enablement of system access. > Anonymous - can see issues > Users (Contributors) - can raise and comment on issues, see linked > source code through Fisheye plugin and be assigned issues Current > Assignee - can edit issues and progress them through the workflow > Triager - can assign issues Engineer (Approver) - can do all the > previous roles and some other specialized things like Watcher > management. > [couple of other roles not worth dwelling on at the moment] > > Some more detail on the criteria to become a Triager, the process > involved, the communication mechanism used etc would be appreciated to > complete enabling this capability. I'd suggest nomination by an approver. This covers both the elevation of a user (based on doing the work in JIRA comments but getting somebody else to press the workflow buttons), and delegation to a team member (for larger development teams e.g. in Nokia/Digia) The responsibilities of a Triager are less than an Approver, so the nomination process shouldn't be more difficult. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Approver status
I'm as interested to see insightful review comments as a bulk of contribution. Put another way, anyone can press the +1 button. The comments that go with a -1 inform how good a reviewer somebody is. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt5 binary installers
I can confirm the first issue (debug only plugins built) for source packages. A workaround is to run "nmake release" in the source after building normally. There seems to be an intended feature to build debug AND release for the Qt DLLs, but debug OR release for executables. However it is unintentionally hitting the Qt plugin DLLs as well. -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of qtnext > Sent: 25 May 2012 18:59 > To: development@qt-project.org > Subject: Re: [Development] Qt5 binary installers > > Hi, > > I have tryed windows version sdk : the install works but : > - plugins and import qml have only debug dll ... there is no release > version (all normal dll have release version) .. I have the same issue > building from git on windows. > - plugins to play movie on windows is not build (no directshow version, > no wmf, only audio). I have the same issue building from git source (it > was working previously with alpha I think) > > > > > Le 24/05/2012 07:51, simo.f...@nokia.com a écrit : > > Hi, > > Finally there is some progress with the bin packaging. > > There is now jenkins creating desktop installers twice a day, if > there is change in git. Currently it detects the git 7 am and pm (GMT > +2). > > First it creates the beta src package (http://origin.releases.qt- > project.org/qt5.0-beta-latest/), which is then built on Linux, Win and > Mac. All latest installers can and will be found from here: > > http://releases.qt-project.org/qt5.0-beta-bin-latest/ > > BUT, there is still some buts... > > - The replication to that dir takes a while atm, hopefully we can fix > > it today. Currently there is only one installer from Yesterday > visible > > - Win packages are still pending one additional python module. After > that get installed you should see msvc2010 package in that dir. > > - Mac packages will get enabled as soon as we get the Mac node > online. > > - The used src config, SHOULD be available if one installs also > sources with the installers. I will modify this, and make the sha1 more > clearly visible. > > > > Linux packages are built on Ubuntu 10.04, 11.10 and 12.04. All > > including 64 and 32 bit versions. Windows is 32 bit Win7 (Danimo, > please correct if I'm wrong) Linux binaries are built as shadow from > top level pro file. Running the configure and then running make + make > install for each sub module in the order stated in generated Makefile. > Currently webkit+webkit-examples are the ones which do not compile. Mac > binaries will be built as in src, but also from top level pro file. > Configure + make for each submodule separately. Win binaries are built > with the build perl script. > > > > The installers are based on Installer-framework. Currently the ci is > using static version of it (from Jan), but hopefully we can fix that > also in the future. The SDK packaging scripts and configurations will > be in qtrepotools. Once I get all nodes up an running I will start > bootstrapping those directly from there. Currently those are updated > manually. So as a summary, there is still lots of things to do but now > there is at least something visible. > > > > Simo > > ___ > > 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 Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] NOTE: Gerrit / Codereview upgrade - Service unavailable Thursday May 24, 09:00 - 09:30 CEST
Gerrit is working for me. Your error message suggests that you are connecting to the bastion host, instead of using it as a proxy. The server fingerprint is shown on https://codereview.qt-project.org/#settings,ssh-keys And doesn't match what you have below. -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Carl Schumann > Sent: 24 May 2012 13:51 > To: Matias Rand; development@qt-project.org > Cc: Denise S. Finstrom; Tim Zingelman; James G. Smedinghoff > Subject: Re: [Development] NOTE: Gerrit / Codereview upgrade - Service > unavailable Thursday May 24, 09:00 - 09:30 CEST > > Qt developers, > > I am having some trouble pushing to gerrit: > > clx72:qt $ git push gerrit HEAD:refs/for/4.8 The authenticity of host > > 'outland.fnal.gov (131.225.135.249)' can't be established. > > RSA key fingerprint is > a5:a4:7c:84:74:1e:a9:c6:b1:51:3a:be:13:d5:86:00. > > Are you sure you want to continue connecting (yes/no)? yes > > ssh_exchange_identification: Connection closed by remote host > > fatal: The remote end hung up unexpectedly clx72:qt $ > outland is our bastion host and gerrit is defined by: > > git remote add gerrit > > ssh://c76l68...@codereview.qt-project.org:29418/qt/qt.git > The issue might be on our side, but I am also querying the list because > of the recent maintenance. > > Is this unavailability over? Anyone have indications of problems? > Thanks for any insights please. > > Sincerely, > Carl > > On 5/22/2012 6:52 AM, Matias Rand wrote: > > Hi, > > > > Gerrit (https://codereview.qt-project.org/) will be unavailable while > we deploy a fix. > > > > When: > > Thursday May 24 - 09:00 - 0930 CEST > > > > JIRA issue fixed: > > https://bugreports.qt-project.org/browse/QTQAINFRA-382 > > > > > > Regards > > > > -- > > Matias Rand > > ___ > > 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 Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QUrl fully-decoded path API
I favour proposal 2.
The legacy URL schemes (ftp and file for what we implement) need to deal with
fully decoded fragments.
The less discoverable con is not so much of a con as this API is mainly
required to implement a protocol rather than to use it.
--
> -Original Message-
> From: development-bounces+shane.kearns=accenture@qt-project.org
> [mailto:development-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of Thiago Macieira
> Sent: 14 May 2012 17:29
> To: development@qt-project.org
> Subject: [Development] QUrl fully-decoded path API
>
> Hello
>
> David and I have been discussing for the past week one of the
> consequences of QUrl operating on encoded data only in Qt 5. There are
> a few use-cases where a fully-decoded path is necessary.
>
> == Rationale ==
> (skip to proposal if you find this lengthy)
>
> I've already had to implement the full decoding so that
> QUrl::toLocalFile() would work. But the same process might be necessary
> for non-local files. For example, from qnetworkaccessftpbackend.cpp:
>
> if (operation() == QNetworkAccessManager::GetOperation) {
> setCachingEnabled(true);
> ftp->get(url().path(), 0, type);
> } else {
> ftp->put(uploadDevice, url().path(), type);
> }
>
> If the URL contained a percent-encoded character that QUrl::path()
> doesn't decode, that will remain in the path and sent to the FTP
> server. More than likely, it's not what was intended. The characters
> that the QUrl does not decode under any circumstances are:
>
> - control characters between 0x00 and 0x1F
> - the percent character itself (0x25)
> - the backspace control character (0x7F)
> - high-bit byte sequences that cannot be decoded as UTF-8
>
> Especially because of the last category, the percent sign can never be
> decoded. Those arbitrary binary sequences can appear anywhere in the
> URL's user info, path, query or fragment, and the code dealing with
> them is common.
> Moreover, encoded paths are the correct way to deal with paths when
> dealing with a URL's most common use: HTTP and the web.
>
> (as a twist of fate, the HTTP backend doesn't use QUrl::path(), but
> QUrl::toString(QUrl::RemoveAuthority | QUrl::RemoveFragment) so it gets
> both the path and the query)
>
> The same applies to setting the path. Often, the data comes in a
> decoded form from other contexts, such as user input or an FTP
> directory listing. For those, encoding is necessary, like
> QUrl::fromLocalFile does.
>
> url.setPath(deslashified.replace(QLatin1Char('%'),
> QStringLiteral("%25")));
>
> As David pointed out in an email to me, no one who didn't get a full
> URL training will be able to write the code properly.
>
> == Proposal 1 ==
>
> Add QUrl::decodedPath() and QUrl::setDecodedPath(), operating on
> QString, which do the necessary encoding and decoding.
> QUrl::fromLocalPath will instead call that function instead of doing
> the work above, and QUrl::toLocalPath's extra decoder will be moved to
> the new function.
>
> The documentation will need to be updated to indicate when to use each.
>
> == Problem 2 ==
>
> The same problem that applies to the path can potentially apply to
> other components of the URL: user name, password, fragment and query.
> For example, imagine using the following random-generated password (I
> generated using
> KeePassX):
>
> url.setPassword("}}>b9o%kR(");
>
> The above will trigger the tolerant-mode's corrector and will transform
> the '%' into "%25". However, when trying to send the password to the
> server, for example using QAuthenticator, we might make this mistake
> (copied from
> qnetworkaccessmanager.cpp):
>
> // if credentials are included in the url, then use them
> if (!url.userName().isEmpty()
> && !url.password().isEmpty()) {
> authenticator->setUser(url.userName());
> authenticator->setPassword(url.password());
> [by the way, this code should test if !userInfo().isEmpty(), to catch
> empty passwords too]
>
> Then we ended up setting the password to "}}>b9o%25kR(", which is very
> likely to be incorrect.
>
> == Proposal 2 ==
>
> So instead of adding decodedPath(), decodedUserName(),
> decodedPassword(), etc.
> and cluttering the Qt5 QUrl API like the Qt4 one was, there's a
> separate
> proposal:
>
> - add an option to QUrl::ComponentFormattingOptions to execute full
> decoding
> - add a new value to QUrl::ParsingMode to indicate full decoded
> parsing
Re: [Development] Build failed use MinGW-TDM or MinGW-w64 on Windows
You need to make install after building each module to copy the output to the prefix directory you specified in configure. The top level makefile only works for in-source developer builds. There's also the build.pl script which works for top level builds with some restrictions as specified in the alpha release notes (not sure how many of those issues are solved since then) -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Loaden Sent: 15 May 2012 09:21 To: development Subject: Re: [Development] Build failed use MinGW-TDM or MinGW-w64 on Windows Full configure/build log, please see attachments. 2012/5/15 Loaden mailto:loa...@gmail.com>> Hi, All! I am just try to build Qt5 under Windows, use MinGW-TDM or MinGW-w64 (32bit), but both failed with the same log. I don't know how to fix the problem. Any comments? cd svg\ && mingw32-make -f Makefile mingw32-make[3]: Entering directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg' mingw32-make -f Makefile.Debug all mingw32-make[4]: Entering directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg' g++ -c -fno-keep-inline-dllexport -g -Wall -frtti -fexceptions -mthreads -DQT_SHARED -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_SVG_LIB -DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -D_USE_MATH_DEFINES -DQT_DLL -DQT_HAVE_SSE2 -I"d:\qpSOFT\Projects\BuildQt5-TDM\qtbase\include" -I"..\..\include\QtSvg\5.0.0" -I"..\..\include\QtSvg\5.0.0\QtSvg" -I"..\..\include" -I"..\..\include\QtSvg" -I"..\..\include" -I"tmp" -I"d:\qpSOFT\Projects\Qt5\qtbase\src\3rdparty\harfbuzz\src" -I"d:\qpSOFT\Projects\Qt5\qtsvg\src\3rdparty\zlib" -I"d:\qpSOFT\Projects\Qt5\qtbase\mkspecs\win32-g++" -I"debug" -I"d:\qpSOFT\Projects\Qt5\qtsvg\src\svg" -I"." -I"d:\qpSOFT\Projects\BuildQt5-TDM\qtbase\mkspecs\default" -o debug\qsvggraphics.o d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvggraphics.cpp In file included from d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvgnode_p.h:56:0, from d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvggraphics_p.h:56, from d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvggraphics.cpp:42: d:\qpSOFT\Projects\Qt5\qtsvg\src\svg\qsvgstyle_p.h:65:20: fatal error: qdebug.h: No such file or directory compilation terminated. mingw32-make[4]: *** [debug/qsvggraphics.o] Error 1 mingw32-make[4]: Leaving directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg' mingw32-make[3]: *** [debug-all] Error 2 mingw32-make[3]: Leaving directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src/svg' mingw32-make[2]: *** [sub-svg-make_default-ordered] Error 2 mingw32-make[2]: Leaving directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg/src' mingw32-make[1]: *** [module-qtsvg-src-make_default] Error 2 mingw32-make[1]: Leaving directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtsvg' mingw32-make: *** [module-qtsvg-make_default] Error 2 mingw32-make: *** Waiting for unfinished jobs Project MESSAGE: Warning: unknown QT module: network Project MESSAGE: Warning: unknown QT module: core Project MESSAGE: This project is using private headers and will therefore be tied to this specific Qt module build version. Project MESSAGE: Running this project against other versions of the Qt modules may crash at any arbitrary point. Project MESSAGE: This is not a bug, but a result of using Qt internals. You have been warned! Project MESSAGE: Warning: unknown QT module: network Project MESSAGE: Warning: unknown QT module: core Project MESSAGE: Warning: unknown QT module: network Project MESSAGE: Warning: unknown QT module: core cd xmlpatterns\ && mingw32-make -f Makefile mingw32-make[3]: Entering directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtxmlpatterns/src/xmlpatterns' mingw32-make -f Makefile.Debug all mingw32-make[4]: Entering directory `D:/qpSOFT/Projects/BuildQt5-TDM/qtxmlpatterns/src/xmlpatterns' g++ -c -fno-keep-inline-dllexport -g -Wall -fexceptions -mthreads -frtti -DQT_SHARED -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_XMLPATTERNS_LIB -DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -D_USE_MATH_DEFINES -DQT_DLL -DQT_HAVE_SSE2 -I"d:\qpSOFT\Projects\BuildQt5-TDM\qtbase\include" -I"..\..\include\QtXmlPatterns\5.0.0" -I"..\..\include\QtXmlPatterns\5.0.0\QtXmlPatterns" -I"..\..\include" -I"..\..\include\QtXmlPatterns" -I"..\..\include" -I"tmp" -I"d:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\acceltree" -I"d:\qpSOFT\Projects\Qt5\qtxmlpatterns\src\xmlpatterns\data" -I&q
Re: [Development] #qt-labs IRC channel on irc.freenode.net
> -Original Message- > On Behalf Of André Somers > Sent: 14 May 2012 16:29 > To: development@qt-project.org > Subject: Re: [Development] #qt-labs IRC channel on irc.freenode.net > > Op 14-5-2012 17:26, Carl Schumann schreef: > > Qt developers, > > > > I am struggling to access the #qt-labs IRC channel on > > irc.freenode.net. I am on a Windows Machine. Any recommendations > for > > a Windows IRC client please? Thanks for any help. > > > > Sincerely, > > Carl Schumann > > > > I use Quassel IRC, which works well for me. Are you sure it's not your > network policies blocking IRC though? > If you need to use a proxy: Quassel can do that, but the setting is hidden in an advanced tab when you edit a server. There is a list of alternate servers and ports at http://freenode.net/irc_servers.shtml -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] unity3d plugin in QML webview
There was a similar issue with QtMultimedia and video windows. With QWidget, you can get a native WinId and use that to create the child windows. With QGraphicsItem, only the top level QGraphicsView has a WinId, not the individual items which are always non native. (sorry I don't have more details, but it should be possible to find out how that was solved by looking at the sources and commit logs) I'd suspect the plugin is calling functions which are stubbed or return incorrect values for the QGraphicsWebView implementation. -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Mülner, Helmut Sent: 14 May 2012 10:53 To: development@qt-project.org Subject: [Development] unity3d plugin in QML webview The unity3d plugin (e.g. http://download.unity3d.com/gallery/live-demos/players/island.unity3d ) works with QWebView but not in QGraphicsWebView or in a QML WebView. The plugin uses three stacked windows on top of the web page and I suspect that something in the QGraphicsView prevents the creation of those windows. I have reported this in the Qt bug tracker (https://bugreports.qt-project.org/browse/QTBUG-25705).<https://bugreports.qt-project.org/browse/QTBUG-25705%29.> Does anybody know what could cause this? -- Helmut Mülner DIGITAL - Institute of Information and Communication Technologies JOANNEUM RESEARCH Forschungsgesellschaft mbH Steyrergasse 17, 8010 Graz, AUSTRIA phone: +43-316-876-2612 general fax: +43-316-876-1191 web:http://www.joanneum.at/digital e-mail: helmut.mül...@joanneum.at<mailto:helmut.mül...@joanneum.at> Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enable Exceptions for Windows CE as default
> -Original Message- > From: Olivier Goffart [mailto:oliv...@woboq.com] > Sent: 11 May 2012 12:53 > To: Kearns, Shane > Cc: lars.kn...@nokia.com; development@qt-project.org > Subject: Re: [Development] Enable Exceptions for Windows CE as default > > On Friday 11 May 2012 11:01:38 shane.kea...@accenture.com wrote: > > You would also need to disable exceptions in STL. > > MSVC will link exception and no exception code without a warning. > > > > Exception thrown from exception handling DLL or object file to non > > exception using main() results in a crash and call to terminate() > > > > Exception thrown through a non exception handling DLL or object file > > is caught, but with intermediate destructors not called. > > > > i.e. with this proposal, if application code calls a Qt function > > inside a try block, and throws an exception from application code > > callback or plugin code, it may silently fail by catching the > > exception but the intermediate stack objects of the Qt code not > having been cleaned up. > > That is assuming those Qt functions as exceptions safe. But we don't > really offer such garentee anywere except in few QtCore classes. Most > of the code is not exception safe and will leak or produce undefined > behaviour in case of exceptions. > > Exceptions are not supposed to cross the Qt layers. (Unless explicitly > documented as working) > > Regarding the STL, the only sensible exception that might be thrown by > the STL is std::bad_alloc (The other ones are not supposed to happen). > And handling OOM error is IMHO pointless in a gui application (too > difficult, unstested, unreliable, don't get me started on this...) > I'm talking about Qt compiled without exception handling in MSVC ( CL /Eh-c- compiler option) Although I only tested this with 3 functions compiled as separate libraries. main() calls bar() which calls foo() main() and foo() are compiled with exception support bar() is compiled without exception support If main() has a try block and foo() throws an exception main() catches the exception stack objects from main() and foo() are cleaned up stack objects from bar() are leaked Mingw32 4.6.2 (which seems to use setjmp/longjmp for exception handling) behaves the same as MSVC2010 (which uses windows SEH) Now another compiler could choose to call terminate() here instead (detecting exception has passed through code without exception handling). Or just crash - it's undefined behaviour. When all the libraries are compiled with exceptions enabled, the behaviour is defined by the language - although any given code path may not be exception safe due to the program. The ARM ABI for exceptions includes an exception handling table as part of the ELF file. RVCT4.0 does not produce linker warnings for mixing exception & no exception code, but I don't know the behaviour at run time. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Enable Exceptions for Windows CE as default
You would also need to disable exceptions in STL. MSVC will link exception and no exception code without a warning. Exception thrown from exception handling DLL or object file to non exception using main() results in a crash and call to terminate() Exception thrown through a non exception handling DLL or object file is caught, but with intermediate destructors not called. i.e. with this proposal, if application code calls a Qt function inside a try block, and throws an exception from application code callback or plugin code, it may silently fail by catching the exception but the intermediate stack objects of the Qt code not having been cleaned up. -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of lars.kn...@nokia.com > Sent: 10 May 2012 21:18 > To: oliv...@woboq.com; development@qt-project.org > Subject: Re: [Development] Enable Exceptions for Windows CE as default > > On 5/10/12 5:13 PM, "ext Olivier Goffart" wrote: > > >On Thursday 10 May 2012 07:10:51 lars.kn...@nokia.com wrote: > >> On 5/10/12 4:20 AM, "ext Thiago Macieira" > > >> > >> wrote: > >> >On quarta-feira, 9 de maio de 2012 21.39.53, lars.kn...@nokia.com > >>wrote: > >> >> How about this then? > >> >> > >> >> https://codereview.qt-project.org/#change,25788 > >> >> > >> >> https://codereview.qt-project.org/#change,25787 > >> > > >> >Yes, something like that. I'm not sure we should do it on 5.0 > though. > >> > >> At least as an option I'd like to have it for 5.0. But I can't see > >>how it can break things given that QtCore has exceptions enabled. In > >>addition, we disable them only when compiling Qt modules, not when > >>compiling app code. > >> So I would rather try it for the beta and see whether we get any > >>feedback about issues with it. > >> > >> My only concern is whether enabling/disabling exceptions changes the > >> ABI on any platform/compiler. > > > >At least with GCC, this should be safe (provided applications don't > let > >exceptions go trough the Qt layer) > > Yes, it's safe with gcc/ELF, I was more wondering about MSVC. > > >There is also QtConcrrent which is not part of QtCore anymore and has > >some exception handling possibilities. > > At least currently it doesn't use any try/catch statements. > > > >And I think -no-exception could stay to disable exception even in > >QtCore if someone still want to reduce the footprint > > I'm not sure it's worth it. We probably gain more by removing one more > configuration option that we'd otherwise need to maintain and test. > > If we really want to remove that overhead the better option would > probably be to only compile the files that need it with exceptions > enabled. > > Cheers, > Lars > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Which "Target Repository" to use for a Merge Request?
https://bugreports.qt-project.org is correct for bugs in Qt. The link you followed is for reporting bugs on the codereview tool itself. -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Carl Schumann > Sent: 10 May 2012 15:35 > Cc: development@qt-project.org; inter...@qt-project.org > Subject: Re: [Development] Which "Target Repository" to use for a Merge > Request? > > Qt Community, > > At https://codereview.qt-project.org I notice a link, "Report Bug", in > the lower right corner. When I click on this link it takes me to: > http://code.google.com/p/gerrit/issues/list > Instead of where I originally reported my bug report: > https://bugreports.qt-project.org > These don't appear to be equivalent, so which one should I be using > please? I am guessing that the documentation that lead me to > bugreports.qt-project.org is out of date, correct? Thanks again for > any help. > > Sincerely, > Carl Schumann > > > On 5/10/2012 8:26 AM, shane.kea...@accenture.com wrote: > > Hi Carl, > > > > We moved to using gerrit code review for patches instead of merge > requests. > > You'll need to register at https://codereview.qt-project.org and > accept a contribution license agreement before you can push changes. > > > > Instructions are at http://wiki.qt-project.org/Setting_up_Gerrit and > > http://wiki.qt-project.org/Gerrit_Introduction > > > > > > -- > > > > > >> -Original Message- > >> From: development-bounces+shane.kearns=accenture@qt-project.org > >> [mailto:development-bounces+shane.kearns=accenture.com@qt- > project.org > >> ] > >> On Behalf Of Carl Schumann > >> Sent: 10 May 2012 13:49 > >> To: development@qt-project.org; Qt Interest List > >> Subject: [Development] Which "Target Repository" to use for a Merge > >> Request? > >> > >> Qt Community, > >> > >> On 8 May 2012 I submitted a bug report: > >> > >> https://bugreports.qt-project.org/browse/QTBUG-25691 > >> > >> I have a proposed fix which I am trying to submit. I used the > >> following documentation in my attempt: > >> http://wiki.qt-project.org/Git_Introduction > >> > >> I am now to the point in the above documentation's procedure where I > >> am told to make a merge request. When I do so I get a form that > asks > >> me to > >> specify "Target Repository". There are many possible options, > e.g., > >> icefox. The documentation does not indicate which one I should > chose. > >> I would appreciate some explanation please. Thanks for any help. > >> > >> Sincerely, > >> Carl Schumann > >> > >> > >> > >> > >> ___ > >> Development mailing list > >> Development@qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > Subject to local law, communications with Accenture and its > affiliates including telephone calls and emails (including content), > may be monitored by our systems for the purposes of security and the > assessment of internal compliance with Accenture policy. > > > __ > > > > > > www.accenture.com > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Which "Target Repository" to use for a Merge Request?
Hi Carl, We moved to using gerrit code review for patches instead of merge requests. You'll need to register at https://codereview.qt-project.org and accept a contribution license agreement before you can push changes. Instructions are at http://wiki.qt-project.org/Setting_up_Gerrit and http://wiki.qt-project.org/Gerrit_Introduction -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Carl Schumann > Sent: 10 May 2012 13:49 > To: development@qt-project.org; Qt Interest List > Subject: [Development] Which "Target Repository" to use for a Merge > Request? > > Qt Community, > > On 8 May 2012 I submitted a bug report: > > https://bugreports.qt-project.org/browse/QTBUG-25691 > > I have a proposed fix which I am trying to submit. I used the > following documentation in my attempt: > http://wiki.qt-project.org/Git_Introduction > > I am now to the point in the above documentation's procedure where I am > told to make a merge request. When I do so I get a form that asks me > to > specify "Target Repository". There are many possible options, e.g., > icefox. The documentation does not indicate which one I should chose. > I would appreciate some explanation please. Thanks for any help. > > Sincerely, > Carl Schumann > > > > > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Bugreports for Playground projects
This sounds like something we should have. e.g. QTPLAYGROUND as the project (instead of QTBUG) and one or more components for each playground project. Does anyone from the JIRA experts group have a comment? -- > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Denis Shienkov > Sent: 02 May 2012 18:06 > To: development@qt-project.org > Subject: Re: [Development] Bugreports for Playground projects > > Hello all. > > I am also interested in this question. > > Say please, where and how can get a bug-tracker for projects from a > playground? > Is this possible? > > Without such features are very hard to make a contribution to the > development. > > For example, users are forced to send bugs to the forums (which are > sparse) or e-mail to the developers, which is not good. > > It would be better for this to have a general tracker, IMO. > > Best regards, > Denis > > > > >Hey, > > > >JIRA does not currently have entries for playground projects (for > >instance a playground project, and then the relevant components). Is > it > >possible to ask for something like that, or is there a better approach > >? JIRA addition would probably require the extension on demand when a > >gerrit project entry is added for instance. The removal would for > >example happen when the project graduates from playground. > > > >I do not see any mentionings here about handling bugreports: > >http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt > > > >Best Regards, > >Laszlo Papp > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] API review - proposed renaming of QAbstractSocket::PauseOnNotify to PauseOnSslErrors
https://codereview.qt-project.org/24905 Although we created an enum for pause modes to make 5.x binary compatible with 5.0, the enum value is not well named. In 5.1, we propose to add PauseOnProxyAuthentication to the enum. PauseOnNotify is not clear what it means, while PauseOnSslErrors is. Any new notification in a minor release would need a new enum value otherwise applications would get pauses they did not expect. This is a new API in 5.0 so the change would be source incompatible with the alpha release, but not with any 4.x releases. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Where is the QtLocation history?
Not sure if it's what you're looking for, but some old history is in git://qt.gitorious.org/qt-mobility/qt-mobility.git in src/location. -- From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Stephen Kelly Sent: 26 April 2012 21:23 To: development@qt-project.org Subject: [Development] Where is the QtLocation history? Hi, I tried to help on this thread: http://thread.gmane.org/gmane.comp.lib.qt.user/1782 and found that most of the significant QtLocation history is squashed into a single commit 5f42e961560a54a2d3978b42478cd90bc8c6927d. Where are the individual commits for that? I'm sure it will be needed again in the future. Thanks, -- Stephen Kelly mailto:stephen.ke...@kdab.com>> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com<http://www.kdab.com> || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Qt addons in gerrit - separate namespace or not?
Simple question, do we want the qt/ namespace to be for essentials only, or also for addons. e.g. should the path to an addon be: ssh://codereview.qt-project.org:29418/qt/qtftp or ssh://codereview.qt-project.org:29418/qtaddon/qtftp There are currently addons in qt/ and qt-labs/ but these were created early on before the playground/ namespace was created for research projects. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
> Random question of the day: do you happen to have stats about how often > those insignificant tests actually fail? That should help to figure out > which ones are actually working, and therefore should not be marked as > insignificant. > > -- > Giuseppe D'Angelo The CI logs are publicly available, but are huge in size. I've been using the attached perl script to run tests repeatedly before removing insignificant_test. e.g. "~/test100.pl -c=250 -- ./tst_x -silent" -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com test100.pl Description: test100.pl ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Towards a Qt 5 beta
Another way tests have been disabled is using CONFIG += no_check_target which
seems to have been done when tests were initially disabled before the
insignificant_test option was added.
e.g. auto.pro has this:
# disable 'make check' on Mac OS X for the following subdirs for the time being
mac {
network.CONFIG += no_check_target
}
If you're a mac developer and have time, please check which of the network
tests really need to be disabled.
--
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
> Go for option 1. > > It's not any more effort than the others, unless we decided to build > one single library (which isn't what you said). Agreed. Based on the guidelines in http://wiki.qt-project.org/Creating_a_new_module_or_tool_for_Qt We should have two Qt addon projects created in gerrit: "Qt Ftp" (qtftp.git) hosting the QFtp class "Qt Http" (qthttp.hit) hosting the QHttp class Retaining the Q for source compatibility with Qt 4. License should be the same as Qt Base, as the code is being moved from there. -- Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
Ok, there are three options I can see and we need to choose one. 1. One add-on for each removed API (e.g. qftp.git, qhttp.git) 2. One add-on for each module (e.g. qt4network.git) 3. A catch-all kitchen sink repository (e.g. qt4support.git) We promised this when removing the APIs, and again in the Qt5 alpha announcement. The code needs to be available by the time we release the beta. Each API builds as a separate (static) library using only public exports of Qt5. (QHttp has a renamed private copy of QAuthenticator and QRingBuffer) > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Oswald Buddenhagen > Sent: 29 March 2012 16:48 > To: development@qt-project.org > Subject: Re: [Development] Qftp removal > > On Thu, Mar 29, 2012 at 02:20:04PM +, ext > shane.kea...@accenture.com wrote: > > It may not be trivial, but it's the workflow we have defined for > promoting a playground module to an official add-on. > > > yeah. too bad our tool doesn't support that particularly well yet. > > > Would it be any more complex than creating a new project (initialised > > with the contents of the previous project repo, rather than empty) > and > > deleting the old project? > > > deleting projects is not supported, either. every change of structure > will leave a dead repo behind, which clutters up the project overview > (happy admining) and the server. > > > And we've created projects with pre-existing git history before, when > importing the Qt5 modules to gerrit. > > > that's entirely different. they had no previous gerrit history. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
It may not be trivial, but it's the workflow we have defined for promoting a playground module to an official add-on. Would it be any more complex than creating a new project (initialised with the contents of the previous project repo, rather than empty) and deleting the old project? And we've created projects with pre-existing git history before, when importing the Qt5 modules to gerrit. > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Oswald Buddenhagen > Sent: 28 March 2012 17:56 > To: development@qt-project.org > Subject: Re: [Development] Qftp removal > > On Wed, Mar 28, 2012 at 04:17:36PM +, ext > shane.kea...@accenture.com wrote: > > If there are other Qt4 classes that would benefit from this approach, > we can rename the repo later. > > > well, no, we cannot (without major hassle) - gerrit doesn't support > renaming. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
(Thread necromancy) As there was no consensus on the repo naming, let's use the original suggestion. I already ported these classes to two static libraries. If there are other Qt4 classes that would benefit from this approach, we can rename the repo later. > -Original Message- > From: lars.kn...@nokia.com [mailto:lars.kn...@nokia.com] > Sent: 11 January 2012 14:49 > To: Kearns, Shane; thiago.macie...@intel.com; development@qt- > project.org > Cc: sergio.ahum...@nokia.com > Subject: Re: [Development] Qftp removal > > Yes, please. We need a name for it. How about qtnetwork4 ? > > I people are ok with the name, can you add the repo, Sergio? > > Who'd be willing to import the code and examples into that repo? Shane? > > Thanks, > Lars > > On 1/11/12 3:26 PM, "ext shane.kea...@accenture.com" > wrote: > > >Can we get an addon module (project in gerrit) for putting standalone > >implementations of these removed features? > >I wouldn't expect a huge amount of commits, but the code (and > >associated > >examples/tests) needs to be moved there and converted from dll exports > >to static libraries. > > > >> -Original Message- > >> From: development-bounces+shane.kearns=accenture@qt-project.org > >> [mailto:development-bounces+shane.kearns=accenture.com@qt- > project.org > >> ] > >> On Behalf Of lars.kn...@nokia.com > >> Sent: Monday, December 26, 2011 10:18 > >> To: thiago.macie...@intel.com; development@qt-project.org > >> Subject: Re: [Development] Qftp removal > >> > >> On 12/24/11 12:24 PM, "ext Thiago Macieira" > >> > >> wrote: > >> > >> >On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote: > >> >> I've been using it for a year now, have had no problems on Linux > >> >>and Windows. I use it to check for application upgrade. Is > there > >> >>a recommended way to do FTP transfers when QFtp is gone. Any > >> >>chance of QFtp getting into Qt Commercial ? > >> > > >> >Qt Commercial and Qt Open Source are the same. If it's removed from > >> one, > >> >it's > >> >removed from both. We can probably place it in a separate module > for > >> >people who still need it. > >> > >> Yes, the code is there and while we really need to remove it from > >> QtNetwork, we should provide a way for people to use it in their > >> projects. > >> IMO a static lib containing both QHttp and QFtp could be a solution. > >> > >> Cheers, > >> Lars > >> > >> > > >> >The recommended way is to use QNetworkAccessManager, which does not > >> have > >> >API > >> >for listing directories. > >> >-- > >> >Thiago Macieira - thiago.macieira (AT) intel.com > >> > Software Architect - Intel Open Source Technology Center > >> > Intel Sweden AB - Registration Number: 556189-6027 > >> > Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden > >> >___ > >> >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 > > > > > > > >Subject to local law, communications with Accenture and its affiliates > >including telephone calls and emails (including content), may be > >monitored by our systems for the purposes of security and the > >assessment of internal compliance with Accenture policy. > >__ > _ > >___ > > > > > >www.accenture.com > Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Why we need some CMake file of Build Or Install Qt?
Hi Stephen, I can confirm - I have a c:\cmake directory created. Based on the date, I think it came from building the alpha package. It contains one folder (Qt5) with two files, Qt5Config.cmake and Qt5ConfigVersion.cmake. Qt config line was "configure -opensource -confirm-license -nomake tests" Alpha package was unzipped to c:\dev\qt\qt-everywhere... From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Stephen Kelly Sent: 22 March 2012 10:15 To: development@qt-project.org Subject: Re: [Development] Why we need some CMake file of Build Or Install Qt? On Thursday, March 22, 2012 11:14:22 Stephen Kelly wrote: > On Thursday, March 22, 2012 10:05:40 Loaden wrote: > > D:\cmake\Qt5\Qt5Config.cmake > > > > D:\cmake\Qt5\Qt5ConfigVersion.cmake > > > > D:\qpSOFT\Sources\Qt5\qtbase\mkspecs\cmake\Qt5BasicConfig.cmake.in > > D:\qpSOFT\Sources\Qt5\qtbase\mkspecs\cmake\Qt5ConfigVersion.cmake.in > > ... > > There are two odd things here: The file shouldn't be named Qt5Config.cmake, > and the location shouldn't be D:\. > > Can you tell me what the installation prefix is? > How did you build Qt? Using qt5.git? > Do you have cmake files in your build directory too? > > Can you send me the generated files? > Oh, and can anyone else on this mailing list confirm the same bug? Thanks, -- Stephen Kelly mailto:stephen.ke...@kdab.com>> | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com<http://www.kdab.com> || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Three issue about Qt5 alpha
Hi Loaden, Thanks for your help testing the alpha release. Issue 3 has already been reported - the workaround is to run "nmake release" to build the release binaries. For some reason the default target only builds the debug binaries. I've copied the "releasing" list, where alpha issues are being discussed. From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Loaden Sent: 20 March 2012 03:58 To: development@qt-project.org; qt-crea...@qt-project.org Subject: [Development] Three issue about Qt5 alpha Issue 1: Wrong behaviour when parse qt.conf See https://bugreports.qt-project.org/browse/QTBUG-24839 Issue 2 (I am not sure this is or not?): After build in Qt source, I choice install qt to other place, e.g. Qt Source Dir = D:\Qt5 Qt Install Root = D:\Dev\Qt5 Use command: nmake install INSTALL_ROOT=\Dev Then rename D:\Qt5 to D:\Qt5_bak, will lead can't run qtdesinger.exe, or qhelpgenerator.exe D:\qpSOFT\DEVx86>qhelpgenerator No platform plugin argument was specified and the default plugin "windows" is not available D:\qpSOFT\DEVx86>qmlplugindump No platform plugin argument was specified and the default plugin "windows" is not available D:\qpSOFT\DEVx86>qmlviewer D:\qpSOFT\DEVx86>qmlviewer D:\qpSOFT\DEVx86>qttracereplay No platform plugin argument was specified and the default plugin "windows" is not available D:\qpSOFT\DEVx86>qttracereplay It's mean we must have a qt.conf file put into D:\Dev\Qt5\bin, the qt.conf set a Paths/Prefix for Qt library. After this done, issue 2 should gone. Issue 3: If configure with -debug-and-release option, I found in the final, almost all qt tools is a debug version. But it's should be release version, e.g. qdoc.exe, moc.exe... And can't find window5.dll, only windowd5.dll? Why we lose the release version of this plugin? Any comments are welcome! -- Regards Loaden Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] The qtbase CI should run the qtdeclarative tests
> For http://codereview.qt-project.org/#change,19591 I requested at test, > but apparently there's some IPv4 vs 6 special configuration needed for > it to make sense. I don't know why the test can't be in qtbase; the > TestHTTPServer that was crashing in qtdeclarative is running on the > local host, I don't think it's doing anything super-special. But I'm > not a network guy. :) > The http network test (tst_qnetworkreply) is still disabled in CI on all platforms because of a hard to reproduce crash on exit (1/200) Mostly we test QNetworkAccessManager against the test server rather than localhost (to test Qt against other implementations rather than only against itself) However if you have a suitable loopback test case for this, I'd welcome it. The test server requires an upgrade before we can do dual stack testing against it. The danted* SOCKS proxy doesn't support IPv6 (SS5** does, but isn't available as a package, only a source tarball) The squid3 HTTP proxy needs a package update and configuration change Apache needs a configuration change Vsftpd needs a configuration change, possibly a package update The frox FTP proxy doesn't support IPv6 (I have not looked for an alternative.) FTP is not network layer transparent Also, it needs IPv6 address for qt-test-server in the hosts file of the DUT, which isn't convenient with link local addresses. I do want this to happen, but getting the existing autotests re-enabled is higher priority. *We're also using an ancient version, the current 1.1.19 results in some XPASS but also some FAILs due to regressions on the server side. ** I have no idea of the quality or stability of this implementation Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qt Playground - Command Line Parser experiment
I would like an argument parser in Qt, and I'd like it to be in qtbase. The reason for qtbase is so that our own tools and manual tests can use it. Manual tests outside of qtbase are normally GUI based. I think this is something that can go into a minor 5.x release. About windows: Tools that use / for arguments also accept - (except the built in shell commands) The / can be used for both short and long arguments (e.g. "nmake /nologo" vs "nmake /kc" vs "nmake /k /c") Arguments may be case insensitive The command line is pretty much only used by technical people (buried 3 levels deep in the app menu), who would probably accept unix style args. If we want to support windows style: Use Qt::CaseInsensitive to opt in to case insensitive args Print a qWarning if the arguments could be ambiguous (assuming the API declares the possible arguments up front like perl's GetOpt::Long) Allow opt out from short argument compression (i.e. "/xzf" would only be considered as a synonym for "--xzf" and not for "-x -z -f" if the opt out is applied) > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Mark Constable > Sent: 15 March 2012 10:29 > To: development@qt-project.org > Subject: Re: [Development] Qt Playground - Command Line Parser > experiment > > Any simple standard cli args parser included with Qt would be > overwhelmingly > better than none at all even if it's just -s shortops (/s for win) and > worry > about --longopts and tar-like variations for Qt6+. The simpler the > better as > long as it's universally available in qtcore, if possible, sooner than > later. > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Windows: Qt5 does not run the application in release mode.
Hi Denis, It looks like the plugins are only built for debug mode. In qtbase/plugins/platform, there are only windowsd5.* files, and not the windows5.* files for release mode. This problem is repeated through the other plugin directories. The missing plugins can be built by running “nmake release” From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Denis Shienkov Sent: 13 March 2012 19:16 To: development@qt-project.org Subject: [Development] Windows: Qt5 does not run the application in release mode. Hi all. I can not run GUI application built in "Release" mode. In the console displays the error: "No platform plugin argument was specified and the default plugin "windows" is not available" What could it be? PS: Qt5 (qtbase) built in Win7 x32 with Windows SDK 7.1: set QTDIR=c:\Qt\qt5-build\qtbase set PATH=%QTDIR%\bin;%PATH% c:\Qt\qt5-src\configure ^ -developer-build ^ -opensource ^ -nomake examples ^ -nomake demos nmake module-qtbase Best regards, Denis Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
> On Fri, Mar 09, 2012 at 07:16:24PM +, ext > shane.kea...@accenture.com wrote: > > > > (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix > > \ > > fix(rc2)-fix(v4.8.1) > > > this is no option, because it "loses" the tag from the history. > "traditionally" we have merged back the release branch to the > maintenance branch (and thus to master), which means that we have all > those cherry-picks twice in the history. try to read *that*. > therefore the only clean options are either a) just don't create a > branch or b) if you create a branch, then apply any fixes which are > supposed to be in it *only* to that branch, so it can be cleanly > forward-merged. > The full picture including the merge back would look like: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix-o-o-o-M \ / fix(rc2)-fix(v4.8.1)-. The tag has to be on the branch (if there is a branch), otherwise "git checkout v4.8.1" doesn't give the same thing as the release tarball. Tools that show the history including branches (e.g. gitk) would give a picture like what's above, "git log" will show the cherry picks twice in the history. The history is unreadable for v4.8.0 because of the 7 parallel staging branches, but displaying two parallel branches (4.8 and 4.8.1) should be sane and readable. I believe that "git log v4.8.1.." includes the commits which came in with the merge (anything on 4.8 but not on 4.8.1 branch) Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Releasing] Qt 4.8.1 open source release date approaching..
> This was discussed earlier, and we were thinking about using a branch. > It > was decided that we will try without. The basic idea is that at any > time > the code should be good to use. Naturally it is not always so, thus we > may > need to take another try. > > We have nothing against using a branch, but it is not mandatory either. > At > least not for patch releases. > > Tag we will naturally do, so that it is easy to know what is the exact > release version. > Summary of an IRC discussion: Currently this SHA is being tested (logically it is 4.8.1-rc1) If all goes well, we can just release that SHA and tag it with v4.8.1 If there is a blocking defect (e.g. serious regression from v4.8.0), then we'd need to fix that. However, other changes have already happened on the 4.8 branch, giving this situation: (rc1)-o-o-o-o-o-o-fix The intermediate commits (-o-) are ordinary bug fixes that can go to 4.8.2. Hopefully they don't introduce regressions themselves, but it is possible. The choice then is whether to take the intermediate commits and restart testing: (rc1)-o-o-o-o-o-o-fix(rc2) Or to create a 4.8.1 release branch, cherry pick the fix, and continue testing: (rc1)-o-o-o-o-o-o-fix \ fix(rc2) Either way, whatever rc is good enough to release is what gets released and tagged. The final situation looks like one of these: (rc1)-o-o-o-o-o-o-fix(rc2)-o-o-o-o-o-o-fix(v4.8.1) Or: (rc1)-o-o-o-o-o-o-fix-o-o-o-o-o-o-fix \ fix(rc2)-fix(v4.8.1) The best case is that rc1 has no showstoppers and we can just release it. The opinion among those who were in the irc discussion was that we should create a branch and cherry pick if there are showstoppers. It was pointed out that branches in git are cheap, so we could have created a 4.8.1 branch already (with no commits, except the HEAD points at the SHA being tested). However, branches in gerrit may not be so cheap as only a few people can create branches on the server. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] where can I get the lastest source code?
> > now the Qt4 version is not developed? > > and I only get the lastest version from > git://gitorious.org/qt/qtbase.git ?? > The Qt4 repository is still at git://gitorious.org/qt/qt.git Bug fixes can still go there for 4.8.x patch releases. The modular repositories (e.g. qtbase) are only for Qt5 onwards. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] (long) thoughts on categorized logging (qLog)
> Home path might not be the best as it could intermingle with other > files that belong to the user. > > On *nix, QDir::homePath() that would be /home/ and users see > that directory a lot, and it will get intermixed with other files. > On Windows, most users have no clue about %userprofile%, so its not an > issue there. > This is less true on windows 7. The start menu (if it's still called that) has links to , documents, pictures and music (c:\users\username, c:\users\username\documents ... etc, subject to localisation) Where the first one is the same as %userprofile% (and QDir::homePath()) points to. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] (long) thoughts on categorized logging (qLog)
>
> well, it probably shouldn't be in CWD regardless of platform.
Agreed, unless you're specifying the log file via a command line parameter
>
>
> On Windows, I'd suggest %APPDATA%\ or at minimum
> %APPDATA%.
> You might even get away with using %TEMP%; but it'd be harder to find
> the log then.
>
> On other platforms, something under ${HOME} .
>
I don't recommend using the temp path on windows, it usually contains hundreds
of files. (and is inside appdata\local by default)
The appdata area is organized by application, however it is a hidden folder.
There's also the local/roaming split for appdata which isn't obvious for cross
platform developers.
The intent of appdata seems to be data that belongs to the application rather
than the user (e.g. settings, persistent data)
As logging is mainly for developers, using QDir::homePath() as the default
everywhere might be ok.
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
> -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Thiago Macieira > Sent: 13 February 2012 19:27 > To: development@qt-project.org > Subject: Re: [Development] Default enabling inbound flow control on > sockets > > As you said yourself, there's a huge potential for regressions here, > especially with a limit as low as 64k. So I am unsure whether we should > do this at all. > > We could apply a high buffer size, like 1 MB. That's probably enough to > contain most data files being downloaded and yet avoid exploding by > OOM. On a modern embedded system, an application would need to be > downloading 50 items in parallel (which means from at least 9 different > servers) before it started to get into trouble. > I'm also not convinced we should do this yet, but some more thoughts on the subject. When using the high level (QNetworkReply) API, you are dealing with objects. Intuitively, downloading a 100MB file will allocate 100MB of memory unless you take steps to prevent this. You might get more or less data than you were expecting, if the object on the server has changed. Regressions are likely, because downloading a complete object and then processing it would be a common usage. When using the low level (QTcpSocket) API, you are dealing with a stream. Intuitively, you would expect the stream applies flow control and rate limiting by itself. If using native apis (either synchronous or asynchronous) on all platforms, this is what happens. The exact amount of buffering in the OS level varies between platforms. With QTcpSocket, this does not happen, because Qt reads all available data from the OS into its own buffers each time the event loop runs socket notifiers. Regressions are less likely, because socket using code is normally processing the stream as it arrives. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changes to the Jira roles and workflow
Maybe you're looking at a "triage" role, if the role is prioritizing and assigning of tasks among a team that is mostly funded by one company. Another role we need in JIRA is "contributor". This is somebody who is not a reviewer, but can still be assigned tasks & transition their assigned tasks through the normal workflow. Ideally, anyone who has had a patch accepted should be given this level of access if they want it.* For example, to work on bugs related to code they previously submitted. Also, this covers most Nokia (or other organization) engineers who are not approvers. I'm hoping abuse of JIRA privileges is rare, but it should also be easy to revoke them if needed. *Some people will contribute a patch for a bug they found in their project that uses Qt, and we don't want to discourage this by giving unwanted responsibility. > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Alan Alpert > Sent: 09 February 2012 22:26 > To: development@qt-project.org > Cc: j...@qt-project.org > Subject: Re: [Development] Changes to the Jira roles and workflow > > On Thu, 9 Feb 2012 12:58:40 ext marius.storm-ol...@nokia.com wrote: > > Hi, > > > > ... > > > > > > There is some discussion over if we should burden maintainers with > Release > > Management work. > > > > There is a suggestion of a new workflow "Nokia Engineer" - no > privileges in > > Gerrit only in Jira. > > That role might be useful, but please don't call it "Nokia Engineer". > Even if > we don't expect anyone to ever volunteer to do task management roles, > Qt as an > open project could grow to other companies. Calling it "Task Manager" > or > "Issue Secretary" (or something along those lines that's not a joke ;) > ) will > mitigate the risk of having to change the name again later. > > > > > ... > > > > > > Default Assignee > > > > There is call for discussion around default assignee - is it the > module > > maintainer? Which tasks are up for grabs if everything new goes to > the > > maintainer? > > The theory I was taught was that you don't use your 'tasks assigned to > me' > list as your list of your in-progress bugs. You use your 'tasks > assigned to me > and listed as in-progress' for that list. So assignment merely means > "If > someone's going to look at this bug, it'll probably be this guy first". > If > you're working on a bug and don't want people to take it away, you mark > it as > in-progress. Then the tasks which are up for grabs are the ones > assigned to > the maintainer (or anyone, actually) which are not marked as 'in- > progress'. > > On the 'unassigned' suggestion, I think that could only work if there's > an > easy way to find the correct maintainer for a component. Currently the > table > in qt-project contains some data, which is nice, but it's just not > convenient > enough or obvious enough to work with JIRA. Default assignee has > basically > been the way people find maintainers for bug reporting (at least), if > you take > that away then something else is needed. > > -- > Alan Alpert > Senior Engineer > Nokia, Qt Development Frameworks > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
> > Not sure. Is it a big problem? Or is it better to just continue as is, > and let the applications that do have a problem set it to something > reasonable to them instead? > > I'd probably suggest that we instead improve the output on that worst > case failure to help devs fix the problems in their programs. > > $0.02 > > Ben qWarning allocates memory, so once the worst case happens, we can't give any output (unless we first handle the exceptions inside Q*Socket) It would be possible to print a warning when buffering exceeds some threshold we consider to be unreasonably large. We can also improve the documentation (it's not bad, but doesn't mention flow control explicitly) https://bugreports.qt-project.org/browse/QTBUG-14464 seems to be explained by missing flow control causing out of memory errors under load. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Default enabling inbound flow control on sockets
You've correctly understood the problem, but the scale is less bad (takes a couple of minutes to exhaust 2GB limit of a 32 bit process using a loopback connection) Changing the default would mean behavior is the same as if you called setReadBufferSize(65536) in the application. Currently the default is setReadBufferSize(0), where 0 has the special meaning of unlimited. Performance tests should not break, because they are reading as fast as possible. There may be a degradation on one side if the writer is faster than the reader. UDP sockets losing data if buffering is exceeded is acceptable (it's supposed to be an unreliable service) I hadn't thought too much about UDP at this point, just TCP. The readAll issue is with QNetworkReply rather than QTcpSocket. There are two programming models in use for this: Simple model: 1. send request 2. wait for the finished signal from the reply 3. call readAll to get the data Good model: 1. send request 2. each time the reply emits bytesAvailable 2a. call readAll to get the currently buffered data 2b. save / process currently buffered data 3. when finished signal is received, call readAll a final time to get the tail The simple model tends to be used where the expected data is small. The good model tends to be used where the data size is unknown (e.g. browsers, download managers) We could give a much larger buffer size for QNetworkReply (e.g. 1MB) to catch reasonable small downloads, but this might be harder for developers (as they only see the buffer limit rarely) Yes, QIODevice allows partial writes, but Q*Socket always accepts all the data in the current implementation. I actually think this side is less of a problem, because the developer knows what kind of data they will be sending. Therefore they are in the best position to decide if they need write flow control or not -Original Message- From: andrew.stanley-jo...@nokia.com [mailto:andrew.stanley-jo...@nokia.com] Sent: 11 February 2012 11:36 To: Kearns, Shane Subject: Re: [Development] Default enabling inbound flow control on sockets Ok, let me verify I understand the problem: 1. If a Qt app is not processing the data, Sockets continue reading no mater what. 2. This results in no flow control, and on a 10gigE connection results in the Qt app potentially receiving ~1 gigabyte/sec stream of data. (assuming the HW/SW etc can handle it) 3. Qt app exhausts all memory within a couple of seconds. This seems like relatively brain dead behaviour. On large systems it's a problem, and on smaller devices outright dangerous. What will changing the default buffer size do? I assume you mean set a reasonable default to QAbstractSocket::readBufferSize(). This seems sensible, it will stop the stream and use appropriate flow control, if available with that protocol. 1. Break performance tests. 2. datagram (UDP) sockets will lose data. 3. As you said, readAll() may have problems, but it's also incompatible with sane network programming. How can I trust the other side is only going to send 50 bytes and not 4 gigs? There's no requirement for write buffering as well. Under Unix's can you can write data to a socket and have it not block and/or have it write less data than available. QIODevice accounts for this and write can return 0 bytes written. You can easily argue most programs don't handle this well. But at some point network links can't handle traffic at any arbitrary rate and flow control must kick in. Buffering is a short term solution. I think it's a good idea to have a build in limit. I think it avoids easily made mistake by developers. -Andrew On 10/02/2012, at 8:25 PM, ext shane.kea...@accenture.com wrote: > The current default behaviour of Qt sockets is that they allocate an > unbounded amount of memory if the application is not reading all data from > the socket but the event loop is running. > In the worst case, this causes memory allocation failure resulting in a crash > or app exit due to bad_alloc exception > > We could change the default read buffer size from 0 (unbounded) to a sensible > default value e.g. 64k (to be benchmarked) > Applications wanting the old behaviour could explicitly call > setReadBufferSize(0) > Applications that already set a read buffer size will be unchanged > > The same change would be required at the QNetworkAccessManager level, as > there is no point applying flow control at the socket and having unbounded > memory allocations in the QNetworkReply. > > This is a behavioural change that would certainly cause regressions. > e.g. any application that waits for the QNetworkReply::finished() signal and > then calls readAll() would break if the size of the object being downloaded > is larger than the buffer size. > > On the other hand, we can't enable default outbound flow control in sockets > (we don't want write to block). > Applications need to use the bytesWritten signal. > QNetworkAccessManager already implem
[Development] Default enabling inbound flow control on sockets
The current default behaviour of Qt sockets is that they allocate an unbounded amount of memory if the application is not reading all data from the socket but the event loop is running. In the worst case, this causes memory allocation failure resulting in a crash or app exit due to bad_alloc exception We could change the default read buffer size from 0 (unbounded) to a sensible default value e.g. 64k (to be benchmarked) Applications wanting the old behaviour could explicitly call setReadBufferSize(0) Applications that already set a read buffer size will be unchanged The same change would be required at the QNetworkAccessManager level, as there is no point applying flow control at the socket and having unbounded memory allocations in the QNetworkReply. This is a behavioural change that would certainly cause regressions. e.g. any application that waits for the QNetworkReply::finished() signal and then calls readAll() would break if the size of the object being downloaded is larger than the buffer size. On the other hand, we can't enable default outbound flow control in sockets (we don't want write to block). Applications need to use the bytesWritten signal. QNetworkAccessManager already implements outbound flow control for uploads. Is making applications safe against this kind of overflow by default worth the compatibility breaks? Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Changes to the Jira roles and workflow
It's easy to make a report on your personal dashboard to show issues reported on a given (set of) component(s). It means polling rather than email notification, but the email notifications have poor signal:noise ratio. > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of marius.storm-ol...@nokia.com > Sent: Thursday, February 09, 2012 11:47 > To: michael.godd...@nokia.com > Cc: thiago.macie...@intel.com; development@qt-project.org > Subject: Re: [Development] Changes to the Jira roles and workflow > > On 09/02/2012 05:41, Goddard Michael (Nokia-MP/Brisbane) wrote: > >> Assigning new tasks "unassigned" will not notify the maintainer > >> about issues in the modules that have come up, and the maintainer > >> will not by notified when someone takes a task and starts working > >> on it. > > > > Surely this is something that JIRA could support? Watching a > > component or similar? (also can Gerrit do this too?) > > Not by default. But there is a 3rdparty pluging to allow adding Watcher > on components: > > https://studio.plugins.atlassian.com/wiki/display/JCWP/JIRA+Component+Wa > tcher+Plugin > > -- > .marius > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Feature freeze and Alpha
This is an important feature to make password prompts not block other unrelated network requests, and not require a nested event loop or multiple threads. There are three places this feature is required: 1. sslErrors signal (QSslSocket and QNetworkReply) - QSslSocket done by Peter, QNetworkReply started by peter 2. authenticationRequired signal (QNetworkReply) - started by Peter 3. proxyAuthenticationRequired signal (QAbstractSocket and QNetworkReply) - not started see https://qt.gitorious.org/~p--hartmann/qt/p--hartmanns-qtbase/commits/auth-pause-squashed for the work already done for QNetworkAccessManager. I don't know if what the barriers are to us using this, as it's the state of his work before leaving Nokia. If there are no legal issues, then we should work on top of that commit so that code attribution is correct. The concept is that when pausing is enabled (via the pause mode opt-in), then the signals are asynchronous. Currently, the application must synchronously fill in the QAuthenticator credentials (or process ssl errors) before returning control to the signal emission point. With the opt in, then the application should instead call the resume slot when the credentials are available. We need to be careful with any code that uses QAuthenticatorPrivate, as it is rather fragile. Regarding binary compatibility: The pause mode enumeration in QAbstractSocket can be split if required. e.g. asynchronous ssl errors supported in 5.0, asynchronous proxy authentication in 5.1 by having two separate opt-in flags. (three opt-in flags may be needed for QNetworkAccessManager) Regarding source compatibility: With the opt-in, we are backwardly source compatible with Qt4. If we change the behaviour to be asynchronous by default (with or without an opt-out), then we would be source incompatible. > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Jonas M. Gastal > Sent: Monday, February 06, 2012 12:39 > To: development@qt-project.org > Subject: Re: [Development] Feature freeze and Alpha > > On Sunday 05 February 2012 14:12:48 lars.kn...@nokia.com wrote: > > These items are still open and we'll need feedback on them: > > * network authentication and SLL errors without stalling QNAM > > (QTBUG-16251, QTBUG-19032) > > Peter did some of the work on this: http://codereview.qt- > project.org/13834 > I don't know if anyone is working on finishing it. I can try to carry > this > forward, but without knowing by when this would need to be done I can't > make > any promises. > > Gastal > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
An important requirement is that it must be easy to enable debugging in Qt libraries without touching the application code. This is so that we can debug regressions affecting closed source applications. With the existing qDebug, we need to disable the qInstallMsgHandler call*, and recompile the relevant Qt libraries with debug logs enabled. *A lot of applications redirect logs to a file, which may be hard to find. Some applications catch and discard qDebug in release builds. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Compatability break in QUrl in Qt 4.8
> Fair enough.
>
> Other opinions around? Olivier has already said he's for reverting to
> the old
> 4.7 behaviour.
>
The documentation note about the dangers of constructing QUrl from QString was
already there in 4.6 (at the bottom of the page)
However, QT_NO_URL_CAST_FROM_STRING is not defined by default, so there are no
compiler errors or warnings when using unsafe construction.
So I'm ambivalent when it comes to C++ applications.
What has convinced me is the Qt Creator HTML5 app wizard generates this kind of
unsafe code.
I would assume that many users of this app wizard are web developers with
limited c++ skills, and in any case would expect the boilerplate generated by
the SDK to be good.
So I am in favour of keeping the 4.7 behaviour in 4.x releases.
I'd also be in favour of making QT_NO_URL_CAST_FROM_STRING turned on by default
in 5.x (i.e. you need to define QT_ALLOW_URL_CAST_FROM_STRING to allow those
assignments)
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
Html5ApplicationViewer viewer;
viewer.setOrientation(Html5ApplicationViewer::ScreenOrientationAuto);
viewer.showExpanded();
viewer.loadFile(QLatin1String("html/index.html")); // <-- relative path
return app.exec();
}
QString Html5ApplicationViewerPrivate::adjustPath(const QString &path)
{
#ifdef Q_OS_UNIX
#ifdef Q_OS_MAC
if (!QDir::isAbsolutePath(path))
return QCoreApplication::applicationDirPath()
+ QLatin1String("/../Resources/") + path;
#else
const QString pathInInstallDir = QCoreApplication::applicationDirPath()
+ QLatin1String("/../") + path;
if (pathInInstallDir.contains(QLatin1String("opt"))
&& pathInInstallDir.contains(QLatin1String("bin"))
&& QFileInfo(pathInInstallDir).exists()) { // <-- condition is
false on symbian
return pathInInstallDir;
}
#endif
#endif
return path; // <-- path is unmodified
}
void Html5ApplicationViewer::loadFile(const QString &fileName)
{
m_d->m_webView->setUrl(QUrl(Html5ApplicationViewerPrivate::adjustPath(fileName)));
// <-- QT_NO_URL_CAST_FROM_STRING wouldn't have helped, but it should still be
using QUrl::fromLocalFile
}
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Removing QContactThumbnail class from QtContacts API
Hi Cristiano, Would you be able to use a data url, for example to handle vCard PHOTO fields that are embedded rather than linked? They are rather inefficient though. An end-user feature you may be losing is the ability to snap a photo of somebody when taking their phone number and have that show up in the address book. While you could store some kind of link to the photo album, this isn't likely to be a simple file: url. From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of cristiano.di-fl...@nokia.com Sent: Tuesday, January 31, 2012 05:45 To: development@qt-project.org Subject: [Development] Removing QContactThumbnail class from QtContacts API Hi, >From the old mobility times there has always been confusion in Contacts API >between the QContactThumbnail and QContactAvatar. An excerpt from our docs: " The content of the thumbnail detail is static once set. That is, in order to change the thumbnail of a particular contact, the user must modify the detail and update the contact. This is in contrast to the QContactAvatar<http://doc.qt.nokia.com/qtmobility-1.2/qcontactavatar.html> detail, which contains URLs to resources; the actual content of the resource might be changed dynamically by person, group or organization for which the QContact<http://doc.qt.nokia.com/qtmobility-1.2/qcontact.html> is a digital representation. That is, the content of a QContactThumbnail detail is set by the user who has created the contact, but the content of a resource identified by a URL specified in a QContactAvatar<http://doc.qt.nokia.com/qtmobility-1.2/qcontactavatar.html> detail is set by whoever owns the resource which the URL identifies. " Now, the reality is that returning a Qimage from QContactAvatar class is not a great idea, since not all the back-ends support real thumbnails, and hence this approach can lead to inefficiency, because: 1. The specific image format for a thumbnail depends on several factors which are out of control of the Contacts middleware API 2. In back-ends where storing directly some binary blobs might not be possible or desirable, we end-up storing anyway the image to file system We are now thinking of removing the detail from the API, and give more "power" to the URL based approach adopted in QContactAvatar. What do the others think? Any objections to killing the QContactThumbnail class in one shot? Will we be able to use only one single detail type (e.g. QContactAvatar) based on URL and not Qimage? Ciao! -Cristiano Cristiano di Flora, PhD SW Architect / Technical lead, MP - Qt Software development Visiokatu 3 33720, Tampere (FINLAND) Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QLog ( Work on qDebug and friends)
> > +1 from me > > - Crazy idea : allow logging to a socket ? ( remote log/debug ) > - More than one logging file ? One file for every category / group of > categories > - Log File rotation > > Just my 2 cents. > Not that crazy an idea - I normally use USB to catch the live debug log from phones. But this is done on the system level rather than Qt. The problem is you can't use QTcpSocket to do it, because QtNetwork might itself be printing QDebug messages. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Problem with pushing my changes
Hi Ram,
Check your firewall configuration, and if necessary, connect through a proxy.
git / ssh can be configured to run over a http proxy that allows the CONNECT
method.
I'd advise using the "git remote" command to save yourself typing.
"git remote add gerrit ram...@codereview.qt-project.org:qt/qtbase.git"
"git push gerrit HEAD:refs/for/master"
Also make sure you upload your SSH public key to gerrit via settings in the web
interface.
PS: your email host attaches advertisements to your messages. You should find a
provider that does not do that, otherwise a lot of people will never see your
messages due to junk email filters.
From: development-bounces+shane.kearns=accenture@qt-project.org
[mailto:development-bounces+shane.kearns=accenture@qt-project.org] On
Behalf Of Ramamurthy K V
Sent: Wednesday, January 25, 2012 05:05
To: development@qt-project.org
Subject: [Development] Problem with pushing my changes
Hi,
I have tried to clone from codereview.qt-project.org, but failed with
"Connection timed out" error.
Then I cloned from gitorious, that works fine.
Made changes to fix the Qt
Bug#23850("https://bugreports.qt.nokia.com/browse/QTBUG-23850";)(I raised this
bug) and did commit the changes.
But when i try to push using "git push
ssh://ram...@codereview.qt-project.org/qt/qtbase HEAD:ref/for/master", it
failed with
ssh: connect to host codereview.qt-project.org port 29418: Connection timed out
fatal: The remote end hung up unexpectedly
Am I doing anything wrong?
Request you to help me on this issue.
Thanks
Ram
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Tests, Shadow-Build and Cross-Compilation
For the cross compilation, the "deployment" section in the .pro file is
supposed to take care of including the test data in the package to upload to
the device under test.
WinCE and Symbian ports in Qt4 have ad hoc solutions for this (cetester and
runonphone tools respectively)
Running out of storage space can be a problem, and so is the speed of testing.
The main task for a platform is to have some tool that uploads the test + test
data in deployment to the target, runs the test, and downloads the test results.
Running tests in parallel over multiple test devices could ease the speed
problems.
Running tests on an emulator is an option, but is an unrealistic environment
for network and mobility testing.
Another problem is if the test device has only wireless connectivity, then
tests can be more flaky than usual.
> -Original Message-
> From: development-bounces+shane.kearns=accenture@qt-project.org
> [mailto:development-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of Holger Hans Peter Freyther
> Sent: Sunday, January 29, 2012 20:13
> To: development
> Subject: [Development] Tests, Shadow-Build and Cross-Compilation
>
> Hi all,
>
> I finally got around to play with my personal jenkins[1] setup again,
> specially to learn (and be kind of an example on how a non Tier1
> platform
> could ever become one).
>
> There are some issues and I would like to discuss how these can be
> solved in a
> way that doesn't look like an ad-hoc solution and that might scale.
>
> I will mumble about the Problems, the Ad-Hoc solutions and muse about a
> fix...
>
>
>
> Problems:
> Shadow builds:
>
> I always liked shadow builds as I could have several Qt configurations
> but a
> command/shared source directory (e.g. X11, QWS, for i386 and ARM). It is
> quite
> common for tests to break in shadow builds (the QA page in the wiki
> discourages this as well).
>
> Cross compilation:
> When cross compiling the machine that compiles the tests will not be the
> machine that ends up running them.
>
>
> Ad-hoc solutions:
> Shadow builds:
>
> The ad-hoc solution appears to change tests that refer to files in a way
> like
> this:
> VERIFY(file.open("testfile"));
>
> to:
> VERIFY(file.open(SRCDIR "testfile"));
>
> and put DEFINES += SRCDIR=... into the pro file.
>
>
> Cross compilation:
>
> The attribute of cross-compilation and running the test on a different
> architecture is somehow attributed to both Windows-CE (and Symbian).
> This
> manifests in the xmlpatterns test by adding deployment targes, deploy
> files,
> change the sourcecode to access different directories.
>
>
> Musing:
> So somehow cross-compilation and shadow-builds suffer from the same
> problem
> that accessing files from the source directory with a relative path. One
> proposal would be to use something like 'QDir::addSearchPath("testdata",
> SRCDIR)'" and have it set to the path of the .pro file, and access
> everything
> using the prefix. Danimo mentioned that this will fail for multimedia
> that
> might not use the Qt resource system. So we might want to have a method
> in the
> testlib to resolve a path like "testdata:foo" to a proper path? For
> cross
> compiling one could change the testdata prefix with a command line
> option or
> environment variable?
>
> The other part/wish would be to always have deployment targets for the
> testcases and generate a run script or such as part of the installation.
>
> comments
> holger
>
>
>
> [1] http://qt-jenkins.moiji-mobile.com/jenkins/
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Subject to local law, communications with Accenture and its affiliates
including telephone calls and emails (including content), may be monitored by
our systems for the purposes of security and the assessment of internal
compliance with Accenture policy.
__
www.accenture.com
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] proposing "removed apis" playground project
This module should be able to host any removed classes if they are technically feasible to build on top of Qt5 after removal from the current library they live in. You will need to: get agreement from the maintainer(s) to remove those models from Qt5 submit a patch to actually remove them submit a patch to add them to the "removed apis" repository further patches may be required to compile, for example if the class depends on private headers or non exported classes QFtp was easy to move, QHttp was harder (due to usage of QAuthenticatorPrivate) From: development-bounces+shane.kearns=accenture@qt-project.org [mailto:development-bounces+shane.kearns=accenture@qt-project.org] On Behalf Of Stephen Kelly Sent: Tuesday, January 24, 2012 15:39 To: development@qt-project.org Subject: Re: [Development] proposing "removed apis" playground project On Tuesday, January 24, 2012 15:11:08 shane.kea...@accenture.com wrote: > This project is to host the source code of APIs which have been removed in > Qt5, where the replacement does not cover all features. Initially it will > be used for static library versions of QFtp and QHttp. As previously > discussed on this mailing list, some applications depend on features of > these classes which are not supported by QNetworkAccessManager. However the > APIs are being removed from Qt5 due to quality of the implementation. QProxyModel also likely belongs in such a module (I think it's deprecated since Qt 4.1). Possibly QDirModel too (replaced by QFileSystemModel). Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] proposing "removed apis" playground project
This project is to host the source code of APIs which have been removed in Qt5, where the replacement does not cover all features. Initially it will be used for static library versions of QFtp and QHttp. As previously discussed on this mailing list, some applications depend on features of these classes which are not supported by QNetworkAccessManager. However the APIs are being removed from Qt5 due to quality of the implementation. Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Legacy "trolltech" strings
org.qt-project sounds like the right default to me, for places where a reverse domain is used. The Nokia maps location plugin should probably still be com.nokia though. > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of xizhi@nokia.com > Sent: Thursday, January 19, 2012 10:52 > To: development@qt-project.org > Subject: [Development] Legacy "trolltech" strings > > Hi, > > Currently we have at least the following in the source code (mainly for > the interface identifiers): > com.trolltech.Qt.* > com.trolltech.qml.* > com.nokia.Qt.* > com.nokia.qt.* > > Any plans / on-going work to fix these legacies? I propose to use > "org.qt-project.*". > Any other ideas? > > > > Xizhi Zhu (Steven) > > Software Engineer @ Qt Development Frameworks > Nokia > > Phone number: > +358 (0)50 480 1247 > +491722534236 > ___ > Development mailing list > Development@qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QRegularExpression -- first round of API review
> > 3) Need a couple of better names for partial matching: > - partial match preferring a complete match > - partial match returning whatever match (partial or complete) is found > first > > PCRE uses Soft and Hard respectively (which are quite meaningless to > me). PreferCompleteMatch / PreferFirstMatch? Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
QFtp, QHttp are ported as standalone classes in a kitchen sink repo on my hard drive. Once there is a project on gerrit, I can push it for code review. > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of Thiago Macieira > Sent: Wednesday, January 11, 2012 15:01 > To: development@qt-project.org > Subject: Re: [Development] Qftp removal > > On Wednesday, 11 de January de 2012 14.48.55, lars.kn...@nokia.com > wrote: > > Yes, please. We need a name for it. How about qtnetwork4 ? > > > > I people are ok with the name, can you add the repo, Sergio? > > > > Who'd be willing to import the code and examples into that repo? > Shane? > > I'd say we should keep each independent class in its own static library > build. > So it would be "qftp" inside a kitchen sink repository. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > Intel Sweden AB - Registration Number: 556189-6027 > Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
> > I'd say we should keep each independent class in its own static library > build. > So it would be "qftp" inside a kitchen sink repository. > I agree completely Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
I'd think one project could handle all the removed features we want to support as static libraries e.g. qftp qhttp qsettings "qt4support" isn't a terrible name, unless it has too bad connotations. "qt4removedapis" is clear as well I'll take care of moving QHttp and QFtp. In general, the person removing an API from Qt should add it here for future removals. (assuming it's feasible and desirable to provide the API standalone) > -Original Message- > From: lars.kn...@nokia.com [mailto:lars.kn...@nokia.com] > Sent: Wednesday, January 11, 2012 14:49 > To: Kearns, Shane; thiago.macie...@intel.com; development@qt-project.org > Cc: sergio.ahum...@nokia.com > Subject: Re: [Development] Qftp removal > > Yes, please. We need a name for it. How about qtnetwork4 ? > > I people are ok with the name, can you add the repo, Sergio? > > Who'd be willing to import the code and examples into that repo? Shane? > > Thanks, > Lars > > On 1/11/12 3:26 PM, "ext shane.kea...@accenture.com" > wrote: > > >Can we get an addon module (project in gerrit) for putting standalone > >implementations of these removed features? > >I wouldn't expect a huge amount of commits, but the code (and > associated > >examples/tests) needs to be moved there and converted from dll exports > to > >static libraries. > > > >> -Original Message- > >> From: development-bounces+shane.kearns=accenture@qt-project.org > >> [mailto:development-bounces+shane.kearns=accenture.com@qt- > project.org] > >> On Behalf Of lars.kn...@nokia.com > >> Sent: Monday, December 26, 2011 10:18 > >> To: thiago.macie...@intel.com; development@qt-project.org > >> Subject: Re: [Development] Qftp removal > >> > >> On 12/24/11 12:24 PM, "ext Thiago Macieira" > > >> wrote: > >> > >> >On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote: > >> >> I've been using it for a year now, have had no problems on Linux > and > >> >> Windows. I use it to check for application upgrade. Is there a > >> >> recommended way to do FTP transfers when QFtp is gone. Any chance > of > >> >>QFtp > >> >> getting into Qt Commercial ? > >> > > >> >Qt Commercial and Qt Open Source are the same. If it's removed from > >> one, > >> >it's > >> >removed from both. We can probably place it in a separate module for > >> >people > >> >who still need it. > >> > >> Yes, the code is there and while we really need to remove it from > >> QtNetwork, we should provide a way for people to use it in their > >> projects. > >> IMO a static lib containing both QHttp and QFtp could be a solution. > >> > >> Cheers, > >> Lars > >> > >> > > >> >The recommended way is to use QNetworkAccessManager, which does not > >> have > >> >API > >> >for listing directories. > >> >-- > >> >Thiago Macieira - thiago.macieira (AT) intel.com > >> > Software Architect - Intel Open Source Technology Center > >> > Intel Sweden AB - Registration Number: 556189-6027 > >> > Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden > >> >___ > >> >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 > > > > > > > >Subject to local law, communications with Accenture and its affiliates > >including telephone calls and emails (including content), may be > >monitored by our systems for the purposes of security and the > assessment > >of internal compliance with Accenture policy. > >___ > ___ > > > > > >www.accenture.com > Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Qftp removal
Can we get an addon module (project in gerrit) for putting standalone implementations of these removed features? I wouldn't expect a huge amount of commits, but the code (and associated examples/tests) needs to be moved there and converted from dll exports to static libraries. > -Original Message- > From: development-bounces+shane.kearns=accenture@qt-project.org > [mailto:development-bounces+shane.kearns=accenture@qt-project.org] > On Behalf Of lars.kn...@nokia.com > Sent: Monday, December 26, 2011 10:18 > To: thiago.macie...@intel.com; development@qt-project.org > Subject: Re: [Development] Qftp removal > > On 12/24/11 12:24 PM, "ext Thiago Macieira" > wrote: > > >On Friday, 23 de December de 2011 22.10.19, David Boosalis wrote: > >> I've been using it for a year now, have had no problems on Linux and > >> Windows. I use it to check for application upgrade. Is there a > >> recommended way to do FTP transfers when QFtp is gone. Any chance of > >>QFtp > >> getting into Qt Commercial ? > > > >Qt Commercial and Qt Open Source are the same. If it's removed from > one, > >it's > >removed from both. We can probably place it in a separate module for > >people > >who still need it. > > Yes, the code is there and while we really need to remove it from > QtNetwork, we should provide a way for people to use it in their > projects. > IMO a static lib containing both QHttp and QFtp could be a solution. > > Cheers, > Lars > > > > >The recommended way is to use QNetworkAccessManager, which does not > have > >API > >for listing directories. > >-- > >Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > Intel Sweden AB - Registration Number: 556189-6027 > > Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden > >___ > >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 Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
