From chgans at gna.org Wed Apr 1 02:28:50 2015 From: chgans at gna.org (Christian Gagneraud) Date: Wed, 01 Apr 2015 13:28:50 +1300 Subject: [Development] QGView and deprecated indirect painting Message-ID: <551B3BC2.10103@gna.org> Hi Trolls! Note: I'm sending this email to qt-dev not to qt-interest because it deals with deprecated features and API changes of the Qt Graphics View framework. QGraphicsView has an optimisation flag called "IndirectPainting", which when set "restore the old painting algorithm that calls QGraphicsView::drawItems() and QGraphicsScene::drawItems()." and is marked as "To be used only for compatibility with old code." I would like to use this feature to achieve per view painting controls such as: - item transparency and colors (effect) - drawing order In my context, there is one main view (the working view) and other auxiliary views (typically in dock widgets), a picture being worth a thousand word, here is an example of the sort of things I'm after: http://techdocs.altium.com/display/ADOH/Working+with+the+Board+Insight+System#WorkingwiththeBoardInsightSystem-SingleLayerMode So, my question is: Do you guys plan to remove this feature, and if yes (which seems likely to me), how could I then control colors, opacity and drawing order on a per view basis? I think it is a very good feature to allow the view to take control of painting over the QGItems and the QGScene. (on the side, i think as well that it is way better to let the view handle mouse and keyboard events instead of the scene or the items) Thanks, Krys From cavendish.qi at gmail.com Wed Apr 1 12:55:02 2015 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 1 Apr 2015 12:55:02 +0200 Subject: [Development] Outdated Branch Guidelines and Commit Policy? Message-ID: https://wiki.qt.io/Branch_Guidelines It's still in dev/stable mode, not the current 5.3/5.4/5.5/dev mode. https://wiki.qt.io/Commit_Policy Make sure to follow the Branch Guidelines. Submit against the lowest applicable branch from which a release is still planned. I have seen more and more bug fixes are going to 5.5 branch instead of 5.4. And many reviewers prefer to do that. 5.4 is much more stable than 5.5, that's for sure, and I think the patches for 5.4 are still valuable for customers and users. If 5.4.2 is not planned, then it's ok. Otherwise... please update the wiki, thanks. Regards, Liang -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Wed Apr 1 13:25:15 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 1 Apr 2015 13:25:15 +0200 Subject: [Development] Outdated Branch Guidelines and Commit Policy? In-Reply-To: References: Message-ID: <20150401112515.GB527@troll08.it.local> On Wed, Apr 01, 2015 at 12:55:02PM +0200, Liang Qi wrote: > https://wiki.qt.io/Branch_Guidelines > It's still in dev/stable mode, not the current 5.3/5.4/5.5/dev mode. > it's not. the markup actually means something. From announce at qt-project.org Wed Apr 1 16:04:54 2015 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Wed, 1 Apr 2015 14:04:54 +0000 Subject: [Development] [Announce] Qt Creator 3.4 RC1 released Message-ID: We are happy to announce the release of Qt Creator 3.4 RC1 http://blog.qt.io/blog/2015/04/01/qt-creator-3-4-rc1-released/ -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From rjvbertin at gmail.com Wed Apr 1 16:17:43 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 01 Apr 2015 16:17:43 +0200 Subject: [Development] [Interest] Et tu, Designer! Fwd: qt creator 3.3.x OS X with the xcb plugin In-Reply-To: <52929394.eElfxUDgFd@portia.local> References: <64945403.aQ8FBHS9cl@portia.local> <15744447.2estggjMCe@tjmaciei-mobl4> <52929394.eElfxUDgFd@portia.local> Message-ID: <1620376.0PXGxA7N9r@portia.local> On Tuesday March 31 2015 13:56:33 René J.V. Bertin wrote: > I think it is caused by creating a QMenuBar explicitly, without specifying a parent object. That eventually leads to the application icon appearing in the Dock, too, so it would seem that Not exactly; Qt Creator presumed that if isMacHost() == true, Qt is by definition using Cocoa (which is usually true): https://github.com/RJVB/mp-port-repository/blob/master/devel/qt5-creator-mac/files/patch-show-menubar-with-xcb.diff https://github.com/RJVB/mp-port-repository/blob/master/devel/qt5-creator-mac/files/patch-no-dockmenu-xcb.diff And for giggles: https://trac.macports.org/attachment/ticket/47329/2QtCreators.png The Designer code is even more blunt: equating #ifdef Q_OS_OSX with Cocoa mode: https://github.com/RJVB/mp-port-repository/blob/master/aqua/qt5-mac-devel/files/patch-designer-show-menubar-on-xcb.diff Cheers, R. From thiago.macieira at intel.com Wed Apr 1 17:32:23 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Apr 2015 08:32:23 -0700 Subject: [Development] Outdated Branch Guidelines and Commit Policy? In-Reply-To: References: Message-ID: <4616866.9x5evJrjbA@tjmaciei-mobl4> On Wednesday 01 April 2015 12:55:02 Liang Qi wrote: > I have seen more and more bug fixes are going to 5.5 branch instead of 5.4. > And many reviewers prefer to do that. > > 5.4 is much more stable than 5.5, that's for sure, and I think the patches > for 5.4 are still valuable for customers and users. 5.4 should receive important and non-risky bugfixes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mw_triad at users.sourceforge.net Wed Apr 1 18:25:29 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 01 Apr 2015 12:25:29 -0400 Subject: [Development] Outdated Branch Guidelines and Commit Policy? In-Reply-To: <4616866.9x5evJrjbA@tjmaciei-mobl4> References: <4616866.9x5evJrjbA@tjmaciei-mobl4> Message-ID: On 2015-04-01 11:32, Thiago Macieira wrote: > 5.4 should receive important and non-risky bugfixes. Can I request that https://bugreports.qt.io/browse/QTBUG-43269 and https://bugreports.qt.io/browse/QTBUG-45328 be fixed in 5.4? At present, one must employ hackish work-arounds (in one case, using low-level GL functions directly) for these in order to use QOpenGLWidget and QOpenGLFramebufferObject together, which seems like a not-so-trivial flaw in that subsystem. It's possible that current distros will pick up 5.4.2 soon after it is released, but 5.5.x may not be available until 2016. (On a related note, I'd really love to see a fix for https://bugreports.qt.io/browse/QTBUG-38599 in 4.8.7. Yes, 4.x; Qt4 is going to be around for a while yet, especially in LTS distros, and this is a fairly painful bug.) -- Matthew From mw_triad at users.sourceforge.net Wed Apr 1 22:17:15 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 01 Apr 2015 16:17:15 -0400 Subject: [Development] Why is QTBUG-27186 closed? Message-ID: I'm getting a little sick of my users having problems because QFileDialog::getSaveFileName does not add the extension. Can someone please explain to me why this (apparently quite popular) bug is not only *NOT* fixed after so long, but the bug claims it *is* fixed and has been closed? -- Matthew From thiago.macieira at intel.com Wed Apr 1 23:52:34 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 01 Apr 2015 14:52:34 -0700 Subject: [Development] Why is QTBUG-27186 closed? In-Reply-To: References: Message-ID: <4111483.tICxUFWVAT@tjmaciei-mobl4> On Wednesday 01 April 2015 16:17:15 Matthew Woehlke wrote: > I'm getting a little sick of my users having problems because > QFileDialog::getSaveFileName does not add the extension. Can someone > please explain to me why this (apparently quite popular) bug is not only > *NOT* fixed after so long, but the bug claims it *is* fixed and has been > closed? Because the developer who closed it thought it was fixed. The developer would not close saying it was fixed if he didn't believe it. The fact that it isn't fixed indicates new information not available to the developer. So the answer as to why it is closed when you think it isn't fixed is the same for any bug: because the developer thought it was fixed. Friedemann commented in June last year that he thought it should be reopened, but never did so. Maybe he forgot. Maybe he ran out of time and didn't get around to it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From culiudabaicai at yeah.net Thu Apr 2 05:20:09 2015 From: culiudabaicai at yeah.net (Baicai) Date: Thu, 2 Apr 2015 11:20:09 +0800 (CST) Subject: [Development] QTreeWidgetItem clone Message-ID: <1bfc0a7d.76.14c7824a37e.Coremail.culiudabaicai@yeah.net> Hi All, QTreeWidgetItem uses the copy constructor to implement its clone method. It does not copy item's type, but there isn't a setType method to modify it. So the clone method is a bit useless in this sense. Is there any reason not to copy the item's type? Or I'm not using it correctly Best Regards, Baicai -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.blanc at nmc-company.com Thu Apr 2 08:58:52 2015 From: julien.blanc at nmc-company.com (Julien Blanc) Date: Thu, 02 Apr 2015 08:58:52 +0200 Subject: [Development] JSON 64 bit int In-Reply-To: References: <54DB3195.8000006@vikingsoft.eu> <201502120108.14451.marc.mutz@kdab.com> <201502120118.47453.kde@carewolf.com> <3798507.nGKNkZuNX0@tjmaciei-mobl4> Message-ID: <551CE8AC.7010705@nmc-company.com> On 12/02/2015 08:42, Knoll Lars wrote: > > Yes, 80 or 128bit doubles are out of the question. The RFC basically > doesn’t specify the range of allowed values, but hints that it should at > least support doubles. We can go above that and allow 64bit integers as > well as they are rather common these days. But anything above that is IMO > something that is out of scope for Qt. > > So I’d be ok with a patch that adds builtin support for 64bit integers. > We’d then need to decide at parse time whether to store the value as > integer or double, and since JSON only talks about numbers the getters > have to do automatic conversion (or we’d break existing code). To be able > to deal with them you’d need a isInteger() flag on QJsonValue. This thread is quite old, but there are some news here that are relevant : http://www.rfc-editor.org/rfc/rfc7493.txt Basically, i think QJson is currently conform to i-json (interoperable json). That should at least : - gives some arguments about *not* using 64bit integers (this is handled by the RFC : use strings in that case) - maybe allows a strict / non strict mode. Regards, Julien Blanc From gunnar.roth at gmx.de Thu Apr 2 10:48:32 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Thu, 2 Apr 2015 10:48:32 +0200 Subject: [Development] quickcontrols has now a hard dependancy on widgets. In-Reply-To: <1418817775959.75561@theqtcompany.com> References: <20141216000017.80FF676E@m0048136.ppops.net>, , <1418817775959.75561@theqtcompany.com> Message-ID: Hello, it has been quite some time since this thread, but yesterday i tried the approach using no_desktop just to find out, the the qtsvg imageformat plugin, has ( of course) a dependency on qtsvg, which in turn does also depend on widgets. Ok so i thought i use -no-widgets when configuring, but my wec 2013 build using qt 5.5 git failed. By the nature of the problem, i think a win32 build would have failed too. Note: that i am dong shadow builds and no -developer-build This modifications made the build compile: --- a\qtbase\src\plugins\platforms\windows/accessible/iaccessible2.cpp    2015-03-12 15:49:39.698271300 +0100 +++ b\qtbase\src\plugins\platforms\windows/accessible/iaccessible2.cpp    2015-04-01 13:18:29.368083400 +0200 @@ -36,11 +36,11 @@  #include "iaccessible2.h"  #include "qwindowsaccessibility.h"  #include  #include  #include -#include +#include  #include    QT_BEGIN_NAMESPACE   --- a\qtbase\src\plugins\platforms\windows/accessible/qwindowsmsaaaccessible.cpp    2015-03-12 15:49:39.706271300 +0100 +++ b\qtbase\src\plugins\platforms\windows/accessible/qwindowsmsaaaccessible.cpp    2015-04-01 13:04:14.062083400 +0200 @@ -37,24 +37,21 @@  #include "qwindowsmsaaaccessible.h"  #include "qwindowsaccessibility.h"  #include  #include  #include  #include "comutils.h"    #include  #include  #include  #include  #include  #include  #include  #include -#include -#include -#include -#include + //#include #ifndef UiaRootObjectId #define UiaRootObjectId -25 #endif  Regards, Gunnar Roth Gesendet: Mittwoch, 17. Dezember 2014 um 14:02 Uhr Von: "deDietrich Gabriel" An: "development at qt-project.org" Cc: "Gunnar Roth" , "gunnar at sletta.org" , "Nurmi J-P" Betreff: Re: Re: [Development] quickcontrols has now a hard dependancy on widgets. Qt Quick Controls do depend on QtWidgets because of styling on desktop. This may be solved in the future as we plan on having separate plugins for styles. (Notice that Qt Quick Controls are not integral part of Qt Quick but a separate module.)   If you're writing an embedded app, then you most likely have a cross-built version of Qt (I'm assuming that's the case for WEC2013, of which I don't know much), and that version probably doesn't need widgets. So you can do as Gunnar S. proposed. Otherwise, your only solution, as I said earlier, is to build Qt Quick Controls with CONFIG += no_desktop. The only feature you'll miss by doing so is the desktop native-looking style, but that wouldn't make sense on WCE2013 either, AFAICT.   Best regards,   Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io[http://www.qt.io]   ------------------------------------------------------------ From: Gunnar Roth Sent: Tuesday, December 16, 2014 4:15 PM To: gunnar at sletta.org Cc: deDietrich Gabriel; development at qt-project.org Subject: Aw: Re: [Development] quickcontrols has now a hard dependancy on widgets.   Well, i know that leaving out widgets from configure would also solve this problem ,but as i wrote i also need widgets in my build for other programs. I just dont understand that i get widgets dependency by just using quickcontrols. And QtQuick does NOT depend on widgets as you say. I just look with depends.exe and qt5quick does only depend on gui,qml,network and core. qml  does depend on network and core only.   Regards, Gunnar (Roth)   Gesendet: Dienstag, 16. Dezember 2014 um 09:00 Uhr Von: gunnar at sletta.org An: "Gunnar Roth" Cc: Gabriel.deDietrich at theqtcompany.com, development at qt-project.org Betreff: Re: [Development] quickcontrols has now a hard dependancy on widgets. Configure qtbase with "-no-widgets" and all widget dependencies should be gone from both Qt Quick and from Controls. --- gunnar.roth at gmx.de wrote: From: "Gunnar Roth" To: "deDietrich Gabriel" Cc: "development at qt-project.org" Subject: Re: [Development] quickcontrols has now a hard dependancy on widgets. Date: Mon, 15 Dec 2014 14:01:41 +0100 HI Gabriel, I didn't know that, but i don't want any widgets dependency for a qml application, neither on desktop nor anywhere else.   Regards, Gunnar     Gesendet: Montag, 15. Dezember 2014 um 12:04 Uhr Von: "deDietrich Gabriel" An: "Gunnar Roth" , "development at qt-project.org" Betreff: Re: [Development] quickcontrols has now a hard dependancy on widgets. Hi Gunnar, You can always rebuild QtQuick Controls making sure you add CONFIG += no_desktop in the .pro file. The widgets dependency is automatic if widgets are present except on mobile platforms (which, paradoxically, exclude embedded). Best regards, Dr. Gabriel de Dietrich Senior Software Developer The Qt Company — www.qt.io[http://www.qt.io][http://www.qt.io[http://www.qt.io]] ________________________________________ From: development-bounces+gabriel.dedietrich=theqtcompany.com at qt-project.org on behalf of Gunnar Roth Sent: Monday, December 15, 2014 10:07 AM To: development at qt-project.org Subject: [Development] quickcontrols has now a hard dependancy on widgets. Hi, Recently i deteced that quickcontrols plugim has started to add a hard dependency on widgets ( on wec2013 and win32 at least ). dpends.exe is showing ??0QStyleHintReturnMask@@QAE at XZ ??0QStyleOption@@QAE at HH@Z ??0QStyleOptionButton@@QAE at XZ ??0QStyleOptionComboBox@@QAE at XZ ??0QStyleOptionFocusRect@@QAE at XZ ??0QStyleOptionFrame@@QAE at XZ ??0QStyleOptionGroupBox@@QAE at XZ ??0QStyleOptionHeader@@QAE at XZ ??0QStyleOptionMenuItem@@QAE at XZ ??0QStyleOptionProgressBar@@QAE at XZ ??0QStyleOptionSlider@@QAE at XZ ??0QStyleOptionSpinBox@@QAE at XZ ??0QStyleOptionTab@@QAE at XZ ??0QStyleOptionTabWidgetFrame@@QAE at XZ ??0QStyleOptionToolBar@@QAE at XZ ??0QStyleOptionToolButton@@QAE at XZ ??0QStyleOptionViewItem@@QAE at XZ ??1QStyleHintReturnMask@@QAE at XZ ??1QStyleOption@@QAE at XZ ??1QStyleOptionViewItem@@QAE at XZ ?font at QApplication@@SA?AVQFont@@XZ ?globalStrut at QApplication@@SA?AVQSize@@XZ ?hideText at QToolTip@@SAXXZ ?palette at QApplication@@SA?AVQPalette@@PBD at Z ?showText at QToolTip@@SAXABVQPoint@@ABVQString@@PAVQWidget@@@Z ?style at QApplication@@SAPAVQStyle@@XZ as imported functions from Widgets library. In contrast to this the quickcontrols dialog plugin has only a soft dependency via qpa, because of the possibility to use the widgets dialogs as a fallback. Ir is very surprising to have a dependency on widgets, which loads this huge dll on our wec2013 platform into memory ( for performance reasons paging of exe/dll is switched off) . I admit that this does only happen if you also build widgets library, but i usually build as much a i can on a platform, even if i don't use it yet. With this patch i now disable that dependency. --- a\qtquickcontrols\src\src.pro 2014-12-05 17:24:10.000000000 +0100 +++ b\qtquickcontrols\src\src.pro 2014-12-08 13:45:54.616785600 +0100 @@ -7,6 +7,6 @@ SUBDIRS += layouts SUBDIRS += dialogs SUBDIRS += dialogs/Private -qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets +#qtHaveModule(quick):qtHaveModule(widgets): SUBDIRS += widgets I would really appreciate a configure option for this. Regards, Gunnar _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development][http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development]] _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development[http://lists.qt-project.org/mailman/listinfo/development]   From Kai.Koehne at theqtcompany.com Thu Apr 2 11:03:23 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 2 Apr 2015 09:03:23 +0000 Subject: [Development] git://code.qt.io availability Message-ID: Hi, Since a few days code.qt.io seems to be quite unreliable: Fetching changes via git:// often fail with "fatal: read error: Invalid argument" (Windows) or "fatal: read error: Connection reset by peer" (Linux). Is someone already looking into this? Should we rather clone from the github mirror to reduce the load? Regards Kai -------- Kai Köhne, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: kai.koehne at theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt From olli.hirvonen at theqtcompany.com Thu Apr 2 12:09:18 2015 From: olli.hirvonen at theqtcompany.com (Hirvonen Olli) Date: Thu, 2 Apr 2015 10:09:18 +0000 Subject: [Development] git://code.qt.io availability In-Reply-To: References: Message-ID: Thanks Kai for noticing...Mika (CC) tries to find a reason and fix. -Olli -----Original Message----- From: Koehne Kai Sent: 2. huhtikuuta 2015 12:03 To: Hirvonen Olli; development at qt-project.org Subject: git://code.qt.io availability Hi, Since a few days code.qt.io seems to be quite unreliable: Fetching changes via git:// often fail with "fatal: read error: Invalid argument" (Windows) or "fatal: read error: Connection reset by peer" (Linux). Is someone already looking into this? Should we rather clone from the github mirror to reduce the load? Regards Kai -------- Kai Köhne, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: kai.koehne at theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt From oswald.buddenhagen at theqtcompany.com Thu Apr 2 13:01:06 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 2 Apr 2015 13:01:06 +0200 Subject: [Development] git://code.qt.io availability In-Reply-To: References: Message-ID: <20150402110106.GC18282@troll08.it.local> On Thu, Apr 02, 2015 at 10:09:18AM +0000, Hirvonen Olli wrote: > Thanks Kai for noticing...Mika (CC) tries to find a reason and fix. > that should be fixed now, at least for the time being. > -Olli > > -----Original Message----- > From: Koehne Kai > Sent: 2. huhtikuuta 2015 12:03 > To: Hirvonen Olli; development at qt-project.org > Subject: git://code.qt.io availability > > Hi, > > Since a few days code.qt.io seems to be quite unreliable: Fetching changes via git:// often fail with "fatal: read error: Invalid argument" (Windows) or "fatal: read error: Connection reset by peer" (Linux). > > Is someone already looking into this? Should we rather clone from the github mirror to reduce the load? > > Regards > > Kai > > -------- > Kai Köhne, Senior Software Engineer | The Qt Company > > Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > Email: kai.koehne at theqtcompany.com | Mobile: + 49 151 55155601 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Friedemann.Kleint at theqtcompany.com Thu Apr 2 15:11:29 2015 From: Friedemann.Kleint at theqtcompany.com (Friedemann Kleint) Date: Thu, 2 Apr 2015 15:11:29 +0200 Subject: [Development] Why is QTBUG-27186 closed? In-Reply-To: <4111483.tICxUFWVAT@tjmaciei-mobl4> References: <4111483.tICxUFWVAT@tjmaciei-mobl4> Message-ID: <551D4001.804@theqtcompany.com> Hi, the behavior of the widgets-based dialog is equivalent to Qt 4.X and that was the end of the story back then. As reading material for Easter, I pushed up a proposal to gerrit ( https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 will (again) provide a spectactular native file dialog? Regards, Friedemann -- Friedemann Kleint | The Qt Company From mw_triad at users.sourceforge.net Thu Apr 2 15:46:29 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 02 Apr 2015 09:46:29 -0400 Subject: [Development] Why is QTBUG-27186 closed? In-Reply-To: <551D4001.804@theqtcompany.com> References: <4111483.tICxUFWVAT@tjmaciei-mobl4> <551D4001.804@theqtcompany.com> Message-ID: On 2015-04-02 09:11, Friedemann Kleint wrote: > the behavior of the widgets-based dialog is equivalent to Qt 4.X and > that was the end of the story back then. As reading material for Easter, > I pushed up a proposal to gerrit ( > https://codereview.qt-project.org/#/c/109815/ ). I expect KDE 5 will > (again) provide a spectactular native file dialog? Likely. Still... equivalent (to Qt 4) or not, it seems clear to me from the numerous comments both on Qt bugs and on e.g. Stack Overflow, that users (i.e. not just myself) expect and desire for the Qt internal dialog to have the same behavior as the KDE dialog. It may be too late to change this for Qt 4, but please, let's get it right for Qt 5 :-). Thanks for repoening. -- Matthew From rjvbertin at gmail.com Thu Apr 2 16:38:45 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 02 Apr 2015 16:38:45 +0200 Subject: [Development] Why is QTBUG-27186 closed? In-Reply-To: References: <551D4001.804@theqtcompany.com> Message-ID: <75204934.0Wft8z0VlW@portia.local> On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote: > It may be too late to change this for Qt 4, but please, let's get it > right for Qt 5 :-). With KF5 aiming to be "just" a modular set of extensions to Qt 5, why not leave it like that, and just push the KDE devs to implement the file dialogs in something that's reasonably small and standalone? (Some) Previous transitions of KDE features into Qt's code base have been done taking into account only/mostly Linux specifics, leaving devs on other platforms (like Mac/OS X) with little choice but to patch Qt in some cases. Adding specific code to an extension library is usually preferable to patching Qt ... R. From mw_triad at users.sourceforge.net Thu Apr 2 17:58:58 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 02 Apr 2015 11:58:58 -0400 Subject: [Development] Why is QTBUG-27186 closed? In-Reply-To: <75204934.0Wft8z0VlW@portia.local> References: <551D4001.804@theqtcompany.com> <75204934.0Wft8z0VlW@portia.local> Message-ID: On 2015-04-02 10:38, René J.V. Bertin wrote: > On Thursday April 02 2015 09:46:29 Matthew Woehlke wrote: >> It may be too late to change this for Qt 4, but please, let's get it >> right for Qt 5 :-). > > With KF5 aiming to be "just" a modular set of extensions to Qt 5, why > not leave it like that, and just push the KDE devs to implement the > file dialogs in something that's reasonably small and standalone? Do you honestly expect that every Qt install on a Linux-based platform will also have the base KF5 libraries installed? Even on a machine that is otherwise running some other desktop (Gnome, XFCE, etc.)? (*Especially* on a machine that only has Qt installed because of some one-off application?) I don't find that reasonable. Nor does it help anyone who, for whatever reason¹, is disabling use of native dialogs. In short, I don't see this as a solution unless it *replaces* QFileDialog. (¹ And there *are* legitimate reasons. Some applications may need the ability to tweak the dialogs or their behavior. I've seen some do it just for cross-platform consistency.) > Adding specific code to an extension library is usually preferable to patching Qt ... There may be cases in which I would agree with that statement. This is not one of them. This is *not* a bug that is specific to Linux. It affects all platforms that do not replace QFileDialog with a platform native dialog, whether because such is not available, or because the user has disabled the native dialogs for whatever reason. It's not a platform issue, it is a defect in QFileDialog. Patching Qt is the *exact right* thing to do in this case. Instances where the patch are not appropriate are instances where the code shouldn't be executing in the first place². (² Maybe this means that the code change should check that the built-in dialog being used, and not a native dialog. That would make sense, and I would have no objection to having the change only apply in that case. The code change still needs to be made in Qt itself, however; the case that does not work is the case where an extension library is *not* in play.) -- Matthew From rjvbertin at gmail.com Thu Apr 2 18:27:48 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 02 Apr 2015 18:27:48 +0200 Subject: [Development] Why is QTBUG-27186 closed? In-Reply-To: References: <75204934.0Wft8z0VlW@portia.local> Message-ID: <2087790.79OzWLSzWl@portia.local> On Thursday April 02 2015 11:58:58 Matthew Woehlke wrote: > Do you honestly expect that every Qt install on a Linux-based platform > will also have the base KF5 libraries installed? Even on a machine that No, and I didn't say that. I did mention "reasonably small" and "standalone", meaning not requiring all of the base KF5 libraries. > (¹ And there *are* legitimate reasons. Some applications may need the > ability to tweak the dialogs or their behavior. I've seen some do it Isn't that exactly what this is about? How does fixing QFileDialog help applications that disable these dialogs to roll their own? > > Adding specific code to an extension library is usually preferable to patching Qt ... > > There may be cases in which I would agree with that statement. This is > not one of them. This is *not* a bug that is specific to Linux. It That statement was not specific to the QFileDialog issue, but referred to cases where we can no longer modify (adapt) downstream code (KDE) to do the appropriate thing on a non-Linux Unix platform, but have to resort to patch Qt. And in those cases it's much less clear-cut where the defect is. R From mw_triad at users.sourceforge.net Thu Apr 2 18:48:52 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 02 Apr 2015 12:48:52 -0400 Subject: [Development] Why is QTBUG-27186 closed? In-Reply-To: <2087790.79OzWLSzWl@portia.local> References: <75204934.0Wft8z0VlW@portia.local> <2087790.79OzWLSzWl@portia.local> Message-ID: On 2015-04-02 12:27, René J.V. Bertin wrote: > On Thursday April 02 2015 11:58:58 Matthew Woehlke wrote: >> Do you honestly expect that every Qt install on a Linux-based platform >> will also have the base KF5 libraries installed? Even on a machine that > > No, and I didn't say that. I did mention "reasonably small" and "standalone", meaning not requiring all of the base KF5 libraries. Yes, but unless it's *part of Qt*, it's still something else that you have to make a special effort to install (or else convince distros that Qt should package-require it). And if it is as small as you are suggesting, why *not* just have it be part of Qt? :-) >> (¹ And there *are* legitimate reasons. Some applications may need the >> ability to tweak the dialogs or their behavior. I've seen some do it > > Isn't that exactly what this is about? How does fixing QFileDialog > help applications that disable these dialogs to roll their own? In my experience, applications that roll their own do so by subclassing QFileDialog. Ergo, this has a chance of helping them. If they're completely rolling their own, then Qt has very limited ability to help them do the right thing, besides provide useful tools, which I think we already do to anything within the extent of "reasonable effort". Frankly, however, I am more concerned with applications that are just using the built-in QFileDialog as-is, which is the case this would benefit most directly. >>> Adding specific code to an extension library is usually preferable to patching Qt ... >> >> There may be cases in which I would agree with that statement. This is >> not one of them. This is *not* a bug that is specific to Linux. > > That statement was not specific to the QFileDialog issue [...] Fair enough. My reply was aimed at this specific case. As I said, in other instances, I may well agree. (I decline to commit to agreeing or not simply because I can't think of a concrete example case offhand.) -- Matthew From thiago.macieira at intel.com Fri Apr 3 08:11:05 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 02 Apr 2015 23:11:05 -0700 Subject: [Development] Why are qtbase integrations taking so long? Message-ID: <3936390.hoTgDX9YKn@tjmaciei-mobl4> qtbase integrations used to take around 3 hours as recently as two weeks ago. In the past week, I've caught several integrations lasting more than 6 hours. The one currently running is integrating a single commit and has been running for 6h30. I've seen one for 12 hours. Is this a timeout not caught by the coordinator? http://testresults.qt.io/ci/status/ says that it is in state "monitor-jenkins- build" and "build_attempt: 6". For attempt 5, the only stage not to be at SUCCESS was linux-g++_developer-build_qtnamespace_qtlibinfix_RHEL65_x64. The same for attempts 3 and 4. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kl222 at 126.com Fri Apr 3 08:21:19 2015 From: kl222 at 126.com (kl222) Date: Fri, 3 Apr 2015 14:21:19 +0800 (CST) Subject: [Development] fatal error: QByteArray: No such file or directory In-Reply-To: References: Message-ID: <2a3740ba.2fc.14c7df0dcdc.Coremail.kl222@126.com> Environment: windows 7 Ultimate msys2 g++ : (Rev5, Built by MSYS2 project) 4.9.2 Compile-timethe followingerror: tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory #include ^ compilation terminated. Makefile.Release:16625: recipe for target '.obj/release/qsimd.o' failed make[4]: *** [.obj/release/qsimd.o] Error 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at raven-worx.net Fri Apr 3 08:28:06 2015 From: info at raven-worx.net (raven-worx Software) Date: Fri, 03 Apr 2015 08:28:06 +0200 Subject: [Development] Errors in release mode only In-Reply-To: References: <20150330212127.20285o3july21vzr@login-7.hoststar.at> Message-ID: <20150403082806.18711y6wg9w8c35i@login-7.hoststar.at> i found what caused the issue: I accidentally also linked some other code to the application in which a static initialization of a QNetworkAccessManger happened. This also explains the different behavior between release and debug mode. >> QEventLoop: Cannot be used without QApplication > > Says everything. > > Show your code. > > Regards, > Konstantin > > 2015-03-30 23:21 GMT+04:00 raven-worx Software : > >> Hi, >> >> i get the following print outs to the console and absolutley have no clue >> why: >> >> SHIMVIEW: ShimInfo(Complete) >> QEventLoop: Cannot be used without QApplication >> QObject::connect: Cannot connect (null)::aboutToQuit() to >> QNativeWifiEngine::closeHandle() >> >> But this only happens in RELEASE MODE! DEBUG mode works fine and these >> print outs are not showing up. >> >> I even get these print outs when my main() only returns 0, so no >> QApplication is instantiated meaning as soon as i link against Qt >> binaries. >> >> Once the application starts up i also noticed that (queued) signals >> from other threads are not delivered anymore, which most probably >> involves the QEventLoop error message somehow. But on the other hand >> events from the OS are delivered. >> >> I am using: >> QtCreator 3.3.1, MSVC2012, Qt 5.4.1 >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > From rjvbertin at gmail.com Fri Apr 3 10:29:55 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 03 Apr 2015 10:29:55 +0200 Subject: [Development] Why are qtbase integrations taking so long? In-Reply-To: <3936390.hoTgDX9YKn@tjmaciei-mobl4> References: <3936390.hoTgDX9YKn@tjmaciei-mobl4> Message-ID: <18550765.lbAyMknX2N@patux> On Thursday April 02 2015 23:11:05 Thiago Macieira wrote: >qtbase integrations used to take around 3 hours as recently as two weeks ago. >In the past week, I've caught several integrations lasting more than 6 hours. >The one currently running is integrating a single commit and has been running >for 6h30. I've seen one for 12 hours. FWIW: in case you have CI/Jenkins bots running clang you may want to profile resource usage/availability. I've seen clang's memory use explode in very specific cases (1 file from the G'Mic project). I've watched it eat around 80% of RAM on a 4Gb linux set-up, after which the system became unresponsive. I've also seen this with MacPorts' clang on OS X, but not with Apple's version (though I now run with 12Gb RAM on OS X 10.9 with its RAM compression tech, which may be enough to keep clang happy). R. From Simon.Hausmann at theqtcompany.com Fri Apr 3 12:47:51 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 3 Apr 2015 10:47:51 +0000 Subject: [Development] Why are qtbase integrations taking so long? In-Reply-To: <3936390.hoTgDX9YKn@tjmaciei-mobl4> References: <3936390.hoTgDX9YKn@tjmaciei-mobl4> Message-ID: <20150403104750.5652547.74876.18467@theqtcompany.com> Hi, I believe what we are seeing is caused by instability in the network that connects the Jenkins service with the Jenkins slave machines. Occasionally network connectivity between the slaves and the master is lost, causing the running build as a whole to abort - all other still running builds are aborted and the results from builds that had already finished are discarded. In an attempt to recover, a whole new integration with builds for all configurations is started. We have observed that this scenario repeats itself several times, causing overall integration of many hours. As part of the work on the new CI system, we have observed similar network connectivity related symptoms. We are treating them more gracefully by not discarding otherwise successful results. Nevertheless it is a major annoyance. Based on rumors and observation of symptoms it is a theory ‎of Frederik and I that there is a firewall service centrally installed in this virtual network. It shows symptoms of connection tracking and - more importantly - signs of being able to handle only an insufficient amount of traffic or connections. Beyond that limit, connection attempts time out and existing connections become "spotty". I would like to get to the bottom of this at some point, because it severely affects the efficiency of the current ci system as well. Tony, do you happen to have any more details about this? I'll see about filing a ticket with IT next week unless we conclude anything different. Simon Original Message From: Thiago Macieira Sent: Friday, April 3, 2015 07:11 To: development at qt-project.org Subject: [Development] Why are qtbase integrations taking so long? qtbase integrations used to take around 3 hours as recently as two weeks ago. In the past week, I've caught several integrations lasting more than 6 hours. The one currently running is integrating a single commit and has been running for 6h30. I've seen one for 12 hours. Is this a timeout not caught by the coordinator? http://testresults.qt.io/ci/status/ says that it is in state "monitor-jenkins- build" and "build_attempt: 6". For attempt 5, the only stage not to be at SUCCESS was linux-g++_developer-build_qtnamespace_qtlibinfix_RHEL65_x64. The same for attempts 3 and 4. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From sahumada at texla.cl Fri Apr 3 13:26:07 2015 From: sahumada at texla.cl (Sergio Ahumada) Date: Fri, 03 Apr 2015 13:26:07 +0200 Subject: [Development] Why are qtbase integrations taking so long? In-Reply-To: <20150403104750.5652547.74876.18467@theqtcompany.com> References: <3936390.hoTgDX9YKn@tjmaciei-mobl4> <20150403104750.5652547.74876.18467@theqtcompany.com> Message-ID: <551E78CF.7040506@texla.cl> On 04/03/2015 12:47 PM, Hausmann Simon wrote: > Hi, > > I believe what we are seeing is caused by instability in the network that connects the Jenkins service with the Jenkins slave machines. Occasionally network connectivity between the slaves and the master is lost, causing the running build as a whole to abort - all other still running builds are aborted and the results from builds that had already finished are discarded. In an attempt to recover, a whole new integration with builds for all configurations is started. > > We have observed that this scenario repeats itself several times, causing overall integration of many hours. I think this is documented here: http://code.qt.io/cgit/qt/qtqa.git/tree/scripts/jenkins/qt-jenkins-integrator.pl#n439 once $MAX_ATTEMPTS is reached .. somobody needs to manually restart the integrator .. CI admins should be notified with an email like http://lists.qt-project.org/pipermail/ci-reports/2015-April/038140.html > As part of the work on the new CI system, we have observed similar network connectivity related symptoms. We are treating them more gracefully by not discarding otherwise successful results. Nevertheless it is a major annoyance. > > Based on rumors and observation of symptoms it is a theory ‎of Frederik and I that there is a firewall service centrally installed in this virtual network. It shows symptoms of connection tracking and - more importantly - signs of being able to handle only an insufficient amount of traffic or connections. Beyond that limit, connection attempts time out and existing connections become "spotty". > > I would like to get to the bottom of this at some point, because it severely affects the efficiency of the current ci system as well. > > Tony, do you happen to have any more details about this? > > I'll see about filing a ticket with IT next week unless we conclude anything different. > > Simon > > Original Message > From: Thiago Macieira > Sent: Friday, April 3, 2015 07:11 > To: development at qt-project.org > Subject: [Development] Why are qtbase integrations taking so long? > > > qtbase integrations used to take around 3 hours as recently as two weeks ago. > > In the past week, I've caught several integrations lasting more than 6 hours. > The one currently running is integrating a single commit and has been running > for 6h30. I've seen one for 12 hours. > > Is this a timeout not caught by the coordinator? > > http://testresults.qt.io/ci/status/ says that it is in state "monitor-jenkins- > build" and "build_attempt: 6". For attempt 5, the only stage not to be at > SUCCESS was linux-g++_developer-build_qtnamespace_qtlibinfix_RHEL65_x64. The > same for attempts 3 and 4. I think that the integrator (coordinator) gives up after 8 retries/attempts .. so if qtbase takes around 3 hrs to run and it is run 8 times .. you could easily wait (worst case) for 24 hrs if no action is taken -- Sergio Ahumada sahumada at texla.cl From alan.ezust at gmail.com Mon Apr 6 21:00:32 2015 From: alan.ezust at gmail.com (Alan Ezust) Date: Mon, 6 Apr 2015 12:00:32 -0700 Subject: [Development] Is QML Item design deliberately hindering C++ interaction? In-Reply-To: References: Message-ID: Personally, I feel that it will not be possible to write QtQuick network applications without some C++ until QUrl and lists of QUrl are supported in QML. The way QUrl are converted into strings in QML currently makes things very difficult for me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Apr 7 06:56:26 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 06 Apr 2015 21:56:26 -0700 Subject: [Development] Updating of 3rdparty stuff Message-ID: <3746511.o9TTYlrKsK@tjmaciei-mobl4> Any volunteers? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ulf.hermann at theqtcompany.com Tue Apr 7 10:20:14 2015 From: ulf.hermann at theqtcompany.com (Ulf Hermann) Date: Tue, 7 Apr 2015 10:20:14 +0200 Subject: [Development] git://code.qt.io availability In-Reply-To: References: Message-ID: <5523933E.4020509@theqtcompany.com> On 04/02/2015 11:03 AM, Koehne Kai wrote: > Since a few days code.qt.io seems to be quite unreliable: Fetching > changes via git:// often fail with "fatal: read error: Invalid > argument" (Windows) or "fatal: read error: Connection reset by peer" > (Linux). Also, the mirroring seems to fail. In the QtCreator repository quite a few changes that got merged last week are still not mirrored. See for example https://codereview.qt-project.org/109803 regards, Ulf -- Ulf Hermann, Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: ulf.hermann at theqtcompany.com | Mobile: + 49 151 68964561 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.io/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt From nicola at nicoladefilippo.it Tue Apr 7 12:24:57 2015 From: nicola at nicoladefilippo.it (Nicola De Filippo) Date: Tue, 7 Apr 2015 12:24:57 +0200 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: <3746511.o9TTYlrKsK@tjmaciei-mobl4> References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> Message-ID: Hi, all 3rdparty or only in qtbase? N. > Il giorno 07/apr/2015, alle ore 06:56, Thiago Macieira ha scritto: > > Any volunteers? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From announce at qt-project.org Tue Apr 7 13:30:36 2015 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Tue, 7 Apr 2015 11:30:36 +0000 Subject: [Development] [Announce] Qt Installer Framework 2.0.0 released Message-ID: We are happy to announce the release of the Qt Installer Framework 2.0.0 http://blog.qt.io/blog/2015/04/07/qt-installer-framework-2-0-released/ -------- Kai Köhne, Senior Software Engineer | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From paul.tvete at theqtcompany.com Tue Apr 7 14:10:39 2015 From: paul.tvete at theqtcompany.com (Paul Olav Tvete) Date: Tue, 7 Apr 2015 14:10:39 +0200 Subject: [Development] QGView and deprecated indirect painting In-Reply-To: <551B3BC2.10103@gna.org> References: <551B3BC2.10103@gna.org> Message-ID: <2694124.XFsUCjMf7L@dragaera> On Wednesday 1. April 2015 13.28.50 Christian Gagneraud wrote: > So, my question is: Do you guys plan to remove this feature, and if yes > (which seems likely to me), how could I then control colors, opacity and > drawing order on a per view basis? There is very little new development for graphics view. Essentially, we focus on stability, and only serious bugs are fixed. I will be very surprised if anyone would think it is a good idea to do a large change to remove features at this point, even if they are deprecated. However, there is a theoretical possibility that changes in other parts of Qt could break this feature, and in that case we might not prioritize fixing those bugs. TL;DR: No plans to remove it, but no guarantees that it will always continue working. - Paul From konstantin at podsvirov.pro Tue Apr 7 14:30:07 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Tue, 07 Apr 2015 15:30:07 +0300 Subject: [Development] [Announce] Qt Installer Framework 2.0.0 released In-Reply-To: References: Message-ID: <5334691428409807@web11g.yandex.ru> Good news! Been waiting for :-) I see in the change log: - Added --framework-version argument. This is a reason to update CPack IFW generator! (will do as will the time). Here is the link for those who are not in the subject: http://www.cmake.org/cmake/help/v3.2/module/CPackIFW.html 07.04.2015, 14:33, "List for announcements regarding Qt releases and development" : > We are happy to announce the release of the Qt Installer Framework 2.0.0 > > http://blog.qt.io/blog/2015/04/07/qt-installer-framework-2-0-released/ > > -------- > Kai Köhne, Senior Software Engineer | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development Regards, Konstantin Podsvirov From helio at kde.org Tue Apr 7 15:43:09 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Tue, 7 Apr 2015 10:43:09 -0300 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: <3746511.o9TTYlrKsK@tjmaciei-mobl4> References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> Message-ID: Raising my hand to help. []'s Helio On Tue, Apr 7, 2015 at 1:56 AM, Thiago Macieira wrote: > Any volunteers? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Apr 7 16:22:32 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Apr 2015 07:22:32 -0700 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> Message-ID: <1593185.aMUveFYZ8J@tjmaciei-mobl4> On Tuesday 07 April 2015 12:24:57 Nicola De Filippo wrote: > Hi, > all 3rdparty or only in qtbase? > N. No, unfortunately. There's a 3rdparty in qtcanvas3d, qtdeclarative, qtimageformats, qtlocation, qtmultimedia, qtscript, qttools and qtwayland. I know qtscript won't get an update. The others I don't know what requires updating or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From helio at kde.org Tue Apr 7 16:26:21 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Tue, 7 Apr 2015 11:26:21 -0300 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: <1593185.aMUveFYZ8J@tjmaciei-mobl4> References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> <1593185.aMUveFYZ8J@tjmaciei-mobl4> Message-ID: What we need look for to proceed ? Or just look on modules, update, test on the platforms and do a proper pull request ? On Tue, Apr 7, 2015 at 11:22 AM, Thiago Macieira wrote: > On Tuesday 07 April 2015 12:24:57 Nicola De Filippo wrote: > > Hi, > > all 3rdparty or only in qtbase? > > N. > > No, unfortunately. > > There's a 3rdparty in qtcanvas3d, qtdeclarative, qtimageformats, > qtlocation, > qtmultimedia, qtscript, qttools and qtwayland. > > I know qtscript won't get an update. The others I don't know what requires > updating or not. > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Tue Apr 7 16:29:06 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 07 Apr 2015 07:29:06 -0700 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> <1593185.aMUveFYZ8J@tjmaciei-mobl4> Message-ID: <2964799.ySXrmJIgFS@tjmaciei-mobl4> On Tuesday 07 April 2015 11:26:21 Helio Chissini de Castro wrote: > What we need look for to proceed ? > > Or just look on modules, update, test on the platforms and do a proper > pull request ? Right, that should be it. For the libs that are patched, re-apply the patches too. Since this is import of 3rdparty code, someone from The Qt Company needs to approve the change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tuukka.turunen at theqtcompany.com Tue Apr 7 16:46:37 2015 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Tue, 7 Apr 2015 14:46:37 +0000 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: <2964799.ySXrmJIgFS@tjmaciei-mobl4> References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> <1593185.aMUveFYZ8J@tjmaciei-mobl4> , <2964799.ySXrmJIgFS@tjmaciei-mobl4> Message-ID: <1428417996819.90853@theqtcompany.com> When updating 3rd party modules, it is good to include as reviewer someone from doc team (e.g. Topi Reiniö), someone from release team (e.g. Jani Heikkinen) and Lars as the chief maintainer to approve. In a typical case it is just about updating info in docs what version we have, but in case there are significant changes (e.g. in licensing or functionality) it may need to be considered if we can take the new version. Sometimes there has also been undesired side effects such as performance drop with a new version or a 3rd party module, so it is good to have release team in the loop. But in most cases newer is better also for 3rd party modules :) Yours, Tuukka ________________________________________ Lähettäjä: development-bounces+tuukka.turunen=theqtcompany.com at qt-project.org käyttäjän puolestaThiago Macieira Lähetetty: 7. huhtikuuta 2015 17:29 Vastaanottaja: development at qt-project.org Aihe: Re: [Development] Updating of 3rdparty stuff On Tuesday 07 April 2015 11:26:21 Helio Chissini de Castro wrote: > What we need look for to proceed ? > > Or just look on modules, update, test on the platforms and do a proper > pull request ? Right, that should be it. For the libs that are patched, re-apply the patches too. Since this is import of 3rdparty code, someone from The Qt Company needs to approve the change. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From steveire at gmail.com Tue Apr 7 16:59:20 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 7 Apr 2015 16:59:20 +0200 Subject: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase Message-ID: Something 'funny' is going on with https://codereview.qt-project.org/#/c/106855/ See qtbase commits * 0b6bfe8c448179ccf9272a309d6b9ddbdc055960 * d9437af198726e80d68ae4d95108cb08602d07f9 * 22b5e178e5a32988f8c23170288ef3d48df5f00d * 558c9cadddacea37669c28ec2abe62c8f5726e8e * 6dcbaa487d222440c2aeeb5f0ad3bc6337d52f5d * 23330d498d8b9b247fede83351a9843094540743 * 57c399c3e65d1339cf3c273adf840801686fb4da * 0b440e1498699d0fa37114453dce3f463f0752fb * b0c58c2bb4cde616302f98e4c64549ae2ae028cf at least, all of which are empty, and 72854081b2e3831ab6619a9c2e7f4ba0a6a1d316 which is not empty. The gerrit commit is 'staged' again even now. What's going on? Is anything being done about this already? It's making a messy history and it should be stopped. Thanks, Steve. From oswald.buddenhagen at theqtcompany.com Tue Apr 7 17:13:06 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Tue, 7 Apr 2015 17:13:06 +0200 Subject: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase In-Reply-To: References: Message-ID: <20150407151306.GD23807@troll08.it.local> On Tue, Apr 07, 2015 at 04:59:20PM +0200, Stephen Kelly wrote: > Something 'funny' is going on with > > https://codereview.qt-project.org/#/c/106855/ > apparently, it wasn't properly "tagged" after a manual fixup. i hacked the database now. everybody should check whether they don't have changes in a similarly unholy state. obviously, gerrit should refuse to create empty cherry-picks. that's a rather long-standing issue ... > See qtbase commits > > * 0b6bfe8c448179ccf9272a309d6b9ddbdc055960 > * d9437af198726e80d68ae4d95108cb08602d07f9 > * 22b5e178e5a32988f8c23170288ef3d48df5f00d > * 558c9cadddacea37669c28ec2abe62c8f5726e8e > * 6dcbaa487d222440c2aeeb5f0ad3bc6337d52f5d > * 23330d498d8b9b247fede83351a9843094540743 > * 57c399c3e65d1339cf3c273adf840801686fb4da > * 0b440e1498699d0fa37114453dce3f463f0752fb > * b0c58c2bb4cde616302f98e4c64549ae2ae028cf > > at least, all of which are empty, and > > 72854081b2e3831ab6619a9c2e7f4ba0a6a1d316 > > which is not empty. The gerrit commit is 'staged' again even now. > > What's going on? Is anything being done about this already? It's > making a messy history and it should be stopped. > From berkayelbir at gmail.com Tue Apr 7 18:56:25 2015 From: berkayelbir at gmail.com (Berkay Elbir) Date: Tue, 7 Apr 2015 19:56:25 +0300 Subject: [Development] [Announce] Qt Installer Framework 2.0.0 released In-Reply-To: References: Message-ID: Hello All, First, I want to congratulate you for your release. By the way, May I ask few questions to you? I have Qt Installer that are being used but I do not know which version it is. - How can I know the version of it? Also, I have two bugs that are following: - Progress Bar when installing is stopped %1 and then shows %90 then finishes. - When Uninstaller runs it does not check that program is running or not and it deletes some of files after that it shows uninstalling is successful. Is there anyone know these bugs? Thanks in advance, Berkay Elbir On Tue, Apr 7, 2015 at 2:30 PM, List for announcements regarding Qt releases and development wrote: > We are happy to announce the release of the Qt Installer Framework 2.0.0 > > http://blog.qt.io/blog/2015/04/07/qt-installer-framework-2-0-released/ > > > -------- > Kai Köhne, Senior Software Engineer | The Qt Company > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht > Charlottenburg, HRB 144331 B > _______________________________________________ > Announce mailing list > Announce at qt-project.org > http://lists.qt-project.org/mailman/listinfo/announce > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steveire at gmail.com Tue Apr 7 22:00:12 2015 From: steveire at gmail.com (Stephen Kelly) Date: Tue, 07 Apr 2015 22:00:12 +0200 Subject: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase References: <20150407151306.GD23807@troll08.it.local> Message-ID: Oswald Buddenhagen wrote: > On Tue, Apr 07, 2015 at 04:59:20PM +0200, Stephen Kelly wrote: >> Something 'funny' is going on with >> >> https://codereview.qt-project.org/#/c/106855/ >> > apparently, it wasn't properly "tagged" after a manual fixup. > i hacked the database now. Great, thanks. > everybody should check whether they don't have changes in a similarly > unholy state. Is the question "how did something creating this much mess go unnoticed for almost three weeks" something anyone feels like pursuing an answer too? Thanks, Steve. From mccarthy.aaron at gmail.com Wed Apr 8 01:37:30 2015 From: mccarthy.aaron at gmail.com (Aaron McCarthy) Date: Wed, 08 Apr 2015 09:37:30 +1000 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: <1593185.aMUveFYZ8J@tjmaciei-mobl4> References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> <1593185.aMUveFYZ8J@tjmaciei-mobl4> Message-ID: <12316599.CdU6CXJ0Jo@yuki> Hi, On Tue, 7 Apr 2015 07:22:32 Thiago Macieira wrote: > On Tuesday 07 April 2015 12:24:57 Nicola De Filippo wrote: > > Hi, > > all 3rdparty or only in qtbase? > > > > N. > > No, unfortunately. > > There's a 3rdparty in qtcanvas3d, qtdeclarative, qtimageformats, qtlocation, > qtmultimedia, qtscript, qttools and qtwayland. The 3rdparty code in qtlocation, poly2tri, was updated to the latest upstream version in January. No upstream changes have happened since then. Cheers, -- Aaron McCarthy From chgans at gna.org Wed Apr 8 05:40:13 2015 From: chgans at gna.org (Christian Gagneraud) Date: Wed, 08 Apr 2015 15:40:13 +1200 Subject: [Development] QGView and deprecated indirect painting In-Reply-To: <2694124.XFsUCjMf7L@dragaera> References: <551B3BC2.10103@gna.org> <2694124.XFsUCjMf7L@dragaera> Message-ID: <5524A31D.9030102@gna.org> On 08/04/15 00:10, Paul Olav Tvete wrote: > On Wednesday 1. April 2015 13.28.50 Christian Gagneraud wrote: >> So, my question is: Do you guys plan to remove this feature, and if yes >> (which seems likely to me), how could I then control colors, opacity and >> drawing order on a per view basis? > > There is very little new development for graphics view. Essentially, we focus > on stability, and only serious bugs are fixed. I will be very surprised if > anyone would think it is a good idea to do a large change to remove features > at this point, even if they are deprecated. > > However, there is a theoretical possibility that changes in other parts of Qt > could break this feature, and in that case we might not prioritize fixing those > bugs. > > TL;DR: No plans to remove it, but no guarantees that it will always continue > working. Hi Paul, Thanks for the clarification. Chris > > - Paul > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From cavendish.qi at gmail.com Wed Apr 8 10:15:47 2015 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 8 Apr 2015 10:15:47 +0200 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: <3746511.o9TTYlrKsK@tjmaciei-mobl4> References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> Message-ID: qtimageformats: libwebp 0.4.3 update https://codereview.qt-project.org/109955 https://codereview.qt-project.org/109956 And checked other 3rdparty: jasper, libmng, libtiff, there is no update from upstream. After Beta released, I will help to update qt doc and https://wiki.qt.io/Third_Party_In_Qt Regards, Liang On 7 April 2015 at 06:56, Thiago Macieira wrote: > Any volunteers? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- http://www.qiliang.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Wed Apr 8 12:55:37 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Wed, 8 Apr 2015 12:55:37 +0200 Subject: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase In-Reply-To: <20150407151306.GD23807@troll08.it.local> References: , <20150407151306.GD23807@troll08.it.local> Message-ID: An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Wed Apr 8 13:00:23 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Wed, 8 Apr 2015 13:00:23 +0200 Subject: [Development] "Add tests for detach on setDevicePixelRatio()" commits in qtbase In-Reply-To: References: , <20150407151306.GD23807@troll08.it.local>, Message-ID: An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Wed Apr 8 13:03:24 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Wed, 8 Apr 2015 13:03:24 +0200 Subject: [Development] git://code.qt.io availability In-Reply-To: <20150402110106.GC18282@troll08.it.local> References: , <20150402110106.GC18282@troll08.it.local> Message-ID: An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Apr 8 13:13:19 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 8 Apr 2015 13:13:19 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? Message-ID: <201504081313.19868.marc.mutz@kdab.com> Hi, I have in the past fixed #include mistakes such as #include for QSharedDataPointer, and even though each time the issue came up that this is a SiC change (but only for users that unduly rely on indirect includes), so far they were always accepted. When splitting off qHash() from qhash.h into qhashfunctions.h, I have come across many files that included qhash.h without using it, and likewise some for which qhashfunctions.h would suffice. One of them now got a -1 for being SiC. Can we please decide once and for all whether #include cleanups that are technically SiC are ok or not, if they only affect users that rely on indirect includes? My vote obviously goes to allowing them. Rationale: We're also allowing adding new overloads of functions, which is SiC for code that takes the address of a functions. We allow it, because there's an easy fix that is both forward and backwards-compatible: explcitly cast pointers to these functions. Something that should probably have been done defensively to begin with. So is #include'ing all required headers yourself. It makes no sense to allow one and forbit the other. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From eirik.aavitsland at theqtcompany.com Wed Apr 8 13:28:49 2015 From: eirik.aavitsland at theqtcompany.com (Eirik Aavitsland) Date: Wed, 8 Apr 2015 13:28:49 +0200 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> Message-ID: <552510F1.8030501@theqtcompany.com> Good stuff, and libpng gets updated to 1.6.17 here https://codereview.qt-project.org/109973 - Eirik Aa. On 04/08/2015 10:15 AM, Liang Qi wrote: > qtimageformats: libwebp 0.4.3 update > > https://codereview.qt-project.org/109955 > https://codereview.qt-project.org/109956 > > And checked other 3rdparty: jasper, libmng, libtiff, there is no update > from upstream. > > After Beta released, I will help to update qt doc and > https://wiki.qt.io/Third_Party_In_Qt > > Regards, > Liang > > > On 7 April 2015 at 06:56, Thiago Macieira > wrote: > > Any volunteers? > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > http://www.qiliang.net > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From ritt.ks at gmail.com Wed Apr 8 13:31:19 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Wed, 8 Apr 2015 15:31:19 +0400 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: <552510F1.8030501@theqtcompany.com> References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> <552510F1.8030501@theqtcompany.com> Message-ID: 2015-04-08 15:28 GMT+04:00 Eirik Aavitsland < eirik.aavitsland at theqtcompany.com>: > > Good stuff, and libpng gets updated to 1.6.17 here > https://codereview.qt-project.org/109973 > > - Eirik Aa. > Someone have to upstream the WinCE and WinRT specific patches to libpng. Konstantin > > On 04/08/2015 10:15 AM, Liang Qi wrote: > > qtimageformats: libwebp 0.4.3 update > > > > https://codereview.qt-project.org/109955 > > https://codereview.qt-project.org/109956 > > > > And checked other 3rdparty: jasper, libmng, libtiff, there is no update > > from upstream. > > > > After Beta released, I will help to update qt doc and > > https://wiki.qt.io/Third_Party_In_Qt > > > > Regards, > > Liang > > > > > > On 7 April 2015 at 06:56, Thiago Macieira > > wrote: > > > > Any volunteers? > > -- > > Thiago Macieira - thiago.macieira (AT) intel.com > > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > > > -- > > http://www.qiliang.net > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten.heimrich at digia.com Wed Apr 8 14:14:17 2015 From: karsten.heimrich at digia.com (Karsten Heimrich) Date: Wed, 8 Apr 2015 14:14:17 +0200 Subject: [Development] [Announce] Qt Installer Framework 2.0.0 released In-Reply-To: References: Message-ID: <55251B99.10508@digia.com> Hi, On 07.04.2015 18:56, Berkay Elbir wrote: > Hello All, > > First, I want to congratulate you for your release. By the way, May I > ask few questions to you? > > I have Qt Installer that are being used but I do not know which > version it is. > > - How can I know the version of it? With the new release there are two options: --version Displays version information. --framework-version Displays the version of the Qt Installer Framework. > > Also, I have two bugs that are following: > > - Progress Bar when installing is stopped %1 and then shows %90 then > finishes. You should report the issue here: https://bugreports.qt.io > - When Uninstaller runs it does not check that program is running or > not and it deletes some of files after that it shows uninstalling is > successful. With the new version you can specify a control script for the uninstaller and check if the application is running. More information can be found here: http://doc.qt.io/qtinstallerframework/noninteractive.html http://doc.qt.io/qtinstallerframework/scripting-installer.html#isProcessRunning-method Regards, -------- Karsten Heimrich, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: karsten.heimrich at theqtcompany.com | Mobile: + 49 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Wed Apr 8 14:28:54 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 8 Apr 2015 14:28:54 +0200 Subject: [Development] git://code.qt.io availability In-Reply-To: References: <20150402110106.GC18282@troll08.it.local> Message-ID: <20150408122854.GA17561@troll08.it.local> On Wed, Apr 08, 2015 at 01:03:24PM +0200, Gunnar Roth wrote: > + git config remote.origin.url https://code.qt.io/cgit/qt/qt3d.git > this definitely doesn't look right (the git repos are not served under cgit/, at least not intentionally). fix the remote of qt5.git and retry. From olivier at woboq.com Wed Apr 8 14:34:03 2015 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 08 Apr 2015 14:34:03 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <201504081313.19868.marc.mutz@kdab.com> References: <201504081313.19868.marc.mutz@kdab.com> Message-ID: <2894889.l2PuTvdTzZ@finn> On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote: > Hi, > > I have in the past fixed #include mistakes such as #include > for QSharedDataPointer, and even though each time the > issue came up that this is a SiC change (but only for users that unduly > rely on indirect includes), so far they were always accepted. > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have come > across many files that included qhash.h without using it, and likewise some > for which qhashfunctions.h would suffice. One of them now got a -1 for being > SiC. > > Can we please decide once and for all whether #include cleanups that are > technically SiC are ok or not, if they only affect users that rely on > indirect includes? > > My vote obviously goes to allowing them. My vote goes against such gratuitous SiC changes. Each little SiC changes add up in frustration for the developer who upgrades its Qt version. So when it is easy to avoid, we should avoid it. > Rationale: We're also allowing adding new overloads of functions, which is > SiC for code that takes the address of a functions. We allow it, because > there's an easy fix that is both forward and backwards-compatible: > explcitly cast pointers to these functions. Something that should probably > have been done defensively to begin with. So is #include'ing all required > headers yourself. > > It makes no sense to allow one and forbit the other. I think you cannot really compare those two: - One almost never take the address of a function. (Unless it is a signal or a slot, in which case i think it is best not to add overload) While relying on indirect #include happens all the time as most only add the #include to fix a compilation error. - Adding an overload often lead to a better API and is therefore something worth doing even if there is small breakage. Removing #includes might at best give a negligible impact on compilation speed. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From gunnar.roth at gmx.de Wed Apr 8 15:08:15 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Wed, 8 Apr 2015 15:08:15 +0200 Subject: [Development] git://code.qt.io availability In-Reply-To: <20150408122854.GA17561@troll08.it.local> References: <20150402110106.GC18282@troll08.it.local> , <20150408122854.GA17561@troll08.it.local> Message-ID: Hi >> + git config remote.origin.url https://code.qt.io/cgit/qt/qt3d.git >> >this definitely doesn't look right (the git repos are not served under >cgit/, at least not intentionally). fix the remote of qt5.git and retry.   Without cgit it does not work for https last time i tried. See my mail from 31.03.2015 12:18 My problem was different as it was due to a interrupted transfer as i know now, i could fix that with the help of http://stackoverflow.com/questions/10671638/how-to-fix-git-repository-broken-by-interrupted-git-fetch by deleting offending *.pack.temp in .git/objects/pack and corresponding idx file. Now it works again ( with cgit ) Regards, Gunnar From frederik.gladhorn at theqtcompany.com Wed Apr 8 15:18:27 2015 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Wed, 8 Apr 2015 15:18:27 +0200 Subject: [Development] Qt Quick Controls for Embedded Message-ID: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> Hi all, as announced by JP's blog post, we've been working on a new set of Qt Quick Controls that have slightly different goals than the existing ones: http://blog.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded/ The main target is performance, especially on low end hardware. The code will live in the qtquickcontrols module, next to the existing controls. For now there is only one style supported, with some theming capabilities. This is an important point to get top notch performance. Now is the time to give everyone the chance to play with the new controls which are at a "tech preview" level. Since the architecture is different, we want to keep a clean separation in the qtquickcontrols git module and will move the code around to accommodate both modules within the repository. The plan is to create two top level directories in the repository: a controls1 directory containing everything currently in the repository (src/tests/examples), and a controls2 directory to contain the new controls. Note that both sets of controls will be co-installable and work together. That is to say, the following will work just fine: import QtQuick.Controls 1.x as Controls1 import QtQuick.Controls 2.x After a long discussion, we think that going with a major version is easiest, as we didn't find a great name that makes it clear what the new control set provides; "Embedded Controls" or "Touch Controls" don't quite seem right. Greetings, Frederik From akseli.salovaara at theqtcompany.com Wed Apr 8 15:37:09 2015 From: akseli.salovaara at theqtcompany.com (Salovaara Akseli) Date: Wed, 8 Apr 2015 13:37:09 +0000 Subject: [Development] New Qt 4.8.7 snapshot build is available Message-ID: Hi, New Qt 4.8.7 snapshot build is available http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-04-07-6/ Snapshot is built against sha1 716fbaef34386c8b05d7d63894a5bc116ddd1b6c Update copyright headers (current HEAD). Final sha1 and exact release date are open. Changes compared to previous snapshot: http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-04-07-6/4.8.7-snapshot-2015-04-07-6-changes Changes compared to Qt 4.8.6: http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-04-07-6/4.8.7-snapshot-2015-04-07-6-all-changes Please test these snapshots, report possible regressions to bugreports.qt.io and send email about that (with bug id) to releasing at qt-project.org. Br, Akseli -- Akseli Salovaara The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From szehowe.koh at gmail.com Wed Apr 8 16:06:21 2015 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Wed, 8 Apr 2015 22:06:21 +0800 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: <5523A3F5.6000900@theqtcompany.com> References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <5523A3F5.6000900@theqtcompany.com> Message-ID: On 7 April 2015 at 17:31, Joerg Bornemann wrote: > > On 07-Apr-15 09:59, Dominique Fober wrote: > > > I'm using the new QJSEngine and I'm trying to get the error line number (in case of error of course). > > Currently I'm handling errors as documented: > > > > if (result.isError()) result.toString().toUtf8() ... > > > > but actually, the string is very poor: e.g. "SyntaxError: Syntax error" > > I would like to get at least a line number. Contextual information would be also welcome. > > Is it possible with the QJSEngine? (I'm using Qt 5.3.0) > > Try to access the properties "message", "fileName" and "lineNumber". > > if (result.isError()) > qDebug() << result.property("fileName").toString(); Ooh, this is news to me. I think we should document this somewhere, if it isn't already done (I searched but couldn't find anything). I'm happy to volunteer if necessary. Could you please provide a list of built-in properties of various QJSValue types? Also, what do you think of some API that returns a list of available properties? (similar to QObject::dynamicPropertyNames() ) > result is a JavaScript Error object iff isError returns true. Regards, Sze-Howe From joerg.bornemann at theqtcompany.com Wed Apr 8 16:10:14 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Wed, 8 Apr 2015 16:10:14 +0200 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <5523A3F5.6000900@theqtcompany.com> Message-ID: <552536C6.8040804@theqtcompany.com> On 08-Apr-15 16:06, Sze Howe Koh wrote: > I think we should document this somewhere, if it isn't already done (I > searched but couldn't find anything). I'm happy to volunteer if > necessary. Could you please provide a list of built-in properties of > various QJSValue types? The docs state mention that isError() returns true if the value is an object of the Error class. That's a JavaScript class. We shouldn't duplicate the JavaScript documentation. > Also, what do you think of some API that returns a list of available > properties? (similar to QObject::dynamicPropertyNames() ) See QJSValueIterator. BR, Joerg From oswald.buddenhagen at theqtcompany.com Wed Apr 8 16:30:23 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 8 Apr 2015 16:30:23 +0200 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> Message-ID: <20150408143023.GA9172@troll08.it.local> On Wed, Apr 08, 2015 at 03:18:27PM +0200, Frederik Gladhorn wrote: > we want to keep a clean separation in the qtquickcontrols git module > and will move the code around to accommodate both modules within the > repository. The plan is to create two top level directories in the > repository: a controls1 directory containing everything currently in > the repository (src/tests/examples), and a controls2 directory to > contain the new controls. > what's the point of keeping them in the same repo when you split it at the top anyway? you just break the uniformity of the repo layout, which is both ugly and traditionally a nightmare build system wise (cf. webkit). From frederik.gladhorn at theqtcompany.com Wed Apr 8 16:39:52 2015 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Wed, 8 Apr 2015 16:39:52 +0200 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: <20150408143023.GA9172@troll08.it.local> References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> <20150408143023.GA9172@troll08.it.local> Message-ID: <2787909.Rxoz4u53b7@frederik-thinkcentre-m93p> On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote: > On Wed, Apr 08, 2015 at 03:18:27PM +0200, Frederik Gladhorn wrote: > > we want to keep a clean separation in the qtquickcontrols git module > > and will move the code around to accommodate both modules within the > > repository. The plan is to create two top level directories in the > > repository: a controls1 directory containing everything currently in > > the repository (src/tests/examples), and a controls2 directory to > > contain the new controls. > > what's the point of keeping them in the same repo when you split it at > the top anyway? you just break the uniformity of the repo layout, which > is both ugly and traditionally a nightmare build system wise (cf. > webkit). The idea was to make code-sharing easy and to lessen the burden on everyone to check out yet another repository etc. As for the build system, I see it similar to how the qt5.git meta module behaves - just two subdirs for the qtquickcontrols repo and that's it. We haven't actually done the merge yet, just tested that it would be feasible, so this is not set in stone. It seems that re-using the name will also cause trouble with documentation and tooling, so ideally we find the perfect new name for both module and repository. Sadly we didn't manage to come up with a great name in a few hours of brain storming. Maybe we just need someone from the outside to come along with a great idea :) Cheers, Frederik From oswald.buddenhagen at theqtcompany.com Wed Apr 8 17:35:07 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Wed, 8 Apr 2015 17:35:07 +0200 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: <2787909.Rxoz4u53b7@frederik-thinkcentre-m93p> References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> <20150408143023.GA9172@troll08.it.local> <2787909.Rxoz4u53b7@frederik-thinkcentre-m93p> Message-ID: <20150408153507.GB9172@troll08.it.local> On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote: > On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote: > > what's the point of keeping them in the same repo when you split it at > > the top anyway? you just break the uniformity of the repo layout, which > > is both ugly and traditionally a nightmare build system wise (cf. > > webkit). > > The idea was to make code-sharing easy > is this actually planned? is it expect to happen to a significant degree? if the answer is yes, then the top-level split is not the right way to go anyway. > and to lessen the burden on everyone to check out yet another > repository etc. > this doesn't sound all that convincing. > As for the build system, I see it similar to how the qt5.git meta module > behaves - just two subdirs for the qtquickcontrols repo and that's it. > i'm already having nightmares. > It seems that re-using the name will also cause trouble with > documentation and tooling, > documentation and any kind of use works on the module level, not at the repo level. > so ideally we find the perfect new name for both module and > repository. Sadly we didn't manage to come up with a great name in a > few hours of brain storming. > i think quick controls 2 will work just fine. it's not like people are not used to "asynchronous" versioning in the qt quick world. but anyway, here are some more ideas: - the classic: qt quick controls NG - the diet: qt quick controls light - the thesaurus: qt quick widgets - the cynic: qt quicker controls From helio at kde.org Wed Apr 8 17:42:59 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Wed, 8 Apr 2015 12:42:59 -0300 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> <552510F1.8030501@theqtcompany.com> Message-ID: Hi I just started a simple spreadsheet on the status of 3rdparty code. I enabled the doc to comments. Here: https://docs.google.com/spreadsheets/d/1xOAI87zKy6w7VSvSzQrIA_zeZBLuTgoSmNU-vAXrIhY/edit?usp=sharing Now need discover the feasibility to do some of them. []'s Helio On Wed, Apr 8, 2015 at 8:31 AM, Konstantin Ritt wrote: > 2015-04-08 15:28 GMT+04:00 Eirik Aavitsland < > eirik.aavitsland at theqtcompany.com>: > >> >> Good stuff, and libpng gets updated to 1.6.17 here >> https://codereview.qt-project.org/109973 >> >> - Eirik Aa. >> > > Someone have to upstream the WinCE and WinRT specific patches to libpng. > > Konstantin > > > >> >> On 04/08/2015 10:15 AM, Liang Qi wrote: >> > qtimageformats: libwebp 0.4.3 update >> > >> > https://codereview.qt-project.org/109955 >> > https://codereview.qt-project.org/109956 >> > >> > And checked other 3rdparty: jasper, libmng, libtiff, there is no update >> > from upstream. >> > >> > After Beta released, I will help to update qt doc and >> > https://wiki.qt.io/Third_Party_In_Qt >> > >> > Regards, >> > Liang >> > >> > >> > On 7 April 2015 at 06:56, Thiago Macieira > > > wrote: >> > >> > Any volunteers? >> > -- >> > Thiago Macieira - thiago.macieira (AT) intel.com >> > Software Architect - Intel Open Source Technology Center >> > >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> > >> > >> > >> > >> > -- >> > http://www.qiliang.net >> > >> > >> > _______________________________________________ >> > Development mailing list >> > Development at qt-project.org >> > http://lists.qt-project.org/mailman/listinfo/development >> > >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From szehowe.koh at gmail.com Wed Apr 8 17:45:29 2015 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Wed, 8 Apr 2015 23:45:29 +0800 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: <552536C6.8040804@theqtcompany.com> References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <5523A3F5.6000900@theqtcompany.com> <552536C6.8040804@theqtcompany.com> Message-ID: On 8 April 2015 at 22:10, Joerg Bornemann wrote: > On 08-Apr-15 16:06, Sze Howe Koh wrote: > >> I think we should document this somewhere, if it isn't already done (I >> searched but couldn't find anything). I'm happy to volunteer if >> necessary. Could you please provide a list of built-in properties of >> various QJSValue types? > > > The docs state mention that isError() returns true if the value is an object > of the Error class. That's a JavaScript class. We shouldn't duplicate the > JavaScript documentation. There are two issues here: 1. The "lineNumber" and "fileName" properties are non-standard. They are Mozilla extensions (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Error ), so even some JavaScript devs might not know they exist. 2. The reader might not make the connection, "This is a JavaScript Error object, therefore it has properties that help me debug" -- especially if they don't have a JavaScript background (which I presume is true for a significant number of Qt users). Personally, I scoured the QJSValue page looking for debugging hints, and the only thing that jumped out at me was QJSValue::toString(). May I suggest adding a bit of documentation on our side to help people discover the features? Currently, http://doc.qt.io/qt-5/qjsengine.html#script-exceptions only recommends using toString() to probe errors. That's an ideal place to add a list of standard and non-standard properties that users can take advantage of. >> Also, what do you think of some API that returns a list of available >> properties? (similar to QObject::dynamicPropertyNames() ) > > > See QJSValueIterator. Got it, thanks. Going off on a slight tangent: https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is converted to a QVariantMap. Each property is converted to a QVariant, recursively". However, calling toVariant() on an Error object (isError() == isObject() == true) produces an empty QVariantMap event though QJSValueIterator gets the properties just fine (using Qt 5.4.1). Is this expected? Regards, Sze-Howe From berkayelbir at gmail.com Wed Apr 8 19:22:24 2015 From: berkayelbir at gmail.com (Berkay Elbir) Date: Wed, 8 Apr 2015 20:22:24 +0300 Subject: [Development] [Announce] Qt Installer Framework 2.0.0 released In-Reply-To: <55251B99.10508@digia.com> References: <55251B99.10508@digia.com> Message-ID: Hi, Thanks for your answer. That was very helpful. Actually, I installed newer version of Qt Installer Framework (1.5.0) then I saw that progress bar bug is fixed. Probably, problem should be solved at 2.0.0 version as well. For the scripts, I will try to implement them. Best Regards, Berkay Elbir On Wed, Apr 8, 2015 at 3:14 PM, Karsten Heimrich wrote: > Hi, > > On 07.04.2015 18:56, Berkay Elbir wrote: > > Hello All, > > First, I want to congratulate you for your release. By the way, May I > ask few questions to you? > > I have Qt Installer that are being used but I do not know which version > it is. > > - How can I know the version of it? > > With the new release there are two options: > > --version Displays version information. > --framework-version Displays the version of the Qt Installer > Framework. > > > Also, I have two bugs that are following: > > - Progress Bar when installing is stopped %1 and then shows %90 then > finishes. > > You should report the issue here: https://bugreports.qt.io > > - When Uninstaller runs it does not check that program is running or > not and it deletes some of files after that it shows uninstalling is > successful. > > With the new version you can specify a control script for the uninstaller > and check if the application is running. > > More information can be found here: > http://doc.qt.io/qtinstallerframework/noninteractive.html > > http://doc.qt.io/qtinstallerframework/scripting-installer.html#isProcessRunning-method > > Regards, > > -------- > Karsten Heimrich, Senior Software Engineer | The Qt Company > > Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > Email: karsten.heimrich at theqtcompany.com | Mobile: + 49 | Phone: +49 30 63 92 3255 www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kl222 at 126.com Thu Apr 9 08:47:06 2015 From: kl222 at 126.com (kl222) Date: Thu, 9 Apr 2015 14:47:06 +0800 Subject: [Development] Build qt fail Message-ID: <000001d07291$165be550$4313aff0$@126.com> Environment: Operation System: windows7 Ultimate Msys2: MINGW32_NT-6.1 l-PC 2.1.0(0.287/5/3) 2015-04-05 21:26 i686 Msys Bash: GNU bash，version 4.3.33(3)-release (i686-pc-msys) Gcc: gcc.exe (Rev5, Built by MSYS2 project) 4.9.2 Perl: This is perl 5, version 20, subversion 2 (v5.20.2) built for i686-msys-thread-multi-64int Python: Python 3.3.3 Error message: g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions -mthreads -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. -I../../include -I../../include/QtCore -I../../include/QtCore/5.5.0 -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o .obj/release/qsimd.o tools/qsimd.cpp tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory #include ^ compilation terminated. Makefile.Release:16625: recipe for target '.obj/release/qsimd.o' failed make[4]: *** [.obj/release/qsimd.o] Error 1 make[4]: Leaving directory '/d/source/qt5/qtbase/src/corelib' Makefile:34: recipe for target 'release' failed make[3]: *** [release] Error 2 make[3]: Leaving directory '/d/source/qt5/qtbase/src/corelib' Makefile:165: recipe for target 'sub-corelib-make_first' failed make[2]: *** [sub-corelib-make_first] Error 2 make[2]: Leaving directory '/d/source/qt5/qtbase/src' Makefile:41: recipe for target 'sub-src-make_first' failed make[1]: *** [sub-src-make_first] Error 2 make[1]: Leaving directory '/d/source/qt5/qtbase' Makefile:69: recipe for target 'module-qtbase-make_first' failed make: *** [module-qtbase-make_first] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sierdzio at gmail.com Thu Apr 9 10:27:18 2015 From: sierdzio at gmail.com (Tomasz Siekierda) Date: Thu, 9 Apr 2015 10:27:18 +0200 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: <20150408153507.GB9172@troll08.it.local> References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> <20150408143023.GA9172@troll08.it.local> <2787909.Rxoz4u53b7@frederik-thinkcentre-m93p> <20150408153507.GB9172@troll08.it.local> Message-ID: On 8 April 2015 at 17:35, Oswald Buddenhagen wrote: > On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote: >> On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote: >> so ideally we find the perfect new name for both module and >> repository. Sadly we didn't manage to come up with a great name in a >> few hours of brain storming. >> > i think quick controls 2 will work just fine. it's not like people are > not used to "asynchronous" versioning in the qt quick world. > > but anyway, here are some more ideas: > - the classic: qt quick controls NG > - the diet: qt quick controls light > - the thesaurus: qt quick widgets > - the cynic: qt quicker controls I like QtQuick.LightControls. In general, since both sets are drastically different (in way they look like, in the way they perform, in styling capabilities, etc.) I do not think giving them similar names (Controls 1 and Controls 2) is a good idea - it may strongly confuse the users. Not everybody follows the mailing list and blog, so if you name them similarly you can expect a flood of questions like "I'm trying to use the new Controls, but X does not work, and Y looks different, while Z can't read my style definition" etc. From mingw.android at gmail.com Thu Apr 9 10:28:55 2015 From: mingw.android at gmail.com (Ray Donnelly) Date: Thu, 9 Apr 2015 09:28:55 +0100 Subject: [Development] Build qt fail In-Reply-To: <000001d07291$165be550$4313aff0$@126.com> References: <000001d07291$165be550$4313aff0$@126.com> Message-ID: On Thu, Apr 9, 2015 at 7:47 AM, kl222 wrote: > Environment: > > Operation System: windows7 Ultimate > > Msys2: MINGW32_NT-6.1 l-PC 2.1.0(0.287/5/3) 2015-04-05 21:26 i686 Msys > > Bash: GNU bash，version 4.3.33(3)-release (i686-pc-msys) > > Gcc: gcc.exe (Rev5, Built by MSYS2 project) 4.9.2 > > Perl: This is perl 5, version 20, subversion 2 (v5.20.2) built for > i686-msys-thread-multi-64int > > Python: Python 3.3.3 > > > > > > Error message: > > > > g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport > -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions -mthreads > -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV > -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB > -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES > -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER > -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 > -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. -I../../include > -I../../include/QtCore -I../../include/QtCore/5.5.0 > -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre > -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 > -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o > .obj/release/qsimd.o tools/qsimd.cpp > > tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory > > #include > > ^ > > compilation terminated. > > Makefile.Release:16625: recipe for target '.obj/release/qsimd.o' failed > > make[4]: *** [.obj/release/qsimd.o] Error 1 > > make[4]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:34: recipe for target 'release' failed > > make[3]: *** [release] Error 2 > > make[3]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:165: recipe for target 'sub-corelib-make_first' failed > > make[2]: *** [sub-corelib-make_first] Error 2 > > make[2]: Leaving directory '/d/source/qt5/qtbase/src' > > Makefile:41: recipe for target 'sub-src-make_first' failed > > make[1]: *** [sub-src-make_first] Error 2 > > make[1]: Leaving directory '/d/source/qt5/qtbase' > > Makefile:69: recipe for target 'module-qtbase-make_first' failed > > make: *** [module-qtbase-make_first] Error 2 > Hi, You need to post full reproduction instructions or a link to them to help us to diagnose this. > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From simon.hausmann at theqtcompany.com Thu Apr 9 10:39:57 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Thu, 9 Apr 2015 10:39:57 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <2894889.l2PuTvdTzZ@finn> References: <201504081313.19868.marc.mutz@kdab.com> <2894889.l2PuTvdTzZ@finn> Message-ID: <12661469.efp2qu8vhJ@rhea> On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote: > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote: > > Hi, > > > > I have in the past fixed #include mistakes such as #include > > for QSharedDataPointer, and even though each time the > > issue came up that this is a SiC change (but only for users that unduly > > rely on indirect includes), so far they were always accepted. > > > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have come > > across many files that included qhash.h without using it, and likewise > > some > > for which qhashfunctions.h would suffice. One of them now got a -1 for > > being SiC. > > > > Can we please decide once and for all whether #include cleanups that are > > technically SiC are ok or not, if they only affect users that rely on > > indirect includes? > > > > My vote obviously goes to allowing them. > > My vote goes against such gratuitous SiC changes. > > Each little SiC changes add up in frustration for the developer who upgrades > its Qt version. > So when it is easy to avoid, we should avoid it. I'm with Olivier on this one. Source compatibility is a key contribution to the success of Qt. For developers building their own software it may not be such a big deal, if they are experienced Qt developers. For somebody who just clones a random project off github and then tries to build it, such a "simple" source incompatible change becomes a deal breaker. I argue that there's a high probability that person is not familiar with these types of changes nor knowledgeable how to fix them. I've encountered this numerous times myself for example trying to keep the nvidia modules on my Laptop compiling with a changing kernel API. Often the fixes are _absolutely_ trivial one liners about missing includes. But I more often can't be bothered to dive into the source code to figure out what to add where. And then we have exactly the element of frustration that harms the product. Simon From joerg.bornemann at theqtcompany.com Thu Apr 9 11:08:24 2015 From: joerg.bornemann at theqtcompany.com (Joerg Bornemann) Date: Thu, 9 Apr 2015 11:08:24 +0200 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <5523A3F5.6000900@theqtcompany.com> <552536C6.8040804@theqtcompany.com> Message-ID: <55264188.3090909@theqtcompany.com> On 08-Apr-15 17:45, Sze Howe Koh wrote: > May I suggest adding a bit of documentation on our side to help people > discover the features? Currently, > http://doc.qt.io/qt-5/qjsengine.html#script-exceptions only recommends > using toString() to probe errors. That's an ideal place to add a list > of standard and non-standard properties that users can take advantage > of. Point taken. In the light that the most interesting properties here are non-standard I agree that we should extend the docs. > Going off on a slight tangent: > https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is > converted to a QVariantMap. Each property is converted to a QVariant, > recursively". However, calling toVariant() on an Error object > (isError() == isObject() == true) produces an empty QVariantMap event > though QJSValueIterator gets the properties just fine (using Qt > 5.4.1). Is this expected? I cannot answer this. But I wouldn't have expected this behavior. :) BR, Joerg From frank.osterfeld at kdab.com Thu Apr 9 11:20:30 2015 From: frank.osterfeld at kdab.com (Frank Osterfeld) Date: Thu, 9 Apr 2015 11:20:30 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <201504081313.19868.marc.mutz@kdab.com> References: <201504081313.19868.marc.mutz@kdab.com> Message-ID: > On 08 Apr 2015, at 13:13, Marc Mutz wrote: > > Hi, > > I have in the past fixed #include mistakes such as #include > for QSharedDataPointer, and even though each time the issue came up that this > is a SiC change (but only for users that unduly rely on indirect includes), so > far they were always accepted. > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have come > across many files that included qhash.h without using it, and likewise some > for which qhashfunctions.h would suffice. One of them now got a -1 for being > SiC. > > Can we please decide once and for all whether #include cleanups that are > technically SiC are ok or not, if they only affect users that rely on indirect > includes? > > My vote obviously goes to allowing them. I had to fix includes when building client code with 5.5 branch (coming from 5.4.1), so this is an actual issue right now, not just a theoretical one. I can do more research which headers I needed to include, if that’s a help to anyone. -- Frank Osterfeld | frank.osterfeld at kdab.com | Senior Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3877 bytes Desc: not available URL: From simon.hausmann at theqtcompany.com Thu Apr 9 11:52:31 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Thu, 9 Apr 2015 11:52:31 +0200 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <552536C6.8040804@theqtcompany.com> Message-ID: <3682276.Ia6Rxzu1m6@rhea> On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote: [...] > Going off on a slight tangent: > https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is > converted to a QVariantMap. Each property is converted to a QVariant, > recursively". However, calling toVariant() on an Error object > (isError() == isObject() == true) produces an empty QVariantMap event > though QJSValueIterator gets the properties just fine (using Qt > 5.4.1). Is this expected? That could be a bug. You should see the enumerable properties, which I think include message and name. If a strack trace was producible at constructor time, then you should also see the fileName and lineNumber properties. "stack" however will not be visible. Simon From marc.mutz at kdab.com Thu Apr 9 12:34:17 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Apr 2015 12:34:17 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <12661469.efp2qu8vhJ@rhea> References: <201504081313.19868.marc.mutz@kdab.com> <2894889.l2PuTvdTzZ@finn> <12661469.efp2qu8vhJ@rhea> Message-ID: <201504091234.17718.marc.mutz@kdab.com> On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote: > On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote: > > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote: > > > Hi, > > > > > > I have in the past fixed #include mistakes such as #include > > > for QSharedDataPointer, and even though each time > > > the issue came up that this is a SiC change (but only for users that > > > unduly rely on indirect includes), so far they were always accepted. > > > > > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have > > > come across many files that included qhash.h without using it, and > > > likewise some > > > for which qhashfunctions.h would suffice. One of them now got a -1 for > > > being SiC. > > > > > > Can we please decide once and for all whether #include cleanups that > > > are technically SiC are ok or not, if they only affect users that rely > > > on indirect includes? > > > > > > My vote obviously goes to allowing them. > > > > My vote goes against such gratuitous SiC changes. > > > > Each little SiC changes add up in frustration for the developer who > > upgrades its Qt version. > > So when it is easy to avoid, we should avoid it. > > I'm with Olivier on this one. Source compatibility is a key contribution to > the success of Qt. > > For developers building their own software it may not be such a big deal, > if they are experienced Qt developers. For somebody who just clones a > random project off github and then tries to build it, such a "simple" > source incompatible change becomes a deal breaker. I argue that there's a > high probability that person is not familiar with these types of changes > nor knowledgeable how to fix them. > > I've encountered this numerous times myself for example trying to keep the > nvidia modules on my Laptop compiling with a changing kernel API. Often the > fixes are _absolutely_ trivial one liners about missing includes. But I > more often can't be bothered to dive into the source code to figure out > what to add where. And then we have exactly the element of frustration > that harms the product. So, by this line of reasoning, the list of #includes in a public header file must be a monotonically increasing function of the Qt version. Since we're keeping SC even across major versions these days, we'll thus slowly converge on including all of a Qt module's headers in each of its headers. So, why don't we shortcut the process and include in each QtFoo-module's header _today_? :) I'm exaggerating, of course. A bit, at least. I wonder: wouldn't it also harm the project if people who use Qt for a living, pay your salary by buying licenses and have to spend X amount of money on additional hardware just to make the nightly builds actually build in just one night started to look for alternatives? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From simon.hausmann at theqtcompany.com Thu Apr 9 12:46:11 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Thu, 9 Apr 2015 12:46:11 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <201504091234.17718.marc.mutz@kdab.com> References: <201504081313.19868.marc.mutz@kdab.com> <12661469.efp2qu8vhJ@rhea> <201504091234.17718.marc.mutz@kdab.com> Message-ID: <2217077.QBTThHQsVf@rhea> On Thursday 9. April 2015 12.34.17 Marc Mutz wrote: > On Thursday 09 April 2015 10:39:57 Simon Hausmann wrote: > > On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote: > > > On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote: > > > > Hi, > > > > > > > > I have in the past fixed #include mistakes such as #include > > > > for QSharedDataPointer, and even though each time > > > > the issue came up that this is a SiC change (but only for users that > > > > unduly rely on indirect includes), so far they were always accepted. > > > > > > > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have > > > > come across many files that included qhash.h without using it, and > > > > likewise some > > > > for which qhashfunctions.h would suffice. One of them now got a -1 for > > > > being SiC. > > > > > > > > Can we please decide once and for all whether #include cleanups that > > > > are technically SiC are ok or not, if they only affect users that rely > > > > on indirect includes? > > > > > > > > My vote obviously goes to allowing them. > > > > > > My vote goes against such gratuitous SiC changes. > > > > > > Each little SiC changes add up in frustration for the developer who > > > upgrades its Qt version. > > > So when it is easy to avoid, we should avoid it. > > > > I'm with Olivier on this one. Source compatibility is a key contribution > > to > > the success of Qt. > > > > For developers building their own software it may not be such a big deal, > > if they are experienced Qt developers. For somebody who just clones a > > random project off github and then tries to build it, such a "simple" > > source incompatible change becomes a deal breaker. I argue that there's a > > high probability that person is not familiar with these types of changes > > nor knowledgeable how to fix them. > > > > I've encountered this numerous times myself for example trying to keep the > > nvidia modules on my Laptop compiling with a changing kernel API. Often > > the > > fixes are _absolutely_ trivial one liners about missing includes. But I > > more often can't be bothered to dive into the source code to figure out > > what to add where. And then we have exactly the element of frustration > > that harms the product. > > So, by this line of reasoning, the list of #includes in a public header file > must be a monotonically increasing function of the Qt version. Since we're > keeping SC even across major versions these days, we'll thus slowly > converge on including all of a Qt module's headers in each of its headers. > So, why don't we shortcut the process and include in each > QtFoo-module's header _today_? :) > > I'm exaggerating, of course. A bit, at least. Right, you are exaggerating. And that's why I don't agree with your enhanced line of reasoning. > I wonder: wouldn't it also harm the project if people who use Qt for a > living, pay your salary by buying licenses and have to spend X amount of > money on additional hardware just to make the nightly builds actually build > in just one night started to look for alternatives? Surely it would. However at the same time I strongly doubt that the proposed changes have a significant impact on the overall build times, especially compared to the much more expensive human developer time that is spent when encountering source incompatible changes and a reduction of daytime productivity is the result. Simon From bobbyphilip at gmail.com Thu Apr 9 12:47:34 2015 From: bobbyphilip at gmail.com (Bobby Philip) Date: Thu, 9 Apr 2015 16:17:34 +0530 Subject: [Development] QT 5.3 DirectFB port Message-ID: Hi, I have been looking at how the DirectFB QPA platform inside QT works. I have seen how inside QDirectFbIntegration::connectToDirectFb() the DirectFB interface is initialised followed by the screen and input module. On my platform atleast, when I create a widget, I see a QDirectbWindow being created, and when it is set visble, a Flip is called for this surface. What I havent understood, is how the output of a newly created surface is blitted to the surface belonging to the layer belonging to the screen which was inited earlier. I believe only when graphics is blitted to this surface will it actually be seen. Could someone point me to how this is done. I am working on a mips based platform and newly porting QT5.3 to it. Regards B -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Thu Apr 9 13:04:21 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Thu, 09 Apr 2015 13:04:21 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <12661469.efp2qu8vhJ@rhea> References: <201504081313.19868.marc.mutz@kdab.com> <2894889.l2PuTvdTzZ@finn> <12661469.efp2qu8vhJ@rhea> Message-ID: <55265CB5.10309@familiesomers.nl> Simon Hausmann schreef op 9-4-2015 om 10:39: > On Wednesday 8. April 2015 14.34.03 Olivier Goffart wrote: >> On Wednesday 08 April 2015 13:13:19 Marc Mutz wrote: >>> Hi, >>> >>> I have in the past fixed #include mistakes such as #include >>> for QSharedDataPointer, and even though each time the >>> issue came up that this is a SiC change (but only for users that unduly >>> rely on indirect includes), so far they were always accepted. >>> >>> When splitting off qHash() from qhash.h into qhashfunctions.h, I have come >>> across many files that included qhash.h without using it, and likewise >>> some >>> for which qhashfunctions.h would suffice. One of them now got a -1 for >>> being SiC. >>> >>> Can we please decide once and for all whether #include cleanups that are >>> technically SiC are ok or not, if they only affect users that rely on >>> indirect includes? >>> >>> My vote obviously goes to allowing them. >> My vote goes against such gratuitous SiC changes. >> >> Each little SiC changes add up in frustration for the developer who upgrades >> its Qt version. >> So when it is easy to avoid, we should avoid it. > I'm with Olivier on this one. Source compatibility is a key contribution to > the success of Qt. > > For developers building their own software it may not be such a big deal, if > they are experienced Qt developers. For somebody who just clones a random > project off github and then tries to build it, such a "simple" source > incompatible change becomes a deal breaker. I argue that there's a high > probability that person is not familiar with these types of changes nor > knowledgeable how to fix them. > I actually consider relying on implicitly included headers a bug, or at a same level as relying on private headers. The fact that Qt somehow implicitly includes header b defining class B when you inluded header a in order to use class A is an implementation detail IMHO. Nowhere does Qt promise stability of such implementation details, I think. Most often this is avoided in Qt via the use of PIMPL of course, but not always. I think it *is* reasonable to remove such indirect includes if they are not needed for Qt itself. However, it is worth looking into how the thing was documented to begin with. In the case of qHash(), the documentation for that one actualy says the include is . I think it is *not* reasonable to break that. André From simon.hausmann at theqtcompany.com Thu Apr 9 13:17:45 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Thu, 9 Apr 2015 13:17:45 +0200 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: <3682276.Ia6Rxzu1m6@rhea> References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <3682276.Ia6Rxzu1m6@rhea> Message-ID: <1785124.lMC8oGzQjT@rhea> On Thursday 9. April 2015 11.52.31 Simon Hausmann wrote: > On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote: > [...] > > > Going off on a slight tangent: > > https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is > > converted to a QVariantMap. Each property is converted to a QVariant, > > recursively". However, calling toVariant() on an Error object > > (isError() == isObject() == true) produces an empty QVariantMap event > > though QJSValueIterator gets the properties just fine (using Qt > > 5.4.1). Is this expected? > > That could be a bug. You should see the enumerable properties, which I think > include message and name. If a strack trace was producible at constructor > time, then you should also see the fileName and lineNumber properties. > "stack" however will not be visible. Ah, I had another look and I have to correct myself here: The properties in question ("message", "name", etc.) are defined as being non- enumerable [1], which is why the are not visible in the toVariant() conversion. Similarly those properties are not visible if you do for (propName in error) { console.log(propName) } QJSValueIterator - as a C++ tool - lists _all_ properties of an object, even the non-enumerable ones. Simon [1] Although those properties are technically vendor extensions and non- standard, they are commonly implemented across web browser oriented JavaScript engines and _there_ they are non-enumerable. From aleixpol at kde.org Thu Apr 9 13:19:24 2015 From: aleixpol at kde.org (Aleix Pol) Date: Thu, 9 Apr 2015 13:19:24 +0200 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> <20150408143023.GA9172@troll08.it.local> <2787909.Rxoz4u53b7@frederik-thinkcentre-m93p> <20150408153507.GB9172@troll08.it.local> Message-ID: On Thu, Apr 9, 2015 at 10:27 AM, Tomasz Siekierda wrote: > On 8 April 2015 at 17:35, Oswald Buddenhagen > wrote: >> On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote: >>> On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote: >>> so ideally we find the perfect new name for both module and >>> repository. Sadly we didn't manage to come up with a great name in a >>> few hours of brain storming. >>> >> i think quick controls 2 will work just fine. it's not like people are >> not used to "asynchronous" versioning in the qt quick world. >> >> but anyway, here are some more ideas: >> - the classic: qt quick controls NG >> - the diet: qt quick controls light >> - the thesaurus: qt quick widgets >> - the cynic: qt quicker controls > > I like QtQuick.LightControls. > > In general, since both sets are drastically different (in way they > look like, in the way they perform, in styling capabilities, etc.) I > do not think giving them similar names (Controls 1 and Controls 2) is > a good idea - it may strongly confuse the users. Not everybody follows > the mailing list and blog, so if you name them similarly you can > expect a flood of questions like "I'm trying to use the new Controls, > but X does not work, and Y looks different, while Z can't read my > style definition" etc. I'd say it's a matter of whether the current QtQuick Controls will become deprecated (or considered Done). If that's the case, then the new component is the clear N+1 version. Also another question is whether they can be mixed. If they can be mixed then you'll want different names. Aleix From marc.mutz at kdab.com Thu Apr 9 14:20:40 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Apr 2015 14:20:40 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <55265CB5.10309@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <12661469.efp2qu8vhJ@rhea> <55265CB5.10309@familiesomers.nl> Message-ID: <201504091420.40302.marc.mutz@kdab.com> On Thursday 09 April 2015 13:04:21 André Somers wrote: > I think it is reasonable to remove such indirect includes if they are > not needed for Qt itself. However, it is worth looking into how the > thing was documented to begin with. In the case of qHash(), the > documentation for that one actualy says the include is . I think > it is not reasonable to break that. I agree, and therefore the change(s) in question does't/don't. -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Thu Apr 9 14:40:11 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 9 Apr 2015 14:40:11 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <2217077.QBTThHQsVf@rhea> References: <201504081313.19868.marc.mutz@kdab.com> <201504091234.17718.marc.mutz@kdab.com> <2217077.QBTThHQsVf@rhea> Message-ID: <201504091440.11963.marc.mutz@kdab.com> On Thursday 09 April 2015 12:46:11 Simon Hausmann wrote: > > So, by this line of reasoning, the list of #includes in a public header > > file must be a monotonically increasing function of the Qt version. > > Since we're keeping SC even across major versions these days, we'll thus > > slowly converge on including all of a Qt module's headers in each of its > > headers. So, why don't we shortcut the process and include in > > each QtFoo-module's header _today_? :) > > > > > > > > I'm exaggerating, of course. A bit, at least. > > Right, you are exaggerating. And that's why I don't agree with your > enhanced line of reasoning. I was exaggerating when proposing to include in each header. I was _not_ exaggerating when I said that by your (plural) line of reasoning, we'll slowly accumulate cruft in every header that will hurt maintainability and compile times. Just look at what qglobal.h includes to stay SC. It's ridiculous. Even worse, it's not enough. For https://codereview.qt- project.org/106680 I'm still fighting with myself because I'd need to add to and rearrange some code in qglobal.h to be able to use QEnableIf as early as qRound(). > > I wonder: wouldn't it also harm the project if people who use Qt for a > > living, pay your salary by buying licenses and have to spend X amount of > > money on additional hardware just to make the nightly builds actually > > build in just one night started to look for alternatives? > > Surely it would. However at the same time I strongly doubt that the > proposed changes have a significant impact on the overall build times, > especially compared to the much more expensive human developer time that > is spent when encountering source incompatible changes and a reduction of > daytime productivity is the result. The problem is not this one change. The problem is the cumulative regression in compile time that ensues when we're not even allowing include changes that only break clients that rely on indirect includes. It's easy to prevent these breakages user-side by applying a tool like Ossi posted in one of the changes: https://code.google.com/p/include-what-you-use/ As Andre said, which header includes which other headers isn't even documented, so it's an implementation detail. Implementation details are subject to change. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From frederik.gladhorn at theqtcompany.com Thu Apr 9 15:01:20 2015 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Thu, 9 Apr 2015 15:01:20 +0200 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> Message-ID: <11646316.f8fJaGkvBr@frederik-thinkcentre-m93p> On Thursday, April 09, 2015 01:19:24 PM Aleix Pol wrote: > On Thu, Apr 9, 2015 at 10:27 AM, Tomasz Siekierda wrote: > > On 8 April 2015 at 17:35, Oswald Buddenhagen > > > > wrote: > >> On Wed, Apr 08, 2015 at 04:39:52PM +0200, Frederik Gladhorn wrote: > >>> On Wednesday, April 08, 2015 04:30:23 PM Oswald Buddenhagen wrote: > >>> so ideally we find the perfect new name for both module and > >>> repository. Sadly we didn't manage to come up with a great name in a > >>> few hours of brain storming. > >> > >> i think quick controls 2 will work just fine. it's not like people are > >> not used to "asynchronous" versioning in the qt quick world. > >> > >> but anyway, here are some more ideas: > >> - the classic: qt quick controls NG > >> - the diet: qt quick controls light > >> - the thesaurus: qt quick widgets > >> - the cynic: qt quicker controls > > > > I like QtQuick.LightControls. > > > > In general, since both sets are drastically different (in way they > > look like, in the way they perform, in styling capabilities, etc.) I > > do not think giving them similar names (Controls 1 and Controls 2) is > > a good idea - it may strongly confuse the users. Not everybody follows > > the mailing list and blog, so if you name them similarly you can > > expect a flood of questions like "I'm trying to use the new Controls, > > but X does not work, and Y looks different, while Z can't read my > > style definition" etc. > > I'd say it's a matter of whether the current QtQuick Controls will > become deprecated (or considered Done). If that's the case, then the > new component is the clear N+1 version. The new controls will not support the "native" look at least for the near future, so we will not deprecate the Qt Quick Controls yet. > Also another question is whether they can be mixed. If they can be > mixed then you'll want different names. They can be mixed, that's already working, by using import as with just the version as differentiator. That might be less obvious though. Cheers, Frederik > > Aleix > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From frederik.gladhorn at theqtcompany.com Thu Apr 9 15:04:59 2015 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Thu, 9 Apr 2015 15:04:59 +0200 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> Message-ID: <1534001.C0Zgerm6cZ@frederik-thinkcentre-m93p> We want to give you the code, here it is :) https://codereview.qt-project.org/#/admin/projects/qt-labs/qtquickcontrols2 It is in the qt-labs namespace which means "no guarantees, no commitment, we'll rename and break everything". Besides this little warning, I think there is a great repository to play with :) Build it against the dev branch of Qt (that'll be 5.6 as minimum requirement for now). Feedback welcome! Cheers, Frederik On Wednesday, April 08, 2015 03:18:27 PM Frederik Gladhorn wrote: > Hi all, > > as announced by JP's blog post, we've been working on a new set of Qt Quick > Controls that have slightly different goals than the existing ones: > http://blog.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded/ > > The main target is performance, especially on low end hardware. > The code will live in the qtquickcontrols module, next to the existing > controls. For now there is only one style supported, with some theming > capabilities. This is an important point to get top notch performance. > > Now is the time to give everyone the chance to play with the new controls > which are at a "tech preview" level. Since the architecture is different, we > want to keep a clean separation in the qtquickcontrols git module and will > move the code around to accommodate both modules within the repository. The > plan is to create two top level directories in the repository: a controls1 > directory containing everything currently in the repository > (src/tests/examples), and a controls2 directory to contain the new controls. > > Note that both sets of controls will be co-installable and work together. > That is to say, the following will work just fine: > > import QtQuick.Controls 1.x as Controls1 > import QtQuick.Controls 2.x > > After a long discussion, we think that going with a major version is > easiest, as we didn't find a great name that makes it clear what the new > control set provides; "Embedded Controls" or "Touch Controls" don't quite > seem right. > > Greetings, > Frederik > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Apr 9 17:36:47 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Apr 2015 08:36:47 -0700 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: References: <201504081313.19868.marc.mutz@kdab.com> Message-ID: <1479808.5qdMParPgn@tjmaciei-mobl4> On Thursday 09 April 2015 11:20:30 Frank Osterfeld wrote: > > My vote obviously goes to allowing them. > > I had to fix includes when building client code with 5.5 branch (coming from > 5.4.1), so this is an actual issue right now, not just a theoretical one. I > can do more research which headers I needed to include, if that’s a help to > anyone. It's probably the QStringList change. In Qt 5.4, QStringList included QDataStream, which included QIODevice, which in turn included QObject. In Qt 5.5, the offending operator>> and << were removed from qstringlist.h, so the #include was dropped. Anyone relying on #include providing QIODevice and QObject will see source code compilation failures. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Apr 9 17:39:38 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Apr 2015 08:39:38 -0700 Subject: [Development] Build qt fail In-Reply-To: <000001d07291$165be550$4313aff0$@126.com> References: <000001d07291$165be550$4313aff0$@126.com> Message-ID: <1541895.2QjQJm3ak9@tjmaciei-mobl4> On Thursday 09 April 2015 14:47:06 kl222 wrote: > -I../../include/QtCore -I../../include/QtCore/5.5.0 > -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre > -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 > -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o > .obj/release/qsimd.o tools/qsimd.cpp > > tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory > > #include Does qtbase/include/QtCore exist? Does a file called QByteArray exist in there? Do any other mixed case file names exist there? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From berkayelbir at gmail.com Thu Apr 9 18:50:52 2015 From: berkayelbir at gmail.com (Berkay Elbir) Date: Thu, 9 Apr 2015 19:50:52 +0300 Subject: [Development] Qt Installer Framework Script Message-ID: Hello, I have a question about QInstaller. How can I make the Uninstaller check exe is running or not before uninstalling? I can do this with installing process but I can not write correct script (installscript.qs) for uninstalling process. Should I write another script for Uninstaller? Actually, I managed to come here with the examples. This is my script : function cancelInstaller() { installer.setDefaultPageVisible(QInstaller.Introduction, false); installer.setDefaultPageVisible(QInstaller.TargetDirectory, false); installer.setDefaultPageVisible(QInstaller.ComponentSelection, false); installer.setDefaultPageVisible(QInstaller.ReadyForInstallation, false); installer.setDefaultPageVisible(QInstaller.StartMenuSelection, false); installer.setDefaultPageVisible(QInstaller.PerformInstallation, false); installer.setDefaultPageVisible(QInstaller.LicenseCheck, false); installer.setValue("FinishedText", "Operation was canceled!"); } function Component() { var programFiles = installer.environmentVariable("ProgramFiles"); if (programFiles != "") installer.setValue("TargetDir", programFiles + "/A"); var programValid = true;if(installer.isProcessRunning("A.exe") == true) { QMessageBox["warning"]("os.warning", "Installer","Program is currently running!",QMessageBox.Ok); programValid = false; } if (!programValid) { cancelInstaller(); return; } } Component.prototype.isDefault = function() { // select the component by default return true; } Component.prototype.createOperations = function() { try { // call the base create operations function component.createOperations(); if (installer.value("os") === "win") { component.addElevatedOperation("Execute", "{0,3010}", "@TargetDir@\vcredist\vcredist_x86.exe", "/norestart", "/q"); component.addOperation("CreateShortcut", "@TargetDir@/A.exe", "@StartMenuDir@/A.lnk"); component.addOperation("CreateShortcut", "@TargetDir@/uninstall.exe", "@StartMenuDir@/Uninstall.lnk"); component.addOperation("CreateShortcut", "@TargetDir@/A.exe", "@DesktopDir@ /A.lnk"); } } catch (e) { print(e); } } Thanks. Best Regards, Berkay Elbir -------------- next part -------------- An HTML attachment was scrubbed... URL: From mw_triad at users.sourceforge.net Thu Apr 9 19:20:41 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 09 Apr 2015 13:20:41 -0400 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <55265CB5.10309@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <2894889.l2PuTvdTzZ@finn> <12661469.efp2qu8vhJ@rhea> <55265CB5.10309@familiesomers.nl> Message-ID: On 2015-04-09 07:04, André Somers wrote: > I think it *is* reasonable to remove such indirect includes if they are > not needed for Qt itself. However, it is worth looking into how the > thing was documented to begin with. In the case of qHash(), the > documentation for that one actualy says the include is . I think > it is *not* reasonable to break that. Is that relevant? My understanding is that what is being changed is not that #include declares qHash (which seems to me like it should - and probably, must, since QHash itself needs qHash - continue to happen), but that unrelated headers that incidentally used to include qhash.h would newly include only qhashfunctions.h instead. I don't object to that. I also support the notion of a separate header *just* for qHash. Bonus points if we get :-). Slightly off-topic: included ? Ick, that's one change I'm glad to see. -- Matthew From thiago.macieira at intel.com Thu Apr 9 20:45:20 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Apr 2015 11:45:20 -0700 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: References: <201504081313.19868.marc.mutz@kdab.com> <55265CB5.10309@familiesomers.nl> Message-ID: <14883765.y9HtRjQQyC@tjmaciei-mobl4> On Thursday 09 April 2015 13:20:41 Matthew Woehlke wrote: > Slightly off-topic: included ? Ick, that's one > change I'm glad to see. Yes, because it had inline operator>>(QDataStream&, const QStringList &) and qdatastream.h requires qiodevice.h. However, that operator was useless, since qdatastream.h has template operator>>(QDataStream&, const QList &). Since it was useless and inline, I dropped it. It wasn't a gratuitous change, though. It was required so I could move some QStringList methods to QList. Since qlist.h needs to include qstringlist.h to ensure the full specialisation of QListSpecialMethods is present before QList is ever instantiated, I had to make sure qstringlist.h didn't include qdatastream.h -- because qdatastream.h includes qlist.h and boom! cyclic includes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Apr 9 20:51:11 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 09 Apr 2015 11:51:11 -0700 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <14883765.y9HtRjQQyC@tjmaciei-mobl4> References: <201504081313.19868.marc.mutz@kdab.com> <14883765.y9HtRjQQyC@tjmaciei-mobl4> Message-ID: <2160476.QqaBeYKDTW@tjmaciei-mobl4> On Thursday 09 April 2015 11:45:20 Thiago Macieira wrote: > It wasn't a gratuitous change, though. It was required so I could move some > QStringList methods to QList. Since qlist.h needs to include > qstringlist.h to ensure the full specialisation of > QListSpecialMethods is present before QList is ever > instantiated, I had to make sure qstringlist.h didn't include qdatastream.h > -- because qdatastream.h includes qlist.h and boom! cyclic includes. The objective is to make Qt6 QStringList be a typedef to QList, not a separate class. We've already managed that for QByteArrayList -- it's just a typedef. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Thu Apr 9 21:28:13 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Apr 2015 21:28:13 +0200 Subject: [Development] saving the qt-x64 archives Message-ID: Hi, it looks like the Qt-x64 project, which used to build Qt binaries for 32-bit and 64-bit Windows, including compiler/platform combinations not supported by the official releases (in particular, there were MinGW64 builds for both Qt 4 and Qt 5), was not only discontinued, but wiped their entire file archive! http://sourceforge.net/projects/qtx64/files/ shows only "This project has no files." As of this writing, the mirror: http://download2.polytechnic.edu.na/pub4/sourceforge/q/qt/qtx64/ still appears to carry all the files. Can somebody with the required bandwidth and storage space mirror the archive before it is gone for good? Kevin Kofler From kevin.kofler at chello.at Thu Apr 9 21:46:36 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 09 Apr 2015 21:46:36 +0200 Subject: [Development] saving the qt-x64 archives References: Message-ID: Kevin Kofler wrote: > it looks like the Qt-x64 project, which used to build Qt binaries for > 32-bit and 64-bit Windows, including compiler/platform combinations not > supported by the official releases (in particular, there were MinGW64 > builds for both Qt 4 and Qt 5), was not only discontinued, but wiped their > entire file archive! http://sourceforge.net/projects/qtx64/files/ shows > only "This project has no files." PS: Hmmm, what the SourceForge page doesn't tell you is that the project is not really dead, but moved to http://tver-soft.org/qt64 where there are more recent downloads. (Just the archives are gone, if you were looking for a specific old version.) Kevin Kofler From kl222 at 126.com Fri Apr 10 07:20:29 2015 From: kl222 at 126.com (kl222) Date: Fri, 10 Apr 2015 13:20:29 +0800 Subject: [Development] =?utf-8?b?562U5aSNOiAgQnVpbGQgcXQgZmFpbA==?= In-Reply-To: References: <000001d07291$165be550$4313aff0$@126.com> Message-ID: <154601d0734e$14648640$3d2d92c0$@126.com> I guess is that the header files generated script error. The QByteArray isn't generated, but the qbytearray.h is generated. The following is my operation: 1.Qt branch: 5.5 2.Configuration order: ./configure -opensource -confirm-license -nomake examples -nomake tests -no-compile-examples -no-sql-sqlite -no-sql-odbc -skip qtdoc -skip qtwebkit-examples -skip qt3d -skip qtcanvas3d -prefix /d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/qt -shared -release -I /d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/include -L /d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/lib -platform win32-g++ -skip qtandroidextras -skip qtx11extras -skip qtmacextras 3.Configuration information: Running configuration tests... Configure summary Build type: win32-g++ (i386, CPU features: none detected) Build options: Configuration .......... accessibility audio-backend avx avx2 c++11 clock-gettime clock-monotonic concurrent dbus full-config getaddrinfo harfbuzz large-config medium-config minimal-config no-freetype opengl openssl pcre png precompile_header qpa qpa reduce_exports reduce_relocations release shared small-config sse2 sse3 sse4_1 sse4_2 ssse3 system-zlib Build parts ............ libs tools Mode ................... release Using sanitizer(s)...... none Using C++11 ............ yes Using gold linker....... no Using PCH .............. yes Target compiler supports: SSE2/SSE3/SSSE3 ...... yes/yes/yes SSE4.1/SSE4.2 ........ yes/yes AVX/AVX2 ............. yes/yes Qt modules and options: Qt D-Bus ............... yes (loading dbus-1 at runtime) Qt Concurrent .......... yes Qt GUI ................. yes Qt Widgets ............. yes Large File ............. yes QML debugging .......... yes Use system proxies ..... no Support enabled for: Accessibility .......... yes ALSA ................... no CUPS ................... no DirectWrite ............ no Evdev .................. no FontConfig ............. no FreeType ............... no Glib ................... no GStreamer .............. no GTK theme .............. no HarfBuzz ............... yes (bundled copy) Iconv .................. no ICU .................... no Image formats: GIF .................. yes (plugin, using bundled copy) JPEG ................. yes (plugin, using bundled copy) PNG .................. yes (in QtGui, using bundled copy) journald ............... no libinput................ no mtdev .................. no Networking: getaddrinfo .......... yes getifaddrs ........... no IPv6 ifname .......... no libproxy.............. no OpenSSL .............. yes (loading libraries at run-time) NIS .................... no OpenGL / OpenVG: EGL .................. no OpenGL ............... desktop OpenVG ............... no PCRE ................... yes (bundled copy) pkg-config ............. yes PulseAudio ............. no QPA backends: DirectFB ............. no EGLFS ................ no EGLFS i.MX6....... . no EGLFS KMS .......... no EGLFS Mali ......... no EGLFS Raspberry Pi . no EGLFS X11 .......... no LinuxFB .............. no XCB .................. no Session management ..... yes SQL drivers: DB2 .................. no InterBase ............ no MySQL ................ no OCI .................. no ODBC ................. no PostgreSQL ........... no SQLite 2 ............. no SQLite ............... no TDS .................. no tslib .................. no udev ................... no xkbcommon-x11........... no xkbcommon-evdev......... no zlib ................... yes (system library) Info: creating super cache file D:\source\qt5\.qmake.super NOTE: This platform does not support runtime library paths, using -no-rpath. Qt is now configured for building. Just run 'make'. Once everything is built, you must run 'make install'. Qt will be installed into /d/source/rabbitim/ThirdLibary/windows_mingw/qt Prior to reconfiguration, make sure you remove any leftovers from the previous build. 4.Complie order: mingw32-make 5.complie error information: g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions -mthreads -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. -I/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/include -I../../include -I../../include/QtCore -I../../include/QtCore/5.5.0 -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o .obj/release/qsharedpointer.o tools/qsharedpointer.cpp g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions -mthreads -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. -I/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/include -I../../include -I../../include/QtCore -I../../include/QtCore/5.5.0 -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o .obj/release/qsimd.o tools/qsimd.cpp tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory #include ^ compilation terminated. Makefile.Release:16638: recipe for target '.obj/release/qsimd.o' failed mingw32-make[4]: *** [.obj/release/qsimd.o] Error 1 mingw32-make[4]: Leaving directory 'D:/source/qt5/qtbase/src/corelib' Makefile:34: recipe for target 'release' failed mingw32-make[3]: *** [release] Error 2 mingw32-make[3]: Leaving directory 'D:/source/qt5/qtbase/src/corelib' Makefile:165: recipe for target 'sub-corelib-make_first' failed mingw32-make[2]: *** [sub-corelib-make_first] Error 2 mingw32-make[2]: Leaving directory 'D:/source/qt5/qtbase/src' Makefile:41: recipe for target 'sub-src-make_first' failed mingw32-make[1]: *** [sub-src-make_first] Error 2 mingw32-make[1]: Leaving directory 'D:/source/qt5/qtbase' Makefile:62: recipe for target 'module-qtbase-make_first' failed mingw32-make: *** [module-qtbase-make_first] Error 2 6. Generate header file: Administrator at l-PC MINGW32 /d/source/qt5/qtbase/include/QtCore $ ls 5.5.0/ QMessageLogger headers.pri QMetaClassInfo QAbstractAnimation QMetaEnum qabstractanimation.h QMetaObject qabstracteventdispatcher.h qmetaobject.h QAbstractItemModel QMetaProperty qabstractitemmodel.h QMetaType QAbstractListModel qmetatype.h QAbstractNativeEventFilter QMetaTypeId qabstractnativeeventfilter.h QMetaTypeId2 QAbstractProxyModel QMetaTypeIdQObject qabstractproxymodel.h QMimeData QAbstractState qmimedata.h qabstractstate.h QMimeDatabase QAbstractTableModel qmimedatabase.h QAbstractTransition QMimeType qabstracttransition.h qmimetype.h qalgorithms.h QModelIndex QAnimationDriver QModelIndexList QAnimationGroup QMultiHash qanimationgroup.h QMultiMap QArgument QMutableByteArrayListIterator qarraydata.h QMutableStringListIterator qarraydataops.h QMutex qarraydatapointer.h qmutex.h QAssociativeIterable QMutexLocker qatomic.h qnamespace.h qatomic_armv5.h QNoDebug qatomic_armv6.h qnumeric.h qatomic_armv7.h QObject qatomic_bootstrap.h qobject.h qatomic_cxx11.h qobject_impl.h qatomic_gcc.h qobjectcleanuphandler.h qatomic_ia64.h QObjectData qatomic_mips.h qobjectdefs.h qatomic_msvc.h qobjectdefs_impl.h qatomic_unix.h QObjectList qatomic_x86.h qpair.h QAtomicAdditiveType QParallelAnimationGroup QAtomicInt qparallelanimationgroup.h QAtomicOpsSupport QPauseAnimation QAtomicWindowsType qpauseanimation.h qbasicatomic.h QPersistentModelIndex QBasicAtomicInt qplugin.h QBasicAtomicPointer QPluginLoader QBasicMutex qpluginloader.h QBasicTimer qpoint.h qbasictimer.h QPointer QBitArray qpointer.h qbitarray.h qprocess.h QBitRef QProcessEnvironment QBuffer qprocessordetection.h qbuffer.h QPropertyAnimation qbytearray.h qpropertyanimation.h QByteArrayData qqueue.h QByteArrayDataPtr QReadLocker QByteArrayList QReadWriteLock qbytearraylist.h qreadwritelock.h QByteArrayMatcher qrect.h qbytearraymatcher.h qrefcount.h QByteRef QRegExp qcache.h qregexp.h QChar QRegularExpression qchar.h qregularexpression.h QCharRef QRegularExpressionMatch QChildEvent QRegularExpressionMatchIterator QCollator QResource qcollator.h qresource.h QCollatorSortKey qresultstore.h QCommandLineOption QReturnArgument qcommandlineoption.h qrunnable.h QCommandLineParser QSaveFile qcommandlineparser.h qsavefile.h qcompilerdetection.h QScopedArrayPointer QConcatenable qscopedpointer.h qconfig.h QScopedPointerArrayDeleter qconfig-dist.h QScopedPointerDeleteLater qconfig-large.h QScopedPointerPodDeleter qconfig-medium.h qscopedvaluerollback.h qconfig-minimal.h QSemaphore qconfig-nacl.h qsemaphore.h qconfig-small.h QSequentialAnimationGroup qcontainerfwd.h qsequentialanimationgroup.h QContiguousCache qset.h qcontiguouscache.h qsettings.h QContiguousCacheTypedData QSharedData qcoreapplication.h qshareddata.h qcoreevent.h QSharedDataPointer QCryptographicHash QSharedMemory qcryptographichash.h qsharedmemory.h QDataStream qsharedpointer.h qdatastream.h qsharedpointer_impl.h QDate QSignalMapper QDateTime qsignalmapper.h qdatetime.h QSignalTransition qdebug.h qsignaltransition.h QDebugStateSaver qsize.h QDeferredDeleteEvent QSocketNotifier QDir qsocketnotifier.h qdir.h QSortFilterProxyModel QDirIterator qsortfilterproxymodel.h qdiriterator.h qstack.h QDynamicPropertyChangeEvent qstandardpaths.h QEasingCurve QState qeasingcurve.h qstate.h qelapsedtimer.h QStateMachine QEnableSharedFromThis qstatemachine.h qendian.h QStaticArrayData QEventLoop QStaticByteArrayData qeventloop.h QStaticPlugin QEventLoopLocker QStaticStringData QEventTransition QStorageInfo qeventtransition.h qstorageinfo.h qexception.h QString QExplicitlySharedDataPointer qstring.h qfactoryinterface.h QStringBuilder qfeatures.h qstringbuilder.h QFile QStringBuilderBase qfile.h QStringBuilderCommon QFileDevice QStringData qfiledevice.h QStringDataPtr QFileInfo qstringlist.h qfileinfo.h QStringListIterator QFileSelector qstringlistmodel.h qfileselector.h QStringMatcher QFileSystemWatcher qstringmatcher.h qfilesystemwatcher.h QSysInfo QFinalState qsysinfo.h qfinalstate.h qsystemdetection.h qflags.h QSystemSemaphore qfunctions_nacl.h qsystemsemaphore.h qfunctions_vxworks.h Qt qfunctions_wince.h qt_windows.h qfunctions_winrt.h QtAlgorithms QFuture QtCleanUpFunction qfuture.h QtConfig QFutureInterface QtContainerFwd qfutureinterface.h QtCore QFutureInterfaceBase QtCoreDepends qfuturesynchronizer.h QtCoreVersion QFutureWatcher qtcoreversion.h qfuturewatcher.h QtDebug QFutureWatcherBase QTemporaryDir QGenericArgument qtemporarydir.h qgenericatomic.h QTemporaryFile QGenericReturnArgument qtemporaryfile.h qglobal.h QtEndian qglobalstatic.h QTextBoundaryFinder qhash.h qtextboundaryfinder.h QHashData QTextCodec QHashDummyValue qtextcodec.h QHashNode QTextDecoder QHistoryState qtextstream.h qhistorystate.h QTextStreamFunction QIdentityProxyModel QtGlobal qidentityproxymodel.h qthread.h QIncompatibleFlag QThreadPool QInternal qthreadpool.h qiodevice.h qthreadstorage.h qisenum.h QTime QItemSelection QTimeLine QItemSelectionModel qtimeline.h qitemselectionmodel.h qtimer.h qiterator.h QTimerEvent QJsonArray QTimeZone qjsonarray.h qtimezone.h QJsonDocument QtNumeric qjsondocument.h QtPlugin QJsonObject QtPluginMetaDataFunction qjsonobject.h QTranslator QJsonParseError qtranslator.h QJsonValue QTypeInfo qjsonvalue.h qtypeinfo.h QJsonValueRef QTypeInfoMerger QJsonValueRefPtr qtypetraits.h QLatin1Char QUnhandledException QLatin1String QUrl QLibrary qurl.h qlibrary.h QUrlQuery QLibraryInfo qurlquery.h qlibraryinfo.h QUrlTwoFlags QLine quuid.h qline.h QVariant QLineF qvariant.h QLinkedList QVariantAnimation qlinkedlist.h qvariantanimation.h QLinkedListNode QVariantComparisonHelper QList QVariantHash qlist.h QVariantList QListData QVariantMap QListSpecialMethods qvarlengtharray.h QLocale QVector qlocale.h qvector.h qlocale_blackberry.h QWaitCondition QLockFile qwaitcondition.h qlockfile.h QWeakPointer qlogging.h QWinEventNotifier qloggingcategory.h qwineventnotifier.h QMap QWriteLocker qmap.h qxmlstream.h QMapData QXmlStreamAttribute QMapDataBase QXmlStreamAttributes QMapNode QXmlStreamEntityDeclaration QMapNodeBase QXmlStreamEntityDeclarations QMargins QXmlStreamEntityResolver qmargins.h QXmlStreamNamespaceDeclaration QMarginsF QXmlStreamNamespaceDeclarations qmath.h QXmlStreamNotationDeclaration QMessageAuthenticationCode QXmlStreamNotationDeclarations qmessageauthenticationcode.h QXmlStreamWriter QMessageLogContext -----邮件原件----- 发件人: Ray Donnelly [mailto:mingw.android at gmail.com] 发送时间: 2015年4月9日 16:29 收件人: kl222 抄送: android-development at qt-project.org 主题: Re: [Development] Build qt fail On Thu, Apr 9, 2015 at 7:47 AM, kl222 wrote: > Environment: > > Operation System: windows7 Ultimate > > Msys2: MINGW32_NT-6.1 l-PC 2.1.0(0.287/5/3) 2015-04-05 21:26 i686 Msys > > Bash: GNU bash，version 4.3.33(3)-release (i686-pc-msys) > > Gcc: gcc.exe (Rev5, Built by MSYS2 project) 4.9.2 > > Perl: This is perl 5, version 20, subversion 2 (v5.20.2) built for > i686-msys-thread-multi-64int > > Python: Python 3.3.3 > > > > > > Error message: > > > > g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport > -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions > -mthreads -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV > -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE > -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS > -D_USE_MATH_DEFINES -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT > -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS > -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 > -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. > -I../../include -I../../include/QtCore -I../../include/QtCore/5.5.0 > -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre > -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 > -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o > .obj/release/qsimd.o tools/qsimd.cpp > > tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or > directory > > #include > > ^ > > compilation terminated. > > Makefile.Release:16625: recipe for target '.obj/release/qsimd.o' > failed > > make[4]: *** [.obj/release/qsimd.o] Error 1 > > make[4]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:34: recipe for target 'release' failed > > make[3]: *** [release] Error 2 > > make[3]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:165: recipe for target 'sub-corelib-make_first' failed > > make[2]: *** [sub-corelib-make_first] Error 2 > > make[2]: Leaving directory '/d/source/qt5/qtbase/src' > > Makefile:41: recipe for target 'sub-src-make_first' failed > > make[1]: *** [sub-src-make_first] Error 2 > > make[1]: Leaving directory '/d/source/qt5/qtbase' > > Makefile:69: recipe for target 'module-qtbase-make_first' failed > > make: *** [module-qtbase-make_first] Error 2 > Hi, You need to post full reproduction instructions or a link to them to help us to diagnose this. > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From kl222 at 126.com Fri Apr 10 07:22:28 2015 From: kl222 at 126.com (kl222) Date: Fri, 10 Apr 2015 13:22:28 +0800 Subject: [Development] Build qt fail Message-ID: <154701d0734e$58faa910$0aeffb30$@126.com> I guess is that the header files generated script error. The QByteArray isn't generated, but the qbytearray.h is generated. The following is my operation: 1.Qt branch: 5.5 2.Configuration order: ./configure -opensource -confirm-license -nomake examples -nomake tests -no-compile-examples -no-sql-sqlite -no-sql-odbc -skip qtdoc -skip qtwebkit-examples -skip qt3d -skip qtcanvas3d -prefix /d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/qt -shared -release -I /d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/include -L /d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/lib -platform win32-g++ -skip qtandroidextras -skip qtx11extras -skip qtmacextras 3.Configuration information: Running configuration tests... Configure summary Build type: win32-g++ (i386, CPU features: none detected) Build options: Configuration .......... accessibility audio-backend avx avx2 c++11 clock-gettime clock-monotonic concurrent dbus full-config getaddrinfo harfbuzz large-config medium-config minimal-config no-freetype opengl openssl pcre png precompile_header qpa qpa reduce_exports reduce_relocations release shared small-config sse2 sse3 sse4_1 sse4_2 ssse3 system-zlib Build parts ............ libs tools Mode ................... release Using sanitizer(s)...... none Using C++11 ............ yes Using gold linker....... no Using PCH .............. yes Target compiler supports: SSE2/SSE3/SSSE3 ...... yes/yes/yes SSE4.1/SSE4.2 ........ yes/yes AVX/AVX2 ............. yes/yes Qt modules and options: Qt D-Bus ............... yes (loading dbus-1 at runtime) Qt Concurrent .......... yes Qt GUI ................. yes Qt Widgets ............. yes Large File ............. yes QML debugging .......... yes Use system proxies ..... no Support enabled for: Accessibility .......... yes ALSA ................... no CUPS ................... no DirectWrite ............ no Evdev .................. no FontConfig ............. no FreeType ............... no Glib ................... no GStreamer .............. no GTK theme .............. no HarfBuzz ............... yes (bundled copy) Iconv .................. no ICU .................... no Image formats: GIF .................. yes (plugin, using bundled copy) JPEG ................. yes (plugin, using bundled copy) PNG .................. yes (in QtGui, using bundled copy) journald ............... no libinput................ no mtdev .................. no Networking: getaddrinfo .......... yes getifaddrs ........... no IPv6 ifname .......... no libproxy.............. no OpenSSL .............. yes (loading libraries at run-time) NIS .................... no OpenGL / OpenVG: EGL .................. no OpenGL ............... desktop OpenVG ............... no PCRE ................... yes (bundled copy) pkg-config ............. yes PulseAudio ............. no QPA backends: DirectFB ............. no EGLFS ................ no EGLFS i.MX6....... . no EGLFS KMS .......... no EGLFS Mali ......... no EGLFS Raspberry Pi . no EGLFS X11 .......... no LinuxFB .............. no XCB .................. no Session management ..... yes SQL drivers: DB2 .................. no InterBase ............ no MySQL ................ no OCI .................. no ODBC ................. no PostgreSQL ........... no SQLite 2 ............. no SQLite ............... no TDS .................. no tslib .................. no udev ................... no xkbcommon-x11........... no xkbcommon-evdev......... no zlib ................... yes (system library) Info: creating super cache file D:\source\qt5\.qmake.super NOTE: This platform does not support runtime library paths, using -no-rpath. Qt is now configured for building. Just run 'make'. Once everything is built, you must run 'make install'. Qt will be installed into /d/source/rabbitim/ThirdLibary/windows_mingw/qt Prior to reconfiguration, make sure you remove any leftovers from the previous build. 4.Complie order: mingw32-make 5.complie error information: g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport g++ -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions g++ -mthreads -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV g++ -DQT_NO_LIBUDEV -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT g++ -DQT_NO_USING_NAMESPACE -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT g++ -D_CRT_SECURE_NO_WARNINGS -D_USE_MATH_DEFINES g++ -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER g++ -DQT_DEPRECATED_WARNINGS -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 g++ -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. g++ -I/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/inclu g++ de -I../../include -I../../include/QtCore g++ -I../../include/QtCore/5.5.0 -I../../include/QtCore/5.5.0/QtCore g++ -Itmp -Iglobal -I../3rdparty/pcre -I../3rdparty/harfbuzz/src g++ -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 g++ -I.moc/release -I../../mkspecs/win32-g++ -o g++ .obj/release/qsharedpointer.o tools/qsharedpointer.cpp -c -include g++ .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport -msse2 g++ -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions -mthreads g++ -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV g++ -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE g++ -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS g++ -D_USE_MATH_DEFINES -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT g++ -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS g++ -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 -DPCRE_STATIC -DQT_NO_ICONV g++ -DQT_CORE_LIB -DQT_NO_DEBUG -I. g++ -I/d/source/rabbitim/ThirdLibary/build_script/../windows_mingw/inclu g++ de -I../../include -I../../include/QtCore g++ -I../../include/QtCore/5.5.0 -I../../include/QtCore/5.5.0/QtCore g++ -Itmp -Iglobal -I../3rdparty/pcre -I../3rdparty/harfbuzz/src g++ -I../3rdparty/md5 -I../3rdparty/md4 -I../3rdparty/sha3 g++ -I.moc/release -I../../mkspecs/win32-g++ -o .obj/release/qsimd.o g++ tools/qsimd.cpp tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or directory #include ^ compilation terminated. Makefile.Release:16638: recipe for target '.obj/release/qsimd.o' failed mingw32-make[4]: *** [.obj/release/qsimd.o] Error 1 mingw32-make[4]: Leaving directory 'D:/source/qt5/qtbase/src/corelib' Makefile:34: recipe for target 'release' failed mingw32-make[3]: *** [release] Error 2 mingw32-make[3]: Leaving directory 'D:/source/qt5/qtbase/src/corelib' Makefile:165: recipe for target 'sub-corelib-make_first' failed mingw32-make[2]: *** [sub-corelib-make_first] Error 2 mingw32-make[2]: Leaving directory 'D:/source/qt5/qtbase/src' Makefile:41: recipe for target 'sub-src-make_first' failed mingw32-make[1]: *** [sub-src-make_first] Error 2 mingw32-make[1]: Leaving directory 'D:/source/qt5/qtbase' Makefile:62: recipe for target 'module-qtbase-make_first' failed mingw32-make: *** [module-qtbase-make_first] Error 2 6. Generate header file: Administrator at l-PC MINGW32 /d/source/qt5/qtbase/include/QtCore $ ls 5.5.0/ QMessageLogger headers.pri QMetaClassInfo QAbstractAnimation QMetaEnum qabstractanimation.h QMetaObject qabstracteventdispatcher.h qmetaobject.h QAbstractItemModel QMetaProperty qabstractitemmodel.h QMetaType QAbstractListModel qmetatype.h QAbstractNativeEventFilter QMetaTypeId qabstractnativeeventfilter.h QMetaTypeId2 QAbstractProxyModel QMetaTypeIdQObject qabstractproxymodel.h QMimeData QAbstractState qmimedata.h qabstractstate.h QMimeDatabase QAbstractTableModel qmimedatabase.h QAbstractTransition QMimeType qabstracttransition.h qmimetype.h qalgorithms.h QModelIndex QAnimationDriver QModelIndexList QAnimationGroup QMultiHash qanimationgroup.h QMultiMap QArgument QMutableByteArrayListIterator qarraydata.h QMutableStringListIterator qarraydataops.h QMutex qarraydatapointer.h qmutex.h QAssociativeIterable QMutexLocker qatomic.h qnamespace.h qatomic_armv5.h QNoDebug qatomic_armv6.h qnumeric.h qatomic_armv7.h QObject qatomic_bootstrap.h qobject.h qatomic_cxx11.h qobject_impl.h qatomic_gcc.h qobjectcleanuphandler.h qatomic_ia64.h QObjectData qatomic_mips.h qobjectdefs.h qatomic_msvc.h qobjectdefs_impl.h qatomic_unix.h QObjectList qatomic_x86.h qpair.h QAtomicAdditiveType QParallelAnimationGroup QAtomicInt qparallelanimationgroup.h QAtomicOpsSupport QPauseAnimation QAtomicWindowsType qpauseanimation.h qbasicatomic.h QPersistentModelIndex QBasicAtomicInt qplugin.h QBasicAtomicPointer QPluginLoader QBasicMutex qpluginloader.h QBasicTimer qpoint.h qbasictimer.h QPointer QBitArray qpointer.h qbitarray.h qprocess.h QBitRef QProcessEnvironment QBuffer qprocessordetection.h qbuffer.h QPropertyAnimation qbytearray.h qpropertyanimation.h QByteArrayData qqueue.h QByteArrayDataPtr QReadLocker QByteArrayList QReadWriteLock qbytearraylist.h qreadwritelock.h QByteArrayMatcher qrect.h qbytearraymatcher.h qrefcount.h QByteRef QRegExp qcache.h qregexp.h QChar QRegularExpression qchar.h qregularexpression.h QCharRef QRegularExpressionMatch QChildEvent QRegularExpressionMatchIterator QCollator QResource qcollator.h qresource.h QCollatorSortKey qresultstore.h QCommandLineOption QReturnArgument qcommandlineoption.h qrunnable.h QCommandLineParser QSaveFile qcommandlineparser.h qsavefile.h qcompilerdetection.h QScopedArrayPointer QConcatenable qscopedpointer.h qconfig.h QScopedPointerArrayDeleter qconfig-dist.h QScopedPointerDeleteLater qconfig-large.h QScopedPointerPodDeleter qconfig-medium.h qscopedvaluerollback.h qconfig-minimal.h QSemaphore qconfig-nacl.h qsemaphore.h qconfig-small.h QSequentialAnimationGroup qcontainerfwd.h qsequentialanimationgroup.h QContiguousCache qset.h qcontiguouscache.h qsettings.h QContiguousCacheTypedData QSharedData qcoreapplication.h qshareddata.h qcoreevent.h QSharedDataPointer QCryptographicHash QSharedMemory qcryptographichash.h qsharedmemory.h QDataStream qsharedpointer.h qdatastream.h qsharedpointer_impl.h QDate QSignalMapper QDateTime qsignalmapper.h qdatetime.h QSignalTransition qdebug.h qsignaltransition.h QDebugStateSaver qsize.h QDeferredDeleteEvent QSocketNotifier QDir qsocketnotifier.h qdir.h QSortFilterProxyModel QDirIterator qsortfilterproxymodel.h qdiriterator.h qstack.h QDynamicPropertyChangeEvent qstandardpaths.h QEasingCurve QState qeasingcurve.h qstate.h qelapsedtimer.h QStateMachine QEnableSharedFromThis qstatemachine.h qendian.h QStaticArrayData QEventLoop QStaticByteArrayData qeventloop.h QStaticPlugin QEventLoopLocker QStaticStringData QEventTransition QStorageInfo qeventtransition.h qstorageinfo.h qexception.h QString QExplicitlySharedDataPointer qstring.h qfactoryinterface.h QStringBuilder qfeatures.h qstringbuilder.h QFile QStringBuilderBase qfile.h QStringBuilderCommon QFileDevice QStringData qfiledevice.h QStringDataPtr QFileInfo qstringlist.h qfileinfo.h QStringListIterator QFileSelector qstringlistmodel.h qfileselector.h QStringMatcher QFileSystemWatcher qstringmatcher.h qfilesystemwatcher.h QSysInfo QFinalState qsysinfo.h qfinalstate.h qsystemdetection.h qflags.h QSystemSemaphore qfunctions_nacl.h qsystemsemaphore.h qfunctions_vxworks.h Qt qfunctions_wince.h qt_windows.h qfunctions_winrt.h QtAlgorithms QFuture QtCleanUpFunction qfuture.h QtConfig QFutureInterface QtContainerFwd qfutureinterface.h QtCore QFutureInterfaceBase QtCoreDepends qfuturesynchronizer.h QtCoreVersion QFutureWatcher qtcoreversion.h qfuturewatcher.h QtDebug QFutureWatcherBase QTemporaryDir QGenericArgument qtemporarydir.h qgenericatomic.h QTemporaryFile QGenericReturnArgument qtemporaryfile.h qglobal.h QtEndian qglobalstatic.h QTextBoundaryFinder qhash.h qtextboundaryfinder.h QHashData QTextCodec QHashDummyValue qtextcodec.h QHashNode QTextDecoder QHistoryState qtextstream.h qhistorystate.h QTextStreamFunction QIdentityProxyModel QtGlobal qidentityproxymodel.h qthread.h QIncompatibleFlag QThreadPool QInternal qthreadpool.h qiodevice.h qthreadstorage.h qisenum.h QTime QItemSelection QTimeLine QItemSelectionModel qtimeline.h qitemselectionmodel.h qtimer.h qiterator.h QTimerEvent QJsonArray QTimeZone qjsonarray.h qtimezone.h QJsonDocument QtNumeric qjsondocument.h QtPlugin QJsonObject QtPluginMetaDataFunction qjsonobject.h QTranslator QJsonParseError qtranslator.h QJsonValue QTypeInfo qjsonvalue.h qtypeinfo.h QJsonValueRef QTypeInfoMerger QJsonValueRefPtr qtypetraits.h QLatin1Char QUnhandledException QLatin1String QUrl QLibrary qurl.h qlibrary.h QUrlQuery QLibraryInfo qurlquery.h qlibraryinfo.h QUrlTwoFlags QLine quuid.h qline.h QVariant QLineF qvariant.h QLinkedList QVariantAnimation qlinkedlist.h qvariantanimation.h QLinkedListNode QVariantComparisonHelper QList QVariantHash qlist.h QVariantList QListData QVariantMap QListSpecialMethods qvarlengtharray.h QLocale QVector qlocale.h qvector.h qlocale_blackberry.h QWaitCondition QLockFile qwaitcondition.h qlockfile.h QWeakPointer qlogging.h QWinEventNotifier qloggingcategory.h qwineventnotifier.h QMap QWriteLocker qmap.h qxmlstream.h QMapData QXmlStreamAttribute QMapDataBase QXmlStreamAttributes QMapNode QXmlStreamEntityDeclaration QMapNodeBase QXmlStreamEntityDeclarations QMargins QXmlStreamEntityResolver qmargins.h QXmlStreamNamespaceDeclaration QMarginsF QXmlStreamNamespaceDeclarations qmath.h QXmlStreamNotationDeclaration QMessageAuthenticationCode QXmlStreamNotationDeclarations qmessageauthenticationcode.h QXmlStreamWriter QMessageLogContext -----邮件原件----- 发件人: Ray Donnelly [mailto:mingw.android at gmail.com] 发送时间: 2015年4月9日 16:29 收件人: kl222 抄送: android-development at qt-project.org 主题: Re: [Development] Build qt fail On Thu, Apr 9, 2015 at 7:47 AM, kl222 wrote: > Environment: > > Operation System: windows7 Ultimate > > Msys2: MINGW32_NT-6.1 l-PC 2.1.0(0.287/5/3) 2015-04-05 21:26 i686 Msys > > Bash: GNU bash，version 4.3.33(3)-release (i686-pc-msys) > > Gcc: gcc.exe (Rev5, Built by MSYS2 project) 4.9.2 > > Perl: This is perl 5, version 20, subversion 2 (v5.20.2) built for > i686-msys-thread-multi-64int > > Python: Python 3.3.3 > > > > > > Error message: > > > > g++ -c -include .pch/release/qt_pch.h -pipe -fno-keep-inline-dllexport > -msse2 -mstackrealign -mfpmath=sse -O2 -std=gnu++0x -fexceptions > -mthreads -frtti -Wall -Wextra -DUNICODE -DQT_NO_MTDEV -DQT_NO_LIBUDEV > -DQT_NO_EVDEV -DQT_NO_TSLIB -DQT_NO_LIBINPUT -DQT_NO_USING_NAMESPACE > -DQT_BUILD_CORE_LIB -DQT_BUILDING_QT -D_CRT_SECURE_NO_WARNINGS > -D_USE_MATH_DEFINES -DQT_ASCII_CAST_WARNINGS -DQT_MOC_COMPAT > -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS > -DQT_DISABLE_DEPRECATED_BEFORE=0x040800 > -DPCRE_STATIC -DQT_NO_ICONV -DQT_CORE_LIB -DQT_NO_DEBUG -I. > -I../../include -I../../include/QtCore -I../../include/QtCore/5.5.0 > -I../../include/QtCore/5.5.0/QtCore -Itmp -Iglobal -I../3rdparty/pcre > -I../3rdparty/harfbuzz/src -I../3rdparty/md5 -I../3rdparty/md4 > -I../3rdparty/sha3 -I.moc/release -I../../mkspecs/win32-g++ -o > .obj/release/qsimd.o tools/qsimd.cpp > > tools/qsimd.cpp:36:22: fatal error: QByteArray: No such file or > directory > > #include > > ^ > > compilation terminated. > > Makefile.Release:16625: recipe for target '.obj/release/qsimd.o' > failed > > make[4]: *** [.obj/release/qsimd.o] Error 1 > > make[4]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:34: recipe for target 'release' failed > > make[3]: *** [release] Error 2 > > make[3]: Leaving directory '/d/source/qt5/qtbase/src/corelib' > > Makefile:165: recipe for target 'sub-corelib-make_first' failed > > make[2]: *** [sub-corelib-make_first] Error 2 > > make[2]: Leaving directory '/d/source/qt5/qtbase/src' > > Makefile:41: recipe for target 'sub-src-make_first' failed > > make[1]: *** [sub-src-make_first] Error 2 > > make[1]: Leaving directory '/d/source/qt5/qtbase' > > Makefile:69: recipe for target 'module-qtbase-make_first' failed > > make: *** [module-qtbase-make_first] Error 2 > Hi, You need to post full reproduction instructions or a link to them to help us to diagnose this. > > > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From christian.kandeler at theqtcompany.com Fri Apr 10 09:51:42 2015 From: christian.kandeler at theqtcompany.com (Christian Kandeler) Date: Fri, 10 Apr 2015 09:51:42 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <2160476.QqaBeYKDTW@tjmaciei-mobl4> References: <201504081313.19868.marc.mutz@kdab.com> <14883765.y9HtRjQQyC@tjmaciei-mobl4> <2160476.QqaBeYKDTW@tjmaciei-mobl4> Message-ID: <5527810E.6090205@theqtcompany.com> On 04/09/2015 08:51 PM, Thiago Macieira wrote: > The objective is to make Qt6 QStringList be a typedef to QList, not a > separate class. Uh-oh, that will break all forward declarations in client code... Christian From dangelog at gmail.com Fri Apr 10 10:00:15 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 10 Apr 2015 10:00:15 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <5527810E.6090205@theqtcompany.com> References: <201504081313.19868.marc.mutz@kdab.com> <14883765.y9HtRjQQyC@tjmaciei-mobl4> <2160476.QqaBeYKDTW@tjmaciei-mobl4> <5527810E.6090205@theqtcompany.com> Message-ID: On 10 April 2015 at 09:51, Christian Kandeler wrote: > Uh-oh, that will break all forward declarations in client code... Why doesn't syncqt generate forwarding headers just yet? :P -- Giuseppe D'Angelo From andre at familiesomers.nl Fri Apr 10 10:03:33 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Fri, 10 Apr 2015 10:03:33 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <2160476.QqaBeYKDTW@tjmaciei-mobl4> References: <201504081313.19868.marc.mutz@kdab.com> <14883765.y9HtRjQQyC@tjmaciei-mobl4> <2160476.QqaBeYKDTW@tjmaciei-mobl4> Message-ID: <552783D5.6060203@familiesomers.nl> Thiago Macieira schreef op 9-4-2015 om 20:51: > On Thursday 09 April 2015 11:45:20 Thiago Macieira wrote: >> It wasn't a gratuitous change, though. It was required so I could move some >> QStringList methods to QList. Since qlist.h needs to include >> qstringlist.h to ensure the full specialisation of >> QListSpecialMethods is present before QList is ever >> instantiated, I had to make sure qstringlist.h didn't include qdatastream.h >> -- because qdatastream.h includes qlist.h and boom! cyclic includes. > The objective is to make Qt6 QStringList be a typedef to QList, not a > separate class. > > We've already managed that for QByteArrayList -- it's just a typedef. There are quite a number of convenience functions on QStringList. Do you really mean to break the code of everyone using them? Better start marking those as deprecated soon then? André From olivier at woboq.com Fri Apr 10 11:12:38 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 10 Apr 2015 11:12:38 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <552783D5.6060203@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <2160476.QqaBeYKDTW@tjmaciei-mobl4> <552783D5.6060203@familiesomers.nl> Message-ID: <204122347.Hf5IvaHEhV@finn> On Friday 10 April 2015 10:03:33 André Somers wrote: > Thiago Macieira schreef op 9-4-2015 om 20:51: > > On Thursday 09 April 2015 11:45:20 Thiago Macieira wrote: > >> It wasn't a gratuitous change, though. It was required so I could move > >> some > >> QStringList methods to QList. Since qlist.h needs to include > >> qstringlist.h to ensure the full specialisation of > >> QListSpecialMethods is present before QList is ever > >> instantiated, I had to make sure qstringlist.h didn't include > >> qdatastream.h > >> -- because qdatastream.h includes qlist.h and boom! cyclic includes. > > > > The objective is to make Qt6 QStringList be a typedef to QList, > > not a separate class. > > > > We've already managed that for QByteArrayList -- it's just a typedef. > > There are quite a number of convenience functions on QStringList. Do you > really mean to break the code of everyone using them? Better start > marking those as deprecated soon then? No, They would still be there because of the template specialization. Look at QByteArrayList. http://code.woboq.org/qt5/qtbase/src/corelib/tools/qbytearraylist.h.html#QByteArrayList -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From andre at familiesomers.nl Fri Apr 10 11:56:37 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Fri, 10 Apr 2015 11:56:37 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <204122347.Hf5IvaHEhV@finn> References: <201504081313.19868.marc.mutz@kdab.com> <2160476.QqaBeYKDTW@tjmaciei-mobl4> <552783D5.6060203@familiesomers.nl> <204122347.Hf5IvaHEhV@finn> Message-ID: <55279E55.7060405@familiesomers.nl> Olivier Goffart schreef op 10-4-2015 om 11:12: > On Friday 10 April 2015 10:03:33 André Somers wrote: >> Thiago Macieira schreef op 9-4-2015 om 20:51: >>> On Thursday 09 April 2015 11:45:20 Thiago Macieira wrote: >>>> It wasn't a gratuitous change, though. It was required so I could move >>>> some >>>> QStringList methods to QList. Since qlist.h needs to include >>>> qstringlist.h to ensure the full specialisation of >>>> QListSpecialMethods is present before QList is ever >>>> instantiated, I had to make sure qstringlist.h didn't include >>>> qdatastream.h >>>> -- because qdatastream.h includes qlist.h and boom! cyclic includes. >>> The objective is to make Qt6 QStringList be a typedef to QList, >>> not a separate class. >>> >>> We've already managed that for QByteArrayList -- it's just a typedef. >> There are quite a number of convenience functions on QStringList. Do you >> really mean to break the code of everyone using them? Better start >> marking those as deprecated soon then? > No, They would still be there because of the template specialization. > Look at QByteArrayList. > http://code.woboq.org/qt5/qtbase/src/corelib/tools/qbytearraylist.h.html#QByteArrayList > Interesting approach. What's the benefit over using a class inheriting from the template as QStringList does? André From jani.heikkinen at theqtcompany.com Fri Apr 10 12:23:48 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Fri, 10 Apr 2015 10:23:48 +0000 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming Message-ID: <1428661428222.50531@theqtcompany.com> Hi all, Qt5.git integration succeed finally in '5.4' and so on we can start soft branching from '5.4' to '5.4.2' today. '5.4.2' branch is already created and downmerge from '5.4' to '5.4.2' will be done Friday 17th April 2015. That way everyone should have enough time to finalize ongoing changes in '5.4' branch & start using '5.4.2' branch for the changes targeted to Qt 5.4.2 release. Target is to release Qt 5.4.2 at the end of April. Please remember: we are doing patch level release now meaning do not put any new features / nice to have fix in it! Please make sure all issues blocking the Qt 5.4.2 release are linked to blocker meta bug: https://bugreports.qt.io/browse/QTBUG-44881 Snapshot creation is ongoing & first Qt5.4.2 snapshot should be available here later today: http://download.qt.io/snapshots/qt/5.4/ br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten.heimrich at digia.com Fri Apr 10 12:50:43 2015 From: karsten.heimrich at digia.com (Karsten Heimrich) Date: Fri, 10 Apr 2015 12:50:43 +0200 Subject: [Development] Qt Installer Framework Script In-Reply-To: References: Message-ID: <5527AB03.8040302@digia.com> Hi, On 09.04.2015 18:50, Berkay Elbir wrote: > > Hello, > > I have a question about QInstaller. How can I make the Uninstaller > check exe is running or not before uninstalling? I can do this with > installing process but I can not write correct script > (installscript.qs) for uninstalling process. > > Should I write another script for Uninstaller? Actually, I managed to > come here with the examples. This is my script : > what you did is a so called Component script, which is executed during install, update, management but not uninstall. There's a second form of scripts available, called Control scripts that are executed always. You can either embed it into your application or start a IFW binary with --script path/to/script. In your case you would like to embed it inside the binary though. Starting point here is the config.xml, put your script next to that file and add a your_script tag. See: http://doc.qt.io/qtinstallerframework/ifw-globalconfig.html Now your script could look like this: function Controller() { } Controller.prototype.IntroductionPageCallback =function() { if (installer.isUninstaller()) { if (installer.isProcessRunning(YOUR_PROCESS_NAME)) { var widget =gui.currentPageWidget(); // get the current wizard page widget.ErrorLabel.setText("" + ("Process: " + YOUR_PROCESS + " still running." + ""); // hide all following pages installer.setDefaultPageVisible(QInstaller.TargetDirectory, false); installer.setDefaultPageVisible(QInstaller.ComponentSelection, false); installer.setDefaultPageVisible(QInstaller.ReadyForInstallation, false); installer.setDefaultPageVisible(QInstaller.StartMenuSelection, false); installer.setDefaultPageVisible(QInstaller.PerformInstallation, false); installer.setDefaultPageVisible(QInstaller.LicenseCheck, false); } } } Basically if you detect your process is running, print an error message and hide all pages. So if the user presses the 'Next' button he will end up on the finish page. Of course you need to connect to the |packageManagerCoreTypeChanged() |signal the page emits so you can set the pages visible again if the user switches to package manager or updater mode. See: http://doc.qt.io/qtinstallerframework/noninteractive.html#introduction-page there is an example script. Regards, -------- Karsten Heimrich, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B Email: karsten.heimrich at theqtcompany.com | www.qt.io |Qt Blog: http://blog.qt.digia.com/ | Twitter: @QtbyDigia, @Qtproject | Facebook: www.facebook.com/qt -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobbyphilip at gmail.com Fri Apr 10 12:54:21 2015 From: bobbyphilip at gmail.com (Bobby Philip) Date: Fri, 10 Apr 2015 16:24:21 +0530 Subject: [Development] QT 5.3 DirectFB port In-Reply-To: References: Message-ID: I have been doing a little more digging into this. I can see QDirectFBWindow being created by the QPlatformIntegration APIs, and this window is being used in QDirectFBBackingStore. But the problem I see is that the surface being associated with this window is not a primary surface. I think this is why I dont see anything on the output. I would like to know whether the surface associated with the layer has to be primary for its contents to be visible. Also does setting the cooperativelevel have any effect on this, or should a specific cooperative level be set to DFB to get a primary surface. Regards B On Thu, Apr 9, 2015 at 4:17 PM, Bobby Philip wrote: > Hi, > I have been looking at how the DirectFB QPA platform inside QT works. > I have seen how inside QDirectFbIntegration::connectToDirectFb() the > DirectFB interface is initialised followed by the screen and input module. > > On my platform atleast, when I create a widget, I see a QDirectbWindow > being created, and when it is set visble, a Flip is called for this surface. > > What I havent understood, is how the output of a newly created surface is > blitted to the surface belonging to the layer belonging to the screen which > was inited earlier. I believe only when graphics is blitted to this surface > will it actually be seen. > > Could someone point me to how this is done. I am working on a mips based > platform and newly porting QT5.3 to it. > > Regards > B > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Fri Apr 10 13:29:01 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 10 Apr 2015 13:29:01 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <55279E55.7060405@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <204122347.Hf5IvaHEhV@finn> <55279E55.7060405@familiesomers.nl> Message-ID: <201504101329.01503.marc.mutz@kdab.com> On Friday 10 April 2015 11:56:37 André Somers wrote: [...] > Interesting approach. What's the benefit over using a class inheriting > from the template as QStringList does? [...] For one, you're not supoosed to inherit from value classes. For another... Oh, I think that's enough reasons :) Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From simon.hausmann at theqtcompany.com Fri Apr 10 13:38:55 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Fri, 10 Apr 2015 13:38:55 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <201504091440.11963.marc.mutz@kdab.com> References: <201504081313.19868.marc.mutz@kdab.com> <2217077.QBTThHQsVf@rhea> <201504091440.11963.marc.mutz@kdab.com> Message-ID: <2170873.KJLBzvMtub@rhea> On Thursday 9. April 2015 14.40.11 Marc Mutz wrote: > On Thursday 09 April 2015 12:46:11 Simon Hausmann wrote: > > > So, by this line of reasoning, the list of #includes in a public header > > > file must be a monotonically increasing function of the Qt version. > > > Since we're keeping SC even across major versions these days, we'll thus > > > slowly converge on including all of a Qt module's headers in each of its > > > headers. So, why don't we shortcut the process and include in > > > each QtFoo-module's header _today_? :) > > > > > > > > > > > > I'm exaggerating, of course. A bit, at least. > > > > Right, you are exaggerating. And that's why I don't agree with your > > enhanced line of reasoning. > > I was exaggerating when proposing to include in each header. > > I was _not_ exaggerating when I said that by your (plural) line of > reasoning, we'll slowly accumulate cruft in every header that will hurt > maintainability and compile times. Just look at what qglobal.h includes to > stay SC. It's ridiculous. Even worse, it's not enough. For > https://codereview.qt- project.org/106680 I'm still fighting with myself > because I'd need to add to and rearrange some > code in qglobal.h to be able to use QEnableIf as early as qRound(). Yes, over time we will accumulate cruft. We must indeed be very careful what we put into public header files. > > > I wonder: wouldn't it also harm the project if people who use Qt for a > > > living, pay your salary by buying licenses and have to spend X amount of > > > money on additional hardware just to make the nightly builds actually > > > build in just one night started to look for alternatives? > > > > Surely it would. However at the same time I strongly doubt that the > > proposed changes have a significant impact on the overall build times, > > especially compared to the much more expensive human developer time that > > is spent when encountering source incompatible changes and a reduction of > > daytime productivity is the result. > > The problem is not this one change. The problem is the cumulative regression > in compile time that ensues when we're not even allowing include changes > that only break clients that rely on indirect includes. > > It's easy to prevent these breakages user-side by applying a tool like Ossi > posted in one of the changes: > https://code.google.com/p/include-what-you-use/ > > As Andre said, which header includes which other headers isn't even > documented, so it's an implementation detail. Implementation details are > subject to change. Implementation details are details that you can change without affecting the users. The proposed changes however do affect the users. In my opinion the "clean up" isn't worth the damage it does, as I explained in my original reply. Simon From porten at froglogic.com Fri Apr 10 14:00:17 2015 From: porten at froglogic.com (Harri Porten) Date: Fri, 10 Apr 2015 14:00:17 +0200 (CEST) Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <201504081313.19868.marc.mutz@kdab.com> References: <201504081313.19868.marc.mutz@kdab.com> Message-ID: On Wed, 8 Apr 2015, Marc Mutz wrote: > I have in the past fixed #include mistakes such as #include > for QSharedDataPointer, and even though each time the issue came up that this > is a SiC change (but only for users that unduly rely on indirect includes), so > far they were always accepted. > > When splitting off qHash() from qhash.h into qhashfunctions.h, I have come > across many files that included qhash.h without using it, and likewise some > for which qhashfunctions.h would suffice. One of them now got a -1 for being > SiC. > > Can we please decide once and for all whether #include cleanups that are > technically SiC are ok or not, if they only affect users that rely on indirect > includes? > > My vote obviously goes to allowing them. I vote for marking the cleanup as a TODO for Qt 6. Non-perfect includes a minor hassle compared to the unpleasent surprises of those upgrading. Speaking of which: a script binding generator tool I used on Qt 5.5 chocked on the "internal" QStringList changes. Aren't those Qt 6 candidates, too? Harri. From andre at familiesomers.nl Fri Apr 10 14:06:18 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Fri, 10 Apr 2015 14:06:18 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <201504101329.01503.marc.mutz@kdab.com> References: <201504081313.19868.marc.mutz@kdab.com> <204122347.Hf5IvaHEhV@finn> <55279E55.7060405@familiesomers.nl> <201504101329.01503.marc.mutz@kdab.com> Message-ID: <5527BCBA.8070800@familiesomers.nl> Marc Mutz schreef op 10-4-2015 om 13:29: > On Friday 10 April 2015 11:56:37 André Somers wrote: > [...] >> Interesting approach. What's the benefit over using a class inheriting >> from the template as QStringList does? > [...] > > For one, you're not supoosed to inherit from value classes. For another... Oh, > I think that's enough reasons :) > That a religious argument instead of a technical one. It was meant as a serious question. It looks to me like the chosen alternative is more complex than what was there before, especially in tricking the user to think that it actually _is_ a class. So again: what is the benefit of a change like this? André From olivier at woboq.com Fri Apr 10 14:58:24 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 10 Apr 2015 14:58:24 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <5527BCBA.8070800@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <201504101329.01503.marc.mutz@kdab.com> <5527BCBA.8070800@familiesomers.nl> Message-ID: <2817634.s0JSDMOyT1@finn> On Friday 10. April 2015 14:06:18 André Somers wrote: > Marc Mutz schreef op 10-4-2015 om 13:29: > > On Friday 10 April 2015 11:56:37 André Somers wrote: > > [...] > > > >> Interesting approach. What's the benefit over using a class inheriting > >> from the template as QStringList does? > > > > [...] > > > > For one, you're not supoosed to inherit from value classes. For another... > > Oh, I think that's enough reasons :) > > That a religious argument instead of a technical one. > > It was meant as a serious question. It looks to me like the chosen > alternative is more complex than what was there before, especially in > tricking the user to think that it actually _is_ a class. So again: what > is the benefit of a change like this? If you have a template QList returnAListOfThings(); You can do returnAListOfThings().join("*"); For example, now, QStringList::fromVector(QVector()) returns a QList which is not a QStringList (So you can't directly call special method. And when you assign it to a QStringList, it cannot be moved) -- Olivier Woboq - Qt services and support - http://woboq.com From kollix at aon.at Fri Apr 10 14:57:07 2015 From: kollix at aon.at (Martin Koller) Date: Fri, 10 Apr 2015 14:57:07 +0200 Subject: [Development] Qt on iOS retina display Message-ID: <5607634.iOPhhbyb0t@lapi.koller> Hi all, I'm porting our app to iOS and can already run it on an iPad Air which should have 2048-by-1536 resolution at 264 pixels per inch. However Qt (5.4.1) only tells me it has 132 dpi and 1024x768 pixels. This seems to have something to do with the device pixel ratio which it tells me is 2 Since I'm completely new to the Apple world (and still could manage to run a Qt app on it - hooray, thanks Qt!!), can somebody tell me if I can do something in whatever settings or my app to have the full resolution or is it just like that ? -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From andre at familiesomers.nl Fri Apr 10 15:03:04 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Fri, 10 Apr 2015 15:03:04 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <2817634.s0JSDMOyT1@finn> References: <201504081313.19868.marc.mutz@kdab.com> <201504101329.01503.marc.mutz@kdab.com> <5527BCBA.8070800@familiesomers.nl> <2817634.s0JSDMOyT1@finn> Message-ID: <5527CA08.7080504@familiesomers.nl> Olivier Goffart schreef op 10-4-2015 om 14:58: > If you have a template QList returnAListOfThings(); You > can do returnAListOfThings().join("*"); For example, now, > QStringList::fromVector(QVector()) returns a QList > which is not a QStringList (So you can't directly call special method. > And when you assign it to a QStringList, it cannot be moved) Thank you; that is a good example. You basicaly make the special methods available for every instantiation of the base template with the type, instead of only for those explicitly instantiated as with the special class. Ok, fair enough, that sounds like something useful to have. I do think it needs a bit of work on the documentation side of things to make it clear that really any QList now behaves as/is a QByteArrayList. The documentation still says it is a class. André From andre at familiesomers.nl Fri Apr 10 15:04:58 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Fri, 10 Apr 2015 15:04:58 +0200 Subject: [Development] Qt on iOS retina display In-Reply-To: <5607634.iOPhhbyb0t@lapi.koller> References: <5607634.iOPhhbyb0t@lapi.koller> Message-ID: <5527CA7A.2020507@familiesomers.nl> Martin Koller schreef op 10-4-2015 om 14:57: > Hi all, > > I'm porting our app to iOS and can already run it on an iPad Air which should > have 2048-by-1536 resolution at 264 pixels per inch. > However Qt (5.4.1) only tells me it has 132 dpi and 1024x768 pixels. > This seems to have something to do with the device pixel ratio which it tells > me is 2 > > Since I'm completely new to the Apple world (and still could manage to run a Qt app > on it - hooray, thanks Qt!!), can somebody tell me if I can do something in > whatever settings or my app to have the full resolution or is it just like that ? > What do you need the full resolution for? Fonts will automaticaly sharpen because they are rendered at full resolution, and image resources can be supplied in two resolutions. André From gmaxera at gmail.com Fri Apr 10 15:09:44 2015 From: gmaxera at gmail.com (Gianluca) Date: Fri, 10 Apr 2015 15:09:44 +0200 Subject: [Development] Qt on iOS retina display In-Reply-To: <5607634.iOPhhbyb0t@lapi.koller> References: <5607634.iOPhhbyb0t@lapi.koller> Message-ID: Hello Martin, it’s not Qt … it’s iOS world that works in this way !! Even if you develop in fully native iOS with SDK, you can access only to the “virtual” resolution of the screen that it’s always the same for the same devices family and then change the pixel ratio. So, for all iPads, even in fully native iOS you alway get the resolution of 1024x768, and you’ve never access to the real resolution. The funny thing happens with iPhone 6 Plus that it’s very absurd. Because the “virtual” resolution is not even a perfect integer division of the real pixel resolution :-) That’s the strangeness of the iOS world; Welcome ! Ciao, Gianluca. Il giorno 10/apr/2015, alle ore 14:57, Martin Koller ha scritto: > Hi all, > > I'm porting our app to iOS and can already run it on an iPad Air which should > have 2048-by-1536 resolution at 264 pixels per inch. > However Qt (5.4.1) only tells me it has 132 dpi and 1024x768 pixels. > This seems to have something to do with the device pixel ratio which it tells > me is 2 > > Since I'm completely new to the Apple world (and still could manage to run a Qt app > on it - hooray, thanks Qt!!), can somebody tell me if I can do something in > whatever settings or my app to have the full resolution or is it just like that ? > > -- > Best regards/Schöne Grüße > > Martin > A: Because it breaks the logical sequence of discussion > Q: Why is top posting bad? > > () ascii ribbon campaign - against html e-mail > /\ - against proprietary attachments > > Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From kollix at aon.at Fri Apr 10 15:54:19 2015 From: kollix at aon.at (Martin Koller) Date: Fri, 10 Apr 2015 15:54:19 +0200 Subject: [Development] Qt on iOS retina display In-Reply-To: References: <5607634.iOPhhbyb0t@lapi.koller> Message-ID: <3086149.tPmQTjDIUS@lapi.koller> On Friday 10 April 2015 15:09:44 Gianluca wrote: > Hello Martin, > it’s not Qt … it’s iOS world that works in this way !! > Even if you develop in fully native iOS with SDK, you can access only to the “virtual” resolution of the screen that it’s always the same for the same devices family and then change the pixel ratio. > So, for all iPads, even in fully native iOS you alway get the resolution of 1024x768, and you’ve never access to the real resolution. > > The funny thing happens with iPhone 6 Plus that it’s very absurd. Because the “virtual” resolution is not even a perfect integer division of the real pixel resolution :-) > That’s the strangeness of the iOS world; Welcome ! Thanks a lot for the insight! Just wanted to be sure I do not do anything wrong - because I struggled a lot the last days as Qt told me I only have 320x480 pixels available, up until today where I discovered this was just because my cmake file did not explicitely tell XCode that I want to target iPhone/iPad ... -- Best regards/Schöne Grüße Martin A: Because it breaks the logical sequence of discussion Q: Why is top posting bad? () ascii ribbon campaign - against html e-mail /\ - against proprietary attachments Geschenkideen, Accessoires, Seifen, Kulinarisches: www.lillehus.at From olivier at woboq.com Fri Apr 10 15:59:06 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 10 Apr 2015 15:59:06 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <2170873.KJLBzvMtub@rhea> References: <201504081313.19868.marc.mutz@kdab.com> <201504091440.11963.marc.mutz@kdab.com> <2170873.KJLBzvMtub@rhea> Message-ID: <5816807.xbcncm8yZ5@finn> On Friday 10. April 2015 13:38:55 Simon Hausmann wrote: > Yes, over time we will accumulate cruft. We must indeed be very careful what > we put into public header files. A possibility would be to put them in a #if Q_DEPRECATED_SINCE(5,5) #include #endif From thiago.macieira at intel.com Fri Apr 10 17:51:27 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Apr 2015 08:51:27 -0700 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <5527CA08.7080504@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <2817634.s0JSDMOyT1@finn> <5527CA08.7080504@familiesomers.nl> Message-ID: <204099760.JVLb2y1xmd@tjmaciei-mobl4> On Friday 10 April 2015 15:03:04 André Somers wrote: > I do think it needs a bit of work on the documentation side of things to > make it clear that really any QList now behaves as/is a > QByteArrayList. The documentation still says it is a class. For documentation purposes only. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Apr 10 17:51:40 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Apr 2015 08:51:40 -0700 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <5527810E.6090205@theqtcompany.com> References: <201504081313.19868.marc.mutz@kdab.com> <2160476.QqaBeYKDTW@tjmaciei-mobl4> <5527810E.6090205@theqtcompany.com> Message-ID: <4495169.M1tnCL60MQ@tjmaciei-mobl4> On Friday 10 April 2015 09:51:42 Christian Kandeler wrote: > On 04/09/2015 08:51 PM, Thiago Macieira wrote: > > The objective is to make Qt6 QStringList be a typedef to QList, > > not a separate class. > > Uh-oh, that will break all forward declarations in client code... Ok, I hadn't considered that... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Apr 10 17:52:26 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Apr 2015 08:52:26 -0700 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: References: <201504081313.19868.marc.mutz@kdab.com> Message-ID: <3927410.Lb7WnUkCe7@tjmaciei-mobl4> On Friday 10 April 2015 14:00:17 Harri Porten wrote: > Speaking of which: a script binding generator tool I used on Qt 5.5 > chocked on the "internal" QStringList changes. Aren't those Qt 6 > candidates, too? Yes and no. They should be, due to the SIC they introduce. But I couldn't get it fixed any other way... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Apr 10 18:28:02 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Apr 2015 09:28:02 -0700 Subject: [Development] The new headersclean is in Message-ID: <2500160.ALHJcDGujs@tjmaciei-mobl4> As discussed in previous threads. This is just a reminder because the compilation time for anyone using the option -developer-build is now increasing by 25-33%. If you need to bypass this option, pass -no-headersclean to your configure script. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From helio at kde.org Fri Apr 10 21:57:25 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Fri, 10 Apr 2015 16:57:25 -0300 Subject: [Development] Updating of 3rdparty stuff In-Reply-To: References: <3746511.o9TTYlrKsK@tjmaciei-mobl4> <552510F1.8030501@theqtcompany.com> Message-ID: So, no more coments. It's ok to go ahead and update + push to review the ones not already there ? []'s On Wed, Apr 8, 2015 at 2:20 PM, Konstantin Ritt wrote: > Added some comments to your spreadsheet > > Regards, > Konstantin > > 2015-04-08 19:42 GMT+04:00 Helio Chissini de Castro : > >> Hi >> >> I just started a simple spreadsheet on the status of 3rdparty code. >> I enabled the doc to comments. >> >> Here: >> https://docs.google.com/spreadsheets/d/1xOAI87zKy6w7VSvSzQrIA_zeZBLuTgoSmNU-vAXrIhY/edit?usp=sharing >> >> Now need discover the feasibility to do some of them. >> >> []'s Helio >> >> >> On Wed, Apr 8, 2015 at 8:31 AM, Konstantin Ritt >> wrote: >> >>> 2015-04-08 15:28 GMT+04:00 Eirik Aavitsland < >>> eirik.aavitsland at theqtcompany.com>: >>> >>>> >>>> Good stuff, and libpng gets updated to 1.6.17 here >>>> https://codereview.qt-project.org/109973 >>>> >>>> - Eirik Aa. >>>> >>> >>> Someone have to upstream the WinCE and WinRT specific patches to libpng. >>> >>> Konstantin >>> >>> >>> >>>> >>>> On 04/08/2015 10:15 AM, Liang Qi wrote: >>>> > qtimageformats: libwebp 0.4.3 update >>>> > >>>> > https://codereview.qt-project.org/109955 >>>> > https://codereview.qt-project.org/109956 >>>> > >>>> > And checked other 3rdparty: jasper, libmng, libtiff, there is no >>>> update >>>> > from upstream. >>>> > >>>> > After Beta released, I will help to update qt doc and >>>> > https://wiki.qt.io/Third_Party_In_Qt >>>> > >>>> > Regards, >>>> > Liang >>>> > >>>> > >>>> > On 7 April 2015 at 06:56, Thiago Macieira >>> > > wrote: >>>> > >>>> > Any volunteers? >>>> > -- >>>> > Thiago Macieira - thiago.macieira (AT) intel.com < >>>> http://intel.com> >>>> > Software Architect - Intel Open Source Technology Center >>>> > >>>> > _______________________________________________ >>>> > Development mailing list >>>> > Development at qt-project.org >>>> > http://lists.qt-project.org/mailman/listinfo/development >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > http://www.qiliang.net >>>> > >>>> > >>>> > _______________________________________________ >>>> > Development mailing list >>>> > Development at qt-project.org >>>> > http://lists.qt-project.org/mailman/listinfo/development >>>> > >>>> >>>> _______________________________________________ >>>> Development mailing list >>>> Development at qt-project.org >>>> http://lists.qt-project.org/mailman/listinfo/development >>>> >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >>> >>> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Apr 10 22:16:30 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 10 Apr 2015 13:16:30 -0700 Subject: [Development] The new headersclean is in In-Reply-To: <2500160.ALHJcDGujs@tjmaciei-mobl4> References: <2500160.ALHJcDGujs@tjmaciei-mobl4> Message-ID: <1431158.vZHUyleWdh@tjmaciei-mobl4> Oops, it's not in. It was another commit that went in, the one that removed the old headersclean. On Friday 10 April 2015 09:28:02 Thiago Macieira wrote: > As discussed in previous threads. > > This is just a reminder because the compilation time for anyone using the > option -developer-build is now increasing by 25-33%. If you need to bypass > this option, pass -no-headersclean to your configure script. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at theqtcompany.com Sat Apr 11 09:29:25 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Sat, 11 Apr 2015 07:29:25 +0000 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <5816807.xbcncm8yZ5@finn> References: <201504081313.19868.marc.mutz@kdab.com> <201504091440.11963.marc.mutz@kdab.com> <2170873.KJLBzvMtub@rhea>,<5816807.xbcncm8yZ5@finn> Message-ID: <20150411072924.30208085.30530.18917@theqtcompany.com> I think that would be a good compromise. Simon Original Message From: Olivier Goffart Sent: Friday, April 10, 2015 15:56 To: development at qt-project.org Cc: Hausmann Simon Subject: Re: [Development] Are SiCs through #include cleanups considered acceptable? On Friday 10. April 2015 13:38:55 Simon Hausmann wrote: > Yes, over time we will accumulate cruft. We must indeed be very careful what > we put into public header files. A possibility would be to put them in a #if Q_DEPRECATED_SINCE(5,5) #include #endif From kde at carewolf.com Sat Apr 11 11:54:11 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sat, 11 Apr 2015 11:54:11 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <1479808.5qdMParPgn@tjmaciei-mobl4> References: <201504081313.19868.marc.mutz@kdab.com> <1479808.5qdMParPgn@tjmaciei-mobl4> Message-ID: <201504111154.12094.kde@carewolf.com> On Thursday 09 April 2015, Thiago Macieira wrote: > On Thursday 09 April 2015 11:20:30 Frank Osterfeld wrote: > > > My vote obviously goes to allowing them. > > > > I had to fix includes when building client code with 5.5 branch (coming > > from 5.4.1), so this is an actual issue right now, not just a > > theoretical one. I can do more research which headers I needed to > > include, if that’s a help to anyone. > > It's probably the QStringList change. > Or the change from including math.h to cmath in qmath.h, which is source incompatible on QNX, in files where the user depended on the math functions being in the global namespace without including math.h directly themselves. `Allan From marc.mutz at kdab.com Sat Apr 11 14:33:09 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 11 Apr 2015 14:33:09 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <5527BCBA.8070800@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <201504101329.01503.marc.mutz@kdab.com> <5527BCBA.8070800@familiesomers.nl> Message-ID: <201504111433.09704.marc.mutz@kdab.com> On Friday 10 April 2015 14:06:18 André Somers wrote: > Marc Mutz schreef op 10-4-2015 om 13:29: [...] > > For one, you're not supoosed to inherit from value classes. For > > another... Oh, I think that's enough reasons :) > > That a religious argument instead of a technical one. Avoiding undefined behaviour isn't "religious". It's deeply technical. See any C++ text book for why. > It was meant as a serious question. And this was a serious answer. :) > It looks to me like the chosen > alternative is more complex than what was there before, That's the bane of C++ library developers. They get to eat the mud so users can have nice shiny interfaces. In this case, after the change (and its completion) there's only one class that deals with lists of strings and not two. Easier. The user cannot accidentally invoke UB because there's only one class he needs to deal with. Safer. No extra code necessary for generic programming, as QList is fully featured. Easier. Less useless conversions between QList and QStringList. More performant. For us, a major advantage is that we can equip QVector with the same extended API as QStringList, easily. That'd just be the next step. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From rjvbertin at gmail.com Sat Apr 11 14:57:39 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 11 Apr 2015 14:57:39 +0200 Subject: [Development] New Qt 4.8.7 snapshot build is available In-Reply-To: References: Message-ID: <1819942.WfJRWanlAb@portia.local> On Wednesday April 08 2015 13:37:09 Salovaara Akseli wrote: Hi, I see I'm being cited as "René J.V. Bertin" (commit eb55d48d1035d06408ffe73696223464957aa71d) which means I once more ran across a website that doesn't handle input from an OS X client appropriately. That should be "René", of course (e-acute as the last character). R. From marc.mutz at kdab.com Sat Apr 11 16:07:45 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 11 Apr 2015 16:07:45 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <5816807.xbcncm8yZ5@finn> References: <201504081313.19868.marc.mutz@kdab.com> <2170873.KJLBzvMtub@rhea> <5816807.xbcncm8yZ5@finn> Message-ID: <201504111607.45952.marc.mutz@kdab.com> On Friday 10 April 2015 15:59:06 Olivier Goffart wrote: > On Friday 10. April 2015 13:38:55 Simon Hausmann wrote: > > Yes, over time we will accumulate cruft. We must indeed be very careful > > what we put into public header files. > > A possibility would be to put them in a > > #if Q_DEPRECATED_SINCE(5,5) > #include > #endif \me likes -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Sat Apr 11 19:39:09 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 11 Apr 2015 10:39:09 -0700 Subject: [Development] New Qt 4.8.7 snapshot build is available In-Reply-To: <1819942.WfJRWanlAb@portia.local> References: <1819942.WfJRWanlAb@portia.local> Message-ID: <1734309.MvcdhKAE83@tjmaciei-mobl4> On Saturday 11 April 2015 14:57:39 René J.V. Bertin wrote: > On Wednesday April 08 2015 13:37:09 Salovaara Akseli wrote: > > Hi, > > I see I'm being cited as "René J.V. Bertin" (commit > eb55d48d1035d06408ffe73696223464957aa71d) which means I once more ran > across a website that doesn't handle input from an OS X client > appropriately. That should be "René", of course (e-acute as the last > character). Uh... $ curl -I http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-04-07-6/4.8.7-snapshot-2015-04-07-6-all-changes HTTP/1.1 200 OK [...] Content-Type: application/x-troff-man A man page?! Akseli, just rename the file to .txt and this will solve the problem. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jpnurmi at theqtcompany.com Sun Apr 12 10:45:14 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Sun, 12 Apr 2015 08:45:14 +0000 Subject: [Development] QML bindings for native Android controls Message-ID: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> Hello, I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - https://youtu.be/Mo8J-g5XPGQ Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one. Factors that affect the naming: - This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined. - This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior. Credits for the groundwork go to Attila Csipa - http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html - http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html -- J-P Nurmi From coroberti at gmail.com Sun Apr 12 11:03:04 2015 From: coroberti at gmail.com (Robert Iakobashvili) Date: Sun, 12 Apr 2015 12:03:04 +0300 Subject: [Development] QML bindings for native Android controls In-Reply-To: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> Message-ID: On Sun, Apr 12, 2015 at 11:45 AM, Nurmi J-P wrote: > Hello, > > I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - https://youtu.be/Mo8J-g5XPGQ > > Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one. > > Factors that affect the naming: > - This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined. > - This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior. > > Credits for the groundwork go to Attila Csipa > - http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html > - http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html > > -- > J-P Nurmi It looks cool! QtBuzzDroid CuteBuzzDroid jm2c Regards, Robert From robertknight at gmail.com Sun Apr 12 23:25:39 2015 From: robertknight at gmail.com (Robert Knight) Date: Sun, 12 Apr 2015 22:25:39 +0100 Subject: [Development] QML bindings for native Android controls In-Reply-To: References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> Message-ID: > I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - https://youtu.be/Mo8J-g5XPGQ This looks great and IMO the only way to be sure of being able to create a top-tier UX for Android or iOS for an app that is intended to have a native look and feel. Are repositories like this best served living with the other Qt playground repos though? I wonder whether it might be able to gain traction faster if it was on GitHub instead? On 12 April 2015 at 10:03, Robert Iakobashvili wrote: > On Sun, Apr 12, 2015 at 11:45 AM, Nurmi J-P wrote: >> Hello, >> >> I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - https://youtu.be/Mo8J-g5XPGQ >> >> Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one. >> >> Factors that affect the naming: >> - This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined. >> - This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior. >> >> Credits for the groundwork go to Attila Csipa >> - http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html >> - http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html >> >> -- >> J-P Nurmi > > It looks cool! > > QtBuzzDroid > CuteBuzzDroid > > jm2c > > Regards, > Robert > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Sun Apr 12 23:56:54 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 12 Apr 2015 14:56:54 -0700 Subject: [Development] Fwd: [C++ Leaders] Please share: CppCon Call for Submission Message-ID: <1855738.txsCEefZ12@tjmaciei-mobl4> [Please don't reply to both lists] ---------- Forwarded Message ---------- Please share with your members that CppCon released its Call for Submission for this fall¹s conference. http://cppcon.org/call-for-submissions-2015/ If you have something interesting to say to the C++ community, this is your chance. The submission deadline is May 22 and the conference is September 20-25. I would really like to see Qt represented. Please let me know if you have an questions or ideas you'd like to discuss. Jon -- Please keep current: ---==> http://isocpp.org/wiki/faq/user-groups-worldwide <==--- Feel free to forward this to any local C++ community leader that you’d like to see join our list. ----------------------------------------- -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 From berkayelbir at gmail.com Mon Apr 13 07:43:05 2015 From: berkayelbir at gmail.com (Berkay Elbir) Date: Mon, 13 Apr 2015 08:43:05 +0300 Subject: [Development] Qt installer framework exe file Message-ID: Hello all; I am using Qt installer 2.0.0. But I can not run my installer.exe as an Admin. I updated my config.xml file like this : TargetDir @ but problem is still exist. Installer crashes when I do not run it as an admin. Thanks in advance, Berkay Elbir -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Mon Apr 13 09:05:06 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Mon, 13 Apr 2015 09:05:06 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <201504111433.09704.marc.mutz@kdab.com> References: <201504081313.19868.marc.mutz@kdab.com> <201504101329.01503.marc.mutz@kdab.com> <5527BCBA.8070800@familiesomers.nl> <201504111433.09704.marc.mutz@kdab.com> Message-ID: <552B6AA2.8070802@familiesomers.nl> Marc Mutz schreef op 11-4-2015 om 14:33: > On Friday 10 April 2015 14:06:18 André Somers wrote: >> Marc Mutz schreef op 10-4-2015 om 13:29: > [...] >>> For one, you're not supoosed to inherit from value classes. For >>> another... Oh, I think that's enough reasons :) >> That a religious argument instead of a technical one. > Avoiding undefined behaviour isn't "religious". It's deeply technical. See any > C++ text book for why. Are you saying that Qt was (and still is) sporting classes that exhibit UB? Really? I guess what you mean with "you're not supoosed to inherit from value classes" is that you should not inherit from classes that don't have a virtual destructor, right? It was my understanding that it is fine to do so, as long as you don't add any member variables. "Any C++ textbook" doesn't explain what's wrong with that, but if you'd like to enlighten me (and perhaps others): please do so. You've put me on another interesting track I learned a lot from before (again: thank you for that!), so why not a second time... >> It was meant as a serious question. > And this was a serious answer. :) > >> It looks to me like the chosen >> alternative is more complex than what was there before, > That's the bane of C++ library developers. They get to eat the mud so users > can have nice shiny interfaces. In this case, after the change (and its > completion) there's only one class that deals with lists of strings and not > two. Easier. The user cannot accidentally invoke UB because there's only one > class he needs to deal with. Safer. No extra code necessary for generic > programming, as QList is fully featured. Easier. Less useless > conversions between QList and QStringList. More performant. > > For us, a major advantage is that we can equip QVector with the same > extended API as QStringList, easily. That'd just be the next step. > I get all of these except for the UB/Safer argument. And yes, they are good arguments to do this, Olivier already provided a convincing use case. I still don't like that the documentation is now pretending that QList is still a class though: as there are good arguments to introduce this change, why lie to the user about it? André From announce at qt-project.org Mon Apr 13 11:06:51 2015 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Mon, 13 Apr 2015 10:06:51 +0100 Subject: [Development] [Announce] Qt Project Security Advisory - Multiple Vulnerabilities in Qt Image Format Handling Message-ID: Qt Project Security Advisory ---------------------------- Title: Multiple Vulnerabilities in Qt Image Format Handling Risk Rating: High CVE: CVE-2015-1858, CVE-2015-1859, CVE-2015-1860 Platforms: All Modules: QtBase Versions: Qt 4.8.6 and earlier, Qt 5.4.1 and earlier Author: Richard J. Moore Date: 12th April 2015 Overview -------- Due to two recent vulnerabilities identified in the built-in image format handling code, it was decided that this area required further testing to determine if further issues remained. Fuzzing using afl-fuzz located a number of issues in the handling of BMP, ICO and GIF files. The issues exposed included denial of service and buffer overflows leading to heap corruption. It is possible the latter could be used to perform remote code execution. Details ------- It is possible to construct invalid BMP, ICO and GIF images that lead to buffer overflows. The CVEs have been assigned as follows: CVE-2015-1858 BMP vulnerability CVE-2015-1859 ICO vulnerability CVE-2015-1860 GIF vulnerability Impact ------ Denial of service and potentially remote code execution. Workaround ---------- None Solution -------- Upgrade to Qt 5.5 once released or apply the patches below: For Qt 5.0 to 5.4: https://codereview.qt-project.org/#/c/108312/ https://codereview.qt-project.org/#/c/108248/ For Qt 4.8: https://codereview.qt-project.org/#/c/108474/ https://codereview.qt-project.org/#/c/108475/ The fixes will also be included in Qt 4.8.7 and 5.4.2. Credits ======= These issues were discovered by Richard Moore, and were addressed by Eirik Aavitsland. While this advisory was being prepared, two of the issues were also identified by Fabian Vogt. Thanks to Redhat for assigning the CVEs. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From karsten.heimrich at digia.com Mon Apr 13 12:09:20 2015 From: karsten.heimrich at digia.com (Karsten Heimrich) Date: Mon, 13 Apr 2015 12:09:20 +0200 Subject: [Development] Qt installer framework exe file In-Reply-To: References: Message-ID: <552B95D0.4010907@digia.com> On 13.04.2015 07:43, Berkay Elbir wrote: > Hello all; > > I am using Qt installer 2.0.0. But I can not run my installer.exe as > an Admin. > I updated my config.xml file like this : > > TargetDir @ That cannot fix your issue, it's not used on Windows. > but problem is still exist. Installer crashes when I do not run it as > an admin. If something keeps crashing for you, you should report it here: https://bugreports.qt.io Please attach as much as possible information, though the best would a crashing minimal example. -- Karsten -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Mon Apr 13 13:24:46 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 13 Apr 2015 13:24:46 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <552B6AA2.8070802@familiesomers.nl> References: <201504081313.19868.marc.mutz@kdab.com> <201504111433.09704.marc.mutz@kdab.com> <552B6AA2.8070802@familiesomers.nl> Message-ID: <201504131324.46806.marc.mutz@kdab.com> On Monday 13 April 2015 09:05:06 André Somers wrote: > Marc Mutz schreef op 11-4-2015 om 14:33: > > On Friday 10 April 2015 14:06:18 André Somers wrote: > >> Marc Mutz schreef op 10-4-2015 om 13:29: > > [...] > > > >>> For one, you're not supoosed to inherit from value classes. For > >>> another... Oh, I think that's enough reasons :) > >> > >> That a religious argument instead of a technical one. > > > > Avoiding undefined behaviour isn't "religious". It's deeply technical. > > See any C++ text book for why. > > Are you saying that Qt was (and still is) sporting classes that exhibit > UB? Really? > > I guess what you mean with "you're not supoosed to inherit from value > classes" is that you should not inherit from classes that don't have a > virtual destructor, right? Correct. > It was my understanding that it is fine to do > so, as long as you don't add any member variables. What if the derived class' dtor releases some resource that's not explicitly managed in the base class? E.g. a widget could save state to settings. In most implementations, what actually happens is that the derived part of the destructor isn't called when the object is deleted through a pointer to the base class. But the standard says it's UB (N3797 [expr.delete]/3). Nothing mentioned about adding member variables or not. And the danger in _any_ UB these days is that compiler writers are getting more and more aggressive in exploiting the fact that UB cannot happen in a correct program, and optimize out code paths that exhibit UB. > "Any C++ textbook" > doesn't explain what's wrong with that, I don't know about Stroustrup's book, but Effective C++ has an item about it (at least -Weffc++ warns about the construct), C++ Coding Standards has one, and Exceptional C++ coined the current guideline: "a base class dtor should be public and virtual or else protected and non-virtual". Thinking in C++, the book I learned C++ from, at least mentions that it may cause memory leaks. It doesn't say it's UB, but I think it's a pre-standard book if it won an award in 1996. > but if you'd like to enlighten > me (and perhaps others): please do so. You've put me on another > interesting track I learned a lot from before (again: thank you for > that!), so why not a second time... HTH, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From jpnurmi at theqtcompany.com Mon Apr 13 13:21:08 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 13 Apr 2015 11:21:08 +0000 Subject: [Development] QML bindings for native Android controls In-Reply-To: References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> Message-ID: <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> On 12 Apr 2015, at 11:03, Robert Iakobashvili wrote: > On Sun, Apr 12, 2015 at 11:45 AM, Nurmi J-P wrote: >> Hello, >> >> I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - https://youtu.be/Mo8J-g5XPGQ >> >> Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one. >> >> Factors that affect the naming: >> - This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined. >> - This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior. >> >> Credits for the groundwork go to Attila Csipa >> - http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html >> - http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html >> >> -- >> J-P Nurmi > > It looks cool! > > QtBuzzDroid > CuteBuzzDroid > > jm2c > > Regards, > Robert Thanks for the ideas, keep it coming! :) We should probably follow the guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt -- J-P Nurmi From jpnurmi at theqtcompany.com Mon Apr 13 14:00:06 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 13 Apr 2015 12:00:06 +0000 Subject: [Development] QML bindings for native Android controls In-Reply-To: References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> Message-ID: <0F585AFA-DA59-4A79-B355-F2F1296DB25B@theqtcompany.com> On 12 Apr 2015, at 23:25, Robert Knight wrote: >> I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - https://youtu.be/Mo8J-g5XPGQ > > This looks great and IMO the only way to be sure of being able to > create a top-tier UX for Android or iOS for an app that is intended to > have a native look and feel. Indeed. UIs have come a long way since the days of Windows 95 and others where it was sufficient to draw buttons and checkboxes a bit differently. These days, UIs are full of little transitions and effects. When those things are missing or slightly off, the UI feels broken. > Are repositories like this best served living with the other Qt > playground repos though? I wonder whether it might be able to gain > traction faster if it was on GitHub instead? I’m afraid it has to be covered by the Qt CLA ie. hosted by the Qt project. -- J-P Nurmi From harri at mpaja.com Mon Apr 13 14:13:23 2015 From: harri at mpaja.com (Harri Pasanen) Date: Mon, 13 Apr 2015 14:13:23 +0200 Subject: [Development] QML bindings for native Android controls In-Reply-To: <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> Message-ID: <552BB2E3.4020003@mpaja.com> Name candidates: QML-Droid or QDroid Btw, can QML do layouting of Android widgets, or is that left for the android layout engine? Harri On 13/04/2015 13:21, Nurmi J-P wrote: > On 12 Apr 2015, at 11:03, Robert Iakobashvili wrote: > >> On Sun, Apr 12, 2015 at 11:45 AM, Nurmi J-P wrote: >>> Hello, >>> >>> I'd like to request a playground repository for the former hackathon project of mine: QML bindings for native Android controls - https://youtu.be/Mo8J-g5XPGQ >>> >>> Before proceeding to a formal request, the baby needs a name. I was hoping you could help me choose one. >>> >>> Factors that affect the naming: >>> - This is not cross-platform, but highly Android specific. The convenience of QML and and full access to the underlying platform APIs combined. >>> - This is not integrated with Qt Quick. Only QML engine & native controls (via JNI) are used. Gives great performance with 100% perfect native behavior. >>> >>> Credits for the groundwork go to Attila Csipa >>> - http://achipa.blogspot.no/2014/11/qml-wrappers-for-native-android.html >>> - http://achipa.blogspot.no/2014/11/native-ui-in-qt-on-android-without.html >>> >>> -- >>> J-P Nurmi >> It looks cool! >> >> QtBuzzDroid >> CuteBuzzDroid >> >> jm2c >> >> Regards, >> Robert > Thanks for the ideas, keep it coming! :) We should probably follow the guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt > > -- > J-P Nurmi > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jeremy.laine at m4x.org Mon Apr 13 14:50:22 2015 From: jeremy.laine at m4x.org (=?UTF-8?B?SmVyZW15IExhaW7DqQ==?=) Date: Mon, 13 Apr 2015 14:50:22 +0200 Subject: [Development] QML bindings for native Android controls In-Reply-To: <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> Message-ID: <552BBB8E.80801@m4x.org> On 04/13/2015 01:21 PM, Nurmi J-P wrote: > Thanks for the ideas, keep it coming! :) We should probably follow the > guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt How about just "android-controls", which would become "qt-android-controls" if the project graduates from playground? Cheers, Jeremy From jpnurmi at theqtcompany.com Mon Apr 13 14:58:42 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 13 Apr 2015 12:58:42 +0000 Subject: [Development] QML bindings for native Android controls In-Reply-To: <552BB2E3.4020003@mpaja.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BB2E3.4020003@mpaja.com> Message-ID: <03F75EFF-404C-44FB-90C7-949A55054ABA@theqtcompany.com> > On 13 Apr 2015, at 14:13, Harri Pasanen wrote: > > Name candidates: QML-Droid or QDroid Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories? http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt > Btw, can QML do layouting of Android widgets, or is that left for the > android layout engine? So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same. -- J-P Nurmi From jpnurmi at theqtcompany.com Mon Apr 13 15:46:07 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 13 Apr 2015 13:46:07 +0000 Subject: [Development] QML bindings for native Android controls In-Reply-To: <552BBB8E.80801@m4x.org> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BBB8E.80801@m4x.org> Message-ID: <9012D978-19F1-4959-97BB-94F07DDE8BAB@theqtcompany.com> On 13 Apr 2015, at 14:50, Jeremy Lainé wrote: > On 04/13/2015 01:21 PM, Nurmi J-P wrote: >> Thanks for the ideas, keep it coming! :) We should probably follow the >> guidelines: https://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt > > > How about just "android-controls", which would become > "qt-android-controls" if the project graduates from playground? I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. -- J-P Nurmi From harri at mpaja.com Mon Apr 13 15:54:10 2015 From: harri at mpaja.com (Harri Pasanen) Date: Mon, 13 Apr 2015 15:54:10 +0200 Subject: [Development] QML bindings for native Android controls In-Reply-To: <03F75EFF-404C-44FB-90C7-949A55054ABA@theqtcompany.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BB2E3.4020003@mpaja.com> <03F75EFF-404C-44FB-90C7-949A55054ABA@theqtcompany.com> Message-ID: <552BCA82.8030407@mpaja.com> On 13/04/2015 14:58, Nurmi J-P wrote: >> >On 13 Apr 2015, at 14:13, Harri Pasanen wrote: >> > >> >Name candidates: QML-Droid or QDroid > Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories? > > http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt > How about then qml-native ? I would give a hint that it is somewhat akin to react-native, and allows for migration to other targets while keeping the name. So at least in theory it could target ios, windows phone as well... Harri From akseli.salovaara at theqtcompany.com Mon Apr 13 15:59:51 2015 From: akseli.salovaara at theqtcompany.com (Salovaara Akseli) Date: Mon, 13 Apr 2015 13:59:51 +0000 Subject: [Development] New Qt 4.8.7 snapshot build is available In-Reply-To: <1734309.MvcdhKAE83@tjmaciei-mobl4> References: <1819942.WfJRWanlAb@portia.local> <1734309.MvcdhKAE83@tjmaciei-mobl4> Message-ID: > On Saturday 11 April 2015 14:57:39 René J.V. Bertin wrote: > > On Wednesday April 08 2015 13:37:09 Salovaara Akseli wrote: > > > > Hi, > > > > I see I'm being cited as "René J.V. Bertin" (commit > > eb55d48d1035d06408ffe73696223464957aa71d) which means I once more > ran > > across a website that doesn't handle input from an OS X client > > appropriately. That should be "René", of course (e-acute as the last > > character). > > Uh... > > $ curl -I http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-04-07-6/4.8.7- > snapshot-2015-04-07-6-all-changes > HTTP/1.1 200 OK > [...] > Content-Type: application/x-troff-man > > A man page?! > > Akseli, just rename the file to .txt and this will solve the problem. > http://download.qt.io/snapshots/qt/4.8/4.8.7/2015-04-07-6/4.8.7-snapshot-2015-04-07-6-all-changes.txt > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Mon Apr 13 22:11:51 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 13 Apr 2015 22:11:51 +0200 Subject: [Development] New Qt 4.8.7 snapshot build is available In-Reply-To: References: Message-ID: <1594665.SOU9ke177Z@portia.local> On Wednesday April 08 2015 13:37:09 Salovaara Akseli wrote: Hi, Trying to build 4.8.7 on Linux using the debian packaging glue for 4.8.6 I'm running into a failure configuring postgresql: ./configure: 1: ./configure: filterIncludePath: not found ./configure: 1: ./configure: filterLibraryPath: not found PostgreSQL auto-detection... () make[2]: Entering directory `/build/buildd/qt4-x11-4.8.7+20150407.6+dfsg-1ubuntu1-rjvb/config.tests/unix/psql' g++ -c -m64 -pipe -O2 -Wall -W -I../../../mkspecs/linux-g++-64 -I. -I/usr/include/freetype2 -o psql.o psql.cpp psql.cpp:42:22: fatal error: libpq-fe.h: No such file or directory #include "libpq-fe.h" ^ compilation terminated. make[2]: *** [psql.o] Error 1 make[2]: Leaving directory `/build/buildd/qt4-x11-4.8.7+20150407.6+dfsg-1ubuntu1-rjvb/config.tests/unix/psql' PostgreSQL disabled. PostgreSQL support cannot be enabled due to functionality tests! Turn on verbose messaging (-v) to ./configure to see the final report. If you believe this message is in error you may use the continue switch (-continue) to ./configure to continue. make[1]: *** [override_dh_auto_configure] Error 101 make[1]: Leaving directory `/build/buildd/qt4-x11-4.8.7+20150407.6+dfsg-1ubuntu1-rjvb' make: *** [build-arch] Error 2 The culprit is probably the failure to find filterIncludePath and filterLibraryPath . Where are those supposed to be found? R. From thiago.macieira at intel.com Mon Apr 13 22:23:29 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 13 Apr 2015 13:23:29 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <4456418.dPheNchoCU@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <13432049.x8zJeZaAJF@finn> <4456418.dPheNchoCU@tjmaciei-mobl4> Message-ID: <2013586.fJmF8rFDf5@tjmaciei-mobl4> On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote: > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote: > > > Finally, note what happens if there's a thread trying to deliver events > > > *while* QCoreApplication is being shut down: notifyInternal() is > > > probably > > > dereferencing a dangling pointer. > > > > Good point. > > But one might argue that thread should be finished before the > > QCoreApplication is destroyed. > > Yeah, that sounds like the solution, but just look at both attempts to cause > QProcessManager's thread to exit: > > https://codereview.qt-project.org/60586 > https://codereview.qt-project.org/102526 > > For QtDBus, I could hook to QCoreApplication's destruction, close the > connections, activate the pending replies with a Disconnected error, and > stop the thread. I'd just rather not do it, if it weren't required. Hi everyone Albert has just told me that this is also hitting now KUniqueApplication with the new QtDBus changes. The reason is that the auxiliary thread isn't processing events before QCoreApplication is created, so no D-Bus calls complete. In fact, I'm pretty sure this causes the auxiliary thread to go on a busy-wait (100% CPU usage) because it registers socket notifiers that become readable, but never reads from them. I'd like some opinions on whether we should try this or not. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Apr 14 01:53:11 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 13 Apr 2015 16:53:11 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <2013586.fJmF8rFDf5@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <4456418.dPheNchoCU@tjmaciei-mobl4> <2013586.fJmF8rFDf5@tjmaciei-mobl4> Message-ID: <2292968.IlfG8VVKbS@tjmaciei-mobl4> On Monday 13 April 2015 13:23:29 Thiago Macieira wrote: > On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote: > > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote: > > > > Finally, note what happens if there's a thread trying to deliver > > > > events > > > > *while* QCoreApplication is being shut down: notifyInternal() is > > > > probably > > > > dereferencing a dangling pointer. > > > > > > Good point. > > > But one might argue that thread should be finished before the > > > QCoreApplication is destroyed. > > > > Yeah, that sounds like the solution, but just look at both attempts to > > cause QProcessManager's thread to exit: > > > > https://codereview.qt-project.org/60586 > > https://codereview.qt-project.org/102526 > > > > For QtDBus, I could hook to QCoreApplication's destruction, close the > > connections, activate the pending replies with a Disconnected error, and > > stop the thread. I'd just rather not do it, if it weren't required. > > Hi everyone > > Albert has just told me that this is also hitting now KUniqueApplication > with the new QtDBus changes. The reason is that the auxiliary thread isn't > processing events before QCoreApplication is created, so no D-Bus calls > complete. In fact, I'm pretty sure this causes the auxiliary thread to go > on a busy-wait (100% CPU usage) because it registers socket notifiers that > become readable, but never reads from them. > > I'd like some opinions on whether we should try this or not. https://codereview.qt-project.org/110325 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mandeepsandhu.chd at gmail.com Tue Apr 14 02:17:51 2015 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 13 Apr 2015 17:17:51 -0700 Subject: [Development] No Change-Id being generated for commit message In-Reply-To: <1612553.gz43JRgcEI@tjmaciei-mobl4> References: <1612553.gz43JRgcEI@tjmaciei-mobl4> Message-ID: > > It's supposed to contain the text that the editor was last launched with. If > you tried to make a commit and didn't save anything, that's what you'll see in > that file. Hmm...probably thats what happened (I don't remember exactly how or when, but I might have tried to abort a commit by simply quitting the editor without editing the commit message). Thanks for your help. -mandeep > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Apr 14 06:12:58 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 13 Apr 2015 21:12:58 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <2013586.fJmF8rFDf5@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <4456418.dPheNchoCU@tjmaciei-mobl4> <2013586.fJmF8rFDf5@tjmaciei-mobl4> Message-ID: <1687975.JCetyqtL7d@tjmaciei-mobl4> On Monday 13 April 2015 13:23:29 Thiago Macieira wrote: > On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote: > > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote: > > > > Finally, note what happens if there's a thread trying to deliver > > > > events > > > > *while* QCoreApplication is being shut down: notifyInternal() is > > > > probably > > > > dereferencing a dangling pointer. > > > > > > Good point. > > > But one might argue that thread should be finished before the > > > QCoreApplication is destroyed. > > > > Yeah, that sounds like the solution, but just look at both attempts to > > cause QProcessManager's thread to exit: > > > > https://codereview.qt-project.org/60586 > > https://codereview.qt-project.org/102526 > > > > For QtDBus, I could hook to QCoreApplication's destruction, close the > > connections, activate the pending replies with a Disconnected error, and > > stop the thread. I'd just rather not do it, if it weren't required. > > Hi everyone > > Albert has just told me that this is also hitting now KUniqueApplication > with the new QtDBus changes. The reason is that the auxiliary thread isn't > processing events before QCoreApplication is created, so no D-Bus calls > complete. In fact, I'm pretty sure this causes the auxiliary thread to go > on a busy-wait (100% CPU usage) because it registers socket notifiers that > become readable, but never reads from them. > > I'd like some opinions on whether we should try this or not. Note another problem: if a thread is running and delivering events while the QCoreApplication gets destroyed, the application will have several race conditions: 1) data races accessing QCoreApplicationPrivate::is_app_closing 2) TOCTOU race in QCoreApplication::sendEvent for the existence of QCoreApplication So I have to ask: do we NEED to use QCoreApplication::notify() virtual outside the main thread? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mathias at taschenorakel.de Tue Apr 14 08:33:06 2015 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Tue, 14 Apr 2015 08:33:06 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <4495169.M1tnCL60MQ@tjmaciei-mobl4> References: <201504081313.19868.marc.mutz@kdab.com> <2160476.QqaBeYKDTW@tjmaciei-mobl4> <5527810E.6090205@theqtcompany.com> <4495169.M1tnCL60MQ@tjmaciei-mobl4> Message-ID: <552CB4A2.2000500@taschenorakel.de> Am 10.04.2015 um 17:51 schrieb Thiago Macieira: > On Friday 10 April 2015 09:51:42 Christian Kandeler wrote: >> On 04/09/2015 08:51 PM, Thiago Macieira wrote: >>> The objective is to make Qt6 QStringList be a typedef to QList, >>> not a separate class. >> >> Uh-oh, that will break all forward declarations in client code... > > Ok, I hadn't considered that... > So we finally have reached the turning point at which we have no chance but to make C++11 mandatory for public Qt headers: class QStringList : public QList { public: using QList::QList; }; :-) Ciao, Mathias From mathias at taschenorakel.de Tue Apr 14 08:36:14 2015 From: mathias at taschenorakel.de (Mathias Hasselmann) Date: Tue, 14 Apr 2015 08:36:14 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <204099760.JVLb2y1xmd@tjmaciei-mobl4> References: <201504081313.19868.marc.mutz@kdab.com> <2817634.s0JSDMOyT1@finn> <5527CA08.7080504@familiesomers.nl> <204099760.JVLb2y1xmd@tjmaciei-mobl4> Message-ID: <552CB55E.300@taschenorakel.de> Am 10.04.2015 um 17:51 schrieb Thiago Macieira: > On Friday 10 April 2015 15:03:04 André Somers wrote: >> I do think it needs a bit of work on the documentation side of things to >> make it clear that really any QList now behaves as/is a >> QByteArrayList. The documentation still says it is a class. > > For documentation purposes only. > Is lying to the user really the proper approach for documentation? I'd totally prefer if the documentation tells the user that special methods are available for QList specializations. Ciao, Mathias From Lars.Knoll at theqtcompany.com Tue Apr 14 08:44:11 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 14 Apr 2015 06:44:11 +0000 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <552CB55E.300@taschenorakel.de> References: <201504081313.19868.marc.mutz@kdab.com> <2817634.s0JSDMOyT1@finn> <5527CA08.7080504@familiesomers.nl> <204099760.JVLb2y1xmd@tjmaciei-mobl4> <552CB55E.300@taschenorakel.de> Message-ID: On 14/04/15 08:36, "Mathias Hasselmann" wrote: >Am 10.04.2015 um 17:51 schrieb Thiago Macieira: >> On Friday 10 April 2015 15:03:04 André Somers wrote: >>> I do think it needs a bit of work on the documentation side of things >>>to >>> make it clear that really any QList now behaves as/is a >>> QByteArrayList. The documentation still says it is a class. >> >> For documentation purposes only. >> >Is lying to the user really the proper approach for documentation? I'd >totally prefer if the documentation tells the user that special methods >are available for QList specializations. Agree. Currently I believe qdoc can’t handle template specializations properly though. So we’ll need to fix that part first. In the meantime, we could add a sentence inside the QByteArrayList docs saying that it’s in reality a typedef. Cheers, Lars From rjvbertin at gmail.com Tue Apr 14 09:46:09 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 14 Apr 2015 09:46:09 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <1687975.JCetyqtL7d@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2013586.fJmF8rFDf5@tjmaciei-mobl4> <1687975.JCetyqtL7d@tjmaciei-mobl4> Message-ID: <2661061.QAjlDNCRcm@patux> On Monday April 13 2015 21:12:58 Thiago Macieira wrote: Hello, >> I'd like some opinions on whether we should try this or not. > >Note another problem: if a thread is running and delivering events while the >QCoreApplication gets destroyed, the application will have several race >conditions: > 1) data races accessing QCoreApplicationPrivate::is_app_closing > 2) TOCTOU race in QCoreApplication::sendEvent for the existence of >QCoreApplication > >So I have to ask: do we NEED to use QCoreApplication::notify() virtual outside >the main thread? Not that I have any intimate knowledge of the inner workings you're discussing, but this sounds like the kind of situation ObjC avoids with its retain/release scheme. Would it help if you somehow imposed such a scheme on central classes like QCoreApplication? R. From rjvbertin at gmail.com Tue Apr 14 10:00:47 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 14 Apr 2015 10:00:47 +0200 Subject: [Development] New Qt 4.8.7 snapshot build is available In-Reply-To: <1594665.SOU9ke177Z@portia.local> References: <1594665.SOU9ke177Z@portia.local> Message-ID: <2482175.u3KnciaifG@patux> On Monday April 13 2015 22:11:51 René J.V. Bertin wrote: >The culprit is probably the failure to find filterIncludePath and filterLibraryPath . Where are those supposed to be found? I think I found my answer: http://git.buildroot.net/buildroot/diff/?id=b37f428bacdca7859fb0b678ec9658cbccaa359a (and a bug report thus seems to be unnecessary). R. From paul.tvete at theqtcompany.com Tue Apr 14 10:14:08 2015 From: paul.tvete at theqtcompany.com (Paul Olav Tvete) Date: Tue, 14 Apr 2015 10:14:08 +0200 Subject: [Development] Are SiCs through #include cleanups considered acceptable? In-Reply-To: <552CB4A2.2000500@taschenorakel.de> References: <201504081313.19868.marc.mutz@kdab.com> <4495169.M1tnCL60MQ@tjmaciei-mobl4> <552CB4A2.2000500@taschenorakel.de> Message-ID: <2645492.vLgdx53vR6@dragaera> On Tuesday 14. April 2015 08.33.06 Mathias Hasselmann wrote: > So we finally have reached the turning point at which we have no chance > but to make C++11 mandatory for public Qt headers: You might think you're trolling, but I think requiring C++11 would be an excellent goal for Qt 6. - Paul From simon.hausmann at theqtcompany.com Tue Apr 14 16:26:19 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Tue, 14 Apr 2015 16:26:19 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <1687975.JCetyqtL7d@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2013586.fJmF8rFDf5@tjmaciei-mobl4> <1687975.JCetyqtL7d@tjmaciei-mobl4> Message-ID: <2685353.DbnL0SWIz8@rhea> On Monday 13. April 2015 21.12.58 Thiago Macieira wrote: > On Monday 13 April 2015 13:23:29 Thiago Macieira wrote: > > On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote: > > > On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote: > > > > > Finally, note what happens if there's a thread trying to deliver > > > > > events > > > > > *while* QCoreApplication is being shut down: notifyInternal() is > > > > > probably > > > > > dereferencing a dangling pointer. > > > > > > > > Good point. > > > > But one might argue that thread should be finished before the > > > > QCoreApplication is destroyed. > > > > > > Yeah, that sounds like the solution, but just look at both attempts to > > > cause QProcessManager's thread to exit: > > > > > > https://codereview.qt-project.org/60586 > > > https://codereview.qt-project.org/102526 > > > > > > For QtDBus, I could hook to QCoreApplication's destruction, close the > > > connections, activate the pending replies with a Disconnected error, and > > > stop the thread. I'd just rather not do it, if it weren't required. > > > > Hi everyone > > > > Albert has just told me that this is also hitting now KUniqueApplication > > with the new QtDBus changes. The reason is that the auxiliary thread isn't > > processing events before QCoreApplication is created, so no D-Bus calls > > complete. In fact, I'm pretty sure this causes the auxiliary thread to go > > on a busy-wait (100% CPU usage) because it registers socket notifiers that > > become readable, but never reads from them. > > > > I'd like some opinions on whether we should try this or not. > > Note another problem: if a thread is running and delivering events while the > QCoreApplication gets destroyed, the application will have several race > conditions: > 1) data races accessing QCoreApplicationPrivate::is_app_closing > 2) TOCTOU race in QCoreApplication::sendEvent for the existence of > QCoreApplication > > So I have to ask: do we NEED to use QCoreApplication::notify() virtual > outside the main thread? The documentation clearly says so, and therefore it is not entirely unlikely that somebody relies on that behavior :( (as much as I dislike it :) Would it be feasible to make event loops started before and after QCoreApplication truly independent from notify() but all the others "join" in? Simon From thiago.macieira at intel.com Tue Apr 14 16:28:03 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 07:28:03 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <2661061.QAjlDNCRcm@patux> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <1687975.JCetyqtL7d@tjmaciei-mobl4> <2661061.QAjlDNCRcm@patux> Message-ID: <21739612.kxajhZWg1P@tjmaciei-mobl4> On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote: > On Monday April 13 2015 21:12:58 Thiago Macieira wrote: > > Hello, > > >> I'd like some opinions on whether we should try this or not. > > > >Note another problem: if a thread is running and delivering events while > >the QCoreApplication gets destroyed, the application will have several > >race> > >conditions: > > 1) data races accessing QCoreApplicationPrivate::is_app_closing > > 2) TOCTOU race in QCoreApplication::sendEvent for the existence of > > > >QCoreApplication > > > >So I have to ask: do we NEED to use QCoreApplication::notify() virtual > >outside the main thread? > > Not that I have any intimate knowledge of the inner workings you're > discussing, but this sounds like the kind of situation ObjC avoids with its > retain/release scheme. Would it help if you somehow imposed such a scheme > on central classes like QCoreApplication? I don't know how to answer this since I have no idea what retain/release is and does. Can you explain? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Apr 14 16:36:49 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 07:36:49 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <2685353.DbnL0SWIz8@rhea> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <1687975.JCetyqtL7d@tjmaciei-mobl4> <2685353.DbnL0SWIz8@rhea> Message-ID: <3858276.pGIsscorMC@tjmaciei-mobl4> On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote: > Would it be feasible to make event loops started before and after > QCoreApplication truly independent from notify() but all the others "join" > in? Not without race conditions. if (self) return self->notify(object, event); // deliver directly return doNotify(object, event); What happens if the QCoreApplication gets deleted between the first and second lines? In fact, what happens if it begins destruction? That's totally in the land of undefined behaviour. I'm not introducing the race condition, it already exists: inline bool QCoreApplication::sendEvent(QObject *receiver, QEvent *event) { if (event) event->spont = false; return self ? self- >notifyInternal(receiver, event) : false; } I only three possible outcomes here: 1) ignore the problem and document it that Qt event delivery is unsafe if you have any threads running by the time QCoreApplication gets deleted 2) fix it by not passing through notify() outside the main thread. That's the solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6. 3) introduce a global, recursive QReadWriteLock that prevents QCoreApplication destruction from concluding. Note that it cannot prevent the destruction from starting, so the virtual table may still change and we are still in undefined behaviour by calling a virtual after the object began destructing. I recommend against 1 and 3 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Apr 14 16:56:19 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 14 Apr 2015 16:56:19 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <21739612.kxajhZWg1P@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2661061.QAjlDNCRcm@patux> <21739612.kxajhZWg1P@tjmaciei-mobl4> Message-ID: <5464147.1FYiBlrVPZ@patux> On Tuesday April 14 2015 07:28:03 Thiago Macieira wrote: >On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote: >I don't know how to answer this since I have no idea what retain/release is >and does. Can you explain? OK, sorry, I thought you had sufficient knowledge of ObjC programming (from before ARC made the whole retain/release mechanism largely transparent). Simplifying things a bit, ObjC uses a refcounting mechanism to keep track of whether objects are in use or not. It also uses allocation pools (NSAutoreleasePool) which contain the list of all objects allocated since they were created; these are created automatically when you enter a runloop for instance. Unused objects are deleted only when the pool is released (or drained), and it is at that time that their "dealloc" method is called. The effect is not unlike that of QObject::deleteLater(). I'm not sure exactly what happens with objects in the pool that are still in use; I presume the pool actually hangs around until all its elements have been released. There are some evident drawbacks to a scheme that discourages immediate deletion (and you're obliged to provide an NSAutoreleasePool in situations where they're not created for you) but it provides much better protection against things like pending events that get delivered after the destination object was deleted (cf. https://bugreports.qt.io/browse/QTBUG-44343). It's a pity ObjC is so intricately linked to OS X, because from a few quick attempts it seems to be perfectly possible to use an ObjC++ wrapper class to extend the retain/release scheme to C++ classes. Is this clear enough? R. From thiago.macieira at intel.com Tue Apr 14 17:27:57 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 08:27:57 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <5464147.1FYiBlrVPZ@patux> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <21739612.kxajhZWg1P@tjmaciei-mobl4> <5464147.1FYiBlrVPZ@patux> Message-ID: <14097820.igoXrKyRLV@tjmaciei-mobl4> On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote: [cut] > ObjC is so intricately linked to OS X, because from a few quick attempts it > seems to be perfectly possible to use an ObjC++ wrapper class to extend the > retain/release scheme to C++ classes. > > Is this clear enough? Yes, thank you. C++ already has that, it's called reference counting. You may have heard we use it in Qt :-) The problem here is that QCoreApplication is not reference counted and we can't change it without breaking *every* *single* *application*, since this is what people usually do: int main(int argc, char **argv) { SomeApplication app(argc, argv); [rest of the application] } That stack declaration is the problem here. The app object will be destroyed at the closing brace, whether we want it or not, and there's nothing we can do to prevent it, delay it or even hook something as it begins. We can only catch it half-way through, when the destruction has reached one of our classes (~QApplication, ~QGuiApplication or ~QCoreApplication), by which time the virtual table has already changed and it's too late. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From coroberti at gmail.com Tue Apr 14 17:36:16 2015 From: coroberti at gmail.com (Robert Iakobashvili) Date: Tue, 14 Apr 2015 18:36:16 +0300 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <14097820.igoXrKyRLV@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <21739612.kxajhZWg1P@tjmaciei-mobl4> <5464147.1FYiBlrVPZ@patux> <14097820.igoXrKyRLV@tjmaciei-mobl4> Message-ID: On Tue, Apr 14, 2015 at 6:27 PM, Thiago Macieira wrote: > On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote: > [cut] >> ObjC is so intricately linked to OS X, because from a few quick attempts it >> seems to be perfectly possible to use an ObjC++ wrapper class to extend the >> retain/release scheme to C++ classes. >> >> Is this clear enough? > > Yes, thank you. > > C++ already has that, it's called reference counting. You may have heard we > use it in Qt :-) > > The problem here is that QCoreApplication is not reference counted and we > can't change it without breaking *every* *single* *application*, since this is > what people usually do: > > int main(int argc, char **argv) > { > SomeApplication app(argc, argv); > [rest of the application] > } > > That stack declaration is the problem here. The app object will be destroyed > at the closing brace, whether we want it or not, and there's nothing we can do > to prevent it, delay it or even hook something as it begins. > > We can only catch it half-way through, when the destruction has reached one of > our classes (~QApplication, ~QGuiApplication or ~QCoreApplication), by which > time the virtual table has already changed and it's too late. C++ idiom with protected destructor enforces heap-allocation of objects and prevents stack allocation. It requires some public destroy() calling "delete this" inside. jm2c Regards, Robert From rjvbertin at gmail.com Tue Apr 14 17:53:20 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 14 Apr 2015 17:53:20 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <14097820.igoXrKyRLV@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <5464147.1FYiBlrVPZ@patux> <14097820.igoXrKyRLV@tjmaciei-mobl4> Message-ID: <9860209.NS8fbaRT2O@patux> On Tuesday April 14 2015 08:27:57 Thiago Macieira wrote: >C++ already has that, it's called reference counting. You may have heard we >use it in Qt :-) Well, reference counting can be used for many things (like deleteLater, I presume) :) >The problem here is that QCoreApplication is not reference counted and we >can't change it without breaking *every* *single* *application*, since this is >what people usually do: >That stack declaration is the problem here. The app object will be destroyed >at the closing brace, whether we want it or not, and there's nothing we can do >to prevent it, delay it or even hook something as it begins. Yes, the issue is that C++ does an immediate delete that you cannot really cancel. This may be an open door, but couldn't you change the application's entry point (or provide an alternative entry point like KDE does with kdemain). That gives you an extra layer around what the user sees as the main function. Combine that with a modified private class with a d pointer that does not necessarily get deleted when the Q*Application dtor is called, and you may have a solution? You won't be breaking any applications, and users can decide for themselves if/when they change their code to make use of the new approach. R. From jeremy.laine at m4x.org Tue Apr 14 18:14:57 2015 From: jeremy.laine at m4x.org (=?windows-1252?Q?Jeremy_Lain=E9?=) Date: Tue, 14 Apr 2015 18:14:57 +0200 Subject: [Development] QML bindings for native Android controls In-Reply-To: <9012D978-19F1-4959-97BB-94F07DDE8BAB@theqtcompany.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BBB8E.80801@m4x.org> <9012D978-19F1-4959-97BB-94F07DDE8BAB@theqtcompany.com> Message-ID: <552D3D01.1090108@m4x.org> On 04/13/2015 03:46 PM, Nurmi J-P wrote: > On 13 Apr 2015, at 14:50, Jeremy Lainé wrote: > >> How about just "android-controls", which would become >> "qt-android-controls" if the project graduates from playground? > I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? > > *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. Another option is "quick-android", which would become "qt-quick-android". Cheers, Jeremy From thiago.macieira at intel.com Tue Apr 14 18:23:42 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 09:23:42 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <14097820.igoXrKyRLV@tjmaciei-mobl4> Message-ID: <2867980.ZD1BxclfJU@tjmaciei-mobl4> On Tuesday 14 April 2015 18:36:16 Robert Iakobashvili wrote: > > The problem here is that QCoreApplication is not reference counted and we > > can't change it without breaking *every* *single* *application*, since > > this is what people usually do: > C++ idiom with protected destructor > enforces heap-allocation of objects and prevents stack allocation. > It requires some public destroy() calling "delete this" inside. Without breaking *every* *single* *application* -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Apr 14 18:27:34 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 09:27:34 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <9860209.NS8fbaRT2O@patux> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <14097820.igoXrKyRLV@tjmaciei-mobl4> <9860209.NS8fbaRT2O@patux> Message-ID: <1786970.R0m3mDNhEf@tjmaciei-mobl4> On Tuesday 14 April 2015 17:53:20 René J.V. Bertin wrote: > This may be an open door, but couldn't you change the application's entry > point (or provide an alternative entry point like KDE does with kdemain). > That gives you an extra layer around what the user sees as the main > function. I don't see how that is beneficial to anything here. It's at best a no-op. > Combine that with a modified private class with a d pointer that > does not necessarily get deleted when the Q*Application dtor is called, and > you may have a solution? You won't be breaking any applications, and users > can decide for themselves if/when they change their code to make use of the > new approach. The problem is not the d pointer or the private class. The problem is the public, *user* class if they derived from QApplication. If they've overridden notify(), then I need to know when the *user* class begins destruction so that we stop calling notify(). Robert's solution would allow for it, but at the expense of being source incompatible with every single Qt application. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From nikolaseu at gmail.com Tue Apr 14 19:45:15 2015 From: nikolaseu at gmail.com (=?UTF-8?Q?Nicol=C3=A1s_Ulrich?=) Date: Tue, 14 Apr 2015 14:45:15 -0300 Subject: [Development] QML bindings for native Android controls In-Reply-To: <552D3D01.1090108@m4x.org> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BBB8E.80801@m4x.org> <9012D978-19F1-4959-97BB-94F07DDE8BAB@theqtcompany.com> <552D3D01.1090108@m4x.org> Message-ID: On Tue, Apr 14, 2015 at 1:14 PM, Jeremy Lainé wrote: > > On 04/13/2015 03:46 PM, Nurmi J-P wrote: > > On 13 Apr 2015, at 14:50, Jeremy Lainé wrote: > > > >> How about just "android-controls", which would become > >> "qt-android-controls" if the project graduates from playground? > > I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? > > > > *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. > > Another option is "quick-android", which would become "qt-quick-android". > > Cheers, > Jeremy +1 I would love to try this so any name is good for me. I was just starting to develop something for android (in java) just because qtquickcontrols doesn't feel right. This however is really encouraging. Do/will the standard Qt models work with the native views? -------------- next part -------------- An HTML attachment was scrubbed... URL: From julien.cugniere at gmail.com Tue Apr 14 19:55:47 2015 From: julien.cugniere at gmail.com (=?ISO-8859-1?Q?Julien_Cugni=E8re?=) Date: Tue, 14 Apr 2015 19:55:47 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <3858276.pGIsscorMC@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <1687975.JCetyqtL7d@tjmaciei-mobl4> <2685353.DbnL0SWIz8@rhea> <3858276.pGIsscorMC@tjmaciei-mobl4> Message-ID: 2015-04-14 16:36 GMT+02:00 Thiago Macieira : > > 2) fix it by not passing through notify() outside the main thread. That's the > solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6. > People rely on QCoreApplication::notify to provide a try/catch when working with Qt and exceptions. That allows dealing with them in a single place, rather than in every single function called by a Qt event. If it stops working in threads, some applications will definitely see the difference. They won't necessarily break, as I seem to remember Qt has a generic try/catch around notify, but they will loose any information from the exception. Is it that common to destroy the application object will threads are still delivering events ? It feels weird to me... It would be a shame to fix a uncommon case by breaking a common one. Just thinking out loud, but assuming it isn't that common, would it make sense to provide a setting to choose between the two behaviors ? Or a Qt function/slot one need to explicitly call from the most derived application destructor when needing to continue processing events ? Or provide a different way of creating/destroying the application object when this behavior is required ? Julien Cugnière From jpnurmi at theqtcompany.com Tue Apr 14 20:16:34 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Tue, 14 Apr 2015 18:16:34 +0000 Subject: [Development] QML bindings for native Android controls In-Reply-To: <552D3D01.1090108@m4x.org> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BBB8E.80801@m4x.org> <9012D978-19F1-4959-97BB-94F07DDE8BAB@theqtcompany.com> <552D3D01.1090108@m4x.org> Message-ID: <7482849B-B49B-492E-A562-6CC96B97AEB2@theqtcompany.com> > On 14 Apr 2015, at 18:14, Jeremy Lainé wrote: > > On 04/13/2015 03:46 PM, Nurmi J-P wrote: >> On 13 Apr 2015, at 14:50, Jeremy Lainé wrote: >> >>> How about just "android-controls", which would become >>> "qt-android-controls" if the project graduates from playground? >> I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? >> >> *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. > > Another option is "quick-android", which would become "qt-quick-android”. I’d like to avoid the “quick" word, because this is incompatible with Qt Quick. -- J-P Nurmi From jpnurmi at theqtcompany.com Tue Apr 14 20:26:08 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Tue, 14 Apr 2015 18:26:08 +0000 Subject: [Development] QML bindings for native Android controls In-Reply-To: References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BBB8E.80801@m4x.org> <9012D978-19F1-4959-97BB-94F07DDE8BAB@theqtcompany.com> <552D3D01.1090108@m4x.org> Message-ID: > On 14 Apr 2015, at 19:45, Nicolás Ulrich wrote: > > I would love to try this so any name is good for me. I was just starting to develop something for android (in java) just because qtquickcontrols doesn't feel right. This however is really encouraging. This is looking very promising, but don’t get too excited yet. :) This is not a finished product, just a hackathon project that I haven’t actually touched since December because I’ve been busy with http://blog.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded/. > Do/will the standard Qt models work with the native views? The example seen in the video is using a JS array as a model for the sake of simplicity, but the same set of models that Qt Quick supports (number, JS arrays, QObjectList, QAbstractItemModel, QQmlXxxModel...) is on the wish list. -- J-P Nurmi From mw_triad at users.sourceforge.net Tue Apr 14 20:37:25 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 14 Apr 2015 14:37:25 -0400 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <1786970.R0m3mDNhEf@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <14097820.igoXrKyRLV@tjmaciei-mobl4> <9860209.NS8fbaRT2O@patux> <1786970.R0m3mDNhEf@tjmaciei-mobl4> Message-ID: On 2015-04-14 12:27, Thiago Macieira wrote: > The problem is the public, *user* class if they derived from QApplication. > > If they've overridden notify(), then I need to know when the *user* class > begins destruction so that we stop calling notify(). Would it be horrible to add a new method, e.g. shutdown(), which subclasses are required to call in their dtor? It won't fix existing applications, but it at least provides a mechanism to make things work. -- Matthew From thiago.macieira at intel.com Tue Apr 14 20:39:33 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 11:39:33 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <3858276.pGIsscorMC@tjmaciei-mobl4> Message-ID: <3395724.3AFATvtSfp@tjmaciei-mobl4> On Tuesday 14 April 2015 19:55:47 Julien Cugnière wrote: > 2015-04-14 16:36 GMT+02:00 Thiago Macieira : > > 2) fix it by not passing through notify() outside the main thread. That's > > the solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6. > > People rely on QCoreApplication::notify to provide a try/catch when > working with Qt and exceptions. That solution has been disproven. It is neither sufficient nor necessary for proper exception unwinding of the event loop. It hasn't been for a long time, since at least around Qt 4.4, probably more. > That allows dealing with them in a > single place, rather than in every single function called by a Qt > event. If it stops working in threads, some applications will > definitely see the difference. They won't necessarily break, as I seem > to remember Qt has a generic try/catch around notify, but they will > loose any information from the exception. We removed the try/catch and replaced with stack objects that will unwind properly. If you're lucky, an exception will simply unwind QCoreApplication out of exec(), so a try/catch around exec() may work. But this is untested and unsupported. DO NOT throw through the event loop and DO NOT throw back to the signal-slot delivery mechanism. We will not deal with bug reports that this does not work. I may accept patches that fix this, provided they don't introduce performance issues. So I am not considering this a valid use-case for the problem at hand. > Is it that common to destroy the application object will threads are > still delivering events ? It feels weird to me... It would be a shame > to fix a uncommon case by breaking a common one. Yes, it happens and that is what's happening with the QtDBus changes I'm making: the thread continues running after QCoreApplication exits. The previous QProcessManager solution tried to exit the thread during QCoreApplication shutdown, but note that it was already too late! The routines added with qAddPostRoutine are run from the QCoreApplication destructor, so the vtables have already changed and we've already run into undefined behaviour. The lastWindowClosed() and aboutToQuit() signals are also too early: they are emitted shortly before exec() returns, but the application may continue running after that. > Just thinking out loud, but assuming it isn't that common, would it > make sense to provide a setting to choose between the two behaviors ? Not an applicaation-wide setting because you don't know *which* threads are running in the background. But I could make it a per-thread choice. > Or a Qt function/slot one need to explicitly call from the most > derived application destructor when needing to continue processing > events ? Source-compatible, but requires changes to all applications, so we can't rely on applications having been corrected to deal with this. So it's useless: we can't rely on the feature. > Or provide a different way of creating/destroying the > application object when this behavior is required ? Same thing: providing a different way without breaking source compatibility means we can't rely on it being used. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Tue Apr 14 20:45:39 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 11:45:39 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <1786970.R0m3mDNhEf@tjmaciei-mobl4> Message-ID: <2053432.1rqcADQOLA@tjmaciei-mobl4> On Tuesday 14 April 2015 14:37:25 Matthew Woehlke wrote: > Would it be horrible to add a new method, e.g. shutdown(), which > subclasses are required to call in their dtor? It won't fix existing > applications, but it at least provides a mechanism to make things work. Same answer as I gave to Julien: if we can't force applications to call it, they won't and we can't rely on it being used. And if we do, it's source- incompatible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Apr 14 21:26:40 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 14 Apr 2015 21:26:40 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <1786970.R0m3mDNhEf@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <9860209.NS8fbaRT2O@patux> <1786970.R0m3mDNhEf@tjmaciei-mobl4> Message-ID: <8368173.QnP0KYjmLo@portia.local> On Tuesday April 14 2015 09:27:34 Thiago Macieira wrote: > On Tuesday 14 April 2015 17:53:20 René J.V. Bertin wrote: > > This may be an open door, but couldn't you change the application's entry > > point (or provide an alternative entry point like KDE does with kdemain). > > That gives you an extra layer around what the user sees as the main > > function. > > I don't see how that is beneficial to anything here. It's at best a no-op. Having a layer above the user main should give you more manoeuvring room to perform house keeping tasks. Whether that's of use here is a different question. It does seem though that it would allow you to stop calling notify() once the user main has returned. That won't catch cases where the Q*Application instance is deleted before main returns, but maybe those cases are less frequent. > The problem is not the d pointer or the private class. Wasn't saying it was. > Same answer as I gave to Julien: if we can't force applications to call it, > they won't and we can't rely on it being used. And if we do, it's source- > incompatible. Between a rock and a hard place one could opt for a compromise. You're planning to introduce changes to QtDBus that may break things. Applications that don't break because of it don't need a solution. If those that break can be fixed with a simple invocation of a new mechanism provided exactly for that purpose, isn't that good enough? R From thiago.macieira at intel.com Wed Apr 15 00:58:20 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 14 Apr 2015 15:58:20 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <8368173.QnP0KYjmLo@portia.local> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <1786970.R0m3mDNhEf@tjmaciei-mobl4> <8368173.QnP0KYjmLo@portia.local> Message-ID: <1995715.F48z5fy9kW@tjmaciei-mobl4> On Tuesday 14 April 2015 21:26:40 René J.V. Bertin wrote: > Between a rock and a hard place one could opt for a compromise. You're > planning to introduce changes to QtDBus that may break things. Applications > that don't break because of it don't need a solution. If those that break > can be fixed with a simple invocation of a new mechanism provided exactly > for that purpose, isn't that good enough? Those applications are broken already today, since we use threads for OpenGL, for the QPA event management and, up to Qt 5.4, in QProcess. They may not have noticed they're broken, but they're broken. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Wed Apr 15 01:13:34 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 14 Apr 2015 16:13:34 -0700 (PDT) Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <1995715.F48z5fy9kW@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <8368173.QnP0KYjmLo@portia.local> <1995715.F48z5fy9kW@tjmaciei-mobl4> Message-ID: <3891046.aWsYASMnxC@portia.local> On Tuesday April 14 2015 15:58:20 Thiago Macieira wrote: > They may not have noticed they're broken, but they're broken. Ok then > > If those that break can be fixed with a simple invocation of a new mechanism provided exactly ^^^^^ shatter into pieces > > for that purpose, isn't that good enough? T,FTFY :) From szehowe.koh at gmail.com Wed Apr 15 02:01:03 2015 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Wed, 15 Apr 2015 08:01:03 +0800 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: <1785124.lMC8oGzQjT@rhea> References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <3682276.Ia6Rxzu1m6@rhea> <1785124.lMC8oGzQjT@rhea> Message-ID: On 9 April 2015 at 19:17, Simon Hausmann wrote: > > On Thursday 9. April 2015 11.52.31 Simon Hausmann wrote: > > On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote: > > [...] > > > > > Going off on a slight tangent: > > > https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object "is > > > converted to a QVariantMap. Each property is converted to a QVariant, > > > recursively". However, calling toVariant() on an Error object > > > (isError() == isObject() == true) produces an empty QVariantMap event > > > though QJSValueIterator gets the properties just fine (using Qt > > > 5.4.1). Is this expected? > > > > That could be a bug. You should see the enumerable properties, which I think > > include message and name. If a strack trace was producible at constructor > > time, then you should also see the fileName and lineNumber properties. > > "stack" however will not be visible. > > Ah, I had another look and I have to correct myself here: > > The properties in question ("message", "name", etc.) are defined as being non- > enumerable [1], which is why the are not visible in the toVariant() > conversion. Similarly those properties are not visible if you do > > for (propName in error) { > console.log(propName) > } > > > QJSValueIterator - as a C++ tool - lists _all_ properties of an object, even > the non-enumerable ones. Thanks for looking it up. Was it a conscious decision to restrict QJSValue::toVariant() to enumerable properties only? What's the rationale? > Simon > > [1] Although those properties are technically vendor extensions and non- > standard, they are commonly implemented across web browser oriented JavaScript > engines and _there_ they are non-enumerable. "name" and "message" are standard :) http://www.ecma-international.org/ecma-262/5.1/#sec-15.11.4 If I've read the spec correctly, all properties of the Error prototype should be non-enumerable, so I think Qt is compliant with this part of the spec. Regards, Sze-Howe From szehowe.koh at gmail.com Wed Apr 15 02:01:55 2015 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Wed, 15 Apr 2015 08:01:55 +0800 Subject: [Development] [Interest] QJSEngine and error line In-Reply-To: <55264188.3090909@theqtcompany.com> References: <5031FBCD-54B0-46A3-826E-516707ADBE5E@grame.fr> <5523A3F5.6000900@theqtcompany.com> <552536C6.8040804@theqtcompany.com> <55264188.3090909@theqtcompany.com> Message-ID: On 9 April 2015 at 17:08, Joerg Bornemann wrote: > On 08-Apr-15 17:45, Sze Howe Koh wrote: > >> May I suggest adding a bit of documentation on our side to help people >> discover the features? Currently, >> http://doc.qt.io/qt-5/qjsengine.html#script-exceptions only recommends >> using toString() to probe errors. That's an ideal place to add a list >> of standard and non-standard properties that users can take advantage >> of. > > > Point taken. In the light that the most interesting properties here are > non-standard I agree that we should extend the docs. https://codereview.qt-project.org/110445/ Regards, Sze-Howe From berkayelbir at gmail.com Wed Apr 15 09:09:59 2015 From: berkayelbir at gmail.com (Berkay Elbir) Date: Wed, 15 Apr 2015 10:09:59 +0300 Subject: [Development] Qt Installer (1.5.0) uninstaller customization Message-ID: Hello All, How can I control the uninstaller to check program is running or not before uninstalling program in Qt installer version 1.5.0 ? Actually, I could do this in 2.0.0 with controller script but then there is a bug: https://bugreports.qt.io/browse/QTIFW-659 and it is not seen in 1.5.0 version so I want to use this version until bug is fixed. Thanks in advance. Best Regards, Berkay Elbir -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kai.Koehne at theqtcompany.com Wed Apr 15 09:46:45 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Wed, 15 Apr 2015 07:46:45 +0000 Subject: [Development] Qt Installer (1.5.0) uninstaller customization In-Reply-To: References: Message-ID: > -----Original Message----- > From: development-bounces+kai.koehne=theqtcompany.com at qt- > Subject: [Development] Qt Installer (1.5.0) uninstaller customization > > Hello All, > > How can I control the uninstaller to check program is running or not before > uninstalling program in Qt installer version 1.5.0 ? Actually, I could do this in > 2.0.0 with controller script but then there is a bug: > https://bugreports.qt.io/browse/QTIFW-659 and it is not seen in 1.5.0 > version so I want to use this version until bug is fixed. Hi, Try using addStopProcessForUpdateRequest, or setStopProcessForUpdateRequest http://doc.qt.io/qtinstallerframework/scripting-component.html#addStopProcessForUpdateRequest-method Calling this at installation/update time will also result in a check in the uninstaller. See http://code.qt.io/cgit/qt-creator/qt-creator.git/tree/dist/installer/ifw/packages/org.qtproject.qtcreator.application/meta/installscript.qs for a real-world usage of this. Regards Kai (This is btw a question that belongs to interest@, not development at . Please drop development at qt-project.org in further replies). From jani.heikkinen at theqtcompany.com Wed Apr 15 11:15:41 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 15 Apr 2015 09:15:41 +0000 Subject: [Development] Qt5.4.2 snapshot available Message-ID: <1429089341032.56632@theqtcompany.com> Hi all, Qt 5.4.2 snapshot finally available. Windows: http://download.qt.io/snapshots/qt/5.4/5.4.2/2015-04-14_118/ Linux: http://download.qt.io/snapshots/qt/5.4/5.4.2/2015-04-14_121/ Mac: http://download.qt.io/snapshots/qt/5.4/5.4.2/2015-04-14_107/ Most of installers are there, only windows MSVC2012 one is missing. We are trying to put Qt5.4.2 out quite soon so please test the packages & inform all release blockers to me immediately. All blockers must be linked in the metabug as well ( https://bugreports.qt.io/browse/QTBUG-44881). It is also a time to start creating changes files for Qt5.4.2 already now, maintainers: Please make sure those are in '5.4.2' branch as soon as possible, hoping during this week already. br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.hausmann at theqtcompany.com Wed Apr 15 11:30:34 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Wed, 15 Apr 2015 11:30:34 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <3858276.pGIsscorMC@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2685353.DbnL0SWIz8@rhea> <3858276.pGIsscorMC@tjmaciei-mobl4> Message-ID: <1724626.Xx8GKFWBmA@rhea> On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote: > On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote: > > Would it be feasible to make event loops started before and after > > QCoreApplication truly independent from notify() but all the others "join" > > in? > > Not without race conditions. > > if (self) > return self->notify(object, event); > > // deliver directly > return doNotify(object, event); > > What happens if the QCoreApplication gets deleted between the first and > second lines? In fact, what happens if it begins destruction? That's > totally in the land of undefined behaviour. > > I'm not introducing the race condition, it already exists: > > inline bool QCoreApplication::sendEvent(QObject *receiver, QEvent *event) > { if (event) event->spont = false; return self ? self- > > >notifyInternal(receiver, event) : false; } > > I only three possible outcomes here: > > 1) ignore the problem and document it that Qt event delivery is unsafe if > you have any threads running by the time QCoreApplication gets deleted > > 2) fix it by not passing through notify() outside the main thread. That's > the solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6. > > 3) introduce a global, recursive QReadWriteLock that prevents > QCoreApplication destruction from concluding. Note that it cannot prevent > the destruction from starting, so the virtual table may still change and we > are still in undefined behaviour by calling a virtual after the object > began destructing. > > I recommend against 1 and 3 I understand that you're not introducing a new race condition, but we also have to consider that option number 2 results in the removal of a feature that is documented and has been there for a long time and that works in the common case. The common case I'm thinking of is that an application starts up, after some time it starts one or multiple working threads, then those threads terminate and maybe at some point later the application also terminates. That case works just fine and my concern is that there are people out there using this feature. That said, I personally think the feature of having this ultra-central hook that is called from all (Qt) threads is a bad feature to have. If we were discussing the introduction of it, I would probably attempt to argue against it. However now we are discussing the removal of it, and I think we need more insight on that before going ahead. Simon From Lars.Knoll at theqtcompany.com Wed Apr 15 11:39:59 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 15 Apr 2015 09:39:59 +0000 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <1724626.Xx8GKFWBmA@rhea> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2685353.DbnL0SWIz8@rhea> <3858276.pGIsscorMC@tjmaciei-mobl4> <1724626.Xx8GKFWBmA@rhea> Message-ID: On 15/04/15 11:30, "Simon Hausmann" wrote: >On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote: >> On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote: >> > Would it be feasible to make event loops started before and after >> > QCoreApplication truly independent from notify() but all the others >>"join" >> > in? >> >> Not without race conditions. >> >> if (self) >> return self->notify(object, event); >> >> // deliver directly >> return doNotify(object, event); >> >> What happens if the QCoreApplication gets deleted between the first and >> second lines? In fact, what happens if it begins destruction? That's >> totally in the land of undefined behaviour. >> >> I'm not introducing the race condition, it already exists: >> >> inline bool QCoreApplication::sendEvent(QObject *receiver, QEvent >>*event) >> { if (event) event->spont = false; return self ? self- >> >> >notifyInternal(receiver, event) : false; } >> >> I only three possible outcomes here: >> >> 1) ignore the problem and document it that Qt event delivery is unsafe >>if >> you have any threads running by the time QCoreApplication gets deleted >> >> 2) fix it by not passing through notify() outside the main thread. >>That's >> the solution I implemented in I27eaacb532114dd188c4ffff13d4ad2a4bb443e6. >> >> 3) introduce a global, recursive QReadWriteLock that prevents >> QCoreApplication destruction from concluding. Note that it cannot >>prevent >> the destruction from starting, so the virtual table may still change >>and we >> are still in undefined behaviour by calling a virtual after the object >> began destructing. >> >> I recommend against 1 and 3 > >I understand that you're not introducing a new race condition, but we >also >have to consider that option number 2 results in the removal of a feature >that >is documented and has been there for a long time and that works in the >common >case. The common case I'm thinking of is that an application starts up, >after >some time it starts one or multiple working threads, then those threads >terminate and maybe at some point later the application also terminates. >That case works just fine and my concern is that there are people out >there >using this feature. > > >That said, I personally think the feature of having this ultra-central >hook >that is called from all (Qt) threads is a bad feature to have. If we were >discussing the introduction of it, I would probably attempt to argue >against >it. > >However now we are discussing the removal of it, and I think we need more >insight on that before going ahead. Well, I’d say we should try to see how much this is being used. I don’t think we ourselves use it at all. How much is this used in other projects? The central notify() hook is something I don’t like at all. It’s very easy to mess things up using it, and I would think most people reimplementing notify() need it for the main thread only. So I would rather go with approach 2, document this as a change, and then try to offer a replacement so people can filter and inspect events on threads. Cheers, Lars From andre at familiesomers.nl Wed Apr 15 11:49:56 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Wed, 15 Apr 2015 11:49:56 +0200 Subject: [Development] RFC: RAII for property changes Message-ID: <552E3444.2080801@familiesomers.nl> Hi, When writing QObject-derived classes with properties, I often found myself writing code like this: void MyClass::setFoo(QString value) { if (m_foo != value) { m_foo = value; emit fooChanged(m_foo); } } Trivial enough, in the simple case. However, when more than one property is involved at the same time, or properties depend on each other, things can get way less simple and more error-phrone quickly, I found. If the order of signals matters (and I found it does some times!), it gets even more tricky to get things right. This is especially tricky because you really would like to emit the signal at the moment the class is in a consistent state. That is, if you have a method that sets both width and height of an object at the same time, you really don't want to emit the signal about the change of one property before the change of another property is also set. In this case, the change may be harmless (but potentially expensive, as perhaps two relayouts are triggered when only one was needed), but there are cases where you'd really expose the class in an inconsistent state if you emit too soon. Considder that at the moment you emit, you give other code the change to do whatever its wants again, including calling methods on your class, even the very same method they just called, or worse, delete it... Your class better be in a consistent state when they do such things. That's why I have been working with a RAII implementation to monitor property changes for a while now. The idea is that you instantiate a RAII class to monitor a property at the beginning of a method that _may_ change the property value, and then do all you want. Upon destruction of the RAII class, it checks if the property value changed and if it did, emit the associated signal. The code I now write looks like this: void MyClass::setFoo(QString value) { PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY Q_UNUSED(guard); m_foo = value; } which then is further simplified by creating a small macro called guardProperty to this: void MyClass::setFoo(QString value) { guardProperty(foo); //foo is the name of the Q_PROPERTY m_foo = value; } Note that you can guard as many properties as you need: void MyClass::setFoo(QString value) { guardProperty(foo); //foo is the name of the Q_PROPERTY guardProperty(isValid); //the isValid property depends on m_foo as well m_foo = value; } The PropertyGuard class itself is quite simple in its basic form. It uses QMetaObject to read the current value and find the notify signal for the property. Upon desctruction, it compares the current value to the initial value stored at creation, and if the two don't match, the signal is emitted. The code deals with signals with zero or one arguments, assuming that in the latter case the one argument is the new property value. I found this little device to be very useful in practice. Not so much in trivial setters like the ones on top (but still useful there, as the intent is clearer and there is less typing), but very much so in non-trivial cases where more than one property may change at a time or other complex interactions take place. In cases where a method changing should trigger other property changes as well, while not exposing inconsistent states of the class I found the device to be extremely valuable, as I can be sure that the emits are done at a moment where the state of class is fully consistent. I find myself writing emit less and less. So, what are your opinions on using a mechanism like this? I have not found it in Qt itself, but perhaps others here are already using similar methods or perhaps very different methods to tackle the issues I described? Looking forward to your comments, André Somers From andre at familiesomers.nl Wed Apr 15 11:56:04 2015 From: andre at familiesomers.nl (=?UTF-8?B?QW5kcsOpIFNvbWVycw==?=) Date: Wed, 15 Apr 2015 11:56:04 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2685353.DbnL0SWIz8@rhea> <3858276.pGIsscorMC@tjmaciei-mobl4> <1724626.Xx8GKFWBmA@rhea> Message-ID: <552E35B4.7050809@familiesomers.nl> Knoll Lars schreef op 15-4-2015 om 11:39: > Well, I’d say we should try to see how much this is being used. I > don’t think we ourselves use it at all. How much is this used in other > projects? The central notify() hook is something I don’t like at all. > It’s very easy to mess things up using it, and I would think most > people reimplementing notify() need it for the main thread only. So I > would rather go with approach 2, document this as a change, and then > try to offer a replacement so people can filter and inspect events on > threads. We use it in our applications. It is used indeed as a catch-all exception handler (I'm not a fan, but ok), but a useful use we also have that we use it as a debug device to get more insight into what events are send around the system, monitoring a set of objects and a set of event types and outputting them. Sure, that's not a common use case and can be done differently, but we have used/abused notifiy for these. André From jeisecke at saltation.de Wed Apr 15 13:56:36 2015 From: jeisecke at saltation.de (Nils Jeisecke) Date: Wed, 15 Apr 2015 13:56:36 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: <552E3444.2080801@familiesomers.nl> References: <552E3444.2080801@familiesomers.nl> Message-ID: Hi, On Wed, Apr 15, 2015 at 11:49 AM, André Somers wrote: > That's why I have been working with a RAII implementation to monitor > property changes for a while now. This looks like an interesting idea. Another issue I often have with properties is performance related. Imagine a model that has more than one filter property. In case that two properties should be set, it does not make sense to update the model twice. Adding a special setFilters method with multiple arguments is no option if you want to use property binding in QML. So I usually have a private "update" slot and a timer that's restarted on each property invocation so that the model update will take place on the next event loop iteration. That "guard" could have a second parameter specifying a "property evaluation" slot that is guaranteed to be invoked *once* on the next event loop iteration. It might be tricky to manage the timer though, maybe setting a special custom object property "___invoke_timer" storing the timer pointer could help? Or - to get rid of the expensive timer - a flag could be stored as a property controlling whether QMetaObject::invoke(this, "", Qt::QueuedConnection) should be called - the slot (or a c++11 lambda?) would have to reset that flag then. Thinking about this, maybe this functionality should be implemented in a separate class. Nils From julien.cugniere at gmail.com Wed Apr 15 15:01:29 2015 From: julien.cugniere at gmail.com (=?ISO-8859-1?Q?Julien_Cugni=E8re?=) Date: Wed, 15 Apr 2015 15:01:29 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <3395724.3AFATvtSfp@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <3858276.pGIsscorMC@tjmaciei-mobl4> <3395724.3AFATvtSfp@tjmaciei-mobl4> Message-ID: 2015-04-14 20:39 GMT+02:00 Thiago Macieira : > > We removed the try/catch and replaced with stack objects that will unwind > properly. If you're lucky, an exception will simply unwind QCoreApplication > out of exec(), so a try/catch around exec() may work. > > But this is untested and unsupported. DO NOT throw through the event loop and > DO NOT throw back to the signal-slot delivery mechanism. We will not deal with > bug reports that this does not work. I may accept patches that fix this, > provided they don't introduce performance issues. > So just to make sure I understand it correctly, the following : bool SomeApplication::notify(QObject *object, QEvent *event) { try { return QCoreApplication::notify(object, event); } catch (const Exception& e) { writeLog(e.message()); return true; } } Works for the moment (we use with Qt 5.3 just fine), but is not supported anymore, and has no official replacement. And with your change, it will stop working entirely. Any application relying on this will have to either add hundreds of thousands of try/catch all over the place (in all slots and event handlers, very error-prone), or be redesigned from scratch to not use exceptions. For the software we develop at work, we will probably end up patching our copy of Qt, as rewriting everything will be prohibitive, and we don't need QtDBUS, or post-application event delivery. From marc.mutz at kdab.com Wed Apr 15 16:43:50 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Apr 2015 16:43:50 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: <552E3444.2080801@familiesomers.nl> References: <552E3444.2080801@familiesomers.nl> Message-ID: <201504151643.50541.marc.mutz@kdab.com> Hi André, On Wednesday 15 April 2015 11:49:56 André Somers wrote: > void MyClass::setFoo(QString value) > { > PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY > Q_UNUSED(guard); > > m_foo = value; > } This is an interesting idea, though I don't think I have encountered the problems with which you motivate PropertyGuard. For use in a library, though, I fear the string-based mechanism is too inefficient. For use within QtWidgets, say, I'd suggest a mechanism that works on the member data directly. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kreios4004 at gmail.com Wed Apr 15 16:54:45 2015 From: kreios4004 at gmail.com (Keith Gardner) Date: Wed, 15 Apr 2015 14:54:45 +0000 Subject: [Development] RFC: RAII for property changes In-Reply-To: <201504151643.50541.marc.mutz@kdab.com> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: On Wed, Apr 15, 2015 at 9:38 AM Marc Mutz wrote: > Hi André, > > On Wednesday 15 April 2015 11:49:56 André Somers wrote: > > void MyClass::setFoo(QString value) > > { > > PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY > > Q_UNUSED(guard); > > > > m_foo = value; > > } > > This is an interesting idea, though I don't think I have encountered the > problems with which you motivate PropertyGuard. > > For use in a library, though, I fear the string-based mechanism is too > inefficient. For use within QtWidgets, say, I'd suggest a mechanism that > works > on the member data directly. > > Thanks, > Marc > I have actually run into the same situation and made a template class that owns the variable. Its constructor takes an initial value and a std::function as a callback for when the value changes. The callback can be a lambda or a std::bind to the expected signal. I also added overloads to allow for the templated class to behave just like the contained type so that it can be swapped in easily. I figured the Qt project wouldn't like the submission of the class due to its template nature and its use of std::function but i am willing to share it if anyone is interested. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Wed Apr 15 16:58:24 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Wed, 15 Apr 2015 16:58:24 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: <201504151643.50541.marc.mutz@kdab.com> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: <552E7C90.1060409@familiesomers.nl> Hi Marc, Thank you for responding. Marc Mutz schreef op 15-4-2015 om 16:43: > Hi André, > > On Wednesday 15 April 2015 11:49:56 André Somers wrote: >> void MyClass::setFoo(QString value) >> { >> PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >> Q_UNUSED(guard); >> >> m_foo = value; >> } > This is an interesting idea, though I don't think I have encountered the > problems with which you motivate PropertyGuard. Are you sure, or is your code just not secure? ;-) Basically, if you have this code (or something like it) somewhere, you already have a problem: void MyClass::setFooAndBar(QString foo, int bar) { if (m_foo != foo) { m_foo = foo; emit fooChanged(foo); //this is where things may start to go wrong already } if (m_bar != bar) { m_bar = bar; emit barChanged(bar); } } Calling separate setters instead from inside setFooAndBar doesn't help. What happens if a slot connected to fooChanged uses the instance of MyClass? What property values does it see? foo is changed, but bar has not changed yet. What if that slot triggers something that ends up deleting the instance? You'd have to write something like this instead: void MyClass::setFooAndBar(QString foo, int bar) { bool fooHasChanged(false); bool barHasChanged(false); if (m_foo != foo) { m_foo = foo; fooHasChanged = true; } if (m_bar != bar) { m_bar = bar; barHasChanged = true; } if (fooHasChanged) emit fooHasChanged(foo); if (barHasChanged) emit barHasChanged(bar); // we should check if we're still alive before we do this } I find my version easier to write and maintain: void MyClass::setFooAndBar(QString foo, int bar) { guardProperty(foo); guardProperty(bar); m_foo = foo; m_bar = bar; } > > For use in a library, though, I fear the string-based mechanism is too > inefficient. For use within QtWidgets, say, I'd suggest a mechanism that works > on the member data directly. I developed this still working on Qt4, and there its's all we have. Do you have a suggestion how to get access to the metaproperty without using the string lookup in Qt5? AFAIK, that is still string-based API. Perhaps it could be a constexpr though, as the value really wouldn't change at runtime (for normal C++ objects, not talking about dynamic generated stuff here)? I doubt that will actually work, but I have not played around with that enough yet. Thanks for your comments though; speed is a real concern of course. André From mw_triad at users.sourceforge.net Wed Apr 15 17:08:11 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 15 Apr 2015 11:08:11 -0400 Subject: [Development] RFC: RAII for property changes In-Reply-To: <201504151643.50541.marc.mutz@kdab.com> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: On 2015-04-15 10:43, Marc Mutz wrote: > On Wednesday 15 April 2015 11:49:56 André Somers wrote: >> void MyClass::setFoo(QString value) >> { >> PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >> Q_UNUSED(guard); >> >> m_foo = value; >> } > > This is an interesting idea, though I don't think I have encountered the > problems with which you motivate PropertyGuard. > > For use in a library, though, I fear the string-based mechanism is too > inefficient. For use within QtWidgets, say, I'd suggest a mechanism that works > on the member data directly. FWIW I had the same thought; also, I'm not a fan of needing the Q_UNUSED, or using a macro to 'hide' it. What about something like this? QPropertyGuard g{this}; g.addProperty("a"); // use QObject::property g.addProperty("b", m_b); // take value member by reference g.addProperty(m_c, &cChanged); // ...and also slot address It's slightly redundant because declaring the guard and adding a property are separate, but there is no unused object, and you can use the same guard for multiple properties. The implementation is trickier (probably you need a dynamically allocated templated helper class with a virtual base to store the value and check for changes), but avoids multiple string-based look-ups. The "slot" could be a functor, like QObject::connect accepts, that could be any of the actual slot, std::function, lambda, etc. -- Matthew From thiago.macieira at intel.com Wed Apr 15 17:11:27 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Apr 2015 08:11:27 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <3395724.3AFATvtSfp@tjmaciei-mobl4> Message-ID: <2217591.37vjjWJZ09@tjmaciei-mobl4> On Wednesday 15 April 2015 15:01:29 Julien Cugnière wrote: > > But this is untested and unsupported. DO NOT throw through the event loop > > and DO NOT throw back to the signal-slot delivery mechanism. We will not > > deal with bug reports that this does not work. I may accept patches that > > fix this, provided they don't introduce performance issues. > > So just to make sure I understand it correctly, the following : > > bool SomeApplication::notify(QObject *object, QEvent *event) > { > try { > return QCoreApplication::notify(object, event); > } > catch (const Exception& e) { > writeLog(e.message()); > return true; > } > } > > Works for the moment (we use with Qt 5.3 just fine), but is not > supported anymore, and has no official replacement. And with your > change, it will stop working entirely. Any application relying on this > will have to either add hundreds of thousands of try/catch all over > the place (in all slots and event handlers, very error-prone), or be > redesigned from scratch to not use exceptions. Not exactly. It all depends on what you define to be "works". I don't consider resuming the event loop to be "works". I think that an uncaught exception should exit the event loop and cause the application to exit, so I consider your code above broken. It should rethrow after logging. But let's assume you have a good reason for continuing the event loop. You're now in unsupported territory because you caught an exception in the middle of the loop and resumed operations. The code above will continue to work for the main thread, but will stop working for auxiliary threads. And there will be no work around. You will need to do the right thing and stop any exceptions from going back to the signal- slot mechanism and the event delivery mechanism. If the problem is exceptions, we can simply add the exception protection elsewhere in the stack, closer to where we actually call out to the event handler or the slot. > For the software we develop at work, we will probably end up patching > our copy of Qt, as rewriting everything will be prohibitive, and we > don't need QtDBUS, or post-application event delivery. Do you need OpenGL or X11? Those use threads and they will probably continue running even after your SomeApplication class's destructor has begun, which means they may call your notify() during the destructor, including just after it finished and ~QApplication began. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From mw_triad at users.sourceforge.net Wed Apr 15 17:12:57 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 15 Apr 2015 11:12:57 -0400 Subject: [Development] RFC: RAII for property changes In-Reply-To: <552E7C90.1060409@familiesomers.nl> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <552E7C90.1060409@familiesomers.nl> Message-ID: [Valid points about the inconsistent state of the object elided.] On 2015-04-15 10:58, André Somers wrote: > What if that slot [connected to the instance property changed > signal] triggers something that ends up deleting the instance? Then the slot is broken. What if the sender needs to do something after it delivers the signal? What if other slots are connected? Deleting a signal sender from a slot connected to the signal is inherently dangerous. Don't do it. This is why we have deleteLater()... IMO it's perfectly valid for an object to assume that emitting a signal will not cause it to be deleted. -- Matthew From thiago.macieira at intel.com Wed Apr 15 17:20:31 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Apr 2015 08:20:31 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <552E35B4.7050809@familiesomers.nl> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <552E35B4.7050809@familiesomers.nl> Message-ID: <3242539.ldNOznXX6C@tjmaciei-mobl4> On Wednesday 15 April 2015 11:56:04 André Somers wrote: > We use it in our applications. It is used indeed as a catch-all > exception handler (I'm not a fan, but ok), but a useful use we also have > that we use it as a debug device to get more insight into what events > are send around the system, monitoring a set of objects and a set of > event types and outputting them. Sure, that's not a common use case and > can be done differently, but we have used/abused notifiy for these. Thanks André. The above contains two use-cases for overriding notify(): 1) catching exceptions, logging and resuming work 2) debugging / inspecting events QGuiApplication does the 2nd case by allowing the QPlatformWindow to inspect events sent to QWindow objects. They don't stop or modify the event in any way. QApplication itself has a third usecase. Well, I think it does, because it's a 680-line function I don't understand. Either way, both are only for objects in the main thread. Anyway, for debugging events, I'd say GammaRay is your solution. You shouldn't have to override a virtual and do your own logging if GammaRay does it for you. As for the catching exceptions, we can provide that as a application-global toggle. We could also allow setting QT_FATAL_EXCEPTIONS to make the printing fatal and stop execution cleanly. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From christian.kandeler at theqtcompany.com Wed Apr 15 17:25:42 2015 From: christian.kandeler at theqtcompany.com (Christian Kandeler) Date: Wed, 15 Apr 2015 17:25:42 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <552E7C90.1060409@familiesomers.nl> Message-ID: <552E82F6.5090009@theqtcompany.com> On 04/15/2015 05:12 PM, Matthew Woehlke wrote: > [Valid points about the inconsistent state of the object elided.] > > On 2015-04-15 10:58, André Somers wrote: >> What if that slot [connected to the instance property changed >> signal] triggers something that ends up deleting the instance? > > Then the slot is broken. What if the sender needs to do something after > it delivers the signal? What if other slots are connected? Deleting a > signal sender from a slot connected to the signal is inherently > dangerous. Don't do it. While delete is probably the most extreme case, all other operations on the sender have the same conceptual problem. I'd even argue that the delete case is relatively benign, because it very likely fails loudly, rather than in some subtle way. Christian From andre at familiesomers.nl Wed Apr 15 18:17:01 2015 From: andre at familiesomers.nl (Andre Somers) Date: Wed, 15 Apr 2015 18:17:01 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: <552E8EFD.1000602@familiesomers.nl> On 15-4-2015 16:54, Keith Gardner wrote: > > > On Wed, Apr 15, 2015 at 9:38 AM Marc Mutz > wrote: > > Hi André, > > On Wednesday 15 April 2015 11:49:56 André Somers wrote: > > void MyClass::setFoo(QString value) > > { > > PropertyGuard guard(this, "foo"); //foo is the name of the > Q_PROPERTY > > Q_UNUSED(guard); > > > > m_foo = value; > > } > > This is an interesting idea, though I don't think I have > encountered the > problems with which you motivate PropertyGuard. > > For use in a library, though, I fear the string-based mechanism is too > inefficient. For use within QtWidgets, say, I'd suggest a > mechanism that works > on the member data directly. > > Thanks, > Marc > > > I have actually run into the same situation and made a template class > that owns the variable. Its constructor takes an initial value and a > std::function as a callback for when the value > changes. The callback can be a lambda or a std::bind to the expected > signal. I also added overloads to allow for the templated class to > behave just like the contained type so that it can be swapped in > easily. I figured the Qt project wouldn't like the submission of the > class due to its template nature and its use of std::function but i am > willing to share it if anyone is interested. I'd certainly be interested to seeing how you solved this, yes. Thanks! André > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Wed Apr 15 18:29:33 2015 From: andre at familiesomers.nl (Andre Somers) Date: Wed, 15 Apr 2015 18:29:33 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: <552E91ED.9000909@familiesomers.nl> On 15-4-2015 17:08, Matthew Woehlke wrote: > On 2015-04-15 10:43, Marc Mutz wrote: >> On Wednesday 15 April 2015 11:49:56 André Somers wrote: >>> void MyClass::setFoo(QString value) >>> { >>> PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >>> Q_UNUSED(guard); >>> >>> m_foo = value; >>> } >> This is an interesting idea, though I don't think I have encountered the >> problems with which you motivate PropertyGuard. >> >> For use in a library, though, I fear the string-based mechanism is too >> inefficient. For use within QtWidgets, say, I'd suggest a mechanism that works >> on the member data directly. > FWIW I had the same thought; also, I'm not a fan of needing the > Q_UNUSED, or using a macro to 'hide' it. > > What about something like this? > > QPropertyGuard g{this}; > g.addProperty("a"); // use QObject::property > g.addProperty("b", m_b); // take value member by reference > g.addProperty(m_c, &cChanged); // ...and also slot address > > It's slightly redundant because declaring the guard and adding a > property are separate, but there is no unused object, and you can use > the same guard for multiple properties. > > The implementation is trickier (probably you need a dynamically > allocated templated helper class with a virtual base to store the value > and check for changes), but avoids multiple string-based look-ups. > > The "slot" could be a functor, like QObject::connect accepts, that could > be any of the actual slot, std::function, lambda, etc. > I'm not sure I understand your solution, or what it yields over what I am using now. Of course what I do is not using multiple string lookups. The property is looked up once on construction of the guard object. Then the current value is copied as a QVariant, as it is made available through the property system. The signal meta-method is also stored from the constructor, so the destructor can use it. So, only one string-lookup needed per property. The elegance is that it uses the property system to get the value *and* the notification signal to trigger, so it is really easy to use. The need for a Q_UNUSED is inherent in any RAII class that you don't explicitly use any more. It works without, but you get a warning about an unused variable which is annoying. QMutexLocker suffers from the same problem. I also don't like using a macro much, but it does yield quite an elegant way to say what you want I think. It also hides the explicit reference to this. You can still use the explicit way too of course, especially if you want to access the guard object afterwards (you can cancel it and access the original value for instance). I am currently not seeing a need to trigger anything else than the notification signal, but I guess that could be added if there is a need for that. André From mw_triad at users.sourceforge.net Wed Apr 15 18:44:21 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 15 Apr 2015 12:44:21 -0400 Subject: [Development] RFC: RAII for property changes In-Reply-To: <552E91ED.9000909@familiesomers.nl> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <552E91ED.9000909@familiesomers.nl> Message-ID: On 2015-04-15 12:29, Andre Somers wrote: > On 15-4-2015 17:08, Matthew Woehlke wrote: >> What about something like this? >> >> QPropertyGuard g{this}; >> g.addProperty("a"); // use QObject::property >> g.addProperty("b", m_b); // take value member by reference >> g.addProperty(m_c, &cChanged); // ...and also slot address >> >> It's slightly redundant because declaring the guard and adding a >> property are separate, but there is no unused object, and you can use >> the same guard for multiple properties. >> >> The implementation is trickier (probably you need a dynamically >> allocated templated helper class with a virtual base to store the value >> and check for changes), but avoids multiple string-based look-ups. >> >> The "slot" could be a functor, like QObject::connect accepts, that could >> be any of the actual slot, std::function, lambda, etc. > > I'm not sure I understand your solution, or what it yields over what I > am using now. Of course what I do is not using multiple string lookups. > The property is looked up once on construction of the guard object. Then > the current value is copied as a QVariant, as it is made available > through the property system. The signal meta-method is also stored from > the constructor, so the destructor can use it. So, only one > string-lookup needed per property. The elegance is that it uses the > property system to get the value *and* the notification signal to > trigger, so it is really easy to use. The second form would thus save the value <-> QVariant comparison and not much else. The third form however eliminates the string look-up entirely by having the user provide both the backing member variable *and* what to do when a change should be emitted. (I'd expect this to be the change signal most of the time, but taking a functor adds the flexibility of allowing users to do other things if needed.) > The need for a Q_UNUSED is inherent in any RAII class that you don't > explicitly use any more. It works without, but you get a warning about > an unused variable which is annoying. QMutexLocker suffers from the same > problem. "Yes", but separating the construction and property binding eliminates that (because you "used" the guard after all) and allows one guard to track multiple properties, with a potential saving in memory complexity. The down side is that it's a little more typing, so it's a trade-off. -- Matthew From kreios4004 at gmail.com Wed Apr 15 19:04:13 2015 From: kreios4004 at gmail.com (Keith Gardner) Date: Wed, 15 Apr 2015 17:04:13 +0000 Subject: [Development] RFC: RAII for property changes In-Reply-To: <552E8EFD.1000602@familiesomers.nl> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <552E8EFD.1000602@familiesomers.nl> Message-ID: > > I'd certainly be interested to seeing how you solved this, yes. Thanks! > I have made a repository for the class with an example. Sorry that there is no documentation for it. It requires C++11 support for r-value references, std::functional, and some type traits features. In addition to having a notify callback, it also provides an optional pre-notify callback to let you know the current value and the value it will change to. https://github.com/kreios4004/Property_Class -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Wed Apr 15 19:11:09 2015 From: andre at familiesomers.nl (Andre Somers) Date: Wed, 15 Apr 2015 19:11:09 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <552E91ED.9000909@familiesomers.nl> Message-ID: <552E9BAD.5000407@familiesomers.nl> On 15-4-2015 18:44, Matthew Woehlke wrote: > The second form would thus save the value <-> QVariant comparison and > not much else. The third form however eliminates the string look-up > entirely by having the user provide both the backing member variable > *and* what to do when a change should be emitted. (I'd expect this to > be the change signal most of the time, but taking a functor adds the > flexibility of allowing users to do other things if needed.) Right, of course. That may be useful indeed. Thank you for your feedback, it is apreciated! André From dangelog at gmail.com Wed Apr 15 19:18:15 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 15 Apr 2015 19:18:15 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <552E7C90.1060409@familiesomers.nl> Message-ID: On 15 April 2015 at 17:12, Matthew Woehlke wrote: > > Then the slot is broken. What if the sender needs to do something after > it delivers the signal? What if other slots are connected? Deleting a > signal sender from a slot connected to the signal is inherently > dangerous. Don't do it. For the record, there's some code in Qt to protect against this. I believe the entire signal emission mechanism is designed to work nonetheless (and tested), and you can probably grep for QPointer.*this (f.i. in widgets code) to see other interesting cases. But I agree it's damn difficult to design robust code this way. -- Giuseppe D'Angelo From 416365416c at gmail.com Wed Apr 15 19:55:12 2015 From: 416365416c at gmail.com (Alan Alpert) Date: Wed, 15 Apr 2015 10:55:12 -0700 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: On Wed, Apr 15, 2015 at 8:08 AM, Matthew Woehlke wrote: > On 2015-04-15 10:43, Marc Mutz wrote: >> On Wednesday 15 April 2015 11:49:56 André Somers wrote: >>> void MyClass::setFoo(QString value) >>> { >>> PropertyGuard guard(this, "foo"); //foo is the name of the Q_PROPERTY >>> Q_UNUSED(guard); >>> >>> m_foo = value; >>> } >> >> This is an interesting idea, though I don't think I have encountered the >> problems with which you motivate PropertyGuard. I have, it comes up a lot in objects used as an interface to QML (where every fooChanged signal will probably trigger binding re-evaluation or JS blocks). I don't think it's that hard to manage, but PropertyGuard does look easier and saves some boilerplate code. >> For use in a library, though, I fear the string-based mechanism is too >> inefficient. For use within QtWidgets, say, I'd suggest a mechanism that works >> on the member data directly. I think it's fine to tie it to the property system, since conceptually it needs a both a read and a notify on the datum. For performance, allow passing in a metaproperty index instead of a property name string. It will still invoke the getter, but they're rarely that complicated (and when they are, you need to go off the getter value*). > FWIW I had the same thought; also, I'm not a fan of needing the > Q_UNUSED, or using a macro to 'hide' it. > > What about something like this? > > QPropertyGuard g{this}; > g.addProperty("a"); // use QObject::property > g.addProperty("b", m_b); // take value member by reference > g.addProperty(m_c, &cChanged); // ...and also slot address > > It's slightly redundant because declaring the guard and adding a > property are separate, but there is no unused object, and you can use > the same guard for multiple properties. The common case is one property I think, so keep that case to one line. I'd envision using it in all my basic setters to save code at the start of a project, and then when the features start to creep in it's easier to add complexity into the setters. Still, you could always leave in a convenience constructor or just wrap it in a macro as before. * Example of when you need to go off getter value instead of member is usually sometime like implicit width, where the getter looks like getWidth() { if (m_width == -1) return m_implicitWidth; return m_width; } In this case, if you have m_width = 80, m_implicitWidth = 80, and call setWidth(-1), then you actually don't want to emit widthChanged even though m_width is updated. That was just an example, not how implicit width actually is implemented in QtQuick. -- Alan Alpert From mw_triad at users.sourceforge.net Wed Apr 15 20:23:12 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Wed, 15 Apr 2015 14:23:12 -0400 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: On 2015-04-15 13:55, Alan Alpert wrote: > The common case is one property I think, so keep that case to one > line. I'd envision using it in all my basic setters to save code at > the start of a project, and then when the features start to creep in > it's easier to add complexity into the setters. If you use the helper class always, sure. I was thinking I probably would not use it for the "easy" cases, i.e. where only one value changes, and instead use it only where it becomes more important to have the helper, in which case it's more likely you have two or more values. Anyway... > Still, you could always leave in a convenience constructor or just > wrap it in a macro as before. ...there's always this :-). The case with one property (or, for that matter, if you don't care about having multiple instances of the helper) can still use a macro to collapse the two lines of code that either version "needs". For that matter, the addProperty flavor doesn't preclude having convenience ctors that also call addProperty :-). -- Matthew From julien.cugniere at gmail.com Wed Apr 15 20:49:42 2015 From: julien.cugniere at gmail.com (=?ISO-8859-1?Q?Julien_Cugni=E8re?=) Date: Wed, 15 Apr 2015 20:49:42 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <2217591.37vjjWJZ09@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <3395724.3AFATvtSfp@tjmaciei-mobl4> <2217591.37vjjWJZ09@tjmaciei-mobl4> Message-ID: 2015-04-15 17:11 GMT+02:00 Thiago Macieira : > Not exactly. It all depends on what you define to be "works". I don't consider > resuming the event loop to be "works". I think that an uncaught exception > should exit the event loop and cause the application to exit, so I consider > your code above broken. It should rethrow after logging. > > But let's assume you have a good reason for continuing the event loop. You're > now in unsupported territory because you caught an exception in the middle of > the loop and resumed operations. The idea is that we have threads which serve requests from other threads through the use of slots. When an exception is thrown during the processing of such a slot, it means the request encountered a fatal error and was aborted. But the thread should continue executing and serving other requests. Same thing with a thread executing a periodic task through the use a QTimer. A particular execution of the task could fail through an exception, but the task can be retried the next time the timer fires. > The code above will continue to work for the main thread, but will stop > working for auxiliary threads. And there will be no work around. You will need > to do the right thing and stop any exceptions from going back to the signal- > slot mechanism and the event delivery mechanism. But this requires wrapping every single slot in a try/catch. Apart from the code churn (we have lots of those), this is repetitive and error-prone, as it's all too easy to add a new slot and forget the try/catch. The software is much more robust and maintainable if the catching of exceptions can be centralized. > If the problem is exceptions, we can simply add the exception protection > elsewhere in the stack, closer to where we actually call out to the event > handler or the slot. Our use of QCoreApplication::notify is intended to solve the problem I describe above by moving the try/catch one level up in the call stack : instead of doing it in the slot itself, we want it done in the caller of the slot. If notify is too far up the stack, it would be fine doing it closer to the user code. I suppose for slots you're thinking of qt_static_metacall or QMetaObject::activate. But ideally it would need to go through a user-supplied function, to be able to customize the type of exception caught, and the way they are handled (logged in our case). Wouldn't that bring the same kind of problem as QCoreApplication::notify ? Or if it can't go through a user supplied function, at the very least Qt should catch std::exception, and log its message through a user-customizable function (such as qWarning()). A simple catch(...) wouldn't be enough, as the text of the exception would be lost. > Do you need OpenGL or X11? Those use threads and they will probably continue > running even after your SomeApplication class's destructor has begun, which > means they may call your notify() during the destructor, including just after > it finished and ~QApplication began. It's a background service, so not really. But I suppose sooner or later we'll run into problems if some other part of Qt starts to use threads. By the way, thanks for taking the time of discussing this use-case. Julien Cugnière From marc.mutz at kdab.com Wed Apr 15 21:03:04 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Apr 2015 21:03:04 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> Message-ID: <201504152103.04891.marc.mutz@kdab.com> On Wednesday 15 April 2015 17:08:11 Matthew Woehlke wrote: > FWIW I had the same thought; also, I'm not a fan of needing the > Q_UNUSED, or using a macro to 'hide' it. I haven't had to use Q_UNUSED on a RAII object since iirc GCC 3 times. What broken compilers are you guys using? > What about something like this? > > QPropertyGuard g{this}; > g.addProperty("a"); // use QObject::property > g.addProperty("b", m_b); // take value member by reference > g.addProperty(m_c, &cChanged); // ...and also slot address There's type erasure going on, so it will allocate memory. Allocating memory in a setter that might just change an int is what I call inefficient. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kreios4004 at gmail.com Wed Apr 15 21:05:39 2015 From: kreios4004 at gmail.com (Keith Gardner) Date: Wed, 15 Apr 2015 19:05:39 +0000 Subject: [Development] RFC: RAII for property changes In-Reply-To: <201504152103.04891.marc.mutz@kdab.com> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <201504152103.04891.marc.mutz@kdab.com> Message-ID: > > > QPropertyGuard g{this}; > > g.addProperty("a"); // use QObject::property > > g.addProperty("b", m_b); // take value member by reference > > g.addProperty(m_c, &cChanged); // ...and also slot address > > There's type erasure going on, so it will allocate memory. Allocating > memory > in a setter that might just change an int is what I call inefficient. > Would something like this be better? // constructor // Provide an initial value and a std::function to notify about the change Property m_example = Property(false, [&](bool value){ emit exampleChanged(value); }); // getter bool *::example() const { return m_example; } // setter void *::setExample(bool value) { m_example = value; } The working code for this example can be found https://github.com/kreios4004/Property_Class. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Wed Apr 15 21:19:31 2015 From: andre at familiesomers.nl (Andre Somers) Date: Wed, 15 Apr 2015 21:19:31 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <201504152103.04891.marc.mutz@kdab.com> Message-ID: <552EB9C3.9020205@familiesomers.nl> On 15-4-2015 21:05, Keith Gardner wrote: > > > QPropertyGuard g{this}; > > g.addProperty("a"); // use QObject::property > > g.addProperty("b", m_b); // take value member by reference > > g.addProperty(m_c, &cChanged); // ...and also slot address > > There's type erasure going on, so it will allocate memory. > Allocating memory > in a setter that might just change an int is what I call inefficient. > > > Would something like this be better? > > // constructor > // Provide an initial value and a std::function to notify about the change > Property m_example = Property(false, [&](bool value){ > emit exampleChanged(value); > }); > > // getter > bool *::example() const { > return m_example; > } > > // setter > void *::setExample(bool value) { > m_example = value; > } > > The working code for this example can be found > https://github.com/kreios4004/Property_Class. > Thank you for posting that. I took a look at it, but I am not sure it actually solves much. It moves the check if something changed to the wrapped variable, but it makes using that value then more complicated. Instead of using the variable directly, one now has to go through m_example.getValue() everywhere. Not pretty, I think. The case of modifying more than one property in one go is also not solved. On the one hand, dependent properties (such a isValid property) are not updated unless you manually write that code again, and on the other hand if you use this to set more than one property in a method, you still are sending signals at the point the class is in an inconsistent state. One nice side effect of my implementation is that the notification is actually only send once. Even if the property value is changed multiple times in the meantime, you still get only one notification. That can be very convenient, even if you don't use it much. André -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Apr 15 21:33:12 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Apr 2015 21:33:12 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: <552E7C90.1060409@familiesomers.nl> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <552E7C90.1060409@familiesomers.nl> Message-ID: <201504152133.12199.marc.mutz@kdab.com> On Wednesday 15 April 2015 16:58:24 André Somers wrote: > Basically, if you have this code (or something like it) somewhere, you > already have a problem: > > void MyClass::setFooAndBar(QString foo, int bar) > { > if (m_foo != foo) { > m_foo = foo; > emit fooChanged(foo); //this is where things may start to go wrong > already > } > > if (m_bar != bar) { > m_bar = bar; > emit barChanged(bar); > } > } 1. This function has more than one responsibility. Functions with more than one responsibility are hard to get right, to maintain, and in general hard to make exception-safe. 2. This function doesn't have all-or-nothing / transactional semantics. That's basically both different way of saying that functions should be structured such that they: 1st perform anything that can fail _without_ modifying the state of the program 2nd commit the new state with never-fail operations 3rd clean up (this includes notification) > void MyClass::setFooAndBar(QString foo, int bar) > { > > bool fooHasChanged(false); > bool barHasChanged(false); > > if (m_foo != foo) { > > m_foo = foo; > fooHasChanged = true; > > } > > if (m_bar != bar) { > > m_bar = bar; > barHasChanged = true; > > } > > if (fooHasChanged) emit fooHasChanged(foo); > if (barHasChanged) emit barHasChanged(bar); // [...] > } This code still doesn't meet that goal. It first modifies m_foo. If the assignment to m_bar throws, then m_foo has been changed, but m_bar hasn't. void MyClass::setFooAndBar(QString foo, int bar) { const bool fooHasChanged = m_foo != foo; const bool barHasChanged = m_bar != bar; m_foo.swap(foo); m_bar = bar; // int can't throw if (fooHasChanged) emit fooHasChanged(m_foo); if (barHasChanged) emit barHasChanged(m_bar); } Untested code: #define EMIT_AT_SCOPE_EXIT_WHEN_CHANGED(value, signal) \ struct Guard##value { decltype(value) oldValue; decltype(value) &ref; ~Guard##value() { if (ref != oldValue) emit signal(ref); } } guard##value = { value, value }; For C++98, the type would have to be passed instead of using decltype. It's still less efficient than it could be, due to oldValue (imagine it being a std::vector), but that can be fixed at the cost of more arguments. Maybe a lot of this stuff can also be templatised, to effectively get something like: const GuardBase &valueGuard = guard(value, &signal); But if the call to signal in this local scope is still indirect, as it is with most function pointers, this is still a no-no, imo. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kreios4004 at gmail.com Wed Apr 15 21:29:02 2015 From: kreios4004 at gmail.com (Keith Gardner) Date: Wed, 15 Apr 2015 19:29:02 +0000 Subject: [Development] RFC: RAII for property changes In-Reply-To: <552EB9C3.9020205@familiesomers.nl> References: <552E3444.2080801@familiesomers.nl> <201504151643.50541.marc.mutz@kdab.com> <201504152103.04891.marc.mutz@kdab.com> <552EB9C3.9020205@familiesomers.nl> Message-ID: On Wed, Apr 15, 2015 at 2:20 PM Andre Somers wrote: > On 15-4-2015 21:05, Keith Gardner wrote: > > > QPropertyGuard g{this}; >> > g.addProperty("a"); // use QObject::property >> > g.addProperty("b", m_b); // take value member by reference >> > g.addProperty(m_c, &cChanged); // ...and also slot address >> >> There's type erasure going on, so it will allocate memory. Allocating >> memory >> in a setter that might just change an int is what I call inefficient. >> > > Would something like this be better? > > // constructor > // Provide an initial value and a std::function to notify about the change > Property m_example = Property(false, [&](bool value){ > emit exampleChanged(value); > }); > > // getter > bool *::example() const { > return m_example; > } > > // setter > void *::setExample(bool value) { > m_example = value; > } > > The working code for this example can be found > https://github.com/kreios4004/Property_Class. > > Thank you for posting that. > > I took a look at it, but I am not sure it actually solves much. It moves > the check if something changed to the wrapped variable, but it makes using > that value then more complicated. Instead of using the variable directly, > one now has to go through m_example.getValue() everywhere. > This is partially true. If it is containing a class or a struct, then you are correct. If it is an int or float and you want to perform some math operation with it, it has the operator const T&() to perform the get automatically. > Not pretty, I think. The case of modifying more than one property in one > go is also not solved. On the one hand, dependent properties (such a > isValid property) are not updated unless you manually write that code > again, and on the other hand if you use this to set more than one property > in a method, you still are sending signals at the point the class is in an > inconsistent state. > True. My goal was to perform a type safe way of change detection so I wouldn't have to write the boilerplate code over and over. It also provides a way customize the way the signal is called in the callback. It does suffer in the more complex scenarios when more than one operation is happening to the object. > One nice side effect of my implementation is that the notification is > actually only send once. Even if the property value is changed multiple > times in the meantime, you still get only one notification. That can be > very convenient, even if you don't use it much. > This is very appealing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Wed Apr 15 21:34:57 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 15 Apr 2015 21:34:57 +0200 Subject: [Development] RFC: RAII for property changes In-Reply-To: References: <552E3444.2080801@familiesomers.nl> <201504152103.04891.marc.mutz@kdab.com> Message-ID: <201504152134.57125.marc.mutz@kdab.com> On Wednesday 15 April 2015 21:05:39 Keith Gardner wrote: > Would something like this be better? > > std::function No, a std::function in general allocates memory and even if it uses the small object optimisation, the call to the lambda will still be indirect. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From thiago.macieira at intel.com Thu Apr 16 01:30:17 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 15 Apr 2015 16:30:17 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2217591.37vjjWJZ09@tjmaciei-mobl4> Message-ID: <4835744.TnRWj5NQDp@tjmaciei-mobl4> On Wednesday 15 April 2015 20:49:42 Julien Cugnière wrote: > The idea is that we have threads which serve requests from other > threads through the use of slots. When an exception is thrown during > the processing of such a slot, it means the request encountered a > fatal error and was aborted. But the thread should continue executing > and serving other requests. > > Same thing with a thread executing a periodic task through the use a > QTimer. A particular execution of the task could fail through an > exception, but the task can be retried the next time the timer fires. I understand what you're saying. My point is that handling error conditions from the functions you call is not part of events and the slot activator's job descriptions. It's your job. And since we do not guarantee that you won't crash before reaching notify() or leak resources, you're in unsupported land. I am willing to make it supported, but differently. > > The code above will continue to work for the main thread, but will stop > > working for auxiliary threads. And there will be no work around. You will > > need to do the right thing and stop any exceptions from going back to the > > signal- slot mechanism and the event delivery mechanism. > > But this requires wrapping every single slot in a try/catch. Apart > from the code churn (we have lots of those), this is repetitive and > error-prone, as it's all too easy to add a new slot and forget the > try/catch. The software is much more robust and maintainable if the > catching of exceptions can be centralized. I think we'll have to agree to disagree. One of the reasons I don't like exceptions is that I philosophically think that you should never have catch-alls. It means someone did not do their job right. My reasoning is that catch-alls indicate all the error details have been lost and the handler can only wield the big hammer as a solution (abort completely or continue despite the errors). > Our use of QCoreApplication::notify is intended to solve the problem I > describe above by moving the try/catch one level up in the call stack > > : instead of doing it in the slot itself, we want it done in the > > caller of the slot. > > If notify is too far up the stack, it would be fine doing it closer to > the user code. I suppose for slots you're thinking of > qt_static_metacall or QMetaObject::activate. Yes, QMetaObject::activate is the one I'm thinking of. > But ideally it would need to go through a user-supplied function, to > be able to customize the type of exception caught, and the way they > are handled (logged in our case). Wouldn't that bring the same kind of > problem as QCoreApplication::notify ? My idea is to provide you with the ability to: - decide whether to catch or not - supply a handler that will be called if an exception is caught - decide whether a caught exception resumes execution or aborts the application (after your handler) If you need access to the exception itself, you can use the C++ runtime to get it. > Or if it can't go through a user supplied function, at the very least > Qt should catch std::exception, and log its message through a > user-customizable function (such as qWarning()). A simple catch(...) > wouldn't be enough, as the text of the exception would be lost. See above. The runtime allows you to get it. But we could handle std::exception specially, indeed. > By the way, thanks for taking the time of discussing this use-case. No problem, input is welcome. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From julien.cugniere at gmail.com Thu Apr 16 11:25:29 2015 From: julien.cugniere at gmail.com (=?ISO-8859-1?Q?Julien_Cugni=E8re?=) Date: Thu, 16 Apr 2015 11:25:29 +0200 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <4835744.TnRWj5NQDp@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <2217591.37vjjWJZ09@tjmaciei-mobl4> <4835744.TnRWj5NQDp@tjmaciei-mobl4> Message-ID: 2015-04-16 1:30 GMT+02:00 Thiago Macieira : > My idea is to provide you with the ability to: > - decide whether to catch or not > - supply a handler that will be called if an exception is caught > - decide whether a caught exception resumes execution or aborts the > application (after your handler) > > If you need access to the exception itself, you can use the C++ runtime to get > it. Are you talking about std::exception_ptr and std::current_exception ? AFAIK that's C++11, but I'm fine with it. From jani.heikkinen at theqtcompany.com Thu Apr 16 12:13:21 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 16 Apr 2015 10:13:21 +0000 Subject: [Development] First Qt5.5 beta snapshot available Message-ID: <1429179201071.5458@theqtcompany.com> Hi all, We have finally first Qt5.5 beta snapshot available Linux: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-04-16_41/ Mac: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-04-16_23/ Win: http://download.qt.io/snapshots/qt/5.5/5.5.0-beta/2015-04-16_20/ Some installers are still missing but there is at least something to be able to start testing. So please test these packages & inform me if there is something blocking the beta. We are trying to get beta out quite soon so it is really important to understand if something necessary is missing or broken Qt5.5 beta blocker metabug: https://bugreports.qt.io/browse/QTBUG-44653 br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From qt at csipa.in.rs Thu Apr 16 12:27:20 2015 From: qt at csipa.in.rs (Attila Csipa) Date: Thu, 16 Apr 2015 13:27:20 +0300 Subject: [Development] QML bindings for native Android controls In-Reply-To: <0F585AFA-DA59-4A79-B355-F2F1296DB25B@theqtcompany.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <0F585AFA-DA59-4A79-B355-F2F1296DB25B@theqtcompany.com> Message-ID: <552F8E88.4050104@csipa.in.rs> On 4/13/2015 3:00 PM, Nurmi J-P wrote: > Indeed. UIs have come a long way since the days of Windows 95 and > others where it was sufficient to draw buttons and checkboxes a bit > differently. These days, UIs are full of little transitions and > effects. When those things are missing or slightly off, the UI feels > broken. Amen to that. When you not only try to reimplement everything a company on the scale of Google/Apple/Msft/etc did, but also try to do it in source compatible way, you're in for a lot of trouble. The choice is basically either the UI equivalent of death-by-a-thousand-papercuts you outlined or a really rough lowest-common-denominator approach (which is really low nowadays given all the various interaction patterns the different platforms have). Add to this the various multimedia and mobile API implications, it quickly becomes a compatibility-matrix lottery. If one wants a JavaScript-driven declarative UI that works on a "most of the time" basis, web/hybrid apps fill the need pretty well, even if 60fps interfaces are a bigger challenge (let's not mix bad JS code with tech limitations here). QtQuick is awesome if you want to make a custom UI (one of the reason it's doing so well in embedded space), but on real cross-platform (especially mobile) apps it's a bit out of the water, despite the progress of QtQuick.Controls, and IMO it will never quite "get there" given the constant flow of new OS versions, widgets, design patterns, etc. And, as I discovered, #ifdefs are a really poor way of handling cross-platform development (they are far better at feature-management than platform-management), so the old-school C++ approach is really not helping there either. What is sorely needed is a fast, prototyping-friendly and platform-agnostic way of doing UIs while relying on their native implementation of widgets, usage patterns, libraries etc. Yes, even if it means giving up the single-codebase dream. QML and it's C++ integration does this quite well (broken-by-design quirks notwithstanding), and that's why wrapper component-sets like this one are a giant step in the right direction. Best regards, Attila From qt at csipa.in.rs Thu Apr 16 12:32:54 2015 From: qt at csipa.in.rs (Attila Csipa) Date: Thu, 16 Apr 2015 13:32:54 +0300 Subject: [Development] QML bindings for native Android controls In-Reply-To: <03F75EFF-404C-44FB-90C7-949A55054ABA@theqtcompany.com> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BB2E3.4020003@mpaja.com> <03F75EFF-404C-44FB-90C7-949A55054ABA@theqtcompany.com> Message-ID: <552F8FD6.4010008@csipa.in.rs> IANAL but using "for Android" should be fine w both Google and Qt (just stick the TM notice in your docs). I'm leaning towards Controls for Android (or, maybe QML for Android). It can still have a name of it's own (pick your favorite dog name or noun), but a descriptive name would IMO go a long way to understand what this is about, especially as it can be confusing as to how it relates to other Qt modules and technologies. Best regards, Attila Csipa On 4/13/2015 3:58 PM, Nurmi J-P wrote: >> On 13 Apr 2015, at 14:13, Harri Pasanen wrote: >> >> Name candidates: QML-Droid or QDroid > Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories? > > http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt > >> Btw, can QML do layouting of Android widgets, or is that left for the >> android layout engine? > So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same. > > -- > J-P Nurmi > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Thu Apr 16 15:22:16 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 16 Apr 2015 15:22:16 +0200 Subject: [Development] memory corruption in moc when building Qt 5.4.0 Message-ID: <8171655.SnbyljdH70@patux> Hi, A bit of a long shot, but is it possible to infer anything from the linked-to build log explaining why I'm seeing a memory corruption abort in moc when building qtbase 5.4.0? https://launchpadlibrarian.net/203470318/buildlog_ubuntu-trusty-amd64.qtbase-opensource-src_5.4.0%2Bdfsg-4ubuntu1~trusty1~rjvb~ppa150416b_BUILDING.txt.gz This is using packaging that comes from Kubuntu's Qt 5.4 for 14.10 PPA backported to/for Ubuntu 14.04 . The i386 packages built fine; for the 64bit packages I've added "-O3 -march=amdfam10" to the CFLAGS, and use clang 3.5 (via the linux-clang mkspec). That approach worked fine with Qt 5.3.2 . My Linux system is severely underdimensioned for building even a part of Qt so my first attempt, if nothing can be said based on that build log, is to try with gcc 4.9 (and probably call it a day if ever that proves to work)... Thanks, R. From rjvbertin at gmail.com Thu Apr 16 16:13:08 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 16 Apr 2015 16:13:08 +0200 Subject: [Development] memory corruption in moc when building Qt 5.4.0 In-Reply-To: <20150416135308.GB399@x4> References: <8171655.SnbyljdH70@patux> <20150416135308.GB399@x4> Message-ID: <3228122.p4hFPN8r2t@portia.local> On Thursday April 16 2015 15:53:08 Markus Trippelsdorf wrote: > See: https://sourceware.org/bugzilla/show_bug.cgi?id=16992 > It is a gold bug that is fixed in binutils trunk. > So either update your binutils or use ld.bfd. Wow ... So it seems that this must be a case of using the gold ld together with one or several of the "incriminated" linker options from that bug report? I'm asking because - the i386 build uses the same linker (in 32bit version of course) and completes without issues - I've built Qt 4.8.7 in both 32bit and 64bit mode just fine today, in another of my PPAs. Both use gcc 4.9 though, but both also use the additional optimisation options. Thanks! R. From robertknight at gmail.com Thu Apr 16 16:16:37 2015 From: robertknight at gmail.com (Robert Knight) Date: Thu, 16 Apr 2015 15:16:37 +0100 Subject: [Development] QML bindings for native Android controls In-Reply-To: <552F8FD6.4010008@csipa.in.rs> References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BB2E3.4020003@mpaja.com> <03F75EFF-404C-44FB-90C7-949A55054ABA@theqtcompany.com> <552F8FD6.4010008@csipa.in.rs> Message-ID: > What is sorely needed is a fast, prototyping-friendly and > platform-agnostic way of doing UIs while relying on their native > implementation of widgets, usage patterns, libraries etc. Xamarin and React Native are aiming to get as close to that as feasible without compromising on design - which means that they explicit DON'T promise "write once, run anywhere" because the UX is not the same across platforms. What they promise instead is 'learn once, run anywhere' - that is, use the same language, tools and non-UI logic across apps. React Native is very new (but very promising) but I'd be interested to hear if anyone has experience of what development of large apps with Xamarin is like vs. Qt for mobile? On 16 April 2015 at 11:32, Attila Csipa wrote: > IANAL but using "for Android" should be fine w both Google and Qt (just > stick the TM notice in your docs). I'm leaning towards Controls for > Android (or, maybe QML for Android). It can still have a name of it's > own (pick your favorite dog name or noun), but a descriptive name would > IMO go a long way to understand what this is about, especially as it can > be confusing as to how it relates to other Qt modules and technologies. > > Best regards, > Attila Csipa > > On 4/13/2015 3:58 PM, Nurmi J-P wrote: >>> On 13 Apr 2015, at 14:13, Harri Pasanen wrote: >>> >>> Name candidates: QML-Droid or QDroid >> Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories? >> >> http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt >> >>> Btw, can QML do layouting of Android widgets, or is that left for the >>> android layout engine? >> So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same. >> >> -- >> J-P Nurmi >> >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Thu Apr 16 18:11:08 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Apr 2015 09:11:08 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <4835744.TnRWj5NQDp@tjmaciei-mobl4> Message-ID: <2273091.T6W6CLIHno@tjmaciei-mobl4> On Thursday 16 April 2015 11:25:29 Julien Cugnière wrote: > 2015-04-16 1:30 GMT+02:00 Thiago Macieira : > > My idea is to provide you with the ability to: > > - decide whether to catch or not > > - supply a handler that will be called if an exception is caught > > - decide whether a caught exception resumes execution or aborts the > > > > application (after your handler) > > > > If you need access to the exception itself, you can use the C++ runtime to > > get it. > > Are you talking about std::exception_ptr and std::current_exception ? > AFAIK that's C++11, but I'm fine with it. I am. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Thu Apr 16 19:39:43 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 16 Apr 2015 19:39:43 +0200 Subject: [Development] QFont qfontForThemeFont(ThemeFontID themeID) Message-ID: <1544001.E7Op9fdLkM@portia.local> Hi, Is the old QFont qfontForThemeFont(ThemeFontID themeID) from Qt 4 still used somewhere in Qt 5.4+ or is its prototype in qt_mac_p.h just a remnant? R. From ritt.ks at gmail.com Thu Apr 16 19:37:31 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 16 Apr 2015 21:37:31 +0400 Subject: [Development] QFont qfontForThemeFont(ThemeFontID themeID) In-Reply-To: <1544001.E7Op9fdLkM@portia.local> References: <1544001.E7Op9fdLkM@portia.local> Message-ID: AFAICT, there is no any more occurrences except in qt_mac_p.h Same for QColor qcolorForThemeTextColor(ThemeTextColor themeColor), BTW. Regards, Konstantin 2015-04-16 21:39 GMT+04:00 René J.V. : > Hi, > > Is the old QFont qfontForThemeFont(ThemeFontID themeID) from Qt 4 still > used somewhere in Qt 5.4+ or is its prototype in qt_mac_p.h just a remnant? > > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Apr 16 20:15:49 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 16 Apr 2015 20:15:49 +0200 Subject: [Development] QFont qfontForThemeFont(ThemeFontID themeID) (and initializeDb) In-Reply-To: References: <1544001.E7Op9fdLkM@portia.local> Message-ID: <2372280.KKP141a4V6@portia.local> On Thursday April 16 2015 21:37:31 Konstantin Ritt wrote: > AFAICT, there is no any more occurrences except in qt_mac_p.h > Same for QColor qcolorForThemeTextColor(ThemeTextColor themeColor), BTW. Ok, thanks, that certainly fits my observation. R From theonlylawislove at gmail.com Thu Apr 16 20:34:19 2015 From: theonlylawislove at gmail.com (Paul Knopf) Date: Thu, 16 Apr 2015 14:34:19 -0400 Subject: [Development] Qt OpenGL to the linux buffer via a platform plugin Message-ID: I have to implement a custom platform plugin that outputs the display directly the the linux framebuffer. I also need (or I should say, REALLY LIKE) support for Qt Quick, so I need to support OpenGL. I have the source code for qtbase open and I am trying to make sense of things. So I have some questions. Is there anything in platformsupport that could help render using OpenGL to a RGBA image to output to the framebuffer? eglconvience? Maybe some other classes somewhere I could use that don't depend on any type of platform such as X11/directfb/wayland/etc? Is there another platform that I could refer to help me here? What exactly is EGL within relation to QT? I see it used in a lot of different platforms. -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpnurmi at theqtcompany.com Thu Apr 16 23:01:29 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Thu, 16 Apr 2015 21:01:29 +0000 Subject: [Development] Playground request: QML for Android Message-ID: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> Hi, I'd like to request a new playground repository for "QML for Android" - http://lists.qt-project.org/pipermail/development/2015-April/021035.html Description: QML wrappers for native Android controls. Playground project name: qtqmlandroid QtQmlAndroid is what I've used as the working title. The playground guidelines say not to include a Qt-prefix, but a majority of the playground projects do... -- J-P Nurmi From thiago.macieira at intel.com Fri Apr 17 00:22:04 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Apr 2015 15:22:04 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <3242539.ldNOznXX6C@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <552E35B4.7050809@familiesomers.nl> <3242539.ldNOznXX6C@tjmaciei-mobl4> Message-ID: <1567295.rXlXyrHTPM@tjmaciei-mobl4> On Wednesday 15 April 2015 08:20:31 Thiago Macieira wrote: > Thanks André. The above contains two use-cases for overriding notify(): > > 1) catching exceptions, logging and resuming work > 2) debugging / inspecting events > So far, given the responses in the interest mailing list, it appears that applications would break imperceptibly for notify() no longer being called in the auxiliary threads. Therefore, I'm redesigning the solution. I'm proposing then the following: 1) deprecate use of notify() in auxiliary threads, with the functionality getting removed in Qt 6 (this is a documentation change only) 2) add a way for threads to individually enable delivery past the QCoreApplication's lifetime, which implies notify() is skipped. I will add this as a private API only. 3) add new mechanisms for filtering and logging events 4) add a mechanism to catch, log and gracefully act on exceptions thrown from event handlers and slots 5) after 3 and 4 are in, deprecate overriding of notify() altogether, with the possibility removed altogether in Qt 6. Since I only need 1 & 2 for my needs, I will not implement 3-5 any time soon (or ever). Exercise left to the reader. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Apr 17 02:32:45 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Apr 2015 17:32:45 -0700 Subject: [Development] Allowing event delivery prior to and after QCoreApplication In-Reply-To: <1567295.rXlXyrHTPM@tjmaciei-mobl4> References: <8416387.76gqJlHrfd@tjmaciei-mobl4> <3242539.ldNOznXX6C@tjmaciei-mobl4> <1567295.rXlXyrHTPM@tjmaciei-mobl4> Message-ID: <57256999.yZBtjKqjVh@tjmaciei-mobl4> On Thursday 16 April 2015 15:22:04 Thiago Macieira wrote: > 1) deprecate use of notify() in auxiliary threads, with the functionality > getting removed in Qt 6 (this is a documentation change only) https://codereview.qt-project.org/110644 > 2) add a way for threads to individually enable delivery past the > QCoreApplication's lifetime, which implies notify() is skipped. I will add > this as a private API only. https://codereview.qt-project.org/110643 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Apr 17 07:31:58 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 16 Apr 2015 22:31:58 -0700 Subject: [Development] The new headersclean is in In-Reply-To: <1431158.vZHUyleWdh@tjmaciei-mobl4> References: <2500160.ALHJcDGujs@tjmaciei-mobl4> <1431158.vZHUyleWdh@tjmaciei-mobl4> Message-ID: <1626249.IYHZ9gqLgH@tjmaciei-mobl4> Now it merged. On Friday 10 April 2015 13:16:30 Thiago Macieira wrote: > Oops, it's not in. It was another commit that went in, the one that removed > the old headersclean. > > On Friday 10 April 2015 09:28:02 Thiago Macieira wrote: > > As discussed in previous threads. > > > > This is just a reminder because the compilation time for anyone using the > > option -developer-build is now increasing by 25-33%. If you need to bypass > > this option, pass -no-headersclean to your configure script. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rainer.keller at theqtcompany.com Fri Apr 17 09:10:43 2015 From: rainer.keller at theqtcompany.com (Rainer Keller) Date: Fri, 17 Apr 2015 09:10:43 +0200 Subject: [Development] Rotating JPEG images by default Message-ID: <5530B1F3.4080501@theqtcompany.com> Hi, there was a change to introduce handling of exif orientation when loading JPEG images. Two bugreports complaining Qt is not handling image orientation caused me to fix this. But now we got bugreports claiming the opposite. In my opinion the orientation information is an essential part of the image and should be applied by default. Taking a picture with your camera users would expect it to look the same in a QImage as it was taken. Therefor it should respect the orientation by default. There are different implementations on other projects. For TIFF format the rotation is also applied. But in webbrowsers the rotation is usually not handled and must be enabled by an additional CSS flag. Regards, Rainer From laszlo.agocs at theqtcompany.com Fri Apr 17 10:08:16 2015 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Fri, 17 Apr 2015 08:08:16 +0000 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5530B1F3.4080501@theqtcompany.com> References: <5530B1F3.4080501@theqtcompany.com> Message-ID: <1429258110380.33705@theqtcompany.com> Hi Rainer, Which bug reports are we talking about? Are you saying that newer versions of Qt would automatically apply rotation to certain images? That's clearly a regression and cannot be done by default. At this stage it can be an opt-in feature at best. The difference to formats like TIFF is unfortunate. Ideally none of the image plugins should apply such smartness automatically (there can be other use cases where we want the pixels as in the file, not everything is a photo viewer application). Instead, there should have been a QImageReader level API to enable this. BR, Laszlo ________________________________________ From: development-bounces+laszlo.agocs=theqtcompany.com at qt-project.org on behalf of Rainer Keller Sent: Friday, April 17, 2015 9:10 AM To: development at qt-project.org Subject: [Development] Rotating JPEG images by default Hi, there was a change to introduce handling of exif orientation when loading JPEG images. Two bugreports complaining Qt is not handling image orientation caused me to fix this. But now we got bugreports claiming the opposite. In my opinion the orientation information is an essential part of the image and should be applied by default. Taking a picture with your camera users would expect it to look the same in a QImage as it was taken. Therefor it should respect the orientation by default. There are different implementations on other projects. For TIFF format the rotation is also applied. But in webbrowsers the rotation is usually not handled and must be enabled by an additional CSS flag. Regards, Rainer _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From rainer.keller at theqtcompany.com Fri Apr 17 10:13:47 2015 From: rainer.keller at theqtcompany.com (Rainer Keller) Date: Fri, 17 Apr 2015 10:13:47 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <1429258110380.33705@theqtcompany.com> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> Message-ID: <5530C0BB.5000607@theqtcompany.com> > Which bug reports are we talking about? https://bugreports.qt.io/browse/QTBUG-37946 https://bugreports.qt.io/browse/QTBUG-45552 From kde at carewolf.com Fri Apr 17 10:48:09 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 17 Apr 2015 10:48:09 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <1429258110380.33705@theqtcompany.com> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> Message-ID: <201504171048.09913.kde@carewolf.com> On Friday 17 April 2015, Agocs Laszlo wrote: > The difference to formats like TIFF is unfortunate. Ideally none of the > image plugins should apply such smartness automatically (there can be > other use cases where we want the pixels as in the file, not everything is > a photo viewer application). Instead, there should have been a > QImageReader level API to enable this. > If we go with the QImageReader level, it could be an QImageIOHandler::Option, and possibly be set different between JPEG and TIFF by default. The real problem is what we decide the default for JPEG should be now. Ideally the orientation could also be kept as metadata in QImage. `Allan From Friedemann.Kleint at theqtcompany.com Fri Apr 17 11:37:52 2015 From: Friedemann.Kleint at theqtcompany.com (Friedemann Kleint) Date: Fri, 17 Apr 2015 11:37:52 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <201504171048.09913.kde@carewolf.com> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> Message-ID: <5530D470.2010601@theqtcompany.com> Hi, >>If we go with the QImageReader level, it could be an QImageIOHandler::Option, >and possibly be set different between JPEG and TIFF by default. The real >problem is what we decide the default for JPEG should be now. Can we add an API making this settable until the beta? - I think automatic rotation is a really cool feature for any viewer-like application and saves writing a lot of quite advanced code (using memory mapping of files and endian-dependent word fiddling on platforms that don't have libexif or similar). Regards, Friedemann -- Friedemann Kleint | The Qt Company From Morten.Sorvig at theqtcompany.com Fri Apr 17 11:46:52 2015 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Fri, 17 Apr 2015 09:46:52 +0000 Subject: [Development] Rotating JPEG images by default In-Reply-To: <201504171048.09913.kde@carewolf.com> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> Message-ID: <936223B2-F42D-4CC6-B6E1-EDEB2BF29C17@digia.com> > On 17 Apr 2015, at 10:48, Allan Sandfeld Jensen wrote: > > > Ideally the orientation could also be kept as metadata in QImage. I’d like to see general metadata support in QImage. The closest thing we have seems to be QImage::text(), which supports QString data only. My specific use case setting and preserving the NSImage “template” property [1] across QImage -> NSImage conversions. This does not really deserve a separate setter/getter: a key/value API would be ideal. Morten [1]https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSImage_Class/index.html#//apple_ref/occ/instm/NSImage/setTemplate: From olivier at woboq.com Fri Apr 17 11:51:34 2015 From: olivier at woboq.com (Olivier Goffart) Date: Fri, 17 Apr 2015 11:51:34 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5530D470.2010601@theqtcompany.com> References: <5530B1F3.4080501@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <5530D470.2010601@theqtcompany.com> Message-ID: <1590666.ZaOuuGZdr5@finn> On Friday 17. April 2015 11:37:52 Friedemann Kleint wrote: > Hi, > > >>If we go with the QImageReader level, it could be an > > QImageIOHandler::Option, > > >and possibly be set different between JPEG and TIFF by default. The real > >problem is what we decide the default for JPEG should be now. > > Can we add an API making this settable until the beta? - I think > automatic rotation is a really cool feature for any viewer-like > application and saves writing a lot of quite advanced code (using memory > mapping of files and endian-dependent word fiddling on platforms that > don't have libexif or similar). Personally, I was really happy to see that fixed. I even backported it to 5.3 for a customer. The use case is that we have code like QPixmap myPixmap(fileName); So the API should span in many places QImage, QPixmap, QImageReader, QImageIOHandler, ... It is true that it is a behaviour change. But now it is too late anyway, and reverting the patch would make another behaviour change. The question is if there are application that need to access the original orientation. And I think it might make sens to have such metadata available form QImage or so (we have QImage::text already) But at this point, I suppose that if we really need it, it should wait Qt 5.6 -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From kde at carewolf.com Fri Apr 17 12:10:22 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 17 Apr 2015 12:10:22 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <936223B2-F42D-4CC6-B6E1-EDEB2BF29C17@digia.com> References: <5530B1F3.4080501@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <936223B2-F42D-4CC6-B6E1-EDEB2BF29C17@digia.com> Message-ID: <201504171210.22706.kde@carewolf.com> On Friday 17 April 2015, Sorvig Morten wrote: > > On 17 Apr 2015, at 10:48, Allan Sandfeld Jensen wrote: > > > > > > Ideally the orientation could also be kept as metadata in QImage. > > I’d like to see general metadata support in QImage. The closest thing we > have seems to be QImage::text(), which supports QString data only. > > My specific use case setting and preserving the NSImage “template” property > [1] across QImage -> NSImage conversions. This does not really deserve a > separate setter/getter: a key/value API would be ideal. > I tried starting on a possible API, just to see if it could be done: https://codereview.qt-project.org/#/c/110685/ `Allan From Shawn.Rutledge at theqtcompany.com Fri Apr 17 12:44:10 2015 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Fri, 17 Apr 2015 10:44:10 +0000 Subject: [Development] Rotating JPEG images by default In-Reply-To: <201504171210.22706.kde@carewolf.com> References: <5530B1F3.4080501@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <936223B2-F42D-4CC6-B6E1-EDEB2BF29C17@digia.com> <201504171210.22706.kde@carewolf.com> Message-ID: <7261F03B-21B7-4226-9E16-D9133E7315DE@digia.com> On 17 Apr 2015, at 12:10, Allan Sandfeld Jensen wrote: > On Friday 17 April 2015, Sorvig Morten wrote: >>> On 17 Apr 2015, at 10:48, Allan Sandfeld Jensen wrote: >>> >>> >>> Ideally the orientation could also be kept as metadata in QImage. >> >> I’d like to see general metadata support in QImage. The closest thing we >> have seems to be QImage::text(), which supports QString data only. >> >> My specific use case setting and preserving the NSImage “template” property >> [1] across QImage -> NSImage conversions. This does not really deserve a >> separate setter/getter: a key/value API would be ideal. >> > I tried starting on a possible API, just to see if it could be done: > https://codereview.qt-project.org/#/c/110685/ QTBUG-22367 needs to get fixed too, which I was trying to do here https://codereview.qt-project.org/#/c/101084/ and I have a patch to show metadata in the imageviewer example https://codereview.qt-project.org/#/c/101083/ From rjvbertin at gmail.com Fri Apr 17 13:43:37 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 17 Apr 2015 13:43:37 +0200 Subject: [Development] memory corruption in moc when building Qt 5.4.0 In-Reply-To: <20150416141029.GC399@x4> References: <8171655.SnbyljdH70@patux> <3228122.p4hFPN8r2t@portia.local> <20150416141029.GC399@x4> Message-ID: <2443881.HTmnVCIPX3@patux> On Thursday April 16 2015 16:10:29 Markus Trippelsdorf wrote: >Well, it could also be another issue. See if switching to ld.bfd fixes >the issue for you. If not, it might be a compiler bug. Turns out you were right. I don't know if this is actually a more or less known bug (or a variant of one), but the qtbase/configure script has a -no-use-gold-linker option. Using that for the clang/64bit build fixed the issue. Thanks! R. From kde at carewolf.com Fri Apr 17 14:19:01 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 17 Apr 2015 14:19:01 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5530B1F3.4080501@theqtcompany.com> References: <5530B1F3.4080501@theqtcompany.com> Message-ID: <201504171419.01755.kde@carewolf.com> On Friday 17 April 2015, Rainer Keller wrote: > Hi, > > there was a change to introduce handling of exif orientation when > loading JPEG images. > Two bugreports complaining Qt is not handling image orientation caused > me to fix this. But now we got bugreports claiming the opposite. > > In my opinion the orientation information is an essential part of the > image and should be applied by default. Taking a picture with your > camera users would expect it to look the same in a QImage as it was > taken. Therefor it should respect the orientation by default. > > There are different implementations on other projects. For TIFF format > the rotation is also applied. But in webbrowsers the rotation is usually > not handled and must be enabled by an additional CSS flag. > I would like to mention one extra relevant detail. While this was implemented for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So sofar only 5.4.1 has had EXIF orientation automatically applied on JPEGs. This also raises the question about what to do for 5.4.2? Best regards `Allan From rainer.keller at theqtcompany.com Fri Apr 17 14:23:50 2015 From: rainer.keller at theqtcompany.com (Rainer Keller) Date: Fri, 17 Apr 2015 14:23:50 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <201504171419.01755.kde@carewolf.com> References: <5530B1F3.4080501@theqtcompany.com> <201504171419.01755.kde@carewolf.com> Message-ID: <5530FB56.4020506@theqtcompany.com> > I would like to mention one extra relevant detail. While this was implemented > for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So sofar > only 5.4.1 has had EXIF orientation automatically applied on JPEGs. This also > raises the question about what to do for 5.4.2? I actually worked, theoretically. There was a bug with the endianess when reading the data field. It worked when data was generated on little endian machines but all photo cameras are big endian. This means only photos taken on x86 machines would have been rotated. From qt at csipa.in.rs Fri Apr 17 15:58:46 2015 From: qt at csipa.in.rs (Attila Csipa) Date: Fri, 17 Apr 2015 16:58:46 +0300 Subject: [Development] QML bindings for native Android controls In-Reply-To: References: <0CE2507A-79EC-492A-83BC-685013FE1F75@theqtcompany.com> <67B37BC2-40CB-484D-A121-48A92F88B482@theqtcompany.com> <552BB2E3.4020003@mpaja.com> <03F75EFF-404C-44FB-90C7-949A55054ABA@theqtcompany.com> <552F8FD6.4010008@csipa.in.rs> Message-ID: <55311196.1010907@csipa.in.rs> Hi, IMO Xamarin has (or at least had) a more modern approach, and since mobile was their bread-and-butter, they put a lot of effort there, and it really shows. I have some experience with it, so (again IMO) various gotchas notwithstanding, on *mobile*, it is considerably more mature than the Qt offering of today, even if I prefer QML over XAML any day. The way I see it, Qt's strong points are really in the desktop/embedded area and the (L)GPL licensing. I'm a bit afraid Xamarin will give in to the dark side (Xamarin.Forms and the related tooling does try to sell the single shared codebase dream, even if it's backed by native controls). No real experiences with React Native yet... Best regards, Attila On 4/16/2015 5:16 PM, Robert Knight wrote: >> What is sorely needed is a fast, prototyping-friendly and >> platform-agnostic way of doing UIs while relying on their native >> implementation of widgets, usage patterns, libraries etc. > Xamarin and React Native are aiming to get as close to that as > feasible without compromising > on design - which means that they explicit DON'T promise "write once, > run anywhere" because > the UX is not the same across platforms. > > What they promise instead is 'learn once, run anywhere' - that is, use > the same language, tools and non-UI > logic across apps. > > React Native is very new (but very promising) but I'd be interested to > hear if anyone has experience of what development of large > apps with Xamarin is like vs. Qt for mobile? > > > On 16 April 2015 at 11:32, Attila Csipa wrote: >> IANAL but using "for Android" should be fine w both Google and Qt (just >> stick the TM notice in your docs). I'm leaning towards Controls for >> Android (or, maybe QML for Android). It can still have a name of it's >> own (pick your favorite dog name or noun), but a descriptive name would >> IMO go a long way to understand what this is about, especially as it can >> be confusing as to how it relates to other Qt modules and technologies. >> >> Best regards, >> Attila Csipa >> >> On 4/13/2015 3:58 PM, Nurmi J-P wrote: >>>> On 13 Apr 2015, at 14:13, Harri Pasanen wrote: >>>> >>>> Name candidates: QML-Droid or QDroid >>> Various derivatives from Droid seem to be popular. Does it not fall to the “any play on names” or “slang in names” categories? >>> >>> http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt >>> >>>> Btw, can QML do layouting of Android widgets, or is that left for the >>>> android layout engine? >>> So far I have just exposed the Android layouts, but implementing anchors is on the wishlist. That would make Qt Quick developers feel at home. Android’s RelativeLayout does not quite feel the same. >>> >>> -- >>> J-P Nurmi >>> >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From theonlylawislove at gmail.com Fri Apr 17 16:20:53 2015 From: theonlylawislove at gmail.com (Paul Knopf) Date: Fri, 17 Apr 2015 10:20:53 -0400 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. Message-ID: I am testing the 'minimal' platform (mine is based off of it), and it seems that is doesn't render the alpha channel (setting opacity). Here is a gist of my main function testing the opacity. The saved images seems to have a tan background and no transparency. Any ideas on how to get the alpha channel represented in the platform backing store? -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From laszlo.agocs at theqtcompany.com Fri Apr 17 16:32:15 2015 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Fri, 17 Apr 2015 14:32:15 +0000 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. In-Reply-To: References: Message-ID: You do have alpha because the minimal's backingstore uses ARGB32_Premultiplied for the backing QImage. What you do not have is setWindowOpacity(). You would need to implement QPlatformWindow::setOpacity() for that, but that is not possible with minimal since there is no compositor that could apply the opacity to the window contents during the composition step. Best regards, Laszlo From: Paul Knopf > Date: Friday 17 April 2015 16:20 To: "development at qt-project.org" > Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. I am testing the 'minimal' platform (mine is based off of it), and it seems that is doesn't render the alpha channel (setting opacity). Here is a gist of my main function testing the opacity. The saved images seems to have a tan background and no transparency. Any ideas on how to get the alpha channel represented in the platform backing store? -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpnurmi at theqtcompany.com Fri Apr 17 17:13:46 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Fri, 17 Apr 2015 15:13:46 +0000 Subject: [Development] Playground request: QML for Android In-Reply-To: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> References: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> Message-ID: <20F19BD7-4CA5-4AC7-B061-E6D06A399CD1@theqtcompany.com> > On 16 Apr 2015, at 23:01, Nurmi J-P wrote: > > Hi, > > I'd like to request a new playground repository for "QML for Android" - http://lists.qt-project.org/pipermail/development/2015-April/021035.html > > Description: QML wrappers for native Android controls. > Playground project name: qtqmlandroid > > QtQmlAndroid is what I've used as the working title. The playground guidelines say not to include a Qt-prefix, but a majority of the playground projects do... > > -- > J-P Nurmi A big thanks to everyone who participated in brainstorming the name. The source code is now available at http://code.qt.io/cgit/playground/qtqmlandroid.git/. Contributions welcome! ;) Quoting the README file: ## Requirements - Qt 5 dev (5.6.0) - Android 5.x - Gradle ## Installation Build like any Qt module. It might be necessary to run 'make install' in 'src/java' until the build system is finalized. ## Qt Creator When building the example in Qt Creator, tick "Use Gradle" in Projects -> Build & Run -> Build Steps -> Build Android APK ## Notes The Android 5.x dependency is not going to stay. Proper Android version handling is just missing for the time being. The goal of the hackathon project was to create a visually stunning demo. -- J-P Nurmi From theonlylawislove at gmail.com Fri Apr 17 17:45:12 2015 From: theonlylawislove at gmail.com (Paul Knopf) Date: Fri, 17 Apr 2015 11:45:12 -0400 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. In-Reply-To: References: Message-ID: What do you mean when you say "compositor"? Are you referring to a window system? Is this something that is possible to implement with the minimal project? What would have to change? I have need a custom platform that encodes the ARGB (proprietary, vendor specific) to the linux framebuffer, but the alpha channel has to actually be correct. How come I can do this without a compositor? QImage bitmap(widget.size(), QImage::Format_ARGB32); bitmap.fill(Qt::transparent); QPainter painter(&bitmap); widget.render(&painter, QPoint(), QRegion(), QWidget::DrawChildren); bitmap.save("file.png"); There must be a way to achieve the same result using a platform plugin. If all else fails, I could create my own thread loop that renders the QWidget with the above code and outputs it to my driver manually, instead of going through the platform plugins, but I would like to support the platform plugin so that I can then switch it out to develop locally using standard Qt platforms (X11, etc). On Fri, Apr 17, 2015 at 10:32 AM, Agocs Laszlo < laszlo.agocs at theqtcompany.com> wrote: > You do have alpha because the minimal's backingstore uses > ARGB32_Premultiplied for the backing QImage. > > What you do not have is setWindowOpacity(). You would need to implement > QPlatformWindow::setOpacity() for that, but that is not possible with > minimal since there is no compositor that could apply the opacity to the > window contents during the composition step. > > Best regards, > Laszlo > > From: Paul Knopf > Date: Friday 17 April 2015 16:20 > To: "development at qt-project.org" > Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. > > I am testing the 'minimal' platform (mine is based off of it), and it > seems that is doesn't render the alpha channel (setting opacity). > > Here is a gist of > my main function testing the opacity. > > The saved images seems to have a tan background and no transparency. > > Any ideas on how to get the alpha channel represented in the platform > backing store? > > -- > Thanks! > > ~Paul > -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Sat Apr 18 12:34:53 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 18 Apr 2015 12:34:53 +0200 Subject: [Development] font selection and weight/style support on OS X: (possible regression from Qt 4 to Qt 5 Message-ID: <15210738.zbxxOWR6gp@patux> Hello, The specific question: how/where is (QFontEngine *)fe->ctfont set that is read in QFontDialogPrivate::setFont (qfontdialog_mac.mm around line 514)? I have been looking into an issue with the selection of fonts in weights/styles that don't follow the usual four suspects (Normal, Italic, Bold, Bold-Italic). In stock Qt 4.8, selecting a Medium or Semi Bold weight (i.e. a weight between normal and bold) works during the initial selection (say in qtconfig's default font selection), but open the font dialog once more, or relaunch the application, and that medium weight will have been replaced by standard bold. I think I have a fix for this in Qt 4.8, which removes the "easy shortcut" I found in 2 places ("there's Normal and anything heavier which becomes Bold") and extends the weight string parser to support most of the font weights you'll find on a typical OS X install. It turns out that almost inevitably I came up with code that looks a lot like what had already been done for Qt 5.4 (I swear, I didn't peak :)) except that I didn't introduce additional const variables to complement the existing QFont::DemiBold etc. styles. We're getting to the question. When opening the font dialog with an initial font, Qt 4 calls QFontDialogPrivate::setFont() where Qt 5.4 uses QCocoaFontPanel::setCurrentFont() . Both functions (can) use [NSFontManager fontWithFamily:traits:weight:size], but the Qt4 version is actually called with fe->ctfont already set to the appropriate NSFont*. And that seems to work more reliably. I have several fonts on my system (including the Apple-provided Avenir family) where fontWithFamily:traits:weight:size does *not* return the requested typeface, as if the weight parameter is ignored. And indeed the documentation for that function suggests that the weight parameter is used as a hint only (https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFontManager_Class/index.html#//apple_ref/occ/instm/NSFontManager/fontWithFamily:traits:weight:size:) though I *hope* that it's used as more than a hint when the requested weight actually exists. Hence my question: where is fe->ctfont initialised? Clearly this uses a different method for obtaining the NSFont (or CFFontRef). Note that I've already tried to put all chances on my side for weight: to be used as more than a hint. I've analysed the weights in question for all fonts on my system (Apple's documentation doesn't bother to document the exact value mapping), and came up with the following + // RJVB + // Thin,Light -> 3, Book -> 4 + // Normal/Regular -> 5 + // Medium/SemiBold/Demibold -> 6,7,8 + // Bold -> 9 + // Ultra/Black/Heavy -> 10,11 + QByteArray *weights = NULL; + switch (font.weight()) { + case QFont::Light: + weights = new QByteArray((const char[]){3,4}); + break; + case QFont::Normal: + weights = new QByteArray((const char[]){5}); + break; + case QFont::DemiBold: + weights = new QByteArray((const char[]){6,7,8}); + break; + case QFont::Bold: + weights = new QByteArray((const char[]){9}); + break; + case QFont::Black: + weights = new QByteArray((const char[]){10,11}); + break; } (evidently I did the same for Apple's other scale, that goes from -1.0 to 1.0). I then test each of the weights corresponding to font.weight(): + if (weights) { + nsFont = NULL; + for (int i = 0 ; i < weights->size() && !nsFont ; ++i) { + weight = (int) (*weights)[i]; + nsFont = [mgr fontWithFamily:qt_mac_QStringToNSString(fontInfo.family()) + traits:mask + weight:weight + size:fontInfo.pointSize()]; + } + delete weights; + } the only thing I haven't yet added is an additional check whether fontWithFamily did indeed return the requested weight, and not the closest lower match (which would let DemiBold downgrade to Normal, or Ultra to Bold). Thanks for bearing with me, and (even more :)) for any feedback! R. From rpzrpzrpz at gmail.com Sat Apr 18 17:47:28 2015 From: rpzrpzrpz at gmail.com (mark diener) Date: Sat, 18 Apr 2015 09:47:28 -0600 Subject: [Development] Building Modules Message-ID: Hello: How does one remove a submodule from a git repository build? (even if I already downloaded it) In this case, I want qlalr submodule to be removed from the build process. Qlalr does not build on Windows Any responses, thanks. Mark -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpzrpzrpz at gmail.com Sat Apr 18 18:02:19 2015 From: rpzrpzrpz at gmail.com (mark diener) Date: Sat, 18 Apr 2015 10:02:19 -0600 Subject: [Development] Modules and skip Message-ID: Hello: The following table lists the Qt essentials. I am building Qt from scratch and I am having a bit of trouble finding where the modules that I can remove from the build are located. Generally in configure, there are -skip directives For example: configure -skip qtserialport Where can I find the comprehensive list of names and what I can skip on configure? How can I remove qtnetwork when the NetworkAccessManager seems to be tied to the gman = view()->engine()->NetworkAccessmanager() ; This implies the network code is not properly isolated from the GUI layer. How to break this linkage without major source code changes? Thanks, Mark ModuleDescription Qt Core Core non-graphical classes used by other modules. Qt GUI Base classes for graphical user interface (GUI) components. Includes OpenGL. Qt Multimedia Classes for audio, video, radio and camera functionality. Qt Multimedia Widgets Widget-based classes for implementing multimedia functionality. Qt Network Classes to make network programming easier and more portable. Qt QML Classes for QML and JavaScript languages. Qt Quick A declarative framework for building highly dynamic applications with custom user interfaces. Qt Quick Controls Reusable Qt Quick based UI controls to create classic desktop-style user interfaces. Qt Quick Dialogs Types for creating and interacting with system dialogs from a Qt Quick application. Qt Quick Layouts Layouts are items that are used to arrange Qt Quick 2 based items in the user interface. Qt SQL Classes for database integration using SQL. Qt Test Classes for unit testing Qt applications and libraries. Qt WebKit Classes for a WebKit2 based implementation and a new QML API. See also Qt WebKit Widgets in the add-on modules. Qt WebKit Widgets WebKit1 and QWidget -based classes from Qt 4. Qt Widgets Classes to extend Qt GUI with C++ widgets. If you use qmake to build your projects, the Qt Core and Qt GUI modules are included by default. To link only against Qt Core, add the following line to your .pro file: QT -= gui On Windows, if you do not use qmake or other build tools such as CMake , you also need to link against the qtmain library. Qt Add-Ons *Qt Add-On* modules bring additional value for specific purposes. These modules may only be available on some development platform. Many add-on modules are either feature-complete and exist for backwards compatibility, or are only applicable to certain platforms. Each add-on module specifies its compatibility promise separately. The Qt installers include the option of downloading the add-ons. For more information, visit the Getting Started with Qt page. The following table lists the Qt add-ons: ModuleDevelopment PlatformsTarget PlatformsDescription Active Qt Windows Classes for applications which use ActiveX and COM Enginio AllAllA Backend-as-a-Service solution to ease the backend development for connected and data-driven applications. Qt Android Extras AllAndroid Provides platform-specific APIs for Android. Qt Bluetooth All Android , Linux , Blackberry Provides access to Bluetooth hardware. Qt Concurrent Classes for writing multi-threaded programs without using low-level threading primitives. Qt D-Bus All Classes for inter-process communication over the D-Bus protocol. Qt Graphical Effects All Graphical effects for use with Qt Quick 2. Qt Image Formats All Plugins for additional image formats: TIFF, MNG, TGA, WBMP. Qt Mac Extras AllOS X Provides platform-specific APIs for OS X. Qt NFC AllBlackberry Provides access to Near-Field communication (NFC) hardware. Qt OpenGL OpenGL support classes. *Note: *Provided to ease porting from Qt 4.x. Please use the QOpenGL classes in Qt GUI for new code Qt Platform Headers Provides classes that encapsulate platform-specific information, tied to a given runtime configuration of a platform plugin . Qt Positioning All Provides access to position, satellite and area monitoring classes. Qt Print Support All Classes to make printing easier and more portable. Qt Declarative All Qt Declarative is provided for Qt 4 compatibility. The documentation is available through the Qt 4.8 Qt Quick documentation. Qt Script All Classes for making Qt applications scriptable. Provided for Qt 4.x compatibility. Please use the QJS* classes in the Qt QML module for new code. Qt Script Tools All Additional components for applications that use Qt Script . Qt Sensors AllAndroid , Blackberry , Qt for iOS , WinRT and Mer.Provides access to sensor hardware and motion gesture recognition. Qt Serial Port AllWindows , Linux , and OS X .Provides access to hardware and virtual serial ports. Qt SVG All Classes for displaying the contents of SVG files. Supports a subset of the SVG 1.2 Tiny standard. Qt WebChannel AllAllProvides access to QObject or QML objects from HTML clients for seamless integration of Qt applications with HTML/JavaScript clients. Qt WebEngine All Windows , Linux , and OS X .Provides a QML API to run web applications using the Chromium browser project . Qt WebEngine Widgets All Windows , Linux , and OS X .Provides a C++ API to run web applications using the Chromium browser project . Qt WebSockets AllAllProvides WebSocket communication compliant with RFC 6455 . Qt Windows Extras AllWindows Provides platform-specific APIs for Windows. Qt X11 Extras All Linux/X11 Provides platform-specific APIs for X11. Qt XML C++ implementations of SAX and DOM. *Note: *Deprecated, please use QXmlStreamReader and QXmlStreamWriter for new functionality. Qt XML Patterns Support for XPath, XQuery , XSLT and XML schema validation. Value-Add Modules In addition to the modules released as part of Qt 5, the following modules and tooling build on top of the Qt libraries to provide additional value. They have their own release schedule, and are available under different Qt licenses. See the Downloads page for more information. FeatureDescription Qt for Device Creation Tools for fast, easy, and fully-integrated embedded device application development. Includes most other Value-Add features. Qt Charts UI Components for displaying visually pleasing charts, driven by static or dynamic data models. Qt Quick Compiler Enables compiling .qml source files into application binaries, improving load times and security for code assets. Qt Quick Enterprise Controls A set of advanced UI controls with an industry-specific look-and-feel. Qt Data Visualization UI Components for creating stunning 3D data visualizations. Qt Purchasing Enables in-app purchase of products in Qt applications on mobile platforms. Qt Virtual Keyboard A framework for implementing different input methods as well as a QML virtual keyboard. Supports localized keyboard layouts and custom visual themes. Qt Quick 2D Renderer Enables the u -------------- next part -------------- An HTML attachment was scrubbed... URL: From harri at mpaja.com Sat Apr 18 18:54:39 2015 From: harri at mpaja.com (Harri Pasanen) Date: Sat, 18 Apr 2015 18:54:39 +0200 Subject: [Development] qtplugininfo install fails Message-ID: <55328C4F.1010405@mpaja.com> Just updated my 5.5 tree, qttools/src ad31b98 Seems like qtplugininfo is ignoring the -prefix passed to configure: cd qtplugininfo/ && ( test -e Makefile || /home/harri/src/qt5/qtbase/bin/qmake /home/harri/src/qt5/qttools/src/qtplugininfo/qtplugininfo.pro -o Makefile ) && make -f Makefile install make[3]: Entering directory '/home/harri/src/qt5/qttools/src/qtplugininfo' mkdir: cannot create directory ‘/libs’: Permission denied Harri From laszlo.agocs at theqtcompany.com Sat Apr 18 20:14:25 2015 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Sat, 18 Apr 2015 18:14:25 +0000 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. In-Reply-To: References: Message-ID: The code snippet has no relation whatsoever to what setWindowOpacity is doing. If you are only after having transparent (alpha == 0) areas on the window, then there is no difference with 'minimal' compared to any other platform. In fact it's much easier since you won't need to worry about having transparency functional on the windowing system level. Just writing out pixels with an alpha of 0 is good enough, f.ex.: tlw.setAutoFillBackground(true); tlw.setBrush(QPalette::Window, Qt::transparent); See http://doc.qt.io/qt-5.4/qwidget.html#transparency-and-double-buffering Cheers, Laszlo From: Paul Knopf > Date: Friday 17 April 2015 17:45 To: Agocs Laszlo > Cc: "development at qt-project.org" > Subject: Re: [Development] Qt 'minimal' platform no rendering alpha/opacity. What do you mean when you say "compositor"? Are you referring to a window system? Is this something that is possible to implement with the minimal project? What would have to change? I have need a custom platform that encodes the ARGB (proprietary, vendor specific) to the linux framebuffer, but the alpha channel has to actually be correct. How come I can do this without a compositor? QImage bitmap(widget.size(), QImage::Format_ARGB32); bitmap.fill(Qt::transparent); QPainter painter(&bitmap); widget.render(&painter, QPoint(), QRegion(), QWidget::DrawChildren); bitmap.save("file.png"); There must be a way to achieve the same result using a platform plugin. If all else fails, I could create my own thread loop that renders the QWidget with the above code and outputs it to my driver manually, instead of going through the platform plugins, but I would like to support the platform plugin so that I can then switch it out to develop locally using standard Qt platforms (X11, etc). On Fri, Apr 17, 2015 at 10:32 AM, Agocs Laszlo > wrote: You do have alpha because the minimal's backingstore uses ARGB32_Premultiplied for the backing QImage. What you do not have is setWindowOpacity(). You would need to implement QPlatformWindow::setOpacity() for that, but that is not possible with minimal since there is no compositor that could apply the opacity to the window contents during the composition step. Best regards, Laszlo From: Paul Knopf > Date: Friday 17 April 2015 16:20 To: "development at qt-project.org" > Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. I am testing the 'minimal' platform (mine is based off of it), and it seems that is doesn't render the alpha channel (setting opacity). Here is a gist of my main function testing the opacity. The saved images seems to have a tan background and no transparency. Any ideas on how to get the alpha channel represented in the platform backing store? -- Thanks! ~Paul -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Sat Apr 18 23:02:24 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Apr 2015 14:02:24 -0700 Subject: [Development] Modules and skip In-Reply-To: References: Message-ID: <4339123.lKjFU9Flvh@tjmaciei-mobl4> On Saturday 18 April 2015 10:02:19 mark diener wrote: > The following table lists the Qt essentials. > > I am building Qt from scratch and I am having a bit of trouble finding > > where the modules that I can remove from the build are located. > > Generally in configure, there are -skip directives > > For example: > > configure -skip qtserialport > > Where can I find the comprehensive list of names and what I can skip on > configure? Run from the top dir: ls That's the list you can skip. > How can I remove qtnetwork when the NetworkAccessManager seems to be tied > to the > > gman = view()->engine()->NetworkAccessmanager() ; You cannot exclude QtNetwork and you cannot skip qtbase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Sat Apr 18 23:00:30 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 18 Apr 2015 14:00:30 -0700 Subject: [Development] Building Modules In-Reply-To: References: Message-ID: <4055514.CO8XyQPJgk@tjmaciei-mobl4> On Saturday 18 April 2015 09:47:28 mark diener wrote: > Hello: > > How does one remove a submodule from a git repository build? > > (even if I already downloaded it) > > In this case, I want qlalr submodule to be removed from the build process. > > Qlalr does not build on Windows rm -rf qlalr -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ritt.ks at gmail.com Mon Apr 20 06:37:57 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Mon, 20 Apr 2015 08:37:57 +0400 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5530FB56.4020506@theqtcompany.com> References: <5530B1F3.4080501@theqtcompany.com> <201504171419.01755.kde@carewolf.com> <5530FB56.4020506@theqtcompany.com> Message-ID: I failed to find an official announcing for the EXIF-based auto-rotation of QImage-s (correct me if I'm wrong), so it looks just like a behavioral regression to me, nothing more. IMO, we should revert the behavior to pre 5.4 and give the control over the image aspects to the user, not to an arbitrary image loader. I mean https://codereview.qt-project.org/#/c/110685/ and https://codereview.qt-project.org/#/c/101084/ could co-operate quite nicely to make the user think: "why my photo gets loaded rotated 90 degrees? ah, img.sourceOrientation() == QImage::Rotated90 --> img.transform(img.sourceOrientation())") P.S. Also not the sample image in QTBUG-37946 isn't auto-rotated in your web browser (well, at least in my web browser). Regards, Konstantin 2015-04-17 16:23 GMT+04:00 Rainer Keller : > > I would like to mention one extra relevant detail. While this was > implemented > > for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So > sofar > > only 5.4.1 has had EXIF orientation automatically applied on JPEGs. This > also > > raises the question about what to do for 5.4.2? > I actually worked, theoretically. There was a bug with the endianess > when reading the data field. It worked when data was generated on little > endian machines but all photo cameras are big endian. > This means only photos taken on x86 machines would have been rotated. > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Mon Apr 20 06:53:30 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Mon, 20 Apr 2015 08:53:30 +0400 Subject: [Development] Rotating JPEG images by default In-Reply-To: References: <5530B1F3.4080501@theqtcompany.com> <201504171419.01755.kde@carewolf.com> <5530FB56.4020506@theqtcompany.com> Message-ID: And to be honest, I don't like the QImage::orientation() API addition w/o providing setOrientation() and a respective code code in the image writer to store orientation as metadata (when possible). `QImage img(sourcePath); img = img.scaled(img.width() / 2, mg.height() / 2); img.save(destPath);` should not loose the metadata when the format has not been changed (at least). Regards, Konstantin 2015-04-20 8:37 GMT+04:00 Konstantin Ritt : > I failed to find an official announcing for the EXIF-based auto-rotation > of QImage-s (correct me if I'm wrong), so it looks just like a behavioral > regression to me, nothing more. > IMO, we should revert the behavior to pre 5.4 and give the control over > the image aspects to the user, not to an arbitrary image loader. > I mean https://codereview.qt-project.org/#/c/110685/ and > https://codereview.qt-project.org/#/c/101084/ could co-operate quite > nicely > to make the user think: "why my photo gets loaded rotated 90 degrees? ah, > img.sourceOrientation() == QImage::Rotated90 --> > img.transform(img.sourceOrientation())") > > P.S. Also not the sample image in QTBUG-37946 > isn't auto-rotated in your > web browser (well, at least in my web browser). > > > Regards, > Konstantin > > 2015-04-17 16:23 GMT+04:00 Rainer Keller : > >> > I would like to mention one extra relevant detail. While this was >> implemented >> > for 5.4, it was not working in 5.4.0, and was only fixed for 5.4.1. So >> sofar >> > only 5.4.1 has had EXIF orientation automatically applied on JPEGs. >> This also >> > raises the question about what to do for 5.4.2? >> I actually worked, theoretically. There was a bug with the endianess >> when reading the data field. It worked when data was generated on little >> endian machines but all photo cameras are big endian. >> This means only photos taken on x86 machines would have been rotated. >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From theonlylawislove at gmail.com Mon Apr 20 09:25:10 2015 From: theonlylawislove at gmail.com (Paul Knopf) Date: Mon, 20 Apr 2015 03:25:10 -0400 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. In-Reply-To: References: Message-ID: Thanks a lot! This worked. I now have a valid alpha component that I can send to my hard vendors API for FPGA video overlay. With this said, I would REALLY like to support OpenGL (for Qt Quick 2/qml). Here is an image of what I am trying to essentially do. What are your thoughts implementing this in Qt? Here is what I need my monitor output to be. The original buffer: size w / h : [R G B A][R G B A][R G B A][...] The output i want: size (w*.25) / (h*.25): [R G B][A R G][B A R][G B A][...] My thoughts are to Render OpenGL off screen (not using framebuffer), then have a thread that periodically captures the output (RGBA) and sends it my linux framebuffer. My output doesn't need high FPS. I understand that sending the extra alpha will increase the size of my resolution by 25%.. The FPGA component/board will identify itself as having a resolution of 1350 (1080 * .25) so that it can internally translate to 1080 with an alpha channel. Does the EGLFS support off-screen rendering? Maybe then, I could create 1080 opengl context off-screen, and then output it, including alpha, to the 1350 framebuffer. Or is there a better way that I could achieve this? I understand that I am asking a lot from you guys, but if someone has some concrete ideas, I am open to a consultation arrangement. Thanks, Paul On Sat, Apr 18, 2015 at 2:14 PM, Agocs Laszlo wrote: > The code snippet has no relation whatsoever to what setWindowOpacity is > doing. If you are only after having transparent (alpha == 0) areas on the > window, then there is no difference with 'minimal' compared to any other > platform. In fact it's much easier since you won't need to worry about > having transparency functional on the windowing system level. Just writing > out pixels with an alpha of 0 is good enough, f.ex.: > > tlw.setAutoFillBackground(true); > tlw.setBrush(QPalette::Window, Qt::transparent); > > See > http://doc.qt.io/qt-5.4/qwidget.html#transparency-and-double-buffering > > Cheers, > Laszlo > > From: Paul Knopf > Date: Friday 17 April 2015 17:45 > To: Agocs Laszlo > Cc: "development at qt-project.org" > Subject: Re: [Development] Qt 'minimal' platform no rendering > alpha/opacity. > > What do you mean when you say "compositor"? Are you referring to a > window system? > > Is this something that is possible to implement with the minimal > project? What would have to change? > > I have need a custom platform that encodes the ARGB (proprietary, vendor > specific) to the linux framebuffer, but the alpha channel has to actually > be correct. > > How come I can do this without a compositor? > > QImage bitmap(widget.size(), QImage::Format_ARGB32); > > bitmap.fill(Qt::transparent); > > QPainter painter(&bitmap); > > widget.render(&painter, QPoint(), QRegion(), QWidget::DrawChildren); > > bitmap.save("file.png"); > > > There must be a way to achieve the same result using a platform plugin. > > If all else fails, I could create my own thread loop that renders the > QWidget with the above code and outputs it to my driver manually, instead > of going through the platform plugins, but I would like to support the > platform plugin so that I can then switch it out to develop locally using > standard Qt platforms (X11, etc). > > On Fri, Apr 17, 2015 at 10:32 AM, Agocs Laszlo < > laszlo.agocs at theqtcompany.com> wrote: > >> You do have alpha because the minimal's backingstore uses >> ARGB32_Premultiplied for the backing QImage. >> >> What you do not have is setWindowOpacity(). You would need to implement >> QPlatformWindow::setOpacity() for that, but that is not possible with >> minimal since there is no compositor that could apply the opacity to the >> window contents during the composition step. >> >> Best regards, >> Laszlo >> >> From: Paul Knopf >> Date: Friday 17 April 2015 16:20 >> To: "development at qt-project.org" >> Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. >> >> I am testing the 'minimal' platform (mine is based off of it), and it >> seems that is doesn't render the alpha channel (setting opacity). >> >> Here is a gist of >> my main function testing the opacity. >> >> The saved images seems to have a tan background and no transparency. >> >> Any ideas on how to get the alpha channel represented in the platform >> backing store? >> >> -- >> Thanks! >> >> ~Paul >> > > > > -- > Thanks! > > ~Paul > -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From aklitzing at gmail.com Mon Apr 20 09:39:13 2015 From: aklitzing at gmail.com (A. Klitzing) Date: Mon, 20 Apr 2015 09:39:13 +0200 Subject: [Development] qtplugininfo install fails In-Reply-To: <55328C4F.1010405@mpaja.com> References: <55328C4F.1010405@mpaja.com> Message-ID: Hi there! corresponding bug report: https://bugreports.qt.io/browse/QTBUG-45095 Best regards André Klitzing 2015-04-18 18:54 GMT+02:00 Harri Pasanen : > Just updated my 5.5 tree, qttools/src ad31b98 > > Seems like qtplugininfo is ignoring the -prefix passed to configure: > > cd qtplugininfo/ && ( test -e Makefile || > /home/harri/src/qt5/qtbase/bin/qmake > /home/harri/src/qt5/qttools/src/qtplugininfo/qtplugininfo.pro -o > Makefile ) && make -f Makefile install > make[3]: Entering directory '/home/harri/src/qt5/qttools/src/qtplugininfo' > mkdir: cannot create directory ‘/libs’: Permission denied > > > Harri > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qt at csipa.in.rs Mon Apr 20 09:44:11 2015 From: qt at csipa.in.rs (Attila Csipa) Date: Mon, 20 Apr 2015 10:44:11 +0300 Subject: [Development] Playground request: QML for Android In-Reply-To: <20F19BD7-4CA5-4AC7-B061-E6D06A399CD1@theqtcompany.com> References: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> <20F19BD7-4CA5-4AC7-B061-E6D06A399CD1@theqtcompany.com> Message-ID: <5534AE4B.5080908@csipa.in.rs> Without actually looking at the sources... How hard (or, rather, what) is the 5.6 dependency? It would help a great deal if it was available for at least for 5.5. Best regards, Attila Csipa On 4/17/2015 6:13 PM, Nurmi J-P wrote: >> On 16 Apr 2015, at 23:01, Nurmi J-P wrote: >> >> Hi, >> >> I'd like to request a new playground repository for "QML for Android" - http://lists.qt-project.org/pipermail/development/2015-April/021035.html >> >> Description: QML wrappers for native Android controls. >> Playground project name: qtqmlandroid >> >> QtQmlAndroid is what I've used as the working title. The playground guidelines say not to include a Qt-prefix, but a majority of the playground projects do... >> >> -- >> J-P Nurmi > A big thanks to everyone who participated in brainstorming the name. The source code is now available at http://code.qt.io/cgit/playground/qtqmlandroid.git/. Contributions welcome! ;) > > Quoting the README file: > > ## Requirements > > - Qt 5 dev (5.6.0) > - Android 5.x > - Gradle > > ## Installation > > Build like any Qt module. It might be necessary to run 'make > install' in 'src/java' until the build system is finalized. > > ## Qt Creator > > When building the example in Qt Creator, tick "Use Gradle" in > > Projects -> Build & Run -> Build Steps -> Build Android APK > > ## Notes > > The Android 5.x dependency is not going to stay. Proper Android > version handling is just missing for the time being. The goal of > the hackathon project was to create a visually stunning demo. > > -- > J-P Nurmi > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From harri at mpaja.com Mon Apr 20 10:29:30 2015 From: harri at mpaja.com (Harri Pasanen) Date: Mon, 20 Apr 2015 10:29:30 +0200 Subject: [Development] 5.5 beta builds for iOS? Message-ID: <5534B8EA.4010402@mpaja.com> There don't seem to be any? Thanks, Harri From sean.harmer at kdab.com Mon Apr 20 11:03:37 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 20 Apr 2015 10:03:37 +0100 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. In-Reply-To: References: Message-ID: <5534C0E9.20201@kdab.com> On 20/04/2015 08:25, Paul Knopf wrote: > Thanks a lot! This worked. I now have a valid alpha component that I > can send to my hard vendors API for FPGA video overlay. > > With this said, I would REALLY like to support OpenGL (for Qt Quick > 2/qml). Here is an image of what I am > trying to essentially do. What are your thoughts implementing this in Qt? > > Here is what I need my monitor output to be. > > The original buffer: size w / h : [R G B A][R G > B A][R G B A][...] > The output i want: size (w*.25) / (h*.25): [R G B][A R G][B A > R][G B A][...] > > My thoughts are to Render OpenGL off screen (not using framebuffer), > then have a thread that periodically captures the output (RGBA) and > sends it my linux framebuffer. My output doesn't need high FPS. I > understand that sending the extra alpha will increase the size of my > resolution by 25%.. The FPGA component/board will identify itself as > having a resolution of 1350 (1080 * .25) so that it can internally > translate to 1080 with an alpha channel. Does the EGLFS support > off-screen rendering? Maybe then, I could create 1080 opengl context > off-screen, and then output it, including alpha, to the 1350 framebuffer. OpenGL supports offscreen rendering as long as the QPA supports OpenGL. * Create a QOffscreenSurface * Create a QOpenGLContext * Create a suitable Framebuffer Object with a colour texture attachment and most likely a depth and stencil attachment. * Bind the FBO as the GL_BUFFER (both read and write binding points) * Draw stuff * Read back the texture attached to the FBO as needed If you are wanting to use this approach to render Qt Quick 2 content, then take a look at the QQuickRenderControl class and accompanying example that ships with Qt. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Mon Apr 20 12:54:36 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 20 Apr 2015 10:54:36 +0000 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <1428661428222.50531@theqtcompany.com> References: <1428661428222.50531@theqtcompany.com> Message-ID: <1429527275871.71506@theqtcompany.com> Hi all! Downmerge from '5.4' to '5.4.2' is now done & all changes targeted to Qt5.4.2 release must be done in '5.4.2' branch. From now on '5.4' is for possible Qt5.4.3 release. If there is some open changes in '5.4' which should be in Qt5.4.2 please sent re-targeting request to Ossi. Once again: Please remember that '5.4.2' is release branch and so on no any nice-to-have fixes in anymore! Maintainers: Please create change files for Qt5.4.2 immediately, we are planning to put Qt5.4.2 out soon! br, Jani ________________________________ Lähettäjä: Heikkinen Jani Lähetetty: 10. huhtikuuta 2015 13:23 Vastaanottaja: development at qt-project.org Kopio: releasing at qt-project.org Aihe: HEADS-UP: Qt 5.4.2 release coming Hi all, Qt5.git integration succeed finally in '5.4' and so on we can start soft branching from '5.4' to '5.4.2' today. '5.4.2' branch is already created and downmerge from '5.4' to '5.4.2' will be done Friday 17th April 2015. That way everyone should have enough time to finalize ongoing changes in '5.4' branch & start using '5.4.2' branch for the changes targeted to Qt 5.4.2 release. Target is to release Qt 5.4.2 at the end of April. Please remember: we are doing patch level release now meaning do not put any new features / nice to have fix in it! Please make sure all issues blocking the Qt 5.4.2 release are linked to blocker meta bug: https://bugreports.qt.io/browse/QTBUG-44881 Snapshot creation is ongoing & first Qt5.4.2 snapshot should be available here later today: http://download.qt.io/snapshots/qt/5.4/ br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Mon Apr 20 13:05:52 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Mon, 20 Apr 2015 13:05:52 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <1429527275871.71506@theqtcompany.com> References: <1428661428222.50531@theqtcompany.com> <1429527275871.71506@theqtcompany.com> Message-ID: <54986696.emDUGsnFxN@patux> On Monday April 20 2015 10:54:36 Heikkinen Jani wrote: Hi, >Once again: Please remember that '5.4.2' is release branch and so on no any nice-to-have fixes in anymore! I'm trying to finish up a patch to the logic behind the support for font weights and styles testing against 5.4.1 currently (and 5.4.2 once it's out). Can I at least launch a code review request against the 5.4 branch when I'm done? R From mardy at users.sourceforge.net Mon Apr 20 15:43:35 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Mon, 20 Apr 2015 16:43:35 +0300 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: <1534001.C0Zgerm6cZ@frederik-thinkcentre-m93p> References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> <1534001.C0Zgerm6cZ@frederik-thinkcentre-m93p> Message-ID: <55350287.1040408@users.sourceforge.net> Hi Frederik, On 04/09/2015 04:04 PM, Frederik Gladhorn wrote: > We want to give you the code, here it is :) > https://codereview.qt-project.org/#/admin/projects/qt-labs/qtquickcontrols2 [...] > Feedback welcome! If I understand correctly, these controls are intended to be a cross-platform set of controls with their own style, with the goal of being good looking and still have a good performance; the goal is not to wrap (or make them look alike) any of the platform native controls, unlike for example qtqmlandroid. Is my understanding correct? If so, it seems to me that the naming is somehow confusing: on one hand we have qtquickcontrols1, which provides a uniform API to render native-looking controls; on the other hand, the qtquickcontrols2 module seems to have a very different goal. Maybe this qtquickcontrols2 module should be renamed to something like qtquickembedded, to avoid giving the false impression that is meant to supersede the existing module? And will qtqmlandroid eventually be merged into qtquickcontrols1, once it's ready? Ciao, Alberto -- http://blog.mardy.it <- geek in un lingua international! From jpnurmi at theqtcompany.com Mon Apr 20 17:28:00 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 20 Apr 2015 15:28:00 +0000 Subject: [Development] Playground request: QML for Android In-Reply-To: <5534AE4B.5080908@csipa.in.rs> References: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> <20F19BD7-4CA5-4AC7-B061-E6D06A399CD1@theqtcompany.com> <5534AE4B.5080908@csipa.in.rs> Message-ID: Things were running fine with Qt 5.5 back in December, so there shouldn’t be any hard dependencies to Qt 5.6. It’s just that now that I tested things before publishing the source code, I had to sync some gradle build scripts from the latest qtbase/dev to get the example up and running. I’ll test with older Qt builds and update the README accordingly. As you know, some of the cool stuff comes from the Android support libraries. I really wanted to have a navigation drawer & the animating hamburger icon in the hackathon demo, and the only way I was able to get it working was with those custom gradle scripts. This is not a polished product, and there are plenty of silly shortcuts like this. :) -- J-P Nurmi On 20 Apr 2015, at 09:44, Attila Csipa wrote: > Without actually looking at the sources... How hard (or, rather, what) > is the 5.6 dependency? It would help a great deal if it was available > for at least for 5.5. > > Best regards, > Attila Csipa > > On 4/17/2015 6:13 PM, Nurmi J-P wrote: >>> On 16 Apr 2015, at 23:01, Nurmi J-P wrote: >>> >>> Hi, >>> >>> I'd like to request a new playground repository for "QML for Android" - http://lists.qt-project.org/pipermail/development/2015-April/021035.html >>> >>> Description: QML wrappers for native Android controls. >>> Playground project name: qtqmlandroid >>> >>> QtQmlAndroid is what I've used as the working title. The playground guidelines say not to include a Qt-prefix, but a majority of the playground projects do... >>> >>> -- >>> J-P Nurmi >> A big thanks to everyone who participated in brainstorming the name. The source code is now available at http://code.qt.io/cgit/playground/qtqmlandroid.git/. Contributions welcome! ;) >> >> Quoting the README file: >> >> ## Requirements >> >> - Qt 5 dev (5.6.0) >> - Android 5.x >> - Gradle >> >> ## Installation >> >> Build like any Qt module. It might be necessary to run 'make >> install' in 'src/java' until the build system is finalized. >> >> ## Qt Creator >> >> When building the example in Qt Creator, tick "Use Gradle" in >> >> Projects -> Build & Run -> Build Steps -> Build Android APK >> >> ## Notes >> >> The Android 5.x dependency is not going to stay. Proper Android >> version handling is just missing for the time being. The goal of >> the hackathon project was to create a visually stunning demo. >> >> -- >> J-P Nurmi >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jpnurmi at theqtcompany.com Mon Apr 20 18:26:41 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 20 Apr 2015 16:26:41 +0000 Subject: [Development] Qt Quick Controls for Embedded In-Reply-To: <55350287.1040408@users.sourceforge.net> References: <12993974.i5qxbXUYEm@frederik-thinkcentre-m93p> <1534001.C0Zgerm6cZ@frederik-thinkcentre-m93p> <55350287.1040408@users.sourceforge.net> Message-ID: <15F2624A-8F5B-4643-B6E4-18B7FD68D0FE@theqtcompany.com> Hi Alberto, > On 20 Apr 2015, at 15:43, Alberto Mardegan wrote: > > Hi Frederik, > > On 04/09/2015 04:04 PM, Frederik Gladhorn wrote: >> We want to give you the code, here it is :) >> https://codereview.qt-project.org/#/admin/projects/qt-labs/qtquickcontrols2 > [...] >> Feedback welcome! > > If I understand correctly, these controls are intended to be a > cross-platform set of controls with their own style, with the goal of > being good looking and still have a good performance; the goal is not to > wrap (or make them look alike) any of the platform native controls, > unlike for example qtqmlandroid. > Is my understanding correct? Consider the “native” styling an open question. It has major implications on the architecture and performance. > If so, it seems to me that the naming is somehow confusing: on one hand > we have qtquickcontrols1, which provides a uniform API to render > native-looking controls; on the other hand, the qtquickcontrols2 module > seems to have a very different goal. It’s just that the good old recipe does no longer give that shiny results. No matter how fancy ways we invent to extract native assets, the native feel is always off. Attila had very good insights on this subject in the "QML bindings for native Android controls” thread. > Maybe this qtquickcontrols2 module should be renamed to something like > qtquickembedded, to avoid giving the false impression that is meant to > supersede the existing module? Nothing is set in stone at this point. Trust me, we have spent an enormous amount of time discussing the name and going back and forth… :) > And will qtqmlandroid eventually be merged into qtquickcontrols1, once > it's ready? The QML for Android playground project is unlikely to be merged with Qt Quick Controls. It’s not using or even compatible with Qt Quick. -- J-P Nurmi From harri at mpaja.com Mon Apr 20 20:09:49 2015 From: harri at mpaja.com (Harri Pasanen) Date: Mon, 20 Apr 2015 20:09:49 +0200 Subject: [Development] Branches 5.4 and 5.4.2 Message-ID: <553540ED.5000100@mpaja.com> Does 5.4 have everything 5.4.2 has? Is there on-line some graphical view of the branches? Thanks, Harri From thiago.macieira at intel.com Mon Apr 20 20:17:54 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 20 Apr 2015 11:17:54 -0700 Subject: [Development] Branches 5.4 and 5.4.2 In-Reply-To: <553540ED.5000100@mpaja.com> References: <553540ED.5000100@mpaja.com> Message-ID: <1758934.Dpc9Mfi1Dd@tjmaciei-mobl4> On Monday 20 April 2015 20:09:49 Harri Pasanen wrote: > Does 5.4 have everything 5.4.2 has? > > Is there on-line some graphical view of the branches? Yes but not always. The 5.4 branch will eventually have the full 5.4.2 release, but until it closes (when the release it happens), it may have a handful of commits not yet merged into 5.4. For example, right now, it has this commit: QNAM: Fix upload corruptions when server closes connection That isn't in 5.4. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jpnurmi at theqtcompany.com Mon Apr 20 21:20:01 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 20 Apr 2015 19:20:01 +0000 Subject: [Development] Playground request: QML for Android In-Reply-To: References: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> <20F19BD7-4CA5-4AC7-B061-E6D06A399CD1@theqtcompany.com> <5534AE4B.5080908@csipa.in.rs> Message-ID: <6770A6ED-0CF4-45B8-A9AA-0C394D1C1D30@theqtcompany.com> Sorry, it’s been 4 months since I was last time playing with this. It looks like the Qt version is not the issue at all. I’m able to run the example fine with self-built Qt 5.5 and 5.4. The problem seems to be that the project doesn’t build with GCC 4.8 used by the prebuilt Qt 5.4 for Android packages. My self-built Qt were using GCC 4.9. The build problem is in the QOptional class borrowed from https://codereview.qt-project.org/#/c/92006/. It’s handy and less error-prone than maintaining separate booleans whether properties have been explicitly set. :) Maybe I should try with the one from https://codereview.qt-project.org/#/c/105743/ instead. -- J-P Nurmi > On 20 Apr 2015, at 17:28, Nurmi J-P wrote: > > Things were running fine with Qt 5.5 back in December, so there shouldn’t be any hard dependencies to Qt 5.6. It’s just that now that I tested things before publishing the source code, I had to sync some gradle build scripts from the latest qtbase/dev to get the example up and running. I’ll test with older Qt builds and update the README accordingly. > > As you know, some of the cool stuff comes from the Android support libraries. I really wanted to have a navigation drawer & the animating hamburger icon in the hackathon demo, and the only way I was able to get it working was with those custom gradle scripts. This is not a polished product, and there are plenty of silly shortcuts like this. :) > > -- > J-P Nurmi > > On 20 Apr 2015, at 09:44, Attila Csipa wrote: > >> Without actually looking at the sources... How hard (or, rather, what) >> is the 5.6 dependency? It would help a great deal if it was available >> for at least for 5.5. >> >> Best regards, >> Attila Csipa >> >> On 4/17/2015 6:13 PM, Nurmi J-P wrote: >>>> On 16 Apr 2015, at 23:01, Nurmi J-P wrote: >>>> >>>> Hi, >>>> >>>> I'd like to request a new playground repository for "QML for Android" - http://lists.qt-project.org/pipermail/development/2015-April/021035.html >>>> >>>> Description: QML wrappers for native Android controls. >>>> Playground project name: qtqmlandroid >>>> >>>> QtQmlAndroid is what I've used as the working title. The playground guidelines say not to include a Qt-prefix, but a majority of the playground projects do... >>>> >>>> -- >>>> J-P Nurmi >>> A big thanks to everyone who participated in brainstorming the name. The source code is now available at http://code.qt.io/cgit/playground/qtqmlandroid.git/. Contributions welcome! ;) >>> >>> Quoting the README file: >>> >>> ## Requirements >>> >>> - Qt 5 dev (5.6.0) >>> - Android 5.x >>> - Gradle >>> >>> ## Installation >>> >>> Build like any Qt module. It might be necessary to run 'make >>> install' in 'src/java' until the build system is finalized. >>> >>> ## Qt Creator >>> >>> When building the example in Qt Creator, tick "Use Gradle" in >>> >>> Projects -> Build & Run -> Build Steps -> Build Android APK >>> >>> ## Notes >>> >>> The Android 5.x dependency is not going to stay. Proper Android >>> version handling is just missing for the time being. The goal of >>> the hackathon project was to create a visually stunning demo. >>> >>> -- >>> J-P Nurmi >>> >>> _______________________________________________ >>> Development mailing list >>> Development at qt-project.org >>> http://lists.qt-project.org/mailman/listinfo/development >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jpnurmi at theqtcompany.com Mon Apr 20 22:04:39 2015 From: jpnurmi at theqtcompany.com (Nurmi J-P) Date: Mon, 20 Apr 2015 20:04:39 +0000 Subject: [Development] Playground request: QML for Android In-Reply-To: <6770A6ED-0CF4-45B8-A9AA-0C394D1C1D30@theqtcompany.com> References: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> <20F19BD7-4CA5-4AC7-B061-E6D06A399CD1@theqtcompany.com> <5534AE4B.5080908@csipa.in.rs> <6770A6ED-0CF4-45B8-A9AA-0C394D1C1D30@theqtcompany.com> Message-ID: > On 20 Apr 2015, at 21:20, Nurmi J-P wrote: > > Maybe I should try with the one from https://codereview.qt-project.org/#/c/105743/ instead. That did the trick. Builds and runs with the prebuilt Qt 5.4 for Android packages now. -- J-P Nurmi From missdeer at gmail.com Tue Apr 21 03:03:29 2015 From: missdeer at gmail.com (Yang Fan) Date: Tue, 21 Apr 2015 09:03:29 +0800 Subject: [Development] 5.5 beta builds for iOS? In-Reply-To: <5534B8EA.4010402@mpaja.com> References: <5534B8EA.4010402@mpaja.com> Message-ID: Some installers are still missing but there is at least something to be able to start testing. On Mon, Apr 20, 2015 at 4:29 PM, Harri Pasanen wrote: > There don't seem to be any? > > Thanks, > > Harri > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Regards, Fan Yang -------------- next part -------------- An HTML attachment was scrubbed... URL: From qt at csipa.in.rs Tue Apr 21 08:07:40 2015 From: qt at csipa.in.rs (Attila Csipa) Date: Tue, 21 Apr 2015 09:07:40 +0300 Subject: [Development] Playground request: QML for Android In-Reply-To: References: <11FD0525-C6AB-428E-A68A-A2BD7B1CD62A@theqtcompany.com> <20F19BD7-4CA5-4AC7-B061-E6D06A399CD1@theqtcompany.com> <5534AE4B.5080908@csipa.in.rs> <6770A6ED-0CF4-45B8-A9AA-0C394D1C1D30@theqtcompany.com> Message-ID: <5535E92C.8060006@csipa.in.rs> That's great news! I'm sure that it'll go a long way helping those who want to evaluate it, but don't compile Qt on a daily basis. Now off to play with it a bit myself :) Best regards, Attila On 4/20/2015 11:04 PM, Nurmi J-P wrote: >> On 20 Apr 2015, at 21:20, Nurmi J-P wrote: >> >> Maybe I should try with the one from https://codereview.qt-project.org/#/c/105743/ instead. > That did the trick. Builds and runs with the prebuilt Qt 5.4 for Android packages now. > > -- > J-P Nurmi > > From jani.heikkinen at theqtcompany.com Tue Apr 21 08:32:47 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 21 Apr 2015 06:32:47 +0000 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <54986696.emDUGsnFxN@patux> References: <1428661428222.50531@theqtcompany.com> <1429527275871.71506@theqtcompany.com> <54986696.emDUGsnFxN@patux> Message-ID: If you aren't fixing critical bug you should use '5.5' branch for that. '5.4' is for possible 5.4.3 and not for any nice-to-have fixes, sorry. Br, jani >>-----Original Message----- >>From: René J.V. Bertin [mailto:rjvbertin at gmail.com] >>Sent: 20. huhtikuuta 2015 14:06 >>To: development at qt-project.org >>Cc: Heikkinen Jani >>Subject: Re: [Development] HEADS-UP: Qt 5.4.2 release coming >> >>On Monday April 20 2015 10:54:36 Heikkinen Jani wrote: >> >>Hi, >> >>>Once again: Please remember that '5.4.2' is release branch and so on no >>any nice-to-have fixes in anymore! >> >>I'm trying to finish up a patch to the logic behind the support for font >>weights and styles testing against 5.4.1 currently (and 5.4.2 once it's out). >>Can I at least launch a code review request against the 5.4 branch when I'm >>done? >> >>R From harri at mpaja.com Tue Apr 21 10:13:59 2015 From: harri at mpaja.com (Harri Pasanen) Date: Tue, 21 Apr 2015 10:13:59 +0200 Subject: [Development] Branches 5.4 and 5.4.2 In-Reply-To: <1758934.Dpc9Mfi1Dd@tjmaciei-mobl4> References: <553540ED.5000100@mpaja.com> <1758934.Dpc9Mfi1Dd@tjmaciei-mobl4> Message-ID: <553606C7.6060100@mpaja.com> On 20/04/2015 20:17, Thiago Macieira wrote: > On Monday 20 April 2015 20:09:49 Harri Pasanen wrote: >> Does 5.4 have everything 5.4.2 has? >> >> Is there on-line some graphical view of the branches? > Yes but not always. The 5.4 branch will eventually have the full 5.4.2 > release, but until it closes (when the release it happens), it may have a > handful of commits not yet merged into 5.4. > Thanks, I was unsure which one is the merge target. Harri From rjvbertin at gmail.com Tue Apr 21 10:33:50 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Apr 2015 10:33:50 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: References: <1428661428222.50531@theqtcompany.com> <54986696.emDUGsnFxN@patux> Message-ID: <3400588.IQeJPI36dd@patux> On Tuesday April 21 2015 06:32:47 Heikkinen Jani wrote: >If you aren't fixing critical bug you should use '5.5' branch for that. '5.4' is for possible 5.4.3 and not for any nice-to-have fixes, sorry. This is actually more than just a nice-to-have fix. It affects anyone doing any kind of serious work with fonts, and not just on OS X. So this is more than just a nice-to-have fix, unless of course you think it's fine for Qt to remain stuck in the 80s or so as far as font handling is concerned. There are lots of typefaces (combinations of font family, weight, style) that cannot be reloaded for the standard ways to represent them in settings files, and I'm not even sure that the approach Qt follows allows for 100% reliable function. I'll see how my patch set applies to 5.5 if I get it to a point where I'm satisfied. If it doesn't, and you really want it for 5.5 or later ... I'll be available for hire (for that crucial incentive to meddle with an unreleased major software version). R. From harri at mpaja.com Tue Apr 21 10:36:38 2015 From: harri at mpaja.com (Harri Pasanen) Date: Tue, 21 Apr 2015 10:36:38 +0200 Subject: [Development] qtplugininfo install fails In-Reply-To: References: <55328C4F.1010405@mpaja.com> Message-ID: <55360C16.7050906@mpaja.com> Thanks! FYI, 5.4.2 branch also seems to suffer from the same for qdbus when compiling for Android, in addition to 5.4 already mentioned in comments. Added a comment to that effect. Harri On 20/04/2015 09:39, A. Klitzing wrote: > Hi there! > > corresponding bug report: https://bugreports.qt.io/browse/QTBUG-45095 > > Best regards > André Klitzing > > > 2015-04-18 18:54 GMT+02:00 Harri Pasanen >: > > Just updated my 5.5 tree, qttools/src ad31b98 > > Seems like qtplugininfo is ignoring the -prefix passed to configure: > > cd qtplugininfo/ && ( test -e Makefile || > /home/harri/src/qt5/qtbase/bin/qmake > /home/harri/src/qt5/qttools/src/qtplugininfo/qtplugininfo.pro > -o > Makefile ) && make -f Makefile install > make[3]: Entering directory > '/home/harri/src/qt5/qttools/src/qtplugininfo' > mkdir: cannot create directory ‘/libs’: Permission denied > > > Harri > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Tue Apr 21 11:46:28 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Apr 2015 11:46:28 +0200 Subject: [Development] Qt Creator uses "_qt_autotest_force_engine_poller"? Message-ID: <10761057.eS8fFCKAyj@portia.local> Hi, I know I should ask this on the QC ML (but I'd prefer not to sign up for just an occasional question like this): Is there a (good) reason why DocumentManagerPrivate::linkWatcher() forces the use of a polling watcher? Mainly asking because I just noticed that this approach can lead to significant CPU use when the IDE is otherwise idle, which is ... unfortunate. R. From olivier at woboq.com Tue Apr 21 14:37:49 2015 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 21 Apr 2015 14:37:49 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <3400588.IQeJPI36dd@patux> References: <1428661428222.50531@theqtcompany.com> <3400588.IQeJPI36dd@patux> Message-ID: <1737541.Vmf48kj2Uv@finn> On Tuesday 21. April 2015 10:33:50 René J.V. Bertin wrote: > On Tuesday April 21 2015 06:32:47 Heikkinen Jani wrote: > >If you aren't fixing critical bug you should use '5.5' branch for that. > >'5.4' is for possible 5.4.3 and not for any nice-to-have fixes, sorry. > This is actually more than just a nice-to-have fix. It affects anyone doing > any kind of serious work with fonts, and not just on OS X. So this is more > than just a nice-to-have fix, unless of course you think it's fine for Qt > to remain stuck in the 80s or so as far as font handling is concerned. > There are lots of typefaces (combinations of font family, weight, style) > that cannot be reloaded for the standard ways to represent them in settings > files, and I'm not even sure that the approach Qt follows allows for 100% > reliable function. I don't know anything about that particular patch, but this does not look like a candidate for a stable branch. If people have been living in the 80s for that long, they can wait until the next minor release. If this is not a regression against Qt4, then it is a new feature, and 5.5 or even dev should be a better candidate. Especially because font rendering is so delicate, and fixes somewhere in this area tends to break applications that relied on the previous behaviour. (When suddenly a line is a pixel larger, the rendering of a whole screen can be disastrous.) But this does sound like a nice change you are doing. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From alessio211734 at yahoo.it Tue Apr 21 14:57:07 2015 From: alessio211734 at yahoo.it (Alessio Mochi) Date: Tue, 21 Apr 2015 12:57:07 +0000 (UTC) Subject: [Development] strange behavior with plugin Message-ID: <117909846.1766101.1429621027029.JavaMail.yahoo@mail.yahoo.com> Hello, I tried to add some code for opengl vbo creation inside my qt plugin. I initialize vbo buffer inside the plugin and after it my program crash in rendering vbo method on one glBindBuffer call. this function is called when plugin start and after it my application crash on a rendering method while render the tooth node just created. bool testPlugin::StartEdit(RenderNode & r, GLArea *gla ) { connect(this,SIGNAL(createVbo()),gla,SLOT(updateVbo())); RenderNode * meshNode=new Tooth("test",&r); MeshModel * model=new MeshModel("test.ply"); int result=vcg::tri::io::ImporterPLY::Open(model->cm, "d:/debugMesh/save.ply", NULL); vcg::tri::UpdateNormal::PerVertexPerFace(model->cm); meshNode->toMeshNode()->setMeshModel(model); r.appendChild(meshNode); emit createVbo(); } createVbo is a signal connected to updateVbo() GLArea slot. GLArea is a derivate of GLWidget class. I don't know why but if I create an external slot inside GLArea with the code contains in testPlugin::StartEdit function my program run correctly while if I let all the code inside the testPlugin::StartEdit the rendering function called in GLArea crash. My render code is in my application (.exe) and is in a method of GLArea. I noticed a strange behavior with debugger looking the stack call function. When the Tooth and MeshModel object is instanced inside my plugin class the method draw in GLArea call the draw method relative to Tooth object and referring to plugin code. while when Tooth and MeshModel object is instanced outside my plugin class the draw method for the Tooth object is relative to application code (.exe). When the tooth draw code is referred to plugin my application crash. Tooth is subclass of MeshNode. This is the stack call of render function when plugin code is outside from it and it's connected to plugin signal. Inside the plugin there is only a emit that call external vbo initialization code. DentalCad.exe!MeshModel::Render(vcg::GLW::DrawMode _dm=DMSmooth, vcg::GLW::ColorMode _cm=CMPerMesh, vcg::GLW::TextureMode _tm=TMNone) Line 111 C++ DentalCad.exe!MeshNode::draw(const RenderMode & rmode={...}) Line 125 + 0x39 bytes C++ DentalCad.exe!GLArea::renderSceneGraph(RenderNode * root=0x0519b330, bool filterTooths=false, const vcg::Color4 & colorPerMesh={...}) Line 591 C++ DentalCad.exe!GLArea::paintEvent(QPaintEvent * event=0x0035cb4c) Line 400 C++ and this is the stack call when all the code is inside the plugin (in this case application crash!) testPlugin.dll!vcg::GlTrimesh > >::DrawFill<1,1,0>() Line 477 C++ testPlugin.dll!vcg::GlTrimesh > >::Draw<6,1,0>() Line 433 C++ testPlugin.dll!vcg::GlTrimesh > >::Draw<6,1>(vcg::GLW::TextureMode tm=TMNone) Line 394 + 0x8 bytes C++ testPlugin.dll!vcg::GlTrimesh > >::Draw<6>(vcg::GLW::ColorMode cm=CMPerMesh, vcg::GLW::TextureMode tm=TMNone) Line 382 + 0xc bytes C++ testPlugin.dll!vcg::GlTrimesh > >::Draw(vcg::GLW::DrawMode dm=DMSmooth, vcg::GLW::ColorMode cm=CMPerMesh, vcg::GLW::TextureMode tm=TMNone) Line 370 + 0x10 bytes C++ testPlugin.dll!MeshModel::Render(vcg::GLW::DrawMode _dm=DMSmooth, vcg::GLW::ColorMode _cm=CMPerMesh, vcg::GLW::TextureMode _tm=TMNone) Line 115 C++ testPlugin.dll!MeshNode::draw(const RenderMode & rmode={...}) Line 125 + 0x39 bytes C++ DentalCad.exe!GLArea::renderSceneGraph(RenderNode * root=0x05019768, bool filterTooths=false, const vcg::Color4 & colorPerMesh={...}) Line 591 C++ DentalCad.exe!GLArea::paintEvent(QPaintEvent * event=0x0041ca14) Line 400 C++ Thanks in advance. Ale. From rjvbertin at gmail.com Tue Apr 21 15:26:36 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Apr 2015 15:26:36 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <1737541.Vmf48kj2Uv@finn> References: <1428661428222.50531@theqtcompany.com> <3400588.IQeJPI36dd@patux> <1737541.Vmf48kj2Uv@finn> Message-ID: <1689672.V2B1A6Ptre@portia.local> On Tuesday April 21 2015 14:37:49 Olivier Goffart wrote: > If people have been living in the 80s for that long, they can wait until the > next minor release. If I decided to pick up on this it's because I had had enough of it that about none of the Medium/Semibold fonts I use in my GUIs were stable (i.e. always "evolved" into either Bold or Normal). > If this is not a regression against Qt4, then it is a new Hmmm, yes and no. Qt4 is affected too, but in a different way. > Especially because font rendering is so delicate, and fixes somewhere in this > area tends to break applications that relied on the previous behaviour. > (When suddenly a line is a pixel larger, the rendering of a whole screen can > be disastrous.) This doesn't have anything to do with rendering. I'm not touching that. It's got to do with getting the proper QFont : QFont font = QFontDialog::getFont(&ok, QFont(), this, "Select Font", options); QFont font2 = QFont(font.family(), font.pointSize(), font.weight(), font.italic()); QFont font3 = QFontDialog::getFont(&ok, font2, this, "Select Font", options); the second dialog can give a different font than the one selected in the 1st and indeed font3==font2!=font . Good test fonts are the Avenir Next and Helvetica Neue families (system fonts on OS X, the latter then new UI default), or even the Segoe UI family that comes with all MS Windows machines. Anyway, I'm not going to insist it has to go into 5.4, but I'm not going to go out of my way to prepare and test the patches against software I'm not even planning to build without proper incentive. Someone may (will) have to pick up on what I come up with. R. From massimocallegari at yahoo.it Tue Apr 21 15:20:07 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Tue, 21 Apr 2015 13:20:07 +0000 (UTC) Subject: [Development] HEADS-UP: Qt 5.4.2 release coming Message-ID: <328340222.1793635.1429622407171.JavaMail.yahoo@mail.yahoo.com> >> Hi all! >> Downmerge from '5.4' to '5.4.2' is now done & all changes targeted to Qt5.4.2 release must be done >> in '5.4.2' branch. From now on '5.4' is for possible Qt5.4.3 release.>> If there is some open changes in '5.4' which should be in Qt5.4.2 please sent re-targeting request to Ossi. >> Once again: Please remember that '5.4.2' is release branch and so on no any nice-to-have fixes in >> anymore! >> Maintainers: Please create change files for Qt5.4.2 immediately, we are planning to put Qt5.4.2 out >> soon! >> br, >> Jani Hi, if possible please include this: https://bugreports.qt.io/browse/QTBUG-45037 Pending on Gerrit here: https://codereview.qt-project.org/#/c/110724/ It's a regression from 5.4.0. Thanks Massimo From harri at mpaja.com Tue Apr 21 15:31:11 2015 From: harri at mpaja.com (Harri Pasanen) Date: Tue, 21 Apr 2015 15:31:11 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <328340222.1793635.1429622407171.JavaMail.yahoo@mail.yahoo.com> References: <328340222.1793635.1429622407171.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5536511F.4020304@mpaja.com> Perhaps worth mentioning that QPushButtons don't render on Android: https://bugreports.qt.io/browse/QTBUG-45714 On 21/04/2015 15:20, Massimo Callegari wrote: >>> Hi all! >>> Downmerge from '5.4' to '5.4.2' is now done & all changes targeted to Qt5.4.2 release must be done >>> in '5.4.2' branch. From now on '5.4' is for possible Qt5.4.3 release.>> If there is some open changes in '5.4' which should be in Qt5.4.2 please sent re-targeting request to Ossi. >>> Once again: Please remember that '5.4.2' is release branch and so on no any nice-to-have fixes in >>> anymore! >>> Maintainers: Please create change files for Qt5.4.2 immediately, we are planning to put Qt5.4.2 out >>> soon! >>> br, >>> Jani > > Hi, if possible please include this: https://bugreports.qt.io/browse/QTBUG-45037 > > Pending on Gerrit here: https://codereview.qt-project.org/#/c/110724/ > It's a regression from 5.4.0. > > > Thanks > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From olivier at woboq.com Tue Apr 21 16:38:57 2015 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 21 Apr 2015 16:38:57 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <1689672.V2B1A6Ptre@portia.local> References: <1428661428222.50531@theqtcompany.com> <1737541.Vmf48kj2Uv@finn> <1689672.V2B1A6Ptre@portia.local> Message-ID: <8285051.Kpv32sV6lG@finn> On Tuesday 21. April 2015 15:26:36 René J.V. Bertin wrote: > On Tuesday April 21 2015 14:37:49 Olivier Goffart wrote: > > If people have been living in the 80s for that long, they can wait until > > the next minor release. > > If I decided to pick up on this it's because I had had enough of it that > about none of the Medium/Semibold fonts I use in my GUIs were stable (i.e. > always "evolved" into either Bold or Normal). That's not the point. One can say that for everything: "If I decided to work on $FEATURE it is because I really need it. Therefore it should go in the next patch release" That's not an argument. > > Especially because font rendering is so delicate, and fixes somewhere in > > this area tends to break applications that relied on the previous > > behaviour. (When suddenly a line is a pixel larger, the rendering of a > > whole screen can be disastrous.) > > This doesn't have anything to do with rendering. I'm not touching that. It's > got to do with getting the proper QFont : [...] As I said, i don't know the specific details of this patch, but the problem is the same. If you get a different font (because you get the more 'proper' font now), then this can break applications layout. It is a behaviour change that should not be part of a patch release. > Anyway, I'm not going to insist it has to go into 5.4, but I'm not going to > go out of my way to prepare and test the patches against software I'm not > even planning to build without proper incentive. Someone may (will) have to > pick up on what I come up with. I understand your point of view. But if you want to maximize your chances that your patch get included in Qt, you have to target the right branch. (And honestly, it is not too hard to switch branches. If you can build 5.4 it is no more work to build 5.5 or dev) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From mardy at users.sourceforge.net Tue Apr 21 17:24:20 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Tue, 21 Apr 2015 18:24:20 +0300 Subject: [Development] Rotating JPEG images by default In-Reply-To: <201504171048.09913.kde@carewolf.com> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> Message-ID: <55366BA4.5050109@users.sourceforge.net> On 04/17/2015 11:48 AM, Allan Sandfeld Jensen wrote: > If we go with the QImageReader level, it could be an QImageIOHandler::Option, > and possibly be set different between JPEG and TIFF by default. The real > problem is what we decide the default for JPEG should be now. IMHO, QImageReader default behaviour should be that of providing a rendered image that looks as visually correct as possible. Whether the orientation is encoded in the image bits or as an EXIF tag is rather irrelevant: the result should be that the QImage contains the image shown with the proper orientation. So, I'm very happy that this bug has been fixed. On the other hand, since we had applications which had already implemented workarounds for this, we should have a way to let them know whether they are using a new Qt image plugin which contains this fix or not. Adding an orientation option to QImageIOHandler::ImageOption would be a possibility. Ciao, Alberto From rjvbertin at gmail.com Tue Apr 21 17:51:13 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Apr 2015 17:51:13 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <8285051.Kpv32sV6lG@finn> References: <1428661428222.50531@theqtcompany.com> <1689672.V2B1A6Ptre@portia.local> <8285051.Kpv32sV6lG@finn> Message-ID: <7499745.oEXbmFEgEW@portia.local> On Tuesday April 21 2015 16:38:57 Olivier Goffart wrote: > That's not the point. That *was* not my point. Which was: who knows how many users have been working around it, or putting up with it, as I used to do. > As I said, i don't know the specific details of this patch, but the problem is > the same. If you get a different font (because you get the more 'proper' font > now), then this can break applications layout. > It is a behaviour change that should not be part of a patch release. The removal of a crashing bug which people avoid by using undocumented features (that might be affected by a proper fix) is also a behavioural change that line of thought... The issue also isn't that font selection through the font dialog doesn't work. It does. Common font weights and styles also get restored properly. That won't change. The only cases in which layout that will change is when applications rely on getting the wrong font, one way or another. In other words, they exploit undocumented behaviour, and that should be their problem. > > (And honestly, it is not too hard to switch branches. If you can build 5.4 it > is no more work to build 5.5 or dev) Sure, if I really had unlimited time and resources at my disposal I wouldn't mind. That's not the case, so I'm not going to be wasting hours of those I do have to build something I'm not going to use. And certainly not if we're talking about 5.6, because that would mean I'll also have to tackle 5.5 and if so ... well, no thanks. R From thiago.macieira at intel.com Tue Apr 21 19:07:49 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Apr 2015 10:07:49 -0700 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <7499745.oEXbmFEgEW@portia.local> References: <1428661428222.50531@theqtcompany.com> <8285051.Kpv32sV6lG@finn> <7499745.oEXbmFEgEW@portia.local> Message-ID: <4511101.Zm8kU3AyCD@tjmaciei-mobl4> On Tuesday 21 April 2015 17:51:13 René J.V. Bertin wrote: > > That's not the point. > > That *was* not my point. Which was: who knows how many users have been > working around it, or putting up with it, as I used to do. Either they've been putting up with it or they've never noticed. Either way, that makes the bug not critical for a patch release. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Apr 21 21:19:43 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Apr 2015 21:19:43 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <4511101.Zm8kU3AyCD@tjmaciei-mobl4> References: <1428661428222.50531@theqtcompany.com> <7499745.oEXbmFEgEW@portia.local> <4511101.Zm8kU3AyCD@tjmaciei-mobl4> Message-ID: <2202139.fAVHDLFue7@portia.local> On Tuesday April 21 2015 10:07:49 Thiago Macieira wrote: > Either they've been putting up with it or they've never noticed. Either way, > that makes the bug not critical for a patch release. Possibly. I've just tried to create a code review for the Qt 4.8 version of my patch. Damn system refused to let me push anything where before I've been able to do so. Too bad. The patch will be available through github for anyone who finds this critical enough to (re)build Qt for it. R. From me at the-compiler.org Tue Apr 21 21:23:13 2015 From: me at the-compiler.org (Florian Bruhin) Date: Tue, 21 Apr 2015 21:23:13 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <2202139.fAVHDLFue7@portia.local> References: <1428661428222.50531@theqtcompany.com> <7499745.oEXbmFEgEW@portia.local> <4511101.Zm8kU3AyCD@tjmaciei-mobl4> <2202139.fAVHDLFue7@portia.local> Message-ID: <20150421192313.GN429@tonks> Hi René, * René J.V. Bertin [2015-04-21 21:19:43 +0200]: > On Tuesday April 21 2015 10:07:49 Thiago Macieira wrote: > > > Either they've been putting up with it or they've never noticed. Either way, > > that makes the bug not critical for a patch release. > > Possibly. > > I've just tried to create a code review for the Qt 4.8 version of my patch. Damn system refused to let me push anything where before I've been able to do so. > Too bad. The patch will be available through github for anyone who finds this critical enough to (re)build Qt for it. I'm sure enough people here will be more than happy to help you with that, but it'd be useful to know what exactly went wrong. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rjvbertin at gmail.com Tue Apr 21 22:32:51 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Apr 2015 22:32:51 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <20150421192313.GN429@tonks> References: <1428661428222.50531@theqtcompany.com> <2202139.fAVHDLFue7@portia.local> <20150421192313.GN429@tonks> Message-ID: <3716059.uszEVF6kYt@portia.local> On Tuesday April 21 2015 21:23:13 Florian Bruhin wrote: Hi Florian, > I'm sure enough people here will be more than happy to help you with > that, but it'd be useful to know what exactly went wrong. It looked as if commits are no longer accepted, and that's after I configured https upload because my SSH key was being refused too. Maybe a transient glitch, but it'll be about a week before I'll have time to look at this again. R From rjvbertin at gmail.com Tue Apr 21 23:36:29 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 21 Apr 2015 23:36:29 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <20150421192313.GN429@tonks> References: <1428661428222.50531@theqtcompany.com> <2202139.fAVHDLFue7@portia.local> <20150421192313.GN429@tonks> Message-ID: <4966757.l8t9Ny5hJ3@portia.local> On Tuesday April 21 2015 21:23:13 Florian Bruhin wrote: Hi > I'm sure enough people here will be more than happy to help you with In the meantime, this site was more than happy to accept my patch - no gitting or committing required :) https://git.reviewboard.kde.org/r/123458/ R. From thiago.macieira at intel.com Wed Apr 22 00:02:33 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Apr 2015 15:02:33 -0700 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <3716059.uszEVF6kYt@portia.local> References: <1428661428222.50531@theqtcompany.com> <20150421192313.GN429@tonks> <3716059.uszEVF6kYt@portia.local> Message-ID: <13118214.RHE6ab7hip@tjmaciei-mobl4> On Tuesday 21 April 2015 22:32:51 René J.V. Bertin wrote: > On Tuesday April 21 2015 21:23:13 Florian Bruhin wrote: > > Hi Florian, > > > I'm sure enough people here will be more than happy to help you with > > that, but it'd be useful to know what exactly went wrong. > > It looked as if commits are no longer accepted, and that's after I > configured https upload because my SSH key was being refused too. Maybe a > transient glitch, but it'll be about a week before I'll have time to look > at this again. That would be wrong, since commits are accepted into 4.8, including via SSH. I know because I've just tested. Like I said, if you don't post the error and the steps you took, you're not going to get help. If after twice being asked to post them you still don't but complain publicly again, you're not asking for help -- you're just whining. So don't bother posting them now, I'll not help you. > In the meantime, this site was more than happy to accept my patch - no > gitting or committing required > > https://git.reviewboard.kde.org/r/123458/ Sure, but your patch should be rejected there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Wed Apr 22 02:14:47 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 22 Apr 2015 02:14:47 +0200 Subject: [Development] [Announce] Qt Project Security Advisory - Multiple Vulnerabilities in Qt Image Format Handling References: Message-ID: Hi, for those who still care about Qt 3, I looked into these vulnerabilities: > CVE-2015-1858 BMP vulnerability To the best of my knowledge, Qt 3 is NOT vulnerable to this issue, for the following reason: The security fix from Qt 4 changes the relevant code sequence in the BMP/DIB reader from "protection, get characters, update p" to "get characters, protection, update p". The Qt 3 code was already using the correct "get characters, protection, update p" order. ("get characters" increments the x and y variables, "protection" checks them.) The character reading code was modified for Qt 4, apparently introducing this bug. > CVE-2015-1859 ICO vulnerability To the best of my knowledge, Qt 3 is NOT vulnerable to this issue, because it does not include an ICO reader. (ICO reading in Qt 3 was provided only in kdelibs3's kimgio, which uses completely different code.) > CVE-2015-1860 GIF vulnerability Qt 3 appears to be VULNERABLE to this issue. I backported the fix from Qt 4: http://pkgs.fedoraproject.org/cgit/qt3.git/plain/qt-x11-free-3.3.8b-CVE-2015-1860.patch Please note that Qt 3 is NOT supported by the Qt Project anymore. The above backported patch (CVE-2015-1860) and statements of non-vulnerability (CVE-2015-1858/1859) are user-contributed (by me, a volunteer Fedora packager) on a purely as-is basis. I hope this helps, Kevin Kofler From thiago.macieira at intel.com Wed Apr 22 03:04:43 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 21 Apr 2015 18:04:43 -0700 Subject: [Development] [Announce] Qt Project Security Advisory - Multiple Vulnerabilities in Qt Image Format Handling In-Reply-To: References: Message-ID: <1789205.FcvNmk1oQT@tjmaciei-mobl4> On Wednesday 22 April 2015 02:14:47 Kevin Kofler wrote: > > CVE-2015-1860 GIF vulnerability > > Qt 3 appears to be VULNERABLE to this issue. I backported the fix from Qt 4: > http://pkgs.fedoraproject.org/cgit/qt3.git/plain/qt-x11-free-3.3.8b-CVE-201 > 5-1860.patch > > Please note that Qt 3 is NOT supported by the Qt Project anymore. The above > backported patch (CVE-2015-1860) and statements of non-vulnerability > (CVE-2015-1858/1859) are user-contributed (by me, a volunteer Fedora > packager) on a purely as-is basis. > > I hope this helps, > Kevin Kofler Thanks Kevin, the patch is useful. Richard, can you relay Kevin's patch to the distro security announcements too? They may find it useful. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Wed Apr 22 08:39:36 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Wed, 22 Apr 2015 08:39:36 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <55366BA4.5050109@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> Message-ID: <55374228.7070608@familiesomers.nl> Alberto Mardegan schreef op 21-4-2015 om 17:24: > On 04/17/2015 11:48 AM, Allan Sandfeld Jensen wrote: >> If we go with the QImageReader level, it could be an QImageIOHandler::Option, >> and possibly be set different between JPEG and TIFF by default. The real >> problem is what we decide the default for JPEG should be now. > IMHO, QImageReader default behaviour should be that of providing a > rendered image that looks as visually correct as possible. Whether the > orientation is encoded in the image bits or as an EXIF tag is rather > irrelevant: the result should be that the QImage contains the image > shown with the proper orientation. > So, I'm very happy that this bug has been fixed. I'm with Konstatin on this one: it seems like a regression to me. It would be a useful feature to add, but then add it in such a way that it is actually clear what it does, the user can control it, and it does not break applications. I think it _is_ relevant how the image is encoded. If the camera really wanted to put the image in the right side up, it should have just rotated the actual image. By default, I would expect to load the image as-is. > On the other hand, since we had applications which had already > implemented workarounds for this, we should have a way to let them know > whether they are using a new Qt image plugin which contains this fix or not. > Adding an orientation option to QImageIOHandler::ImageOption would be a > possibility. > Yeah, but do it the other way around: make applying a rotation encoded in the meta data of an image optional, and make it a symetric interface (also provide a setter). André From rjvbertin at gmail.com Wed Apr 22 09:55:52 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 22 Apr 2015 09:55:52 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <13118214.RHE6ab7hip@tjmaciei-mobl4> References: <1428661428222.50531@theqtcompany.com> <3716059.uszEVF6kYt@portia.local> <13118214.RHE6ab7hip@tjmaciei-mobl4> Message-ID: <1856781.nkBWOZXb7x@patux> On Tuesday April 21 2015 15:02:33 Thiago Macieira >... just whining. No comment. But just for the record, I was indeed annoyed (with myself at least as much as with gerrit) but otherwise just observing a fact. I think I made it clear enough that I wasn't going to have time to spend on the issue for a bit. >> https://git.reviewboard.kde.org/r/123458/ > >Sure, but your patch should be rejected there. Opinion, not a fact. The patch is up there for review and reference, not to sneak into Qt via a backdoor. There is no backdoor, only a mirror of the main repository. R. From mardy at users.sourceforge.net Wed Apr 22 13:32:51 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Wed, 22 Apr 2015 14:32:51 +0300 Subject: [Development] Rotating JPEG images by default In-Reply-To: <55374228.7070608@familiesomers.nl> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> Message-ID: <553786E3.2060805@users.sourceforge.net> On 04/22/2015 09:39 AM, André Somers wrote: > I'm with Konstatin on this one: it seems like a regression to me. It > would be a useful feature to add, but then add it in such a way that it > is actually clear what it does, the user can control it, and it does not > break applications. I think it _is_ relevant how the image is encoded. It may be that we disagree because we have a different view of what is the goal of QImage and friends. To me, what matters is not the pixel data, but how the image looks like when I blit it. I'm writing an image viewer using QML, and I just expect that Image { source: "file.jpg" } will show me the file as it's intended to be viewed. I don't think that it's acceptable to require the developer to play with flags in order to see the image with the correct rotation. > If the camera really wanted to put the image in the right side up, it > should have just rotated the actual image. By default, I would expect to > load the image as-is. We disagree on what "as-is" means. :-) For me, EXIF information is an integral part of the image. Also, sometimes the camera guesses the orientation wrong (especially when you shoot at the sky or at the ground), and the best way to correct that is to do it in a lossless way, using the EXIF rotation flag; there are several image viewers that allow you to do this. Ciao, Alberto From rpzrpzrpz at gmail.com Wed Apr 22 13:44:00 2015 From: rpzrpzrpz at gmail.com (rpzrpzrpz at gmail.com) Date: Wed, 22 Apr 2015 05:44:00 -0600 Subject: [Development] Building Modules In-Reply-To: <4055514.CO8XyQPJgk@tjmaciei-mobl4> References: <4055514.CO8XyQPJgk@tjmaciei-mobl4> Message-ID: <55378980.8050409@gmail.com> Thiago: Unfortunately, your suggestion of removing the directory and/or its contents did not yield a positive result. How does one successfully remove a sub-module from the build process? Copied below is the nmake output after removing the contents of the qlalr directory and the directory itself as a second test. Thank you, md nmake -f Makefile.Release Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 Copyright (C) Microsoft Corporation. All rights reserved. cd tools\qlalr\ && ( if not exist Makefile C:\qt5\qtbase\bin\qmake C:\qt5\qtbase\src\tools\qlalr\qlalr.pro -o Makefile ) && nmake -f Makefile Cannot find file: C:\qt5\qtbase\src\tools\qlalr\qlalr.pro . NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. On 4/18/2015 3:00 PM, Thiago Macieira wrote: > On Saturday 18 April 2015 09:47:28 mark diener wrote: >> Hello: >> >> How does one remove a submodule from a git repository build? >> >> (even if I already downloaded it) >> >> In this case, I want qlalr submodule to be removed from the build process. >> >> Qlalr does not build on Windows > > rm -rf qlalr > -- No spell checkers were harmed during the creation of this message. From abbapoh at gmail.com Wed Apr 22 13:57:47 2015 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Wed, 22 Apr 2015 14:57:47 +0300 Subject: [Development] Rotating JPEG images by default In-Reply-To: <553786E3.2060805@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> Message-ID: I think, there should be an option in Image item to use autorotation or not 2015-04-22 14:32 GMT+03:00 Alberto Mardegan : > On 04/22/2015 09:39 AM, André Somers wrote: > > I'm with Konstatin on this one: it seems like a regression to me. It > > would be a useful feature to add, but then add it in such a way that it > > is actually clear what it does, the user can control it, and it does not > > break applications. I think it _is_ relevant how the image is encoded. > > It may be that we disagree because we have a different view of what is > the goal of QImage and friends. To me, what matters is not the pixel > data, but how the image looks like when I blit it. > I'm writing an image viewer using QML, and I just expect that > > Image { > source: "file.jpg" > } > > will show me the file as it's intended to be viewed. I don't think that > it's acceptable to require the developer to play with flags in order to > see the image with the correct rotation. > > > If the camera really wanted to put the image in the right side up, it > > should have just rotated the actual image. By default, I would expect to > > load the image as-is. > > We disagree on what "as-is" means. :-) For me, EXIF information is an > integral part of the image. > Also, sometimes the camera guesses the orientation wrong (especially > when you shoot at the sky or at the ground), and the best way to correct > that is to do it in a lossless way, using the EXIF rotation flag; there > are several image viewers that allow you to do this. > > Ciao, > Alberto > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Wed Apr 22 17:47:27 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Wed, 22 Apr 2015 19:47:27 +0400 Subject: [Development] Rotating JPEG images by default In-Reply-To: <553786E3.2060805@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> Message-ID: Konstantin 2015-04-22 15:32 GMT+04:00 Alberto Mardegan : > On 04/22/2015 09:39 AM, André Somers wrote: > > I'm with Konstatin on this one: it seems like a regression to me. It > > would be a useful feature to add, but then add it in such a way that it > > is actually clear what it does, the user can control it, and it does not > > break applications. I think it _is_ relevant how the image is encoded. > > It may be that we disagree because we have a different view of what is > the goal of QImage and friends. To me, what matters is not the pixel > data, but how the image looks like when I blit it. > I'm writing an image viewer using QML, and I just expect that > > Image { > source: "file.jpg" > } > > will show me the file as it's intended to be viewed. I don't think that > it's acceptable to require the developer to play with flags in order to > see the image with the correct rotation. > In your image viewer, you'll have 99 other QML Image elements for buttons/background/whatever that doesn't load photos. I don't think your expectation/intention is to make all your UI elements 1) dependent on a metadata ignored by most image viewers (- crap, editor shows me a 400x300 image and it appears to be 300x400 in QML. stupid QML! stupid trolls! I need to kill someone...) 2) behave differently prior to 5.4 and after 5.4. Enabling that feature in 5.4 IS a behavioral regression which must be fixed. > If the camera really wanted to put the image in the right side up, it > > should have just rotated the actual image. By default, I would expect to > > load the image as-is. > > We disagree on what "as-is" means. :-) For me, EXIF information is an > integral part of the image. > Regardless of how you interpret "image as it's intended to be viewed", CSS doesn't do auto-rotation by default - one have to enable this feature where needed. > Also, sometimes the camera guesses the orientation wrong (especially > when you shoot at the sky or at the ground), and the best way to correct > that is to do it in a lossless way, using the EXIF rotation flag; there > are several image viewers that allow you to do this. > Unrelated. It doesn't matter where to transform - on the camera, in the viewer, or at load time. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gunnar.roth at gmx.de Wed Apr 22 18:22:02 2015 From: gunnar.roth at gmx.de (Gunnar Roth) Date: Wed, 22 Apr 2015 18:22:02 +0200 Subject: [Development] Building Modules In-Reply-To: <55378980.8050409@gmail.com> References: <4055514.CO8XyQPJgk@tjmaciei-mobl4> <55378980.8050409@gmail.com> Message-ID: <5FE7F6D7-1C8D-4612-8BC5-F96594DD62BF@gmx.de> Looks like you removed the directory AFTER configure. But you should remove it before. Regards, Gunnar > Am 22.04.2015 um 13:44 schrieb rpzrpzrpz at gmail.com: > > > Thiago: > > Unfortunately, your suggestion of removing the directory and/or its > contents did not yield a positive result. > > How does one successfully remove a sub-module from the build process? > > Copied below is the nmake output after removing the contents of the > qlalr directory and the directory itself as a second test. > > Thank you, > > md > > nmake -f Makefile.Release > > Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > cd tools\qlalr\ && ( if not exist Makefile > C:\qt5\qtbase\bin\qmake C:\qt5\qtbase\src\tools\qlalr\qlalr.pro > -o Makefile ) && nmake -f Makefile > Cannot find file: C:\qt5\qtbase\src\tools\qlalr\qlalr.pro > . > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > NMAKE : fatal error U1077: 'cd' : return code '0x2' > Stop. > > On 4/18/2015 3:00 PM, Thiago Macieira wrote: >> On Saturday 18 April 2015 09:47:28 mark diener wrote: >>> Hello: >>> >>> How does one remove a submodule from a git repository build? >>> >>> (even if I already downloaded it) >>> >>> In this case, I want qlalr submodule to be removed from the build process. >>> >>> Qlalr does not build on Windows >> >> rm -rf qlalr >> > > -- > No spell checkers were harmed during the creation of this message. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Apr 22 19:23:56 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Apr 2015 10:23:56 -0700 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <1856781.nkBWOZXb7x@patux> References: <1428661428222.50531@theqtcompany.com> <13118214.RHE6ab7hip@tjmaciei-mobl4> <1856781.nkBWOZXb7x@patux> Message-ID: <2931895.hU6UUbtNnX@tjmaciei-mobl4> On Wednesday 22 April 2015 09:55:52 René J.V. Bertin wrote: > >> https://git.reviewboard.kde.org/r/123458/ > > > >Sure, but your patch should be rejected there. > > Opinion, not a fact. > > The patch is up there for review and reference, not to sneak into Qt via a > backdoor. There is no backdoor, only a mirror of the main repository. Which is exactly why it should be rejected: if it's a mirror, it shouldn't contain additional changes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From apoenitz at t-online.de Wed Apr 22 20:54:06 2015 From: apoenitz at t-online.de (=?iso-8859-1?Q?Andr=E9_P=F6nitz?=) Date: Wed, 22 Apr 2015 20:54:06 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <553786E3.2060805@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> Message-ID: <20150422185406.GA2468@klara.mpi.htwm.de> On Wed, Apr 22, 2015 at 02:32:51PM +0300, Alberto Mardegan wrote: > On 04/22/2015 09:39 AM, André Somers wrote: > > I'm with Konstatin on this one: I am, too. > > it seems like a regression to me. It > > would be a useful feature to add, but then add it in such a way that it > > is actually clear what it does, the user can control it, and it does not > > break applications. I think it _is_ relevant how the image is encoded. And I agree with André here. > It may be that we disagree because we have a different view of what is > the goal of QImage and friends. QImage is traditionally closer to "pixel manipulation" than to "display", which is QPixmap's domain, albeit both with quite some wiggle room. > To me, what matters is not the pixel > data, but how the image looks like when I blit it. That's of course one possible expectation, and without further context possibly even a reasonable one. However, we do have context here, namely existing behaviour in Qt 5.x, as well as certain general promises given for changes between Qt 5.x and Qt 5.(x+1). > I'm writing an image viewer using QML, and I just expect that > > Image { > source: "file.jpg" > } > > will show me the file as it's intended to be viewed. I don't think that > it's acceptable to require the developer to play with flags in order to > see the image with the correct rotation. Even though "no behaviour change" isn't one of the guarantees, I don't think rotating part of an application's GUI by 90 degrees behind the developer's back is acceptable. If an application accepts such change it should announce it by explicitly opting in, i.e. by setting a flag/calling a function/whatever. Andre' [another one] From mardy at users.sourceforge.net Thu Apr 23 00:11:23 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 23 Apr 2015 01:11:23 +0300 Subject: [Development] Rotating JPEG images by default In-Reply-To: <20150422185406.GA2468@klara.mpi.htwm.de> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> <20150422185406.GA2468@klara.mpi.htwm.de> Message-ID: <55381C8B.6080708@users.sourceforge.net> On 04/22/2015 09:54 PM, André Pönitz wrote: > However, we do have context here, namely existing behaviour in Qt 5.x, > as well as certain general promises given for changes between Qt 5.x and > Qt 5.(x+1). I see it as a long standing bug which finally got fixed. But the problem is that the behavioural change is already out there, with Qt 5.4. I think it would be easier to have a runtime check on the QT version (and eventually drop the local workarounds) than to introduce another behavioural change in the next Qt version. > Even though "no behaviour change" isn't one of the guarantees, I don't > think rotating part of an application's GUI by 90 degrees behind the > developer's back is acceptable. It's very unlikely that such images are used as part of the GUI. But I'm nitpicking, I certainly agree with you that the behavioural change is a major annoyance. However, if application developers had filed this bug earlier, instead of silently working around it in their application, we wouldn't even be discussing this. So, in a way, I believe that if this behavioural change affects someone in a bad way, some part of the blame falls on his side too. > If an application accepts such change it should announce it by explicitly > opting in, i.e. by setting a flag/calling a function/whatever. Actually, this sounds like a very good idea; I wouldn't mind if this was a opt-in, as long as the behaviour was configurable with a single line change (a static method on QGuiApplication, maybe?). As long as I don't have to change it in every single QImage/QML Image, all is fine to me. Ciao, Alberto From rpzrpzrpz at gmail.com Thu Apr 23 01:29:28 2015 From: rpzrpzrpz at gmail.com (mark diener) Date: Wed, 22 Apr 2015 17:29:28 -0600 Subject: [Development] Building Modules In-Reply-To: <3024797.xHFHXZ1j20@tjmaciei-mobl4> References: <4055514.CO8XyQPJgk@tjmaciei-mobl4> <3024797.xHFHXZ1j20@tjmaciei-mobl4> Message-ID: Thiago and Gunnar: Thank you for your suggestions, yet none of them work. To shrink my test environment, I downloaded the 2 source code files as a minimum build test. http://download.qt.io/official_releases/qt/5.4/5.4.1/submodules/qt5-opensource-src-5.4.1.7z http://download.qt.io/official_releases/qt/5.4/5.4.1/submodules/qtbase-opensource-src-5.4.1.7z And unzipped them to a qt5 directory, with the contents of opensource-srcxxx.7z in the C:\qt5 directory and qtbasexxx.7z contents unzipped to C:\qt5\qtbase. Then I physically remove the qlalr directory and run configure: configure -prefix C:\Qt541\swin32 -opensource -opengl desktop -nomake tests The result is still the same, that bloody QLALR is STILL in the build process! As per Thiago, I ran nmake qmake and re-run nmake (post configure) with no success. So I ask WHY is the build process looking for qlalr.pro when the directory does not exist before running configure? Here is the result of configure/make on the above source files and the immediate removal of C:\qt5\qtbase\src\tools\qlalr from the tree : nmake building feedback.... then... moc_qhistorystate.cpp moc_qabstracttransition.cpp moc_qsignaltransition.cpp moc_qeventtransition.cpp Generating Code... link /NOLOGO /DYNAMICBASE /NXCOMPAT /BASE:0x67000000 /INCREMENTAL:NO /DLL /SUBSYSTEM:WINDOWS /VERSION:5.41 /MANIFEST:embed /OUT:..\..\lib\Qt5Core.dll @C:\Users\md\AppData\Local\Temp\ nm271C.tmp Creating library ..\..\lib\Qt5Core.lib and object ..\..\lib\Qt5Core.exp cd tools\qlalr\ && ( if not exist Makefile C:\qt5\bin\qmake C:\qt5\src\tools\qlalr\qlalr.pro -o Makefile ) && "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\BIN\nmake.exe" - f Makefile Cannot find file: C:\qt5\src\tools\qlalr\qlalr.pro. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. c:\qt5> YIKES! On Wed, Apr 22, 2015 at 10:22 AM, Thiago Macieira wrote: > You need to remove before running configure. If you do it after running > configure, run > nmake qmake > > So that the Makefiles get regenerated. > > On Wednesday 22 April 2015 00:44:28 you wrote: > > Thiago: > > > > Unfortunately, your suggestion of removing the directory and/or its > > contents did not yield a positive result. > > > > How does one successfully remove a sub-module from the build process? > > > > Copied below is the nmake output after removing the contents of the qlalr > > directory and the directory itself as a second test. > > > > Thank you, > > > > md > > > > nmake -f Makefile.Release > > > > Microsoft (R) Program Maintenance Utility Version 12.00.21005.1 > > Copyright (C) Microsoft Corporation. All rights reserved. > > > > cd tools\qlalr\ && ( if not exist Makefile > C:\qt5\qtbase\bin\qmake > > C:\qt5\qtbase\src\tools\qlalr\qlalr.pro -o Makefile ) && nmake -f > Makefile > > Cannot find file: C:\qt5\qtbase\src\tools\qlalr\qlalr.pro. > > NMAKE : fatal error U1077: 'cd' : return code '0x2' > > Stop. > > NMAKE : fatal error U1077: 'cd' : return code '0x2' > > Stop. > > NMAKE : fatal error U1077: 'cd' : return code '0x2' > > Stop. > > > > > > > > On Sat, Apr 18, 2015 at 3:00 PM, Thiago Macieira < > thiago.macieira at intel.com> > > wrote: > > > On Saturday 18 April 2015 09:47:28 mark diener wrote: > > > > Hello: > > > > > > > > How does one remove a submodule from a git repository build? > > > > > > > > (even if I already downloaded it) > > > > > > > > In this case, I want qlalr submodule to be removed from the build > > > > > > process. > > > > > > > Qlalr does not build on Windows > > > > > > rm -rf qlalr > > > -- > > > Thiago Macieira - thiago.macieira (AT) intel.com > > > > > > Software Architect - Intel Open Source Technology Center > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Apr 23 02:13:14 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Apr 2015 17:13:14 -0700 Subject: [Development] Building Modules In-Reply-To: References: <3024797.xHFHXZ1j20@tjmaciei-mobl4> Message-ID: <2715128.ObKsc41sO9@tjmaciei-mobl4> On Wednesday 22 April 2015 17:29:28 mark diener wrote: > Thiago and Gunnar: > > Thank you for your suggestions, yet none of them work. > > To shrink my test environment, I downloaded the 2 source code files as a > minimum build test. > > http://download.qt.io/official_releases/qt/5.4/5.4.1/submodules/qt5-opensour > ce-src-5.4.1.7z > http://download.qt.io/official_releases/qt/5.4/5.4.1/submodules/qtbase-open > source-src-5.4.1.7z You don't need the first one. You only need qtbase. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jkt at kde.org Thu Apr 23 02:26:22 2015 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Thu, 23 Apr 2015 02:26:22 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <2202139.fAVHDLFue7@portia.local> References: <1428661428222.50531@theqtcompany.com> <7499745.oEXbmFEgEW@portia.local> <4511101.Zm8kU3AyCD@tjmaciei-mobl4> <2202139.fAVHDLFue7@portia.local> Message-ID: <57c60756-0fda-44b1-a091-6847f742821b@kde.org> On Tuesday, 21 April 2015 21:19:43 CEST, René J.V. Bertin wrote: > Damn system refused to let me push anything where before I've > been able to do so. Hi René, what did the damn system say, and what command did you use to send your patch to that damn system? Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From jkt at kde.org Thu Apr 23 02:29:29 2015 From: jkt at kde.org (=?iso-8859-1?Q?Jan_Kundr=E1t?=) Date: Thu, 23 Apr 2015 02:29:29 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <55381C8B.6080708@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> <20150422185406.GA2468@klara.mpi.htwm.de> <55381C8B.6080708@users.sourceforge.net> Message-ID: <5891aa93-d172-4318-b305-e4379ab6cb96@kde.org> On Thursday, 23 April 2015 00:11:23 CEST, Alberto Mardegan wrote: > as long as the behaviour was configurable with a single line > change (a static method on QGuiApplication, maybe?). That means that you will have to patch all libraries which care about this option and which you're using at the same time. I don't think that this is realistic. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ From rpzrpzrpz at gmail.com Thu Apr 23 02:36:01 2015 From: rpzrpzrpz at gmail.com (mark diener) Date: Wed, 22 Apr 2015 18:36:01 -0600 Subject: [Development] Building Modules In-Reply-To: <2715128.ObKsc41sO9@tjmaciei-mobl4> References: <3024797.xHFHXZ1j20@tjmaciei-mobl4> <2715128.ObKsc41sO9@tjmaciei-mobl4> Message-ID: Gunnar & Thiago: Ok, thanks, that will shrink my build test footprint even more. I think the magic configure switch is "-nomake tools" on Visual Studio 2013 Win32 I missed it during the scanning of options for configure.bat, and that caused much consternation. But now I can run nmake, nmake install without error. Thank you again for your frequent and prompt suggestions. Cheers, md On Wed, Apr 22, 2015 at 6:13 PM, Thiago Macieira wrote: > On Wednesday 22 April 2015 17:29:28 mark diener wrote: > > Thiago and Gunnar: > > > > Thank you for your suggestions, yet none of them work. > > > > To shrink my test environment, I downloaded the 2 source code files as a > > minimum build test. > > > > > http://download.qt.io/official_releases/qt/5.4/5.4.1/submodules/qt5-opensour > > ce-src-5.4.1.7z > > > http://download.qt.io/official_releases/qt/5.4/5.4.1/submodules/qtbase-open > > source-src-5.4.1.7z > > You don't need the first one. You only need qtbase. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Thu Apr 23 02:38:06 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 22 Apr 2015 17:38:06 -0700 Subject: [Development] Building Modules In-Reply-To: References: <2715128.ObKsc41sO9@tjmaciei-mobl4> Message-ID: <1942092.7TAiG2nzes@tjmaciei-mobl4> On Wednesday 22 April 2015 18:36:01 mark diener wrote: > Gunnar & Thiago: > > Ok, thanks, that will shrink my build test footprint even more. > > I think the magic configure switch is "-nomake tools" on Visual Studio > 2013 Win32 > > I missed it during the scanning of options for configure.bat, and that > caused much consternation. qtbase has no tools (the tools directory contains the configure.exe's source only), so -nomake tools is a no-op. You definitely want -nomake tests and you may want -nomake examples. However, the -nomake tools option is recorded so if you built qtdeclarative afterwards, it would skip building the qtdeclarative tools. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ritt.ks at gmail.com Thu Apr 23 03:53:08 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 23 Apr 2015 05:53:08 +0400 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5891aa93-d172-4318-b305-e4379ab6cb96@kde.org> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> <20150422185406.GA2468@klara.mpi.htwm.de> <55381C8B.6080708@users.sourceforge.net> <5891aa93-d172-4318-b305-e4379ab6cb96@kde.org> Message-ID: > > On Thursday, 23 April 2015 00:11:23 CEST, Alberto Mardegan wrote: > > as long as the behaviour was configurable with a single line > > change (a static method on QGuiApplication, maybe?). > Stop polluting QGuiApplication! Seriously. We already have a complete solution - https://codereview.qt-project.org/110685 All we need now is to fix the behavioral regression introduced in 5.4. Konstantin P.S. I bet most of you didn't know about this new cool feature until this thread, just like me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andre at familiesomers.nl Thu Apr 23 07:34:21 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Thu, 23 Apr 2015 07:34:21 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <553786E3.2060805@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> Message-ID: <5538845D.4060700@familiesomers.nl> Alberto Mardegan schreef op 22-4-2015 om 13:32: > > It may be that we disagree because we have a different view of what is > the goal of QImage and friends. To me, what matters is not the pixel > data, but how the image looks like when I blit it. > I'm writing an image viewer using QML, and I just expect that > > Image { > source: "file.jpg" > } > > will show me the file as it's intended to be viewed. I don't think that > it's acceptable to require the developer to play with flags in order to > see the image with the correct rotation. > Please note that QImage isn't the same as the QML/Quick Image element. I think your example confuses the discussion. QImage is not a class that does displaying of images on the screen. I am not against adding a property autoRotate or something like that on the Image element at all (but again: not enabled by default please). André From rjvbertin at gmail.com Thu Apr 23 09:31:42 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 23 Apr 2015 09:31:42 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <57c60756-0fda-44b1-a091-6847f742821b@kde.org> References: <1428661428222.50531@theqtcompany.com> <2202139.fAVHDLFue7@portia.local> <57c60756-0fda-44b1-a091-6847f742821b@kde.org> Message-ID: <1852105.q4fxhfIq6n@patux> On Thursday April 23 2015 02:26:22 Jan Kundrát wrote: Hi, >what did the damn system say, and what command did you use to send your >patch to that damn system? I cannot answer that exactly, I was trying to do the push amidst the preparations for a trip which I'm now on and which explains that the "we'll see next week" bit of my message. The successful tickets I created were done with Atlassian SourceTree, which I tried using again but I also tried the command shown in the online documentation. It's not like I tried once without any RTFM and then made a public announcement of defeat. R. From mardy at users.sourceforge.net Thu Apr 23 10:00:08 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 23 Apr 2015 11:00:08 +0300 Subject: [Development] Rotating JPEG images by default In-Reply-To: References: <5530B1F3.4080501@theqtcompany.com> <1429258110380.33705@theqtcompany.com> <201504171048.09913.kde@carewolf.com> <55366BA4.5050109@users.sourceforge.net> <55374228.7070608@familiesomers.nl> <553786E3.2060805@users.sourceforge.net> <20150422185406.GA2468@klara.mpi.htwm.de> <55381C8B.6080708@users.sourceforge.net> <5891aa93-d172-4318-b305-e4379ab6cb96@kde.org> Message-ID: <5538A688.1000202@users.sourceforge.net> On 04/23/2015 04:53 AM, Konstantin Ritt wrote: > We already have a complete solution - > https://codereview.qt-project.org/110685 That looks good. > All we need now is to fix the behavioral regression introduced in 5.4. But if I understand the code correctly, the fix above gives developers an option to opt *out* of the automatic rotation, so it will still behave differently than Qt < 5.4, unless the developer updates his app to use the new API. Which to me is all very good, but I think it's not what you have been suggesting in this thread. Ciao, Alberto From syntheticpp at gmx.net Thu Apr 23 11:13:41 2015 From: syntheticpp at gmx.net (Peter Kuemmel) Date: Thu, 23 Apr 2015 11:13:41 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <1852105.q4fxhfIq6n@patux> References: <1428661428222.50531@theqtcompany.com> <2202139.fAVHDLFue7@portia.local> <57c60756-0fda-44b1-a091-6847f742821b@kde.org>, <1852105.q4fxhfIq6n@patux> Message-ID: René, maybe this helps you a bit: https://codereview.qt-project.org/#/c/111056/ It's only a incomplete copy and paste of your Qt 4 patch, but it could show you the direction. Peter From kde at carewolf.com Thu Apr 23 12:03:14 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 23 Apr 2015 12:03:14 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5538A688.1000202@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> Message-ID: <201504231203.14249.kde@carewolf.com> On Thursday 23 April 2015, Alberto Mardegan wrote: > On 04/23/2015 04:53 AM, Konstantin Ritt wrote: > > We already have a complete solution - > > https://codereview.qt-project.org/110685 > > That looks good. > > > All we need now is to fix the behavioral regression introduced in 5.4. > > But if I understand the code correctly, the fix above gives developers > an option to opt *out* of the automatic rotation, so it will still > behave differently than Qt < 5.4, unless the developer updates his app > to use the new API. > > Which to me is all very good, but I think it's not what you have been > suggesting in this thread. > It has gone through several iterations, and this is where it is currently at. If there is a consensus to change the defaults the patch can easily be amended again. Right now I don't see a consensus though, and personally lean both ways. `Allan From gunnar at sletta.org Thu Apr 23 12:36:05 2015 From: gunnar at sletta.org (Gunnar Sletta) Date: Thu, 23 Apr 2015 12:36:05 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <201504231203.14249.kde@carewolf.com> References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> <201504231203.14249.kde@carewolf.com> Message-ID: <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> I think we should strive to not introduce regressions on purpose. Hence: - Revert the behavioral change in 5.4 which adds rotation to JPEGs - Have opt-in rotation in QImageReader. - Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6) Anything else will cause us a lot of pain down the line. cheers, Gunnar > On 23 Apr 2015, at 12:03, Allan Sandfeld Jensen wrote: > > On Thursday 23 April 2015, Alberto Mardegan wrote: >> On 04/23/2015 04:53 AM, Konstantin Ritt wrote: >>> We already have a complete solution - >>> https://codereview.qt-project.org/110685 >> >> That looks good. >> >>> All we need now is to fix the behavioral regression introduced in 5.4. >> >> But if I understand the code correctly, the fix above gives developers >> an option to opt *out* of the automatic rotation, so it will still >> behave differently than Qt < 5.4, unless the developer updates his app >> to use the new API. >> >> Which to me is all very good, but I think it's not what you have been >> suggesting in this thread. >> > It has gone through several iterations, and this is where it is currently at. > If there is a consensus to change the defaults the patch can easily be amended > again. > > Right now I don't see a consensus though, and personally lean both ways. > > `Allan > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mardy at users.sourceforge.net Thu Apr 23 13:20:33 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 23 Apr 2015 14:20:33 +0300 Subject: [Development] Rotating JPEG images by default In-Reply-To: <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> <201504231203.14249.kde@carewolf.com> <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> Message-ID: <5538D581.2010407@users.sourceforge.net> On 04/23/2015 01:36 PM, Gunnar Sletta wrote: > I think we should strive to not introduce regressions on purpose. Hence: > - Revert the behavioral change in 5.4 which adds rotation to JPEGs > - Have opt-in rotation in QImageReader. > - Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6) > > Anything else will cause us a lot of pain down the line. Also the above causes some pain. Whether we go for opt-in or opt-out of the automatic rotation, please have a static method to globally specify whether automatic rotation is desired or not. We should have QML Image show the JPEGs with the correct rotation without requiring special flags or custom image readers. Ciao, Alberto From gunnar at sletta.org Thu Apr 23 13:34:46 2015 From: gunnar at sletta.org (Gunnar Sletta) Date: Thu, 23 Apr 2015 13:34:46 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5538D581.2010407@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> <201504231203.14249.kde@carewolf.com> <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> <5538D581.2010407@users.sourceforge.net> Message-ID: > On 23 Apr 2015, at 13:20, Alberto Mardegan wrote: > > On 04/23/2015 01:36 PM, Gunnar Sletta wrote: >> I think we should strive to not introduce regressions on purpose. Hence: >> - Revert the behavioral change in 5.4 which adds rotation to JPEGs >> - Have opt-in rotation in QImageReader. >> - Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6) >> >> Anything else will cause us a lot of pain down the line. > > Also the above causes some pain. Whether we go for opt-in or opt-out of > the automatic rotation, please have a static method to globally specify > whether automatic rotation is desired or not. I don’t think static options like that are a very good idea. It is not hard to enable an option in your image reading code after all. And it will be in the part of the code where people normally look for image stuff. If we put it in QGuiApplication, nobody would know to look for it there. > We should have QML Image show the JPEGs with the correct rotation > without requiring special flags or custom image readers. Whether or not Image {} sets the rotation mode is a separate feature, but following the same logic. Image should NOT rotate by default. Image::respectFileOrientation or whatever as an opt-in would be perfectly fine. Again, we can talk about changing that default for Qt 6, but not in the 5 timeframe, IMO. > > Ciao, > Alberto > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From andre at familiesomers.nl Thu Apr 23 13:34:43 2015 From: andre at familiesomers.nl (=?windows-1252?Q?Andr=E9_Somers?=) Date: Thu, 23 Apr 2015 13:34:43 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5538D581.2010407@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> <201504231203.14249.kde@carewolf.com> <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> <5538D581.2010407@users.sourceforge.net> Message-ID: <5538D8D3.3000808@familiesomers.nl> Alberto Mardegan schreef op 23-4-2015 om 13:20: > On 04/23/2015 01:36 PM, Gunnar Sletta wrote: >> I think we should strive to not introduce regressions on purpose. Hence: >> - Revert the behavioral change in 5.4 which adds rotation to JPEGs >> - Have opt-in rotation in QImageReader. >> - Keep TIFF rotation as it is (and change it to the Qt-wide default for Qt 6) >> >> Anything else will cause us a lot of pain down the line. > Also the above causes some pain. Whether we go for opt-in or opt-out of > the automatic rotation, please have a static method to globally specify > whether automatic rotation is desired or not. > > We should have QML Image show the JPEGs with the correct rotation > without requiring special flags or custom image readers. > What is the problem with using Image { source: "someImage.jpg" autorotate: true } Again: note that QImage != QML Image I don't like globals if they can be avoided. In this case, I think they can. André From mardy at users.sourceforge.net Thu Apr 23 14:04:10 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Thu, 23 Apr 2015 15:04:10 +0300 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5538D8D3.3000808@familiesomers.nl> References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> <201504231203.14249.kde@carewolf.com> <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> <5538D581.2010407@users.sourceforge.net> <5538D8D3.3000808@familiesomers.nl> Message-ID: <5538DFBA.9010209@users.sourceforge.net> On 04/23/2015 02:34 PM, André Somers wrote: > What is the problem with using > > Image { > source: "someImage.jpg" > autorotate: true > } > > Again: note that QImage != QML Image > > I don't like globals if they can be avoided. In this case, I think they can. I could certainly live with that, but if you renamed "autorotate" to "showWithCorrectRotation" you'd have to agree that it's a rather silly flag. Of course I want my images to appear with the correct rotation. :-) I do agree that for QImage leaving the autorotation off can make sense in some cases. But for QML Image, I cannot think of a single case where I wouldn't want a JPEG to be automatically rotated. Ciao, Alberto From ritt.ks at gmail.com Thu Apr 23 14:12:13 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 23 Apr 2015 16:12:13 +0400 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5538DFBA.9010209@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> <201504231203.14249.kde@carewolf.com> <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> <5538D581.2010407@users.sourceforge.net> <5538D8D3.3000808@familiesomers.nl> <5538DFBA.9010209@users.sourceforge.net> Message-ID: 2015-04-23 16:04 GMT+04:00 Alberto Mardegan : > On 04/23/2015 02:34 PM, André Somers wrote: > > What is the problem with using > > > > Image { > > source: "someImage.jpg" > > autorotate: true > > } > > > > Again: note that QImage != QML Image > > > > I don't like globals if they can be avoided. In this case, I think they > can. > > I could certainly live with that, but if you renamed "autorotate" to > "showWithCorrectRotation" you'd have to agree that it's a rather silly > flag. Of course I want my images to appear with the correct rotation. :-) > > I do agree that for QImage leaving the autorotation off can make sense > in some cases. But for QML Image, I cannot think of a single case where > I wouldn't want a JPEG to be automatically rotated. > The behavior must be consistent for both. I cannot think of a single case where you would want text direction to be automatically applied in QML but not in QTextDocument (not an ideal example, but still). Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Apr 23 14:30:21 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 23 Apr 2015 14:30:21 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: References: <1428661428222.50531@theqtcompany.com> <1852105.q4fxhfIq6n@patux> Message-ID: <2327552.Ad5dJsB4Qj@portia.local> On Thursday April 23 2015 11:13:41 Peter Kuemmel wrote: > René, maybe this helps you a bit: > > https://codereview.qt-project.org/#/c/111056/ > > It's only a incomplete copy and paste of your Qt 4 patch, > but it could show you the direction. Hi Peter, Thanks! Why an incomplete copy/paste? I see it's missing the changes to tools/qtconfig/mainwindow.cpp, did you omit other changes as well? R. From ritt.ks at gmail.com Thu Apr 23 14:33:40 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 23 Apr 2015 16:33:40 +0400 Subject: [Development] Rotating JPEG images by default In-Reply-To: References: <5530B1F3.4080501@theqtcompany.com> <5538A688.1000202@users.sourceforge.net> <201504231203.14249.kde@carewolf.com> <6C72667A-C385-4DCE-B2AE-CCAAB7AA5CEC@sletta.org> <5538D581.2010407@users.sourceforge.net> <5538D8D3.3000808@familiesomers.nl> <5538DFBA.9010209@users.sourceforge.net> Message-ID: Just FYI, http://www.daveperrett.com/articles/2012/07/28/exif-orientation-handling-is-a-ghetto/ http://webmasters.stackexchange.com/questions/16684/ipad-and-iphone-browser-rotating-images-on-site (note that OS from Apple is a bit "special") and the CSS3 working group discussion: http://lists.w3.org/Archives/Public/www-style/2011Dec/0001.html Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From kde at carewolf.com Thu Apr 23 14:46:52 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 23 Apr 2015 14:46:52 +0200 Subject: [Development] Rotating JPEG images by default In-Reply-To: <5538DFBA.9010209@users.sourceforge.net> References: <5530B1F3.4080501@theqtcompany.com> <5538D8D3.3000808@familiesomers.nl> <5538DFBA.9010209@users.sourceforge.net> Message-ID: <201504231446.52790.kde@carewolf.com> On Thursday 23 April 2015, Alberto Mardegan wrote: > On 04/23/2015 02:34 PM, André Somers wrote: > > What is the problem with using > > > > Image { > > > > source: "someImage.jpg" > > autorotate: true > > > > } > > > > Again: note that QImage != QML Image > > > > I don't like globals if they can be avoided. In this case, I think they > > can. > > I could certainly live with that, but if you renamed "autorotate" to > "showWithCorrectRotation" you'd have to agree that it's a rather silly > flag. Of course I want my images to appear with the correct rotation. :-) > > I do agree that for QImage leaving the autorotation off can make sense > in some cases. But for QML Image, I cannot think of a single case where > I wouldn't want a JPEG to be automatically rotated. > Well, it could be separated between QImage and QPixmap, and QML images following QPixmap. With the logic being that images are for pixel handling and pixmaps for showing. It could cause all kinds of confusion though. `Allan From announce at qt-project.org Thu Apr 23 15:33:34 2015 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 23 Apr 2015 13:33:34 +0000 Subject: [Development] [Announce] Qt Creator 3.4.0 released Message-ID: <94159457-AC52-4415-815B-D41F3E50B3D3@digia.com> We are happy to announce the release of Qt Creator 3.4.0: https://blog.qt.io/blog/2015/04/23/qt-creator-3-4-0-released/ Best regards from the Qt Creator team -- Eike Ziller, Senior Software Engineer | The Qt Company Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Announce mailing list Announce at qt-project.org http://lists.qt-project.org/mailman/listinfo/announce From theonlylawislove at gmail.com Thu Apr 23 15:38:15 2015 From: theonlylawislove at gmail.com (Paul Knopf) Date: Thu, 23 Apr 2015 09:38:15 -0400 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. In-Reply-To: <5534C0E9.20201@kdab.com> References: <5534C0E9.20201@kdab.com> Message-ID: Sean, I took a look at the example, and this all looks good. However, I think my platform will still grab a handle to the framebuffer. I will be using an i.MX6 device, and the configuration would use the following EGLFS hook. https://github.com/qtproject/qtbase/blob/befe1e37e28db95a79622d628a338feaa8eee77b/src/plugins/platforms/eglfs/deviceintegration/eglfs_viv/qeglfsvivintegration.cpp QEglFSVivIntegration::platformInit(), it looks it still opens the framebuffer, even if we plan on doing only off-screen rendering. The problem is that, I need to open/close/manage the linux framebuffer myself, which is the whole point of doing offscreen rendering. Maybe I can create a custom EGLFS hook, based off of viv, but return a dummy size, and do no initialization. If I am doing strictly off-screen rendering, can I be sure that "QEglFSVivIntegration::platformDisplay()", "QEglFSVivIntegration::createNativeWindow()", and "QEglFSVivIntegration::destroyNativeWindow()" will never be called? On Mon, Apr 20, 2015 at 5:03 AM, Sean Harmer wrote: > On 20/04/2015 08:25, Paul Knopf wrote: > > Thanks a lot! This worked. I now have a valid alpha component that I can > send to my hard vendors API for FPGA video overlay. > > With this said, I would REALLY like to support OpenGL (for Qt Quick > 2/qml). Here is an image of what I am > trying to essentially do. What are your thoughts implementing this in Qt? > > Here is what I need my monitor output to be. > > The original buffer: size w / h : [R G B A][R G B > A][R G B A][...] > The output i want: size (w*.25) / (h*.25): [R G B][A R G][B A R][G B > A][...] > > My thoughts are to Render OpenGL off screen (not using framebuffer), > then have a thread that periodically captures the output (RGBA) and sends > it my linux framebuffer. My output doesn't need high FPS. I understand that > sending the extra alpha will increase the size of my resolution by 25%.. > The FPGA component/board will identify itself as having a resolution of > 1350 (1080 * .25) so that it can internally translate to 1080 with an alpha > channel. Does the EGLFS support off-screen rendering? Maybe then, I could > create 1080 opengl context off-screen, and then output it, including alpha, > to the 1350 framebuffer. > > > OpenGL supports offscreen rendering as long as the QPA supports OpenGL. > > * Create a QOffscreenSurface > * Create a QOpenGLContext > * Create a suitable Framebuffer Object with a colour texture attachment > and most likely a depth and stencil attachment. > * Bind the FBO as the GL_BUFFER (both read and write binding points) > * Draw stuff > * Read back the texture attached to the FBO as needed > > If you are wanting to use this approach to render Qt Quick 2 content, then > take a look at the QQuickRenderControl class and accompanying example that > ships with Qt. > > Cheers, > > Sean > > -- > Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK > 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 > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From syntheticpp at gmx.net Thu Apr 23 16:58:05 2015 From: syntheticpp at gmx.net (Peter Kuemmel) Date: Thu, 23 Apr 2015 16:58:05 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <2327552.Ad5dJsB4Qj@portia.local> References: <1428661428222.50531@theqtcompany.com> <1852105.q4fxhfIq6n@patux> , <2327552.Ad5dJsB4Qj@portia.local> Message-ID: > > Hi Peter, > > Thanks! > > Why an incomplete copy/paste? I see it's missing the changes to tools/qtconfig/mainwindow.cpp, did you omit other changes as well? Because the gerrit code is Qt5 not Qt4. So it needs a complete review and test by you if it works on Mac, I don't have a Mac. Peter > > R. > From laszlo.agocs at theqtcompany.com Thu Apr 23 17:04:20 2015 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Thu, 23 Apr 2015 15:04:20 +0000 Subject: [Development] Qt 'minimal' platform no rendering alpha/opacity. In-Reply-To: References: <5534C0E9.20201@kdab.com>, Message-ID: <1429801474001.38731@theqtcompany.com> It won't write anything to the framebuffer though. As long as you do not create an actual window (only use QOffscreenSurface, not QWindow) and do not call swapBuffers() there will be nothing written out. How and when the EGL implementation opens the framebuffer is not under Qt's or the application's control. Best regards, Laszlo ________________________________ From: development-bounces+laszlo.agocs=theqtcompany.com at qt-project.org on behalf of Paul Knopf Sent: Thursday, April 23, 2015 3:38 PM To: Sean Harmer Cc: development at qt-project.org Subject: Re: [Development] Qt 'minimal' platform no rendering alpha/opacity. Sean, I took a look at the example, and this all looks good. However, I think my platform will still grab a handle to the framebuffer. I will be using an i.MX6 device, and the configuration would use the following EGLFS hook. https://github.com/qtproject/qtbase/blob/befe1e37e28db95a79622d628a338feaa8eee77b/src/plugins/platforms/eglfs/deviceintegration/eglfs_viv/qeglfsvivintegration.cpp QEglFSVivIntegration::platformInit(), it looks it still opens the framebuffer, even if we plan on doing only off-screen rendering. The problem is that, I need to open/close/manage the linux framebuffer myself, which is the whole point of doing offscreen rendering. Maybe I can create a custom EGLFS hook, based off of viv, but return a dummy size, and do no initialization. If I am doing strictly off-screen rendering, can I be sure that "QEglFSVivIntegration::platformDisplay()", "QEglFSVivIntegration::createNativeWindow()", and "QEglFSVivIntegration::destroyNativeWindow()" will never be called? On Mon, Apr 20, 2015 at 5:03 AM, Sean Harmer > wrote: On 20/04/2015 08:25, Paul Knopf wrote: Thanks a lot! This worked. I now have a valid alpha component that I can send to my hard vendors API for FPGA video overlay. With this said, I would REALLY like to support OpenGL (for Qt Quick 2/qml). Here is an image of what I am trying to essentially do. What are your thoughts implementing this in Qt? Here is what I need my monitor output to be. The original buffer: size w / h : [R G B A][R G B A][R G B A][...] The output i want: size (w*.25) / (h*.25): [R G B][A R G][B A R][G B A][...] My thoughts are to Render OpenGL off screen (not using framebuffer), then have a thread that periodically captures the output (RGBA) and sends it my linux framebuffer. My output doesn't need high FPS. I understand that sending the extra alpha will increase the size of my resolution by 25%.. The FPGA component/board will identify itself as having a resolution of 1350 (1080 * .25) so that it can internally translate to 1080 with an alpha channel. Does the EGLFS support off-screen rendering? Maybe then, I could create 1080 opengl context off-screen, and then output it, including alpha, to the 1350 framebuffer. OpenGL supports offscreen rendering as long as the QPA supports OpenGL. * Create a QOffscreenSurface * Create a QOpenGLContext * Create a suitable Framebuffer Object with a colour texture attachment and most likely a depth and stencil attachment. * Bind the FBO as the GL_BUFFER (both read and write binding points) * Draw stuff * Read back the texture attached to the FBO as needed If you are wanting to use this approach to render Qt Quick 2 content, then take a look at the QQuickRenderControl class and accompanying example that ships with Qt. Cheers, Sean -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK 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 _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Thanks! ~Paul -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Thu Apr 23 20:31:35 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Thu, 23 Apr 2015 20:31:35 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: References: <1428661428222.50531@theqtcompany.com> <2327552.Ad5dJsB4Qj@portia.local> Message-ID: <21031526.1YY4iU2sp1@patux> On Thursday April 23 2015 16:58:05 Peter Kuemmel wrote: >Because the gerrit code is Qt5 not Qt4. Doh ... I wondered about that and should have realised it was the case seeing the dialoghelper file on the list. >So it needs a complete review and test by you if it works on Mac, Actually, I am still working on a Qt 5 version. Porting the OS X specific changes of the Qt 4 patch was relatively straightforward, but the Linux code needs some attention as well. That's a bit problematic because I don't currently have a Linux rig powerful enough to build Qt, but also I can't find the x11/xcb/freetype equivalent to qcocoafontdialoghelper.mm ... Anyway, the current patch for Qt 5 (5.4.1) is here: https://github.com/RJVB/mp-port-repository/blob/master/aqua/qt5-mac-devel/files/patch-improve-fontweight-support.diff I looked at the gerrit comments, and one made me wonder: is Qt no longer the product of a European company? I'm pretty sure trolls are a EU species, who if they could write without errors would use an EU language and spelling ;) R. From syntheticpp at gmx.net Thu Apr 23 23:59:54 2015 From: syntheticpp at gmx.net (=?windows-1252?Q?Peter_K=FCmmel?=) Date: Thu, 23 Apr 2015 23:59:54 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <21031526.1YY4iU2sp1@patux> References: <1428661428222.50531@theqtcompany.com> <2327552.Ad5dJsB4Qj@portia.local> <21031526.1YY4iU2sp1@patux> Message-ID: <55396B5A.6060704@gmx.net> On 23.04.2015 20:31, René J.V. Bertin wrote: > On Thursday April 23 2015 16:58:05 Peter Kuemmel wrote: > >> Because the gerrit code is Qt5 not Qt4. > > Doh ... I wondered about that and should have realised it was the case seeing the dialoghelper file on the list. > >> So it needs a complete review and test by you if it works on Mac, > > Actually, I am still working on a Qt 5 version. Porting the OS X specific changes of the Qt 4 patch was relatively straightforward, but the Linux code needs some attention as well. That's a bit problematic because I don't currently have a Linux rig powerful enough to build Qt, but also I can't find the x11/xcb/freetype equivalent to qcocoafontdialoghelper.mm ... > Anyway, the current patch for Qt 5 (5.4.1) is here: https://github.com/RJVB/mp-port-repository/blob/master/aqua/qt5-mac-devel/files/patch-improve-fontweight-support.diff I would start only with the Mac changes, and if they get accepted, you/one could change the other systems (where the folk is not that sensitive on font stuff ;) ) > > > I looked at the gerrit comments, and one made me wonder: is Qt no longer the product of a European company? I'm pretty sure trolls are a EU species, who if they could write without errors would use an EU language and spelling ;) > > R. > From syntheticpp at gmx.net Fri Apr 24 00:05:01 2015 From: syntheticpp at gmx.net (=?windows-1252?Q?Peter_K=FCmmel?=) Date: Fri, 24 Apr 2015 00:05:01 +0200 Subject: [Development] HEADS-UP: Qt 5.4.2 release coming In-Reply-To: <2327552.Ad5dJsB4Qj@portia.local> References: <1428661428222.50531@theqtcompany.com> <1852105.q4fxhfIq6n@patux> <2327552.Ad5dJsB4Qj@portia.local> Message-ID: <55396C8D.2050506@gmx.net> On 23.04.2015 14:30, René J.V. Bertin wrote: > On Thursday April 23 2015 11:13:41 Peter Kuemmel wrote: >> René, maybe this helps you a bit: >> >> https://codereview.qt-project.org/#/c/111056/ >> >> It's only a incomplete copy and paste of your Qt 4 patch, >> but it could show you the direction. > > Hi Peter, > > Thanks! > > Why an incomplete copy/paste? I see it's missing the changes to tools/qtconfig/mainwindow.cpp, did you omit other changes as well? Wasn't qtconfig removed from Qt5? > > R. > From ritt.ks at gmail.com Fri Apr 24 01:51:48 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Fri, 24 Apr 2015 03:51:48 +0400 Subject: [Development] font selection and weight/style support on OS X: (possible regression from Qt 4 to Qt 5 In-Reply-To: <15210738.zbxxOWR6gp@patux> References: <15210738.zbxxOWR6gp@patux> Message-ID: In case you're on Qt 4.x, look at QFont <-> QString and QFont <-> QDataStream (|de)serialization. I recall there was a bug fixed in ~5.3, though I don't know if it was backported to 4.x. Konstantin 2015-04-18 14:34 GMT+04:00 René J.V. : > Hello, > > The specific question: how/where is (QFontEngine *)fe->ctfont set that is > read in QFontDialogPrivate::setFont (qfontdialog_mac.mm around line 514)? > > I have been looking into an issue with the selection of fonts in > weights/styles that don't follow the usual four suspects (Normal, Italic, > Bold, Bold-Italic). > In stock Qt 4.8, selecting a Medium or Semi Bold weight (i.e. a weight > between normal and bold) works during the initial selection (say in > qtconfig's default font selection), but open the font dialog once more, or > relaunch the application, and that medium weight will have been replaced by > standard bold. > > I think I have a fix for this in Qt 4.8, which removes the "easy shortcut" > I found in 2 places ("there's Normal and anything heavier which becomes > Bold") and extends the weight string parser to support most of the font > weights you'll find on a typical OS X install. > > It turns out that almost inevitably I came up with code that looks a lot > like what had already been done for Qt 5.4 (I swear, I didn't peak :)) > except that I didn't introduce additional const variables to complement the > existing QFont::DemiBold etc. styles. > > We're getting to the question. > When opening the font dialog with an initial font, Qt 4 calls > QFontDialogPrivate::setFont() where Qt 5.4 uses > QCocoaFontPanel::setCurrentFont() . Both functions (can) use [NSFontManager > fontWithFamily:traits:weight:size], but the Qt4 version is actually called > with fe->ctfont already set to the appropriate NSFont*. > > And that seems to work more reliably. I have several fonts on my system > (including the Apple-provided Avenir family) where > fontWithFamily:traits:weight:size does *not* return the requested typeface, > as if the weight parameter is ignored. And indeed the documentation for > that function suggests that the weight parameter is used as a hint only ( > https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSFontManager_Class/index.html#//apple_ref/occ/instm/NSFontManager/fontWithFamily:traits:weight:size:) > though I *hope* that it's used as more than a hint when the requested > weight actually exists. > > Hence my question: where is fe->ctfont initialised? Clearly this uses a > different method for obtaining the NSFont (or CFFontRef). > > Note that I've already tried to put all chances on my side for weight: to > be used as more than a hint. I've analysed the weights in question for all > fonts on my system (Apple's documentation doesn't bother to document the > exact value mapping), and came up with the following > > + // RJVB > + // Thin,Light -> 3, Book -> 4 > + // Normal/Regular -> 5 > + // Medium/SemiBold/Demibold -> 6,7,8 > + // Bold -> 9 > + // Ultra/Black/Heavy -> 10,11 > + QByteArray *weights = NULL; > + switch (font.weight()) { > + case QFont::Light: > + weights = new QByteArray((const char[]){3,4}); > + break; > + case QFont::Normal: > + weights = new QByteArray((const char[]){5}); > + break; > + case QFont::DemiBold: > + weights = new QByteArray((const char[]){6,7,8}); > + break; > + case QFont::Bold: > + weights = new QByteArray((const char[]){9}); > + break; > + case QFont::Black: > + weights = new QByteArray((const char[]){10,11}); > + break; > } > > (evidently I did the same for Apple's other scale, that goes from -1.0 to > 1.0). I then test each of the weights corresponding to font.weight(): > > + if (weights) { > + nsFont = NULL; > + for (int i = 0 ; i < weights->size() && !nsFont ; ++i) { > + weight = (int) (*weights)[i]; > + nsFont = [mgr > fontWithFamily:qt_mac_QStringToNSString(fontInfo.family()) > + traits:mask > + weight:weight > + size:fontInfo.pointSize()]; > + } > + delete weights; > + } > > the only thing I haven't yet added is an additional check whether > fontWithFamily did indeed return the requested weight, and not the closest > lower match (which would let DemiBold downgrade to Normal, or Ultra to > Bold). > > Thanks for bearing with me, and (even more :)) for any feedback! > > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From poizan at poizan.dk Fri Apr 24 05:51:54 2015 From: poizan at poizan.dk (Kasper F. Brandt) Date: Fri, 24 Apr 2015 05:51:54 +0200 Subject: [Development] Static build of QtWebKit with msvc2012? Message-ID: Is there any reason that static build of QtWebKit isn't enabled for msvc2012? I just tried adding win32-msvc2012 to Tools/qmake/mkspecs/features/configure.prf around line 129 and the build went fine. Is it simply a matter of it not being tested/not wanting to support it in the future? Should I open an issue and/or send a patch? - Kasper Brandt From kde at carewolf.com Fri Apr 24 11:22:10 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Fri, 24 Apr 2015 11:22:10 +0200 Subject: [Development] Static build of QtWebKit with msvc2012? In-Reply-To: References: Message-ID: <201504241122.11252.kde@carewolf.com> On Friday 24 April 2015, Kasper F. Brandt wrote: > Is there any reason that static build of QtWebKit isn't enabled for > msvc2012? I just tried adding win32-msvc2012 to > Tools/qmake/mkspecs/features/configure.prf around line 129 and the > build went fine. Is it simply a matter of it not being tested/not > wanting to support it in the future? > > Should I open an issue and/or send a patch? > It think it is a matter of no one having tried. Please do both. `Allan From marc.mutz at kdab.com Fri Apr 24 14:33:27 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 24 Apr 2015 14:33:27 +0200 Subject: [Development] QQuaternion issues with new 5.5 API Message-ID: <201504241433.27134.marc.mutz@kdab.com> Hi, While implementing qHash() overloads for gui/math3d classes, I found that QQuaternion gained several methods for 5.5 which I don't like: *EulerAngles(): They are missing a QEulerAngles class. Instead, they deal with (float, float, float) and QVector3D. One function even returns three floats as out- parameters. I think my (partial) work on QDate/Time has shown just how much compilers don't like out parameters. The question here is how general such a QEulerAngles class should be... *AxisAndAngle()/*Axes(): Same here, to a lesser extent. What bugs me most is the return-by-out- parameters, not so much that there's no QAxis3D class. There are several steps forward: - Create QEulerAngles as a float-only class - ditto, but as a template - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as template arguments, with explicit conversions between, then use that in QEulerAngles. [this likely won't happen for 5.5, though] - remove the methods in question for 5.5 and try again in 5.6 Any opinions about which ones to take? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Fri Apr 24 14:36:17 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 24 Apr 2015 14:36:17 +0200 Subject: [Development] QQuaternion issues with new 5.5 API In-Reply-To: <201504241433.27134.marc.mutz@kdab.com> References: <201504241433.27134.marc.mutz@kdab.com> Message-ID: <201504241436.17858.marc.mutz@kdab.com> On Friday 24 April 2015 14:33:27 Marc Mutz wrote: > There are several steps forward: > > - Create QEulerAngles as a float-only class > - ditto, but as a template > - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as > template arguments, with explicit conversions between, then use that in > QEulerAngles. [this likely won't happen for 5.5, though] > - remove the methods in question for 5.5 and try again in 5.6 > > Any opinions about which ones to take? Of course - do nothing is an option, too, but clearly not the one that I'd prefer :) -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From gunnar at sletta.org Fri Apr 24 14:32:22 2015 From: gunnar at sletta.org (Gunnar Sletta) Date: Fri, 24 Apr 2015 14:32:22 +0200 Subject: [Development] QQuaternion issues with new 5.5 API In-Reply-To: <201504241433.27134.marc.mutz@kdab.com> References: <201504241433.27134.marc.mutz@kdab.com> Message-ID: > On 24 Apr 2015, at 14:33, Marc Mutz wrote: > > Hi, > > While implementing qHash() overloads for gui/math3d classes, Why are we doing this? a QHash makes very little sense me.. - Gunnar > I found that > QQuaternion gained several methods for 5.5 which I don't like: > > *EulerAngles(): > > They are missing a QEulerAngles class. Instead, they deal with (float, float, > float) and QVector3D. One function even returns three floats as out- > parameters. I think my (partial) work on QDate/Time has shown just how much > compilers don't like out parameters. The question here is how general such a > QEulerAngles class should be... > > *AxisAndAngle()/*Axes(): > > Same here, to a lesser extent. What bugs me most is the return-by-out- > parameters, not so much that there's no QAxis3D class. > > There are several steps forward: > > - Create QEulerAngles as a float-only class > - ditto, but as a template > - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as template > arguments, with explicit conversions between, then use that in QEulerAngles. > [this likely won't happen for 5.5, though] > - remove the methods in question for 5.5 and try again in 5.6 > > Any opinions about which ones to take? > > Thanks, > Marc > > -- > Marc Mutz | Senior Software Engineer > KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company > Tel: +49-30-521325470 > KDAB - The Qt Experts > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From ritt.ks at gmail.com Fri Apr 24 17:04:43 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Fri, 24 Apr 2015 19:04:43 +0400 Subject: [Development] QQuaternion issues with new 5.5 API In-Reply-To: References: <201504241433.27134.marc.mutz@kdab.com> Message-ID: 2015-04-24 16:32 GMT+04:00 Gunnar Sletta : > > > On 24 Apr 2015, at 14:33, Marc Mutz wrote: > > > > Hi, > > > > While implementing qHash() overloads for gui/math3d classes, > > Why are we doing this? a QHash makes very little sense me.. > Completely agreed. Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Fri Apr 24 17:10:49 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Fri, 24 Apr 2015 19:10:49 +0400 Subject: [Development] QQuaternion issues with new 5.5 API In-Reply-To: <201504241433.27134.marc.mutz@kdab.com> References: <201504241433.27134.marc.mutz@kdab.com> Message-ID: 2015-04-24 16:33 GMT+04:00 Marc Mutz : > Hi, > > While implementing qHash() overloads for gui/math3d classes, I found that > QQuaternion gained several methods for 5.5 which I don't like: > > *EulerAngles(): > > They are missing a QEulerAngles class. Instead, they deal with (float, > float, > float) and QVector3D. One function even returns three floats as out- > parameters. I think my (partial) work on QDate/Time has shown just how much > compilers don't like out parameters. The question here is how general such > a > QEulerAngles class should be... > > *AxisAndAngle()/*Axes(): > > Same here, to a lesser extent. What bugs me most is the return-by-out- > parameters, not so much that there's no QAxis3D class. > > There are several steps forward: > > - Create QEulerAngles as a float-only class > - ditto, but as a template > - ditto, but also add Q*Angle classes that have DEG/RAD hard-coded as > template > arguments, with explicit conversions between, then use that in > QEulerAngles. > [this likely won't happen for 5.5, though] > - remove the methods in question for 5.5 and try again in 5.6 > > Any opinions about which ones to take? > Sure I wanted to do it via introducing QAngle (which is also useful for many other classes, even outside math3d), but that's definitely a 6.0 material; and then there is no much sense in introducing it just for QQuaternion. Konstantin -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Apr 24 17:53:00 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 24 Apr 2015 08:53 -0700 Subject: [Development] QQuaternion issues with new 5.5 API In-Reply-To: References: <201504241433.27134.marc.mutz@kdab.com> Message-ID: <1569996.W1DWu4HQcf@tjmaciei-mobl4> On Friday 24 April 2015 14:32:22 Gunnar Sletta wrote: > > While implementing qHash() overloads for gui/math3d classes, > > Why are we doing this? a QHash makes very little sense me.. That's besides the point. Marc could have said "I've just noticed" and the rest of his arguments would still be valid. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Fri Apr 24 21:51:31 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Fri, 24 Apr 2015 21:51:31 +0200 Subject: [Development] QQuaternion issues with new 5.5 API In-Reply-To: References: <201504241433.27134.marc.mutz@kdab.com> Message-ID: <201504242151.31254.marc.mutz@kdab.com> On Friday 24 April 2015 14:32:22 Gunnar Sletta wrote: > > While implementing qHash() overloads for gui/math3d classes, > > Why are we doing this? a QHash makes very little sense me.. Well, there are are bug reports asking for qHash(QPoint), so it seems to make sense to _someone_ :) Esp. for types that don't have a natural total order (=most), and thus don't / shouldn't have operator<, adding a qHash() overload, as long as it can be done (it can't for QPointF) is the only way to enable associative containers of any kind for that type. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From rpzrpzrpz at gmail.com Sun Apr 26 17:14:37 2015 From: rpzrpzrpz at gmail.com (rpzrpzrpz at gmail.com) Date: Sun, 26 Apr 2015 09:14:37 -0600 Subject: [Development] Configure setting location for release Message-ID: <553D00DD.3040403@gmail.com> Hello: Does anybody know where I could find the configure settings used for building the released QT versions 5.4.x? I would like to see the IOS and Android settings. Thank you, md -- No spell checkers were harmed during the creation of this message. From psychon at znc.in Sun Apr 26 21:39:23 2015 From: psychon at znc.in (Uli Schlachter) Date: Sun, 26 Apr 2015 21:39:23 +0200 Subject: [Development] New (optional?) dependency: xcb-util-errors Message-ID: <553D3EEB.1080504@znc.in> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone, here are some 'recent' examples of error messages printed for X11 protocol errors: QXcbConnection::handleXcbError - QXcbConnection: XCB error: 170 (Unknown), sequence: 162, resource id: 90, major code: 146 (Unknown), minor code: 20 https://codereview.qt-project.org/#/c/108209/ (See my comment from Mar 14 8:52 AM) ~ > qtcreator -noload Welcome QXcbConnection: Failed to get the primary output of the screen Starting process: "/usr/bin/cmake" "--help" QXcbConnection: XCB error: 172 (Unknown), sequence: 158, resource id: 150, major code: 149 (Unknown), minor code: 20 https://bugreports.qt.io/browse/QTBUG-31389 (And lots of other comments in there) QXcbConnection: XCB error: 159 (Unknown), sequence: 156, resource id: 0, major code: 149 (Unknown), minor code: 20 https://codereview.qt-project.org/74133 These error messages are not really helpful. Here is a (bad[0]) example for a better error message: QXcbConnection: XCB error: 3 (Window), sequence: 7, resource id: 42, major code: 4 (DestroyWindow), minor code: 0 (Non-extension request / Unknown) The first of my three examples is what made me work on a library for figuring out more useful names than "Unknown" for these error messages. The result is xcb-util-errors: http://cgit.freedesktop.org/xcb/util-errors/ http://lists.freedesktop.org/archives/xcb/2015-April/010264.html Now I want to make Qt use this library for better error messages: https://codereview.qt-project.org/109873 The actual question that I want to ask with this mail: This is a new external dependency. Is it ok to add this dependency to Qt? I have some options to offer for this which only differ in their behavior when ./configure is called with -system-xcb (which is the default): (A) Handle this library like other xcb libraries: Require an installed copy with -system-xcb (the default) and use a bundled version with -qt-xcb. (B) Use an installed copy with -system-xcb if available, else use the bundled version. Always use the bundled version with -qt-xcb. (C) Use an installed copy with -system-xcb if available, else just print the numeric values without a human readable description. Use the bundled version with -qt-xcb. With (A) we have a new hard dependency which might be hard to satisfy for some people. For (B) I'm not sure about the source code structure that should be used. AFAIK the code in src/3rdparty/xcb is only used with -qt-xcb and ignored otherwise. Thus it would be inconsistent to put xcb-util-errors there. Note that (C) is worse than the current state where Qt at least contains some lookup tables for core (=not coming from some extension) X11 errors and events. What do you think and prefer? Does adding this dependency make sense at all? Cheers, Uli P.S.: Thanks to Shawn Rutledge und Alejandro Exojo for talking to me about this in #qt-labs. They came up with options (B) and (C). [0]: This is a bad example, because the current code would also generate such an error message for *this* example, since no X11 extensions are involved. However, this library works for all X11 protocol error and response numbers and also for all major and minor numbers (at least those for which a XCB XML protocol description is available, which only excludes some deprecated things). - -- - - Captain, I think I should tell you I've never actually landed a starship before. - - That's all right, Lieutenant, neither have I. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVPT7nAAoJECLkKOvLj8sGWZUH/RgszVRfZaMw881Tq2f2cYT7 zXkTWaW9ZtrgG0BU8iS/u7QT34jAnaUDMPyXwAqYIn5NCxgda59+kurGDMuQU+C7 zmjLK6i7zR1m73FAYeOKGssiXUa2HpDLVeUwFNnUs0pQMvzq2zBEJOzmy6B8jATQ 9Jk0VBPiaOK/RdHY6LpSTSjAJx5sOI/+shr0zqnZT2Xr2qrdUbH5W7oC6F+4U31Z p0NIH54OF2jrbFOYdw2bYcs9lcelAnpsd/aXhoxI0hpVlbVPbUVMq+fiQqmQL8nd ZGqd2f/W79wNB3ODuwGazRErVdfKvbyl/yBEPGMyXxXZ7pLTsRDtMh7R78veTBk= =jhHf -----END PGP SIGNATURE----- From thiago.macieira at intel.com Mon Apr 27 00:53:37 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 26 Apr 2015 15:53:37 -0700 Subject: [Development] New (optional?) dependency: xcb-util-errors In-Reply-To: <553D3EEB.1080504@znc.in> References: <553D3EEB.1080504@znc.in> Message-ID: <2950770.PdxY2EzEfK@tjmaciei-mobl4> On Sunday 26 April 2015 21:39:23 Uli Schlachter wrote: > The actual question that I want to ask with this mail: This is a new > external dependency. Is it ok to add this dependency to Qt? How common is that library? What distros often have it? How long have they had it? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From szehowe.koh at gmail.com Mon Apr 27 01:56:35 2015 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Mon, 27 Apr 2015 07:56:35 +0800 Subject: [Development] QJsonArray concatenation Message-ID: Hello, This is the cleanest way I can currently think of to concatenate 2 QJsonArrays: for (const auto& value : array2) array1 << value; Most of Qt's array-like containers (QVector, QList, QByteArray, QString) have concatenation functions, but QJsonArray doesn't. So, I propose adding the following overloads, to match the other containers: - QJsonArray::operator+(const QJsonArray&) - QJsonArray::operator+=(const QJsonArray&) - QJsonArray::operator<<(const QJsonArray&) The gotcha: This can cause a behaviour change. Currently, inputting QJsonArray into operator+=() makes valid code -- the QJsonArray is implicitly converted into a single QJsonValue first. My proposal would make the same code avoid the conversion and append each element individually instead. Is this acceptable for Qt 5.x? (I don't know how widely-used is the implicit conversion to QJsonValue) Note that there has been one other behaviour change that I know of: https://forum.qt.io/topic/50282/ QJsonArray array1; // ... QJsonArray array2{array1}; In Qt 5.3, array2 is a copy of array1. However, Qt 5.4 introduced the initializer list-based constructor. This constructor implicitly converts array1 into a single QJsonValue, so array2 contains one element only. Ideally, this change would not have happened (and ideally, my proposed overloads would have been added back in Qt 5.3, when the single-element versions were added). So, we can now choose between maintaining SC, or having a more functional API that's more consistent with other containers. Which is the correct choice? Regards, Sze-Howe -------------- next part -------------- An HTML attachment was scrubbed... URL: From bacarozzo at gmail.com Mon Apr 27 11:15:40 2015 From: bacarozzo at gmail.com (Federico Buti) Date: Mon, 27 Apr 2015 11:15:40 +0200 Subject: [Development] Sound routing Message-ID: Hi list(s), I'm in the early development stage of a mobile app and I'm currently trying to figure out which native API are mapped to Qt and which are not. Writing native code is not a problem but I would avoid wasting time for reinventing the wheel. :) Among the other things I'm concerned with the following points: 1) Is there an API to directly call GPS navigation? Something like the "openUrlExternally" that works for phone dialling. Is it available or should I make a native call? 2) The app requires a specific sound routing: if the earphones are plugged, sound should be hear only on them. If earphones are not available, sound should be routed to the phone speaker (for smartphone devices). Such a routing is part of Qt Multimedia for iOS/Android? 3) It seems to me that network information, like the SSID, are still not reliable on Android (don't know about iOS). To collect them I need again to rely on native calls? Thanks in advance to anyone, F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Shawn.Rutledge at theqtcompany.com Mon Apr 27 11:15:58 2015 From: Shawn.Rutledge at theqtcompany.com (Rutledge Shawn) Date: Mon, 27 Apr 2015 09:15:58 +0000 Subject: [Development] New (optional?) dependency: xcb-util-errors In-Reply-To: <2950770.PdxY2EzEfK@tjmaciei-mobl4> References: <553D3EEB.1080504@znc.in> <2950770.PdxY2EzEfK@tjmaciei-mobl4> Message-ID: <6BD03C5B-9A5D-4DBB-A741-D767B35FB235@digia.com> On 27 Apr 2015, at 00:53, Thiago Macieira wrote: > On Sunday 26 April 2015 21:39:23 Uli Schlachter wrote: >> The actual question that I want to ask with this mail: This is a new >> external dependency. Is it ok to add this dependency to Qt? > > How common is that library? What distros often have it? How long have they had > it? It’s a completely new library, so nobody has it yet. But the patch includes a copy of the lib in 3rdparty. But if it had already existed, we’d modify configure to try to use the system library by default, whereas if you pass -qt-xcb to configure, then it would use the 3rdparty copy, right? So should we do that now, with the expectation that it will eventually start showing up on some distros, or should we try to always use the 3rdparty copy for now? From Jorgen.Lind at theqtcompany.com Mon Apr 27 13:46:05 2015 From: Jorgen.Lind at theqtcompany.com (Lind Jorgen) Date: Mon, 27 Apr 2015 11:46:05 +0000 Subject: [Development] New (optional?) dependency: xcb-util-errors In-Reply-To: <553D3EEB.1080504@znc.in> References: <553D3EEB.1080504@znc.in> Message-ID: <1430135166562.46966@theqtcompany.com> Its a small library, so I think it is sensible to compile it in the plugin (even with the error data). I don't think it makes much sense at current time to check if there is a system version available and then use that. However, what is bothering me is that this is code that we don't want to be relevant for 99.99% of people. We already use plugins in plugins in the xcb backend. We could lazily load this on the first error? Br, Jørgen ________________________________________ From: development-bounces+jorgen.lind=theqtcompany.com at qt-project.org on behalf of Uli Schlachter Sent: 26 April 2015 21:39 To: development at qt-project.org Subject: [Development] New (optional?) dependency: xcb-util-errors -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi everyone, here are some 'recent' examples of error messages printed for X11 protocol errors: QXcbConnection::handleXcbError - QXcbConnection: XCB error: 170 (Unknown), sequence: 162, resource id: 90, major code: 146 (Unknown), minor code: 20 https://codereview.qt-project.org/#/c/108209/ (See my comment from Mar 14 8:52 AM) ~ > qtcreator -noload Welcome QXcbConnection: Failed to get the primary output of the screen Starting process: "/usr/bin/cmake" "--help" QXcbConnection: XCB error: 172 (Unknown), sequence: 158, resource id: 150, major code: 149 (Unknown), minor code: 20 https://bugreports.qt.io/browse/QTBUG-31389 (And lots of other comments in there) QXcbConnection: XCB error: 159 (Unknown), sequence: 156, resource id: 0, major code: 149 (Unknown), minor code: 20 https://codereview.qt-project.org/74133 These error messages are not really helpful. Here is a (bad[0]) example for a better error message: QXcbConnection: XCB error: 3 (Window), sequence: 7, resource id: 42, major code: 4 (DestroyWindow), minor code: 0 (Non-extension request / Unknown) The first of my three examples is what made me work on a library for figuring out more useful names than "Unknown" for these error messages. The result is xcb-util-errors: http://cgit.freedesktop.org/xcb/util-errors/ http://lists.freedesktop.org/archives/xcb/2015-April/010264.html Now I want to make Qt use this library for better error messages: https://codereview.qt-project.org/109873 The actual question that I want to ask with this mail: This is a new external dependency. Is it ok to add this dependency to Qt? I have some options to offer for this which only differ in their behavior when ./configure is called with -system-xcb (which is the default): (A) Handle this library like other xcb libraries: Require an installed copy with -system-xcb (the default) and use a bundled version with -qt-xcb. (B) Use an installed copy with -system-xcb if available, else use the bundled version. Always use the bundled version with -qt-xcb. (C) Use an installed copy with -system-xcb if available, else just print the numeric values without a human readable description. Use the bundled version with -qt-xcb. With (A) we have a new hard dependency which might be hard to satisfy for some people. For (B) I'm not sure about the source code structure that should be used. AFAIK the code in src/3rdparty/xcb is only used with -qt-xcb and ignored otherwise. Thus it would be inconsistent to put xcb-util-errors there. Note that (C) is worse than the current state where Qt at least contains some lookup tables for core (=not coming from some extension) X11 errors and events. What do you think and prefer? Does adding this dependency make sense at all? Cheers, Uli P.S.: Thanks to Shawn Rutledge und Alejandro Exojo for talking to me about this in #qt-labs. They came up with options (B) and (C). [0]: This is a bad example, because the current code would also generate such an error message for *this* example, since no X11 extensions are involved. However, this library works for all X11 protocol error and response numbers and also for all major and minor numbers (at least those for which a XCB XML protocol description is available, which only excludes some deprecated things). - -- - - Captain, I think I should tell you I've never actually landed a starship before. - - That's all right, Lieutenant, neither have I. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJVPT7nAAoJECLkKOvLj8sGWZUH/RgszVRfZaMw881Tq2f2cYT7 zXkTWaW9ZtrgG0BU8iS/u7QT34jAnaUDMPyXwAqYIn5NCxgda59+kurGDMuQU+C7 zmjLK6i7zR1m73FAYeOKGssiXUa2HpDLVeUwFNnUs0pQMvzq2zBEJOzmy6B8jATQ 9Jk0VBPiaOK/RdHY6LpSTSjAJx5sOI/+shr0zqnZT2Xr2qrdUbH5W7oC6F+4U31Z p0NIH54OF2jrbFOYdw2bYcs9lcelAnpsd/aXhoxI0hpVlbVPbUVMq+fiQqmQL8nd ZGqd2f/W79wNB3ODuwGazRErVdfKvbyl/yBEPGMyXxXZ7pLTsRDtMh7R78veTBk= =jhHf -----END PGP SIGNATURE----- _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From edward.sutton at subsite.com Mon Apr 27 14:58:23 2015 From: edward.sutton at subsite.com (Edward Sutton) Date: Mon, 27 Apr 2015 12:58:23 +0000 Subject: [Development] Configure setting location for release In-Reply-To: <553D00DD.3040403@gmail.com> References: <553D00DD.3040403@gmail.com> Message-ID: <00094A8C-0EEB-4F95-A048-947346D35B27@subsite.com> Are the configure settings used to build Qt releases version controlled or accessible by the public? I think knowing what the configure settings are would be useful? This is the configure that Qt tech support told me is used to build Android ( I am not sure if that meant release builds? ): -release -xplatform android-g++ -opengl es2 -android-arch armeabi-v7a -nomake tests -nomake examples -skip qtserialport -skip qtwebkit -skip qtwebkit- examples -skip qtx11extras -sysconfdir /etc/xdg -no-icu -openssl -Ed On Apr 26, 2015, at 10:14 AM, rpzrpzrpz at gmail.com wrote: Hello: Does anybody know where I could find the configure settings used for building the released QT versions 5.4.x? I would like to see the IOS and Android settings. Thank you, md -- No spell checkers were harmed during the creation of this message. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development This email and any files transmitted with it from The Charles Machine Works, Inc. are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify the sender. Our company accepts no liability for the contents of this email, or for the consequences of any actions taken on the basis of the information provided, unless that information is subsequently confirmed in writing. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Mon Apr 27 18:06:23 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Apr 2015 09:06:23 -0700 Subject: [Development] Configure setting location for release In-Reply-To: <00094A8C-0EEB-4F95-A048-947346D35B27@subsite.com> References: <553D00DD.3040403@gmail.com> <00094A8C-0EEB-4F95-A048-947346D35B27@subsite.com> Message-ID: <3481819.EfxB7RnTl1@tjmaciei-mobl4> On Monday 27 April 2015 12:58:23 Edward Sutton wrote: > Are the configure settings used to build Qt releases version controlled or > accessible by the public? I think knowing what the configure settings are > would be useful? They are. See http://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From psychon at znc.in Mon Apr 27 22:21:49 2015 From: psychon at znc.in (Uli Schlachter) Date: Mon, 27 Apr 2015 22:21:49 +0200 Subject: [Development] New (optional?) dependency: xcb-util-errors In-Reply-To: <1430135166562.46966@theqtcompany.com> References: <553D3EEB.1080504@znc.in> <1430135166562.46966@theqtcompany.com> Message-ID: <553E9A5D.1040409@znc.in> Hi, sorry, but which plugins in plugins are being used? I can't find anything like that. Also, as you mention it is a small library: $ size libxcb-errors.so text data bss dec hex filename 30900 2632 8 33540 8304 libxcb-errors.so $ size libQt5XcbQpa.so text data bss dec hex filename 1604315 36860 1792 1642967 1911d7 libQt5XcbQpa.so That's ~2% of Qt's Xcb Qpa text size and ~7% data size of its data size. The text size likely is due to this being both debug builds and thus doesn't really say much. The code itself is quite trivial. The dats size seems more relevant, but 24k of the data is rodata (but ~2k of it is in the .data.rel.ro section). That likely will only be loaded into system memory on first use. I'm not sure if the overhead of lazily loading it and having this as a separate file is really worth it. How m Most people also won't need the code from qxcbsessionmanager.cpp. ;-) Uli Am 27.04.2015 um 13:46 schrieb Lind Jorgen: > Its a small library, so I think it is sensible to compile it in the plugin (even with the error data). I don't think it makes much sense at current time to check if there is a system version available and then use that. However, what is bothering me is that this is code that we don't want to be relevant for 99.99% of people. We already use plugins in plugins in the xcb backend. We could lazily load this on the first error? > > Br, > Jørgen > > ________________________________________ > From: development-bounces+jorgen.lind=theqtcompany.com at qt-project.org on behalf of Uli Schlachter > Sent: 26 April 2015 21:39 > To: development at qt-project.org > Subject: [Development] New (optional?) dependency: xcb-util-errors > > Hi everyone, > > here are some 'recent' examples of error messages printed for X11 protocol errors: > > > QXcbConnection::handleXcbError - QXcbConnection: XCB error: 170 (Unknown), > sequence: 162, resource id: 90, major code: 146 (Unknown), minor code: 20 > > https://codereview.qt-project.org/#/c/108209/ > (See my comment from Mar 14 8:52 AM) > > > ~ > qtcreator -noload Welcome > QXcbConnection: Failed to get the primary output of the screen > Starting process: "/usr/bin/cmake" "--help" > QXcbConnection: XCB error: 172 (Unknown), sequence: 158, resource id: 150, > major code: 149 (Unknown), minor code: 20 > > https://bugreports.qt.io/browse/QTBUG-31389 > (And lots of other comments in there) > > > QXcbConnection: XCB error: 159 (Unknown), sequence: 156, resource id: 0, > major code: 149 (Unknown), minor code: 20 > > https://codereview.qt-project.org/74133 > > > These error messages are not really helpful. Here is a (bad[0]) example for a > better error message: > > QXcbConnection: XCB error: 3 (Window), sequence: 7, resource id: 42, major > code: 4 (DestroyWindow), minor code: 0 (Non-extension request / Unknown) > > > The first of my three examples is what made me work on a library for figuring > out more useful names than "Unknown" for these error messages. The result is > xcb-util-errors: > > http://cgit.freedesktop.org/xcb/util-errors/ > http://lists.freedesktop.org/archives/xcb/2015-April/010264.html > > Now I want to make Qt use this library for better error messages: > > https://codereview.qt-project.org/109873 > > The actual question that I want to ask with this mail: This is a new external > dependency. Is it ok to add this dependency to Qt? > > I have some options to offer for this which only differ in their behavior when > ./configure is called with -system-xcb (which is the default): > > (A) Handle this library like other xcb libraries: Require an installed copy > with -system-xcb (the default) and use a bundled version with -qt-xcb. > (B) Use an installed copy with -system-xcb if available, else use the bundled > version. Always use the bundled version with -qt-xcb. > (C) Use an installed copy with -system-xcb if available, else just print the > numeric values without a human readable description. Use the bundled version > with -qt-xcb. > > With (A) we have a new hard dependency which might be hard to satisfy for some > people. > > For (B) I'm not sure about the source code structure that should be used. > AFAIK the code in src/3rdparty/xcb is only used with -qt-xcb and ignored > otherwise. Thus it would be inconsistent to put xcb-util-errors there. > > Note that (C) is worse than the current state where Qt at least contains some > lookup tables for core (=not coming from some extension) X11 errors and events. > > What do you think and prefer? Does adding this dependency make sense at all? > > Cheers, > Uli > > P.S.: Thanks to Shawn Rutledge und Alejandro Exojo for talking to me about > this in #qt-labs. They came up with options (B) and (C). > > [0]: This is a bad example, because the current code would also generate such > an error message for *this* example, since no X11 extensions are involved. > However, this library works for all X11 protocol error and response numbers > and also for all major and minor numbers (at least those for which a XCB XML > protocol description is available, which only excludes some deprecated things). > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Bruce Schneier can read and understand Perl programs. From thiago.macieira at intel.com Tue Apr 28 02:02:41 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 27 Apr 2015 17:02:41 -0700 Subject: [Development] New (optional?) dependency: xcb-util-errors In-Reply-To: <553E9A5D.1040409@znc.in> References: <553D3EEB.1080504@znc.in> <1430135166562.46966@theqtcompany.com> <553E9A5D.1040409@znc.in> Message-ID: <3985920.aMX54qKYFF@tjmaciei-mobl4> On Monday 27 April 2015 22:21:49 Uli Schlachter wrote: > Hi, > > sorry, but which plugins in plugins are being used? I can't find anything > like that. > > Also, as you mention it is a small library: > > $ size libxcb-errors.so > text data bss dec hex filename > 30900 2632 8 33540 8304 libxcb-errors.so It's a C library in a Unix system. Just dlopen the library and make the calls you need. We'll have to convince Linux distributions to package it. If they don't, we won't print nicer error messages, that's all. No loss of real functionality. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From simon.hausmann at theqtcompany.com Tue Apr 28 10:52:32 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Tue, 28 Apr 2015 10:52:32 +0200 Subject: [Development] Modifying and accessing environment variables in Qt Message-ID: <3545858.P76U9uhIrU@rhea> Hi, Have you ever seen crashes in the CI system that ended up in getenv? For example in http://testresults.qt.io/ci/QtBase_5.4.2_Integration/build_00020/linux-g++_no-widgets_Ubuntu_12.04_x64/log.txt.gz There are many more of these kinds of crashes throughout our tests and whenever it happens we ignore the problem and just press the "stage" button again. Must be some instability or bad configuration on the CI machine, right? It turns out, it isn't. Lars and I got to the bottom of this earlier this week and the finding is a different one: In shockingly many places in Qt itself as well as in our unit tests we access environment variables and in some places we also change them. The problem is that access to the environment is an operation that is inherently unsafe from a threading perspective. There's a process global "environ" variable, getenv() returns a bare pointer and putenv/setenv modify that very environment. And there's no way around that, the C run-time is not safe. Let one thread call getenv() - which iterates through the environ array - and then let another thread call putenv/setenv to modify the same array. The result is a seemingly random crash - or as it turns out: Frequent crashes in our CI system when trying to get changes into Qt :) >From a practical perspective we are particularly vulnerable on Linux to this, because QThread itself calls getenv() each time we start up a thread - it's the can-we-use-glib-event-dispatcher-or-was-it-disabled check. Now we could try to change qthread_unix.cpp to not do that, but let's be honest: That's a drop in the ocean of places where we access (reading and writing!) the environment in Qt. Just grep for putenv/setenv/getenv in qtbase/src and be surprised. There are various options about what we can do with different degrees of "perfection", but ultimately it's all going to require a compromise. The option that we are favoring at the moment is two-fold: 1) Policy in Qt is to use the Qt wrappers for accessing the environment (qgetenv, etc.). 2) These functions we protect with a mutex. Yes, this isn't perfect, because we still include large quantities of code in src/3rdparty in Qt that has unprotected calls to getenv(). But then that hasn't stopped us from patching that code in the past. The concrete proposal of change is at https://codereview.qt-project.org/#/c/111158/ What do you think? I'd most appreciate a +2 or a concrete patch with an alternate solution. Simon From massimocallegari at yahoo.it Tue Apr 28 12:08:43 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Tue, 28 Apr 2015 10:08:43 +0000 (UTC) Subject: [Development] QQmlEngine and ObjectOwnership Message-ID: <1248095853.8655885.1430215723263.JavaMail.yahoo@mail.yahoo.com> Hi everyone, I want to share my experience with the garbage collection of registered classes through qmlRegisterType. I got crazy to understand why my application was randomly crashing and I hope this will help others in the future. Basically if you want to expose a C++ class in the QML world, you do something like: qmlRegisterType("com.myapp.classes", 1, 0, "MyClass"); Then you can use the class methods exposed with Q_PROPERTY in QML like this: MyClass.myProperty The thing is that when dealing with class pointers, the QML engine performs garbage collection of the exposed classes when it no longer needs them. If your classes are created in C++ (new MyClass()) at some point in the C++ code, you will find that the class has been destroyed by QML !! This causes a bunch of segFaults like there is no tomorrow. So, after getting crazy to discover this, I discovered also that there is a method of QQmlEngine to assign the ownership of a class: QQmlEngine::setObjectOwnership(myNewClass, QQmlEngine::CppOwnership); After adding this simple line after a "myNewClass = new MyClass()", everything started to working properly. Note that in my application, classes created in C++ exist as long as the application lives. Now, I found pretty counter-intuitive that a class created in C++ is actually owned by QML ( QQmlEngine::JavaScriptOwnership) I believe the default ownership should be CppOwnership if the class is created in C++ and then, in case, the developer can do the other way around, letting QML to handle the destruction of QObjects. Cheers, Massimo From gmaxera at gmail.com Tue Apr 28 12:21:02 2015 From: gmaxera at gmail.com (Gianluca) Date: Tue, 28 Apr 2015 12:21:02 +0200 Subject: [Development] QQmlEngine and ObjectOwnership In-Reply-To: <1248095853.8655885.1430215723263.JavaMail.yahoo@mail.yahoo.com> References: <1248095853.8655885.1430215723263.JavaMail.yahoo@mail.yahoo.com> Message-ID: <42858573-1474-4334-8CEC-9F29B7356859@gmail.com> Hello Massimo, I got crazy last year for the same reason … and one developer drive me in the right direction and solved the problem in a slightly different way of you. In my code, sometimes the object is created from QML side … and sometimes is created from C++. In these situations, the ideal behavior should be (of course for me), that object created in C++ are not owned by QML … but as you find, the situation is not like that. So, another strangeness of the owernship by QML … is that depends on the parent of the object created :-S I discovered that if the parent is a QObject created by me outside QML (so, in C++ code) the QML doesn’t take ownership. So, that’s my weird solution: two constructor 1) one set as parent a singleton object created from C++ code, and I use it when I need to create the code from C++ and pass the object to QML 2) another that doesn’t set the parent, and I use it from QML and in this way, then the QML destroy it whenever it wants and it’s ok because this object never pass to C++. Ciao, Gianluca. Il giorno 28/apr/2015, alle ore 12:08, Massimo Callegari ha scritto: > Hi everyone, > > I want to share my experience with the garbage collection of registered classes through qmlRegisterType. > > I got crazy to understand why my application was randomly crashing and I hope this will help others in the future. > > Basically if you want to expose a C++ class in the QML world, you do something like: > > qmlRegisterType("com.myapp.classes", 1, 0, "MyClass"); > > Then you can use the class methods exposed with Q_PROPERTY in QML like this: MyClass.myProperty > > The thing is that when dealing with class pointers, the QML engine performs garbage collection of the exposed classes when it no longer needs them. > > If your classes are created in C++ (new MyClass()) at some point in the C++ code, you will find that the class has been destroyed by QML !! This causes a bunch of segFaults like there is no tomorrow. > > So, after getting crazy to discover this, I discovered also that there is a method of QQmlEngine to > assign the ownership of a class: > > QQmlEngine::setObjectOwnership(myNewClass, QQmlEngine::CppOwnership); > > > After adding this simple line after a "myNewClass = new MyClass()", everything started to working properly. > > Note that in my application, classes created in C++ exist as long as the application lives. > Now, I found pretty counter-intuitive that a class created in C++ is actually owned by QML ( > QQmlEngine::JavaScriptOwnership) > > > I believe the default ownership should be CppOwnership if the class is created in C++ and then, in case, the developer can do the other way around, letting QML to handle the destruction of QObjects. > > Cheers, > > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From massimocallegari at yahoo.it Tue Apr 28 12:30:12 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Tue, 28 Apr 2015 10:30:12 +0000 (UTC) Subject: [Development] QQmlEngine and ObjectOwnership In-Reply-To: <42858573-1474-4334-8CEC-9F29B7356859@gmail.com> References: <42858573-1474-4334-8CEC-9F29B7356859@gmail.com> Message-ID: <1950203490.8676108.1430217012525.JavaMail.yahoo@mail.yahoo.com> Hello Gianluca, interesting point indeed. However double constructors seems like a workaround to me for the chicken and the egg problem :) Then, obviously, if it works it works. No question about that ! :) Massimo ----- Messaggio originale ----- Da: Gianluca A: Massimo Callegari Cc: "development at qt-project.org" Inviato: Martedì 28 Aprile 2015 12:21 Oggetto: Re: [Development] QQmlEngine and ObjectOwnership Hello Massimo, I got crazy last year for the same reason … and one developer drive me in the right direction and solved the problem in a slightly different way of you. In my code, sometimes the object is created from QML side … and sometimes is created from C++. In these situations, the ideal behavior should be (of course for me), that object created in C++ are not owned by QML … but as you find, the situation is not like that. So, another strangeness of the owernship by QML … is that depends on the parent of the object created :-S I discovered that if the parent is a QObject created by me outside QML (so, in C++ code) the QML doesn’t take ownership. So, that’s my weird solution: two constructor 1) one set as parent a singleton object created from C++ code, and I use it when I need to create the code from C++ and pass the object to QML 2) another that doesn’t set the parent, and I use it from QML and in this way, then the QML destroy it whenever it wants and it’s ok because this object never pass to C++. Ciao, Gianluca. Il giorno 28/apr/2015, alle ore 12:08, Massimo Callegari ha scritto: > Hi everyone, > > I want to share my experience with the garbage collection of registered classes through qmlRegisterType. > > I got crazy to understand why my application was randomly crashing and I hope this will help others in the future. > > Basically if you want to expose a C++ class in the QML world, you do something like: > > qmlRegisterType("com.myapp.classes", 1, 0, "MyClass"); > > Then you can use the class methods exposed with Q_PROPERTY in QML like this: MyClass.myProperty > > The thing is that when dealing with class pointers, the QML engine performs garbage collection of the exposed classes when it no longer needs them. > > If your classes are created in C++ (new MyClass()) at some point in the C++ code, you will find that the class has been destroyed by QML !! This causes a bunch of segFaults like there is no tomorrow. > > So, after getting crazy to discover this, I discovered also that there is a method of QQmlEngine to > assign the ownership of a class: > > QQmlEngine::setObjectOwnership(myNewClass, QQmlEngine::CppOwnership); > > > After adding this simple line after a "myNewClass = new MyClass()", everything started to working properly. > > Note that in my application, classes created in C++ exist as long as the application lives. > Now, I found pretty counter-intuitive that a class created in C++ is actually owned by QML ( > QQmlEngine::JavaScriptOwnership) > > > I believe the default ownership should be CppOwnership if the class is created in C++ and then, in case, the developer can do the other way around, letting QML to handle the destruction of QObjects. > > Cheers, > > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From bo at vikingsoft.eu Tue Apr 28 14:25:52 2015 From: bo at vikingsoft.eu (Bo Thorsen) Date: Tue, 28 Apr 2015 14:25:52 +0200 Subject: [Development] QQmlEngine and ObjectOwnership In-Reply-To: <1248095853.8655885.1430215723263.JavaMail.yahoo@mail.yahoo.com> References: <1248095853.8655885.1430215723263.JavaMail.yahoo@mail.yahoo.com> Message-ID: <553F7C50.5040002@vikingsoft.eu> On 04/28/2015 12:08 PM, Massimo Callegari wrote: > Hi everyone, > > I want to share my experience with the garbage collection of registered classes through qmlRegisterType. > > I got crazy to understand why my application was randomly crashing and I hope this will help others in the future. > > Basically if you want to expose a C++ class in the QML world, you do something like: > > qmlRegisterType("com.myapp.classes", 1, 0, "MyClass"); > > Then you can use the class methods exposed with Q_PROPERTY in QML like this: MyClass.myProperty > > The thing is that when dealing with class pointers, the QML engine performs garbage collection of the exposed classes when it no longer needs them. > > If your classes are created in C++ (new MyClass()) at some point in the C++ code, you will find that the class has been destroyed by QML !! This causes a bunch of segFaults like there is no tomorrow. > > So, after getting crazy to discover this, I discovered also that there is a method of QQmlEngine to > assign the ownership of a class: > > QQmlEngine::setObjectOwnership(myNewClass, QQmlEngine::CppOwnership); > > > After adding this simple line after a "myNewClass = new MyClass()", everything started to working properly. > > Note that in my application, classes created in C++ exist as long as the application lives. > Now, I found pretty counter-intuitive that a class created in C++ is actually owned by QML ( > QQmlEngine::JavaScriptOwnership) > > > I believe the default ownership should be CppOwnership if the class is created in C++ and then, in case, the developer can do the other way around, letting QML to handle the destruction of QObjects. Hi Massimo, No, the default is correct. When you expose types to the QML engine, it will construct and destruct objects of your types as it wants to. If you want to have objects that are not controlled by the engine, you can either use qmlRegisterUncreatableType or expose object as context properties with viewer->rootContext()->setContextProperty(). The uncreatable types are useful if you have an object that returns an object of this type. Remember to set the parent of those objects. The "fix" you found is actually the proper way to do this, if you want to create QML objects and control the deletion of them. This is not normally what you would do, so it should not be the default. In the area where you are here - dynamic creation of QML objects - there be mighty dragons. Careful where you go with this. It is much easier to avoid this area completely by using Loader objects and registering global objects to the contexts. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From massimocallegari at yahoo.it Tue Apr 28 14:46:29 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Tue, 28 Apr 2015 12:46:29 +0000 (UTC) Subject: [Development] QQmlEngine and ObjectOwnership In-Reply-To: <553F7C50.5040002@vikingsoft.eu> References: <553F7C50.5040002@vikingsoft.eu> Message-ID: <71770306.8893793.1430225189257.JavaMail.yahoo@mail.yahoo.com> Hi Bo, well, I guess it all depends on what kind of application you're writing. I just wanted to share my specific(?) case so if someone stumbles on it, they can find the solution out of the box :) Mine is probably a poor experience with the QML world, where C++ still gives me that safety to sleep at night :) I am wondering though, in a multi-context application, where you have a MainView.qml with a big Loader that changes context when clicking on some buttons, where do you place "shared" Items that need to be accessed by a context that don't know anything about the other contexts ? That's why I prefer to have a solid C++ ground where I can access my classes all across QML contexts. For now I take QML as an awesome place to design a UI and perform small logics and animations. Maybe in the future I will change my mind ! Anyway, let there be mighty dragons ! :) Massimo ----- Messaggio originale ----- Da: Bo Thorsen A: Massimo Callegari ; "development at qt-project.org" Cc: Inviato: Martedì 28 Aprile 2015 14:25 Oggetto: Re: [Development] QQmlEngine and ObjectOwnership On 04/28/2015 12:08 PM, Massimo Callegari wrote: > Hi everyone, > > I want to share my experience with the garbage collection of registered classes through qmlRegisterType. > > I got crazy to understand why my application was randomly crashing and I hope this will help others in the future. > > Basically if you want to expose a C++ class in the QML world, you do something like: > > qmlRegisterType("com.myapp.classes", 1, 0, "MyClass"); > > Then you can use the class methods exposed with Q_PROPERTY in QML like this: MyClass.myProperty > > The thing is that when dealing with class pointers, the QML engine performs garbage collection of the exposed classes when it no longer needs them. > > If your classes are created in C++ (new MyClass()) at some point in the C++ code, you will find that the class has been destroyed by QML !! This causes a bunch of segFaults like there is no tomorrow. > > So, after getting crazy to discover this, I discovered also that there is a method of QQmlEngine to > assign the ownership of a class: > > QQmlEngine::setObjectOwnership(myNewClass, QQmlEngine::CppOwnership); > > > After adding this simple line after a "myNewClass = new MyClass()", everything started to working properly. > > Note that in my application, classes created in C++ exist as long as the application lives. > Now, I found pretty counter-intuitive that a class created in C++ is actually owned by QML ( > QQmlEngine::JavaScriptOwnership) > > > I believe the default ownership should be CppOwnership if the class is created in C++ and then, in case, the developer can do the other way around, letting QML to handle the destruction of QObjects. Hi Massimo, No, the default is correct. When you expose types to the QML engine, it will construct and destruct objects of your types as it wants to. If you want to have objects that are not controlled by the engine, you can either use qmlRegisterUncreatableType or expose object as context properties with viewer->rootContext()->setContextProperty(). The uncreatable types are useful if you have an object that returns an object of this type. Remember to set the parent of those objects. The "fix" you found is actually the proper way to do this, if you want to create QML objects and control the deletion of them. This is not normally what you would do, so it should not be the default. In the area where you are here - dynamic creation of QML objects - there be mighty dragons. Careful where you go with this. It is much easier to avoid this area completely by using Loader objects and registering global objects to the contexts. Bo Thorsen, Director, Viking Software. -- Viking Software Qt and C++ developers for hire http://www.vikingsoft.eu From mw_triad at users.sourceforge.net Tue Apr 28 16:26:13 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Tue, 28 Apr 2015 10:26:13 -0400 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <3545858.P76U9uhIrU@rhea> References: <3545858.P76U9uhIrU@rhea> Message-ID: On 2015-04-28 04:52, Simon Hausmann wrote: > [getenv/setenv not thread safe] > > There are various options about what we can do with different degrees of "perfection", > but ultimately it's all going to require a compromise. The option that we are favoring > at the moment is two-fold: > > 1) Policy in Qt is to use the Qt wrappers for accessing the environment (qgetenv, etc.). > > 2) These functions we protect with a mutex. > > The concrete proposal of change is at > > https://codereview.qt-project.org/#/c/111158/ > > What do you think? Is there a reason not to use a read/write mutex for this? -- Matthew From simon.hausmann at theqtcompany.com Tue Apr 28 17:10:05 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Tue, 28 Apr 2015 17:10:05 +0200 Subject: [Development] Changes to continuous integration in qtdeclarative/dev In-Reply-To: <1648795.hSnZoV7MRK@frederik-thinkcentre-m93p> References: <1648795.hSnZoV7MRK@frederik-thinkcentre-m93p> Message-ID: <3182120.sb99rJVMoS@rhea> On Thursday 19. March 2015 13.16.43 Frederik Gladhorn wrote: > Hi all, > > I'd like to give everyone a heads up (of hopefully good news). We plan to > switch over the dev branch of qtdeclarative to a new continuous integration > system in the beginning of next week. We currently aim for Monday if all > goes well. A quick update on this: It did go well - sort of :). We've had a few hiccups on the way, but now the system works rather well for declarative I would say. Also integration times are down, from about 2.5 hours for declarative down to 1 hour and 20 minutes. And we haven't even started parallelizing tests across different virtual machines... Meanwhile we've also taken it into production for changes to qtquickcontrols2. Going forward we're working on getting more modules on board, I'm looking at qtbase in particular ;-). In addition we have a pretty good plan now how we can make our internal web interface public, which provides a live view into running integrations. Simon From mardy at users.sourceforge.net Tue Apr 28 19:12:35 2015 From: mardy at users.sourceforge.net (Alberto Mardegan) Date: Tue, 28 Apr 2015 12:12:35 -0500 Subject: [Development] QQmlEngine and ObjectOwnership In-Reply-To: <71770306.8893793.1430225189257.JavaMail.yahoo@mail.yahoo.com> References: <553F7C50.5040002@vikingsoft.eu> <71770306.8893793.1430225189257.JavaMail.yahoo@mail.yahoo.com> Message-ID: <553FBF83.1030508@users.sourceforge.net> Hi Massimo, On 04/28/2015 07:46 AM, Massimo Callegari wrote: > I just wanted to share my specific(?) case so if someone stumbles on it, they can find the solution out of the box :) I also stumbled on this problem once. Luckily, the documentation is quite clear on this -- the problem is that it's not that easy to find it. :-) http://doc.qt.io/qt-5/qqmlengine.html#ObjectOwnership-enum Note that regardless what you think of these heuristics, it's too late to change them: existing applications will either start crashing or leaking memory, so it's a no-go. > I am wondering though, in a multi-context application, where you have a MainView.qml with a big > Loader that changes context when clicking on some buttons, where do you place "shared" Items that > need to be accessed by a context that don't know anything about the other contexts ? This, and what you previously wrote (that these objects stay alive for the whole lifetime of the app) makes me think that you probably want to register your objects as singletons: http://doc.qt.io/qt-5/qqmlengine.html#qmlRegisterSingletonType Ciao, Alberto From wargand at gmx.de Wed Apr 29 00:42:46 2015 From: wargand at gmx.de (Guido Seifert) Date: Wed, 29 Apr 2015 00:42:46 +0200 Subject: [Development] Qt dev does not compile with GCC 5.1 Message-ID: <20150429004246.0d75d3b2.wargand@gmx.de> Hi, little head start for you guys :-) Today I compiled a fresh GCC 5.1.0. Then I tried to compile a very fresh Qt (today's dev branch) with it. This is the result: In file included from gen/blink/bindings/core/v8/V8GeneratedCoreBindings01.cpp:34:0: gen/blink/bindings/core/v8/V8NodeFilter.cpp: In function ‘void blink::installV8NodeFilterTemplate(v8::Handle, v8::Isolate*)’: gen/blink/bindings/core/v8/V8NodeFilter.cpp:93:5: error: narrowing conversion of ‘4294967295u’ from ‘unsigned int’ to ‘int’ inside { } So, not really Qt, but 3rd party or not... not compiling through is not compiling through. Guido From simon.hausmann at theqtcompany.com Wed Apr 29 10:02:29 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Wed, 29 Apr 2015 10:02:29 +0200 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: References: <3545858.P76U9uhIrU@rhea> Message-ID: <4493433.2HGQztyxT3@simon-sx58> On Tuesday, April 28, 2015 10:26:13 AM Matthew Woehlke wrote: > On 2015-04-28 04:52, Simon Hausmann wrote: > > [getenv/setenv not thread safe] > > > > There are various options about what we can do with different degrees of > > "perfection", but ultimately it's all going to require a compromise. The > > option that we are favoring at the moment is two-fold: > > > > 1) Policy in Qt is to use the Qt wrappers for accessing the environment > > (qgetenv, etc.). > > > > 2) These functions we protect with a mutex. > > > > The concrete proposal of change is at > > > > https://codereview.qt-project.org/#/c/111158/ > > > > What do you think? > > Is there a reason not to use a read/write mutex for this? In my opinion the overhead of the read-write lock is not worth the prospective gain in the unlikely event of repeated concurrent environment access. Simon From wargand at gmx.de Wed Apr 29 10:33:08 2015 From: wargand at gmx.de (Guido Seifert) Date: Wed, 29 Apr 2015 10:33:08 +0200 Subject: [Development] Qt dev does not compile with GCC 5.1 In-Reply-To: <20150429061603.GB15910@x4> References: <20150429004246.0d75d3b2.wargand@gmx.de> <20150429061603.GB15910@x4> Message-ID: <20150429103308.0c506be9.wargand@gmx.de> Oh, for me this is good enough. I am just playing around with new stuff. But if the qt project can wait for 5.2? 3-4 month if I googled correctly? No idea. Guido On Wed, 29 Apr 2015 08:16:03 +0200 Markus Trippelsdorf wrote: > This will be fixed in 5.2, see: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65801 > > Until then, just add casts to int. > > -- > Markus > From marc.mutz at kdab.com Wed Apr 29 11:55:48 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Apr 2015 11:55:48 +0200 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <3545858.P76U9uhIrU@rhea> References: <3545858.P76U9uhIrU@rhea> Message-ID: <201504291155.48985.marc.mutz@kdab.com> On Tuesday 28 April 2015 10:52:32 Simon Hausmann wrote: > There are various options about what we can do with different degrees of > "perfection", but ultimately it's all going to require a compromise. The > option that we are favoring at the moment is two-fold: > > 1) Policy in Qt is to use the Qt wrappers for accessing the environment > (qgetenv, etc.). > > 2) These functions we protect with a mutex. > > Yes, this isn't perfect, because we still include large quantities of code > in src/3rdparty in Qt that has unprotected calls to getenv(). But then > that hasn't stopped us from patching that code in the past. From Gerrit, expanded here and there: I don't believe this is the right fix. 1. man putenv on Linux says that since glibc 2.1, putenv is reentrant. In any case, it's almost trivial to fix this in libc (using CAS, as Ossi suggested in a comment on v1 of the patch), but impossible outside. 2. what business does a program have, anyway, of modifying the environment after threads may have started? Such code should be fixed. Making the Qt wrappers "save" could lead to more code doing nonsense instead of being fixed. 3. C functions such as localtime(3) are calling tzset(3) which reads TZ. You may be able to patch 3rd-party code, but you cannot patch libc. Callers of putenv()/setenv() should be fixed to not do so after initial initialisation, ie. when threads may have started. This is how most initialisation in libraries is required to be handled, see e.g. https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check.html and I don't see why Qt should do something different from every other C/C++ library on the planet, at least not for such a common problem as library initialisation. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From marc.mutz at kdab.com Wed Apr 29 12:20:05 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 29 Apr 2015 12:20:05 +0200 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <201504291155.48985.marc.mutz@kdab.com> References: <3545858.P76U9uhIrU@rhea> <201504291155.48985.marc.mutz@kdab.com> Message-ID: <201504291220.06000.marc.mutz@kdab.com> On Wednesday 29 April 2015 11:55:48 Marc Mutz wrote: > 1. man putenv on Linux says that since glibc 2.1, putenv is reentrant http://osxr.org/glibc/source/stdlib/setenv.c#0109 but getenv isn't protected by any lock, indeed: http://osxr.org/glibc/source/stdlib/getenv.c#0033 -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From simon.hausmann at theqtcompany.com Wed Apr 29 11:15:21 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Wed, 29 Apr 2015 11:15:21 +0200 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <201504291155.48985.marc.mutz@kdab.com> References: <3545858.P76U9uhIrU@rhea> <201504291155.48985.marc.mutz@kdab.com> Message-ID: <1611220.3XPGm5H5L0@simon-sx58> On Wednesday, April 29, 2015 11:55:48 AM Marc Mutz wrote: > On Tuesday 28 April 2015 10:52:32 Simon Hausmann wrote: > > There are various options about what we can do with different degrees of > > "perfection", but ultimately it's all going to require a compromise. The > > option that we are favoring at the moment is two-fold: > > > > 1) Policy in Qt is to use the Qt wrappers for accessing the environment > > (qgetenv, etc.). > > > > 2) These functions we protect with a mutex. > > > > Yes, this isn't perfect, because we still include large quantities of code > > in src/3rdparty in Qt that has unprotected calls to getenv(). But then > > that hasn't stopped us from patching that code in the past. > > From Gerrit, expanded here and there: > > I don't believe this is the right fix. > > 1. man putenv on Linux says that since glibc 2.1, putenv is reentrant. In > any case, it's almost trivial to fix this in libc (using CAS, as Ossi > suggested in a comment on v1 of the patch), but impossible outside. Does reentrancy here refer to the supplied arguments of putenv? Can you explain how this helps with concurrent getenv invocations? (Sorry, I must be missing something - I don't see how this relates to the crashes) > 2. what business does a program have, anyway, of modifying the environment > after threads may have started? Such code should be fixed. Making the Qt > wrappers "save" could lead to more code doing nonsense instead of being > fixed. > > 3. C functions such as localtime(3) are calling tzset(3) which reads TZ. > You may be able to patch 3rd-party code, but you cannot patch libc. Right, there are more "unsafe" functions in libc that we cannot change. But isn't that an orthogonal topic to the issue of our tests crashing? > Callers of putenv()/setenv() should be fixed to not do so after initial > initialisation, ie. when threads may have started. This is how most > initialisation in libraries is required to be handled, see e.g. > https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check.htm > l and I don't see why Qt should do something different from every other > C/C++ library on the planet, at least not for such a common problem as > library initialisation. How can we do this in Qt and in our tests? It would all have to be done before the application constructor, because already our platform plugins start threads. This is in contrast to individual test functions in Qt calling putenv(). Simon From tuukka.turunen at theqtcompany.com Wed Apr 29 12:00:30 2015 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Wed, 29 Apr 2015 10:00:30 +0000 Subject: [Development] Licensing of WinRT and Windows Embedded in Qt 5.5 Message-ID: Hello, The Qt Company has decided that the license of WinRT port of Qt will be LGPLv3 / GPLv2+ / Commercial in Qt 5.5. Microsoft is soon to release Windows 10, and Qt 5.5.x is planned to bring full support for it. We prefer LGPLv3 and therefore we want to adjust the licensing now and discontinue the LGPLv2.1 option of Qt for WinRT. There are no changes to the licensing of Win32 port of Qt. The terms and conditions of the Windows Store are compatible with the new licensing options. Similarly it has been decided that the license of Windows Embedded Compact (WinCE) port of Qt will be LGPLv3 / GPLv2+ / Commercial in Qt 5.5. This has already been discussed with KDAB, who is the platform maintainer and a major contributor of the Windows Embedded Compact port of Qt. There is a blog post describing our plans for Windows 10 support: http://blog.qt.io/blog/2015/04/29/windows-10-support-in-qt Yours, Tuukka Turunen Director, R&D The Qt Company Email: tuukka.turunen at theqtcompany.com www.qt.io -------------- next part -------------- An HTML attachment was scrubbed... URL: From Eike.Ziller at theqtcompany.com Wed Apr 29 12:35:24 2015 From: Eike.Ziller at theqtcompany.com (Ziller Eike) Date: Wed, 29 Apr 2015 10:35:24 +0000 Subject: [Development] Qt Creator uses "_qt_autotest_force_engine_poller"? In-Reply-To: <10761057.eS8fFCKAyj@portia.local> References: <10761057.eS8fFCKAyj@portia.local> Message-ID: > On Apr 21, 2015, at 11:46 AM, René J.V. Bertin wrote: > > Hi, > > I know I should ask this on the QC ML (but I'd prefer not to sign up for just an occasional question like this): > > Is there a (good) reason why DocumentManagerPrivate::linkWatcher() forces the use of a polling watcher? The reason is https://bugreports.qt.io/browse/QTBUG-15522 Br, Eike > > Mainly asking because I just noticed that this approach can lead to significant CPU use when the IDE is otherwise idle, which is ... unfortunate. > > R. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Eike Ziller, Senior Software Engineer - The Qt Company GmbH The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From konstantin at podsvirov.pro Wed Apr 29 15:57:07 2015 From: konstantin at podsvirov.pro (Konstantin Podsvirov) Date: Wed, 29 Apr 2015 16:57:07 +0300 Subject: [Development] [CPackIFW] Adding QtIFW 2.0 Support (Technical Preview) Message-ID: <5216931430315827@web13g.yandex.ru> Hello dear developers! Recently we learned the good news about the release QtIFW 2.0: http://blog.qt.io/blog/2015/04/07/qt-installer-framework-2-0-released And I too was delighted at once. But then I was faced with an unstable work of the installer on Windows and it upset me. I think QtIFW 2.0 as quickly as possible became better - you need to actively use and test in various situations. On adding support QtIFW 2.0 now I work in a topic branch cpack-ifw-develop: http://git.podsvirov.pro/?p=kitware/cmake.git;a=shortlog;h=refs/heads/cpack-ifw-develop All those interested can get acquainted with the code, but I want to submit online installers CMake based on this code, and built by ourselves :-) : Two installer collected in Debian 8: http://ifw.podsvirov.pro/cmake/cmake-master-i386-online.run http://ifw.podsvirov.pro/cmake/cmake-master-amd64-online.run And two installer collected in Windows 7: http://ifw.podsvirov.pro/cmake/cmake-master-win32-online.exe http://ifw.podsvirov.pro/cmake/cmake-master-win64-online.exe Working with cpack-ifw-develop I will periodically update the online repository. The presented version of CMake (CPackIFW) already know how to work with QtIFW 2.0 but not in full. I would like to know from users CPackIFW and QtIFW what functionality demanded in the first place. Suggest we discuss the quality of the generated configuration files. Also available documentation: http://ifw.podsvirov.pro/cmake/doc/sphinx http://ifw.podsvirov.pro/cmake/doc/doxygen When I decide that the support QtIFW 2.0 has reached an acceptable state, we will begin work on the integration of changes. Waiting for answers, questions, suggestions! -- Regards, Konstantin Podsvirov From thiago.macieira at intel.com Wed Apr 29 17:42:08 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Apr 2015 08:42:08 -0700 Subject: [Development] Licensing of WinRT and Windows Embedded in Qt 5.5 In-Reply-To: References: Message-ID: <7976786.BscxDqjIjs@tjmaciei-mobl4> On Wednesday 29 April 2015 10:00:30 Turunen Tuukka wrote: > The Qt Company has decided that the license of WinRT port of Qt will be > LGPLv3 / GPLv2+ / Commercial in Qt 5.5. Microsoft is soon to release > Windows 10, and Qt 5.5.x is planned to bring full support for it. We prefer > LGPLv3 and therefore we want to adjust the licensing now and discontinue > the LGPLv2.1 option of Qt for WinRT. There are no changes to the licensing > of Win32 port of Qt. The terms and conditions of the Windows Store are > compatible with the new licensing options. Hi Tuukka How is that accomplished? Are you licensing a few files inside QtCore, QtGui and QtWidgets as LGPLv3/GPLv2+/Commercial? Or is it just the QPA plugin for WinRT/WinCE? I just want to know which files are to have the different licence header. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Apr 29 17:45:24 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Apr 2015 08:45:24 -0700 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <4493433.2HGQztyxT3@simon-sx58> References: <3545858.P76U9uhIrU@rhea> <4493433.2HGQztyxT3@simon-sx58> Message-ID: <1953028.MymdS5yk33@tjmaciei-mobl4> On Wednesday 29 April 2015 10:02:29 Simon Hausmann wrote: > In my opinion the overhead of the read-write lock is not worth the > prospective gain in the unlikely event of repeated concurrent environment > access. Agreed. An RWLock has a benefit when there are multiple *read* threads trying to access the same data, frequently and at the same time and such access is not short in time. The added benefit is fairness to the writer. A mutex is much simpler. For the case here, a mutex suffices: the accesses are short and infrequent. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Wed Apr 29 17:47:22 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 29 Apr 2015 08:47:22 -0700 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <1611220.3XPGm5H5L0@simon-sx58> References: <3545858.P76U9uhIrU@rhea> <201504291155.48985.marc.mutz@kdab.com> <1611220.3XPGm5H5L0@simon-sx58> Message-ID: <2344989.F0K3p1CpLo@tjmaciei-mobl4> On Wednesday 29 April 2015 11:15:21 Simon Hausmann wrote: > How can we do this in Qt and in our tests? The problem here is the fact that they're tests. Unlike regular applications, we're doing things at times when applications shouldn't be doing the same action. Strictly speaking, we should fix the tests. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From sandroandrade at kde.org Wed Apr 29 22:26:25 2015 From: sandroandrade at kde.org (Sandro Andrade) Date: Wed, 29 Apr 2015 17:26:25 -0300 Subject: [Development] QtModeling - the last mile Message-ID: Hi there, Some time ago, I started the development of QtModeling : a qt add-on aimed at providing metamodeling features and the basic infrastructure for dealing with software models. It already has a lot of interesting features and now I have the available time to making it good enough to be released. There are, however, some design choices I would like to discuss and get some feedback from some of you guys. Implementing the UML metamodel, for example, requires a considerable time investiment. Part of this is already done, but I would like to set up a plan to incrementally release such features. So, would anyone be willing to provide some guidance and keep up with QtModeling to its release ? Thanks in advance, -- Sandro From ritt.ks at gmail.com Wed Apr 29 23:01:52 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Thu, 30 Apr 2015 01:01:52 +0400 Subject: [Development] QtModeling - the last mile In-Reply-To: References: Message-ID: Any links/code/docs?) Konstantin 2015-04-30 0:26 GMT+04:00 Sandro Andrade : > Hi there, > > Some time ago, I started the development of QtModeling : a qt add-on > aimed at providing metamodeling features and the basic infrastructure > for dealing with software models. It already has a lot of interesting > features and now I have the available time to making it good enough to > be released. > > There are, however, some design choices I would like to discuss and > get some feedback from some of you guys. Implementing the UML > metamodel, for example, requires a considerable time investiment. Part > of this is already done, but I would like to set up a plan to > incrementally release such features. > > So, would anyone be willing to provide some guidance and keep up with > QtModeling to its release ? > > Thanks in advance, > -- > Sandro > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmitry.volosnykh at gmail.com Wed Apr 29 23:07:52 2015 From: dmitry.volosnykh at gmail.com (Dmitry Volosnykh) Date: Thu, 30 Apr 2015 00:07:52 +0300 Subject: [Development] QtModeling - the last mile In-Reply-To: References: Message-ID: Konstantin, here you are: http://wiki.qt.io/QtModeling On Thu, Apr 30, 2015 at 12:01 AM, Konstantin Ritt wrote: > Any links/code/docs?) > > Konstantin > > 2015-04-30 0:26 GMT+04:00 Sandro Andrade : > >> Hi there, >> >> Some time ago, I started the development of QtModeling : a qt add-on >> aimed at providing metamodeling features and the basic infrastructure >> for dealing with software models. It already has a lot of interesting >> features and now I have the available time to making it good enough to >> be released. >> >> There are, however, some design choices I would like to discuss and >> get some feedback from some of you guys. Implementing the UML >> metamodel, for example, requires a considerable time investiment. Part >> of this is already done, but I would like to set up a plan to >> incrementally release such features. >> >> So, would anyone be willing to provide some guidance and keep up with >> QtModeling to its release ? >> >> Thanks in advance, >> -- >> Sandro >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development >> > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sandroandrade at kde.org Wed Apr 29 23:08:51 2015 From: sandroandrade at kde.org (Sandro Andrade) Date: Wed, 29 Apr 2015 18:08:51 -0300 Subject: [Development] QtModeling - the last mile In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 6:01 PM, Konstantin Ritt wrote: > Any links/code/docs?) Yes, sorry :) Wiki page: http://wiki.qt.io/QtModeling Git repository: http://www.gitorious.org/qt/qtmodeling DuSE-MT (QtModeling-based tool) website: http://duse.sourceforge.net/ DuSE-MT repository: www.gitorious.org/duse-mt/duse-mt Some posts about QtModeling: https://liveblue.wordpress.com/2012/12/11/call-for-arms-qtmofqtuml/ https://liveblue.wordpress.com/2013/01/21/qtmofqtuml-xmi-serialization-and-metamodel-plugins/ https://liveblue.wordpress.com/2013/11/18/how-cute-can-modeling-be/ Cheers, Sandro > > Konstantin > > 2015-04-30 0:26 GMT+04:00 Sandro Andrade : >> >> Hi there, >> >> Some time ago, I started the development of QtModeling : a qt add-on >> aimed at providing metamodeling features and the basic infrastructure >> for dealing with software models. It already has a lot of interesting >> features and now I have the available time to making it good enough to >> be released. >> >> There are, however, some design choices I would like to discuss and >> get some feedback from some of you guys. Implementing the UML >> metamodel, for example, requires a considerable time investiment. Part >> of this is already done, but I would like to set up a plan to >> incrementally release such features. >> >> So, would anyone be willing to provide some guidance and keep up with >> QtModeling to its release ? >> >> Thanks in advance, >> -- >> Sandro >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > From perezmeyer at gmail.com Thu Apr 30 00:00:18 2015 From: perezmeyer at gmail.com (Lisandro =?ISO-8859-1?Q?Dami=E1n_Nicanor_P=E9rez?= Meyer) Date: Wed, 29 Apr 2015 19:00:18 -0300 Subject: [Development] New (optional?) dependency: xcb-util-errors In-Reply-To: <1430135166562.46966@theqtcompany.com> References: <553D3EEB.1080504@znc.in> <1430135166562.46966@theqtcompany.com> Message-ID: <2812146.3We3Rfi1b1@luna> On Monday 27 April 2015 11:46:05 Lind Jorgen wrote: > Its a small library, so I think it is sensible to compile it in the plugin > (even with the error data). I don't think it makes much sense at current > time to check if there is a system version available and then use that. Oh yes it's sensible, else we distro maintainers will: - be forced to package it to avoid using the embedded version - be forced to create patches to use the system version Compile-time detection falling back to embedded version is the best solution IMHO. As far as I can tell Debian isn't shipping it, but it doesn't surprises me if it's a new lib, we just came out of freeze. -- "In college, I cooked some hot dogs by putting metal forks in each end of the hot dog and running 120 volts through it. Hot dogs have just enough conductivity so that this works well" greenroom(576281) - on a truly geeky way to cook hot dogs. Posted in Slashdot, also found in The Open Source Cookbook for Geeks. Lisandro Damián Nicanor Pérez Meyer http://perezmeyer.com.ar/ http://perezmeyer.blogspot.com/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From tuukka.turunen at theqtcompany.com Thu Apr 30 00:27:11 2015 From: tuukka.turunen at theqtcompany.com (Turunen Tuukka) Date: Wed, 29 Apr 2015 22:27:11 +0000 Subject: [Development] Licensing of WinRT and Windows Embedded in Qt 5.5 In-Reply-To: <7976786.BscxDqjIjs@tjmaciei-mobl4> References: <7976786.BscxDqjIjs@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Thiago Macieira [mailto:thiago.macieira at intel.com] > Sent: 29. huhtikuuta 2015 18:42 > To: development at qt-project.org > Cc: Turunen Tuukka > Subject: Re: [Development] Licensing of WinRT and Windows Embedded in Qt > 5.5 > > On Wednesday 29 April 2015 10:00:30 Turunen Tuukka wrote: > > The Qt Company has decided that the license of WinRT port of Qt will > > be > > LGPLv3 / GPLv2+ / Commercial in Qt 5.5. Microsoft is soon to release > > Windows 10, and Qt 5.5.x is planned to bring full support for it. We > > prefer > > LGPLv3 and therefore we want to adjust the licensing now and > > discontinue the LGPLv2.1 option of Qt for WinRT. There are no changes > > to the licensing of Win32 port of Qt. The terms and conditions of the > > Windows Store are compatible with the new licensing options. > > Hi Tuukka > > How is that accomplished? Are you licensing a few files inside QtCore, QtGui and > QtWidgets as LGPLv3/GPLv2+/Commercial? Or is it just the QPA plugin for > WinRT/WinCE? > > I just want to know which files are to have the different licence header. It would be the WinRT platform plugins, which are located in: Qt Base (the WinRT QPA plugin) Qt Location (WinRT positioning backend) Multimedia (WinRT backend) Qt Sensors (WinRT backend) I think we are able to use the existing LGPLv3 / GPLv2+ / commercial header template, so the change should be straightforward. Yours, Tuukka > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Apr 30 10:50:59 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 30 Apr 2015 10:50:59 +0200 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <1611220.3XPGm5H5L0@simon-sx58> References: <3545858.P76U9uhIrU@rhea> <201504291155.48985.marc.mutz@kdab.com> <1611220.3XPGm5H5L0@simon-sx58> Message-ID: <201504301050.59278.marc.mutz@kdab.com> On Wednesday 29 April 2015 11:15:21 Simon Hausmann wrote: > > 1. man putenv on Linux says that since glibc 2.1, putenv is reentrant. In > > > > any case, it's almost trivial to fix this in libc (using CAS, as Ossi > > suggested in a comment on v1 of the patch), but impossible outside. > > Does reentrancy here refer to the supplied arguments of putenv? Can you > explain how this helps with concurrent getenv invocations? > > (Sorry, I must be missing something - I don't see how this relates to the > crashes) See my other mail. It prevents putenv/putenv races, but not putenv/getenv, indeed. > > 2. what business does a program have, anyway, of modifying the > > environment after threads may have started? Such code should be fixed. > > Making the Qt wrappers "save" could lead to more code doing nonsense > > instead of being fixed. This is my main point. > > 3. C functions such as localtime(3) are calling tzset(3) which reads TZ. > > You may be able to patch 3rd-party code, but you cannot patch libc. > > Right, there are more "unsafe" functions in libc that we cannot change. > But isn't that an orthogonal topic to the issue of our tests crashing? You want to fix races between environment accesses. I'm saying that libc functions are implicitly accessing the environment, too, and you cannot insert you Qt mutex there. So this is isn't really orthogonal. > > Callers of putenv()/setenv() should be fixed to not do so after initial > > initialisation, ie. when threads may have started. This is how most > > initialisation in libraries is required to be handled, see e.g. > > > > https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check. > >htm > > > > l and I don't see why Qt should do something different from every other > > C/C++ library on the planet, at least not for such a common problem as > > library initialisation. > > How can we do this in Qt and in our tests? Tests are presumably easy. If everything else fails, QtTest could execute itself anew for each test. After a quick scan, the only thing I'm worried about in QtBase is qglxconvenience.cpp, which temporarily modifies the environment. > It would all have to be done before the application constructor, because > already our platform plugins start threads. This is in contrast to > individual test functions in Qt calling putenv(). Platform plugins are creating threads before the Q*Application ctor runs? How is that possible if the Q*Application ctor is the first Qt code that gets called from the application? If they do, it means that the threads are already running when control enters main(). And that's unacceptable, because it deprives application authors of the window of control where there's only one thread of execution. Guaranteed. So you cannot, say, use gpgme with a Qt program. Qt can't make the rules. It has to abide by them. As an aside: That so much code in Qt checks the environment for some more-or-less obscure options indicates the need for explicit management of these options. I'll give this some more thought. Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From simon.hausmann at theqtcompany.com Thu Apr 30 10:06:05 2015 From: simon.hausmann at theqtcompany.com (Simon Hausmann) Date: Thu, 30 Apr 2015 10:06:05 +0200 Subject: [Development] Modifying and accessing environment variables in Qt In-Reply-To: <201504301050.59278.marc.mutz@kdab.com> References: <3545858.P76U9uhIrU@rhea> <1611220.3XPGm5H5L0@simon-sx58> <201504301050.59278.marc.mutz@kdab.com> Message-ID: <2081865.ylHffNj5Et@simon-sx58> On Thursday, April 30, 2015 10:50:59 AM Marc Mutz wrote: > > > 2. what business does a program have, anyway, of modifying the > > > > > > environment after threads may have started? Such code should be > > > fixed. > > > Making the Qt wrappers "save" could lead to more code doing nonsense > > > instead of being fixed. > > This is my main point. That is a valid point, for sure. Inherently valid due to the nature of the way the C runtime implements this and is accessible to everyone. > > > 3. C functions such as localtime(3) are calling tzset(3) which reads TZ. > > > > > > You may be able to patch 3rd-party code, but you cannot patch libc. > > > > Right, there are more "unsafe" functions in libc that we cannot change. > > But isn't that an orthogonal topic to the issue of our tests crashing? > > You want to fix races between environment accesses. I'm saying that libc > functions are implicitly accessing the environment, too, and you cannot > insert you Qt mutex there. So this is isn't really orthogonal. I think you may be misunderstanding me. I don't want to fix all races, I want to fix the common cases in Qt, in particular the ones that affect our everyday work of trying to integrate changes by passing tests. I'm looking for a pragmatic improvement, not a perfect solution. I see however that you agree to the proposed change being acceptable as a stop-gap - so thank you :) > > > Callers of putenv()/setenv() should be fixed to not do so after initial > > > initialisation, ie. when threads may have started. This is how most > > > initialisation in libraries is required to be handled, see e.g. > > > > > > https://www.gnupg.org/documentation/manuals/gpgme/Library-Version-Check > > > . > > > > > >htm > > > > > > l and I don't see why Qt should do something different from every other > > > C/C++ library on the planet, at least not for such a common problem as > > > library initialisation. > > > > How can we do this in Qt and in our tests? > > Tests are presumably easy. If everything else fails, QtTest could execute > itself anew for each test. Can you elaborate on that? I don't think I fully understand what you mean. The only portable solution that I can think of is to replace each use of an environment variable with an autotest-only exported variable in Qt, that is used instead. That may be a path forward and I'd be happy to help review changes towards that. > After a quick scan, the only thing I'm worried > about in QtBase is qglxconvenience.cpp, which temporarily modifies the > environment. > > It would all have to be done before the application constructor, because > > already our platform plugins start threads. This is in contrast to > > individual test functions in Qt calling putenv(). > > Platform plugins are creating threads before the Q*Application ctor runs? > How is that possible if the Q*Application ctor is the first Qt code that > gets called from the application? If they do, it means that the threads are > already running when control enters main(). And that's unacceptable, > because it deprives application authors of the window of control where > there's only one thread of execution. Guaranteed. So you cannot, say, use > gpgme with a Qt program. No, I do not claim that threads are created before the Q*Application constructor runs. Please re-read what I wrote. I said that the platform plugins start threads, and they are loaded in the Q*Application constructor. So environment variables have to be set before there, if they affect the platform plugins. Simon From rjvbertin at gmail.com Thu Apr 30 10:24:04 2015 From: rjvbertin at gmail.com (=?utf-8?Q?Ren=C3=A9_JV_Bertin?=) Date: Thu, 30 Apr 2015 10:24:04 +0200 Subject: [Development] Qt Creator uses "_qt_autotest_force_engine_poller"? In-Reply-To: References: <10761057.eS8fFCKAyj@portia.local> Message-ID: Makes sense, thanks. R On 29 Apr 2015, at 12:35, Ziller Eike wrote: > >> On Apr 21, 2015, at 11:46 AM, René J.V. Bertin wrote: >> >> Hi, >> >> I know I should ask this on the QC ML (but I'd prefer not to sign up for just an occasional question like this): >> >> Is there a (good) reason why DocumentManagerPrivate::linkWatcher() forces the use of a polling watcher? > > The reason is https://bugreports.qt.io/browse/QTBUG-15522 > > Br, Eike > >> >> Mainly asking because I just noticed that this approach can lead to significant CPU use when the IDE is otherwise idle, which is ... unfortunate. >> >> R. >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > > -- > Eike Ziller, Senior Software Engineer - The Qt Company GmbH > > The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin > Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > From akseli.salovaara at theqtcompany.com Thu Apr 30 15:17:22 2015 From: akseli.salovaara at theqtcompany.com (Salovaara Akseli) Date: Thu, 30 Apr 2015 13:17:22 +0000 Subject: [Development] Qt 4.8.7 release candidate available Message-ID: Hi, Qt 4.8.7 release candidate packages are available at http://download.qt.io/development_releases/qt/4.8/4.8.7-rc1/ and SHA-1 is now frozen so please test these packages accordingly. These packages are built against SHA-1: fa81aa6d027049e855b76f5408586a288f160575 * QNAM: Fix upload corruptions when server closes connection (current HEAD). Preliminary version of changes-4.8.7 file is available at http://download.qt.io/development_releases/qt/4.8/4.8.7-rc1/changes-4.8.7-rc1.txt and full git log http://download.qt.io/development_releases/qt/4.8/4.8.7-rc1/4.8.7-rc1-changes-git-log.txt (mirroring in progress - if changes files are not available please try again a bit later). If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please report those to bugreports.qt.io and raise issue also (with bug id) on releasing mailing list. Br, Akseli -- Akseli Salovaara The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From mw_triad at users.sourceforge.net Thu Apr 30 16:48:56 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 30 Apr 2015 10:48:56 -0400 Subject: [Development] Qt 4.8.7 release candidate available In-Reply-To: References: Message-ID: On 2015-04-30 09:17, Salovaara Akseli wrote: > If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please report those to bugreports.qt.io and raise issue also (with bug id) on releasing mailing list. Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 fixed? This is a really nasty bug that cripples all (newly launched) Qt applications when it happens. It's listed as P1 and has been reproduced, but I don't know enough about the bowels of QSessionManager to suggest a solution. KDE4 is likely to be around for a while yet (e.g. LTS distros) and it would be good if this can be fixed. -- Matthew From Simon.Hausmann at theqtcompany.com Thu Apr 30 19:37:07 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 30 Apr 2015 17:37:07 +0000 Subject: [Development] Qt 4.8.7 release candidate available In-Reply-To: References: , Message-ID: <20150430173706.5677136.88463.21306@theqtcompany.com> IMO this isn't a Qt bug, I commented on Jira. I suspect another app isn't implementing the protocol directly, but if we really want to protect ourselves then we should probably ditch the entire session management code from Qt 4 (it's gone in Qt 5, too :) Simon Original Message From: Matthew Woehlke Sent: Thursday, April 30, 2015 16:49 To: development at qt-project.org Cc: releasing at qt-project.org Subject: Re: [Development] Qt 4.8.7 release candidate available On 2015-04-30 09:17, Salovaara Akseli wrote: > If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please report those to bugreports.qt.io and raise issue also (with bug id) on releasing mailing list. Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 fixed? This is a really nasty bug that cripples all (newly launched) Qt applications when it happens. It's listed as P1 and has been reproduced, but I don't know enough about the bowels of QSessionManager to suggest a solution. KDE4 is likely to be around for a while yet (e.g. LTS distros) and it would be good if this can be fixed. -- Matthew _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mw_triad at users.sourceforge.net Thu Apr 30 22:04:18 2015 From: mw_triad at users.sourceforge.net (Matthew Woehlke) Date: Thu, 30 Apr 2015 16:04:18 -0400 Subject: [Development] Proposal: Deprecating platforms in Qt 5.6 that don't support lambda In-Reply-To: <3721327.bCAph42EGJ@tjmaciei-mobl4> References: <2824381.7J9KQt27bL@marvin> <3721327.bCAph42EGJ@tjmaciei-mobl4> Message-ID: On 2015-02-20 14:42, Thiago Macieira wrote: > On Friday 20 February 2015 12:53:24 Matthew Woehlke wrote: >> for (auto const i : qtEnumerate(map)) >> >> Maybe it would be nice for Qt to provide one or both of these? > > Sounds easy enough. Want to give it a try? I *finally* got permission to share this. Sorry it took so long. The attached code, excluding the copyright notices, is hereby placed into the Public Domain. Permission is also granted to use the attached code under either the BSD license, as stated in the files themselves, or pursuant to Kitware's CLA with Qt. It is my hope that this is useful to other people. (Also that the first one finds its way into STL eventually :-), though that's a bit OT for here.) These are both C++11 code. At minimum, they'll need brace-initialization changed to parentheses-initialization in order to build in C++03 mode. However, qtIndexRange also uses trailing return type specification, and I'm not sure it's possible to avoid that without losing type deduction, which sort-of defeats the purpose. There are also lots of elided type specifiers, though those are easy enough to add. Personally, I wouldn't consider it a terrible loss if these were only available in C++11-or-later mode, since they're intended to be used with range-based for. > Note that this should also work for foreach: > > foreach (const auto i, qtEnumerate(map)) I'm not sure if it will or not; it was designed to work in range-based for, i.e. it supplies begin() and end(). I'm not sure if that's enough to automagically work in Q_FOREACH. Thiago, do you want me to take another look at integrating these into Qt proper, or do you have it in hand? -- Matthew -------------- next part -------------- /* Copyright 2015 Kitware, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither name of Kitware, Inc. nor the names of any contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Based on code written by Matthew Woehlke and used by permission. */ #ifndef __qtEnumerate_h #define __qtEnumerate_h //----------------------------------------------------------------------------- template class qtEnumerator { public: class iterator; qtEnumerator(Container const& container) : c(container) {} iterator begin() const { return {c.begin()}; } iterator end() const { return {c.end()}; } protected: Container const& c; }; //----------------------------------------------------------------------------- template class qtEnumerator::iterator { public: using Iterator = typename Container::const_iterator; Iterator operator*() const { return i; } iterator& operator++() { ++i; return *this; } bool operator==(iterator const& other) const { return i == other.i; } bool operator!=(iterator const& other) const { return i != other.i; } protected: friend class qtEnumerator; iterator(Iterator const& iter) : i{iter} {} Iterator i; }; //----------------------------------------------------------------------------- template qtEnumerator qtEnumerate(Container const& container) { return {container}; } #endif -------------- next part -------------- /* Copyright 2015 Kitware, Inc. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. * Neither name of Kitware, Inc. nor the names of any contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. Based on code written by Matthew Woehlke and used by permission. */ #ifndef __qtIndexRange_h #define __qtIndexRange_h //----------------------------------------------------------------------------- template class qtIndexRangeType { public: class iterator; qtIndexRangeType(T count) : End{count} {} iterator begin() const { return {T{0}}; } iterator end() const { return {End}; } protected: T End; }; //----------------------------------------------------------------------------- template class qtIndexRangeType::iterator { public: T operator*() const { return Value; } iterator& operator++() { ++Value; return *this; } bool operator==(iterator const& other) const { return Value == other.Value; } bool operator!=(iterator const& other) const { return Value != other.Value; } protected: friend class qtIndexRangeType; iterator(T value) : Value{value} {} T Value; }; //----------------------------------------------------------------------------- template auto qtIndexRange(T count) -> qtIndexRangeType { return {count}; } #endif From samuel.gaist at edeltech.ch Thu Apr 30 23:36:34 2015 From: samuel.gaist at edeltech.ch (Samuel Gaist) Date: Thu, 30 Apr 2015 23:36:34 +0200 Subject: [Development] Qt 4.8.7 release candidate available In-Reply-To: <20150430173706.5677136.88463.21306@theqtcompany.com> References: , <20150430173706.5677136.88463.21306@theqtcompany.com> Message-ID: <5EF04C72-C1B6-460F-B6CE-84F199D2872D@edeltech.ch> Hi, It's back since 5.2 with an implementation for OS X waiting for Qt 5 (also for Qt 4 but since it's considered a new feature it won't get in) Samuel On 30 avr. 2015, at 19:37, Hausmann Simon wrote: > IMO this isn't a Qt bug, I commented on Jira. > > I suspect another app isn't implementing the protocol directly, but if we really want to protect ourselves then we should probably ditch the entire session management code from Qt 4 (it's gone in Qt 5, too :) > > Simon > > Original Message > From: Matthew Woehlke > Sent: Thursday, April 30, 2015 16:49 > To: development at qt-project.org > Cc: releasing at qt-project.org > Subject: Re: [Development] Qt 4.8.7 release candidate available > > > On 2015-04-30 09:17, Salovaara Akseli wrote: >> If blocker issues for Qt 4.8.7 release (i.e. new regression) are found please report those to bugreports.qt.io and raise issue also (with bug id) on releasing mailing list. > > Is there no hope for getting https://bugreports.qt.io/browse/QTBUG-38599 > fixed? This is a really nasty bug that cripples all (newly launched) Qt > applications when it happens. It's listed as P1 and has been reproduced, > but I don't know enough about the bowels of QSessionManager to suggest a > solution. > > KDE4 is likely to be around for a while yet (e.g. LTS distros) and it > would be good if this can be fixed. > > -- > Matthew > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development