From szehowe.koh at gmail.com Mon Nov 2 10:49:03 2015 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Mon, 2 Nov 2015 17:49:03 +0800 Subject: [Development] Old platform-specific functions In-Reply-To: References: Message-ID: On 10 October 2015 at 11:06, Sze Howe Koh wrote: > > On 16 September 2015 at 15:46, Jake Petroules > wrote: > > > On Sep 15, 2015, at 9:07 PM, Sze Howe Koh wrote: > > > > > > Hi all, > > > > > > There's a list of platform-specific functions from Qt 4: > > > http://doc.qt.io/qt-5/exportedfunctions.html > > > > > > It looks like most of these functions are now gone. The non-existing > > > functions should be removed from the documentation, but 3 functions > > > remain in the code base: > > > > > > * qt_mac_secure_keyboard() is marked Q_DEAD_CODE_FROM_QT4_MAC > > > (qlineedit.cpp) > > > > > > Maybe introduce a new function in QPA, exposed through QtMac namespace in > > QtMacExtras? > > > > > * qt_mac_set_dock_menu() is marked QT_DEPRECATED, and is slated for > > > removal in Qt 6 (qmenu.h) > > > > > > Replaced by QMenu::setAsDockMenu > > (http://doc.qt.io/qt-5/qmenu.html#setAsDockMenu) > > > > > * qt_set_sequence_auto_mnemonic() is not marked as dead/deprecated in any > > > way. > > > > > > Maybe introduce a new function on QShortcut that takes an enum (Auto, On, > > Off)? > > > > > > > Should any of these be left in the documentation? (Note that > > > qt_set_sequence_auto_mnemonic() is currently documented as a way to > > > get non-standard behaviour on OS X: > > > http://doc.qt.io/qt-5/qshortcut.html#details ) > > > Thanks for your input, Jake. I'll leave the decision about new > functions to the folks involved in GUI code; I'll just update the > documentation to reflect the current situation: > > https://codereview.qt-project.org/127249/ > https://codereview.qt-project.org/127250/ > https://bugreports.qt.io/browse/QTBUG-48693 > https://bugreports.qt.io/browse/QTBUG-48694 Bump. Would someone be willing to review and approve https://codereview.qt-project.org/127249/ ? (The other one has merged) Thanks, Sze-Howe From pgquiles at elpauer.org Mon Nov 2 20:44:49 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 2 Nov 2015 20:44:49 +0100 Subject: [Development] FOSDEM Desktops DevRoom 2016: Call for Participation Message-ID: FOSDEM Desktops DevRoom 2016 Call for Participation FOSDEM is one of the largest gatherings of Free Software contributors in the world and happens each February in Brussels (Belgium, Europe). One of the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop DevRoom”), which will host Desktop-related talks. We are now inviting proposals for talks about Free/Libre/Open-source Software on the topics of Desktop development, Desktop applications and interoperability amongst Desktop Environments. This is a unique opportunity to show novel ideas and developments to a wide technical audience. Topics accepted include, but are not limited to: - Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE, Cinnamon, ReactOS, etc - Closed desktops: Windows, Mac OS X, CDE, MorphOS, etc (when talking about a FLOSS topic) - Software development for the desktop - Development tools - Applications that enhance desktops - General desktop matters - Cross-platform software development - Web Talks can be very specific, such as the advantages/disadvantages of development with Qt on Wayland over X11/Mir; or as general as predictions for the fusion of Desktop and web in 5 years time. Topics that are of interest to the users and developers of all desktop environments are especially welcome. The FOSDEM 2015 schedule[1] might give you some inspiration. Submissions Please include the following information when submitting a proposal: - Your name - The title of your talk (please be descriptive, as titles will be listed with around 400 from other projects) - Short abstract of one or two paragraphs - Short bio (with photo) - Requested time: from 15 to 45 minutes. Normal duration is 30 minutes. Longer duration requests must be properly justified. You may be assigned LESS time than you request. How to submit All submissions are made in the Pentabarf event planning tool: https://penta.fosdem.org/submission/FOSDEM16 When submitting your talk, make sure to select the "Desktops" devroom as the "Track". Otherwise your talk will not be even considered for any devroom. If you already have a Pentabarf account from a previous year, even if your talk was not accepted, please reuse it. Create an account if, and only if, you don’t have one from a previous year. If you have any issues with Pentabarf, please contact pgquiles at elpauer dot org. Deadline The deadline for submissions is December 6th 2015. FOSDEM will be held on the weekend of January 30th and 31st 2015 and the Desktops DevRoom will take place on Sunday, January 31st 2015. We will contact every submitter with a "yes" or "no" before December 18th 2015. Recording permission The talks in the Desktops devroom will be audio and video recorded, and possibly streamed live too. By submitting a proposal you consent to be recorded and agree to license the content of your talk under a Creative Commons (CC-BY) license. If you want us to stop the recording in the Q & A part (should you have one), please tell us. We can do that but only for the Q & A part. More information The official communication channel for the Desktops DevRoom is its mailing list desktops-devroom at lists.fosdem.org. Use this page to manage your subscription: https://lists.fosdem.org/listinfo/desktops-devroom Organization The Desktops DevRoom 2016 is managed by a team representing the most notable open desktops: - Pau Garcia i Quiles, KDE - Christophe Fergeau, Gnome - Michael Zanetti, Unity - Philippe Caseiro, Enlightenment - Jérome Leclanche, Razor If you want to join the team, please contact pgquiles at elpauer dot org -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Tue Nov 3 13:06:16 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Tue, 3 Nov 2015 12:06:16 +0000 Subject: [Development] New Qt 5.6.0 Beta snapshot available Message-ID: Hi all, We have new Qt 5.6.0 beta snapshot available, Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/241/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/265/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/198/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Please test these packages carefully and inform me immediately all beta blockers which aren't already linked in https://bugreports.qt.io/browse/QTBUG-47958 . br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at theqtcompany.com Tue Nov 3 15:28:13 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Tue, 3 Nov 2015 14:28:13 +0000 Subject: [Development] How does mktime() handle DST transitions ? Message-ID: Hi all, I'm looking into QTBUG-49008 and need to work out how diverse implementations of mktime handle DST transitions: at one end of the year there's a gap (where 1:59 is followed by 3:00), at the other end there's a duplicated hour (where 2:59 is followed by a reprise of 2:00 in Europe, or 1:59 by 1:00 in the USA, IIUC). While we still need to work out what behaviour *we* want to give, implementing it is going to depend on knowing what the platform mktime gives us to work with. I know glibc's behaviour (2.19-22), although confirmation of it from elsewhere and version variation may be worth knowing. We have a kludge for MS-Win that suggests what it does (actually quite sensible, though different to GNU), but I'd be glad of confirmation. The 'net suggests FreeBSD may even treat some of it as errors; I may need to follow up on that, and on Mac. So I wrote a simple test program. If you're willing to compile and run the attached simple C program, please let me know its output and your platform's details - ideally off-list - I'll give a summary in a few days' time. Those not in Europe shall need to amend the data in two statics at the top of the file (there are comments to guide you) to hit when your DST transitions are. (I'd also be glad to know what those are, if you include a diff.) Eddy. -------------- next part -------------- A non-text attachment was scrubbed... Name: mktime.c Type: text/x-csrc Size: 1978 bytes Desc: mktime.c URL: From massimocallegari at yahoo.it Wed Nov 4 14:16:48 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 4 Nov 2015 13:16:48 +0000 (UTC) Subject: [Development] Bit of help for QtWayland on a Raspberry Pi References: <327426126.3228940.1446643008749.JavaMail.yahoo@mail.yahoo.com> Message-ID: <327426126.3228940.1446643008749.JavaMail.yahoo@mail.yahoo.com> Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. Turns out that I can't compile QtWayland examples cause the compositor module is not built. According to the README, the following packages are needed: xkbcommon 0.2.0 - http://xkbcommon.org/ wayland 1.2.0 - http://wayland.freedesktop.org/ And this is what I have in my environment: pi at raspberrypi ~ $ dpkg -l | grep xkb ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data pi at raspberrypi ~ $ dpkg -l | grep wayland ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: xkbcommon-x11........... no xkbcommon-evdev......... no I've had a look at how the detection is performed and it's basically: pkg-config --exists xkbcommon If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. I suspect I'm missing a package but I can't figure out which one. Any help is appreciated. Thanks, Massimo From giuliocamuffo at gmail.com Wed Nov 4 15:04:03 2015 From: giuliocamuffo at gmail.com (Giulio Camuffo) Date: Wed, 4 Nov 2015 16:04:03 +0200 Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: <327426126.3228940.1446643008749.JavaMail.yahoo@mail.yahoo.com> References: <327426126.3228940.1446643008749.JavaMail.yahoo@mail.yahoo.com> <327426126.3228940.1446643008749.JavaMail.yahoo@mail.yahoo.com> Message-ID: 2015-11-04 15:16 GMT+02:00 Massimo Callegari : > Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. > > I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. > Turns out that I can't compile QtWayland examples cause the compositor module is not built. > > According to the README, the following packages are needed: > > xkbcommon 0.2.0 - http://xkbcommon.org/ > wayland 1.2.0 - http://wayland.freedesktop.org/ > > And this is what I have in my environment: > > pi at raspberrypi ~ $ dpkg -l | grep xkb > ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files > ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library > ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library > ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities > ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data > > pi at raspberrypi ~ $ dpkg -l | grep wayland > ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries > ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library > ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library > ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library > ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library > ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library > ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files > ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library > rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries > > Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: > > xkbcommon-x11........... no > xkbcommon-evdev......... no > > > I've had a look at how the detection is performed and it's basically: > pkg-config --exists xkbcommon > > If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. A return status of 0 means that it was found. What is the actual error you're hitting? Note that qtwayland can also be built without xkbcommon. -- Giulio > > I suspect I'm missing a package but I can't figure out which one. > > Any help is appreciated. > > Thanks, > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Nov 4 15:23:53 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 04 Nov 2015 09:23:53 -0500 Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: References: <327426126.3228940.1446643008749.JavaMail.yahoo@mail.yahoo.com> Message-ID: <9216404.M8D3cYGBaa@tjmaciei-mobl4> On Wednesday 04 November 2015 16:04:03 Giulio Camuffo wrote: > > Apparently, the problem is in the detection of xkbcommon, cause the > > configure summary says this: > > > > xkbcommon-x11........... no > > xkbcommon-evdev......... no > > > > > > I've had a look at how the detection is performed and it's basically: > > pkg-config --exists xkbcommon > > > > If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. > > A return status of 0 means that it was found. What is the actual error > you're hitting? Note that qtwayland can also be built without > xkbcommon. Please check the config.log file. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From albert.astals at canonical.com Wed Nov 4 15:31:46 2015 From: albert.astals at canonical.com (Albert Astals Cid) Date: Wed, 4 Nov 2015 15:31:46 +0100 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: References: Message-ID: On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars wrote: > Qt 5.6: > > * We make 5.6 a long term supported release Any plan on how long will be that "long term"? 2 years? 5 years? Cheers, Albert From massimocallegari at yahoo.it Wed Nov 4 15:33:09 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 4 Nov 2015 14:33:09 +0000 (UTC) Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: References: Message-ID: <1680579704.3289360.1446647589557.JavaMail.yahoo@mail.yahoo.com> > A return status of 0 means that it was found. What is the actual error > you're hitting? Note that qtwayland can also be built without > xkbcommon. My problem was the compositor library not built. Then I read the README harder and built it with CONFIG+=wayland-compositor Now I (should) have all the libraries and plugins in place. So I tried to launch qwindow-compositor like this: export XDG_RUNTIME_DIR="/var/run" QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=brcm ./qwindow-compositor The output is: Unable to query physical screen size, defaulting to 100 dpi. To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). using socket /var/run/wayland-0 QPainter::begin: Paint device returned engine == 0, type: 3 And nothing else. I see no changes on the screen. If I launch a Qt application with -platform wayland, it gets stuck and it is not rendered on screen. Any clue ? Thanks ----- Messaggio originale ----- Da: Giulio Camuffo A: Massimo Callegari Cc: "development at qt-project.org" Inviato: Mercoledì 4 Novembre 2015 15:04 Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi 2015-11-04 15:16 GMT+02:00 Massimo Callegari : > Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. > > I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. > Turns out that I can't compile QtWayland examples cause the compositor module is not built. > > According to the README, the following packages are needed: > > xkbcommon 0.2.0 - http://xkbcommon.org/ > wayland 1.2.0 - http://wayland.freedesktop.org/ > > And this is what I have in my environment: > > pi at raspberrypi ~ $ dpkg -l | grep xkb > ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files > ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library > ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library > ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities > ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data > > pi at raspberrypi ~ $ dpkg -l | grep wayland > ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries > ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library > ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library > ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library > ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library > ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library > ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files > ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library > rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries > > Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: > > xkbcommon-x11........... no > xkbcommon-evdev......... no > > > I've had a look at how the detection is performed and it's basically: > pkg-config --exists xkbcommon > > If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. A return status of 0 means that it was found. What is the actual error you're hitting? Note that qtwayland can also be built without xkbcommon. -- Giulio > > I suspect I'm missing a package but I can't figure out which one. > > Any help is appreciated. > > Thanks, > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From massimocallegari at yahoo.it Wed Nov 4 15:50:39 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 4 Nov 2015 14:50:39 +0000 (UTC) Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: <9216404.M8D3cYGBaa@tjmaciei-mobl4> References: <9216404.M8D3cYGBaa@tjmaciei-mobl4> Message-ID: <704288548.3358308.1446648639441.JavaMail.yahoo@mail.yahoo.com> > On Wednesday 04 November 2015 16:04:03 Giulio Camuffo wrote: > > > Apparently, the problem is in the detection of xkbcommon, cause the > > > configure summary says this: > > > > > > xkbcommon-x11........... no > > > xkbcommon-evdev......... no > > > > > > > > > I've had a look at how the detection is performed and it's basically: > > > pkg-config --exists xkbcommon > > > > > > If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. > > > > A return status of 0 means that it was found. What is the actual error > > you're hitting? Note that qtwayland can also be built without > > xkbcommon. > Please check the config.log file. qtbase doesn't have a config.log file. I have them only in qtmultimedia, qt3d, qtwayland, qtimageformats and qtconnectivity _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From massimocallegari at yahoo.it Wed Nov 4 16:33:55 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 4 Nov 2015 15:33:55 +0000 (UTC) Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: <1680579704.3289360.1446647589557.JavaMail.yahoo@mail.yahoo.com> References: <1680579704.3289360.1446647589557.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1981821670.3333209.1446651235626.JavaMail.yahoo@mail.yahoo.com> I kind of solved the main issue ! Turned out I didn't have libjpeg installed in my target system (which is different from my dev system) Basically the method QWindowCompositor::makeBackgroundImage looped indefinitely cause QImage returned a 0,0 size of background.jpg. Maybe an extra check would help there :) Now I can launch Qt apps on the compositor, but they're not decorated, so I cannot move them around. That's my ultimate goal actually. I tried to export the use of a client decoration like this: QT_WAYLAND_DECORATION=bradient ./hellowindow -platform wayland --single But no window decoration. The libbradient.so plugin is there but apparently it's not picked up. Or aren't decorations supported at all on the brcm integration ? ----- Messaggio originale ----- Da: Massimo Callegari A: Giulio Camuffo Cc: "development at qt-project.org" Inviato: Mercoledì 4 Novembre 2015 15:33 Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi > A return status of 0 means that it was found. What is the actual error > you're hitting? Note that qtwayland can also be built without > xkbcommon. My problem was the compositor library not built. Then I read the README harder and built it with CONFIG+=wayland-compositor Now I (should) have all the libraries and plugins in place. So I tried to launch qwindow-compositor like this: export XDG_RUNTIME_DIR="/var/run" QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=brcm ./qwindow-compositor The output is: Unable to query physical screen size, defaulting to 100 dpi. To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). using socket /var/run/wayland-0 QPainter::begin: Paint device returned engine == 0, type: 3 And nothing else. I see no changes on the screen. If I launch a Qt application with -platform wayland, it gets stuck and it is not rendered on screen. Any clue ? Thanks ----- Messaggio originale ----- Da: Giulio Camuffo A: Massimo Callegari Cc: "development at qt-project.org" Inviato: Mercoledì 4 Novembre 2015 15:04 Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi 2015-11-04 15:16 GMT+02:00 Massimo Callegari : > Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. > > I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. > Turns out that I can't compile QtWayland examples cause the compositor module is not built. > > According to the README, the following packages are needed: > > xkbcommon 0.2.0 - http://xkbcommon.org/ > wayland 1.2.0 - http://wayland.freedesktop.org/ > > And this is what I have in my environment: > > pi at raspberrypi ~ $ dpkg -l | grep xkb > ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files > ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library > ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library > ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities > ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data > > pi at raspberrypi ~ $ dpkg -l | grep wayland > ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries > ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library > ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library > ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library > ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library > ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library > ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files > ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library > rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries > > Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: > > xkbcommon-x11........... no > xkbcommon-evdev......... no > > > I've had a look at how the detection is performed and it's basically: > pkg-config --exists xkbcommon > > If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. A return status of 0 means that it was found. What is the actual error you're hitting? Note that qtwayland can also be built without xkbcommon. -- Giulio > > I suspect I'm missing a package but I can't figure out which one. > > Any help is appreciated. > > Thanks, > Massimo > _______________________________________________ > 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 giuliocamuffo at gmail.com Wed Nov 4 16:38:41 2015 From: giuliocamuffo at gmail.com (Giulio Camuffo) Date: Wed, 4 Nov 2015 17:38:41 +0200 Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: <1981821670.3333209.1446651235626.JavaMail.yahoo@mail.yahoo.com> References: <1680579704.3289360.1446647589557.JavaMail.yahoo@mail.yahoo.com> <1981821670.3333209.1446651235626.JavaMail.yahoo@mail.yahoo.com> Message-ID: 2015-11-04 17:33 GMT+02:00 Massimo Callegari : > I kind of solved the main issue ! > Turned out I didn't have libjpeg installed in my target system (which is different from my dev system) > > Basically the method QWindowCompositor::makeBackgroundImage looped indefinitely cause QImage returned a 0,0 size of background.jpg. > Maybe an extra check would help there :) > > Now I can launch Qt apps on the compositor, but they're not decorated, so I cannot move them around. > That's my ultimate goal actually. > > I tried to export the use of a client decoration like this: > QT_WAYLAND_DECORATION=bradient ./hellowindow -platform wayland --single > > But no window decoration. The libbradient.so plugin is there but apparently it's not picked up. > > Or aren't decorations supported at all on the brcm integration ? Indeed they aren't on GL windows. The goal with decorations is to move them to subsurfaces and just draw them with SHM, so we don't need to do hacks for GL windows like we do in the wayland-egl hardwareintegration. -- Giulio > > > > ----- Messaggio originale ----- > Da: Massimo Callegari > A: Giulio Camuffo > Cc: "development at qt-project.org" > Inviato: Mercoledì 4 Novembre 2015 15:33 > Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi > >> A return status of 0 means that it was found. What is the actual error >> you're hitting? Note that qtwayland can also be built without >> xkbcommon. > > My problem was the compositor library not built. Then I read the README harder and built it with CONFIG+=wayland-compositor > > Now I (should) have all the libraries and plugins in place. So I tried to launch qwindow-compositor like this: > > export XDG_RUNTIME_DIR="/var/run" > QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=brcm ./qwindow-compositor > > The output is: > Unable to query physical screen size, defaulting to 100 dpi. > To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). > using socket /var/run/wayland-0 > QPainter::begin: Paint device returned engine == 0, type: 3 > > And nothing else. I see no changes on the screen. > If I launch a Qt application with -platform wayland, it gets stuck and it is not rendered on screen. > > Any clue ? > Thanks > > > > ----- Messaggio originale ----- > Da: Giulio Camuffo > A: Massimo Callegari > Cc: "development at qt-project.org" > Inviato: Mercoledì 4 Novembre 2015 15:04 > Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi > > 2015-11-04 15:16 GMT+02:00 Massimo Callegari : >> Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. >> >> I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. >> Turns out that I can't compile QtWayland examples cause the compositor module is not built. >> >> According to the README, the following packages are needed: >> >> xkbcommon 0.2.0 - http://xkbcommon.org/ >> wayland 1.2.0 - http://wayland.freedesktop.org/ >> >> And this is what I have in my environment: >> >> pi at raspberrypi ~ $ dpkg -l | grep xkb >> ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files >> ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library >> ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library >> ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities >> ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data >> >> pi at raspberrypi ~ $ dpkg -l | grep wayland >> ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries >> ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library >> ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library >> ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library >> ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library >> ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library >> ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files >> ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library >> rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries >> >> Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: >> >> xkbcommon-x11........... no >> xkbcommon-evdev......... no >> >> >> I've had a look at how the detection is performed and it's basically: >> pkg-config --exists xkbcommon >> >> If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. > > A return status of 0 means that it was found. What is the actual error > you're hitting? Note that qtwayland can also be built without > xkbcommon. > > > -- > Giulio > > >> >> I suspect I'm missing a package but I can't figure out which one. >> >> Any help is appreciated. >> >> Thanks, >> Massimo >> _______________________________________________ >> 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 massimocallegari at yahoo.it Wed Nov 4 16:55:17 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 4 Nov 2015 15:55:17 +0000 (UTC) Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: References: Message-ID: <2037165280.3414956.1446652517222.JavaMail.yahoo@mail.yahoo.com> ----- Messaggio originale ----- Da: Giulio Camuffo A: Massimo Callegari Cc: "development at qt-project.org" Inviato: Mercoledì 4 Novembre 2015 16:38 Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi 2015-11-04 17:33 GMT+02:00 Massimo Callegari : > I kind of solved the main issue ! > Turned out I didn't have libjpeg installed in my target system (which is different from my dev system) > > Basically the method QWindowCompositor::makeBackgroundImage looped indefinitely cause QImage returned a 0,0 size of background.jpg. > Maybe an extra check would help there :) > > Now I can launch Qt apps on the compositor, but they're not decorated, so I cannot move them around. > That's my ultimate goal actually. > > I tried to export the use of a client decoration like this: > QT_WAYLAND_DECORATION=bradient ./hellowindow -platform wayland --single > > But no window decoration. The libbradient.so plugin is there but apparently it's not picked up. > > Or aren't decorations supported at all on the brcm integration ? > Indeed they aren't on GL windows. The goal with decorations is to move > them to subsurfaces and just draw them with SHM, so we don't need to > do hacks for GL windows like we do in the wayland-egl > hardwareintegration. So what's the whole point of having a compositor if you cannot do anything on windows ? Can windows+decorations be treated like GL textures as part of the same GL window ? I'm really starting to miss what we had with QWS in Qt4. There are too many limitations on the EGLFS QPA (see also QtMultimedia) and on embedded systems one cannot afford to have a full Xorg instance running. > > > > ----- Messaggio originale ----- > Da: Massimo Callegari > A: Giulio Camuffo > Cc: "development at qt-project.org" > Inviato: Mercoledì 4 Novembre 2015 15:33 > Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi > >> A return status of 0 means that it was found. What is the actual error >> you're hitting? Note that qtwayland can also be built without >> xkbcommon. > > My problem was the compositor library not built. Then I read the README harder and built it with CONFIG+=wayland-compositor > > Now I (should) have all the libraries and plugins in place. So I tried to launch qwindow-compositor like this: > > export XDG_RUNTIME_DIR="/var/run" > QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=brcm ./qwindow-compositor > > The output is: > Unable to query physical screen size, defaulting to 100 dpi. > To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). > using socket /var/run/wayland-0 > QPainter::begin: Paint device returned engine == 0, type: 3 > > And nothing else. I see no changes on the screen. > If I launch a Qt application with -platform wayland, it gets stuck and it is not rendered on screen. > > Any clue ? > Thanks > > > > ----- Messaggio originale ----- > Da: Giulio Camuffo > A: Massimo Callegari > Cc: "development at qt-project.org" > Inviato: Mercoledì 4 Novembre 2015 15:04 > Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi > > 2015-11-04 15:16 GMT+02:00 Massimo Callegari : >> Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. >> >> I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. >> Turns out that I can't compile QtWayland examples cause the compositor module is not built. >> >> According to the README, the following packages are needed: >> >> xkbcommon 0.2.0 - http://xkbcommon.org/ >> wayland 1.2.0 - http://wayland.freedesktop.org/ >> >> And this is what I have in my environment: >> >> pi at raspberrypi ~ $ dpkg -l | grep xkb >> ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files >> ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library >> ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library >> ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities >> ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data >> >> pi at raspberrypi ~ $ dpkg -l | grep wayland >> ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries >> ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library >> ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library >> ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library >> ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library >> ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library >> ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files >> ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library >> rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries >> >> Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: >> >> xkbcommon-x11........... no >> xkbcommon-evdev......... no >> >> >> I've had a look at how the detection is performed and it's basically: >> pkg-config --exists xkbcommon >> >> If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. > > A return status of 0 means that it was found. What is the actual error > you're hitting? Note that qtwayland can also be built without > xkbcommon. > > > -- > Giulio > > >> >> I suspect I'm missing a package but I can't figure out which one. >> >> Any help is appreciated. >> >> Thanks, >> Massimo >> _______________________________________________ >> 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 giuliocamuffo at gmail.com Wed Nov 4 17:46:50 2015 From: giuliocamuffo at gmail.com (Giulio Camuffo) Date: Wed, 4 Nov 2015 18:46:50 +0200 Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: <2037165280.3414956.1446652517222.JavaMail.yahoo@mail.yahoo.com> References: <2037165280.3414956.1446652517222.JavaMail.yahoo@mail.yahoo.com> Message-ID: 2015-11-04 17:55 GMT+02:00 Massimo Callegari : > > > > > ----- Messaggio originale ----- > Da: Giulio Camuffo > A: Massimo Callegari > Cc: "development at qt-project.org" > Inviato: Mercoledì 4 Novembre 2015 16:38 > Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi > > 2015-11-04 17:33 GMT+02:00 Massimo Callegari : >> I kind of solved the main issue ! >> Turned out I didn't have libjpeg installed in my target system (which is different from my dev system) >> >> Basically the method QWindowCompositor::makeBackgroundImage looped indefinitely cause QImage returned a 0,0 size of background.jpg. >> Maybe an extra check would help there :) >> >> Now I can launch Qt apps on the compositor, but they're not decorated, so I cannot move them around. >> That's my ultimate goal actually. >> >> I tried to export the use of a client decoration like this: >> QT_WAYLAND_DECORATION=bradient ./hellowindow -platform wayland --single >> >> But no window decoration. The libbradient.so plugin is there but apparently it's not picked up. >> >> Or aren't decorations supported at all on the brcm integration ? > >> Indeed they aren't on GL windows. The goal with decorations is to move >> them to subsurfaces and just draw them with SHM, so we don't need to >> do hacks for GL windows like we do in the wayland-egl >> hardwareintegration. > > So what's the whole point of having a compositor if you cannot do anything on windows ? What do you mean? You don't need decorations to interact with windows, though they are surely useful. > Can windows+decorations be treated like GL textures as part of the same GL window ? Yes, that's what the wayland-egl plugin does, but as i said it's an hack that nobody bothered to port to brcm, because it fiddles with the GL context state, and that's a thing applications don't usually like. The subsurface approach will fix this problem, i may have something working in a few days. > > I'm really starting to miss what we had with QWS in Qt4. There are too many limitations on the EGLFS QPA (see also QtMultimedia) and on embedded systems one cannot afford to have a full Xorg instance running. > > > >> >> >> >> ----- Messaggio originale ----- >> Da: Massimo Callegari >> A: Giulio Camuffo >> Cc: "development at qt-project.org" >> Inviato: Mercoledì 4 Novembre 2015 15:33 >> Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi >> >>> A return status of 0 means that it was found. What is the actual error >>> you're hitting? Note that qtwayland can also be built without >>> xkbcommon. >> >> My problem was the compositor library not built. Then I read the README harder and built it with CONFIG+=wayland-compositor >> >> Now I (should) have all the libraries and plugins in place. So I tried to launch qwindow-compositor like this: >> >> export XDG_RUNTIME_DIR="/var/run" >> QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=brcm ./qwindow-compositor >> >> The output is: >> Unable to query physical screen size, defaulting to 100 dpi. >> To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). >> using socket /var/run/wayland-0 >> QPainter::begin: Paint device returned engine == 0, type: 3 >> >> And nothing else. I see no changes on the screen. >> If I launch a Qt application with -platform wayland, it gets stuck and it is not rendered on screen. >> >> Any clue ? >> Thanks >> >> >> >> ----- Messaggio originale ----- >> Da: Giulio Camuffo >> A: Massimo Callegari >> Cc: "development at qt-project.org" >> Inviato: Mercoledì 4 Novembre 2015 15:04 >> Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi >> >> 2015-11-04 15:16 GMT+02:00 Massimo Callegari : >>> Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. >>> >>> I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. >>> Turns out that I can't compile QtWayland examples cause the compositor module is not built. >>> >>> According to the README, the following packages are needed: >>> >>> xkbcommon 0.2.0 - http://xkbcommon.org/ >>> wayland 1.2.0 - http://wayland.freedesktop.org/ >>> >>> And this is what I have in my environment: >>> >>> pi at raspberrypi ~ $ dpkg -l | grep xkb >>> ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files >>> ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library >>> ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library >>> ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities >>> ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data >>> >>> pi at raspberrypi ~ $ dpkg -l | grep wayland >>> ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries >>> ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library >>> ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library >>> ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library >>> ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library >>> ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library >>> ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files >>> ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library >>> rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries >>> >>> Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: >>> >>> xkbcommon-x11........... no >>> xkbcommon-evdev......... no >>> >>> >>> I've had a look at how the detection is performed and it's basically: >>> pkg-config --exists xkbcommon >>> >>> If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. >> >> A return status of 0 means that it was found. What is the actual error >> you're hitting? Note that qtwayland can also be built without >> xkbcommon. >> >> >> -- >> Giulio >> >> >>> >>> I suspect I'm missing a package but I can't figure out which one. >>> >>> Any help is appreciated. >>> >>> Thanks, >>> Massimo >>> _______________________________________________ >>> 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 Wed Nov 4 17:50:41 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 04 Nov 2015 11:50:41 -0500 Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: <704288548.3358308.1446648639441.JavaMail.yahoo@mail.yahoo.com> References: <9216404.M8D3cYGBaa@tjmaciei-mobl4> <704288548.3358308.1446648639441.JavaMail.yahoo@mail.yahoo.com> Message-ID: <6106125.uSUJ9kom4L@tjmaciei-mobl4> On Wednesday 04 November 2015 14:50:39 Massimo Callegari wrote: > > On Wednesday 04 November 2015 16:04:03 Giulio Camuffo wrote: > > > > Apparently, the problem is in the detection of xkbcommon, cause the > > > > configure summary says this: > > > > > > > > xkbcommon-x11........... no > > > > xkbcommon-evdev......... no > > > > > > > > > > > > I've had a look at how the detection is performed and it's basically: > > > > pkg-config --exists xkbcommon > > > > > > > > If I run it on my PC it returns 1, while on the Raspberry Pi it > > > > returns 0. > > > > > > A return status of 0 means that it was found. What is the actual error > > > you're hitting? Note that qtwayland can also be built without > > > xkbcommon. > > > > Please check the config.log file. > > qtbase doesn't have a config.log file. > I have them only in qtmultimedia, qt3d, qtwayland, qtimageformats and > qtconnectivity Oh, I thought that was from running qmake in qtwayland. Run configure with -v and it should give you more information. Also note that the check for xkbcommon-x11 is inside the XCB block. So if you turned XCB off, you won't get xkbcommon. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jtranter at ics.com Wed Nov 4 19:17:04 2015 From: jtranter at ics.com (Jeff Tranter) Date: Wed, 4 Nov 2015 13:17:04 -0500 Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: References: <2037165280.3414956.1446652517222.JavaMail.yahoo@mail.yahoo.com> Message-ID: <563A4BA0.8000107@ics.com> If you get this working, can you update one or both of these Wiki pages? https://wiki.qt.io/Qtwayland https://wiki.qt.io/RaspberryPi I am sure there are other people who want to build and try this. On 15-11-04 11:46 AM, Giulio Camuffo wrote: > 2015-11-04 17:55 GMT+02:00 Massimo Callegari : >> >> >> >> >> ----- Messaggio originale ----- >> Da: Giulio Camuffo >> A: Massimo Callegari >> Cc: "development at qt-project.org" >> Inviato: Mercoledì 4 Novembre 2015 16:38 >> Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi >> >> 2015-11-04 17:33 GMT+02:00 Massimo Callegari : >>> I kind of solved the main issue ! >>> Turned out I didn't have libjpeg installed in my target system (which is different from my dev system) >>> >>> Basically the method QWindowCompositor::makeBackgroundImage looped indefinitely cause QImage returned a 0,0 size of background.jpg. >>> Maybe an extra check would help there :) >>> >>> Now I can launch Qt apps on the compositor, but they're not decorated, so I cannot move them around. >>> That's my ultimate goal actually. >>> >>> I tried to export the use of a client decoration like this: >>> QT_WAYLAND_DECORATION=bradient ./hellowindow -platform wayland --single >>> >>> But no window decoration. The libbradient.so plugin is there but apparently it's not picked up. >>> >>> Or aren't decorations supported at all on the brcm integration ? >> >>> Indeed they aren't on GL windows. The goal with decorations is to move >>> them to subsurfaces and just draw them with SHM, so we don't need to >>> do hacks for GL windows like we do in the wayland-egl >>> hardwareintegration. >> >> So what's the whole point of having a compositor if you cannot do anything on windows ? > > What do you mean? You don't need decorations to interact with windows, > though they are surely useful. > >> Can windows+decorations be treated like GL textures as part of the same GL window ? > > Yes, that's what the wayland-egl plugin does, but as i said it's an > hack that nobody bothered to port to brcm, because it fiddles with the > GL context state, and that's a thing applications don't usually like. > The subsurface approach will fix this problem, i may have something > working in a few days. > >> >> I'm really starting to miss what we had with QWS in Qt4. There are too many limitations on the EGLFS QPA (see also QtMultimedia) and on embedded systems one cannot afford to have a full Xorg instance running. >> >> >> >>> >>> >>> >>> ----- Messaggio originale ----- >>> Da: Massimo Callegari >>> A: Giulio Camuffo >>> Cc: "development at qt-project.org" >>> Inviato: Mercoledì 4 Novembre 2015 15:33 >>> Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi >>> >>>> A return status of 0 means that it was found. What is the actual error >>>> you're hitting? Note that qtwayland can also be built without >>>> xkbcommon. >>> >>> My problem was the compositor library not built. Then I read the README harder and built it with CONFIG+=wayland-compositor >>> >>> Now I (should) have all the libraries and plugins in place. So I tried to launch qwindow-compositor like this: >>> >>> export XDG_RUNTIME_DIR="/var/run" >>> QT_WAYLAND_CLIENT_BUFFER_INTEGRATION=brcm ./qwindow-compositor >>> >>> The output is: >>> Unable to query physical screen size, defaulting to 100 dpi. >>> To override, set QT_QPA_EGLFS_PHYSICAL_WIDTH and QT_QPA_EGLFS_PHYSICAL_HEIGHT (in millimeters). >>> using socket /var/run/wayland-0 >>> QPainter::begin: Paint device returned engine == 0, type: 3 >>> >>> And nothing else. I see no changes on the screen. >>> If I launch a Qt application with -platform wayland, it gets stuck and it is not rendered on screen. >>> >>> Any clue ? >>> Thanks >>> >>> >>> >>> ----- Messaggio originale ----- >>> Da: Giulio Camuffo >>> A: Massimo Callegari >>> Cc: "development at qt-project.org" >>> Inviato: Mercoledì 4 Novembre 2015 15:04 >>> Oggetto: Re: [Development] Bit of help for QtWayland on a Raspberry Pi >>> >>> 2015-11-04 15:16 GMT+02:00 Massimo Callegari : >>>> Hey devs, I am trying to run the QtWayland qwindow-compositor example on a Raspberry Pi. >>>> >>>> I have a Debian Wheezy development environment and I cross compile Qt 5.5.1 on my PC. >>>> Turns out that I can't compile QtWayland examples cause the compositor module is not built. >>>> >>>> According to the README, the following packages are needed: >>>> >>>> xkbcommon 0.2.0 - http://xkbcommon.org/ >>>> wayland 1.2.0 - http://wayland.freedesktop.org/ >>>> >>>> And this is what I have in my environment: >>>> >>>> pi at raspberrypi ~ $ dpkg -l | grep xkb >>>> ii libxkbcommon-dev 0.3.1-1rpi5 armhf library interface to the XKB compiler - development files >>>> ii libxkbcommon0:armhf 0.3.1-1rpi5 armhf library interface to the XKB compiler - shared library >>>> ii libxkbfile1:armhf 1:1.0.8-1 armhf X11 keyboard file manipulation library >>>> ii x11-xkb-utils 7.7~1 armhf X11 XKB utilities >>>> ii xkb-data 2.5.1-3 all X Keyboard Extension (XKB) configuration data >>>> >>>> pi at raspberrypi ~ $ dpkg -l | grep wayland >>>> ii libgail-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GNOME Accessibility Implementation Library -- shared libraries >>>> ii libgtk-3-0:armhf 3.10.2-1+rpi9+waylandrpi1 armhf GTK+ graphical user interface library >>>> ii libgtk-3-bin 3.10.2-1+rpi9+waylandrpi1 armhf programs for the GTK+ graphical user interface library >>>> ii libgtk-3-common 3.10.2-1+rpi9+waylandrpi1 all common files for the GTK+ graphical user interface library >>>> ii libwayland-client0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - client library >>>> ii libwayland-cursor0:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - cursor library >>>> ii libwayland-dev 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - development files >>>> ii libwayland-server0a:armhf 1.4.0+git-0rpi1rpi6 armhf wayland compositor infrastructure - server library >>>> rc libwayland0:armhf 1.1.0-0rpi1 armhf wayland compositor infrastructure - shared libraries >>>> >>>> Apparently, the problem is in the detection of xkbcommon, cause the configure summary says this: >>>> >>>> xkbcommon-x11........... no >>>> xkbcommon-evdev......... no >>>> >>>> >>>> I've had a look at how the detection is performed and it's basically: >>>> pkg-config --exists xkbcommon >>>> >>>> If I run it on my PC it returns 1, while on the Raspberry Pi it returns 0. >>> >>> A return status of 0 means that it was found. What is the actual error >>> you're hitting? Note that qtwayland can also be built without >>> xkbcommon. >>> >>> >>> -- >>> Giulio >>> >>> >>>> >>>> I suspect I'm missing a package but I can't figure out which one. >>>> >>>> Any help is appreciated. >>>> >>>> Thanks, >>>> Massimo >>>> _______________________________________________ >>>> 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 > -- Jeff Tranter, Engineering Manager, Integrated Computer Solutions. ICS - Delivering World-Class Applications for Embedded & Mobile Devices http://ics.com/services/ From kevin.kofler at chello.at Thu Nov 5 00:06:11 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 05 Nov 2015 00:06:11 +0100 Subject: [Development] How does mktime() handle DST transitions ? References: Message-ID: Welbourne Edward wrote: > I'm looking into QTBUG-49008 and need to work out how diverse > implementations of mktime handle DST transitions: at one end of the year > there's a gap (where 1:59 is followed by 3:00), at the other end there's > a duplicated hour (where 2:59 is followed by a reprise of 2:00 in > Europe, or 1:59 by 1:00 in the USA, IIUC). While we still need to work > out what behaviour *we* want to give, implementing it is going to depend > on knowing what the platform mktime gives us to work with. The EU actually defines the switchover time in UTC, so which hour is duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST. Kevin Kofler From filippocucchetto at gmail.com Thu Nov 5 00:49:54 2015 From: filippocucchetto at gmail.com (Filippo Cucchetto) Date: Thu, 5 Nov 2015 00:49:54 +0100 Subject: [Development] QtQuick wrong paint behaviour on window (and maybe other platforms) Message-ID: Hi all, i writing here for raising some warning on some severe rendering issue i'm seeing on windows with QtQuick when the window is resized: QTBUG-45105 QTBUG-49240 QTBUG-48235 I don't know who's the actual maintainer of this part of Qt, if there's any. I can also try to look at this issues myself i'm someone can guide me a little bit on the internals. i'm experiencing this problems with two different machines running windows 10 so seems pretty easy to reproduce them. -- Filippo Cucchetto -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlayt at kde.org Thu Nov 5 09:40:01 2015 From: jlayt at kde.org (John Layt) Date: Thu, 5 Nov 2015 08:40:01 +0000 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: Message-ID: On 3 November 2015 at 14:28, Welbourne Edward < edward.welbourne at theqtcompany.com> wrote: > Hi all, > > I'm looking into QTBUG-49008 and need to work out how diverse > implementations of mktime handle DST transitions: at one end of the year > there's a gap (where 1:59 is followed by 3:00), at the other end there's > a duplicated hour (where 2:59 is followed by a reprise of 2:00 in > Europe, or 1:59 by 1:00 in the USA, IIUC). While we still need to work > out what behaviour *we* want to give, implementing it is going to depend > on knowing what the platform mktime gives us to work with. > > I know glibc's behaviour (2.19-22), although confirmation of it from > elsewhere and version variation may be worth knowing. We have a kludge > for MS-Win that suggests what it does (actually quite sensible, though > different to GNU), but I'd be glad of confirmation. The 'net suggests > FreeBSD may even treat some of it as errors; I may need to follow up on > that, and on Mac. So I wrote a simple test program. > > If you're willing to compile and run the attached simple C program, > please let me know its output and your platform's details - ideally > off-list - I'll give a summary in a few days' time. Those not in Europe > shall need to amend the data in two statics at the top of the file > (there are comments to guide you) to hit when your DST transitions are. > (I'd also be glad to know what those are, if you include a diff.) > > Eddy. > Hi Eddy, I'm the original author of a lot of the current QDateTime/QTimeZone code, thanks for looking into this, I'm sadly not in a position these days to give much time to Qt. There's a serious problem with mktime() and ambiguous hours, i.e. the hour that gets repeated at daylight savings changeover. The root of the problem is that the C/POSIX spec doesn't define the correct behaviour, so every implementation decides what to do. I've previously documented the exact details in a previous email to the list a few years back which I can dig up if needed, but here's what I recall. On Windows they default to the second occurrence of the time. On Mac/BSD they default to the first occurrence, except on some versions where the first 43 or so minutes are the first occurrence and the rest are second occurrence! On GNU it just uses whatever the last time calculation had cached as the occurrence, or the first occurrence if nothing is cached, so is completely unreliable! On Windows mktime() in general use can also return different results than the higher level Win32 api. I concluded that we cannot reliably use mktime() for the ambiguous time conversions, or even in general cross-platform use. My conclusion was we needed to improve QTimeZone to be fast enough to replace mktime() if we wanted 100% reliable and compatible behaviour across all platforms. That may all have changed now we have more recent minimum versions of each OS. As a rule, I favour going with a default of assuming first occurrence, I think I found it easier to calculate from the tz database rules and slightly more logical. I've even got patches floating around trying different ways of implementing a clean API to control this based on the KDE api. I'll try have a look at the bug on the weekend, but I can't promise anything. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From massimocallegari at yahoo.it Thu Nov 5 10:46:35 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Thu, 5 Nov 2015 09:46:35 +0000 (UTC) Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: References: Message-ID: <367775213.186444.1446716795994.JavaMail.yahoo@mail.yahoo.com> >>> Indeed they aren't on GL windows. The goal with decorations is to move >>> them to subsurfaces and just draw them with SHM, so we don't need to >>> do hacks for GL windows like we do in the wayland-egl >>> hardwareintegration. >> >> So what's the whole point of having a compositor if you cannot do anything on windows ? > > What do you mean? You don't need decorations to interact with windows, > though they are surely useful. I mean from the user interaction perspective. Let's leave the compositing of multiple applications aside for a moment. Normally, a QtWidget application makes use of modal/non-modal windows to represent sub-areas of the software (e.g. configurations, preview, status, etc) If a window doesn't have the OK/Cancel buttons, then you need a window decoration to close it. Also, it might be necessary to move a sub-window around the screen to see what happened in the main window. There you need a title bar to get a grip to the window. Eventually QML has the same needs when using the Window item. In general, the point is that with QPA plugins like eglfs, linuxfb and wayland it is impossible to use Qt application in some cases. That was not the case with QWS, which provided a simple windowing system out of the box. I think it should be somehow considered to reintroduce QWS on top of QPA. So QPA plugins would be in charge of purely handling the hardware/protocols abstraction and QWS would be an optional layer adding the missing pieces to make an application usable on certain QPA (basically when the OS doesn't provide a window manager) >> Can windows+decorations be treated like GL textures as part of the same GL window ? > > Yes, that's what the wayland-egl plugin does, but as i said it's an > hack that nobody bothered to port to brcm, because it fiddles with the > GL context state, and that's a thing applications don't usually like. > The subsurface approach will fix this problem, i may have something > working in a few days. That would be great news for my use case ! If you want, I have a user on Gerrit, and in case I can make some tests on brcm-eglfs. Just add me to reviewers when the changeset is somehow usable. Thanks ! Massimo From edward.welbourne at theqtcompany.com Thu Nov 5 12:48:17 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 5 Nov 2015 11:48:17 +0000 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: , Message-ID: Hi John, I was hoping to hear from you - thanks for getting in touch. > I'm the original author of a lot of the current QDateTime/QTimeZone code, Indeed; git blame told me this and you'd shown up in my googling for references to the topic, which is why I've added you to some code-reviews. > I'm sadly not in a position these days to give much time to Qt. Fair enough. Any help you can give is, of course, welcome. > There's a serious problem with mktime() and ambiguous hours Indeed. Fortunately, this isn't the first time I've met it. If I were dictator of the world, DST would be abolished right away ! > The root of the problem is that the C/POSIX spec doesn't > define the correct behaviour, Indeed, although part of the problem is that it's not entirely clear what correct behaviour would be, regardless of spec. The python answer currently appeals to me - see links on the bug, when you find time. > I've previously documented the exact details in a previous > email to the list a few years back I may have found that, although I thought it was a blog post (mail archive software can confuse me that way). See links on bug. > On GNU it just uses whatever the last time calculation > had cached as the occurrence, Is that the .is_dst = -1 handling ? At least for the 0 or 1 handling, its behaviour is fairly straightforward - in the autumn overlap, it preserves the .is_dst, in the spring gap it flips the .is_dst and changes the hour in the way that matches that. For the limited testing I've done, the .is_dst = -1 has been to treat each the way it does when opting to set .is_dst (or leave it set, in autumn). Do you know what FreeBSD does ? I read some old posts that appeared to indicate it treated .is_dst = -1 as an error in the overlap and anything in the gap as an error. The FreeBSD maintainer appeared, back in 2000, to firmly believe this was The Right Thing To Do; and my understanding is that it's an entirely legitimate thing to do (wrt mktime's spec). I don't know if that's changed in the last fifteen years, though. > On Windows mktime() in general use can also return different > results than the higher level Win32 api. Do you remember whether the high-level one was any more helpful, sensible or predictable ? > I concluded that we cannot reliably use mktime() for the > ambiguous time conversions My main problem with it is *detecting* when we're in a transition; if we can do that, we can make up any rule we like and adjust suitably. I don't want the other > 99.96% of all hours to suffer any overhead, of course, which is what makes detection tricky. > or even in general cross-platform use. I'm reasonably confident I can work round the portability issues, as long as I have a reasonably good grasp of the kinds of variation that's out there. It helps that all cases for which I have reports so far - OSX, glibc, MS-Win - agree on what to do when .is_dst is either 0 or 1. The only variation at present is for .is_dst = -1. > My conclusion was we needed to improve QTimeZone to be fast enough to > replace mktime() if we wanted 100% reliable and compatible behaviour > across all platforms. OK, I guess I'd better take a close look at QTimeZone, then ;-) > As a rule, I favour going with a default of assuming first occurrence, > I think I found it easier to calculate from the tz database rules and > slightly more logical. That's reasonable for the (invalid) spring gap; but for the autumn overlap there are genuinely two distinct times and we really should have some way to represent them as distinct QDateTime objects. I presently rather like how python has resolved this. (Again, see links on bug.) > I've even got patches floating around trying different ways of > implementing a clean API to control this based on the KDE api. What is the KDE API ? Point me at a link if you can, or post one on the bug; I'd like to see what solutions have been tried, especially when I can get some insight into how well they've worked out. Naturally, I'd also like to make sure whatever we come up with is easy for KDE to use, too. > I'll try have a look at the bug on the weekend, but I can't promise anything. I quite understand - thanks for whatever time you can spare. I'm afraid my notes on the bug aren't terse ! Eddy. From edward.welbourne at theqtcompany.com Thu Nov 5 12:53:59 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 5 Nov 2015 11:53:59 +0000 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: , Message-ID: Kevin Kofler wrote: > The EU actually defines the switchover time in UTC, That's a surprise. Do you have a reference for that ? > so which hour is duplicated depends on the actual > time zone. It's the 3:mm hour in CET/CEST. I distinctly remember, the weekend before last, seeing the 2:mm hour duplicated, here in Oslo on CEST/CET. That's also the hour I'm used to being duplicated in the UK on BST/GMT, albeit I've been away for long enough they could have changed it without me noticing. Eddy. From andre at familiesomers.nl Thu Nov 5 13:10:33 2015 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 5 Nov 2015 13:10:33 +0100 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: Message-ID: <563B4739.3090105@familiesomers.nl> Op 5-11-2015 om 00:06 schreef Kevin Kofler: > Welbourne Edward wrote: >> I'm looking into QTBUG-49008 and need to work out how diverse >> implementations of mktime handle DST transitions: at one end of the year >> there's a gap (where 1:59 is followed by 3:00), at the other end there's >> a duplicated hour (where 2:59 is followed by a reprise of 2:00 in >> Europe, or 1:59 by 1:00 in the USA, IIUC). While we still need to work >> out what behaviour *we* want to give, implementing it is going to depend >> on knowing what the platform mktime gives us to work with. > The EU actually defines the switchover time in UTC, so which hour is > duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST. > > Nonsense*. I live in the CET (Netherlands), I am 100% sure that the hour duplicated is the 2:mm range, not the 3:mm range. At 03:00, the time is reset to 02:00 entering winter time again. That happened last October 25. Going to summer time, the hour skipped is the 2:mm range also. André *) At least in so far the actual clock time in the country is concerned. Perhaps for other purposes the EU defines a single switchover moment for the whole of the EU? That is pure speculation though. From me at the-compiler.org Thu Nov 5 13:16:36 2015 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 5 Nov 2015 13:16:36 +0100 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: <563B4739.3090105@familiesomers.nl> References: <563B4739.3090105@familiesomers.nl> Message-ID: <20151105121636.GN5929@tonks> * André Somers [2015-11-05 13:10:33 +0100]: > Op 5-11-2015 om 00:06 schreef Kevin Kofler: > >Welbourne Edward wrote: > >>I'm looking into QTBUG-49008 and need to work out how diverse > >>implementations of mktime handle DST transitions: at one end of the year > >>there's a gap (where 1:59 is followed by 3:00), at the other end there's > >>a duplicated hour (where 2:59 is followed by a reprise of 2:00 in > >>Europe, or 1:59 by 1:00 in the USA, IIUC). While we still need to work > >>out what behaviour *we* want to give, implementing it is going to depend > >>on knowing what the platform mktime gives us to work with. > >The EU actually defines the switchover time in UTC, so which hour is > >duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST. > > > Nonsense*. I live in the CET (Netherlands), I am 100% sure that the hour > duplicated is the 2:mm range, not the 3:mm range. At 03:00, the time is > reset to 02:00 entering winter time again. That happened last October 25. > Going to summer time, the hour skipped is the 2:mm range also. While not in the EU, I can confirm what André said for Switzerland as well :) 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From thiago.macieira at intel.com Thu Nov 5 14:45:01 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 Nov 2015 08:45:01 -0500 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: <563B4739.3090105@familiesomers.nl> References: <563B4739.3090105@familiesomers.nl> Message-ID: <5010910.uxzotGGPIy@tjmaciei-mobl4> On Thursday 05 November 2015 13:10:33 André Somers wrote: > *) At least in so far the actual clock time in the country is concerned. > Perhaps for other purposes the EU defines a single switchover moment for > the whole of the EU? That is pure speculation though. Correct. In Finland, the clocks go back at 4:00 back to 3:00. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From andre at familiesomers.nl Thu Nov 5 14:54:04 2015 From: andre at familiesomers.nl (=?UTF-8?Q?Andr=c3=a9_Somers?=) Date: Thu, 5 Nov 2015 14:54:04 +0100 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: Message-ID: <563B5F7C.6070707@familiesomers.nl> Op 5-11-2015 om 00:06 schreef Kevin Kofler: > Welbourne Edward wrote: >> I'm looking into QTBUG-49008 and need to work out how diverse >> implementations of mktime handle DST transitions: at one end of the year >> there's a gap (where 1:59 is followed by 3:00), at the other end there's >> a duplicated hour (where 2:59 is followed by a reprise of 2:00 in >> Europe, or 1:59 by 1:00 in the USA, IIUC). While we still need to work >> out what behaviour *we* want to give, implementing it is going to depend >> on knowing what the platform mktime gives us to work with. > The EU actually defines the switchover time in UTC, so which hour is > duplicated depends on the actual time zone. It's the 3:mm hour in CET/CEST. Actually, you are right about the sync in the EU (for all clocks) and about the hour that is duplicated depending on the time zone, but I think you are off on the hour it happens. In CET it is 2:mm that is duplicated, in GMT and WET it is 1:mm and in finland (EET) it is 3:mm that is duplicated. See http://www.timeanddate.com/news/time/europe-dst-end-2015.html Interesting, I did not know that the summertime adjustment is synchronized in the EU. Interesting little factoid :-) André From thiago.macieira at intel.com Thu Nov 5 14:52:51 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 Nov 2015 08:52:51 -0500 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: <5010910.uxzotGGPIy@tjmaciei-mobl4> References: <563B4739.3090105@familiesomers.nl> <5010910.uxzotGGPIy@tjmaciei-mobl4> Message-ID: <2710905.9xuL1eF1v7@tjmaciei-mobl4> On Thursday 05 November 2015 08:45:01 Thiago Macieira wrote: > On Thursday 05 November 2015 13:10:33 André Somers wrote: > > *) At least in so far the actual clock time in the country is concerned. > > Perhaps for other purposes the EU defines a single switchover moment for > > the whole of the EU? That is pure speculation though. > > Correct. In Finland, the clocks go back at 4:00 back to 3:00. And in Portugal, at 2:00 they go back to 1:00. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Thu Nov 5 16:43:37 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 5 Nov 2015 16:43:37 +0100 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: <563B5F7C.6070707@familiesomers.nl> References: <563B5F7C.6070707@familiesomers.nl> Message-ID: <201511051643.37849.marc.mutz@kdab.com> On Thursday 05 November 2015 14:54:04 André Somers wrote: > Interesting, I did not know that the summertime adjustment is > synchronized in the EU. Interesting little factoid :-) The sole purpose of this being, of course, to prevent you from speeding with your car without penalty for more than just one hour, just by crossing into an adjacent TZ... -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts From kevin.kofler at chello.at Thu Nov 5 16:15:00 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Thu, 05 Nov 2015 16:15 +0100 Subject: [Development] How does mktime() handle DST transitions ? References: <563B5F7C.6070707@familiesomers.nl> Message-ID: André Somers wrote: > Actually, you are right about the sync in the EU (for all clocks) and > about the hour that is duplicated depending on the time zone, but I > think you are off on the hour it happens. In CET it is 2:mm that is > duplicated, in GMT and WET it is 1:mm and in finland (EET) it is 3:mm > that is duplicated. > > See > http://www.timeanddate.com/news/time/europe-dst-end-2015.html You're of course right. Sorry, I should have remembered the exact time, being up at that time more often than not and also having to deal with it in programming at times. Looks like I was just too tired when I wrote this. > Interesting, I did not know that the summertime adjustment is > synchronized in the EU. Interesting little factoid :-) Yes, and I felt it important to point this out, which is why I rushed to reply (and then screwed it up). Sorry for the misinformation, Kevin Kofler From thiago.macieira at intel.com Thu Nov 5 17:44:33 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 Nov 2015 11:44:33 -0500 Subject: [Development] RFD: plugins vs QStringLiterals Message-ID: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Proposal: force QStringLiteral uses to always address a heap-allocated QString, instead of pointing to the static data. Possibly, this should be an interned atom/quark à la GQuark, so two passes on the same QStringLiteral would result in the same heap pointers. Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not really unload. Maybe even QLibrary, if we find people use QLibrary to load Qt- based plugins instead of our own classes. Background: When we created QStringLiteral, we thought it was the best thing since sliced bread. We started using it everywhere and so did our users, after our recommendations. I even had a session in last years' Dev Days explaining when to use QStringLiteral and when not to. The objective of that session was to explain performance. The problem we're seeing is that it's quite easy to violate the precondition that the QStringLiteral never, ever disappears. This happens when plugins are involved. Any QStringLiteral in a plugin or in a library that gets loaded by that plugin is subject to disappearing before the end of the program. [Henceforth, "plugin" is "any dynamically loaded module, whether intended as a library or plugin, including all their dependencies that weren't loaded before"] I've said in the past that unloading plugins is a bad idea in C++. The case then was that it's easy to leave objects of a polymorphic class type whose virtual table is located in the unloaded plugin. This is not very different, since the QStringLiteral's data is also global data not expected to disappeaar. We've already worked around two cases of crash-at-exit caused by this, both coincidentally related to QtDBus's interface cache. But this can also happen for any other types of cache, like: QRegExp rx(QStringLiteral()); QPixmapCache::insert(QStringLiteral("foo"), px); What do we do then? 1) Declare it SEP and only apply workarounds for the places where QStringLiteral is used in our plugins, suggesting that people do the same in their plugins. Problems: libraries loaded by plugins, fragile. 2) Deep-copy the QStringLiterals a) with atom/quark b) without Problem: performance impact, complexity of the atom/quark solution. 3) Never unload any plugins, possibly also compiling our own libraries and plugins with -z nodelete. Solves most of the problems, including the C++ vtable case. Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls), prevents upgrading of plugins without restarting the host application. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at theqtcompany.com Thu Nov 5 17:57:49 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 5 Nov 2015 16:57:49 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <20151105165745.5918802.67634.47949@theqtcompany.com> And moc data is affected in a similar way. I continue to be in favor of (3) Simon Original Message From: Thiago Macieira Sent: Friday, November 6, 2015 00:44 To: development at qt-project.org Subject: [Development] RFD: plugins vs QStringLiterals Proposal: force QStringLiteral uses to always address a heap-allocated QString, instead of pointing to the static data. Possibly, this should be an interned atom/quark à la GQuark, so two passes on the same QStringLiteral would result in the same heap pointers. Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not really unload. Maybe even QLibrary, if we find people use QLibrary to load Qt- based plugins instead of our own classes. Background: When we created QStringLiteral, we thought it was the best thing since sliced bread. We started using it everywhere and so did our users, after our recommendations. I even had a session in last years' Dev Days explaining when to use QStringLiteral and when not to. The objective of that session was to explain performance. The problem we're seeing is that it's quite easy to violate the precondition that the QStringLiteral never, ever disappears. This happens when plugins are involved. Any QStringLiteral in a plugin or in a library that gets loaded by that plugin is subject to disappearing before the end of the program. [Henceforth, "plugin" is "any dynamically loaded module, whether intended as a library or plugin, including all their dependencies that weren't loaded before"] I've said in the past that unloading plugins is a bad idea in C++. The case then was that it's easy to leave objects of a polymorphic class type whose virtual table is located in the unloaded plugin. This is not very different, since the QStringLiteral's data is also global data not expected to disappeaar. We've already worked around two cases of crash-at-exit caused by this, both coincidentally related to QtDBus's interface cache. But this can also happen for any other types of cache, like: QRegExp rx(QStringLiteral()); QPixmapCache::insert(QStringLiteral("foo"), px); What do we do then? 1) Declare it SEP and only apply workarounds for the places where QStringLiteral is used in our plugins, suggesting that people do the same in their plugins. Problems: libraries loaded by plugins, fragile. 2) Deep-copy the QStringLiterals a) with atom/quark b) without Problem: performance impact, complexity of the atom/quark solution. 3) Never unload any plugins, possibly also compiling our own libraries and plugins with -z nodelete. Solves most of the problems, including the C++ vtable case. Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls), prevents upgrading of plugins without restarting the host application. -- 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 sergio.martins at kdab.com Thu Nov 5 18:02:25 2015 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 05 Nov 2015 17:02:25 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <6946309.ASoCuUn8e6@desktop> On Thursday, November 05, 2015 11:44:33 AM Thiago Macieira wrote: > Proposal: force QStringLiteral uses to always address a heap-allocated > QString, instead of pointing to the static data. Possibly, this should be an > interned atom/quark à la GQuark, so two passes on the same QStringLiteral > would result in the same heap pointers. > > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not > really unload. Maybe even QLibrary, if we find people use QLibrary to load > Qt- based plugins instead of our own classes. > > Background: > > When we created QStringLiteral, we thought it was the best thing since > sliced bread. We started using it everywhere and so did our users, after > our recommendations. I even had a session in last years' Dev Days > explaining when to use QStringLiteral and when not to. The objective of > that session was to explain performance. > > The problem we're seeing is that it's quite easy to violate the precondition > that the QStringLiteral never, ever disappears. This happens when plugins > are involved. Any QStringLiteral in a plugin or in a library that gets > loaded by that plugin is subject to disappearing before the end of the > program. > > [Henceforth, "plugin" is "any dynamically loaded module, whether intended as > a library or plugin, including all their dependencies that weren't loaded > before"] > > I've said in the past that unloading plugins is a bad idea in C++. The case > then was that it's easy to leave objects of a polymorphic class type whose > virtual table is located in the unloaded plugin. This is not very different, > since the QStringLiteral's data is also global data not expected to > disappeaar. > > We've already worked around two cases of crash-at-exit caused by this, both > coincidentally related to QtDBus's interface cache. But this can also happen > for any other types of cache, like: > > QRegExp rx(QStringLiteral()); > QPixmapCache::insert(QStringLiteral("foo"), px); > > What do we do then? > > 1) Declare it SEP and only apply workarounds for the places where > QStringLiteral is used in our plugins, suggesting that people do the same in > their plugins. +1 for SEP Document the circumstances where QSL might crash so the user can decide for himself what he values most. Customers will usually want stability, so they probably won't use QSL, but for many projects, like KDE, it's important to remove all those heap allocations and we tolerate a crash now and then. These crashes are very rare, and when they happen they are easy to diagnose and fix. Until now I've only seen the dbus crash you fixed and the QRegExp crash which I debugged in 15 minutes yesterday. > Problems: libraries loaded by plugins, fragile. > > 2) Deep-copy the QStringLiterals > a) with atom/quark > b) without > > Problem: performance impact, complexity of the atom/quark solution. -1 That defeats the purpose of QSL no ? > 3) Never unload any plugins, possibly also compiling our own libraries and > plugins with -z nodelete. Solves most of the problems, including the C++ > vtable case. > > Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls), > prevents upgrading of plugins without restarting the host application. +0 Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From oswald.buddenhagen at theqtcompany.com Thu Nov 5 18:13:36 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 5 Nov 2015 18:13:36 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <20151105171336.GB3927@troll08.it.local> On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote: > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not > really unload. > you already did that quite a while ago. was it reverted? or never integrated? > I've said in the past that unloading plugins is a bad idea in C++. The case > then was that it's easy to leave objects of a polymorphic class type whose > virtual table is located in the unloaded plugin. This is not very different, > since the QStringLiteral's data is also global data not expected to > disappeaar. > the generic c++ case isn't that bad, because the user can reasonably control the lifetime of objects and delete them before unloading associated plugins. obviously, qt's implicit sharing takes away this control, which is exactly the problem. > 2) Deep-copy the QStringLiterals > a) with atom/quark > this sounds like it could be quite horrible (when people rely on cheap instantiation, e.g., for comparisons). > b) without > > Problem: performance impact, complexity of the atom/quark solution. > to lessen the performance impact, we could have a #define to control the construction behavior of QSL at compile time. i'm not quite sure whether to make that opt-in or opt-out (safety vs. performance). From robin+qt at viroteck.net Thu Nov 5 18:23:37 2015 From: robin+qt at viroteck.net (Robin Burchell) Date: Thu, 05 Nov 2015 18:23:37 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <20151105171336.GB3927@troll08.it.local> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <20151105171336.GB3927@troll08.it.local> Message-ID: <1446744217.3302113.430206977.54DBB6DC@webmail.messagingengine.com> On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote: > > Problem: performance impact, complexity of the atom/quark solution. > > > to lessen the performance impact, we could have a #define to control the > construction behavior of QSL at compile time. i'm not quite sure whether > to make that opt-in or opt-out (safety vs. performance). Is the problem only apparent inside of plugins? Do we have a way to detect whether someone is building plugin code at build time? (CONFIG += plugin for qmake, I guess?) If so, couldn't the behaviour of QStringLiteral differ for code inside of plugins, to that outside of them? Robin From milian.wolff at kdab.com Thu Nov 5 18:23:49 2015 From: milian.wolff at kdab.com (Milian Wolff) Date: Thu, 05 Nov 2015 18:23:49 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <20151105171336.GB3927@troll08.it.local> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <20151105171336.GB3927@troll08.it.local> Message-ID: <2461360.X6WgcvV3Mx@agathebauer> On Donnerstag, 5. November 2015 18:13:36 CET Oswald Buddenhagen wrote: > On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote: > > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but > > not > > really unload. > > you already did that quite a while ago. was it reverted? or never > integrated? > > > I've said in the past that unloading plugins is a bad idea in C++. The > > case > > then was that it's easy to leave objects of a polymorphic class type whose > > virtual table is located in the unloaded plugin. This is not very > > different, since the QStringLiteral's data is also global data not > > expected to disappeaar. > > the generic c++ case isn't that bad, because the user can reasonably > control the lifetime of objects and delete them before unloading > associated plugins. > > obviously, qt's implicit sharing takes away this control, which is > exactly the problem. > > > 2) Deep-copy the QStringLiterals > > > > a) with atom/quark > > this sounds like it could be quite horrible (when people rely on cheap > instantiation, e.g., for comparisons). When you load a plugin, or compile a QRegExp, or use DBUS, or ... then the cost of these operations easily dwarfs the string heap allocation. So this is not that bad, imo. -- Milian Wolff | milian.wolff at kdab.com | 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: 5903 bytes Desc: not available URL: From pierluigi.fiorini at gmail.com Thu Nov 5 18:45:41 2015 From: pierluigi.fiorini at gmail.com (Pier Luigi Fiorini) Date: Thu, 5 Nov 2015 18:45:41 +0100 Subject: [Development] Bit of help for QtWayland on a Raspberry Pi In-Reply-To: <367775213.186444.1446716795994.JavaMail.yahoo@mail.yahoo.com> References: <367775213.186444.1446716795994.JavaMail.yahoo@mail.yahoo.com> Message-ID: 2015-11-05 10:46 GMT+01:00 Massimo Callegari : > >>> Indeed they aren't on GL windows. The goal with decorations is to move > >>> them to subsurfaces and just draw them with SHM, so we don't need to > >>> do hacks for GL windows like we do in the wayland-egl > >>> hardwareintegration. > >> > >> So what's the whole point of having a compositor if you cannot do > anything on windows ? > > > > What do you mean? You don't need decorations to interact with windows, > > though they are surely useful. > > I mean from the user interaction perspective. > Let's leave the compositing of multiple applications aside for a moment. > Normally, a QtWidget application makes use of modal/non-modal windows to > represent sub-areas of the software (e.g. configurations, preview, status, > etc) > If a window doesn't have the OK/Cancel buttons, then you need a window > decoration to close it. > Also, it might be necessary to move a sub-window around the screen to see > what happened in the main window. There you need a title bar to get a grip > to the window. > Eventually QML has the same needs when using the Window item. > > In general, the point is that with QPA plugins like eglfs, linuxfb and > wayland it is impossible to use Qt application in some cases. > That was not the case with QWS, which provided a simple windowing system > out of the box. > > I think it should be somehow considered to reintroduce QWS on top of QPA. > So QPA plugins would be in charge of purely handling the > hardware/protocols abstraction and QWS would be an optional layer adding > the missing pieces to make an application usable on certain QPA (basically > when the OS doesn't provide a window manager) > Window management is available with QtWayland, the client side decoration is missing only with the brcm hw integration as explained earlier by Giulio. > > > >> Can windows+decorations be treated like GL textures as part of the same > GL window ? > > > > Yes, that's what the wayland-egl plugin does, but as i said it's an > > hack that nobody bothered to port to brcm, because it fiddles with the > > GL context state, and that's a thing applications don't usually like. > > The subsurface approach will fix this problem, i may have something > > working in a few days. > > That would be great news for my use case ! > If you want, I have a user on Gerrit, and in case I can make some tests on > brcm-eglfs. Just add me to reviewers when the changeset is somehow usable. > > Thanks ! > Massimo > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Out of the box experience http://hawaiios.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From oswald.buddenhagen at theqtcompany.com Thu Nov 5 18:57:38 2015 From: oswald.buddenhagen at theqtcompany.com (Oswald Buddenhagen) Date: Thu, 5 Nov 2015 18:57:38 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2461360.X6WgcvV3Mx@agathebauer> <1446744217.3302113.430206977.54DBB6DC@webmail.messagingengine.com> Message-ID: <20151105175738.GA6297@troll08.it.local> On Thu, Nov 05, 2015 at 06:23:37PM +0100, Robin Burchell wrote: > On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote: > > > Problem: performance impact, complexity of the atom/quark solution. > > > > > to lessen the performance impact, we could have a #define to control the > > construction behavior of QSL at compile time. i'm not quite sure whether > > to make that opt-in or opt-out (safety vs. performance). > > Is the problem only apparent inside of plugins? Do we have a way to > detect whether someone is building plugin code at build time? (CONFIG += > plugin for qmake, I guess?) If so, couldn't the behaviour of > QStringLiteral differ for code inside of plugins, to that outside of > them? > you can also have plugin code which is perfectly safe. only a kinda perfect static analysis would give you a verdict about the safety of your code. On Thu, Nov 05, 2015 at 06:23:49PM +0100, Milian Wolff wrote: > On Donnerstag, 5. November 2015 18:13:36 CET Oswald Buddenhagen wrote: > > On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote: > > > 2) Deep-copy the QStringLiterals > > > > > > a) with atom/quark > > > > this sounds like it could be quite horrible (when people rely on cheap > > instantiation, e.g., for comparisons). > > When you load a plugin, or compile a QRegExp, or use DBUS, or ... then the > cost of these operations easily dwarfs the string heap allocation. So this is > not that bad, imo. > uhm, so? you can still do something "stupid" with QSL in a tight loop. From marc.mutz at kdab.com Thu Nov 5 21:06:20 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 5 Nov 2015 21:06:20 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <201511052106.20905.marc.mutz@kdab.com> On Thursday 05 November 2015 17:44:33 Thiago Macieira wrote: > Proposal: force QStringLiteral uses to always address a heap-allocated > QString, instead of pointing to the static data. Possibly, this should be > an interned atom/quark à la GQuark, so two passes on the same > QStringLiteral would result in the same heap pointers. TL;DR: what's atom/quark in this context? -- 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 Nov 5 21:11:58 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 5 Nov 2015 21:11:58 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2461360.X6WgcvV3Mx@agathebauer> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <20151105171336.GB3927@troll08.it.local> <2461360.X6WgcvV3Mx@agathebauer> Message-ID: <201511052111.58562.marc.mutz@kdab.com> On Thursday 05 November 2015 18:23:49 Milian Wolff wrote: > When you load a plugin, or compile a QRegExp, or use DBUS, or ... then the > cost of these operations easily dwarfs the string heap allocation. So this > is not that bad, imo. Making a nothrow operation throwing is bad. Avoiding heap allocations is not _just_ about performance.... -- 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 Nov 5 21:49:35 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 Nov 2015 15:49:35 -0500 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <20151105171336.GB3927@troll08.it.local> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <20151105171336.GB3927@troll08.it.local> Message-ID: <8719565.EgQ2tbCXuv@tjmaciei-mobl4> On Thursday 05 November 2015 18:13:36 Oswald Buddenhagen wrote: > On Thu, Nov 05, 2015 at 11:44:33AM -0500, Thiago Macieira wrote: > > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but > > not > > really unload. > > you already did that quite a while ago. was it reverted? or never > integrated? And I did. QPluginLoader does not really unload its plugins. QFactoryLoader still does. Don't ask me why we have two and one doesn't use the other. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 5 21:50:17 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 Nov 2015 15:50:17 -0500 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <1446744217.3302113.430206977.54DBB6DC@webmail.messagingengine.com> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <20151105171336.GB3927@troll08.it.local> <1446744217.3302113.430206977.54DBB6DC@webmail.messagingengine.com> Message-ID: <6723433.ntzkB7zmhd@tjmaciei-mobl4> On Thursday 05 November 2015 18:23:37 Robin Burchell wrote: > On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote: > > > Problem: performance impact, complexity of the atom/quark solution. > > > > to lessen the performance impact, we could have a #define to control the > > construction behavior of QSL at compile time. i'm not quite sure whether > > to make that opt-in or opt-out (safety vs. performance). > > Is the problem only apparent inside of plugins? Do we have a way to > detect whether someone is building plugin code at build time? (CONFIG += > plugin for qmake, I guess?) If so, couldn't the behaviour of > QStringLiteral differ for code inside of plugins, to that outside of > them? Plugins and any library loaded by plugins that hadn't been loaded before. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 5 21:55:29 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 Nov 2015 15:55:29 -0500 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <201511052106.20905.marc.mutz@kdab.com> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <201511052106.20905.marc.mutz@kdab.com> Message-ID: <2791242.0R77puoD7v@tjmaciei-mobl4> On Thursday 05 November 2015 21:06:20 Marc Mutz wrote: > On Thursday 05 November 2015 17:44:33 Thiago Macieira wrote: > > Proposal: force QStringLiteral uses to always address a heap-allocated > > QString, instead of pointing to the static data. Possibly, this should be > > an interned atom/quark à la GQuark, so two passes on the same > > QStringLiteral would result in the same heap pointers. > > TL;DR: what's atom/quark in this context? The documentation for XAtom and GQuark probably explains more. Basically it's a string that becomes managed by the library and for which a pointer comparison guarantees string comparison. str1 == str2 ←→ &str1 == &str2 Obviously this is more useful for when you have pointers (GQuark) or you have some other form of identifier (XAtom). The benefit for us is that it would allocate memory only on the first use. After that, it always returns the same pre-allocated string data. We'd implement it using a QSet. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 5 22:03:36 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 05 Nov 2015 16:03:36 -0500 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <6723433.ntzkB7zmhd@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <1446744217.3302113.430206977.54DBB6DC@webmail.messagingengine.com> <6723433.ntzkB7zmhd@tjmaciei-mobl4> Message-ID: <14670063.3zqCZgIpXW@tjmaciei-mobl4> On Thursday 05 November 2015 15:50:17 Thiago Macieira wrote: > On Thursday 05 November 2015 18:23:37 Robin Burchell wrote: > > On Thu, Nov 5, 2015, at 06:13 PM, Oswald Buddenhagen wrote: > > > > Problem: performance impact, complexity of the atom/quark solution. > > > > > > to lessen the performance impact, we could have a #define to control the > > > construction behavior of QSL at compile time. i'm not quite sure whether > > > to make that opt-in or opt-out (safety vs. performance). > > > > Is the problem only apparent inside of plugins? Do we have a way to > > detect whether someone is building plugin code at build time? (CONFIG += > > plugin for qmake, I guess?) If so, couldn't the behaviour of > > QStringLiteral differ for code inside of plugins, to that outside of > > them? > > Plugins and any library loaded by plugins that hadn't been loaded before. Q: How often does this happen? A: It happens for virtually EVERY GUI Qt application because QtGui loads all imageformat plugins, which means QtSvg gets loaded whether you wanted it or not. It happens again on XCB because the platform plugin links to its private QtXcbQpa library, which in turn links to QtDBus. It gets worse if you have KF5-based image format plugins, since kimg_eps.so links to QtPrintSupport. Fortunately, none of them today link to other KF5 libraries, but can we continue to count on that? Note: the imageformats are loaded via QPluginLoader, so they aren't unloaded. The QPA platform plugin is loaded via QFactoryLoader, so it gets unloaded. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From boud at valdyas.org Fri Nov 6 08:36:09 2015 From: boud at valdyas.org (Boudewijn Rempt) Date: Fri, 6 Nov 2015 08:36:09 +0100 (CET) Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <14670063.3zqCZgIpXW@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <1446744217.3302113.430206977.54DBB6DC@webmail.messagingengine.com> <6723433.ntzkB7zmhd@tjmaciei-mobl4> <14670063.3zqCZgIpXW@tjmaciei-mobl4> Message-ID: On Thu, 5 Nov 2015, Thiago Macieira wrote: > It gets worse if you have KF5-based image format plugins, since kimg_eps.so > links to QtPrintSupport. Fortunately, none of them today link to other KF5 > libraries, but can we continue to count on that? Well, the KRA and OpenRaster image format plugins that come with Krita need Kf5::Archive to open the zip files containers. At least they no longer link to krita's core libraries, lcms2 and all the rest. Boudewijn From jedrzej.nowacki at theqtcompany.com Fri Nov 6 08:49:04 2015 From: jedrzej.nowacki at theqtcompany.com (=?utf-8?B?SsSZZHJ6ZWo=?= Nowacki) Date: Fri, 6 Nov 2015 08:49:04 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <20151105165745.5918802.67634.47949@theqtcompany.com> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <20151105165745.5918802.67634.47949@theqtcompany.com> Message-ID: <2968146.rSi6pdxlQu@42> And every small, movable object kept in QVariant is affected. QMetaType also keeps pointers to functions defined in plugins if such register a type. I believe that we had that discussion around Qt4->Qt5 migration. Unloading plugins is not safe, sometimes it works but still it is very tricky. I agree with Simon and I'm in favor of 3. Cheers, Jędrek On Thursday 05 of November 2015 16:57:49 Hausmann Simon wrote: > And moc data is affected in a similar way. I continue to be in favor of (3) > > Simon > > Original Message > From: Thiago Macieira > Sent: Friday, November 6, 2015 00:44 > To: development at qt-project.org > Subject: [Development] RFD: plugins vs QStringLiterals > > > Proposal: force QStringLiteral uses to always address a heap-allocated > QString, instead of pointing to the static data. Possibly, this should be an > interned atom/quark à la GQuark, so two passes on the same QStringLiteral > would result in the same heap pointers. > > Alternative: force QPluginLoader / QFactoryLoader to fake unloading but not > really unload. Maybe even QLibrary, if we find people use QLibrary to load > Qt- based plugins instead of our own classes. > > Background: > > When we created QStringLiteral, we thought it was the best thing since > sliced bread. We started using it everywhere and so did our users, after > our recommendations. I even had a session in last years' Dev Days > explaining when to use QStringLiteral and when not to. The objective of > that session was to explain performance. > > The problem we're seeing is that it's quite easy to violate the precondition > that the QStringLiteral never, ever disappears. This happens when plugins > are involved. Any QStringLiteral in a plugin or in a library that gets > loaded by that plugin is subject to disappearing before the end of the > program. > > [Henceforth, "plugin" is "any dynamically loaded module, whether intended as > a library or plugin, including all their dependencies that weren't loaded > before"] > > I've said in the past that unloading plugins is a bad idea in C++. The case > then was that it's easy to leave objects of a polymorphic class type whose > virtual table is located in the unloaded plugin. This is not very different, > since the QStringLiteral's data is also global data not expected to > disappeaar. > > We've already worked around two cases of crash-at-exit caused by this, both > coincidentally related to QtDBus's interface cache. But this can also happen > for any other types of cache, like: > > QRegExp rx(QStringLiteral()); > QPixmapCache::insert(QStringLiteral("foo"), px); > > What do we do then? > > 1) Declare it SEP and only apply workarounds for the places where > QStringLiteral is used in our plugins, suggesting that people do the same in > their plugins. > > Problems: libraries loaded by plugins, fragile. > > 2) Deep-copy the QStringLiterals > a) with atom/quark > b) without > > Problem: performance impact, complexity of the atom/quark solution. > > 3) Never unload any plugins, possibly also compiling our own libraries and > plugins with -z nodelete. Solves most of the problems, including the C++ > vtable case. > > Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls), > prevents upgrading of plugins without restarting the host application. > > -- > 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 > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From edward.welbourne at theqtcompany.com Fri Nov 6 09:35:25 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Fri, 6 Nov 2015 08:35:25 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <6946309.ASoCuUn8e6@desktop> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4>,<6946309.ASoCuUn8e6@desktop> Message-ID: IIUC, the problem Thiago is discussing is a crash on exit(), or after main() has returned. This limits the scope of the problem (we don't make applications crashy while running), but only somewhat. There may be things in the application loading a plugin that rely on clean shutdown, including destructors of the application's globals, which may get skipped if a (long ago unloaded) plugin's globals cause a crash before the application's destructors get their turn. Thiago asked: >> What do we do then? >> >> 1) Declare it SEP and only apply workarounds for the places where >> QStringLiteral is used in our plugins, suggesting that people do the same in >> their plugins. On 05 November 2015 18:02, Sergio Martins replied: > +1 for SEP > Document the circumstances where QSL might crash so the user can > decide for himself what he values most. > > Customers will usually want stability, so they probably won't use QSL, > but for many projects, like KDE, it's important to remove all those > heap allocations and we tolerate a crash now and then. These crashes > are very rare, and when they happen they are easy to diagnose and > fix. Until now I've only seen the dbus crash you fixed and the QRegExp > crash which I debugged in 15 minutes yesterday. The problem with SEP is that it only works in so far as there *is* something the author of client code can do about the situation. They may not have enough choice to control this. Qt is a framework. It gets used in many ways. This makes it hard to say what options clients have - or don't have. In the end, SEP means telling some class of potential clients of Qt that Qt has made a design decision that means they have to use something other than Qt. The client code may be a plugin for an application that the plugin authors can't influence, that unloads whether the plugin authors like it or not. It is not unheard of for an application to include a "plugin blacklist" of plugins known to cause problems; if the application developers dislike crash-on-exit, they may then blacklist the plugin. Authors of plugins in such contexts can't sensibly use Qt, unless we can ensure that "unloading" doesn't actually unload. Of course, such an application is likely using naked dlopen/dlcose, not our helpers. The application may be long-running, loading and unloading plugins on demand: it may end up loading new versions of a plugin it has previously unloaded. (There are at least two APIs for web server plugins; fortunately, these are usually loaded in separate processes; but a lean mean new web-server supporting those APIs to ease migration to it as replacement might handle things differently.) As Thiago mentioned, any don't-really-unload solution breaks this. We likely have to live with some element of SEP: the other solutions only mitigate the problem or limit its scope, so we have to document the remaining cases where Qt won't be a good choice for plugin authors. We should at least try to make that a problem for as few potential clients as possible. I played around with this problem (in my ignorance) last month. It seems *some* globals in plugins do get destructed when the library gets unloaded. This surely is what should happen. However, others did not; I failed to work out why (partly due to getting distracted by a red herring). If we can work out what causes the difference and work out how to get globals to go away on dlclose(), we may have a better solution. However, I failed to see a way to do that. Eddy. From mitch.curtis at theqtcompany.com Fri Nov 6 09:50:09 2015 From: mitch.curtis at theqtcompany.com (Curtis Mitch) Date: Fri, 6 Nov 2015 08:50:09 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf Of > Thiago Macieira > Sent: Thursday, 5 November 2015 5:45 PM > To: development at qt-project.org > Subject: [Development] RFD: plugins vs QStringLiterals > [snip] > > 1) Declare it SEP and only apply workarounds for the places where > QStringLiteral is used in our plugins, suggesting that people do the same > in their plugins. SEP? > Problems: libraries loaded by plugins, fragile. > > 2) Deep-copy the QStringLiterals > a) with atom/quark > b) without > > Problem: performance impact, complexity of the atom/quark solution. > > 3) Never unload any plugins, possibly also compiling our own libraries and > plugins with -z nodelete. Solves most of the problems, including the C++ > vtable case. > > Problems: doesn't catch bypassing of QLibrary (dlopen/LoadLibrary calls), > prevents upgrading of plugins without restarting the host application. > > -- > 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 edward.welbourne at theqtcompany.com Fri Nov 6 09:52:29 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Fri, 6 Nov 2015 08:52:29 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4>, Message-ID: > SEP? Sorry, reference to hitch-hiker's guide to the galaxy: Someone Else's Problem. Eddy. From Kai.Koehne at theqtcompany.com Fri Nov 6 10:47:51 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Fri, 6 Nov 2015 09:47:51 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4>,<6946309.ASoCuUn8e6@desktop> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf > [...] > The problem with SEP is that it only works in so far as there *is* something the > author of client code can do about the situation. They may not have enough > choice to control this. > > Qt is a framework. > It gets used in many ways. > This makes it hard to say what options clients have - or don't have. > In the end, SEP means telling some class of potential clients of Qt that Qt has > made a design decision that means they have to use something other than Qt. Well ... we'd 'just' have to make sure we don't "leak" QString's created by QStringLiteral across dll/plugin boundaries. Then, it's indeed the choice of the user's (say KDE) whether they want to use it in their libraries and applications, or not. The easiest way to achieve this is to ban QStringLiteral and QByteArrayLiteral inside Qt's own code. Somehow I doubt that this would have noticeable impact anyway, at least if the replacement tries to cache strings once constructed, instead of mindlessly calling QString::fromLatin1() a million times in a row. Regards Kai From edward.welbourne at theqtcompany.com Fri Nov 6 13:34:06 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Fri, 6 Nov 2015 12:34:06 +0000 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: <563B5F7C.6070707@familiesomers.nl>, Message-ID: > If you're willing to compile and run the attached simple C program, > please let me know its output and your platform's details - ideally > off-list - I'll give a summary in a few days' time. Thanks to those who responded, I now know: * that all the platforms below do the same thing if tm_isdst is 0 or 1 (Yay !) * with .tm_isdst = -1, there is diversity of handling. When tm_isdst is 0 or 1, in the fall back it gets preserved; in the spring forward, it gets flipped and tm_hour is changed in the way it usually would for such a flip. OSX 10.10, Xcode 6.02 * varies within the hour (see below) * at half past: handled as if you'd claimed tm_isdst = 0 (see above) MacBook, Darwin 15.0.0 Ubuntu 12.04, glibc 2.15 Debian/stretch, glibc 2.19 * clear tm_isdst and move an hour earlier in spring * set tm_isdst and preserve hour in autumn MinGW MSVC 2015 * set tm_isdst and move an hour later in spring * clear tm_isdst and preserve hour in autumn. My initial test was, it turns out, naive. Apparently some platforms vary handling of -1 across the hour. I also bit the bullet and worked out how to auto-detect DST transitions. One response indicates asctime_r() isn't portable. So I attach a new version of mktime.c, that needs no manual configuration and is, I hope, a little more portable. I note that setting the TZ environment variable (on platforms that honour it, at least) can be used to discover what your O/S thinks happens in other time-zones than your local one. As before, if anyone feels inclined to give this a whirl, I'd again appreciate any responses, along with descriptions of the system they come from (e.g. uname -a output). Eddy -------------- next part -------------- A non-text attachment was scrubbed... Name: mktime.c Type: text/x-csrc Size: 6196 bytes Desc: mktime.c URL: From kevin.kofler at chello.at Fri Nov 6 17:20:51 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Fri, 06 Nov 2015 17:20:51 +0100 Subject: [Development] RFD: plugins vs QStringLiterals References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: Thiago Macieira wrote: > 1) Declare it SEP and only apply workarounds for the places where > QStringLiteral is used in our plugins, suggesting that people do the same > in their plugins. > > Problems: libraries loaded by plugins, fragile. +1. Caveat emptor. Deep copying destroys the point of QStringLiteral, never unloading plugins is a crude hack. There is only really a problem if the strings (or shallow copies thereof) are passed around in the program after unloading the plugin. So this is very much in the control of the plugin author. They just need to deep-copy the strings they return in the plugin interface with: QString(orig.constData(), orig.size()) if they can be QStringLiterals and are susceptible of outliving the plugin. Kevin Kofler From dangelog at gmail.com Fri Nov 6 17:38:35 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Fri, 6 Nov 2015 17:38:35 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler wrote: > They just need to deep-copy the > strings they return in the plugin interface with: > QString(orig.constData(), orig.size()) > if they can be QStringLiterals and are susceptible of outliving the plugin. Given the problem is a specific case of dangling pointers to resources (in the plugin) about to get destroyed... in the general case, are we playing it "nice" and offering a way for the plugin to clean up after itself, by removing any resouce it may have given out to other libraries which will outlive it? -- Giuseppe D'Angelo From Lars.Knoll at theqtcompany.com Fri Nov 6 17:45:33 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Fri, 6 Nov 2015 16:45:33 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <83A9B8CB-DB9A-4103-AE12-C724BA4E9AE0@theqtcompany.com> On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo" wrote: >On Fri, Nov 6, 2015 at 5:20 PM, Kevin Kofler wrote: >> They just need to deep-copy the >> strings they return in the plugin interface with: >> QString(orig.constData(), orig.size()) >> if they can be QStringLiterals and are susceptible of outliving the plugin. > >Given the problem is a specific case of dangling pointers to resources >(in the plugin) about to get destroyed... in the general case, are we >playing it "nice" and offering a way for the plugin to clean up after >itself, by removing any resouce it may have given out to other >libraries which will outlive it? Unfortunately in many ways that's pretty hard to do. QStringLiteral is only one part of the problem as others have noted. We have many other things that could potentially still be referenced when the plugin gets unloaded: * virtual tables * doc generated data * metatype registrations * string and byte array literals * any pointers to static data that leave the scope of the plugin To me this points strongly to opt for never unloading plugins. We can of course offer a way to force the unloading if the user does it's own stuff and knows what he's doing. But Qt should probably never unload any plugins it loads, as we do not control those and don't know whether they are safe to unload. With that we're ok for the plugins we load. And if someone else insists on unloading something it's his problem. Cheers, Lars From holger at freyther.de Fri Nov 6 18:29:57 2015 From: holger at freyther.de (Holger Freyther) Date: Fri, 6 Nov 2015 18:29:57 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <83A9B8CB-DB9A-4103-AE12-C724BA4E9AE0@theqtcompany.com> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <83A9B8CB-DB9A-4103-AE12-C724BA4E9AE0@theqtcompany.com> Message-ID: <22DA2581-F623-4CF4-97ED-874FD7AC5436@freyther.de> > On 06 Nov 2015, at 17:45, Knoll Lars wrote: > > On 06/11/15 17:38, "Development on behalf of Giuseppe D'Angelo" wrote: Hi, > To me this points strongly to opt for never unloading plugins. We can of course offer a way to force the unloading if the user does it's own stuff and knows what he's doing. But Qt should probably never unload any plugins it loads, as we do not control those and don't know whether they are safe to unload. FYI the musl libc has already made dlclose a no-op[1] out of concerns for the robustness of applications. If you want to add a force option we would probably need a way to flush "caches" in all of qt as well? kind regards holger [1] http://wiki.musl-libc.org/wiki/Functional_differences_from_glibc#Unloading_libraries From thiago.macieira at intel.com Fri Nov 6 19:08:07 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 06 Nov 2015 10:08:07 -0800 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <7389851.sMLd2ElNZY@tjmaciei-mobl4> On Friday 06 November 2015 08:52:29 Welbourne Edward wrote: > > SEP? > > Sorry, reference to hitch-hiker's guide to the galaxy: > Someone Else's Problem. https://en.wikipedia.org/wiki/SEP_field "... is a psychological effect where people choose to dissociate themselves from an issue that may be in critical need of recognition. Such issues may be of large concern to the population as a whole but can easily be a choice of ignorance by an individual" -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Nov 6 19:10:52 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 06 Nov 2015 10:10:52 -0800 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <83A9B8CB-DB9A-4103-AE12-C724BA4E9AE0@theqtcompany.com> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <83A9B8CB-DB9A-4103-AE12-C724BA4E9AE0@theqtcompany.com> Message-ID: <5988055.d1hRm4RkbG@tjmaciei-mobl4> On Friday 06 November 2015 16:45:33 Knoll Lars wrote: > To me this points strongly to opt for never unloading plugins. We can of > course offer a way to force the unloading if the user does it's own stuff > and knows what he's doing. But Qt should probably never unload any plugins > it loads, as we do not control those and don't know whether they are safe > to unload. > > With that we're ok for the plugins we load. And if someone else insists on > unloading something it's his problem. I'm leaning towards that too. But before I go and modify QFactoryLoader... what is that class for? Can anyone find out from the old history? It traces its existence back to "Long live Qt 4.5". -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Nov 6 19:12:58 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 06 Nov 2015 10:12:58 -0800 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <6484531.X3ZcorFbHT@tjmaciei-mobl4> On Friday 06 November 2015 09:47:51 Koehne Kai wrote: > The easiest way to achieve this is to ban QStringLiteral and > QByteArrayLiteral inside Qt's own code. Somehow I doubt that this would > have noticeable impact anyway, at least if the replacement tries to cache > strings once constructed, instead of mindlessly calling > QString::fromLatin1() a million times in a row. Doesn't help with the other types of static data we might keep pointers to (meta objects, meta types, vtables, etc.) -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From pumpkinteapot at gmail.com Sat Nov 7 18:52:31 2015 From: pumpkinteapot at gmail.com (Luke Parry) Date: Sat, 7 Nov 2015 17:52:31 +0000 Subject: [Development] Override toString() method for c++ QObject types in QML Message-ID: Is it possible to override the toString method for native c++ QObject types for use in QML scripts? e.g. using Q_INVOKABLE QString toString() const; This doesn't appear to work because it is overridden by some default implementation which returns a pointer value. Is this done intentionally? Could a workaround be done through javascript prototype methods... It would just improve the readability of debug messages and errors when running scripts. Huge Thanks, Luke Parry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ritt.ks at gmail.com Sat Nov 7 23:45:59 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Sun, 8 Nov 2015 02:45:59 +0400 Subject: [Development] Override toString() method for c++ QObject types in QML In-Reply-To: References: Message-ID: Maybe JSON.stringify(obj) is what you need? Konstantin 2015-11-07 21:52 GMT+04:00 Luke Parry : > Is it possible to override the toString method for native c++ QObject > types for use in QML scripts? > > e.g. using > > Q_INVOKABLE QString toString() const; > > This doesn't appear to work because it is overridden by some default > implementation which returns a pointer value. Is this done intentionally? > Could a workaround be done through javascript prototype methods... > > It would just improve the readability of debug messages and errors when > running scripts. > > Huge Thanks, > Luke Parry > > _______________________________________________ > 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 Sun Nov 8 08:42:18 2015 From: kl222 at 126.com (kl222) Date: Sun, 8 Nov 2015 15:42:18 +0800 Subject: [Development] Install file path is error Message-ID: <000801d119f9$05a5fb50$10f1f1f0$@126.com> Oswald Buddenhagen: Qt version: greater than 5.4. Platform: windows mingw My qmake command: C:/Qt/Qt5.5.1/5.5/android_armv7/bin/qmake.exe -spec android-g++ QXMPP_LIBRARY_TYPE=staticlib PREFIX=E:/source/im/client/rabbitim/ThirdLibary/build_script/../android INCLUDEPATH+=E:/source/im/client/rabbitim/ThirdLibary/build_script/../android/include LIBS+=-LE:/source/im/client/rabbitim/ThirdLibary/build_script/../android/lib QXMPP_USE_VPX=1 CONFIG+=debug -o Makefile ../../src/src.pro make install When compiling android library, the installation file location Error. 1. Path format error 2. Prefix destination path of no use PREFIX Error: Makefile install_headers: first FORCE @test -d E:$(INSTALL_ROOT)/source/im/client/rabbitim/ThirdLibary/build_script/../android/include/qxmpp || mkdir -p E:$(INSTALL_ROOT)/source/im/client/rabbitim/ThirdLibary/build_script/../android/include/qxmpp -$(INSTALL_FILE) E:/source/im/lib/qxmpp/src/base/QXmppArchiveIq.h E:$(INSTALL_ROOT)/source/im/client/rabbitim/ThirdLibary/build_script/../android/include/qxmpp/ Bug report: https://bugreports.qt.io/browse/QTBUG-49298 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile Type: application/octet-stream Size: 584801 bytes Desc: not available URL: From steveire at gmail.com Sun Nov 8 22:57:31 2015 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 08 Nov 2015 22:57:31 +0100 Subject: [Development] Override toString() method for c++ QObject types in QML References: Message-ID: Konstantin Ritt wrote: > Maybe JSON.stringify(obj) is what you need? > I think the intention is to override what that does using a specified method. Thanks, Steve. From Lars.Knoll at theqtcompany.com Mon Nov 9 10:10:56 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 9 Nov 2015 09:10:56 +0000 Subject: [Development] Override toString() method for c++ QObject types in QML In-Reply-To: References: Message-ID: <7DDD4AB5-EFDA-420F-B523-1EA3826692A7@theqtcompany.com> On 08/11/15 22:57, "Development on behalf of Stephen Kelly" wrote: >Konstantin Ritt wrote: > >> Maybe JSON.stringify(obj) is what you need? >> > >I think the intention is to override what that does using a specified >method. JSON.stringify() does something slightly different than what you can do by reimplementing toString(). For toString(), the default implementation for the object prototype will currently get used. Implementing an invokable method on the wrapped QObject would be nice, but currently there is some logic in the engine missing that would allow that method to get picked up automatically. Cheers, Lars From ronan.jouchet at cadensimaging.com Mon Nov 9 16:14:10 2015 From: ronan.jouchet at cadensimaging.com (Ronan Jouchet) Date: Mon, 9 Nov 2015 10:14:10 -0500 Subject: [Development] [QtQuick] Is Qt.import() really async? How to cope with it? Message-ID: <5640B842.30408@cadensimaging.com> (This is a mailing list re-post of the forum.qt.io thread at [forum1]) Hi. I want a QML component to call a js domain/business-specific library, itself calling a generic library. Exactly the use case depicted by the "Including a JavaScript Resource from Another JavaScript Resource" [doc1] documentation entry: ui.qml → script.js → factorial.js. In this example, script.js calls `Qt.include("factorial.js")`, then immediately calls the `factorial(value)` function included from factorial.js. But trying exactly this in my project, instead of working as expected, I end up with error `script.js:6: ReferenceError: factorial is not defined` :-/ . Why? Because `Qt.include()` is asynchronous! As mentioned by Qt.include()'s documentation [doc2], "Qt.include() returns an object that describes the status of the operation [...]. The status property will be updated as the operation progresses. If provided, callback is invoked when the operation completes. The callback is passed the same object as is returned from the `Qt.include()` call." And indeed, true to the method documentation, if trying a synchronous approach, the Qt.include() call yields the following object: { "OK":0, "LOADING":1, "NETWORK_ERROR":2, "EXCEPTION":3, "status":1 } `status` equals "LOADING", our child method hasn't been copied to caller scope yet. Okay. So instead of going synchronous, let's play ball and make the example async with a callback: // script.js function showCalculations(value) { console.log("Just a top-level scope stub, to be replaced on import of factorial.js"); } Qt.include("factorial.js", function(includeStatus) { console.log(includeStatus); // logs 0 now, great showCalculations = function(value) { console.log( "Call factorial() from script.js:", factorial(value)); } }); The good news here is that the `includeStatus.status` being logged is now 0, the callback did fire on successful import as promised. But the bad news is of course that, because the include is asynchronous and non-blocking, it will not not be resolved at the time QML needs it, and QML will use the shim, logging "Just a top-level scope stub...". Of course, not including a stub will result in worse: the function not being found. → Am I missing anything / is the documentation effectively incorrect? Or am I facing a special case? My qml and scripts are part of a qrc, could it be interfering? Thanks for your help. [forum1] https://forum.qt.io/topic/60424/how-to-cope-with-the-asynchronous-ness-of-qt-import [doc1] http://doc.qt.io/qt-5/qtqml-javascript-imports.html#including-a-javascript-resource-from-another-javascript-resource [doc2] http://doc.qt.io/qt-5/qml-qtqml-qt.html#include-method -- Ronan From heliocastro at gmail.com Mon Nov 9 18:49:11 2015 From: heliocastro at gmail.com (Helio Chissini de Castro) Date: Mon, 9 Nov 2015 15:49:11 -0200 Subject: [Development] New Qt 5.6.0 Beta snapshot available In-Reply-To: References: Message-ID: Hello Jani There's an issue on the src package, no doc subdir was provided under qtbase, not enable us to build docs offline. []'s Helio On Tue, Nov 3, 2015 at 10:06 AM, Heikkinen Jani < jani.heikkinen at theqtcompany.com> wrote: > Hi all, > > > We have new Qt 5.6.0 beta snapshot available, > > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/241/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/265/ > > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/198/ > > src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ > > > Please test these packages carefully and inform me immediately all beta > blockers which aren't already linked in > https://bugreports.qt.io/browse/QTBUG-47958 . > > > br, > > Jani > > > > _______________________________________________ > 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 pumpkinteapot at gmail.com Tue Nov 10 12:12:08 2015 From: pumpkinteapot at gmail.com (Luke Parry) Date: Tue, 10 Nov 2015 11:12:08 +0000 Subject: [Development] Override toString() method for c++ QObject types in QML In-Reply-To: <7DDD4AB5-EFDA-420F-B523-1EA3826692A7@theqtcompany.com> References: <7DDD4AB5-EFDA-420F-B523-1EA3826692A7@theqtcompany.com> Message-ID: That's fine. I was curious if this was possible or not in the current state of QML2. I do not yet have critical need for it but it could also be useful for overriding the valueOf prototype. I will just use another method to provide debug information about a QObject type. Thanks for the quick answer, Luke On 9 November 2015 at 09:10, Knoll Lars wrote: > > On 08/11/15 22:57, "Development on behalf of Stephen Kelly" < > development-bounces at qt-project.org on behalf of steveire at gmail.com> wrote: > > >Konstantin Ritt wrote: > > > >> Maybe JSON.stringify(obj) is what you need? > >> > > > >I think the intention is to override what that does using a specified > >method. > > JSON.stringify() does something slightly different than what you can do by > reimplementing toString(). > > For toString(), the default implementation for the object prototype will > currently get used. Implementing an invokable method on the wrapped QObject > would be nice, but currently there is some logic in the engine missing that > would allow that method to get picked up automatically. > > Cheers, > Lars > > > _______________________________________________ > 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 marc.mutz at kdab.com Tue Nov 10 14:55:19 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Tue, 10 Nov 2015 14:55:19 +0100 Subject: [Development] Fwd: Change in qt/qtbase[dev]: QFileSystemWatcher: print out path in case of error. Message-ID: <201511101455.19812.marc.mutz@kdab.com> Hi, is anyone looking into this recurring CI problem? Thanks, Marc -- Marc Mutz | Senior Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- An embedded message was scrubbed... From: "Qt CI Bot (Code Review)" Subject: Change in qt/qtbase[dev]: QFileSystemWatcher: print out path in case of error. Date: Tue, 10 Nov 2015 12:31:42 +0000 Size: 4097 URL: From thiago.macieira at intel.com Tue Nov 10 18:41:07 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 10 Nov 2015 09:41:07 -0800 Subject: [Development] Fwd: Change in qt/qtbase[dev]: QFileSystemWatcher: print out path in case of error. In-Reply-To: <201511101455.19812.marc.mutz@kdab.com> References: <201511101455.19812.marc.mutz@kdab.com> Message-ID: <9846983.1jWvDnhBzk@tjmaciei-mobl4> On Tuesday 10 November 2015 14:55:19 Marc Mutz wrote: > Hi, > > is anyone looking into this recurring CI problem? Yes, it's fixed by https://codereview.qt-project.org/140389 -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From ritt.ks at gmail.com Tue Nov 10 18:59:26 2015 From: ritt.ks at gmail.com (Konstantin Ritt) Date: Tue, 10 Nov 2015 20:59:26 +0300 Subject: [Development] Dropping support for Android 15 and below in Qt 5.7 In-Reply-To: <562F29BC.90406@theqtcompany.com> References: <562F29BC.90406@theqtcompany.com> Message-ID: My +1. Konstantin 2015-10-27 10:37 GMT+03:00 Eskil A. Blomfeldt via Development < development at qt-project.org>: > Hi, > > According to the data from Google Play, there are currently only 7.4% of > active devices on Android versions 15 and below (< 4.1). > > https://developer.android.com/about/dashboards/index.html > > Since this is a small and diminishing group and since the testing we are > doing on these old devices is limited, I propose we drop support for > versions 15 and below in Qt 5.7. It should simplify the code some, and > definitely our testing requirements. > > -- Eskil > _______________________________________________ > 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 olivier at woboq.com Tue Nov 10 19:43:35 2015 From: olivier at woboq.com (Olivier Goffart) Date: Tue, 10 Nov 2015 19:43:35 +0100 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: References: Message-ID: <1567522.7rxADYjp0Y@finn> On Tuesday 23. June 2015 10:17:40 Knoll Lars wrote: [...] > Qt 5.7: > * New compiler baseline with gcc 4.7 and VC++ 2012 > * Enable and use the C++11 features supported by these compilers > unconditionally By "C++11 features", do you mean only core language feature, or can we also use standard library features. For example I would like to use std::enable_if instead of QtPrivate::QEnableIf [https://codereview.qt-project.org/140266] Clang would then gives better error messages because it knows about it. I would also want to use the type traits such as std::is_trivial and std::is_trivially_copyable [https://codereview.qt-project.org/140476] Likewise, Marc is trying to use std::declval and type traits in exception specification [https://codereview.qt-project.org/140132/] Not to mention that we already use directly things like std::move or std::forward. Since all of these are C++11 features supported by these compiler, I would assume that we can use them unconditionally. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From Lars.Knoll at theqtcompany.com Tue Nov 10 21:05:11 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 10 Nov 2015 20:05:11 +0000 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: References: Message-ID: <9BD08D53-0B6F-4B92-A7F7-4C4926D29DD2@theqtcompany.com> On 04/11/15 15:31, "Albert Astals Cid" wrote: >On Tue, Jun 23, 2015 at 12:17 PM, Knoll Lars > wrote: >> Qt 5.6: >> >> * We make 5.6 a long term supported release > >Any plan on how long will be that "long term"? 2 years? 5 years? 3 years was the current thinking. Cheers, Lars From thiago.macieira at intel.com Tue Nov 10 21:10:17 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 10 Nov 2015 12:10:17 -0800 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <1567522.7rxADYjp0Y@finn> References: <1567522.7rxADYjp0Y@finn> Message-ID: <4011066.6evGl58dNp@tjmaciei-mobl4> On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: > Since all of these are C++11 features supported by these compiler, I would > assume that we can use them unconditionally. The problem is that the Standard Library in use is not always the one provided with the compiler. See the cases of libstdc++ with Clang and Dinkumware with QNX's GCC. If we're going to use certain Standard Library features that weren't previously checked with Q_COMPILER [*], I'd like a survey of our target platforms to confirm the features are present and work, then we can produce a whitelist. [*] The following Standard Library features were already checked: 1) by Q_COMPILER_ATOMICS 2) std::move and std::forward, by Q_COMPILER_RVALUE_REFS 3) by Q_COMPILER_INITIALIZER_LISTS -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Lars.Knoll at theqtcompany.com Tue Nov 10 21:22:28 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Tue, 10 Nov 2015 20:22:28 +0000 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <1567522.7rxADYjp0Y@finn> References: <1567522.7rxADYjp0Y@finn> Message-ID: On 10/11/15 19:43, "Olivier Goffart" wrote: >On Tuesday 23. June 2015 10:17:40 Knoll Lars wrote: >[...] >> Qt 5.7: >> * New compiler baseline with gcc 4.7 and VC++ 2012 >> * Enable and use the C++11 features supported by these compilers >> unconditionally > >By "C++11 features", do you mean only core language feature, or can we also >use standard library features. The core language features are certainly ok. Standard library features is something where we've always been a bit more careful, as the level of support for them from different standard library implementations has unfortunately been somewhat orthogonal to the compiler discussion (see the discussion about atomics a few weeks ago). At least for now, I don't want us to rely too much on standard library features in our APIs (ie. Using these types in the APIs we expose to our users). But I am not opposed to using any of these features in our implementation, if they work on all platforms we currently support with Qt 5.7. > >For example I would like to use std::enable_if instead of QtPrivate::QEnableIf >[https://codereview.qt-project.org/140266] >Clang would then gives better error messages because it knows about it. > >I would also want to use the type traits such as std::is_trivial and >std::is_trivially_copyable >[https://codereview.qt-project.org/140476] > >Likewise, Marc is trying to use std::declval and type traits >in exception specification [https://codereview.qt-project.org/140132/] > >Not to mention that we already use directly things like std::move or >std::forward. > >Since all of these are C++11 features supported by these compiler, I would >assume that we can use them unconditionally. We should check that these features work and are supported on all the platforms we target with 5.7. If they are, I'm ok to use them. The usual suspects that could cause issues are VS2012 (WEC2013), QNX 6.6, and RHEL. Ideally, we could simply let the CI decide whether the feature works, but unfortunately I don't think we're currently running auto tests for QNX or WEC. So we'll know whether things compile on those platforms, but we don't know whether they work without someone actually trying it out. Cheers, Lars From thiago.macieira at intel.com Tue Nov 10 23:21:09 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 10 Nov 2015 14:21:09 -0800 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <4011066.6evGl58dNp@tjmaciei-mobl4> References: <1567522.7rxADYjp0Y@finn> <4011066.6evGl58dNp@tjmaciei-mobl4> Message-ID: <3010959.kt3CgulTqK@tjmaciei-mobl4> On Tuesday 10 November 2015 12:10:17 Thiago Macieira wrote: > The problem is that the Standard Library in use is not always the one > provided with the compiler. See the cases of libstdc++ with Clang and > Dinkumware with QNX's GCC. > > If we're going to use certain Standard Library features that weren't > previously checked with Q_COMPILER [*], I'd like a survey of our target > platforms to confirm the features are present and work, then we can produce > a whitelist. FYI Five months ago, Mozilla *added* a tuple class instead of using std::tuple: https://bugzilla.mozilla.org/show_bug.cgi?id=1163328 Quoting the proposal above: > The C++11 standard library has them (std::tuple), but since we can't use > that yet, I propose adding one to MFBT. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed Nov 11 00:41:23 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 11 Nov 2015 00:41:23 +0100 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <1567522.7rxADYjp0Y@finn> References: <1567522.7rxADYjp0Y@finn> Message-ID: <201511110041.23805.marc.mutz@kdab.com> On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: > Likewise, Marc is trying to use std::declval and type traits > in exception specification [https://codereview.qt-project.org/140132/] declval is in use for exception specifications since at least 5.5 (in QPair). As for type_traits, please note that for many of them, there is no other way to get at the information (std::is_trivial*, std::is_polymorphic, even some std::is_nothrow_constructible, because a seemingly equivalent noexcep operator (say, noexcept(T(std::declval()) also includes the dtor). I propose that whatever we decide here is checked for in machine-readable form in tst_compiler. 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 aclight at gmail.com Wed Nov 11 01:40:04 2015 From: aclight at gmail.com (Adam Light) Date: Tue, 10 Nov 2015 16:40:04 -0800 Subject: [Development] Pixelated UI elements in Windows HiDPI mode (5.6) Message-ID: I built Qt 5.6 (latest from the 5.6 git branch as of this morning) and tested our application with the build on Windows 10. I'm calling QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); before the QApplication is created. I don't have an actual High DPI monitor so I've been testing by clicking the "scaling level" link in the Display control panel applet and setting the scaling factor to 200%. I then click OK, Apply, log out of my account, and log back in. First of all, thanks to everyone who's been involved in improving the HiDPI code for Qt 5.6. HiDPI is much better now in 5.6 compared to 5.5. I've noticed that a lot of the UI elements that look like they're using icons for which a HiDPI version is not being used, including: * radio/check buttons * arrows on combo boxes, tool buttons, scroll bars, tab widgets * The ? and X icon of QMdiSubwindow * The clear button (grey X) of a QLineEdit I don't see tickets in Jira for any of these. I'm willing to create tickets for these items, but I'm not sure what the most useful way would be to organize the tickets. So, first, should I create tickets for these at all? If so, would it be best to create one ticket that mentions all of the different issues, or should I create a separate ticket for each individual element? Thanks Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Wed Nov 11 08:39:05 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 11 Nov 2015 07:39:05 +0000 Subject: [Development] New Qt 5.6 Beta snapshot available Message-ID: Hi all, New Qt5.6 Beta snapshot available in http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/253/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/275/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/203/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Unfortunately these aren't yet final beta packages but should be pretty close so please test these packages and report all beta blockers immediately: We are targeting to put beta out as soon as possible, preferably already during next week. These packages contain now QtCreator 3.6.0-RC snapshot. RTA testing still ongoing but according to smoke test results packages seems to be ok for wider testing Known issues: - https://bugreports.qt.io/browse/QTBUG-47958 :Issues to be fixed before Qt 5.6.0 Beta - There might be some issues with kits in the creator: during the smoke testing some users have seen problems with compiler (auto)detection (and some users haven't) - New tech preview components not seen in installer UI br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From Friedemann.Kleint at theqtcompany.com Wed Nov 11 08:39:15 2015 From: Friedemann.Kleint at theqtcompany.com (Friedemann Kleint) Date: Wed, 11 Nov 2015 08:39:15 +0100 Subject: [Development] Pixelated UI elements in Windows HiDPI mode (5.6) In-Reply-To: References: Message-ID: <5642F0A3.70005@theqtcompany.com> Hi, >I don't see tickets in Jira for any of these. Please do not create unrelated, single tickets for each issue. Previously, we had https://bugreports.qt.io/browse/QTBUG-40277 "Adapt styles to High DPI" (related to https://bugreports.qt.io/browse/QTBUG-46615 "Implement High DPI scaling v2 (5.6)"). QTBUG-40277 could be cleaned up listing the remaining items or a new report linked to QTBUG-46615 could be created in a similar fashion. Also note that the Windows styles do not support scaling (and will not for the foreseeable future); we recommend using Fusion style (or Mac style on OS X). Regards, Friedemann -- Friedemann Kleint | The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From Lars.Knoll at theqtcompany.com Wed Nov 11 09:43:57 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Wed, 11 Nov 2015 08:43:57 +0000 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <201511110041.23805.marc.mutz@kdab.com> References: <1567522.7rxADYjp0Y@finn> <201511110041.23805.marc.mutz@kdab.com> Message-ID: <3143FB29-5622-40A1-B95F-1DD29179CAD8@theqtcompany.com> On 11/11/15 00:41, "Development on behalf of Marc Mutz" wrote: >On Tuesday 10 November 2015 19:43:35 Olivier Goffart wrote: >> Likewise, Marc is trying to use std::declval and type traits >> in exception specification [https://codereview.qt-project.org/140132/] > >declval is in use for exception specifications since at least 5.5 (in QPair). > >As for type_traits, please note that for many of them, there is no other way >to get at the information (std::is_trivial*, std::is_polymorphic, even some >std::is_nothrow_constructible, because a seemingly equivalent noexcep operator >(say, noexcept(T(std::declval()) also includes the dtor). > >I propose that whatever we decide here is checked for in machine-readable form >in tst_compiler. Fully agree to that. But as long as we can’t execute autotests on all platforms in the CI someone will need to manually check those on some of the target platforms if we extend the set of features used. Cheers, Lars From Morten.Sorvig at theqtcompany.com Wed Nov 11 13:51:44 2015 From: Morten.Sorvig at theqtcompany.com (Sorvig Morten) Date: Wed, 11 Nov 2015 12:51:44 +0000 Subject: [Development] Pixelated UI elements in Windows HiDPI mode (5.6) In-Reply-To: References: Message-ID: > On 11 Nov 2015, at 01:40, Adam Light wrote: > > I built Qt 5.6 (latest from the 5.6 git branch as of this morning) and tested our application with the build on Windows 10. I'm calling > QApplication::setAttribute(Qt::AA_EnableHighDpiScaling); > before the QApplication is created. > > I don't have an actual High DPI monitor so I've been testing by clicking the "scaling level" link in the Display control panel applet and setting the scaling factor to 200%. I then click OK, Apply, log out of my account, and log back in. You can also set the QT_SCALE_FACTOR environment variable for quick testing like like this. (Set it to 2, not 200%.) > > First of all, thanks to everyone who's been involved in improving the HiDPI code for Qt 5.6. HiDPI is much better now in 5.6 compared to 5.5. > > I've noticed that a lot of the UI elements that look like they're using icons for which a HiDPI version is not being used, including: > * radio/check buttons > * arrows on combo boxes, tool buttons, scroll bars, tab widgets > * The ? and X icon of QMdiSubwindow > * The clear button (grey X) of a QLineEdit This could be an nice opportunity for a contribution from someone with artistic ambitions. Morten From massimocallegari at yahoo.it Wed Nov 11 14:22:16 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Wed, 11 Nov 2015 13:22:16 +0000 (UTC) Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: References: Message-ID: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> Hi, I think there something wrong with the sources package Nov 10th (I downloaded the 7z one) 1- the folder name is 'releaseexporttools_src_work_win" instead of "qt-everywhere-opensource-5.6.0" 2- the configure script in the main folder gives an error on Linux. I believe it has something to do with dos2unix carriage return. I had to copy the one from 5.5.1 to build. 3- all the submodules are missing the examples folder I know it's still a snapshot, but I just wanted to report what I found. Thanks Massimo ________________________________ Da: Heikkinen Jani A: "development at qt-project.org" Inviato: Mercoledì 11 Novembre 2015 8:39 Oggetto: [Development] New Qt 5.6 Beta snapshot available Hi all, New Qt5.6 Beta snapshot available in http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/253/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/275/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/203/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Unfortunately these aren't yet final beta packages but should be pretty close so please test these packages and report all beta blockers immediately: We are targeting to put beta out as soon as possible, preferably already during next week. These packages contain now QtCreator 3.6.0-RC snapshot. RTA testing still ongoing but according to smoke test results packages seems to be ok for wider testing Known issues: - https://bugreports.qt.io/browse/QTBUG-47958 :Issues to be fixed before Qt 5.6.0 Beta - There might be some issues with kits in the creator: during the smoke testing some users have seen problems with compiler (auto)detection (and some users haven't) - New tech preview components not seen in installer UI br, Jani _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From helio at kde.org Wed Nov 11 14:35:43 2015 From: helio at kde.org (Helio Chissini de Castro) Date: Wed, 11 Nov 2015 11:35:43 -0200 Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> References: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> Message-ID: And for us, distributions, we need at least splitted source codes. We just CAN'T test our packages the way is deployed now. On Wed, Nov 11, 2015 at 11:22 AM, Massimo Callegari < massimocallegari at yahoo.it> wrote: > Hi, I think there something wrong with the sources package Nov 10th (I > downloaded the 7z one) > > 1- the folder name is 'releaseexporttools_src_work_win" instead of > "qt-everywhere-opensource-5.6.0" > > 2- the configure script in the main folder gives an error on Linux. I > believe it has something to do with dos2unix carriage return. I had to copy > the one from 5.5.1 to build. > > 3- all the submodules are missing the examples folder > > I know it's still a snapshot, but I just wanted to report what I found. > > Thanks > Massimo > > ________________________________ > Da: Heikkinen Jani > A: "development at qt-project.org" > Inviato: Mercoledì 11 Novembre 2015 8:39 > Oggetto: [Development] New Qt 5.6 Beta snapshot available > > > > > Hi all, > > New Qt5.6 Beta snapshot available in > http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/ > > Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/253/ > > Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/275/ > Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/203/ > > src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ > > > > Unfortunately these aren't yet final beta packages but should be pretty > close so please test these packages and report all beta blockers > immediately: We are targeting to put beta out as soon as possible, > preferably already during next week. > > These packages contain now QtCreator 3.6.0-RC snapshot. > > RTA testing still ongoing but according to smoke test results packages > seems to be ok for wider testing > > > Known issues: > > - https://bugreports.qt.io/browse/QTBUG-47958 :Issues to be fixed before > Qt 5.6.0 Beta > > - There might be some issues with kits in the creator: during the smoke > testing some users have seen problems with compiler (auto)detection (and > some users haven't) > - New tech preview components not seen in installer UI > > br, > Jani > > _______________________________________________ > 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 frederik.gladhorn at theqtcompany.com Wed Nov 11 14:45:27 2015 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Wed, 11 Nov 2015 14:45:27 +0100 Subject: [Development] Continuous Integration status Message-ID: <3042918.GbbOduDR47@frederik-thinkcentre-m93p> Hi all, for those submitting patches to Qt the last few days were actually not very rewarding since the continuous integration hasn't been working really. I really hope that we're back on track, since Monday we had all kinds of things coming together to hit us one after the other. Since we want to make the long term support with Qt 5.6 a reality, we have been restructuring how we test and produce packages. The two were completely independent processes before, but we aligned them so that we have one system testing and producing the binaries for the packages. In the process we hit some small road bumps, such as having to enable the sql plugins and noticing that they don't actually always build smoothly, which started the mess on Monday. We also had a small bug that prevented integrations from finishing, so that the queue grew larger and larger, revealing some ddns and dhcp issues and eventually a full disk too since we were just piling up more and more VMs. In fact we've been so busy fire fighting that this mail comes a bit late... Long story short, we did a lot of fixing and hope to be back with full force. Just now we have the "dev" branch still locked down to make sure we are back to normal, things should roll as usual again in a few hours. Sorry for the inconvenience and bear with us, Qt 5.6 will be better than ever once this is sorted out :) Cheers, Frederik From marc.mutz at kdab.com Wed Nov 11 16:34:20 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 11 Nov 2015 16:34:20 +0100 Subject: [Development] Continuous Integration status In-Reply-To: <3042918.GbbOduDR47@frederik-thinkcentre-m93p> References: <3042918.GbbOduDR47@frederik-thinkcentre-m93p> Message-ID: <201511111634.20782.marc.mutz@kdab.com> Hi Frederik, ... and everyone else maintaining the CI. On Wednesday 11 November 2015 14:45:27 Frederik Gladhorn wrote: [...] > Long story short, we did a lot of fixing and hope to be back with full > force. Just now we have the "dev" branch still locked down to make sure we > are back to normal, things should roll as usual again in a few hours. [...] You're doing an amazing job. The CI before the hickups already felt much smoother than what we had for the longest time. Just wanted to say thank you to everyone involved. 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 Wed Nov 11 16:13:35 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 11 Nov 2015 16:13:35 +0100 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <2933163.CROrJTuMtl@asterix> References: <2506385.IRh3OJzgst@patux> <2433728.8ETpESIlmq@portia.local> <2933163.CROrJTuMtl@asterix> Message-ID: <1817248.tUYbtdtZUR@portia.local> On Wednesday November 11 2015 15:52:33 David Faure wrote: Cross-posting on Qt's development ML because it seems more than relevant there. To put things in context: this discussion on kde-frameworks-devel was started because an autotest from KService deleted a good chunk from my /Applications directory before I killed it (it'd have deleted the whole folder if I'd been running an SSD). > *writableLocation* returns /Applications ? How is that possible? Yes. It cannot be otherwise as you've probably seen making the patch below, but I can understand the choice. OTOH, app bundles can be anywhere on OS X (as long as you use LaunchServices), so it'd be just as fine to set the writable location to $HOME/Applications. You might consider that for your patch. Another thing that occurs to me: ApplicationsLocation doesn't hold the actual applications on Linux. Are QstandardPaths locations allowed to have different interpretations (and implications) like that, across platforms? > Please test this patch before I submit it to gerrit: > > > diff --git a/src/corelib/io/qstandardpaths_mac.mm b/src/corelib/io/qstandardpaths_mac.mm > index d6126ce..8e030ae 100644 > --- a/src/corelib/io/qstandardpaths_mac.mm > +++ b/src/corelib/io/qstandardpaths_mac.mm > @@ -162,6 +162,9 @@ QString QStandardPaths::writableLocation(StandardLocation type) > if (type == AppConfigLocation) > appendOrganizationAndApp(path); > return path; > + case ApplicationsLocation: > + path = qttestDir + QLatin1String("/Applications"); > + return path; > default: > break; > } That looks like what I would certainly have come up with. Will test it, but as I just posted, we'll probably want to verify certain other locations as well. And you'll probably want to include my fix to the FontsLocation which omitted /Library/Fonts and considered /System/Library/Fonts to be writable ... --- a/qtbase/src/corelib/io/qstandardpaths_mac.mm +++ b/qtbase/src/corelib/io/qstandardpaths_mac.mm @@ -178,6 +178,8 @@ case GenericCacheLocation: case CacheLocation: case RuntimeLocation: + case FontsLocation: + // the font location that is writable for all users is ~/Library/Fonts return macLocation(type, kUserDomain); default: return macLocation(type, kOnAppropriateDisk); @@ -218,6 +220,12 @@ dirs.append(bundlePath + resourcesPath); } } + if (type == FontsLocation) { + // /Library/Fonts + dirs.append(macLocation(type,kLocalDomain)); + // /System/Library/Fonts + dirs.append(macLocation(type,kSystemDomain)); + } const QString localDir = writableLocation(type); dirs.prepend(localDir); return dirs; > > I'll be reporting this to Qt, of course. > That seems premature, due to you having your own patch on top of QSP. My own patch does nothing when XDG mode isn't activated (and that particular aspect works, as does the activation stuff). And of course I'd submit a patch that doesn't include any XDG modifications. R. From Jake.Petroules at theqtcompany.com Wed Nov 11 16:32:20 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 11 Nov 2015 15:32:20 +0000 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <1817248.tUYbtdtZUR@portia.local> References: <2506385.IRh3OJzgst@patux> <2433728.8ETpESIlmq@portia.local> <2933163.CROrJTuMtl@asterix> <1817248.tUYbtdtZUR@portia.local> Message-ID: <03236587-4CA4-4CE8-91C9-769858142E8E@theqtcompany.com> On Nov 11, 2015, at 7:13 AM, René J.V. Bertin > wrote: On Wednesday November 11 2015 15:52:33 David Faure wrote: Cross-posting on Qt's development ML because it seems more than relevant there. To put things in context: this discussion on kde-frameworks-devel was started because an autotest from KService deleted a good chunk from my /Applications directory before I killed it (it'd have deleted the whole folder if I'd been running an SSD). *writableLocation* returns /Applications ? How is that possible? Yes. It cannot be otherwise as you've probably seen making the patch below, but I can understand the choice. OTOH, app bundles can be anywhere on OS X (as long as you use LaunchServices), so it'd be just as fine to set the writable location to $HOME/Applications. You might consider that for your patch. No, there is only one location so it must remain /Applications as expected by anyone on the OS X platform. Another thing that occurs to me: ApplicationsLocation doesn't hold the actual applications on Linux. Are QstandardPaths locations allowed to have different interpretations (and implications) like that, across platforms? Please test this patch before I submit it to gerrit: diff --git a/src/corelib/io/qstandardpaths_mac.mm b/src/corelib/io/qstandardpaths_mac.mm index d6126ce..8e030ae 100644 --- a/src/corelib/io/qstandardpaths_mac.mm +++ b/src/corelib/io/qstandardpaths_mac.mm @@ -162,6 +162,9 @@ QString QStandardPaths::writableLocation(StandardLocation type) if (type == AppConfigLocation) appendOrganizationAndApp(path); return path; + case ApplicationsLocation: + path = qttestDir + QLatin1String("/Applications"); + return path; default: break; } That looks like what I would certainly have come up with. Will test it, but as I just posted, we'll probably want to verify certain other locations as well. And you'll probably want to include my fix to the FontsLocation which omitted /Library/Fonts and considered /System/Library/Fonts to be writable ... --- a/qtbase/src/corelib/io/qstandardpaths_mac.mm +++ b/qtbase/src/corelib/io/qstandardpaths_mac.mm @@ -178,6 +178,8 @@ case GenericCacheLocation: case CacheLocation: case RuntimeLocation: + case FontsLocation: + // the font location that is writable for all users is ~/Library/Fonts return macLocation(type, kUserDomain); default: return macLocation(type, kOnAppropriateDisk); @@ -218,6 +220,12 @@ dirs.append(bundlePath + resourcesPath); } } + if (type == FontsLocation) { + // /Library/Fonts + dirs.append(macLocation(type,kLocalDomain)); + // /System/Library/Fonts + dirs.append(macLocation(type,kSystemDomain)); + } const QString localDir = writableLocation(type); dirs.prepend(localDir); return dirs; That won't apply, I refactored QSP recently in dev branch to drop the dependency on deprecated Carbon APIs. That font dirs problem should be fixed already, however. I'll be reporting this to Qt, of course. That seems premature, due to you having your own patch on top of QSP. My own patch does nothing when XDG mode isn't activated (and that particular aspect works, as does the activation stuff). And of course I'd submit a patch that doesn't include any XDG modifications. R. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Nov 11 16:53:25 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 11 Nov 2015 16:53:25 +0100 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <03236587-4CA4-4CE8-91C9-769858142E8E@theqtcompany.com> References: <2506385.IRh3OJzgst@patux> <1817248.tUYbtdtZUR@portia.local> <03236587-4CA4-4CE8-91C9-769858142E8E@theqtcompany.com> Message-ID: <2872195.haFMHcpolX@patux> On Wednesday November 11 2015 15:32:20 Petroules Jake wrote: >No, there is only one location so it must remain /Applications as expected by anyone on the OS X platform. I don't understand, what do you mean with "there is only one location"? It is also expected that regular users do not have write permissions in /Applications or similar system locations, so some compromise must be found IMHO. >That won't apply, I refactored QSP recently in dev branch to drop the dependency on deprecated Carbon APIs. That font dirs problem should be fixed already, however. It still applies in 5.5.0 . In what version is that refactored code expected to land? The next 5.5 release already? R. From Jake.Petroules at theqtcompany.com Wed Nov 11 17:03:31 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 11 Nov 2015 16:03:31 +0000 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <2872195.haFMHcpolX@patux> References: <2506385.IRh3OJzgst@patux> <1817248.tUYbtdtZUR@portia.local> <03236587-4CA4-4CE8-91C9-769858142E8E@theqtcompany.com> <2872195.haFMHcpolX@patux> Message-ID: <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> On Nov 11, 2015, at 7:53 AM, René J.V. Bertin > wrote: On Wednesday November 11 2015 15:32:20 Petroules Jake wrote: No, there is only one location so it must remain /Applications as expected by anyone on the OS X platform. I don't understand, what do you mean with "there is only one location"? I mean the API returns a single value, not a list. However, READable locations will return a list containing both $HOME/Applications and /Applications It is also expected that regular users do not have write permissions in /Applications or similar system locations, so some compromise must be found IMHO. That won't apply, I refactored QSP recently in dev branch to drop the dependency on deprecated Carbon APIs. That font dirs problem should be fixed already, however. It still applies in 5.5.0 . In what version is that refactored code expected to land? The next 5.5 release already? 5.7 I think. https://codereview.qt-project.org/#/c/122044/ R. -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Nov 11 17:20:18 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 11 Nov 2015 17:20:18 +0100 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> References: <2506385.IRh3OJzgst@patux> <2872195.haFMHcpolX@patux> <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> Message-ID: <8069187.9vKdhW8Egc@patux> On Wednesday November 11 2015 16:03:31 Petroules Jake wrote: >I don't understand, what do you mean with "there is only one location"? > >I mean the API returns a single value, not a list. However, READable locations will return a list containing both $HOME/Applications and /Applications Ah. I hadn't even considered returning a list, just returning $HOME/Applications - at least when not running with elevated privileges. As to what users expect: has there been a poll or other evaluation of whether people actually have an expectation about what the writable ApplicationsLocation should be? It seems that given the nature of the location on OS X, there is more reason not to use the writable variant than there is to use it. It seems rather evident that applications ported from the Freedesktop universe shouldn't use ApplicationsLocation to install or search for .desktop files, for instance. One could maybe even argue that the only relevant location would be ApplicationLocation (without the 's'), which would translate to the parent of the running application's app bundle (which would be /Applications for applications installed via the App Store). As I said, app bundles are supposed to be relocatable, and /Applications is just where Apple decided to put them by default. >5.7 I think. https://codereview.qt-project.org/#/c/122044/ Time enough to incorporate a patch for 5.5.1+ and 5.6 , or do you prefer to wait until someone messes up /System/Library/Fonts by accident like I did with /Applications? ;) R From thiago.macieira at intel.com Wed Nov 11 17:48:24 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 Nov 2015 08:48:24 -0800 Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> References: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> Message-ID: <7275014.nXYofjS2uP@tjmaciei-mobl4> On Wednesday 11 November 2015 13:22:16 Massimo Callegari wrote: > 2- the configure script in the main folder gives an error on Linux. I > believe it has something to do with dos2unix carriage return. I had to copy > the one from 5.5.1 to build. .7z and .zip are meant for windows, so the text files have CRLF line-endings. If you download the .zip file, you can use the -a option to convert back from CRLF to LF. There's no such option for 7z/7za, so don't download those files for Unix usage. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aclight at gmail.com Wed Nov 11 18:41:25 2015 From: aclight at gmail.com (Adam Light) Date: Wed, 11 Nov 2015 09:41:25 -0800 Subject: [Development] Pixelated UI elements in Windows HiDPI mode (5.6) In-Reply-To: <5642F0A3.70005@theqtcompany.com> References: <5642F0A3.70005@theqtcompany.com> Message-ID: On Tue, Nov 10, 2015 at 11:39 PM, Friedemann Kleint < Friedemann.Kleint at theqtcompany.com> wrote: > Hi, > > >I don't see tickets in Jira for any of these. > > Please do not create unrelated, single tickets for each issue. Previously, > we had https://bugreports.qt.io/browse/QTBUG-40277 "Adapt styles to High > DPI" (related to https://bugreports.qt.io/browse/QTBUG-46615 "Implement > High DPI scaling v2 (5.6)"). QTBUG-40277 could be cleaned up listing the > remaining items or a new report linked to QTBUG-46615 could be created in a > similar fashion. > > Thanks. I've created a new issue for this at https://bugreports.qt.io/browse/QTBUG-49374. > Also note that the Windows styles do not support scaling (and will not for > the foreseeable future); we recommend using Fusion style (or Mac style on > OS X). > > > To be clear, I think the scaling you're talking about here is the equivalent of setting QT_SCALE_FACTOR = 2, right? That gives a different (and much worse) result than the Windows 10 "set a custom scaling level" setting. Thanks Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From faure at kde.org Wed Nov 11 19:07:17 2015 From: faure at kde.org (David Faure) Date: Wed, 11 Nov 2015 19:07:17 +0100 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> References: <2506385.IRh3OJzgst@patux> <2872195.haFMHcpolX@patux> <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> Message-ID: <1648450.gjUH6ec4DU@asterix> On Wednesday 11 November 2015 16:03:31 Petroules Jake wrote: > I mean the API returns a single value, not a list. Yes, and the value returned by writableLocation() is supposed to be user-specific (something under $HOME) rather than system-wide. So /Applications should be in QSP::standardLocations(ApplicationsLocation) but QSP::writableLocation(ApplicationsLocation) should return something under $HOME, like on XDG unixes (where it's ~/.local/share/applications). -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 From rjvbertin at gmail.com Wed Nov 11 19:45:50 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 11 Nov 2015 19:45:50 +0100 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <1648450.gjUH6ec4DU@asterix> References: <2506385.IRh3OJzgst@patux> <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> <1648450.gjUH6ec4DU@asterix> Message-ID: <24531328.HUNuU7cVT0@portia.local> On Wednesday November 11 2015 19:07:17 David Faure wrote: > Yes, and the value returned by writableLocation() is supposed to be user-specific > (something under $HOME) rather than system-wide. Agreed. > > So /Applications should be in QSP::standardLocations(ApplicationsLocation) > but QSP::writableLocation(ApplicationsLocation) should return something under > $HOME, like on XDG unixes (where it's ~/.local/share/applications). Ah, so apparently it really should be ".../share/applications" when QSP is in XDG-compliant mode. Back to the drawing board :) Anyway, here's the list of all locations, standard and writable, regular and testing, native and XDG-compliant. I'd appreciate extra pairs of eyes to check for inconsistencies or errors. Standard locations: AppConfigLocation = $HOME/Library/Preferences/qtpaths AppDataLocation = $HOME/Library/Application Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/ AppLocalDataLocation = $HOME/Library/Application Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/ ApplicationsLocation = /Applications CacheLocation = $HOME/Library/Caches/qtpaths:/Library/Caches/qtpaths ConfigLocation = $HOME/Library/Preferences DataLocation = $HOME/Library/Application Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/ DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts:/Library/Fonts:/System/Library/Fonts GenericCacheLocation = $HOME/Library/Caches:/Library/Caches GenericConfigLocation = $HOME/Library/Preferences GenericDataLocation = $HOME/Library/Application Support:/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR Standard locations, testing mode: AppConfigLocation = $HOME/.qttest/Preferences/qtpaths AppDataLocation = $HOME/.qttest/Application Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/ AppLocalDataLocation = $HOME/.qttest/Application Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/ ApplicationsLocation = /Applications CacheLocation = $HOME/.qttest/Cache/qtpaths:/Library/Caches/qtpaths ConfigLocation = $HOME/.qttest/Preferences DataLocation = $HOME/.qttest/Application Support/qtpaths:/Library/Application Support/qtpaths:/opt/local/libexec/qt5/bin/ DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts:/Library/Fonts:/System/Library/Fonts GenericCacheLocation = $HOME/.qttest/Cache:/Library/Caches GenericConfigLocation = $HOME/.qttest/Preferences GenericDataLocation = $HOME/.qttest/Application Support:/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR Writable locations: AppConfigLocation = $HOME/Library/Preferences/qtpaths AppDataLocation = $HOME/Library/Application Support/qtpaths AppLocalDataLocation = $HOME/Library/Application Support/qtpaths ApplicationsLocation = /Applications CacheLocation = $HOME/Library/Caches/qtpaths ConfigLocation = $HOME/Library/Preferences DataLocation = $HOME/Library/Application Support/qtpaths DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts GenericCacheLocation = $HOME/Library/Caches GenericConfigLocation = $HOME/Library/Preferences GenericDataLocation = $HOME/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR Writable locations, testing mode: AppConfigLocation = $HOME/.qttest/Preferences/qtpaths AppDataLocation = $HOME/.qttest/Application Support/qtpaths AppLocalDataLocation = $HOME/.qttest/Application Support/qtpaths ApplicationsLocation = /Applications CacheLocation = $HOME/.qttest/Cache/qtpaths ConfigLocation = $HOME/.qttest/Preferences DataLocation = $HOME/.qttest/Application Support/qtpaths DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts GenericCacheLocation = $HOME/.qttest/Cache GenericConfigLocation = $HOME/.qttest/Preferences GenericDataLocation = $HOME/.qttest/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR Standard locations, XDG/Freedesktop compliant mode: AppConfigLocation = $HOME/Library/Preferences/qtpaths AppDataLocation = $HOME/.local/share/qtpaths:/Library/Application Support/qtpaths:/opt/local/share/qtpaths:/opt/local/libexec/qt5/bin/ AppLocalDataLocation = $HOME/.local/share/qtpaths:/Library/Application Support/qtpaths:/opt/local/share/qtpaths:/opt/local/libexec/qt5/bin/ ApplicationsLocation = /Applications CacheLocation = $HOME/.cache/qtpaths:$HOME/.cache:/Library/Caches/qtpaths ConfigLocation = $HOME/.config:/opt/local/etc/xdg DataLocation = $HOME/.local/share/qtpaths:/Library/Application Support/qtpaths:/opt/local/share/qtpaths:/opt/local/libexec/qt5/bin/ DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts:/Library/Fonts:/System/Library/Fonts GenericCacheLocation = $HOME/.cache:$HOME/.cache:/Library/Caches GenericConfigLocation = $HOME/.config:/opt/local/etc/xdg GenericDataLocation = $HOME/.local/share:/opt/local/share:/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR Standard locations, testing + XDG/Freedesktop compliant mode: AppConfigLocation = $HOME/.qttest/Preferences/qtpaths AppDataLocation = $HOME/.qttest/.local/share/qtpaths:/Library/Application Support/qtpaths:/opt/local/share/qtpaths:/opt/local/libexec/qt5/bin/ AppLocalDataLocation = $HOME/.qttest/.local/share/qtpaths:/Library/Application Support/qtpaths:/opt/local/share/qtpaths:/opt/local/libexec/qt5/bin/ ApplicationsLocation = /Applications CacheLocation = $HOME/.qttest/.cache/qtpaths:$HOME/.cache:/Library/Caches/qtpaths ConfigLocation = $HOME/.qttest/.config:/opt/local/etc/xdg DataLocation = $HOME/.qttest/.local/share/qtpaths:/Library/Application Support/qtpaths:/opt/local/share/qtpaths:/opt/local/libexec/qt5/bin/ DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts:/Library/Fonts:/System/Library/Fonts GenericCacheLocation = $HOME/.qttest/.cache:$HOME/.cache:/Library/Caches GenericConfigLocation = $HOME/.qttest/.config:/opt/local/etc/xdg GenericDataLocation = $HOME/.qttest/.local/share:/opt/local/share:/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR Writable locations, XDG/Freedesktop compliant mode: AppConfigLocation = $HOME/Library/Preferences/qtpaths AppDataLocation = $HOME/.local/share/qtpaths AppLocalDataLocation = $HOME/.local/share/qtpaths ApplicationsLocation = /Applications CacheLocation = $HOME/.cache/qtpaths ConfigLocation = $HOME/.config DataLocation = $HOME/.local/share/qtpaths DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts GenericCacheLocation = $HOME/.cache GenericConfigLocation = $HOME/.config GenericDataLocation = $HOME/.local/share HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR Writable locations, testing + XDG/Freedesktop compliant mode: AppConfigLocation = $HOME/.qttest/Preferences/qtpaths AppDataLocation = $HOME/.qttest/.local/share/qtpaths AppLocalDataLocation = $HOME/.qttest/.local/share/qtpaths ApplicationsLocation = /Applications CacheLocation = $HOME/.qttest/.cache/qtpaths ConfigLocation = $HOME/.qttest/.config DataLocation = $HOME/.qttest/.local/share/qtpaths DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts GenericCacheLocation = $HOME/.qttest/.cache GenericConfigLocation = $HOME/.qttest/.config GenericDataLocation = $HOME/.qttest/.local/share HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR From Jake.Petroules at theqtcompany.com Wed Nov 11 20:09:58 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 11 Nov 2015 19:09:58 +0000 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <8069187.9vKdhW8Egc@patux> References: <2506385.IRh3OJzgst@patux> <2872195.haFMHcpolX@patux> <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> <8069187.9vKdhW8Egc@patux> Message-ID: On Nov 11, 2015, at 8:20 AM, René J.V. Bertin > wrote: On Wednesday November 11 2015 16:03:31 Petroules Jake wrote: I don't understand, what do you mean with "there is only one location"? I mean the API returns a single value, not a list. However, READable locations will return a list containing both $HOME/Applications and /Applications Ah. I hadn't even considered returning a list, just returning $HOME/Applications - at least when not running with elevated privileges. As to what users expect: has there been a poll or other evaluation of whether people actually have an expectation about what the writable ApplicationsLocation should be? It seems that given the nature of the location on OS X, there is more reason not to use the writable variant than there is to use it. It seems rather evident that applications ported from the Freedesktop universe shouldn't use ApplicationsLocation to install or search for .desktop files, for instance. .desktop files are not used on OS X. One could maybe even argue that the only relevant location would be ApplicationLocation (without the 's'), which would translate to the parent of the running application's app bundle (which would be /Applications for applications installed via the App Store). As I said, app bundles are supposed to be relocatable, and /Applications is just where Apple decided to put them by default. 5.7 I think. https://codereview.qt-project.org/#/c/122044/ Time enough to incorporate a patch for 5.5.1+ and 5.6 , or do you prefer to wait until someone messes up /System/Library/Fonts by accident like I did with /Applications? ;) On 10.11 you can't - SIP will block writes to /System. ;) Feel free to do whatever you like for test mode but do not change the existing writable paths. R -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Nov 11 20:27:49 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 11 Nov 2015 11:27:49 -0800 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <1648450.gjUH6ec4DU@asterix> References: <2506385.IRh3OJzgst@patux> <6E887739-6DC1-4175-83F6-D274A3CE883A@theqtcompany.com> <1648450.gjUH6ec4DU@asterix> Message-ID: <2687451.9jzZcxtj7n@tjmaciei-mobl4> On Wednesday 11 November 2015 19:07:17 David Faure wrote: > On Wednesday 11 November 2015 16:03:31 Petroules Jake wrote: > > I mean the API returns a single value, not a list. > > Yes, and the value returned by writableLocation() is supposed to be > user-specific (something under $HOME) rather than system-wide. > > So /Applications should be in QSP::standardLocations(ApplicationsLocation) > but QSP::writableLocation(ApplicationsLocation) should return something > under $HOME, like on XDG unixes (where it's ~/.local/share/applications). Assuming there's such a standard. If there isn't, it should return empty (no writable location). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From faure at kde.org Wed Nov 11 21:21:50 2015 From: faure at kde.org (David Faure) Date: Wed, 11 Nov 2015 21:21:50 +0100 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: References: <2506385.IRh3OJzgst@patux> <8069187.9vKdhW8Egc@patux> Message-ID: <2253253.MRL03PEYQ7@asterix> On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote: > Feel free to do whatever you like for test mode but do not change the existing writable paths. Jake, I would like to understand why you say that. As the QSP author and maintainer, I am 100% sure that the value of writableLocation(x) should be under $HOME. Spot the wrong value in this list of results: Writable locations: AppConfigLocation = $HOME/Library/Preferences/qtpaths AppDataLocation = $HOME/Library/Application Support/qtpaths AppLocalDataLocation = $HOME/Library/Application Support/qtpaths ApplicationsLocation = /Applications CacheLocation = $HOME/Library/Caches/qtpaths ConfigLocation = $HOME/Library/Preferences DataLocation = $HOME/Library/Application Support/qtpaths DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts GenericCacheLocation = $HOME/Library/Caches GenericConfigLocation = $HOME/Library/Preferences GenericDataLocation = $HOME/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR This is a bug, it was never intended for writableLocation to return a system-wide path. I can imagine that there is actually no use case for users writing into an ApplicationsLocation under $HOME on OSX (KDE code excluded). But in that case making the value more consistent with the other ones can't possibly hurt. -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 From Jake.Petroules at theqtcompany.com Wed Nov 11 21:37:36 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 11 Nov 2015 20:37:36 +0000 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: <2253253.MRL03PEYQ7@asterix> References: <2506385.IRh3OJzgst@patux> <8069187.9vKdhW8Egc@patux> <2253253.MRL03PEYQ7@asterix> Message-ID: On Nov 11, 2015, at 12:21 PM, David Faure > wrote: On Wednesday 11 November 2015 19:09:58 Petroules Jake wrote: Feel free to do whatever you like for test mode but do not change the existing writable paths. Jake, I would like to understand why you say that. As the QSP author and maintainer, I am 100% sure that the value of writableLocation(x) should be under $HOME. Spot the wrong value in this list of results: Writable locations: AppConfigLocation = $HOME/Library/Preferences/qtpaths AppDataLocation = $HOME/Library/Application Support/qtpaths AppLocalDataLocation = $HOME/Library/Application Support/qtpaths ApplicationsLocation = /Applications CacheLocation = $HOME/Library/Caches/qtpaths ConfigLocation = $HOME/Library/Preferences DataLocation = $HOME/Library/Application Support/qtpaths DesktopLocation = $HOME/Desktop DocumentsLocation = $HOME/Documents DownloadLocation = $HOME/Downloads FontsLocation = $HOME/Library/Fonts GenericCacheLocation = $HOME/Library/Caches GenericConfigLocation = $HOME/Library/Preferences GenericDataLocation = $HOME/Library/Application Support HomeLocation = $HOME MoviesLocation = $HOME/Movies MusicLocation = $HOME/Music PicturesLocation = $HOME/Pictures RuntimeLocation = $HOME/Library/Application Support TempLocation = $TMPDIR This is a bug, it was never intended for writableLocation to return a system-wide path. I can imagine that there is actually no use case for users writing into an ApplicationsLocation under $HOME on OSX (KDE code excluded). But in that case making the value more consistent with the other ones can't possibly hurt. Yes, I can agree with that -- it's completely useless to anyone, but consistent. Also, I was mistaken -- writableDirectory does indeed return $HOME/Applications now with my patch as everything is routed through the same mechanism (using NSUserDomainMask). What we SHOULD have in Qt is something similar to NSSearchPathDomainMask so we could have a little more fine grained control. Maybe a user WANTS to write to locations in the local domain instead of the user domain (and in some cases, you DO -- like Applications). -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Nov 11 22:45:27 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 11 Nov 2015 22:45:27 +0100 Subject: [Development] QStandardPaths::writableLocation() on OSX in test mode In-Reply-To: References: <2506385.IRh3OJzgst@patux> <2253253.MRL03PEYQ7@asterix> Message-ID: <1579645.Rqy7HoxgdA@portia.local> On Wednesday November 11 2015 20:37:36 Petroules Jake wrote: > What we SHOULD have in Qt is something similar to NSSearchPathDomainMask so we could have a little more fine grained control. Maybe a user WANTS to write to locations in the local domain instead of the user domain (and in some cases, you DO -- like Applications). I'm not sure if writing to /Applications is the best use case example. We'd be talking about some sort of application manager I suppose, and wouldn't that be the kind of application that's so specific that you'd prefer to avoid "precooked" functions to determine destination paths? (On OS X you'd probably want to make the destination a setting, even.) Anyway, if and when you start thinking about that kind of modification, maybe we could re-open the discussion about a way to get QSP to return XDG-compliant locations? R. PS Jake: your emails make no distinction between quoted text and your replies in plain-text representation. From jani.heikkinen at theqtcompany.com Thu Nov 12 09:10:25 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 12 Nov 2015 08:10:25 +0000 Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> References: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, Thanks for feedback, some comments below Br, Jani >>-----Original Message----- >>From: Massimo Callegari [mailto:massimocallegari at yahoo.it] >>Sent: 11. marraskuuta 2015 15:22 >>To: Heikkinen Jani ; development at qt- >>project.org >>Subject: Re: [Development] New Qt 5.6 Beta snapshot available >> >>Hi, I think there something wrong with the sources package Nov 10th (I >>downloaded the 7z one) >> >>1- the folder name is 'releaseexporttools_src_work_win" instead of "qt- >>everywhere-opensource-5.6.0" >> [Heikkinen Jani] This is known issue and will be fixed later >>2- the configure script in the main folder gives an error on Linux. I believe it has >>something to do with dos2unix carriage return. I had to copy the one from 5.5.1 >>to build. >> [Heikkinen Jani] As Thiago already replied, .7z package is with windows line endings >>3- all the submodules are missing the examples folder [Heikkinen Jani] Nice finding! Please write an error report to the Jira >> >>I know it's still a snapshot, but I just wanted to report what I found. >> >>Thanks >>Massimo >> >>________________________________ >>Da: Heikkinen Jani >>A: "development at qt-project.org" >>Inviato: Mercoledì 11 Novembre 2015 8:39 >>Oggetto: [Development] New Qt 5.6 Beta snapshot available >> >> >> >> >>Hi all, >> >>New Qt5.6 Beta snapshot available in >>http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/ >> >>Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/253/ >> >>Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/275/ >>Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/203/ >> >>src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ >> >> >> >>Unfortunately these aren't yet final beta packages but should be pretty close so >>please test these packages and report all beta blockers immediately: We are >>targeting to put beta out as soon as possible, preferably already during next >>week. >> >>These packages contain now QtCreator 3.6.0-RC snapshot. >> >>RTA testing still ongoing but according to smoke test results packages seems to >>be ok for wider testing >> >> >>Known issues: >> >>- https://bugreports.qt.io/browse/QTBUG-47958 :Issues to be fixed before Qt >>5.6.0 Beta >> >>- There might be some issues with kits in the creator: during the smoke testing >>some users have seen problems with compiler (auto)detection (and some users >>haven't) >>- New tech preview components not seen in installer UI >> >>br, >>Jani >> >>_______________________________________________ >>Development mailing list >>Development at qt-project.org >>http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at theqtcompany.com Thu Nov 12 09:12:06 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Thu, 12 Nov 2015 08:12:06 +0000 Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: References: <1072699129.5044387.1447248136462.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, Splitted src packages are under work. Most probably we won’t have those for beta but for RC. Is that OK? Br, Jani From: Development [mailto:development-bounces at qt-project.org] On Behalf Of Helio Chissini de Castro Sent: 11. marraskuuta 2015 15:36 To: development at qt-project.org Subject: Re: [Development] New Qt 5.6 Beta snapshot available And for us, distributions, we need at least splitted source codes. We just CAN'T test our packages the way is deployed now. On Wed, Nov 11, 2015 at 11:22 AM, Massimo Callegari > wrote: Hi, I think there something wrong with the sources package Nov 10th (I downloaded the 7z one) 1- the folder name is 'releaseexporttools_src_work_win" instead of "qt-everywhere-opensource-5.6.0" 2- the configure script in the main folder gives an error on Linux. I believe it has something to do with dos2unix carriage return. I had to copy the one from 5.5.1 to build. 3- all the submodules are missing the examples folder I know it's still a snapshot, but I just wanted to report what I found. Thanks Massimo ________________________________ Da: Heikkinen Jani > A: "development at qt-project.org" > Inviato: Mercoledì 11 Novembre 2015 8:39 Oggetto: [Development] New Qt 5.6 Beta snapshot available Hi all, New Qt5.6 Beta snapshot available in http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/253/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/275/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/203/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Unfortunately these aren't yet final beta packages but should be pretty close so please test these packages and report all beta blockers immediately: We are targeting to put beta out as soon as possible, preferably already during next week. These packages contain now QtCreator 3.6.0-RC snapshot. RTA testing still ongoing but according to smoke test results packages seems to be ok for wider testing Known issues: - https://bugreports.qt.io/browse/QTBUG-47958 :Issues to be fixed before Qt 5.6.0 Beta - There might be some issues with kits in the creator: during the smoke testing some users have seen problems with compiler (auto)detection (and some users haven't) - New tech preview components not seen in installer UI br, Jani _______________________________________________ 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 massimocallegari at yahoo.it Thu Nov 12 10:04:12 2015 From: massimocallegari at yahoo.it (Massimo Callegari) Date: Thu, 12 Nov 2015 09:04:12 +0000 (UTC) Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: References: Message-ID: <475246226.5744907.1447319052131.JavaMail.yahoo@mail.yahoo.com> >> 2- the configure script in the main folder gives an error on Linux. I believe it has >> something to do with dos2unix carriage return. I had to copy the one from 5.5.1 >> to build. >> > [Heikkinen Jani] As Thiago already replied, .7z package is with windows line endings I am a bit puzzled by this news. I have always downloaded 7z packages for size and time-to-download reasons, and never had this issue before. As I said, using the configure script from the 5.5.1 7z archive works as expected. In general I'd expect no difference in the contents of the different archive types. Windows users won't even use the configure script, but configure.bat. ________________________________ Da: Heikkinen Jani A: Massimo Callegari ; "development at qt-project.org" Inviato: Giovedì 12 Novembre 2015 9:10 Oggetto: RE: [Development] New Qt 5.6 Beta snapshot available Hi, Thanks for feedback, some comments below Br, Jani >>-----Original Message----- >>From: Massimo Callegari [mailto:massimocallegari at yahoo.it] >>Sent: 11. marraskuuta 2015 15:22 >>To: Heikkinen Jani ; development at qt- >>project.org >>Subject: Re: [Development] New Qt 5.6 Beta snapshot available >> >>Hi, I think there something wrong with the sources package Nov 10th (I >>downloaded the 7z one) >> >>1- the folder name is 'releaseexporttools_src_work_win" instead of "qt- >>everywhere-opensource-5.6.0" >> [Heikkinen Jani] This is known issue and will be fixed later >>2- the configure script in the main folder gives an error on Linux. I believe it has >>something to do with dos2unix carriage return. I had to copy the one from 5.5.1 >>to build. >> [Heikkinen Jani] As Thiago already replied, .7z package is with windows line endings >>3- all the submodules are missing the examples folder [Heikkinen Jani] Nice finding! Please write an error report to the Jira >> >>I know it's still a snapshot, but I just wanted to report what I found. >> >>Thanks >>Massimo >> >>________________________________ >>Da: Heikkinen Jani >>A: "development at qt-project.org" >>Inviato: Mercoledì 11 Novembre 2015 8:39 >>Oggetto: [Development] New Qt 5.6 Beta snapshot available >> >> >> >> >>Hi all, >> >>New Qt5.6 Beta snapshot available in >>http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/ >> >>Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/253/ >> >>Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/275/ >>Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/203/ >> >>src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ >> >> >> >>Unfortunately these aren't yet final beta packages but should be pretty close so >>please test these packages and report all beta blockers immediately: We are >>targeting to put beta out as soon as possible, preferably already during next >>week. >> >>These packages contain now QtCreator 3.6.0-RC snapshot. >> >>RTA testing still ongoing but according to smoke test results packages seems to >>be ok for wider testing >> >> >>Known issues: >> >>- https://bugreports.qt.io/browse/QTBUG-47958 :Issues to be fixed before Qt >>5.6.0 Beta >> >>- There might be some issues with kits in the creator: during the smoke testing >>some users have seen problems with compiler (auto)detection (and some users >>haven't) >>- New tech preview components not seen in installer UI >> >>br, >>Jani >> >>_______________________________________________ >>Development mailing list >>Development at qt-project.org >>http://lists.qt-project.org/mailman/listinfo/development From paul.tvete at theqtcompany.com Thu Nov 12 12:28:48 2015 From: paul.tvete at theqtcompany.com (Paul Olav Tvete) Date: Thu, 12 Nov 2015 12:28:48 +0100 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <5988055.d1hRm4RkbG@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <83A9B8CB-DB9A-4103-AE12-C724BA4E9AE0@theqtcompany.com> <5988055.d1hRm4RkbG@tjmaciei-mobl4> Message-ID: <6406388.xuKpzhV9DI@dragaera> On Friday 6. November 2015 10.10.52 Thiago Macieira wrote: > But before I go and modify QFactoryLoader... what is that class for? Can > anyone find out from the old history? It traces its existence back to "Long > live Qt 4.5". Added by Matthias in commit 89df363e4a795d67342d04e478af592618e16363 at Thu May 6 13:28:09 2004 "added the new plugin stuff. Not yet used, not yet compiled." Hope that helps. :p But seriously, there does not seem to be a lot more information in the old history than what's in the code today. - Paul From Lars.Knoll at theqtcompany.com Thu Nov 12 12:54:14 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 12 Nov 2015 11:54:14 +0000 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <6406388.xuKpzhV9DI@dragaera> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <83A9B8CB-DB9A-4103-AE12-C724BA4E9AE0@theqtcompany.com> <5988055.d1hRm4RkbG@tjmaciei-mobl4> <6406388.xuKpzhV9DI@dragaera> Message-ID: On 12/11/15 12:28, "Development on behalf of Paul Olav Tvete" wrote: >On Friday 6. November 2015 10.10.52 Thiago Macieira wrote: >> But before I go and modify QFactoryLoader... what is that class for? Can >> anyone find out from the old history? It traces its existence back to "Long >> live Qt 4.5". > >Added by Matthias in commit 89df363e4a795d67342d04e478af592618e16363 at Thu >May 6 13:28:09 2004 > >"added the new plugin stuff. Not yet used, not yet compiled." > >Hope that helps. :p > >But seriously, there does not seem to be a lot more information in the old >history than what's in the code today. Most of that code is 8 years old by now, and some of the reasons for having these things separated have most probably disappeared by now. Let's simply look at things from todays perspective :) Cheers, Lars From eskil.abrahamsen-blomfeldt at theqtcompany.com Thu Nov 12 13:59:08 2015 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil A. Blomfeldt) Date: Thu, 12 Nov 2015 13:59:08 +0100 Subject: [Development] Qt Purchasing in Qt 5.7 Was: Qt Purchasing in Qt 5.6 In-Reply-To: <55C07B37.5030807@theqtcompany.com> References: <55C07B37.5030807@theqtcompany.com> Message-ID: <56448D1C.10102@theqtcompany.com> On 04. aug. 2015 10:43, Eskil Abrahamsen Blomfeldt wrote: > Hi, > > Qt Purchasing is a commercial add-on module developed by The Qt Company > which implements a cross-platform API for in-app purchases on iOS and > Android. In order to make it easier for third parties to contribute new > backends for the API, we want to release it in the Qt Project under > LGPLv3/GPLv2/Commercial. I propose to include it as part of Qt 5.6.0. Trying this again with Qt 5.7 in case it wasn't obvious from the previous discussion :) The code has been available for several months now, and good feedback and contributions have been made. -- Eskil From edward.sutton at subsite.com Thu Nov 12 15:24:27 2015 From: edward.sutton at subsite.com (Edward Sutton) Date: Thu, 12 Nov 2015 14:24:27 +0000 Subject: [Development] New Qt 5.6.0 Beta snapshot available In-Reply-To: References: Message-ID: <87D82020-987E-4292-8930-212EF49E3E0F@subsite.com> I installed Qt 5.6 beta on OS X 10.10.5 with Xcode 7.1.1. ( I also have Qt 5.5.1 commercial installed. ) It works fine if I open, build, and run a Qt Example app using Qt Creator 3.5.82 (3.6.0-rc1). However when I open an existing Qt project or create a new Qt Widgets Application with Qt Creator 3.5.82 (3.6.0-rc1) I get following error: 08:16:48: Running steps for project qt5-6-beta-widgets... 08:16:48: Starting: "/Users/edward3/Qt5.6.0/5.6/clang_64/bin/qmake" /Users/edward3/Documents/projects/qt5-6-beta-widgets/qt5-6-beta-widgets.pro -r -spec macx-clang CONFIG+=debug CONFIG+=x86_64 CONFIG+=qml_debug Info: creating stash file /Users/edward3/Documents/projects/build-qt5-6-beta-widgets-Desktop_Qt_5_6_0_clang_64bit-Debug/.qmake.stash dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore Referenced from: /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic Reason: image not found sh: line 1: 1965 Trace/BPT trap: 5 /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic -d ../qt5-6-beta-widgets/mainwindow.ui 08:16:49: The process "/Users/edward3/Qt5.6.0/5.6/clang_64/bin/qmake" exited normally. 08:16:49: Starting: "/usr/bin/make" /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic ../qt5-6-beta-widgets/mainwindow.ui -o ui_mainwindow.h dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore Referenced from: /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic Reason: image not found make: *** [ui_mainwindow.h] Trace/BPT trap: 5 08:16:50: The process "/usr/bin/make" exited with code 2. Error while building/deploying project qt5-6-beta-widgets (kit: Desktop Qt 5.6.0 clang 64bit) When executing step "Make" 08:16:50: Elapsed time: 00:01. -Ed On Nov 3, 2015, at 6:06 AM, Heikkinen Jani > wrote: Hi all, We have new Qt 5.6.0 beta snapshot available, Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/241/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/265/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/198/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Please test these packages carefully and inform me immediately all beta blockers which aren't already linked inhttps://bugreports.qt.io/browse/QTBUG-47958 . br, Jani _______________________________________________ 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 Richard.Gustavsen at theqtcompany.com Thu Nov 12 15:36:28 2015 From: Richard.Gustavsen at theqtcompany.com (Gustavsen Richard) Date: Thu, 12 Nov 2015 14:36:28 +0000 Subject: [Development] New Qt 5.6.0 Beta snapshot available In-Reply-To: <87D82020-987E-4292-8930-212EF49E3E0F@subsite.com> References: , <87D82020-987E-4292-8930-212EF49E3E0F@subsite.com> Message-ID: https://codereview.qt-project.org/#/c/140650/ -Richard ________________________________ Fra: Development på vegne av Edward Sutton Sendt: 12. november 2015 15:24 Til: Heikkinen Jani Kopi: development at qt-project.org Emne: Re: [Development] New Qt 5.6.0 Beta snapshot available I installed Qt 5.6 beta on OS X 10.10.5 with Xcode 7.1.1. ( I also have Qt 5.5.1 commercial installed. ) It works fine if I open, build, and run a Qt Example app using Qt Creator 3.5.82 (3.6.0-rc1). However when I open an existing Qt project or create a new Qt Widgets Application with Qt Creator 3.5.82 (3.6.0-rc1) I get following error: 08:16:48: Running steps for project qt5-6-beta-widgets... 08:16:48: Starting: "/Users/edward3/Qt5.6.0/5.6/clang_64/bin/qmake" /Users/edward3/Documents/projects/qt5-6-beta-widgets/qt5-6-beta-widgets.pro -r -spec macx-clang CONFIG+=debug CONFIG+=x86_64 CONFIG+=qml_debug Info: creating stash file /Users/edward3/Documents/projects/build-qt5-6-beta-widgets-Desktop_Qt_5_6_0_clang_64bit-Debug/.qmake.stash dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore Referenced from: /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic Reason: image not found sh: line 1: 1965 Trace/BPT trap: 5 /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic -d ../qt5-6-beta-widgets/mainwindow.ui 08:16:49: The process "/Users/edward3/Qt5.6.0/5.6/clang_64/bin/qmake" exited normally. 08:16:49: Starting: "/usr/bin/make" /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic ../qt5-6-beta-widgets/mainwindow.ui -o ui_mainwindow.h dyld: Library not loaded: @rpath/QtCore.framework/Versions/5/QtCore Referenced from: /Users/edward3/Qt5.6.0/5.6/clang_64/bin/uic Reason: image not found make: *** [ui_mainwindow.h] Trace/BPT trap: 5 08:16:50: The process "/usr/bin/make" exited with code 2. Error while building/deploying project qt5-6-beta-widgets (kit: Desktop Qt 5.6.0 clang 64bit) When executing step "Make" 08:16:50: Elapsed time: 00:01. -Ed On Nov 3, 2015, at 6:06 AM, Heikkinen Jani > wrote: Hi all, We have new Qt 5.6.0 beta snapshot available, Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/241/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/265/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/198/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ Please test these packages carefully and inform me immediately all beta blockers which aren't already linked inhttps://bugreports.qt.io/browse/QTBUG-47958 . br, Jani _______________________________________________ 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 Thu Nov 12 18:58:15 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 12 Nov 2015 09:58:15 -0800 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <6406388.xuKpzhV9DI@dragaera> Message-ID: <1748248.nBNTKpL47S@tjmaciei-mobl4> On Thursday 12 November 2015 11:54:14 Knoll Lars wrote: > On 12/11/15 12:28, "Development on behalf of Paul Olav Tvete" wrote: > >On Friday 6. November 2015 10.10.52 Thiago Macieira wrote: > >> But before I go and modify QFactoryLoader... what is that class for? Can > >> anyone find out from the old history? It traces its existence back to > >> "Long > >> live Qt 4.5". > > > >Added by Matthias in commit 89df363e4a795d67342d04e478af592618e16363 at Thu > >May 6 13:28:09 2004 > > > >"added the new plugin stuff. Not yet used, not yet compiled." > > > >Hope that helps. :p > > > >But seriously, there does not seem to be a lot more information in the old > >history than what's in the code today. > > Most of that code is 8 years old by now, and some of the reasons for having > these things separated have most probably disappeared by now. Let's simply > look at things from todays perspective :) Ok, thanks. I'll disable plugin unloading in QFactoryLoader in 5.6. We can look into merging it with QPluginLoader later. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 12 18:59:41 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 12 Nov 2015 09:59:41 -0800 Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: References: Message-ID: <1516314.lH2tU0ZbQm@tjmaciei-mobl4> On Thursday 12 November 2015 08:12:06 Heikkinen Jani wrote: > Splitted src packages are under work. Most probably we won’t have those for > beta but for RC. Is that OK? No. As agreed during the 5.0 release cycle, the official release is the split packages and big .tar.gz is a convenience. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Thu Nov 12 19:05:28 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 12 Nov 2015 10:05:28 -0800 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <1748248.nBNTKpL47S@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> <1748248.nBNTKpL47S@tjmaciei-mobl4> Message-ID: <2759209.8CIPFQt2Ga@tjmaciei-mobl4> On Thursday 12 November 2015 09:58:15 Thiago Macieira wrote: > Ok, thanks. I'll disable plugin unloading in QFactoryLoader in 5.6. We can > look into merging it with QPluginLoader later. Actually, I've just seen the difference. ~QPluginLoader: if (d) d->release(); ~QFactoryLoaderPrivate: for (int i = 0; i < libraryList.count(); ++i) { QLibraryPrivate *library = libraryList.at(i); library->unload(); library->release(); } A QPluginLoader loads one plugin. A QFactoryLoader loads all plugins matching a given filter. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From annulen at yandex.ru Thu Nov 12 20:06:43 2015 From: annulen at yandex.ru (Konstantin Tokarev) Date: Thu, 12 Nov 2015 22:06:43 +0300 Subject: [Development] New Qt 5.6 Beta snapshot available In-Reply-To: <475246226.5744907.1447319052131.JavaMail.yahoo@mail.yahoo.com> References: <475246226.5744907.1447319052131.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1231851447355203@web15j.yandex.ru> 12.11.2015, 12:04, "Massimo Callegari" : >>>  2- the configure script in the main folder gives an error on Linux. I believe it has >>>  something to do with dos2unix carriage return. I had to copy the one from 5.5.1 >>>  to build. >>  [Heikkinen Jani] As Thiago already replied, .7z package is with windows line endings > > I am a bit puzzled by this news. > I have always downloaded 7z packages for size and time-to-download reasons, and never had this issue before. > As I said, using the configure script from the 5.5.1 7z archive works as expected. > > In general I'd expect no difference in the contents of the different archive types. Windows users won't even use the configure script, but configure.bat. It would be nice to have tar.xz for non-Windows users btw. -- Regards, Konstantin From thiago.macieira at intel.com Thu Nov 12 21:54:13 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 12 Nov 2015 12:54:13 -0800 Subject: [Development] RFD: plugins vs QStringLiterals In-Reply-To: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> References: <2035479.oFNpaQ3XJG@tjmaciei-mobl4> Message-ID: <2402698.Mpnk7bklrb@tjmaciei-mobl4> On Thursday 05 November 2015 11:44:33 Thiago Macieira wrote: > 3) Never unload any plugins, possibly also compiling our own libraries and > plugins with -z nodelete. Solves most of the problems, including the C++ > vtable case. Patch for QPluginLoader and QFactoryLoader: https://codereview.qt-project.org/140750 Do we want to add -z nodelete? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Nov 13 19:25:54 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 13 Nov 2015 10:25:54 -0800 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <3143FB29-5622-40A1-B95F-1DD29179CAD8@theqtcompany.com> References: <201511110041.23805.marc.mutz@kdab.com> <3143FB29-5622-40A1-B95F-1DD29179CAD8@theqtcompany.com> Message-ID: <1662337.Mca6AmMWLk@tjmaciei-mobl4> On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > Fully agree to that. But as long as we can’t execute autotests on all > platforms in the CI someone will need to manually check those on some of > the target platforms if we extend the set of features used. They can be added to config.tests/unix/stl. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Fri Nov 13 19:37:25 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 13 Nov 2015 10:37:25 -0800 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: References: <1567522.7rxADYjp0Y@finn> Message-ID: <2179031.L5GMPoFkkI@tjmaciei-mobl4> On Tuesday 10 November 2015 20:22:28 Knoll Lars wrote: > At least for now, I don't want us to rely too much on standard library > features in our APIs (ie. Using these types in the APIs we expose to our > users). > > But I am not opposed to using any of these features in our implementation, > if they work on all platforms we currently support with Qt 5.7. Hi Lars To confirm: some of the use we're talking about is in public headers, such as std::enable_if and . They don't affect our API and ABI, but they require the user to have the ability in question in order to compile their application. I don't think this changes your recommendation, but I wanted to clarify. One more thing: I'd like a whitelist of features that have been tested and are known to work on all platforms. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From frank.richter at gmail.com Sat Nov 14 14:03:49 2015 From: frank.richter at gmail.com (Frank Richter) Date: Sat, 14 Nov 2015 13:03:49 +0000 Subject: [Development] Contribution: Windows Stock Icons Message-ID: Hello everybody, I made some (non-trivial) changes to the Windows stock icon implementation. The goals were 1. Use public/"modern" APIs as much as possible to obtain the icons. 2. Make the various different resolutions stock icons are provided in available to Qt. For the first goal I changed to code to use SHGetStockIconInfo as much as possible and shell item icons for some other icons; hardcoded resource IDs and the legacy IDI_ icons are only used as a last resort. (It's worth mentioning that the IDI_ icons will only return "Windows 7" style icons; for the new Windows 8 icons you need to use SHGetStockIconInfo. For the second goal I added an icon engine that looks at some raw icon resource data to load all available sizes. To expose all those sizes I added a platform theme method to return an icon engine for a stock icon. Of course I'd very much like to see this make it; however, I think that before starting to submit individual patches for review maybe a bit of "approach review" might be a good idea. * Are these changes desireable? * What do you think of returning icon engines from the platform theme? * And what about the more bare-metal icon loading? For the time being I uploaded the changes (in order of evolving implementation) to github: https://github.com/res2k/qtbase/commits/dev Looking forward to your feedback, - Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From marc.mutz at kdab.com Sat Nov 14 20:42:18 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Sat, 14 Nov 2015 20:42:18 +0100 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <1662337.Mca6AmMWLk@tjmaciei-mobl4> References: <3143FB29-5622-40A1-B95F-1DD29179CAD8@theqtcompany.com> <1662337.Mca6AmMWLk@tjmaciei-mobl4> Message-ID: <201511142042.18819.marc.mutz@kdab.com> On Friday 13 November 2015 19:25:54 Thiago Macieira wrote: > On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > > Fully agree to that. But as long as we can’t execute autotests on all > > platforms in the CI someone will need to manually check those on some of > > the target platforms if we extend the set of features used. > > They can be added to config.tests/unix/stl. Why (just) 'unix'? -- 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 Nov 14 19:43:20 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sat, 14 Nov 2015 10:43:20 -0800 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <201511142042.18819.marc.mutz@kdab.com> References: <1662337.Mca6AmMWLk@tjmaciei-mobl4> <201511142042.18819.marc.mutz@kdab.com> Message-ID: <2891408.bXjDo4jcjm@tjmaciei-mobl4> On Saturday 14 November 2015 20:42:18 Marc Mutz wrote: > On Friday 13 November 2015 19:25:54 Thiago Macieira wrote: > > On Wednesday 11 November 2015 08:43:57 Knoll Lars wrote: > > > Fully agree to that. But as long as we can’t execute autotests on all > > > platforms in the CI someone will need to manually check those on some of > > > the target platforms if we extend the set of features used. > > > > They can be added to config.tests/unix/stl. > > Why (just) 'unix'? That's where it's always been. config.tests/common didn't show up until 5.0. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From jianliang79 at gmail.com Sun Nov 15 15:19:48 2015 From: jianliang79 at gmail.com (Liang Jian) Date: Sun, 15 Nov 2015 22:19:48 +0800 Subject: [Development] [Qt-5.6] leak of QtSharedPointer::ExternalRefCountData objects Message-ID: Hello everyone, I checkout qt 5.6 branch yesterday in my windows 10 x64 machine, I build it and run my program and see many leaks. Then I use C++ Memory Validator to find the source of the leaks, I can now confirm the leaked objects are QtSharedPointer::ExternalRefCountData which are created in QQmlObjectCreator::createInstance(), qqmlobjectcreator.cpp Line 1049, below is the call stack printed by C++ Memory Validator: Qt5Cored.dll QtSharedPointer::ExternalRefCountData::getAndRef : [d:\qt5\qtbase\src\corelib\tools\qsharedpointer.cpp Line 1337] Qt5Qmld.dll QWeakPointer::QWeakPointer : [d:\qt5\qtbase\src\corelib\tools\qsharedpointer_impl.h Line 706] Qt5Qmld.dll QPointer::QPointer : [d:\qt5\qtbase\src\corelib\kernel\qpointer.h Line 65] Qt5Qmld.dll QQmlObjectCreator::createInstance : [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 1049] 1044 : QQmlData *ddata = QQmlData::get(instance, /*create*/true); 1045 : ddata->rootObjectInCreation = true; 1046 : sharedState->rootContext->isRootObjectInCreation = false; 1047 : } 1048 : 1049 : sharedState->allCreatedObjects.push(instance); 1050 : } else { 1051 : Q_ASSERT(typeRef->component); 1052 : Q_QML_OC_PROFILE(sharedState->profiler, profiler.update(typeRef->component->fileName(), 1053 : context->url(), obj->location.line, obj->location.column)); 1054 : if (typeRef->component->compilationUnit->data->isSingleton()) Qt5Qmld.dll QQmlObjectCreator::create : [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 197] Qt5Qmld.dll QQmlComponentPrivate::beginCreate : [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 863] Qt5Qmld.dll QQmlComponent::beginCreate : [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 812] Qt5Qmld.dll QQmlComponent::create : [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 772] Qt5Quickd.dll QQuickView::continueExecute : [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 486] Qt5Quickd.dll QQuickViewPrivate::execute : [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 127] Qt5Quickd.dll QQuickView::setSource : [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 256] All the leaked QtSharedPointer::ExternalRefCountData objects are allocated in the line sharedState->allCreatedObjects.push(instance); then some other code path will also use QPointer (contained in some structures allocated by v4mm) to track the same object 'instance' and I guess the QPointer wasn't properly destructed which will cause the QtSharedPointer::ExternalRefCountData not deleted. I have investigated this issue for nearly one day, but I can't find which code cause the leak, this is a non-trivial leak, I hope somebody can help to find the source of the leak. thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From jianliang79 at gmail.com Sun Nov 15 16:58:58 2015 From: jianliang79 at gmail.com (Liang Jian) Date: Sun, 15 Nov 2015 23:58:58 +0800 Subject: [Development] [Qt-5.6] leak of QtSharedPointer::ExternalRefCountData objects In-Reply-To: References: Message-ID: After some further investigation I can now confirm that one of the leak is caused by the following code in QQmlObjectCreator::createInstance(), qqmlobjectcreator.cpp: *sharedState->allJavaScriptObjects = QV4::QObjectWrapper::wrap(v4, instance); ++sharedState->allJavaScriptObjects; But the reason is still unknown On Sun, Nov 15, 2015 at 10:19 PM, Liang Jian wrote: > Hello everyone, I checkout qt 5.6 branch yesterday in my windows 10 > x64 machine, I build it and run my program and see many leaks. Then I use C++ > Memory Validator to find the source of the leaks, I can now confirm the > leaked objects are QtSharedPointer::ExternalRefCountData which are created > in QQmlObjectCreator::createInstance(), qqmlobjectcreator.cpp Line 1049, > below is the call stack printed by C++ Memory Validator: > > Qt5Cored.dll QtSharedPointer::ExternalRefCountData::getAndRef : > [d:\qt5\qtbase\src\corelib\tools\qsharedpointer.cpp Line 1337] > > Qt5Qmld.dll QWeakPointer::QWeakPointer : > [d:\qt5\qtbase\src\corelib\tools\qsharedpointer_impl.h Line 706] > > Qt5Qmld.dll QPointer::QPointer : > [d:\qt5\qtbase\src\corelib\kernel\qpointer.h Line 65] > > Qt5Qmld.dll QQmlObjectCreator::createInstance : > [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 1049] > 1044 : QQmlData *ddata = QQmlData::get(instance, > /*create*/true); > 1045 : ddata->rootObjectInCreation = true; > 1046 : > sharedState->rootContext->isRootObjectInCreation = false; > 1047 : } > 1048 : > 1049 : sharedState->allCreatedObjects.push(instance); > 1050 : } else { > 1051 : Q_ASSERT(typeRef->component); > 1052 : Q_QML_OC_PROFILE(sharedState->profiler, > profiler.update(typeRef->component->fileName(), > 1053 : context->url(), obj->location.line, > obj->location.column)); > 1054 : if > (typeRef->component->compilationUnit->data->isSingleton()) > Qt5Qmld.dll QQmlObjectCreator::create : > [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 197] > > Qt5Qmld.dll QQmlComponentPrivate::beginCreate : > [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 863] > > Qt5Qmld.dll QQmlComponent::beginCreate : > [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 812] > > Qt5Qmld.dll QQmlComponent::create : > [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 772] > > Qt5Quickd.dll QQuickView::continueExecute : > [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 486] > > Qt5Quickd.dll QQuickViewPrivate::execute : > [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 127] > > Qt5Quickd.dll QQuickView::setSource : > [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 256] > > > All the leaked QtSharedPointer::ExternalRefCountData objects are > allocated in the line > sharedState->allCreatedObjects.push(instance); > then some other code path will also use QPointer (contained in some > structures allocated by v4mm) to track the same object 'instance' and I > guess the QPointer wasn't properly destructed which will cause the QtSharedPointer::ExternalRefCountData > not deleted. > I have investigated this issue for nearly one day, but I can't find > which code cause the leak, this is a non-trivial leak, I hope somebody can > help to find the source of the leak. thanks! > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jani.heikkinen at theqtcompany.com Mon Nov 16 09:44:32 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Mon, 16 Nov 2015 08:44:32 +0000 Subject: [Development] New qt5.6 beta snapshot available In-Reply-To: References: Message-ID: Hi all, We have again new 5.6 beta snapshot available in http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/203/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/275/ Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/253/ src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ These aren't yet final beta packages but please test these & report all new blocker immediately known issues: * Still missing: ** Win MSVC 2015 x86 (binaries available, packaging needs to be fixed, ongoing) ** WinPhone x86 binaries still missing from WinRT MSVC 2013 (No binaries from coin yet) Some beta blockers should be fixed but there is still some blocker issues open in https://bugreports.qt.io/browse/QTBUG-47958 * QTBUG-49349 WinRT: No app starting on Windows 10 Mobile 10581 ** Fix availabe & waiting for qt5.git integration * QTBUG-49197 WinRT: MSVC2015 installer does not contain arm build ** Binaries available, installer confs needs to be fixed * QTBUG-49226 Unsatisfied dependencies to system libraries ** Should be fixed, needs to be verified * QTBUG-49367 QtAndroidBluetooth-bundled.jar missing from 5.6 beta Mac installer ** Fixing ongoing * QTBUG-48914 Qt5.6 offline: plugins/mediaservice/ libs missing ** Fix available but approved yet * QTBUG-49368 Windows Phone Emulator (x86) Qt version missing from installer ** Fix availabe & waiting for qt5.git integration * QTBUG-49211 [REG 5.5->5.6] Cannot find documentation specification file .../qtenginiooverview.qdocconf when building s ** Should be fixed, needs to be verified * QTBUG-49369 Several Qt tools fail to find QtCore ** Fix available but not in yet. * QTBUG-48915 Qt5.6 offline: Enginio missing from android targets ** Still valid issue * QTBUG-49362 winrt: windows phone kit does not have valid device set ** Should be fixed, needs to be verified * QTBUG-49366 [Reg 5.5->5.6]: Cannot compile apps with sql for iOS ** Study ongoing * QTBUG-49422 Qt5.6 offline: Qt53DCollision lib missing ** Study request sent * QTCREATORBUG-15330 winrt: combined c++ and qml debugging fails ** Fix under review * QTBUG-45662 Add qtbase/bin/fixqt4headers.pl to packages ** Fix availabe & waiting for qt5.git integration br, Jani -------------- next part -------------- An HTML attachment was scrubbed... URL: From jianliang79 at gmail.com Mon Nov 16 16:01:30 2015 From: jianliang79 at gmail.com (Liang Jian) Date: Mon, 16 Nov 2015 23:01:30 +0800 Subject: [Development] [Qt-5.6] leak of QtSharedPointer::ExternalRefCountData objects In-Reply-To: References: Message-ID: The allocated QV4::QObjectWrapper object hold a QPointer which track 'instance', it seems that it should be destroyed with QObjectWrapper::destroyObject() to properly destruct the QPointer in it in QV4::MemoryManager::sweep(). But when sweep() is being called it couldn't find the QObjectWrapper object created before which will make the QPointer in it not destructed properly. On Sun, Nov 15, 2015 at 11:58 PM, Liang Jian wrote: > After some further investigation I can now confirm that one of the > leak is caused by the following code in QQmlObjectCreator::createInstance(), > qqmlobjectcreator.cpp: > > *sharedState->allJavaScriptObjects = QV4::QObjectWrapper::wrap(v4, > instance); > > ++sharedState->allJavaScriptObjects; > > > But the reason is still unknown > > > > On Sun, Nov 15, 2015 at 10:19 PM, Liang Jian > wrote: > >> Hello everyone, I checkout qt 5.6 branch yesterday in my windows 10 >> x64 machine, I build it and run my program and see many leaks. Then I use C++ >> Memory Validator to find the source of the leaks, I can now confirm the >> leaked objects are QtSharedPointer::ExternalRefCountData which are created >> in QQmlObjectCreator::createInstance(), qqmlobjectcreator.cpp Line 1049, >> below is the call stack printed by C++ Memory Validator: >> >> Qt5Cored.dll QtSharedPointer::ExternalRefCountData::getAndRef : >> [d:\qt5\qtbase\src\corelib\tools\qsharedpointer.cpp Line 1337] >> >> Qt5Qmld.dll QWeakPointer::QWeakPointer : >> [d:\qt5\qtbase\src\corelib\tools\qsharedpointer_impl.h Line 706] >> >> Qt5Qmld.dll QPointer::QPointer : >> [d:\qt5\qtbase\src\corelib\kernel\qpointer.h Line 65] >> >> Qt5Qmld.dll QQmlObjectCreator::createInstance : >> [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 1049] >> 1044 : QQmlData *ddata = QQmlData::get(instance, >> /*create*/true); >> 1045 : ddata->rootObjectInCreation = true; >> 1046 : >> sharedState->rootContext->isRootObjectInCreation = false; >> 1047 : } >> 1048 : >> 1049 : sharedState->allCreatedObjects.push(instance); >> 1050 : } else { >> 1051 : Q_ASSERT(typeRef->component); >> 1052 : Q_QML_OC_PROFILE(sharedState->profiler, >> profiler.update(typeRef->component->fileName(), >> 1053 : context->url(), obj->location.line, >> obj->location.column)); >> 1054 : if >> (typeRef->component->compilationUnit->data->isSingleton()) >> Qt5Qmld.dll QQmlObjectCreator::create : >> [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 197] >> >> Qt5Qmld.dll QQmlComponentPrivate::beginCreate : >> [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 863] >> >> Qt5Qmld.dll QQmlComponent::beginCreate : >> [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 812] >> >> Qt5Qmld.dll QQmlComponent::create : >> [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 772] >> >> Qt5Quickd.dll QQuickView::continueExecute : >> [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 486] >> >> Qt5Quickd.dll QQuickViewPrivate::execute : >> [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 127] >> >> Qt5Quickd.dll QQuickView::setSource : >> [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 256] >> >> >> All the leaked QtSharedPointer::ExternalRefCountData objects are >> allocated in the line >> sharedState->allCreatedObjects.push(instance); >> then some other code path will also use QPointer (contained in some >> structures allocated by v4mm) to track the same object 'instance' and I >> guess the QPointer wasn't properly destructed which will cause the QtSharedPointer::ExternalRefCountData >> not deleted. >> I have investigated this issue for nearly one day, but I can't find >> which code cause the leak, this is a non-trivial leak, I hope somebody can >> help to find the source of the leak. thanks! >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From drwho at infidigm.net Mon Nov 16 19:31:48 2015 From: drwho at infidigm.net (drwho at infidigm.net) Date: Mon, 16 Nov 2015 13:31:48 -0500 Subject: [Development] Requesting New Repository - QtZeroConf In-Reply-To: References: <55F0AB05.6070507@infidigm.net> <2548460.BMXh572SF9@tjmaciei-mobl4> <3227085.irlKgJ6P7c@tjmaciei-mobl4> <7a20da0a56adcc012702deb702b6b6a8.squirrel@www.infidigm.net> , <3a41772c9e3aec2e95f62d8734e345e5.squirrel@www.infidigm.net> Message-ID: <09a62cdf2d6f3e6ef1f24e712f9eed15.squirrel@www.infidigm.net> > Hi, > > Given that mdns uses an unprivileged port, it seems like to me it should > be possible > for just about any process to send and receive mdns queries. Which means > that any > app could participate in the mdns groups by itself if it wanted. The > primary advantage > that I can see with re-using a running daemon is that the daemon can > detect if your > process crashes and clear out the distributed DNS records. If the app > takes care of > that by itself, then it would have to deliberately use short TTLs I think. > > Interestingly enough, the protocol doesn't seem to be that complicated. A > cross-platform > implementation written in Go is under 1000 LOC (server and client, count > includes comments): > > https://github.com/hashicorp/mdns > > > So an alternate approach would be to try to implement the protocol by > itself. > > > Another option that I think would be viable is to go up in the level of > abstraction > and try to come up with an API that allows discovery and publishing of > network > services on mdns as well as UPNP at the same time. Then the windows > version could > just re-use UPNP APIs in Windows and on the other OSes we use zeroconf. ssdp discovers devices, zeroconf discovers services (on devices). ssdp has different classes of devices (eg. rootdevice). zeroconf has optional txt records. I don't see a way to combine these into a higher level of abstraction. -- ssdp -- registerResourceSimple(const char *target, const char *usn, const char *location) registerResourceSimple("upnp:rootdevice", "uuid:1234abcd-12ab-12ab-12ab-1234567abc12::upnp:rootdevice", "http://192.168.1.100/"); -- ZeroConf -- registerService(const char *name, const char *type, const char *domain, quint16 port); registerService("Vaction-Tracker-server", "_vactracker._tcp", "local", 12345); I have completed testing of my zeroconf project on Linux, Android, Windows and Mac. I would like to contribute the code to the playground area with the project name zeroconf with the hope of it someday becoming a sub module. Jon From mandeepsandhu.chd at gmail.com Mon Nov 16 19:50:46 2015 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Mon, 16 Nov 2015 10:50:46 -0800 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: <563B5F7C.6070707@familiesomers.nl> Message-ID: Hey Eddy, Here's the response from my OSX 10.10.4 (Time Zone: Pacific Standard Time (PST) -0800 UTC UTC/GMT). $ ./mktime Studying DST transitions in system default time-zone Testing spring forward Initial: Sun Mar 8 02:30:00 2015 Accepted: 1425810600 Ignorant of DST (-> 1): Sun Mar 8 03:30:00 2015 Accepted: 1425810600 Claiming no DST (-> 1): Sun Mar 8 03:30:00 2015 Accepted: 1425807000 Claiming DST (-> 0): Sun Mar 8 01:30:00 2015 Testing fall backward Initial: Sun Nov 1 01:30:00 2015 Accepted: 1446366600 Ignorant of DST (-> 1): Sun Nov 1 01:30:00 2015 Accepted: 1446367200 Ignorant of DST (-> 1): Sun Nov 1 01:40:00 2015 Accepted: 1446370860 Ignorant of DST (-> 0): Sun Nov 1 01:41:00 2015 Accepted: 1446370200 Claiming no DST (-> 0): Sun Nov 1 01:30:00 2015 Accepted: 1446366600 Claiming DST (-> 1): Sun Nov 1 01:30:00 2015 $ HTH, -mandeep On Fri, Nov 6, 2015 at 4:34 AM, Welbourne Edward wrote: >> If you're willing to compile and run the attached simple C program, >> please let me know its output and your platform's details - ideally >> off-list - I'll give a summary in a few days' time. > > Thanks to those who responded, I now know: > * that all the platforms below do the same thing if tm_isdst is 0 or 1 (Yay !) > * with .tm_isdst = -1, there is diversity of handling. > > When tm_isdst is 0 or 1, in the fall back it gets preserved; > in the spring forward, it gets flipped and tm_hour is changed > in the way it usually would for such a flip. > > OSX 10.10, Xcode 6.02 > * varies within the hour (see below) > * at half past: handled as if you'd claimed tm_isdst = 0 (see above) > > MacBook, Darwin 15.0.0 > Ubuntu 12.04, glibc 2.15 > Debian/stretch, glibc 2.19 > * clear tm_isdst and move an hour earlier in spring > * set tm_isdst and preserve hour in autumn > > MinGW > MSVC 2015 > * set tm_isdst and move an hour later in spring > * clear tm_isdst and preserve hour in autumn. > > My initial test was, it turns out, naive. Apparently some platforms > vary handling of -1 across the hour. I also bit the bullet and worked > out how to auto-detect DST transitions. One response indicates > asctime_r() isn't portable. So I attach a new version of mktime.c, that > needs no manual configuration and is, I hope, a little more portable. I > note that setting the TZ environment variable (on platforms that honour > it, at least) can be used to discover what your O/S thinks happens in > other time-zones than your local one. > > As before, if anyone feels inclined to give this a whirl, I'd again > appreciate any responses, along with descriptions of the system they > come from (e.g. uname -a output). > > Eddy > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From tim at klingt.org Tue Nov 17 04:38:53 2015 From: tim at klingt.org (Tim Blechmann) Date: Tue, 17 Nov 2015 10:38:53 +0700 Subject: [Development] New qt5.6 beta snapshot available In-Reply-To: References: Message-ID: > These aren't yet final beta packages but please test these & report all > new blocker immediately no new blockers, but i still need to apply these two patches to be able to compile 5.6-beta on osx: https://codereview.qt-project.org/#/c/139577/ https://codereview.qt-project.org/#/c/139981/ both issues are compile failures for statically linked qt, though for some reasons gerrit cannot integrate them. -- btw, would it be possible to configure gerrit to build statically linked qt and possibly also namespaced qt before integrating a patch? in the past it happened quite often that those two configuration options did not compile ... though this is all something which could easily be verified automatically ... cheers, tim From thiago.macieira at intel.com Tue Nov 17 04:45:30 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 Nov 2015 19:45:30 -0800 Subject: [Development] New qt5.6 beta snapshot available In-Reply-To: References: Message-ID: <2524315.BB4IbUITMW@tjmaciei-mobl4> On Tuesday 17 November 2015 10:38:53 Tim Blechmann wrote: > > These aren't yet final beta packages but please test these & report all > > new blocker immediately > > no new blockers, but i still need to apply these two patches to be able > to compile 5.6-beta on osx: > > https://codereview.qt-project.org/#/c/139577/ > https://codereview.qt-project.org/#/c/139981/ > > both issues are compile failures for statically linked qt, though for > some reasons gerrit cannot integrate them. Neither is a showstopper for the release and the first doesn't cause a build error for regular people (no -developer-build). > btw, would it be possible to configure gerrit to build statically linked > qt and possibly also namespaced qt before integrating a patch? in the > past it happened quite often that those two configuration options did > not compile ... though this is all something which could easily be > verified automatically ... Namespace builds are tested. I don't think static builds are. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tim at klingt.org Tue Nov 17 05:23:40 2015 From: tim at klingt.org (Tim Blechmann) Date: Tue, 17 Nov 2015 11:23:40 +0700 Subject: [Development] New qt5.6 beta snapshot available In-Reply-To: <2524315.BB4IbUITMW@tjmaciei-mobl4> References: <2524315.BB4IbUITMW@tjmaciei-mobl4> Message-ID: >>> These aren't yet final beta packages but please test these & report all >>> new blocker immediately >> >> no new blockers, but i still need to apply these two patches to be able >> to compile 5.6-beta on osx: >> >> https://codereview.qt-project.org/#/c/139577/ >> https://codereview.qt-project.org/#/c/139981/ >> >> both issues are compile failures for statically linked qt, though for >> some reasons gerrit cannot integrate them. > > Neither is a showstopper for the release and the first doesn't cause a build > error for regular people (no -developer-build). well, both should be trivially fixable, once CI won't fail with an FTP timeout ;) >> btw, would it be possible to configure gerrit to build statically linked >> qt and possibly also namespaced qt before integrating a patch? in the >> past it happened quite often that those two configuration options did >> not compile ... though this is all something which could easily be >> verified automatically ... > > Namespace builds are tested. I don't think static builds are. since when are namespace builds tested? it must be something rather new, as about a month ago i had to apply this fix [1] to compile qt-5.6-base ... and i remember similar fixes which i had to do for 5.4/5.5. cheers, tim [1] https://codereview.qt-project.org/#/c/127867/ From Simon.Hausmann at theqtcompany.com Tue Nov 17 05:54:15 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 17 Nov 2015 04:54:15 +0000 Subject: [Development] New qt5.6 beta snapshot available In-Reply-To: References: <2524315.BB4IbUITMW@tjmaciei-mobl4>, Message-ID: <20151117045415.5935179.36335.49070@theqtcompany.com> Hi, Namespaced builds are only tested on Linux IIRC, not os x. Similarly static builds happen for ios, where the plugin loading code is probably not used. Simon Original Message From: Tim Blechmann Sent: Tuesday, November 17, 2015 05:24 To: development at qt-project.org Subject: Re: [Development] New qt5.6 beta snapshot available >>> These aren't yet final beta packages but please test these & report all >>> new blocker immediately >> >> no new blockers, but i still need to apply these two patches to be able >> to compile 5.6-beta on osx: >> >> https://codereview.qt-project.org/#/c/139577/ >> https://codereview.qt-project.org/#/c/139981/ >> >> both issues are compile failures for statically linked qt, though for >> some reasons gerrit cannot integrate them. > > Neither is a showstopper for the release and the first doesn't cause a build > error for regular people (no -developer-build). well, both should be trivially fixable, once CI won't fail with an FTP timeout ;) >> btw, would it be possible to configure gerrit to build statically linked >> qt and possibly also namespaced qt before integrating a patch? in the >> past it happened quite often that those two configuration options did >> not compile ... though this is all something which could easily be >> verified automatically ... > > Namespace builds are tested. I don't think static builds are. since when are namespace builds tested? it must be something rather new, as about a month ago i had to apply this fix [1] to compile qt-5.6-base ... and i remember similar fixes which i had to do for 5.4/5.5. cheers, tim [1] https://codereview.qt-project.org/#/c/127867/ _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Tue Nov 17 08:37:54 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 16 Nov 2015 23:37:54 -0800 Subject: [Development] New qt5.6 beta snapshot available In-Reply-To: References: <2524315.BB4IbUITMW@tjmaciei-mobl4> Message-ID: <3772305.NozI7rt4xG@tjmaciei-mobl4> On Tuesday 17 November 2015 11:23:40 Tim Blechmann wrote: > >> btw, would it be possible to configure gerrit to build statically linked > >> qt and possibly also namespaced qt before integrating a patch? in the > >> past it happened quite often that those two configuration options did > >> not compile ... though this is all something which could easily be > >> verified automatically ... > > > > Namespace builds are tested. I don't think static builds are. > > since when are namespace builds tested? it must be something rather new, > as about a month ago i had to apply this fix [1] to compile qt-5.6-base > ... and i remember similar fixes which i had to do for 5.4/5.5. I think since the Qt Project started, so before 5.0. But like Simon said, only for Linux. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From tim at klingt.org Tue Nov 17 09:24:40 2015 From: tim at klingt.org (Tim Blechmann) Date: Tue, 17 Nov 2015 15:24:40 +0700 Subject: [Development] New qt5.6 beta snapshot available In-Reply-To: <20151117045415.5935179.36335.49070@theqtcompany.com> References: <2524315.BB4IbUITMW@tjmaciei-mobl4> <20151117045415.5935179.36335.49070@theqtcompany.com> Message-ID: > Namespaced builds are only tested on Linux IIRC, not os x. Similarly > static builds happen for ios, where the plugin loading code is > probably not used. ah, that explains why all namespaced build failures that i saw were on osx :) From enmarantispam at gmail.com Tue Nov 17 11:53:39 2015 From: enmarantispam at gmail.com (NIkolai Marchenko) Date: Tue, 17 Nov 2015 13:53:39 +0300 Subject: [Development] Inflexibility and inconsistency of QTextEdit undo/redo mechanism Message-ID: Could something be done about that? Users don't have any control over undo/redo stack other than pausing or resetting it and no way to directly access it. Also, some functions reset undo stack for no reason while others, similar ones don't. I was baffled that insertHtml doesnt reset undo stack and setHtml does. -------------- next part -------------- An HTML attachment was scrubbed... URL: From b.terrier at gmail.com Tue Nov 17 13:46:22 2015 From: b.terrier at gmail.com (Benjamin TERRIER) Date: Tue, 17 Nov 2015 13:46:22 +0100 Subject: [Development] Contribution: Windows Stock Icons In-Reply-To: References: Message-ID: Hi, For the first point I think it is a good idea. However the second point seems to be already taken care of. As far as i know, the current API for obtaining such icons is QStyle::standardIcon(), looking at its implementation in QCommonStyle, it calls QPlatformTheme::standardPixmap() for multiple hardcoded sizes (16x16 and 32x32 at this moment). So the returned QIcon already provides various resolutions. It might be improved by calling QPlatformTheme::standardPixmap() for sizes matching SHGSI_LARGEICON, SHGSI_SMALLICON, SHGSI_SHELLICONSIZE. Regards, Benjamin 2015-11-14 14:03 GMT+01:00 Frank Richter : > Hello everybody, > I made some (non-trivial) changes to the Windows stock icon implementation. > The goals were > 1. Use public/"modern" APIs as much as possible to obtain the icons. > 2. Make the various different resolutions stock icons are provided in > available to Qt. > > For the first goal I changed to code to use SHGetStockIconInfo as much as > possible and shell item icons for some other icons; hardcoded resource IDs > and the legacy IDI_ icons are only used as a last resort. (It's worth > mentioning that the IDI_ icons will only return "Windows 7" style icons; for > the new Windows 8 icons you need to use SHGetStockIconInfo. > > For the second goal I added an icon engine that looks at some raw icon > resource data to load all available sizes. To expose all those sizes I added > a platform theme method to return an icon engine for a stock icon. > > Of course I'd very much like to see this make it; however, I think that > before starting to submit individual patches for review maybe a bit of > "approach review" might be a good idea. > * Are these changes desireable? > * What do you think of returning icon engines from the platform theme? > * And what about the more bare-metal icon loading? > > For the time being I uploaded the changes (in order of evolving > implementation) to github: > https://github.com/res2k/qtbase/commits/dev > > Looking forward to your feedback, > - Frank > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From dangelog at gmail.com Tue Nov 17 13:54:10 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Tue, 17 Nov 2015 13:54:10 +0100 Subject: [Development] Contribution: Windows Stock Icons In-Reply-To: References: Message-ID: On Sat, Nov 14, 2015 at 2:03 PM, Frank Richter wrote: > Of course I'd very much like to see this make it; however, I think that > before starting to submit individual patches for review maybe a bit of > "approach review" might be a good idea. > * Are these changes desireable? > * What do you think of returning icon engines from the platform theme? > * And what about the more bare-metal icon loading? > > For the time being I uploaded the changes (in order of evolving > implementation) to github: > https://github.com/res2k/qtbase/commits/dev By all means , please push them on gerrit so we can get them a thorough review! Thanks, -- Giuseppe D'Angelo From edward.welbourne at theqtcompany.com Tue Nov 17 14:40:13 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Tue, 17 Nov 2015 13:40:13 +0000 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: <563B5F7C.6070707@familiesomers.nl> , Message-ID: Hi again Mandeep, Thanks for that. > Accepted: 1446367200 > Ignorant of DST (-> 1): Sun Nov 1 01:40:00 2015 > Accepted: 1446370860 > Ignorant of DST (-> 0): Sun Nov 1 01:41:00 2015 OK, fun - now I know when at least one implementation changes over within the hour ! Eddy. From frank.richter at gmail.com Tue Nov 17 17:48:24 2015 From: frank.richter at gmail.com (Frank Richter) Date: Tue, 17 Nov 2015 16:48:24 +0000 Subject: [Development] Contribution: Windows Stock Icons In-Reply-To: References: Message-ID: Hi, on newer Windows systems some stock icons come in a wealth of sizes for various scaling needs. For example, on Windows 10 some icons are available in 11 different sizes! (Including 256x256.) Hardcoding a "small" and "large" size doesn't really do them justice (even if you'd consider the "shell" icon sizes, which may be different, but not necessarily so). Those extra sizes are certainly beneficial if there are unusual icon size or scaling needs. However, not all icons are available in all those sizes all the time. If Qt should be allowed to use all available resolutions, yet avoid that any synthesized sizes are used, a hardcoded list of sizes doesn't work so well. Thus I opted for the "manual resource wrangling" approach. -f.r. On Tue, 17 Nov 2015 at 13:46 Benjamin TERRIER wrote: > Hi, > > For the first point I think it is a good idea. > > However the second point seems to be already taken care of. As far as > i know, the current API for obtaining such icons is > QStyle::standardIcon(), looking at its implementation in QCommonStyle, > it calls QPlatformTheme::standardPixmap() for multiple hardcoded sizes > (16x16 and 32x32 at this moment). So the returned QIcon already > provides various resolutions. > It might be improved by calling QPlatformTheme::standardPixmap() for > sizes matching SHGSI_LARGEICON, SHGSI_SMALLICON, SHGSI_SHELLICONSIZE. > > Regards, > > Benjamin > > > 2015-11-14 14:03 GMT+01:00 Frank Richter : > > Hello everybody, > > I made some (non-trivial) changes to the Windows stock icon > implementation. > > The goals were > > 1. Use public/"modern" APIs as much as possible to obtain the icons. > > 2. Make the various different resolutions stock icons are provided in > > available to Qt. > > > > For the first goal I changed to code to use SHGetStockIconInfo as much as > > possible and shell item icons for some other icons; hardcoded resource > IDs > > and the legacy IDI_ icons are only used as a last resort. (It's worth > > mentioning that the IDI_ icons will only return "Windows 7" style icons; > for > > the new Windows 8 icons you need to use SHGetStockIconInfo. > > > > For the second goal I added an icon engine that looks at some raw icon > > resource data to load all available sizes. To expose all those sizes I > added > > a platform theme method to return an icon engine for a stock icon. > > > > Of course I'd very much like to see this make it; however, I think that > > before starting to submit individual patches for review maybe a bit of > > "approach review" might be a good idea. > > * Are these changes desireable? > > * What do you think of returning icon engines from the platform theme? > > * And what about the more bare-metal icon loading? > > > > For the time being I uploaded the changes (in order of evolving > > implementation) to github: > > https://github.com/res2k/qtbase/commits/dev > > > > Looking forward to your feedback, > > - Frank > > > > > > _______________________________________________ > > 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 mandeepsandhu.chd at gmail.com Tue Nov 17 18:55:39 2015 From: mandeepsandhu.chd at gmail.com (Mandeep Sandhu) Date: Tue, 17 Nov 2015 09:55:39 -0800 Subject: [Development] How does mktime() handle DST transitions ? In-Reply-To: References: <563B5F7C.6070707@familiesomers.nl> Message-ID: Awesome! Glad I could help. -mandeep On Tue, Nov 17, 2015 at 5:40 AM, Welbourne Edward wrote: > Hi again Mandeep, > > Thanks for that. > >> Accepted: 1446367200 >> Ignorant of DST (-> 1): Sun Nov 1 01:40:00 2015 >> Accepted: 1446370860 >> Ignorant of DST (-> 0): Sun Nov 1 01:41:00 2015 > > OK, fun - now I know when at least one implementation changes over within the hour ! > > Eddy. From jani.heikkinen at theqtcompany.com Wed Nov 18 11:13:02 2015 From: jani.heikkinen at theqtcompany.com (Heikkinen Jani) Date: Wed, 18 Nov 2015 10:13:02 +0000 Subject: [Development] New Qt 5.6 Beta snapshot available Message-ID: Hi all, New snapshot available for your testing: Windows: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/268/ Linux: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/280/ Mac: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/213/ Src: http://download.qt.io/snapshots/qt/5.6/5.6.0-beta/latest_src/ These packages aren't yet final beta packages but we are closing so it is important to get these packages tested. Please test the packages & inform me immediately about new blockers found. Known issues: - WinRT x86 msvc2015 binaries still missing form winrt_msvc2015 package, binaries should be coming with next qt5.git integration - Tech preview modules missing from src package, fix should be in next packages - Open issues in blocker list (https://bugreports.qt.io/browse/QTBUG-47958): * QTBUG-49197 WinRT: MSVC2015 installer does not contain arm build ** Verification needed, should be fixed in packages * QTBUG-49226 Unsatisfied dependencies to system libraries ** Verification needed, should be fixed in packages * QTBUG-49367 QtAndroidBluetooth-bundled.jar missing from 5.6 beta Mac installer ** Fix ongoing * QTBUG-48914 Qt5.6 offline: plugins/mediaservice/ libs missing ** Fix under review * QTBUG-49366 [Reg 5.5->5.6]: Cannot compile apps with sql for iOS ** Fix available * QTBUG-49368 Windows Phone Emulator (x86) Qt version missing from installer ** Verification needed, should be fixed in packages * QTBUG-48927 Regression: Qt Quick Controls applications containing a MenuBar with at least one Menu item crash ** Fix available & waiting for qt5.git integ. * QTBUG-49211 [REG 5.5->5.6] Cannot find documentation specification file: ** Verification needed, should be fixed in packages * QTBUG-49369 Several Qt tools fail to find QtCore: ** Fix available & waiting for qt5.git integration * QTBUG-48915 Qt5.6 offline: Enginio missing from android targets: ** Fix in, should be ok in next packages * QTBUG-49471 Bluetooth on Linux not working due to build issue ** Fix ongoing * QTBUG-45662 Add qtbase/bin/fixqt4headers.pl to packages: ** Verification needed, should be fixed in packages * QTBUG-49454 Qt 5.6 offline: msvc2013 #254 Installer fails on missing dependency ** Verification needed, should be fixed in packages -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmilith at gmail.com Wed Nov 18 13:01:26 2015 From: dmilith at gmail.com (Daniel Dettlaff) Date: Wed, 18 Nov 2015 13:01:26 +0100 Subject: [Development] FreeBSD 10 and up, No gcc and solution Message-ID: Hello, I’m heavy Qt user under FreeBSD on my servers (no gui stuff). Here’s a definition for qt5 in my software (skip the software, it doesn’t matter): https://bitbucket.org/verknowsys/sofin-definitions/src/e57660d476d3725dc7aaa8a637be59da59349b22/definitions/qtbase55.def?at=stable&fileviewer=file-view-default I created a spec for freebsd-clang based on freebsd-g++46. It’s described/ scripted how I did create freebsd-clang spec for fBSD 10 and 11 (tested with a lot of modules, and external Qt software since FreeBSD 10.0) Standard specs bundled by default are - freebsd-g++, freebsd-g++46 and freebsd-icc - which simply wont work anymore for newer FreeBSD OS releases (without gcc). My question is could you please provide such spec by default to be shipped with Qt itself? My solution is a hack obviously. -- kind regards Daniel (dmilith) Dettlaff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From nolden at kde.org Wed Nov 18 13:16:49 2015 From: nolden at kde.org (Ralf Nolden) Date: Wed, 18 Nov 2015 13:16:49 +0100 Subject: [Development] FreeBSD 10 and up, No gcc and solution In-Reply-To: References: Message-ID: <1521100.0VRrvrQdpT@w530.nolden.freebsd> Am Mittwoch, 18. November 2015, 13:01:26 schrieb Daniel Dettlaff: Hi Daniel, you can simply use ./configure -platform unsupported/freebsd-clang I've provided some patches for Qt on FreeBSD on the kde-freebsd mailinglist to move the libs to /usr/local/lib/qt5 which are still not in the freebsd ports yet. Those allow using portupgrade and building a custom Qt with a ports/packages installed Qt without build errors. You may want to have a look at those too. > Hello, I’m heavy Qt user under FreeBSD on my servers (no gui stuff). > > Here’s a definition for qt5 in my software (skip the software, it doesn’t > matter): > https://bitbucket.org/verknowsys/sofin-definitions/src/e57660d476d3725dc7aa > a8a637be59da59349b22/definitions/qtbase55.def?at=stable&fileviewer=file-view > -default > > I created a spec for freebsd-clang based on freebsd-g++46. > It’s described/ scripted how I did create freebsd-clang spec for fBSD 10 and > 11 (tested with a lot of modules, and external Qt software since FreeBSD > 10.0) Standard specs bundled by default are - freebsd-g++, freebsd-g++46 > and freebsd-icc - which simply wont work anymore for newer FreeBSD OS > releases (without gcc). > > My question is could you please provide such spec by default to be shipped > with Qt itself? My solution is a hack obviously. > > -- > kind regards > Daniel (dmilith) Dettlaff -- Kind regards, Ralf Nolden From dmilith at gmail.com Wed Nov 18 13:30:14 2015 From: dmilith at gmail.com (Daniel Dettlaff) Date: Wed, 18 Nov 2015 13:30:14 +0100 Subject: [Development] FreeBSD 10 and up, No gcc and solution In-Reply-To: References: Message-ID: > I created a spec for freebsd-clang based on freebsd-g++46. > It’s described/ scripted how I did create freebsd-clang spec for fBSD 10 and 11 (tested with a lot of modules, and external Qt software since FreeBSD 10.0) > Standard specs bundled by default are - freebsd-g++, freebsd-g++46 and freebsd-icc - which simply wont work anymore for newer FreeBSD OS releases (without gcc). It’s also worth mentioning: ``` ${SED_BIN} -i '' -e 's/-pthread/-pthread -lutil -lexecinfo/g’ qmake.conf ``` this part is necessary only under FreeBSD 10.x Under 11.x it causes clang warnings (non fatal though so I left it this way). -- kind regards Daniel (dmilith) Dettlaff -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From dangelog at gmail.com Wed Nov 18 13:34:15 2015 From: dangelog at gmail.com (Giuseppe D'Angelo) Date: Wed, 18 Nov 2015 13:34:15 +0100 Subject: [Development] FreeBSD 10 and up, No gcc and solution In-Reply-To: References: Message-ID: On Wed, Nov 18, 2015 at 1:30 PM, Daniel Dettlaff wrote: > Under 11.x it causes clang warnings (non fatal though so I left it this way). Maybe you can contribute your improvements to the mkspecs? http://wiki.qt.io/Category:Developing_Qt Cheers, -- Giuseppe D'Angelo From jianliang79 at gmail.com Wed Nov 18 15:38:16 2015 From: jianliang79 at gmail.com (Liang Jian) Date: Wed, 18 Nov 2015 22:38:16 +0800 Subject: [Development] [Qt-5.6] leak of QtSharedPointer::ExternalRefCountData objects In-Reply-To: References: Message-ID: I have submited a patch to fix this issue: https://codereview.qt-project.org/#/c/141311/ On Mon, Nov 16, 2015 at 11:01 PM, Liang Jian wrote: > The allocated QV4::QObjectWrapper object hold a QPointer which track > 'instance', it seems that it should be destroyed with QObjectWrapper::destroyObject() > to properly destruct the QPointer in it in QV4::MemoryManager::sweep(). > But when sweep() is being called it couldn't find the QObjectWrapper > object created before which will make the QPointer in it not destructed > properly. > > On Sun, Nov 15, 2015 at 11:58 PM, Liang Jian > wrote: > >> After some further investigation I can now confirm that one of the >> leak is caused by the following code in QQmlObjectCreator::createInstance(), >> qqmlobjectcreator.cpp: >> >> *sharedState->allJavaScriptObjects = QV4::QObjectWrapper::wrap(v4, >> instance); >> >> ++sharedState->allJavaScriptObjects; >> >> >> But the reason is still unknown >> >> >> >> On Sun, Nov 15, 2015 at 10:19 PM, Liang Jian >> wrote: >> >>> Hello everyone, I checkout qt 5.6 branch yesterday in my windows >>> 10 x64 machine, I build it and run my program and see many leaks. Then I >>> use C++ Memory Validator to find the source of the leaks, I can now >>> confirm the leaked objects are QtSharedPointer::ExternalRefCountData which >>> are created in QQmlObjectCreator::createInstance(), qqmlobjectcreator.cpp >>> Line 1049, below is the call stack printed by C++ Memory Validator: >>> >>> Qt5Cored.dll QtSharedPointer::ExternalRefCountData::getAndRef : >>> [d:\qt5\qtbase\src\corelib\tools\qsharedpointer.cpp Line 1337] >>> >>> Qt5Qmld.dll QWeakPointer::QWeakPointer : >>> [d:\qt5\qtbase\src\corelib\tools\qsharedpointer_impl.h Line 706] >>> >>> Qt5Qmld.dll QPointer::QPointer : >>> [d:\qt5\qtbase\src\corelib\kernel\qpointer.h Line 65] >>> >>> Qt5Qmld.dll QQmlObjectCreator::createInstance : >>> [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 1049] >>> 1044 : QQmlData *ddata = QQmlData::get(instance, >>> /*create*/true); >>> 1045 : ddata->rootObjectInCreation = true; >>> 1046 : >>> sharedState->rootContext->isRootObjectInCreation = false; >>> 1047 : } >>> 1048 : >>> 1049 : sharedState->allCreatedObjects.push(instance); >>> 1050 : } else { >>> 1051 : Q_ASSERT(typeRef->component); >>> 1052 : Q_QML_OC_PROFILE(sharedState->profiler, >>> profiler.update(typeRef->component->fileName(), >>> 1053 : context->url(), obj->location.line, >>> obj->location.column)); >>> 1054 : if >>> (typeRef->component->compilationUnit->data->isSingleton()) >>> Qt5Qmld.dll QQmlObjectCreator::create : >>> [d:\qt5\qtdeclarative\src\qml\qml\qqmlobjectcreator.cpp Line 197] >>> >>> Qt5Qmld.dll QQmlComponentPrivate::beginCreate : >>> [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 863] >>> >>> Qt5Qmld.dll QQmlComponent::beginCreate : >>> [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 812] >>> >>> Qt5Qmld.dll QQmlComponent::create : >>> [d:\qt5\qtdeclarative\src\qml\qml\qqmlcomponent.cpp Line 772] >>> >>> Qt5Quickd.dll QQuickView::continueExecute : >>> [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 486] >>> >>> Qt5Quickd.dll QQuickViewPrivate::execute : >>> [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 127] >>> >>> Qt5Quickd.dll QQuickView::setSource : >>> [d:\qt5\qtdeclarative\src\quick\items\qquickview.cpp Line 256] >>> >>> >>> All the leaked QtSharedPointer::ExternalRefCountData objects are >>> allocated in the line >>> sharedState->allCreatedObjects.push(instance); >>> then some other code path will also use QPointer (contained in some >>> structures allocated by v4mm) to track the same object 'instance' and I >>> guess the QPointer wasn't properly destructed which will cause the QtSharedPointer::ExternalRefCountData >>> not deleted. >>> I have investigated this issue for nearly one day, but I can't find >>> which code cause the leak, this is a non-trivial leak, I hope somebody can >>> help to find the source of the leak. thanks! >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronan.jouchet at cadensimaging.com Wed Nov 18 16:46:06 2015 From: ronan.jouchet at cadensimaging.com (Ronan Jouchet) Date: Wed, 18 Nov 2015 10:46:06 -0500 Subject: [Development] [QML] Need advice on frontend architecture Message-ID: <564C9D3E.1010806@cadensimaging.com> Hi. I recently joined a nascent QML project with the objective to bring it from the "working prototype" stage to something maintainable and efficient. Previously, my last GUI work was on a web application using React [1] + Flux [2], which I *loved* for the mental simplicity and testability their functional model brings (i.e: update the state, be confident that {1. the view is updated, 2. with good performance regardless of the state mutation complexity / number of bindings}). Now, back to QML, looking at the documentation, examples, and a few blog posts, - I find a good overview of QML language constructs - ... as well as tons of simple, mostly stateless widget examples , but: - I have yet to encounter frontend architecture recommendations (like Flux) - I often stumble on QML constructs that push me into one-component-directly-mutating-another corners. Drinking the React kool-aid made me very wary of those, and I'd now actively avoiding them because they can quickly lead to spaghetti. For example, QML states [3], and direct mutations using `parent`, `root`, or accessing by id. So, as you can expect, I'm trying to bring a Flux-ish approach to our QML app, by creating central data stores encapsulating {a. my application state as pure data, b. functions to manipulate the state}, and making my QML components depend on this pure data. But so far it feels like I'm swimming against the tide, plus: - I have little idea how performance will evolve down the road. - Contrarily to the web application mentioned in the introduction, I also have to mix my JS state with C++ classes instantiated in my QML, also bringing their own state, which I use too in QML. - My store-observing logic implies regularly using `onXyzChanged` signal handlers (e.g. to re-generate a ListModel when the source Array changes), which means bring Data Store attribute `xyz` to the local QML component scope, which isn't feasible with a current-scope-limited aliases [4], so I'm using ordinary property references (property var cheeses: dataStoreInventory.cheeses;), which "allocates a new, unique storage space for the property", effectively doubling the memory usage of my state, with unknown memory leaking behavior. - I'm reading lots of very affirmative, but sometimes old, and often poorly researched articles encouraging QML developers to avoid JS and do all the logic in C++, save for basic widget arithmetic. As a web developer, the productivity benefits of JS are obvious to me (plus the library availability, *when* libraries are content with the exotic JS environment provided by QML, but that's another question), but these claims are starting to make me wary of too much JS in my QML app. Or maybe these cautionary tales are just instances of good tools badly used yielding bad results? Anyway I'm wondering how much JS is reasonable in a long-running QML app with serious performance expectations (calculations and heavy 2d/3d in C++, QML gui) As you can guess, I'm lost in all this. Do you have battlefield-tested advice/links to structure QML apps? Thanks for your help. [1] https://facebook.github.io/react/ [2] https://facebook.github.io/flux/ [3] http://doc.qt.io/qt-5/qtquick-statesanimations-states.html [4] http://doc.qt.io/qt-5/qtqml-syntax-objectattributes.html#property-aliases -- Ronan From me at the-compiler.org Wed Nov 18 17:03:32 2015 From: me at the-compiler.org (Florian Bruhin) Date: Wed, 18 Nov 2015 17:03:32 +0100 Subject: [Development] [QML] Need advice on frontend architecture In-Reply-To: <564C9D3E.1010806@cadensimaging.com> References: <564C9D3E.1010806@cadensimaging.com> Message-ID: <20151118160332.GD23889@tonks> Hey, * Ronan Jouchet [2015-11-18 10:46:06 -0500]: > I recently joined a nascent QML project with the objective to bring it from > the "working prototype" stage to something maintainable and efficient. > > [...] This list is for development *of* Qt itself, not *with* it. You probably want to post this to the Interest mailinglist instead: http://lists.qt-project.org/mailman/listinfo/interest 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: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: Digital signature URL: From Simon.Hausmann at theqtcompany.com Thu Nov 19 09:14:57 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Thu, 19 Nov 2015 08:14:57 +0000 Subject: [Development] PSA: 5.6 branch integrations Message-ID: Hi, Due to a hiccup in the qtbase build system any integrations targetting the 5.6 branch in modules other than qtbase that depend directly or indirectly on qtdeclarative are going to fail until further notice. Examples of affected modules include qttools, qtwebengine, etc. I suggest to hold off staging attempts. I'll send a follow-up email once the fix made it into qtbase. Simon From holger at freyther.de Thu Nov 19 11:36:20 2015 From: holger at freyther.de (Holger Freyther) Date: Thu, 19 Nov 2015 10:36:20 +0000 Subject: [Development] Status of the coverity builds Message-ID: <1D70A59D-12AC-4882-9156-5A798C020FC5@freyther.de> Hi, I would like to provide a small status of the coverity builds and ask for some help. The last weekend the analysis failed because lower than a threshold of C++ code could be parsed. The coverity analysis tool is executed alongside the compiler when building qt5. This has occurred in the past and I dealt with it by first trying to upgrade the analysis tool and then ending up disabling C++1X support in Qt. Now disabling C++1X isn't an option anymore but luckily the new analysis tool can parse enough of Qt to generate a scan result and the new results were uploaded, analyzed and we have a ton of new potential issues raised by it. It would be great if we could have a look and try to clear these new issues quickly. The build is done every Saturday on a Ubuntu 14.04 system and the result is then uploaded to coverity, the build is always done from the dev branch and I wonder if in front of a release we shouldn't be tracking the release branch instead. Preferable the dev->release->dev switch would be done something that does happen automatically. Shall we build the release branch close to a release? Is there an indicator a script could see if we are close to the release? kind regards holger From edward.welbourne at theqtcompany.com Thu Nov 19 11:41:21 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 19 Nov 2015 10:41:21 +0000 Subject: [Development] Status of the coverity builds In-Reply-To: <1D70A59D-12AC-4882-9156-5A798C020FC5@freyther.de> References: <1D70A59D-12AC-4882-9156-5A798C020FC5@freyther.de> Message-ID: > The build is done every Saturday on a Ubuntu 14.04 system and > the result is then uploaded to coverity What's the specific URL ? > the build is always done from the dev branch and I wonder if in front > of a release we shouldn't be tracking the release branch instead. I'm surprised the release branch isn't the usual target of such analysis. If we have issues that can be found by static analysis, surely we want to fix them sooner rather than later ! Eddy. From holger at freyther.de Thu Nov 19 11:52:02 2015 From: holger at freyther.de (Holger Freyther) Date: Thu, 19 Nov 2015 10:52:02 +0000 Subject: [Development] Status of the coverity builds In-Reply-To: References: <1D70A59D-12AC-4882-9156-5A798C020FC5@freyther.de> Message-ID: <01233577-3C5B-4226-9BA0-BAB9FCA1E88F@freyther.de> > On 19 Nov 2015, at 10:41, Welbourne Edward wrote: > >> The build is done every Saturday on a Ubuntu 14.04 system and >> the result is then uploaded to coverity > > What's the specific URL ? You will need to join the "project" and then can see the results. The website appears to be down right now but my history contains the following: https://scan.coverity.com/projects/qt-project > >> the build is always done from the dev branch and I wonder if in front >> of a release we shouldn't be tracking the release branch instead. > > I'm surprised the release branch isn't the usual target of such > analysis. If we have issues that can be found by static analysis, > surely we want to fix them sooner rather than later ! Well in general new code lands in dev and one should get feedback about it as early as possible? It is just when dev is branched to stable we might want to change what is being tracked? holger From edward.welbourne at theqtcompany.com Thu Nov 19 12:40:49 2015 From: edward.welbourne at theqtcompany.com (Welbourne Edward) Date: Thu, 19 Nov 2015 11:40:49 +0000 Subject: [Development] Status of the coverity builds In-Reply-To: <01233577-3C5B-4226-9BA0-BAB9FCA1E88F@freyther.de> References: <1D70A59D-12AC-4882-9156-5A798C020FC5@freyther.de> , <01233577-3C5B-4226-9BA0-BAB9FCA1E88F@freyther.de> Message-ID: >>> The build is done every Saturday on a Ubuntu 14.04 system and >>> the result is then uploaded to coverity >> >> What's the specific URL ? > > You will need to join the "project" and then can see the results. I take it that's something I can do once the site is back up. If not, where do I need to go to do that ? > The website > appears to be down right now but my history contains the following: > > https://scan.coverity.com/projects/qt-project OK, thanks for the link. Still apparently down - scan.coverity.com took too long to respond. - according to Vivaldi. >> I'm surprised the release branch isn't the usual target of such >> analysis. If we have issues that can be found by static analysis, >> surely we want to fix them sooner rather than later ! > > Well in general new code lands in dev and one should get feedback > about it as early as possible? It is just when dev is branched to stable > we might want to change what is being tracked? Makes sense. I've mostly been contributing fixes, on the release branch, and it'd be reassuring to have coverity check them, too - but new code surely is more in need. A switch to testing release branch during the pre-release bug-fixing does sound like a smart idea. Do we lack the resources to simply check both ? Eddy. From holger at freyther.de Thu Nov 19 12:59:53 2015 From: holger at freyther.de (Holger Freyther) Date: Thu, 19 Nov 2015 11:59:53 +0000 Subject: [Development] Status of the coverity builds In-Reply-To: References: <1D70A59D-12AC-4882-9156-5A798C020FC5@freyther.de> <01233577-3C5B-4226-9BA0-BAB9FCA1E88F@freyther.de> Message-ID: <0DA8024C-F3D1-490E-A241-5D2FC9EE7E9B@freyther.de> > On 19 Nov 2015, at 11:40, Welbourne Edward wrote: > > I take it that's something I can do once the site is back up. > If not, where do I need to go to do that ? right. > Makes sense. I've mostly been contributing fixes, on the release > branch, and it'd be reassuring to have coverity check them, too - but > new code surely is more in need. A switch to testing release branch > during the pre-release bug-fixing does sound like a smart idea. Do we > lack the resources to simply check both ? The service is (at least was) sponsored by the Department of Homeland Security and we can get one configuration scanned every couple of days. If people look at the results fast enough we can have alternate builds (dev, stable, release) every week but I think the noise of closed/opened issues would just be annoying. :) holger From Simon.Hausmann at theqtcompany.com Fri Nov 20 06:59:33 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Fri, 20 Nov 2015 05:59:33 +0000 Subject: [Development] PSA: 5.6 branch integrations In-Reply-To: References: Message-ID: <20151120055932.5955665.52602.49714@theqtcompany.com> Hi, Thanks to Ossi's analysis and efforts this is fixed now. Simon Original Message From: Hausmann Simon Sent: Thursday, November 19, 2015 09:15 To: development at qt-project.org Subject: [Development] PSA: 5.6 branch integrations Hi, Due to a hiccup in the qtbase build system any integrations targetting the 5.6 branch in modules other than qtbase that depend directly or indirectly on qtdeclarative are going to fail until further notice. Examples of affected modules include qttools, qtwebengine, etc. I suggest to hold off staging attempts. I'll send a follow-up email once the fix made it into qtbase. Simon _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From yurikoles at gmail.com Fri Nov 20 08:56:10 2015 From: yurikoles at gmail.com (Yurii Kolesnykov) Date: Fri, 20 Nov 2015 07:56:10 +0000 Subject: [Development] Official Qt Creator short name? Message-ID: Many distributions and package management repositories use different spelling of 'qtcreator' vs 'qt-creator'. And one needs to recall/fail to install/search for correct spelling in this particular system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Fri Nov 20 17:48:20 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 Nov 2015 08:48:20 -0800 Subject: [Development] Official Qt Creator short name? In-Reply-To: References: Message-ID: <9284471.5zOvyG2lWg@tjmaciei-mobl4> On Friday 20 November 2015 07:56:10 Yurii Kolesnykov wrote: > Many distributions and package management repositories use different > spelling of 'qtcreator' vs 'qt-creator'. And one needs to recall/fail to > install/search for correct spelling in this particular system. They also use different names for the different Qt libraries. Some of them have "lib" prefix and some don't; some of them split per Git repository, some split per library. I don't think we should do anything about this. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From john_a at fastmail.com Fri Nov 20 18:21:24 2015 From: john_a at fastmail.com (john_a at fastmail.com) Date: Fri, 20 Nov 2015 09:21:24 -0800 Subject: [Development] Who are the right Qt developers to deal with this bug (broken keyboard shortcuts)? Message-ID: <1448040084.579642.445519553.02C85251@webmail.messagingengine.com> I use KDE on linux. When KDE moved to its Plasma5 version, it moved to Qt5 too. When it did support for custom keyboard shortcuts broke. Not the first time apparently; there are reports about it going back years. I went to IRC and in email trying to figure out the problem. I filed a bug at KDE. After lots of back and forth I was told it was a Qt problem -- NOT KDE. This Qt bug was filed Broken handling of synthetic (keyboard) input events https://bugreports.qt.io/browse/QTBUG-48795 I contacted a Qt dev that had dealt with some of this before to ask for input. He responded, saying he's not involved, pointiing to someone else. Who ALSO responded saying he's not been involved. I've spent a lot of time trying to do my part on this. I've bounced around at KDE, and now at Qt. I'm really frustrated trying to get the right people involved. I'd really appreciate someone's help is just identifying the right people at Qt to be talking to. I'll contact them, and get them involved in the bug if I can, and get off this list where I don't belong -- I just need to figure out who "They" are and stop this ping-pong-ball business. Thanks for ANY help in getting pointed to the right people. From porten at froglogic.com Fri Nov 20 18:39:14 2015 From: porten at froglogic.com (Harri Porten) Date: Fri, 20 Nov 2015 18:39:14 +0100 (CET) Subject: [Development] Who are the right Qt developers to deal with this bug (broken keyboard shortcuts)? In-Reply-To: <1448040084.579642.445519553.02C85251@webmail.messagingengine.com> References: <1448040084.579642.445519553.02C85251@webmail.messagingengine.com> Message-ID: On Fri, 20 Nov 2015, john_a at fastmail.com wrote: > I'll contact them, and get them involved in the bug if I can, and get > off this list where I don't belong -- I just need to figure out who > "They" are and stop this ping-pong-ball business. Speaking of business: keep in mind that the people you spoke to might either work on KDE or Qt in their spare time. Or, they might get paid to work on Qt for commercial license holders with a support contract. Hence I can only suggest that your best chance of getting this issue fixed is a) do it yourself (I got involved in KDE and Qt like that) or b) pay someone to fix it. Harri. From john_a at fastmail.com Fri Nov 20 18:52:06 2015 From: john_a at fastmail.com (john_a at fastmail.com) Date: Fri, 20 Nov 2015 09:52:06 -0800 Subject: [Development] Who are the right Qt developers to deal with this bug (broken keyboard shortcuts)? In-Reply-To: References: <1448040084.579642.445519553.02C85251@webmail.messagingengine.com> Message-ID: <1448041926.2162233.445550641.1B69AF06@webmail.messagingengine.com> Everybody's always placing a value on devs time, but never on the just users who work hard too, and contibute for free, too. Ti the health if these "commervial products", no less. If the answer to it-used-to-work-but-the-product-upgrade-broke-it really is DIY or pay for it, thats just sad. But ok, because there are really good options. Macs and Windows work just fine. On Fri, Nov 20, 2015, at 09:39 AM, Harri Porten wrote: > On Fri, 20 Nov 2015, john_a at fastmail.com wrote: > > > I'll contact them, and get them involved in the bug if I can, and get > > off this list where I don't belong -- I just need to figure out who > > "They" are and stop this ping-pong-ball business. > > Speaking of business: keep in mind that the people you spoke to might > either work on KDE or Qt in their spare time. Or, they might get paid to > work on Qt for commercial license holders with a support contract. > > Hence I can only suggest that your best chance of getting this issue fixed > is a) do it yourself (I got involved in KDE and Qt like that) or b) pay > someone to fix it. > > Harri. From thiago.macieira at intel.com Fri Nov 20 23:13:46 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 20 Nov 2015 14:13:46 -0800 Subject: [Development] Who are the right Qt developers to deal with this bug (broken keyboard shortcuts)? In-Reply-To: <1448041926.2162233.445550641.1B69AF06@webmail.messagingengine.com> References: <1448040084.579642.445519553.02C85251@webmail.messagingengine.com> <1448041926.2162233.445550641.1B69AF06@webmail.messagingengine.com> Message-ID: <3150127.X1F3uQTeBJ@tjmaciei-mobl4> On Friday 20 November 2015 09:52:06 john_a at fastmail.com wrote: > Everybody's always placing a value on devs time, but never on the just > users who work hard too, and contibute for free, too. Ti the health if > these "commervial products", no less. > > If the answer to it-used-to-work-but-the-product-upgrade-broke-it really is > DIY or pay for it, thats just sad. > > But ok, because there are really good options. Macs and Windows work just > fine. John, please don't forget that the developers have other things to do. Your bug has been triaged and is currently assigned to the person best able to fix it (Gatis). But note how it's a P3 bug. That means the P1 and P2 bugs assigned to him will get his attention first. He'll get to it when he has time. Unfortunately, that may be "one year from now" or later. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From kevin.kofler at chello.at Sun Nov 22 23:59:52 2015 From: kevin.kofler at chello.at (Kevin Kofler) Date: Sun, 22 Nov 2015 23:59:52 +0100 Subject: [Development] Who are the right Qt developers to deal with this bug (broken keyboard shortcuts)? References: <1448040084.579642.445519553.02C85251@webmail.messagingengine.com> <1448041926.2162233.445550641.1B69AF06@webmail.messagingengine.com> <3150127.X1F3uQTeBJ@tjmaciei-mobl4> Message-ID: Thiago Macieira wrote: > John, please don't forget that the developers have other things to do. > Your bug has been triaged and is currently assigned to the person best > able to fix it (Gatis). But note how it's a P3 bug. That means the P1 and > P2 bugs assigned to him will get his attention first. The real question is then, why does a regression that affects one of the most popular Qt programs out there (KDE Plasma) get such a low priority? Kevin Kofler From thiago.macieira at intel.com Mon Nov 23 06:45:46 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 22 Nov 2015 21:45:46 -0800 Subject: [Development] Who are the right Qt developers to deal with this bug (broken keyboard shortcuts)? In-Reply-To: References: <1448040084.579642.445519553.02C85251@webmail.messagingengine.com> <3150127.X1F3uQTeBJ@tjmaciei-mobl4> Message-ID: <1768343.K8ItUQLtTu@tjmaciei-mobl4> On Sunday 22 November 2015 23:59:52 Kevin Kofler wrote: > Thiago Macieira wrote: > > John, please don't forget that the developers have other things to do. > > Your bug has been triaged and is currently assigned to the person best > > able to fix it (Gatis). But note how it's a P3 bug. That means the P1 and > > P2 bugs assigned to him will get his attention first. > > The real question is then, why does a regression that affects one of the > most popular Qt programs out there (KDE Plasma) get such a low priority? Because it is an uncommon case. Corner-case issues don't get high priority. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From olivier at woboq.com Mon Nov 23 09:59:43 2015 From: olivier at woboq.com (Olivier Goffart) Date: Mon, 23 Nov 2015 09:59:43 +0100 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <2179031.L5GMPoFkkI@tjmaciei-mobl4> References: <2179031.L5GMPoFkkI@tjmaciei-mobl4> Message-ID: <14071234.PvcYbKEM6S@finn> On Friday 13. November 2015 10:37:25 Thiago Macieira wrote: > One more thing: I'd like a whitelist of features that have been tested and > are known to work on all platforms. The white list can be obtained by doing 'git grep "std::"' :-) Anyway, i'd like to start the white list with std::enable_if -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From frederik.gladhorn at theqtcompany.com Mon Nov 23 12:46:05 2015 From: frederik.gladhorn at theqtcompany.com (Frederik Gladhorn) Date: Mon, 23 Nov 2015 12:46:05 +0100 Subject: [Development] =?utf-8?q?Nominating_Pasi_Ker=C3=A4nen_for_Approver?= =?utf-8?q?_status?= Message-ID: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> Hi all, I'd like to nominate Pasi Keränen as Approver in the Qt Project. He is actually already a maintainer for the Qt Canvas 3D module, so this will actually "complete" his maintainer status with the general approver bit. Pasi is a great colleague and fun to work with. He has a focus on 3D and lately became more active in the Qt 3D module as well. Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Pasi+Ker%25C3%25A4nen+ %253Cpasi.keranen%2540theqtcompany.com%253E%22,n,z Cheers, Frederik From Simon.Hausmann at theqtcompany.com Mon Nov 23 12:55:41 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Mon, 23 Nov 2015 11:55:41 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Pasi_Ker=E4nen_for_Approv?= =?iso-8859-1?q?er_status?= In-Reply-To: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> References: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> Message-ID: +1 Simon ________________________________________ From: Development on behalf of Frederik Gladhorn Sent: Monday, November 23, 2015 12:46 To: development at qt-project.org Subject: [Development] Nominating Pasi Keränen for Approver status Hi all, I'd like to nominate Pasi Keränen as Approver in the Qt Project. He is actually already a maintainer for the Qt Canvas 3D module, so this will actually "complete" his maintainer status with the general approver bit. Pasi is a great colleague and fun to work with. He has a focus on 3D and lately became more active in the Qt 3D module as well. Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:%22Pasi+Ker%25C3%25A4nen+ %253Cpasi.keranen%2540theqtcompany.com%253E%22,n,z Cheers, Frederik _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From sean.harmer at kdab.com Mon Nov 23 13:04:26 2015 From: sean.harmer at kdab.com (Sean Harmer) Date: Mon, 23 Nov 2015 12:04:26 +0000 Subject: [Development] =?utf-8?q?Nominating_Pasi_Ker=C3=A4nen_for_Approver?= =?utf-8?q?_status?= In-Reply-To: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> References: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> Message-ID: <6428231.q9RDk4kDcb@cartman> On Monday 23 Nov 2015 12:46:05 Frederik Gladhorn wrote: > Hi all, > > I'd like to nominate Pasi Keränen as Approver in the Qt Project. He is > actually already a maintainer for the Qt Canvas 3D module, so this will > actually "complete" his maintainer status with the general approver bit. He isn't already? Of course a big +1 from me. Cheers, Sean > > Pasi is a great colleague and fun to work with. He has a focus on 3D and > lately became more active in the Qt 3D module as well. > > Gerrit dashboard: > https://codereview.qt-project.org/#/q/owner:%22Pasi+Ker%25C3%25A4nen+ > %253Cpasi.keranen%2540theqtcompany.com%253E%22,n,z > > Cheers, > Frederik > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK KDAB (UK) Ltd, a KDAB Group company Tel. +44 (0)1625 809908; Sweden (HQ) +46-563-540090 Mobile: +44 (0)7545 140604 KDAB - Qt Experts From Lars.Knoll at theqtcompany.com Mon Nov 23 13:05:39 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 23 Nov 2015 12:05:39 +0000 Subject: [Development] =?utf-8?q?Nominating_Pasi_Ker=C3=A4nen_for_Approver?= =?utf-8?q?_status?= In-Reply-To: References: <1971491.miAyTmngjk@frederik-thinkcentre-m93p> Message-ID: And another big +1 from me :) Cheers, Lars On 23/11/15 12:55, "Development on behalf of Hausmann Simon" wrote: >+1 > > >Simon > >________________________________________ >From: Development on behalf of Frederik Gladhorn >Sent: Monday, November 23, 2015 12:46 >To: development at qt-project.org >Subject: [Development] Nominating Pasi Keränen for Approver status > >Hi all, > >I'd like to nominate Pasi Keränen as Approver in the Qt Project. He is >actually already a maintainer for the Qt Canvas 3D module, so this will >actually "complete" his maintainer status with the general approver bit. > >Pasi is a great colleague and fun to work with. He has a focus on 3D and >lately became more active in the Qt 3D module as well. > >Gerrit dashboard: >https://codereview.qt-project.org/#/q/owner:%22Pasi+Ker%25C3%25A4nen+ >%253Cpasi.keranen%2540theqtcompany.com%253E%22,n,z > >Cheers, >Frederik >_______________________________________________ >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 marc.mutz at kdab.com Mon Nov 23 14:40:38 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Mon, 23 Nov 2015 14:40:38 +0100 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <14071234.PvcYbKEM6S@finn> References: <2179031.L5GMPoFkkI@tjmaciei-mobl4> <14071234.PvcYbKEM6S@finn> Message-ID: <201511231440.39696.marc.mutz@kdab.com> On Monday 23 November 2015 09:59:43 Olivier Goffart wrote: > On Friday 13. November 2015 10:37:25 Thiago Macieira wrote: > > One more thing: I'd like a whitelist of features that have been tested > > and are known to work on all platforms. > > The white list can be obtained by doing 'git grep "std::"' :-) > > Anyway, i'd like to start the white list with std::enable_if I'd like to add , too. And std::declval<>. All of enable_if, declval, and type_traits don't enter the ABI, even though they are part of the API (correct?). I'd also like to discuss deprecating QPair for std::pair. The standard prescribes the layout of a std::pair, so I don't see how two implementations can be binary incompatible. In particular, the optimisation of boost's compressed_pair, which takes advantage of the empty base class optimisation to squash empty element types, doesn't seem to be allowed for std::pair. (In general, though, I'd -1 any new API using QPair or std::pair instead of a hand-made small struct, unless the latter isn't possible (in generic code, say)). 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 Mon Nov 23 17:20:08 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 23 Nov 2015 08:20:08 -0800 Subject: [Development] Qt LTS & C++11 plans In-Reply-To: <201511231440.39696.marc.mutz@kdab.com> References: <14071234.PvcYbKEM6S@finn> <201511231440.39696.marc.mutz@kdab.com> Message-ID: <4957407.5QgDHubuha@tjmaciei-mobl4> On Monday 23 November 2015 14:40:38 Marc Mutz wrote: > > The white list can be obtained by doing 'git grep "std::"' :-) > > > > > > > > Anyway, i'd like to start the white list with std::enable_if > > I'd like to add , too. And std::declval<>. > > All of enable_if, declval, and type_traits don't enter the ABI, even though > they are part of the API (correct?). Then please add this info to the wiki page on library coding conventions. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From laszlo.agocs at theqtcompany.com Tue Nov 24 10:04:17 2015 From: laszlo.agocs at theqtcompany.com (Agocs Laszlo) Date: Tue, 24 Nov 2015 09:04:17 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Pasi_Pet=E4j=E4j=E4rvi_fo?= =?iso-8859-1?q?r_Approver_status?= Message-ID: Hello, I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt Project. Pasi is the maintainer of the VxWorks port and has also been contributing a lot for other embedded platforms over the years. Public Gerrit dashboard: https://codereview.qt-project.org/#/q/owner:pasi.petajajarvi,n,z Best regards, Laszlo -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirik.aavitsland at theqtcompany.com Tue Nov 24 11:13:27 2015 From: eirik.aavitsland at theqtcompany.com (Eirik Aavitsland) Date: Tue, 24 Nov 2015 11:13:27 +0100 Subject: [Development] =?utf-8?b?Tm9taW5hdGluZyBQYXNpIFBldMOkasOkasOkcnZp?= =?utf-8?q?_for_Approver_status?= In-Reply-To: References: Message-ID: <56543847.8020407@theqtcompany.com> On 11/24/2015 10:04 AM, Agocs Laszlo wrote: > Hello, > > I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt > Project. > > Pasi is the maintainer of the VxWorks port and has also been > contributing a lot for other embedded platforms over the years. > +1 - Eirik Aa. From rjvbertin at gmail.com Tue Nov 24 11:25:46 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 24 Nov 2015 11:25:46 +0100 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] Message-ID: <2336038.eOTL747QKn@patux.local> Hello, This is a follow-up question to one I posted yesterday. Looking into the paths used for QSP::RuntimeLocation in more detail I noticed that GLib has its own ideas, using $HOME/.cache on OS X: https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-runtime-dir I have the impression that it's not that uncommon to use glib from Qt-based applications; how (un)likely is it that the disagreement on the location of the user runtime directory will lead to issues? R PS: why did Qt choose ~/Library/Application Support for that location? Isn't the stuff stored there supposed to be volatile that doesn't need to survive reboots or end up in (Time Machine) backups? From Simon.Hausmann at theqtcompany.com Tue Nov 24 11:30:32 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Tue, 24 Nov 2015 10:30:32 +0000 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] In-Reply-To: <2336038.eOTL747QKn@patux.local> References: <2336038.eOTL747QKn@patux.local> Message-ID: Hi, I think the chances of a Qt application depending on glib on Mac OS X are extremely slim, given that glib is not part of the default system installation. I think the much more common case of a Qt application on Mac OS X is to just use Qt and the system APIs without any third-party library dependency. So I think it makes sense if our defaults align towards that use-case and with what apple recommends for applications. Their documentation makes a compelling case IMO: https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html Simon ________________________________________ From: Development on behalf of René J. V. Bertin Sent: Tuesday, November 24, 2015 11:25 To: development at qt-project.org Subject: [Development] glib's and Qt's RuntimeLocation [OS X] Hello, This is a follow-up question to one I posted yesterday. Looking into the paths used for QSP::RuntimeLocation in more detail I noticed that GLib has its own ideas, using $HOME/.cache on OS X: https://developer.gnome.org/glib/stable/glib-Miscellaneous-Utility-Functions.html#g-get-user-runtime-dir I have the impression that it's not that uncommon to use glib from Qt-based applications; how (un)likely is it that the disagreement on the location of the user runtime directory will lead to issues? R PS: why did Qt choose ~/Library/Application Support for that location? Isn't the stuff stored there supposed to be volatile that doesn't need to survive reboots or end up in (Time Machine) backups? _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From rjvbertin at gmail.com Tue Nov 24 12:09:34 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Tue, 24 Nov 2015 12:09:34 +0100 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] In-Reply-To: References: <2336038.eOTL747QKn@patux.local> Message-ID: <3808874.ztW0XVQ8bo@patux> On Tuesday November 24 2015 10:30:32 Hausmann Simon wrote: Hi, >I think the chances of a Qt application depending on glib on Mac OS X are extremely slim, >given that glib is not part of the default system installation. That strikes me as a bit of a surprising argument for a middleware that is cross-platform by its very nature, and not any more part of a default system installation than glib... Chances of a direct dependency appear slim, but they increase (probably considerably) if you consider indirect dependencies. And of course glib isn't likely to be the only API on which applications can depend and that uses the concept of a user runtime directory that's based on XDG principles. Note that I'm not really calling your choice into question (a bit more the fact that RuntimeLocation returns the "AppSupport" root, and leaves it to the application to add e.g. its name, to comply with sandboxing principles). >I think the much more common case of a Qt application on Mac OS X is to just use Qt and the system APIs without any third-party library dependency. So I think it makes sense if our defaults align towards that use-case and with what apple recommends for applications. Their documentation makes a compelling case IMO: > >https://developer.apple.com/library/mac/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html What part exactly? I don't have access to my Mac right now, but it seems to me that OS X also has equivalent user directories under /var (/private/var if you prefer). R From Andy.Nichols at theqtcompany.com Tue Nov 24 13:03:35 2015 From: Andy.Nichols at theqtcompany.com (Nichols Andy) Date: Tue, 24 Nov 2015 12:03:35 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_Pasi_Pet=E4j=E4j=E4rvi_fo?= =?iso-8859-1?q?r_Approver_status?= In-Reply-To: References: Message-ID: I would like to nominate Pasi Petäjäjärvi for Approver status in the Qt Project. Pasi is the maintainer of the VxWorks port and has also been contributing a lot for other embedded platforms over the years. +1 from me as well. Great to have more embedded experts as approvers ;-) Regards, Andy Nichols -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jake.Petroules at theqtcompany.com Tue Nov 24 17:51:37 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Tue, 24 Nov 2015 16:51:37 +0000 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] In-Reply-To: <2336038.eOTL747QKn@patux.local> References: <2336038.eOTL747QKn@patux.local> Message-ID: On Nov 24, 2015, at 2:25 AM, René J. V. Bertin > wrote: PS: why did Qt choose ~/Library/Application Support for that location? Isn't the stuff stored there supposed to be volatile that doesn't need to survive reboots or end up in (Time Machine) backups? ~/Library/Application Support is non volatile and absolutely must survive reboots. ~/Library/Cache does not. -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Tue Nov 24 19:58:22 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 24 Nov 2015 19:58:22 +0100 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] References: <2336038.eOTL747QKn@patux.local> Message-ID: <2869532.vjZug5W4un@portia.local> Petroules Jake wrote: > PS: why did Qt choose ~/Library/Application Support for that location? Isn't > the stuff stored there supposed to be volatile that doesn't need to survive > reboots or end up in (Time Machine) backups? > > ~/Library/Application Support is non volatile and absolutely must survive > reboots. ~/Library/Cache does not. -- Yes, that was the argument -- the "there" referred to RuntimeLocation which AFAIK does not need to survive reboots or be backed up. I'd have chosen $TMPDIR (aka QDir::tempPath()) myself. Contrary to ~/Library/Cache that one is cleared on each reboot, which seems advantageous at least for the kind of things RuntimeLocation is used for in FOSS/Freedesktop applications. It's not much of an issue, though I did modify my QSP/XDG patch to include RuntimeLocation when XDG mode is activated. R From thiago.macieira at intel.com Tue Nov 24 22:03:38 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 24 Nov 2015 13:03:38 -0800 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] In-Reply-To: <2869532.vjZug5W4un@portia.local> References: <2336038.eOTL747QKn@patux.local> <2869532.vjZug5W4un@portia.local> Message-ID: <2674556.zCHCq2yifi@tjmaciei-mobl4> On Tuesday 24 November 2015 19:58:22 René J. V. Bertin wrote: > I'd have chosen $TMPDIR (aka QDir::tempPath()) myself. Contrary to > ~/Library/Cache that one is cleared on each reboot, which seems advantageous > at least for the kind of things RuntimeLocation is used for in > FOSS/Freedesktop applications. It mustn't be $TMPDIR. It needs to be a directory owned by the user so no other users can create files or sockets or FIFOs in there (no chance for malicious collision). It could be a subdir of $TMPDIR, but then we run into a race condition problem of creating a secure subdir with a well-established name among applications. That's why the XDG spec says that XDG_RUNTIME_DIR *must* have been created when the user logs in and must be removed when the user fully logs out. The fallback option that QStandardDirs offers when XDG_RUNTIME_DIR isn't set has those problems: it has race conditions and, because of that, it isn't secure. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Tue Nov 24 23:04:59 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Tue, 24 Nov 2015 23:04:59 +0100 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] References: <2336038.eOTL747QKn@patux.local> <2869532.vjZug5W4un@portia.local> <2674556.zCHCq2yifi@tjmaciei-mobl4> Message-ID: <3393474.8Wp8T594mf@portia.local> Thiago Macieira wrote: > It mustn't be $TMPDIR. It needs to be a directory owned by the user so no You're missing a detail. On OS X, $TMPDIR (and QDir::tempPath()) *are* user specific. They're also very "immemorable"... > It could be a subdir of $TMPDIR, but then we run into a race condition problem > of creating a secure subdir with a well-established name among applications. > That's why the XDG spec says that XDG_RUNTIME_DIR *must* have been created > when the user logs in and must be removed when the user fully logs out. The former is true for $TMPDIR on OS X, but it is not deleted. The contents are wiped at reboot though, so the Unix fallback directory does get cleaned at that occasion. Do you have any idea what RuntimeLocation is used for on hosts that don't follow XDG principles (OS X, MS Windows) -- beyond what individual applications can decide evidently? R. From thiago.macieira at intel.com Wed Nov 25 00:57:33 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 24 Nov 2015 15:57:33 -0800 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] In-Reply-To: <3393474.8Wp8T594mf@portia.local> References: <2336038.eOTL747QKn@patux.local> <2674556.zCHCq2yifi@tjmaciei-mobl4> <3393474.8Wp8T594mf@portia.local> Message-ID: <6165678.gBgiVGhxtx@tjmaciei-mobl4> On Tuesday 24 November 2015 23:04:59 René J. V. Bertin wrote: > Thiago Macieira wrote: > > It mustn't be $TMPDIR. It needs to be a directory owned by the user so no > > You're missing a detail. On OS X, $TMPDIR (and QDir::tempPath()) *are* user > specific. They're also very "immemorable"... They're not required to be. If we can detect that they are, then sure, we could use it as XDG_RUNTIME_DIR. But we need to detect as otherwise someone could set TMPDIR before starting the application. > > It could be a subdir of $TMPDIR, but then we run into a race condition > > problem of creating a secure subdir with a well-established name among > > applications. That's why the XDG spec says that XDG_RUNTIME_DIR *must* > > have been created when the user logs in and must be removed when the user > > fully logs out. > The former is true for $TMPDIR on OS X, but it is not deleted. The contents > are wiped at reboot though, so the Unix fallback directory does get cleaned > at that occasion. > > Do you have any idea what RuntimeLocation is used for on hosts that don't > follow XDG principles (OS X, MS Windows) -- beyond what individual > applications can decide evidently? That's why QStandardPaths has a table in the documentation listing all possibilities. For Windows, it's C:\Users\ (i.e., $HOME); Blackberry is /var/tmp; Android has /cache and it's not supported on iOS. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Simon.Hausmann at theqtcompany.com Wed Nov 25 07:25:34 2015 From: Simon.Hausmann at theqtcompany.com (Hausmann Simon) Date: Wed, 25 Nov 2015 06:25:34 +0000 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <20151125062158.7A0CE50175@mx.qt-project.org> References: , <20151125062158.7A0CE50175@mx.qt-project.org> Message-ID: <20151125062533.5935185.93932.50346@theqtcompany.com> Hi, It would seem that recent QPair changes have a negative impact on the ability to compile some existing code :) Is this an issue in the usage or an issue with QPair? Simon Original Message From: Qt CI Bot (Code Review) Sent: Wednesday, November 25, 2015 07:22 To: Qi Liang Cc: Hausmann Simon; Qt Sanity Bot; Nowacki Jedrzej; Gladhorn Frederik; Abrahamsen-Blomfeldt Eskil; Denis Shienkov; Kokko Antti Subject: Change in qt/qt5[dev]: Updated submodules. Qt CI Bot has posted comments on this change. Change subject: Updated submodules. ...................................................................... Continuous Integration: Failed Module "qt/qtenginio" (ea2f8a119986979465d3679b9c03469ed529d4f6) did not compile: base\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT1' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT2' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2059: syntax error: '>' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2976: 'std::is_nothrow_assignable': too few template arguments C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT1' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT2' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2059: syntax error: '>' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2976: 'std::is_nothrow_assignable': too few template arguments C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT1' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT2' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2059: syntax error: '>' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2976: 'std::is_nothrow_assignable': too few template arguments C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT1' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT2' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2059: syntax error: '>' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2976: 'std::is_nothrow_assignable': too few template arguments C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT1' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT2' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2059: syntax error: '>' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2976: 'std::is_nothrow_assignable': too few template arguments C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT1' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2923: 'std::is_nothrow_assignable': 'TT2' is not a valid template type argument for parameter '_From' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(77): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(QPair &&) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT1': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2059: syntax error: '>' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2976: 'std::is_nothrow_assignable': too few template arguments C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2955: 'std::is_nothrow_assignable': use of class template requires template argument list C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': undeclared identifier C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Program Files\Microsoft Visual Studio 14.0\VC\INCLUDE\type_traits(799): note: see declaration of 'std::is_nothrow_assignable' C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2057: expected constant expression C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This diagnostic occurred in the compiler generated function 'QPair &QPair::operator =(const QPair &) noexcept()' Build log: http://testresults.qt.io/logs/qt/qtenginio/ea2f8a119986979465d3679b9c03469ed529d4f6/WindowsWindows_10x86WindowsWindows_10x86MSVC2015DebugAndRelease_Release_OpenGLDynamic/b4d58bba40ce738dc962860279784ecebd1d7384/buildlog.txt.gz Details: http://testresults.qt.io/coin/integration/qt/qt5/tasks/1448431848.thrift_bin Tested changes (refs/builds/qtci/dev/1448431601): https://codereview.qt-project.org/#/q/8718a0c87cb915f8f0cb0266b373a07189b45aba,n,z Updated submodules. -- To view, visit https://codereview.qt-project.org/141800 To unsubscribe, visit https://codereview.qt-project.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I54527e1c5ad138ac63d38d8eabcf158d11b0286d Gerrit-PatchSet: 3 Gerrit-Project: qt/qt5 Gerrit-Branch: dev Gerrit-Owner: Liang Qi Gerrit-Reviewer: Antti Kokko Gerrit-Reviewer: Denis Shienkov Gerrit-Reviewer: Eskil Abrahamsen Blomfeldt Gerrit-Reviewer: Frederik Gladhorn Gerrit-Reviewer: J?drzej Nowacki Gerrit-Reviewer: Liang Qi Gerrit-Reviewer: Qt Sanity Bot Gerrit-Reviewer: Simon Hausmann Gerrit-HasComments: No From thiago.macieira at intel.com Wed Nov 25 07:49:59 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 24 Nov 2015 22:49:59 -0800 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <20151125062533.5935185.93932.50346@theqtcompany.com> References: <20151125062158.7A0CE50175@mx.qt-project.org> <20151125062533.5935185.93932.50346@theqtcompany.com> Message-ID: <1469745.VqfVkCRnEj@tjmaciei-mobl4> On Wednesday 25 November 2015 06:25:34 Hausmann Simon wrote: > Hi, > > It would seem that recent QPair changes have a negative impact on the > ability to compile some existing code :) > > Is this an issue in the usage or an issue with QPair? Compiler bug. > C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): note: This > diagnostic occurred in the compiler generated function 'QPair > &QPair::operator =(const QPair &) noexcept()' > C:\Users\qt\work\qt\qtbase\include\QtCore/qpair.h(65): error C2065: 'TT2': > undeclared identifier The line in question (qpair.h:65) is part of the declaration: template Q_DECL_RELAXED_CONSTEXPR QPair &operator=(QPair &&p) Q_DECL_NOEXCEPT_EXPR((std::is_nothrow_assignable::value && std::is_nothrow_assignable::value)) { first = std::move(p.first); second = std::move(p.second); return *this; } As can be seen, TT2 is declared as a template typename parameter. If the compiler is complaining that it isn't declared, it must be a compiler bug. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From marc.mutz at kdab.com Wed Nov 25 12:31:35 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Wed, 25 Nov 2015 12:31:35 +0100 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <1469745.VqfVkCRnEj@tjmaciei-mobl4> References: <20151125062533.5935185.93932.50346@theqtcompany.com> <1469745.VqfVkCRnEj@tjmaciei-mobl4> Message-ID: <201511251231.35612.marc.mutz@kdab.com> On Wednesday 25 November 2015 07:49:59 Thiago Macieira wrote: > As can be seen, TT2 is declared as a template typename parameter. If the > compiler is complaining that it isn't declared, it must be a compiler bug. That still begs the question why this comes up in "qtengineio". You'd guess that tst_qpair would have caught it... oh, right, tst_qpair... didn't exist before I added it for constexpr checks... grr. -- 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 Wed Nov 25 15:52:23 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Wed, 25 Nov 2015 15:52:23 +0100 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] Message-ID: <1961896.MD985YbvDI@portia.local> Thiago Macieira wrote: >> You're missing a detail. On OS X, $TMPDIR (and QDir::tempPath()) *are* user >> specific. They're also very "immemorable"... > > They're not required to be. If we can detect that they are, then sure, we > could use it as XDG_RUNTIME_DIR. >> > It could be a subdir of $TMPDIR, but then we run into a race condition >> > problem of creating a secure subdir with a well-established name among >> > applications. That's why the XDG spec says that XDG_RUNTIME_DIR *must* >> > have been created when the user logs in and must be removed when the user >> > fully logs out. It sounds like all this is hard to enforce without checking before returning a location. NB: that's what KDE does with the directory that is supposed to act as ... the trashbin! Note that OS X has NSString *NSTemporaryDirectory(), and also that QSP is already half set up to determine TempLocation via kTemporaryFolderType : kTemporaryFolderType = 'temp', /* On Mac OS X, each user has their own temporary items folder, and the Folder Manager attempts to set permissions of these*/ /* folders such that other users can not access the data inside. On Mac OS X 10.4 and later the data inside the temporary*/ /* items folder is deleted at logout and at boot, but not otherwise. Earlier version of Mac OS X would delete items inside*/ /* the temporary items folder after a period of inaccess. You can ask for a temporary item in a specific domain or on a */ /* particular volume by FSVolumeRefNum. If you want a location for temporary items for a short time, then use either*/ /* ( kUserDomain, kkTemporaryFolderType ) or ( kSystemDomain, kTemporaryFolderType ). The kUserDomain varient will always be*/ /* on the same volume as the user's home folder, while the kSystemDomain version will be on the same volume as /var/tmp/ ( and*/ /* will probably be on the local hard drive in case the user's home is a network volume ). If you want a location for a temporary*/ /* file or folder to use for saving a document, especially if you want to use FSpExchangeFile() to implement a safe-save, then*/ /* ask for the temporary items folder on the same volume as the file you are safe saving.*/ /* However, be prepared for a failure to find a temporary folder in any domain or on any volume. Some volumes may not have*/ /* a location for a temporary folder, or the permissions of the volume may be such that the Folder Manager can not return*/ /* a temporary folder for the volume.*/ /* If your application creates an item in a temporary items folder you should delete that item as soon as it is not needed,*/ /* and certainly before your application exits, since otherwise the item is consuming disk space until the user logs out or*/ /* restarts. Any items left inside a temporary items folder should be moved into a folder inside the Trash folder on the disk*/ /* when the user logs in, inside a folder named "Recovered items", in case there is anything useful to the end user.*/ The only open question is what `macLocation` domain should be returned by QSP::TempLocation: kUserDomain, kSystemDomain or kOnAppropriateDisk . Maybe Jake Petroules already addressed that question? R. -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Nov 25 18:19:08 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 25 Nov 2015 09:19:08 -0800 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <201511251231.35612.marc.mutz@kdab.com> References: <1469745.VqfVkCRnEj@tjmaciei-mobl4> <201511251231.35612.marc.mutz@kdab.com> Message-ID: <2146887.jlqNp1W864@tjmaciei-mobl4> On Wednesday 25 November 2015 12:31:35 Marc Mutz wrote: > On Wednesday 25 November 2015 07:49:59 Thiago Macieira wrote: > > As can be seen, TT2 is declared as a template typename parameter. If the > > compiler is complaining that it isn't declared, it must be a compiler bug. > > That still begs the question why this comes up in "qtengineio". You'd guess > that tst_qpair would have caught it... oh, right, tst_qpair... didn't exist > before I added it for constexpr checks... grr. There are other uses of QPair in the source code. Anyway, if this is a compiler bug, the conditions for triggering it may not be evident. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From aleixpol at kde.org Wed Nov 25 18:27:11 2015 From: aleixpol at kde.org (Aleix Pol) Date: Wed, 25 Nov 2015 18:27:11 +0100 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <2146887.jlqNp1W864@tjmaciei-mobl4> References: <1469745.VqfVkCRnEj@tjmaciei-mobl4> <201511251231.35612.marc.mutz@kdab.com> <2146887.jlqNp1W864@tjmaciei-mobl4> Message-ID: On Wed, Nov 25, 2015 at 6:19 PM, Thiago Macieira wrote: > On Wednesday 25 November 2015 12:31:35 Marc Mutz wrote: >> On Wednesday 25 November 2015 07:49:59 Thiago Macieira wrote: >> > As can be seen, TT2 is declared as a template typename parameter. If the >> > compiler is complaining that it isn't declared, it must be a compiler bug. >> >> That still begs the question why this comes up in "qtengineio". You'd guess >> that tst_qpair would have caught it... oh, right, tst_qpair... didn't exist >> before I added it for constexpr checks... grr. > > There are other uses of QPair in the source code. > > Anyway, if this is a compiler bug, the conditions for triggering it may not be > evident. Does the fact that it's a compiler bug change the fact that it should be changed on the Qt side of things? If we have this compiler on the CI, Qt users will have it as well. Aleix From Jake.Petroules at theqtcompany.com Wed Nov 25 19:37:41 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 25 Nov 2015 18:37:41 +0000 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] In-Reply-To: <1961896.MD985YbvDI@portia.local> References: <1961896.MD985YbvDI@portia.local> Message-ID: On Nov 25, 2015, at 6:52 AM, René J.V. Bertin > wrote: Thiago Macieira wrote: >> You're missing a detail. On OS X, $TMPDIR (and QDir::tempPath()) *are* user >> specific. They're also very "immemorable"... > > They're not required to be. If we can detect that they are, then sure, we > could use it as XDG_RUNTIME_DIR. >> > It could be a subdir of $TMPDIR, but then we run into a race condition >> > problem of creating a secure subdir with a well-established name among >> > applications. That's why the XDG spec says that XDG_RUNTIME_DIR *must* >> > have been created when the user logs in and must be removed when the user >> > fully logs out. It sounds like all this is hard to enforce without checking before returning a location. NB: that's what KDE does with the directory that is supposed to act as ... the trashbin! Note that OS X has NSString *NSTemporaryDirectory(), and also that QSP is already half set up to determine TempLocation via kTemporaryFolderType : kTemporaryFolderType = 'temp', /* On Mac OS X, each user has their own temporary items folder, and the Folder Manager attempts to set permissions of these*/ /* folders such that other users can not access the data inside. On Mac OS X 10.4 and later the data inside the temporary*/ /* items folder is deleted at logout and at boot, but not otherwise. Earlier version of Mac OS X would delete items inside*/ /* the temporary items folder after a period of inaccess. You can ask for a temporary item in a specific domain or on a */ /* particular volume by FSVolumeRefNum. If you want a location for temporary items for a short time, then use either*/ /* ( kUserDomain, kkTemporaryFolderType ) or ( kSystemDomain, kTemporaryFolderType ). The kUserDomain varient will always be*/ /* on the same volume as the user's home folder, while the kSystemDomain version will be on the same volume as /var/tmp/ ( and*/ /* will probably be on the local hard drive in case the user's home is a network volume ). If you want a location for a temporary*/ /* file or folder to use for saving a document, especially if you want to use FSpExchangeFile() to implement a safe-save, then*/ /* ask for the temporary items folder on the same volume as the file you are safe saving.*/ /* However, be prepared for a failure to find a temporary folder in any domain or on any volume. Some volumes may not have*/ /* a location for a temporary folder, or the permissions of the volume may be such that the Folder Manager can not return*/ /* a temporary folder for the volume.*/ /* If your application creates an item in a temporary items folder you should delete that item as soon as it is not needed,*/ /* and certainly before your application exits, since otherwise the item is consuming disk space until the user logs out or*/ /* restarts. Any items left inside a temporary items folder should be moved into a folder inside the Trash folder on the disk*/ /* when the user logs in, inside a folder named "Recovered items", in case there is anything useful to the end user.*/ The only open question is what `macLocation` domain should be returned by QSP::TempLocation: kUserDomain, kSystemDomain or kOnAppropriateDisk . Maybe Jake Petroules already addressed that question? In 5.7 QStandardPaths just uses QDir::tempPath(); there are no more calls to the Carbon File Manager. R. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From thiago.macieira at intel.com Wed Nov 25 20:32:50 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Wed, 25 Nov 2015 11:32:50 -0800 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: References: <2146887.jlqNp1W864@tjmaciei-mobl4> Message-ID: <2216857.uYgr0j4lI8@tjmaciei-mobl4> On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote: > > Anyway, if this is a compiler bug, the conditions for triggering it may > > not be evident. > > Does the fact that it's a compiler bug change the fact that it should > be changed on the Qt side of things? > > If we have this compiler on the CI, Qt users will have it as well. No, it does not change the fact that we need to either work around or remove the change that triggered it. Qt needs to compile with MSVC 2015. One way to do that is to disable noexcept for MSVC2015. Another is to remove the use of . If the change is to remove noexcept, I'd like to know if Update 1 fixes the issue. If it doesn't, it would be a good idea to dissect a testcase and submit to Microsoft. It would be the fourth one for Update 1 that we found just by compiling Qt with all the C++11 features enabled... -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From rjvbertin at gmail.com Wed Nov 25 21:24:10 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 25 Nov 2015 21:24:10 +0100 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] References: <1961896.MD985YbvDI@portia.local> Message-ID: <1798568.AMUR4gzKIE@portia.local> Petroules Jake wrote: [snipped] > The only open question is what `macLocation` domain should be returned by > QSP::TempLocation: kUserDomain, kSystemDomain or kOnAppropriateDisk . Maybe > Jake Petroules already addressed that question? > > In 5.7 QStandardPaths just uses QDir::tempPath(); there are no more calls to > the Carbon File Manager. If 5.7 still uses ObjC++ for qstandardpaths_mac, you could use NSTemporaryDirectory() for QSP::TempLocation, and let QDir::tempPath() use that, instead of the other way round. That would remove Thiago's critique that someone could change $TMPDIR. Or one could avoid QDir::tempPath() in RuntimeLocation and use NSTemporaryDirectory instead, if tempPath() is supposed to return $TMPDIR in order to be under user control. R. From Jake.Petroules at theqtcompany.com Wed Nov 25 21:29:20 2015 From: Jake.Petroules at theqtcompany.com (Petroules Jake) Date: Wed, 25 Nov 2015 20:29:20 +0000 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] In-Reply-To: <1798568.AMUR4gzKIE@portia.local> References: <1961896.MD985YbvDI@portia.local> <1798568.AMUR4gzKIE@portia.local> Message-ID: On Nov 25, 2015, at 12:24 PM, René J. V. Bertin > wrote: Petroules Jake wrote: [snipped] The only open question is what `macLocation` domain should be returned by QSP::TempLocation: kUserDomain, kSystemDomain or kOnAppropriateDisk . Maybe Jake Petroules already addressed that question? In 5.7 QStandardPaths just uses QDir::tempPath(); there are no more calls to the Carbon File Manager. If 5.7 still uses ObjC++ for qstandardpaths_mac, you could use NSTemporaryDirectory() for QSP::TempLocation, and let QDir::tempPath() use that, instead of the other way round. That would remove Thiago's critique that someone could change $TMPDIR. Or one could avoid QDir::tempPath() in RuntimeLocation and use NSTemporaryDirectory instead, if tempPath() is supposed to return $TMPDIR in order to be under user control. R. Feel free to take action if Thiago agrees; I have no particular opinions about how it's "supposed" to work. _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development -- Jake Petroules - jake.petroules at theqtcompany.com Consulting Services Engineer - The Qt Company -------------- next part -------------- An HTML attachment was scrubbed... URL: From rjvbertin at gmail.com Wed Nov 25 22:14:54 2015 From: rjvbertin at gmail.com (=?UTF-8?B?UmVuw6kgSi4gVi4=?= Bertin) Date: Wed, 25 Nov 2015 22:14:54 +0100 Subject: [Development] glib's and Qt's RuntimeLocation [OS X] References: <1961896.MD985YbvDI@portia.local> <1798568.AMUR4gzKIE@portia.local> Message-ID: <1904840.otj6LJ7xQn@portia.local> Petroules Jake wrote: > Feel free to take action if Thiago agrees; I have no particular opinions about > how it's "supposed" to work. Ok, we'll see then. But for the record, QString::fromNSString(NSTemporaryDirectory()) returns "$TMPDIR/" (trailing slash included), presuming that TMPDIR is left at the value set by the OS, at login. It does *not* simply echo the current value of $TMPDIR, contrary to QDir::tempPath(). R. From marc.mutz at kdab.com Thu Nov 26 09:53:24 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 26 Nov 2015 09:53:24 +0100 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <2216857.uYgr0j4lI8@tjmaciei-mobl4> References: <2216857.uYgr0j4lI8@tjmaciei-mobl4> Message-ID: <201511260953.24969.marc.mutz@kdab.com> On Wednesday 25 November 2015 20:32:50 Thiago Macieira wrote: > On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote: > > > Anyway, if this is a compiler bug, the conditions for triggering it may > > > not be evident. > > > > Does the fact that it's a compiler bug change the fact that it should > > be changed on the Qt side of things? > > > > If we have this compiler on the CI, Qt users will have it as well. > > No, it does not change the fact that we need to either work around or > remove the change that triggered it. Qt needs to compile with MSVC 2015. > > One way to do that is to disable noexcept for MSVC2015. Another is to > remove the use of . We cannot remove the use, because we cannot replace it with the noexcept operator we used before, because that already failed. We cannot remove noexcept in general, because it's now part of the API. We can, however, remove it for just MSVC. > If the change is to remove noexcept, I'd like to know if Update 1 fixes the > issue. If it doesn't, it would be a good idea to dissect a testcase and > submit to Microsoft. It would be the fourth one for Update 1 that we found > just by compiling Qt with all the C++11 features enabled... Here's a test case for what I think might be the problem: https://codereview.qt-project.org/141999 The code which triggers this seems to come from a mismatch of QPair vs. QPair where either S1 != T1 or S2 != T2. The error also suggested that an rvalue is passed as the RHS. A fix in Qt would therefore be to avoid the T/S mismatch in qtengineio, leaving users with the same problem, or revoke NOEXCEPT for MSVC. A third option (you should always have three) is to bring out the template-foo to remove references, cv-qualifiers and arrays from the type before passing it to std::declval, similar to what we did before, but recognizing the QPair problem and working around it. 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 faure at kde.org Thu Nov 26 09:39:18 2015 From: faure at kde.org (David Faure) Date: Thu, 26 Nov 2015 09:39:18 +0100 Subject: [Development] QLocale changed? Message-ID: <1732413.gfBjQQpNsN@asterix> This: QCOMPARE(QLocale::c().toString(1234.0, 'f', 0), QString("1,234")); was the behavior until Qt 5.5 With Qt 5.6, this happens: Actual (QLocale::c().toString(1234.0, 'f', 0)): "1234" Expected (QString("1,234")) : "1,234" Is this an expected change? -- David Faure, faure at kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 From Lars.Knoll at theqtcompany.com Thu Nov 26 09:55:44 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Thu, 26 Nov 2015 08:55:44 +0000 Subject: [Development] QLocale changed? In-Reply-To: <1732413.gfBjQQpNsN@asterix> References: <1732413.gfBjQQpNsN@asterix> Message-ID: <18604787-9347-4602-A025-D931775687E9@theqtcompany.com> Its a behavioural change, after we got quite a few bug reports about this behaviour (being inconsistent with what people expect). See change 3695285fde904935fc2e88010dac171144e8677a and the bug reports mentioned in there. Cheers, Lars On 26/11/15 09:39, "Development on behalf of David Faure" wrote: >This: > > QCOMPARE(QLocale::c().toString(1234.0, 'f', 0), QString("1,234")); > >was the behavior until Qt 5.5 > >With Qt 5.6, this happens: > > Actual (QLocale::c().toString(1234.0, 'f', 0)): "1234" > Expected (QString("1,234")) : "1,234" > >Is this an expected change? > >-- >David Faure, faure at kde.org, http://www.davidfaure.fr >Working on KDE Frameworks 5 > >_______________________________________________ >Development mailing list >Development at qt-project.org >http://lists.qt-project.org/mailman/listinfo/development From Kai.Koehne at theqtcompany.com Thu Nov 26 10:10:50 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 26 Nov 2015 09:10:50 +0000 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <201511260953.24969.marc.mutz@kdab.com> References: <2216857.uYgr0j4lI8@tjmaciei-mobl4> <201511260953.24969.marc.mutz@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf > Of Marc Mutz > Sent: Thursday, November 26, 2015 9:53 AM > To: development at qt-project.org > Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. > > On Wednesday 25 November 2015 20:32:50 Thiago Macieira wrote: > > On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote: > > > > Anyway, if this is a compiler bug, the conditions for triggering > > > > it may not be evident. > > > > > > Does the fact that it's a compiler bug change the fact that it > > > should be changed on the Qt side of things? > > > > > > If we have this compiler on the CI, Qt users will have it as well. > > > > No, it does not change the fact that we need to either work around or > > remove the change that triggered it. Qt needs to compile with MSVC 2015. > > > > One way to do that is to disable noexcept for MSVC2015. Another is to > > remove the use of . > > We cannot remove the use, because we cannot replace it with the > noexcept operator we used before, because that already failed. We cannot > remove noexcept in general, because it's now part of the API. We can, however, > remove it for just MSVC. > > > If the change is to remove noexcept, I'd like to know if Update 1 > > fixes the issue. If it doesn't, it would be a good idea to dissect a > > testcase and submit to Microsoft. It would be the fourth one for > > Update 1 that we found just by compiling Qt with all the C++11 features > enabled... > > Here's a test case for what I think might be the problem: > > https://codereview.qt-project.org/141999 The test in this and the following patch set compile fine for me with MSVC 2015 (32 bit), while qtenginio fails. So it's not actually testing the problem. Regards Kai From marc.mutz at kdab.com Thu Nov 26 12:00:13 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 26 Nov 2015 12:00:13 +0100 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: References: <201511260953.24969.marc.mutz@kdab.com> Message-ID: <201511261200.14000.marc.mutz@kdab.com> On Thursday 26 November 2015 10:10:50 Koehne Kai wrote: > > -----Original Message----- > > From: Development [mailto:development-bounces at qt-project.org] On Behalf > > Of Marc Mutz > > Sent: Thursday, November 26, 2015 9:53 AM > > To: development at qt-project.org > > Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. > > > > On Wednesday 25 November 2015 20:32:50 Thiago Macieira wrote: > > > On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote: > > > > > Anyway, if this is a compiler bug, the conditions for triggering > > > > > it may not be evident. > > > > > > > > Does the fact that it's a compiler bug change the fact that it > > > > should be changed on the Qt side of things? > > > > > > > > If we have this compiler on the CI, Qt users will have it as well. > > > > > > No, it does not change the fact that we need to either work around or > > > remove the change that triggered it. Qt needs to compile with MSVC > > > 2015. > > > > > > One way to do that is to disable noexcept for MSVC2015. Another is to > > > remove the use of . > > > > We cannot remove the use, because we cannot replace it with > > the noexcept operator we used before, because that already failed. We > > cannot remove noexcept in general, because it's now part of the API. We > > can, however, remove it for just MSVC. > > > > > If the change is to remove noexcept, I'd like to know if Update 1 > > > fixes the issue. If it doesn't, it would be a good idea to dissect a > > > testcase and submit to Microsoft. It would be the fourth one for > > > Update 1 that we found just by compiling Qt with all the C++11 features > > > > enabled... > > > > Here's a test case for what I think might be the problem: > > https://codereview.qt-project.org/141999 > > The test in this and the following patch set compile fine for me with MSVC > 2015 (32 bit), while qtenginio fails. So it's not actually testing the > problem. Then can someone please paste the code in question, because the error message didn't seem to include a location in enginio... 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 Kai.Koehne at theqtcompany.com Thu Nov 26 11:36:57 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Thu, 26 Nov 2015 10:36:57 +0000 Subject: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. In-Reply-To: <201511261200.14000.marc.mutz@kdab.com> References: <201511260953.24969.marc.mutz@kdab.com> <201511261200.14000.marc.mutz@kdab.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf > Of Marc Mutz > Sent: Thursday, November 26, 2015 12:00 PM > To: development at qt-project.org > Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. > > On Thursday 26 November 2015 10:10:50 Koehne Kai wrote: > > > -----Original Message----- > > > From: Development [mailto:development-bounces at qt-project.org] On > > > Behalf Of Marc Mutz > > > Sent: Thursday, November 26, 2015 9:53 AM > > > To: development at qt-project.org > > > Subject: Re: [Development] Fw: Change in qt/qt5[dev]: Updated submodules. > > > > > > On Wednesday 25 November 2015 20:32:50 Thiago Macieira wrote: > > > > On Wednesday 25 November 2015 18:27:11 Aleix Pol wrote: > > > > > > Anyway, if this is a compiler bug, the conditions for > > > > > > triggering it may not be evident. > > > > > > > > > > Does the fact that it's a compiler bug change the fact that it > > > > > should be changed on the Qt side of things? > > > > > > > > > > If we have this compiler on the CI, Qt users will have it as well. > > > > > > > > No, it does not change the fact that we need to either work around > > > > or remove the change that triggered it. Qt needs to compile with > > > > MSVC 2015. > > > > > > > > One way to do that is to disable noexcept for MSVC2015. Another is > > > > to remove the use of . > > > > > > We cannot remove the use, because we cannot replace it > > > with the noexcept operator we used before, because that already > > > failed. We cannot remove noexcept in general, because it's now part > > > of the API. We can, however, remove it for just MSVC. > > > > > > > If the change is to remove noexcept, I'd like to know if Update 1 > > > > fixes the issue. If it doesn't, it would be a good idea to dissect > > > > a testcase and submit to Microsoft. It would be the fourth one for > > > > Update 1 that we found just by compiling Qt with all the C++11 > > > > features > > > > > > enabled... > > > > > > Here's a test case for what I think might be the problem: > > > https://codereview.qt-project.org/141999 > > > > The test in this and the following patch set compile fine for me with > > MSVC > > 2015 (32 bit), while qtenginio fails. So it's not actually testing the > > problem. > > Then can someone please paste the code in question, because the error > message didn't seem to include a location in enginio... I created a bug report with a stripped down example: https://bugreports.qt.io/browse/QTBUG-49658 Cheers Kai From christianbauer at siemens.com Thu Nov 26 11:50:10 2015 From: christianbauer at siemens.com (Bauer, Christian) Date: Thu, 26 Nov 2015 10:50:10 +0000 Subject: [Development] QFutureInterface Message-ID: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> Hello, There was a discussion about the "internal" class QFutureInterface a few months ago on this list [1] about making QFuture/QFutureInterface more like std::future/std::promise in C++11. It seems this is not going to happen before Qt 6. We have a use case for a promise though and the current QFutureInterface is not sufficient. A custom wrapper for the QFutureInterface solves this problem for now, but requires a patch of Qt. I am wondering if you are willing to incorporate this patch into the official Qt release. It's about adding a getter to QFutureInterfaceBase for the d pointer QWaitCondition. Such a getter already exists inside the QFutureInterfaceBase for the d pointer QMutex. Thanks Christian [1] http://lists.qt-project.org/pipermail/development/2015-July/022586.html From marc.mutz at kdab.com Thu Nov 26 13:32:54 2015 From: marc.mutz at kdab.com (Marc Mutz) Date: Thu, 26 Nov 2015 13:32:54 +0100 Subject: [Development] QFutureInterface In-Reply-To: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> References: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> Message-ID: <201511261332.54740.marc.mutz@kdab.com> Hi Christian, On Thursday 26 November 2015 11:50:10 Bauer, Christian wrote: > Hello, > > There was a discussion about the "internal" class QFutureInterface a few > months ago on this list [1] about making QFuture/QFutureInterface more > like std::future/std::promise in C++11. It seems this is not going to > happen before Qt 6. > > We have a use case for a promise though and the current QFutureInterface is > not sufficient. A custom wrapper for the QFutureInterface solves this > problem for now, but requires a patch of Qt. > > I am wondering if you are willing to incorporate this patch into the > official Qt release. It's about adding a getter to QFutureInterfaceBase > for the d pointer QWaitCondition. Such a getter already exists inside the > QFutureInterfaceBase for the d pointer QMutex. You should be able to develop a QPromise/QPackagedTask with the current QFutureInterface already. At least as long as it's attached to some QThreadPool. What, exactly, are you trying to do that requires a patch to QFI? 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 announce at qt-project.org Thu Nov 26 13:10:27 2015 From: announce at qt-project.org (List for announcements regarding Qt releases and development) Date: Thu, 26 Nov 2015 12:10:27 +0000 Subject: [Development] [Announce] Qt Creator 3.6 RC1 released Message-ID: We are happy to announce the release of Qt Creator 3.6 RC1: http://blog.qt.io/blog/2015/11/26/qt-creator-3-6-rc1-released/ Br, -- 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 sergio.martins at kdab.com Thu Nov 26 22:18:04 2015 From: sergio.martins at kdab.com (Sergio Martins) Date: Thu, 26 Nov 2015 21:18:04 +0000 Subject: [Development] QDateTime is missing shared null optimization In-Reply-To: References: <1913461.pj1cWZrqNP@agathebauer> <9049509.VvP2y0TsRn@tjmaciei-mobl4> Message-ID: <1589873.26HKSccYy0@desktop> On Sunday, 2 August 2015 01:24:50 WET John Layt wrote: > It would require a lot of shuffling code around, as a lot of code is > in the d_ptr, it would horribly complicate things and there's the > potential for interesting corner cases, like say adding enough years > to a date to push it from one implementation to another... Is the > complexity worth it? It would also require a bunch of ifdefs because of 32 bit platforms. If nobody is interested in implementing Robert's idea then I'm available to implement "use a nullptr to indicate shared null". Regards, -- Sérgio Martins | sergio.martins at kdab.com | Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt Experts From eskil.abrahamsen-blomfeldt at theqtcompany.com Fri Nov 27 11:46:56 2015 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil A. Blomfeldt) Date: Fri, 27 Nov 2015 11:46:56 +0100 Subject: [Development] Suggestion for change on how blockers are marked in Jira Message-ID: <565834A0.9090600@theqtcompany.com> Hi! We've had a few informal discussions locally about the current process of manually adding bugs to a meta-task in order for them to be considered blockers for a particular release. Wouldn't it be more practical if this was baked into the information you register on the bug itself, so that it can easily be added to filters and so that you don't have to search for the task to let the release team know about it? Our suggestion is: Instead of the meta-task, we use the "Fix version" field. The combination of "Status: Closed" and "Fix version" is currently used to indicate the first version containing a particular fix. "Status: Open" and "Fix version", however, has a very loose definition at best. Since we're doing time-based releases, it gives a promise it might not be able to keep, so the preference has been to leave the field unset until the report is closed. So we could define it like this: If a bug report is open and has "Fix version: Qt X.Y", then it will be considered a blocker for Qt X.Y. The release team will maintain this the same way they maintain the meta-task, and will override it if they disagree that it should be a blocker. When the report is closed, the "Fix version/s" field is set to the versions that actually contain the fix as before. -- Eskil From tor.arne.vestbo at theqtcompany.com Fri Nov 27 13:01:35 2015 From: tor.arne.vestbo at theqtcompany.com (=?UTF-8?Q?Tor_Arne_Vestb=c3=b8?=) Date: Fri, 27 Nov 2015 13:01:35 +0100 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: <565834A0.9090600@theqtcompany.com> References: <565834A0.9090600@theqtcompany.com> Message-ID: <5658461F.7070209@theqtcompany.com> Yes x 1000 On 27/11/15 11:46, Eskil A. Blomfeldt wrote: > Hi! > > We've had a few informal discussions locally about the current process > of manually adding bugs to a meta-task in order for them to be > considered blockers for a particular release. > > Wouldn't it be more practical if this was baked into the information you > register on the bug itself, so that it can easily be added to filters > and so that you don't have to search for the task to let the release > team know about it? > > Our suggestion is: Instead of the meta-task, we use the "Fix version" > field. The combination of "Status: Closed" and "Fix version" is > currently used to indicate the first version containing a particular > fix. "Status: Open" and "Fix version", however, has a very loose > definition at best. Since we're doing time-based releases, it gives a > promise it might not be able to keep, so the preference has been to > leave the field unset until the report is closed. > > So we could define it like this: If a bug report is open and has "Fix > version: Qt X.Y", then it will be considered a blocker for Qt X.Y. The > release team will maintain this the same way they maintain the > meta-task, and will override it if they disagree that it should be a > blocker. > > When the report is closed, the "Fix version/s" field is set to the > versions that actually contain the fix as before. > > -- Eskil From christian.kandeler at theqtcompany.com Fri Nov 27 13:44:57 2015 From: christian.kandeler at theqtcompany.com (Christian Kandeler) Date: Fri, 27 Nov 2015 13:44:57 +0100 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: <565834A0.9090600@theqtcompany.com> References: <565834A0.9090600@theqtcompany.com> Message-ID: <56585049.1080001@theqtcompany.com> On 11/27/2015 11:46 AM, Eskil A. Blomfeldt wrote: > We've had a few informal discussions locally about the current process > of manually adding bugs to a meta-task in order for them to be > considered blockers for a particular release. > > Wouldn't it be more practical if this was baked into the information you > register on the bug itself, so that it can easily be added to filters > and so that you don't have to search for the task to let the release > team know about it? > > Our suggestion is: Instead of the meta-task, we use the "Fix version" > field. The combination of "Status: Closed" and "Fix version" is > currently used to indicate the first version containing a particular > fix. "Status: Open" and "Fix version", however, has a very loose > definition at best. Since we're doing time-based releases, it gives a > promise it might not be able to keep, so the preference has been to > leave the field unset until the report is closed. > > So we could define it like this: If a bug report is open and has "Fix > version: Qt X.Y", then it will be considered a blocker for Qt X.Y. The > release team will maintain this the same way they maintain the > meta-task, and will override it if they disagree that it should be a > blocker. Sounds sensible, but what about all the existing bugs that have a "Fix version" assigned? Won't they all become blockers now? Or can a script wipe this field before the new semantics are announced? Christian From christianbauer at siemens.com Fri Nov 27 13:45:28 2015 From: christianbauer at siemens.com (Bauer, Christian) Date: Fri, 27 Nov 2015 12:45:28 +0000 Subject: [Development] QFutureInterface In-Reply-To: <201511261332.54740.marc.mutz@kdab.com> References: <54B0CAFD8875674EAD2C2C03BA3652F001849F66@DENBGAT9EI5MSX.ww902.siemens.net> <201511261332.54740.marc.mutz@kdab.com> Message-ID: <54B0CAFD8875674EAD2C2C03BA3652F00184A591@DENBGAT9EI5MSX.ww902.siemens.net> Hi Marc, > You should be able to develop a QPromise/QPackagedTask with the current QFutureInterface already. > At least as long as it's attached to some > QThreadPool. > What, exactly, are you trying to do that requires a patch to QFI? I am not aware of any QPackagedTask in Qt, only of packaged_task in C++11. Or do you mean RunFunctionTaskBase? The QFuture(Interface) represents the return value of a function, e.g., the one passed in QtConcurrent::run. The QFuture(Interface) will execute the function on a thread pool. As soon as this function returns, the return value is stored and the state of the promise set to Finished. Our (simplified) problem is: this function does not return a value but feeds an asynchronous pipeline. When the pipeline processing is done it will call promise.SetResult(); promise.reportResult(); and only then the future should be notified of the result. We can achieve this by using a custom waitForFinished() in our future wrapper, instead of using the QFuture waitForFinished. But this requires access to the QWaitCondition of the QFutureInterface. I hope the use case is clear. The C++11 future/promise achieves exactly this, and we are using the QFuture in a similar way. Thanks Christian From eskil.abrahamsen-blomfeldt at theqtcompany.com Fri Nov 27 14:23:01 2015 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil A. Blomfeldt) Date: Fri, 27 Nov 2015 14:23:01 +0100 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: <56585049.1080001@theqtcompany.com> References: <565834A0.9090600@theqtcompany.com> <56585049.1080001@theqtcompany.com> Message-ID: <56585935.6080205@theqtcompany.com> On 27. nov. 2015 13:44, Christian Kandeler wrote: > On 11/27/2015 11:46 AM, Eskil A. Blomfeldt wrote: >> >> So we could define it like this: If a bug report is open and has "Fix >> version: Qt X.Y", then it will be considered a blocker for Qt X.Y. The >> release team will maintain this the same way they maintain the >> meta-task, and will override it if they disagree that it should be a >> blocker. > > Sounds sensible, but what about all the existing bugs that have a "Fix > version" assigned? Won't they all become blockers now? Or can a script > wipe this field before the new semantics are announced? I think a batched change for all open reports with a "Fix version" != "Some future release" would have to be part of this. A quick check reveals that we (for instance) currently have 27 unresolved bugs with fix version set to "5.3.0", so this might be a good clean-up to have in any case. -- Eskil From alexander.blasche at theqtcompany.com Fri Nov 27 14:42:46 2015 From: alexander.blasche at theqtcompany.com (Blasche Alexander) Date: Fri, 27 Nov 2015 13:42:46 +0000 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: <56585049.1080001@theqtcompany.com> References: <565834A0.9090600@theqtcompany.com> <56585049.1080001@theqtcompany.com> Message-ID: > -----Original Message----- > From: Development [mailto:development-bounces at qt-project.org] On Behalf > Of Christian Kandeler ... > Sounds sensible, but what about all the existing bugs that have a "Fix > version" assigned? Won't they all become blockers now? Or can a script > wipe this field before the new semantics are announced? I would suggest that when release management sets Qt 5.x.y to released in Jira, every unresolved bug with a fix for tag of 5.x.y is shifted out. After all, after a release there should be no further unresolved issues for that particular release. >So we could define it like this: If a bug report is open and has "Fix >version: Qt X.Y", then it will be considered a blocker for Qt X.Y. There is a small point missing here. Priorities still play a role here. P1 is blocker, every other priority is not a blocker but still targets 5.x.y. Of course depending on how close the release is the P4 fix may ot get accepted anymore and its fix for tag may have to be shifted eventually. From paul.tvete at theqtcompany.com Fri Nov 27 14:53:47 2015 From: paul.tvete at theqtcompany.com (Paul Olav Tvete) Date: Fri, 27 Nov 2015 14:53:47 +0100 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: <56585935.6080205@theqtcompany.com> References: <565834A0.9090600@theqtcompany.com> <56585049.1080001@theqtcompany.com> <56585935.6080205@theqtcompany.com> Message-ID: <2063225.U4KgW0xLif@dragaera> On Friday, November 27, 2015 02:23:01 PM Eskil A. Blomfeldt wrote: > I think a batched change for all open reports with a "Fix version" != > "Some future release" would have to be part of this. A quick check > reveals that we (for instance) currently have 27 unresolved bugs with > fix version set to "5.3.0", so this might be a good clean-up to have in > any case. I thought we discussed that this should only apply to P1 (and af course P0) bugs? If a bug is a blocker, it is by definition a P1. There is some sense in allowing non-blocking bugs to have a Fix Version, to aid in planning. As far as I can see, we have 157 bugs that have a Fix Version of 5.3.0 or later. Of those, one is P0, and 25 are P1. About half of those are for 5.3/5.4. - Paul From rjvbertin at gmail.com Fri Nov 27 23:39:07 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Fri, 27 Nov 2015 23:39:07 +0100 Subject: [Development] setting default widgetStyle (and ColorScheme) Message-ID: <1835651.Y05THmYp62@portia.local> Digging through Qt's source code to figure out if and how I can get KF5 applications to honour theming settings on OS X, I observe the following in class QKdeThemePrivate in qgenericunixthemes.cpp: static QString kdeGlobals(const QString &kdeDir) { return kdeDir + QStringLiteral("/share/config/kdeglobals"); } and QVariant QKdeThemePrivate::readKdeSetting() then does foreach (const QString &kdeDir, kdeDirs) { QSettings *settings = kdeSettings.value(kdeDir); if (!settings) { const QString kdeGlobalsPath = kdeGlobals(kdeDir); if (QFileInfo(kdeGlobalsPath).isReadable()) { // ... etc ... It may be intentional that that file avoids the use of QStandardPaths (is it?), but it seems that this code cannot read the kdeglobals file in its intended location (~/.config/kdeglobals on XDG-compliant systems). Not even when $KDExxx variables are set to provide the correct value for `kdeDirs` . Am I right that kdeGlobals() should return the current value only if kdeVersion<=4, and for kdeVersion>=5 it should rather return `kdeDir + QStringLiteral("/kdeglobals")`, with `kdeDirs` extended to include ~/.config? In that case, should a fallback for "/share/config/kdeglobals" be added? A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct? R. From olivier at woboq.com Sat Nov 28 01:07:17 2015 From: olivier at woboq.com (Olivier Goffart) Date: Sat, 28 Nov 2015 01:07:17 +0100 Subject: [Development] setting default widgetStyle (and ColorScheme) In-Reply-To: <1835651.Y05THmYp62@portia.local> References: <1835651.Y05THmYp62@portia.local> Message-ID: <3064024.pZ2hNzyTRF@finn> On Friday 27. November 2015 23:39:07 René J.V. Bertin wrote: > Digging through Qt's source code to figure out if and how I can get KF5 > applications to honour theming settings on OS X, I observe the following in > class QKdeThemePrivate in qgenericunixthemes.cpp: > > static QString kdeGlobals(const QString &kdeDir) > { > return kdeDir + QStringLiteral("/share/config/kdeglobals"); > } > > and QVariant QKdeThemePrivate::readKdeSetting() then does > > foreach (const QString &kdeDir, kdeDirs) { > QSettings *settings = kdeSettings.value(kdeDir); > if (!settings) { > const QString kdeGlobalsPath = kdeGlobals(kdeDir); > if (QFileInfo(kdeGlobalsPath).isReadable()) { > // ... etc ... > > It may be intentional that that file avoids the use of QStandardPaths (is > it?), but it seems that this code cannot read the kdeglobals file in its > intended location (~/.config/kdeglobals on XDG-compliant systems). Not even > when $KDExxx variables are set to provide the correct value for `kdeDirs` . > > Am I right that kdeGlobals() should return the current value only if > kdeVersion<=4, and for kdeVersion>=5 it should rather return `kdeDir + > QStringLiteral("/kdeglobals")`, with `kdeDirs` extended to include > ~/.config? In that case, should a fallback for "/share/config/kdeglobals" > be added? > > A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct? That code was written for integrating into KDE 4. It was not adapted to work with Plasma 5. A pure KF5 appliation would anyway use the KDE platform theme plugin provided by KDE Frameworks. (in frameworkintegration) (So in other words: that code should not be executed when kde frameworks is installed, in theory) -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org From rjvbertin at gmail.com Sat Nov 28 01:33:43 2015 From: rjvbertin at gmail.com (=?ISO-8859-1?Q?Ren=E9_J=2EV=2E?= Bertin) Date: Sat, 28 Nov 2015 01:33:43 +0100 Subject: [Development] setting default widgetStyle (and ColorScheme) In-Reply-To: <3064024.pZ2hNzyTRF@finn> References: <1835651.Y05THmYp62@portia.local> <3064024.pZ2hNzyTRF@finn> Message-ID: <25909650.XYoVZRbSnS@portia.local> On Saturday November 28 2015 01:07:17 Olivier Goffart wrote: > > A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct? > > That code was written for integrating into KDE 4. That much was clear :) > A pure KF5 appliation would anyway use the KDE platform theme plugin provided > by KDE Frameworks. (in frameworkintegration) > (So in other words: that code should not be executed when kde frameworks is > installed, in theory) I think I have everything to install the frameworkintegration fw currently, I'll do that and report back, thanks. R. From rjvbertin at gmail.com Sat Nov 28 03:07:14 2015 From: rjvbertin at gmail.com (=?utf-8?Q?Ren=C3=A9_JV_Bertin?=) Date: Sat, 28 Nov 2015 03:07:14 +0100 Subject: [Development] setting default widgetStyle (and ColorScheme) In-Reply-To: <3064024.pZ2hNzyTRF@finn> References: <1835651.Y05THmYp62@portia.local> <3064024.pZ2hNzyTRF@finn> Message-ID: <6CCC5D69-B0B2-4B08-8E96-FDA0E85EC61C@gmail.com> On 28 Nov 2015, at 01:07, Olivier Goffart wrote: >> >> A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct? > > That code was written for integrating into KDE 4. > It was not adapted to work with Plasma 5. > > A pure KF5 appliation would anyway use the KDE platform theme plugin provided > by KDE Frameworks. (in frameworkintegration) > (So in other words: that code should not be executed when kde frameworks is > installed, in theory) In fact, my observations probably imply that the code *is* called when running "pure Qt5" apps under X11 (it is with the xcb plugin on OS X; I checked). If indeed so, I think it should be updated to comply with KF5 principles if KDE_SESSION_VERSION = 5 (and use the KDE4 config as a fallback). No? R From aleixpol at kde.org Sat Nov 28 03:51:18 2015 From: aleixpol at kde.org (Aleix Pol) Date: Sat, 28 Nov 2015 03:51:18 +0100 Subject: [Development] setting default widgetStyle (and ColorScheme) In-Reply-To: <6CCC5D69-B0B2-4B08-8E96-FDA0E85EC61C@gmail.com> References: <1835651.Y05THmYp62@portia.local> <3064024.pZ2hNzyTRF@finn> <6CCC5D69-B0B2-4B08-8E96-FDA0E85EC61C@gmail.com> Message-ID: On Sat, Nov 28, 2015 at 3:07 AM, René JV Bertin wrote: > > > On 28 Nov 2015, at 01:07, Olivier Goffart wrote: > >>> >>> A pure KF5 system will not have ~/.kde*/share/config/kdeglobals, correct? >> >> That code was written for integrating into KDE 4. >> It was not adapted to work with Plasma 5. >> >> A pure KF5 appliation would anyway use the KDE platform theme plugin provided >> by KDE Frameworks. (in frameworkintegration) >> (So in other words: that code should not be executed when kde frameworks is >> installed, in theory) > > In fact, my observations probably imply that the code *is* called when running "pure Qt5" apps under X11 (it is with the xcb plugin on OS X; I checked). If indeed so, I think it should be updated to comply with KF5 principles if KDE_SESSION_VERSION = 5 (and use the KDE4 config as a fallback). No? No, it's not run when the frameworksintegration QPlatformTheme plugin is loaded. If it was, it would be a bug. Aleix PS: René, cross-posting is bad. Let's bring the issues up in the correct channels. If it was a bug in Qt, a bug report would have been more appropriate. From stefbon at gmail.com Mon Nov 30 11:07:21 2015 From: stefbon at gmail.com (Stef Bon) Date: Mon, 30 Nov 2015 11:07:21 +0100 Subject: [Development] About qfilesystemwatcher: what events? Message-ID: Hi, I'm looking at qfilesystemwatcher. It's not possible to configure what events it watches. For example: when watching a directory and an event happens on an entry in this directory: it's changed. The size for example is changed. qfilesystemwatcher doe not give this information: it only signals that the "something" has been changed in the directory. This means that you have to scan through the directory and compare each file one by one. FS Watches to watch a whole directory are used a lot, but it should give more information about the event (name of entry, and a mask, simular to inotify). Is this planned? Stef From markg85 at gmail.com Mon Nov 30 11:52:23 2015 From: markg85 at gmail.com (Mark Gaiser) Date: Mon, 30 Nov 2015 11:52:23 +0100 Subject: [Development] About qfilesystemwatcher: what events? In-Reply-To: References: Message-ID: On Mon, Nov 30, 2015 at 11:07 AM, Stef Bon wrote: > Hi, > > I'm looking at qfilesystemwatcher. > It's not possible to configure what events it watches. For example: > > when watching a directory and an event happens on an entry in this > directory: it's changed. > The size for example is changed. qfilesystemwatcher doe not give this > information: it only signals that the "something" has been changed in > the directory. > > This means that you have to scan through the directory and compare > each file one by one. > FS Watches to watch a whole directory are used a lot, but it should > give more information about the event (name of entry, and a mask, > simular to inotify). > > Is this planned? > > Stef > > Hi Stef, What you describe is planned by me for the inotify backend (linux), but that's on my schedule for at least a year now so don't bet on that ending up in Qt anytime soon. Even if i make it, the other backends (Mac, Windows and the other supported Qt platforms) have to be adjusted accordingly as well and i don't even know if those backeds support the "flexibility" of inotify. If you (or anyone else) can offer help, it would be much appreciated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eskil.abrahamsen-blomfeldt at theqtcompany.com Mon Nov 30 13:13:32 2015 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil A. Blomfeldt) Date: Mon, 30 Nov 2015 13:13:32 +0100 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: <2063225.U4KgW0xLif@dragaera> References: <565834A0.9090600@theqtcompany.com> <56585049.1080001@theqtcompany.com> <56585935.6080205@theqtcompany.com> <2063225.U4KgW0xLif@dragaera> Message-ID: <565C3D6C.1040202@theqtcompany.com> On 27. nov. 2015 14:53, Paul Olav Tvete wrote: > On Friday, November 27, 2015 02:23:01 PM Eskil A. Blomfeldt wrote: >> I think a batched change for all open reports with a "Fix version" != >> "Some future release" would have to be part of this. A quick check >> reveals that we (for instance) currently have 27 unresolved bugs with >> fix version set to "5.3.0", so this might be a good clean-up to have in >> any case. > I thought we discussed that this should only apply to P1 (and af course P0) > bugs? If a bug is a blocker, it is by definition a P1. There is some sense in > allowing non-blocking bugs to have a Fix Version, to aid in planning. > > As far as I can see, we have 157 bugs that have a Fix Version of 5.3.0 or > later. Of those, one is P0, and 25 are P1. About half of those are for > 5.3/5.4. Personally, I don't see the need for that. The way it's used now, it's not maintained, so you end up with open bug reports that claim they have been fixed in a released Qt, which is just confusing. It would make the system easier if that field refers to the version where we know the bug has been / will be fixed, and not arbitrarily based on some plans or user requests. In principle, that means there will be no unresolved bugs with P >= 2 that has a fix version set, which makes more sense since we are not promising fix versions for non-blockers. -- Eskil From Lars.Knoll at theqtcompany.com Mon Nov 30 13:21:04 2015 From: Lars.Knoll at theqtcompany.com (Knoll Lars) Date: Mon, 30 Nov 2015 12:21:04 +0000 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: <565C3D6C.1040202@theqtcompany.com> References: <565834A0.9090600@theqtcompany.com> <56585049.1080001@theqtcompany.com> <56585935.6080205@theqtcompany.com> <2063225.U4KgW0xLif@dragaera> <565C3D6C.1040202@theqtcompany.com> Message-ID: <2D0025D7-79FF-45A8-8144-EC2855F0EBAA@theqtcompany.com> On 30/11/15 13:13, "Development on behalf of Eskil A. Blomfeldt" wrote: > > >On 27. nov. 2015 14:53, Paul Olav Tvete wrote: >> On Friday, November 27, 2015 02:23:01 PM Eskil A. Blomfeldt wrote: >>> I think a batched change for all open reports with a "Fix version" != >>> "Some future release" would have to be part of this. A quick check >>> reveals that we (for instance) currently have 27 unresolved bugs with >>> fix version set to "5.3.0", so this might be a good clean-up to have in >>> any case. >> I thought we discussed that this should only apply to P1 (and af course P0) >> bugs? If a bug is a blocker, it is by definition a P1. There is some sense in >> allowing non-blocking bugs to have a Fix Version, to aid in planning. >> >> As far as I can see, we have 157 bugs that have a Fix Version of 5.3.0 or >> later. Of those, one is P0, and 25 are P1. About half of those are for >> 5.3/5.4. > >Personally, I don't see the need for that. The way it's used now, it's >not maintained, so you end up with open bug reports that claim they have >been fixed in a released Qt, which is just confusing. It would make the >system easier if that field refers to the version where we know the bug >has been / will be fixed, and not arbitrarily based on some plans or >user requests. > >In principle, that means there will be no unresolved bugs with P >= 2 >that has a fix version set, which makes more sense since we are not >promising fix versions for non-blockers. I think this makes most sense. The old way where we had a Fix Version set for open bugs is at the minimum confusing to users. Usually it’s worse, because it creates false expectations. Setting a Fix Version on an open bug is somewhat of a commitment by us that we will do what we can to get that bug fixed for this version. And that’s more the exception than the rule, ie. It makes the bug a showstopper for that release. Cheers, Lars From eskil.abrahamsen-blomfeldt at theqtcompany.com Mon Nov 30 13:24:38 2015 From: eskil.abrahamsen-blomfeldt at theqtcompany.com (Eskil A. Blomfeldt) Date: Mon, 30 Nov 2015 13:24:38 +0100 Subject: [Development] Suggestion for change on how blockers are marked in Jira In-Reply-To: References: <565834A0.9090600@theqtcompany.com> <56585049.1080001@theqtcompany.com> Message-ID: <565C4006.8080804@theqtcompany.com> On 27. nov. 2015 14:42, Blasche Alexander wrote: >> -----Original Message----- >> From: Development [mailto:development-bounces at qt-project.org] On Behalf >> Of Christian Kandeler > ... >> Sounds sensible, but what about all the existing bugs that have a "Fix >> version" assigned? Won't they all become blockers now? Or can a script >> wipe this field before the new semantics are announced? > I would suggest that when release management sets Qt 5.x.y to released in Jira, every unresolved bug with a fix for tag of 5.x.y is shifted out. After all, after a release there should be no further unresolved issues for that particular release. My take is that Qt 5.x.y cannot be released as long as there are unresolved bugs with "fix for" set to 5.x.y. > >> So we could define it like this: If a bug report is open and has "Fix >> version: Qt X.Y", then it will be considered a blocker for Qt X.Y. > There is a small point missing here. Priorities still play a role here. P1 is blocker, every other priority is not a blocker but still targets 5.x.y. Of course depending on how close the release is the P4 fix may ot get accepted anymore and its fix for tag may have to be shifted eventually. As mentioned in the answer to Paul, is someone sets "fix for" on a non-blocker bug, I think it should either be cleared by the release team or changed to P1. If you look at the current meta-task, there are several P2s there, so it's not a given that the priority is set correctly. Asking people to set two fields instead of one to get on the blocker-list might just be adding more complexity without adding any real value. My opinion is that having yet another meaning for the "fix for" field when it's set on unresolved, lower-priority bugs (which is "I think I might want to at some point fix this, maybe 5.x.y or something, I dunno") doesn't have any actual value and makes the system more confusing, so my suggestion is that we stop doing that (which I also though was the consensus when we discussed moving to time-based releases, but I don't remember how formalized the discussion was). -- Eskil From stefbon at gmail.com Mon Nov 30 17:51:35 2015 From: stefbon at gmail.com (Stef Bon) Date: Mon, 30 Nov 2015 17:51:35 +0100 Subject: [Development] About qfilesystemwatcher: what events? In-Reply-To: References: Message-ID: Hi, I will look into it. Do I have to checkout the qt source as described here: http://wiki.qt.io/Building_Qt_5_from_Git Futher is there a projectpage? (to see the current issues) And is the ability to forward a watch to a network filesystem included? Please let me explain. I've been digging for some time now why fs notify methods do not work with filesystems like cifs, nfs and fuse. This is because the backend (or server) is possibly shared with others, which cannot be monitored by the VFS self. I've been looking at the ability to patch the Linux kernel (patching fsnotify, and let the filesystem "know: a watch has been set, and act on that), and notify the kernel when something changes. I had this working for FUSE, but I think it's too complicated and won't make it in the mainstream. I had another option, and that is to that in userspace. Simply put: when a watch is set on a filesystem, qfilesystemwatcher contacts the filesystem via a socket, and sends a message to inform the fs that a watch is set. Required is some service/daemon that is doing all the fsnotify for applications (like fam in the past did). Stef Bon Voorburg the Netherlands From thiago.macieira at intel.com Mon Nov 30 18:02:55 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 Nov 2015 09:02:55 -0800 Subject: [Development] https://bugreports.qt.io/browse/QTBUG-48717 - need help Message-ID: <26397150.qWdG1MjIGc@tjmaciei-mobl4> I need someone with an ARM board to reproduce the issue and pinpoint where the event delivery problem might be. My gut feeling was that it was caused by the different platform plugins, my the reporter says that the problem happens with XCB too. There should be no platform-specific code in the event processing code, so this sounds like either miscompilation (compiler bug), undefined behaviour (Qt's bug) or something as simple as the fact that chars are unsigned on ARM (also Qt's bug). -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Nov 30 18:29:06 2015 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 30 Nov 2015 09:29:06 -0800 Subject: [Development] buildsystem now needs to keep behaviour compatibility Message-ID: <2394178.nH4WTEmeSG@tjmaciei-mobl4> [This is mostly to Ossi, Jörg and myself, but sending to everyone FYI] Now that we will no longer include qtwebkit, qtquick1 and qtscript in the main releases, we are asking people to continue building the last released version of some of those modules against newer Qt versions. That was in the 5.5.0 changelog: - The QtWebKit and QtQuick1 modules and support for the QML 1 language are deprecated and Qt 5.5 will be the last release to include them. Starting with Qt 5.6, the source code for those modules will not be included in Qt's packaging. Compiling the 5.5 release of QtWebKit modules along with Qt 5.6 or future versions should work. QtQuick1 is not guaranteed to work in future versions after Qt 5.6. - The QtScript module is deprecated and will be removed from Qt's packaging starting with version 5.7. The 5.5 and 5.6 releases of QtScript should continue to work along with Qt 5.7 and future versions. Therefore, whenever you're making changes to the buildsystem, please test the last releases of qtwebkit and qtscript to verify that they don't break the build. If they do, your change is not allowed and you should redesign (probably by making your change an opt-in for the other modules). I'm guilty and will need to rework one change I made. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From pgquiles at elpauer.org Mon Nov 30 22:44:35 2015 From: pgquiles at elpauer.org (Pau Garcia i Quiles) Date: Mon, 30 Nov 2015 22:44:35 +0100 Subject: [Development] FOSDEM Desktops DevRoom 2016: Call for Participation In-Reply-To: References: Message-ID: Hello, Just a quick mail to remind everybody we will accept talk proposals for the Desktops DevRoom at FOSDEM 2016 only until this Saturday. Hurry up! On Mon, Nov 2, 2015 at 8:44 PM, Pau Garcia i Quiles wrote: > > FOSDEM Desktops DevRoom 2016 Call for Participation > > FOSDEM is one of the largest gatherings of Free Software contributors in > the world and happens each February in Brussels (Belgium, Europe). One of > the tracks will be the Desktops DevRoom (formerly known as “CrossDesktop > DevRoom”), which will host Desktop-related talks. > > We are now inviting proposals for talks about Free/Libre/Open-source > Software on the topics of Desktop development, Desktop applications and > interoperability amongst Desktop Environments. This is a unique opportunity > to show novel ideas and developments to a wide technical audience. > > Topics accepted include, but are not limited to: > > - Open Desktops: Gnome, KDE, Unity, Enlightenment, XFCE, Razor, MATE, > Cinnamon, ReactOS, etc > > - Closed desktops: Windows, Mac OS X, CDE, MorphOS, etc (when talking > about a FLOSS topic) > > - Software development for the desktop > > - Development tools > > - Applications that enhance desktops > > - General desktop matters > > - Cross-platform software development > > - Web > > > Talks can be very specific, such as the advantages/disadvantages of > development with Qt on Wayland over X11/Mir; or as general as predictions > for the fusion of Desktop and web in 5 years time. Topics that are of > interest to the users and developers of all desktop environments are > especially welcome. The FOSDEM 2015 schedule[1] might give you some > inspiration. > > > Submissions > > Please include the following information when submitting a proposal: > > - Your name > > - The title of your talk (please be descriptive, as titles will be > listed with around 400 from other projects) > > - Short abstract of one or two paragraphs > > - Short bio (with photo) > > - Requested time: from 15 to 45 minutes. Normal duration is 30 > minutes. Longer duration requests must be properly justified. You may be > assigned LESS time than you request. > > > How to submit > > All submissions are made in the Pentabarf event planning tool: > > https://penta.fosdem.org/submission/FOSDEM16 > > When submitting your talk, make sure to select the "Desktops" devroom as > the "Track". Otherwise your talk will not be even considered for any > devroom. > > If you already have a Pentabarf account from a previous year, even if your > talk was not accepted, please reuse it. Create an account if, and only if, > you don’t have one from a previous year. If you have any issues with > Pentabarf, please contact pgquiles at elpauer dot org. > > > Deadline > > The deadline for submissions is December 6th 2015. > > FOSDEM will be held on the weekend of January 30th and 31st 2015 and the > Desktops DevRoom will take place on Sunday, January 31st 2015. > > We will contact every submitter with a "yes" or "no" before December 18th > 2015. > > > Recording permission > > The talks in the Desktops devroom will be audio and video recorded, and > possibly streamed live too. > > By submitting a proposal you consent to be recorded and agree to license > the content of your talk under a Creative Commons (CC-BY) license. > > If you want us to stop the recording in the Q & A part (should you have > one), please tell us. We can do that but only for the Q & A part. > > > More information > > The official communication channel for the Desktops DevRoom is its mailing > list desktops-devroom at lists.fosdem.org. > > Use this page to manage your subscription: > > https://lists.fosdem.org/listinfo/desktops-devroom > > > Organization > > The Desktops DevRoom 2016 is managed by a team representing the most > notable open desktops: > > > - Pau Garcia i Quiles, KDE > > - Christophe Fergeau, Gnome > > - Michael Zanetti, Unity > > - Philippe Caseiro, Enlightenment > > - Jérome Leclanche, Razor > > > If you want to join the team, please contact pgquiles at elpauer dot org > > -- > Pau Garcia i Quiles > http://www.elpauer.org > (Due to my workload, I may need 10 days to answer) > -- Pau Garcia i Quiles http://www.elpauer.org (Due to my workload, I may need 10 days to answer) -------------- next part -------------- An HTML attachment was scrubbed... URL: