From steveire at gmail.com Sun Apr 1 20:18:24 2018 From: steveire at gmail.com (Stephen Kelly) Date: Sun, 01 Apr 2018 19:18:24 +0100 Subject: [Development] Proposing David Faure as maintainer of Qt Models References: <8b471cbefc01fe740d34bcd82bd021e3@kdab.com> Message-ID: Sérgio Martins wrote: > Hi, > > > Although the wiki says Qt Models don't have a maintainer I'd say David > Faure has been an unofficial maintainer. > David is one of the top contributors to model related code and is > someone you'll always want to add as reviewer. > > He's well known in the community and already maintains QtXmlPatterns, Qt > mimetypes and Qt3Support. > > Disclaimer: David works with me at KDAB. > (And if you're wondering if KDAB has any plans for this module, the > answer is no. In fact I hope it remains low change volume). > > > Finally, a big thanks to the previous maintainer, Stephen Kelly, who did > a great job, both on Qt and KDE models! +1 for David from me too! Greetings, Steve. From szehowe.koh at gmail.com Tue Apr 3 02:14:29 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Tue, 3 Apr 2018 08:14:29 +0800 Subject: [Development] To improve UX of the online installer Message-ID: 3 broad issues impede new users who want to start using Qt and frustrate old users who want to update Qt: (A) Downloading metadata is very time-consuming. (B) The automatic mirror selection algorithm doesn't always pick the best mirror. (C) (New users) It's not clear how to choose what to install. ====================================== Factors that contribute to (A) include: * The metadata downloader opens lots of short-duration TCP connections. Wireshark revealed 2391 HTTP GET requests from 77.86.229.90 (download.qt.io) on Windows. This process is less painful on Linux (1205 GETs -- almost half of Windows') as there are fewer compilers/platforms. * Downloading many small files is very inefficient compared to downloading a few large files. While GET-ting metadata from download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten kibibytes). After this, the actual binaries download from my designated mirror at ~1 MiB/s, which shows that metadata downloader doesn't make good use of available bandwidth. I'm in Australia. * MaintenanceTool downloads metadata too frequently (QTIFW-975). * If the metadata download fails halfway (e.g. one file times out), the whole process needs to start from scratch. There is no retry/resume. This makes the online installer nigh unusable if the user's connection to download.qt.io is flaky: https://forum.qt.io/post/450076 * Currently, there is a way to manually avoid downloading unwanted metadata: Deselecting the unwanted Temporary Repositories. However, all 91 Repositories must be unchecked one-by-one, and this process must be repeated each time MaintenanceTool is restarted: https://forum.qt.io/post/450076 ====================================== Evidence for (B) include: * Geographical proximity does not imply mirror quality. E.g. a user from China finds Chinese mirrors too slow, and opts for non-Chinese mirrors instead: http://lists.qt-project.org/pipermail/interest/2013-December/010336.html * The algorithm doesn't pick the closest mirror anyway. E.g. a user from Israel was given a Japanese mirror instead of a European mirror: https://forum.qt.io/topic/87221/ ====================================== Examples of (C) include: * Some users don't realize there are multiple kits per Qt version. They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): https://forum.qt.io/topic/87608/windows-install-download-size * Some users don't realize Qt Creator != Qt. They install Qt Creator without Qt and end up unable to build anything: https://forum.qt.io/topic/84198/no-valid-kits-found * Some users don't realize they need to install a compiler separately. They also end up unable to build anything: https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements ====================================== Ideas for improvement (some render others unnecessary): 1. Amalgamate and compress all metadata into one file (or at least one file per "group"). 2. Cache metadata locally and use a hash to identify them; avoid re-downloading metadata that's already available (Mitch Curtis suggested this at QTIFW-975) 3. Avoid downloading metadata for archived/advanced packages by default (Iikka Eklund said this is planned in QTIFW-975) 4a. Remember the which Repositories the user has deselected before, and ignore them for future sessions. 4b. Let the user choose broad "groups" that they are interested in, and remember this choice. For example, there is no point getting metadata for Android/UWP packages or showing these packages in the "Selection Tree" if I'm only interested in Desktop development. 5. Add a "Select/Deselect All" button to the Repositories page. 6. Allow retry/resume if the metadata download fails halfway. 7. Allow users to manually pick a mirror for binary download. 8a. Before the user is asked to "Select the components to install", show a short page that to explain the difference between Qt and Qt Creator and explain that a compiler must be installed separately unless MinGW is used. 8b. Before the user is asked to "Select the components to install", have a small wizard to ask a new user some questions -- Which version(s): Latest version, LTS version, or older version? Which target platforms? Which compiler? Or do they not care/know and want us to suggest a good default? Use the answers to pre-fill the "Selection Tree" and remind the user to download an external compiler if necessary. 9. If no Qt version is selected (or if too many are selected), pop-up a confirmation dialog before installing. 10. Expand the documentation at http://doc.qt.io/qt-5/gettingstarted.html Since (3) is already being planned, please consider (4) which is a generalization of (3). It would be fantastic to see a holistic approach that addresses (A) + (B) + (C). For example, (8b) helps the user make the right selection at the first try. At the same time, users' answers in (8b) feed into (4b) to download fewer metadata files and trim the "Selection Tree". This is further sped up by (1) + (2): Each "group" has its own amalgamated metadata file, and these files are cached locally to avoid re-downloading in the future. Once the selection is complete, (7) ensures that the use can get binaries in a timely manner even if the auto-selected mirror is no good. Regards, Sze-Howe From fromqt at tungware.se Tue Apr 3 02:29:37 2018 From: fromqt at tungware.se (Henry Skoglund) Date: Tue, 3 Apr 2018 02:29:37 +0200 Subject: [Development] To improve UX of the online installer In-Reply-To: References: Message-ID: <87e57495-666b-742c-171f-97d7cd8d13d3@tungware.se> Hi, excellent initiative, a better MaintenanceTool UX would also improve the general opinion of Qt I think. Just one to add 2 things to Sze Howe's list: 8c. For the users that, in search of a 32-bit MSVC2017-flavored Qt version, downloads the UWP x86 (MSVC 2017) version of Qt, and then tries to run it on Windows 7: please explain that the UWP stuff only runs on Windows 10. 11. Please make 'Update components' the default selection once you've logged in, or 'Add or remove components'. Anything but 'Remove all components' !!! Rgrds Henry On 2018-04-03 02:14, Sze Howe Koh wrote: > 3 broad issues impede new users who want to start using Qt and > frustrate old users who want to update Qt: > > (A) Downloading metadata is very time-consuming. > (B) The automatic mirror selection algorithm doesn't always pick > the best mirror. > (C) (New users) It's not clear how to choose what to install. > > > ====================================== > Factors that contribute to (A) include: > > * The metadata downloader opens lots of short-duration TCP > connections. Wireshark revealed 2391 HTTP GET requests from > 77.86.229.90 (download.qt.io) on Windows. This process is less painful > on Linux (1205 GETs -- almost half of Windows') as there are fewer > compilers/platforms. > > > * Downloading many small files is very inefficient compared to > downloading a few large files. While GET-ting metadata from > download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten > kibibytes). After this, the actual binaries download from my > designated mirror at ~1 MiB/s, which shows that metadata downloader > doesn't make good use of available bandwidth. I'm in Australia. > > > * MaintenanceTool downloads metadata too frequently (QTIFW-975). > > > * If the metadata download fails halfway (e.g. one file times out), > the whole process needs to start from scratch. There is no > retry/resume. This makes the online installer nigh unusable if the > user's connection to download.qt.io is flaky: > https://forum.qt.io/post/450076 > > > * Currently, there is a way to manually avoid downloading unwanted > metadata: Deselecting the unwanted Temporary Repositories. However, > all 91 Repositories must be unchecked one-by-one, and this process > must be repeated each time MaintenanceTool is restarted: > https://forum.qt.io/post/450076 > > > ====================================== > Evidence for (B) include: > > * Geographical proximity does not imply mirror quality. E.g. a user > from China finds Chinese mirrors too slow, and opts for non-Chinese > mirrors instead: > http://lists.qt-project.org/pipermail/interest/2013-December/010336.html > > > * The algorithm doesn't pick the closest mirror anyway. E.g. a user > from Israel was given a Japanese mirror instead of a European mirror: > https://forum.qt.io/topic/87221/ > > > ====================================== > Examples of (C) include: > > * Some users don't realize there are multiple kits per Qt version. > They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): > https://forum.qt.io/topic/87608/windows-install-download-size > > > * Some users don't realize Qt Creator != Qt. They install Qt Creator > without Qt and end up unable to build anything: > https://forum.qt.io/topic/84198/no-valid-kits-found > > > * Some users don't realize they need to install a compiler separately. > They also end up unable to build anything: > https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements > > > ====================================== > Ideas for improvement (some render others unnecessary): > > 1. Amalgamate and compress all metadata into one file (or at least one > file per "group"). > > 2. Cache metadata locally and use a hash to identify them; avoid > re-downloading metadata that's already available (Mitch Curtis > suggested this at QTIFW-975) > > 3. Avoid downloading metadata for archived/advanced packages by > default (Iikka Eklund said this is planned in QTIFW-975) > > 4a. Remember the which Repositories the user has deselected before, > and ignore them for future sessions. > > 4b. Let the user choose broad "groups" that they are interested in, > and remember this choice. For example, there is no point getting > metadata for Android/UWP packages or showing these packages in the > "Selection Tree" if I'm only interested in Desktop development. > > 5. Add a "Select/Deselect All" button to the Repositories page. > > 6. Allow retry/resume if the metadata download fails halfway. > > 7. Allow users to manually pick a mirror for binary download. > > 8a. Before the user is asked to "Select the components to install", > show a short page that to explain the difference between Qt and Qt > Creator and explain that a compiler must be installed separately > unless MinGW is used. > > 8b. Before the user is asked to "Select the components to install", > have a small wizard to ask a new user some questions -- Which > version(s): Latest version, LTS version, or older version? Which > target platforms? Which compiler? Or do they not care/know and want us > to suggest a good default? Use the answers to pre-fill the "Selection > Tree" and remind the user to download an external compiler if > necessary. > > 9. If no Qt version is selected (or if too many are selected), pop-up > a confirmation dialog before installing. > > 10. Expand the documentation at http://doc.qt.io/qt-5/gettingstarted.html > > > Since (3) is already being planned, please consider (4) which is a > generalization of (3). > > It would be fantastic to see a holistic approach that addresses (A) + > (B) + (C). For example, (8b) helps the user make the right selection > at the first try. At the same time, users' answers in (8b) feed into > (4b) to download fewer metadata files and trim the "Selection Tree". > This is further sped up by (1) + (2): Each "group" has its own > amalgamated metadata file, and these files are cached locally to avoid > re-downloading in the future. Once the selection is complete, (7) > ensures that the use can get binaries in a timely manner even if the > auto-selected mirror is no good. > > > Regards, > Sze-Howe > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From jhihn at gmx.com Tue Apr 3 02:43:12 2018 From: jhihn at gmx.com (Jason H) Date: Tue, 3 Apr 2018 02:43:12 +0200 Subject: [Development] To improve UX of the online installer In-Reply-To: References: Message-ID: I'm not involved with the installer, but 2 points. 1. Number of gets doesn't really matter as long as it's HTTP 1.1. yeah it's not as optimal as a single compressed download, but it's not terrible. If it's only 1.0, then that's a problem. Or it could be that the concurrent connections are being limited, or the gets are just taking a fixed time to get a response. Maybe memcached would help? 2. "Closest" mirror isn't what is important, it's speed. Though you may be implying that the chosen mirror was still slower? It seemed that you argue both? 3. I think the scope is ok. Qt is not a tool chain, it's a library with tools. And the expectation is that Qt sits above the platform and compiler(s). > Sent: Tuesday, April 03, 2018 at 2:14 AM > From: "Sze Howe Koh" > To: "Qt development mailing list" > Subject: [Development] To improve UX of the online installer > > 3 broad issues impede new users who want to start using Qt and > frustrate old users who want to update Qt: > > (A) Downloading metadata is very time-consuming. > (B) The automatic mirror selection algorithm doesn't always pick > the best mirror. > (C) (New users) It's not clear how to choose what to install. > > > ====================================== > Factors that contribute to (A) include: > > * The metadata downloader opens lots of short-duration TCP > connections. Wireshark revealed 2391 HTTP GET requests from > 77.86.229.90 (download.qt.io) on Windows. This process is less painful > on Linux (1205 GETs -- almost half of Windows') as there are fewer > compilers/platforms. > > > * Downloading many small files is very inefficient compared to > downloading a few large files. While GET-ting metadata from > download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten > kibibytes). After this, the actual binaries download from my > designated mirror at ~1 MiB/s, which shows that metadata downloader > doesn't make good use of available bandwidth. I'm in Australia. > > > * MaintenanceTool downloads metadata too frequently (QTIFW-975). > > > * If the metadata download fails halfway (e.g. one file times out), > the whole process needs to start from scratch. There is no > retry/resume. This makes the online installer nigh unusable if the > user's connection to download.qt.io is flaky: > https://forum.qt.io/post/450076 > > > * Currently, there is a way to manually avoid downloading unwanted > metadata: Deselecting the unwanted Temporary Repositories. However, > all 91 Repositories must be unchecked one-by-one, and this process > must be repeated each time MaintenanceTool is restarted: > https://forum.qt.io/post/450076 > > > ====================================== > Evidence for (B) include: > > * Geographical proximity does not imply mirror quality. E.g. a user > from China finds Chinese mirrors too slow, and opts for non-Chinese > mirrors instead: > http://lists.qt-project.org/pipermail/interest/2013-December/010336.html > > > * The algorithm doesn't pick the closest mirror anyway. E.g. a user > from Israel was given a Japanese mirror instead of a European mirror: > https://forum.qt.io/topic/87221/ > > > ====================================== > Examples of (C) include: > > * Some users don't realize there are multiple kits per Qt version. > They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): > https://forum.qt.io/topic/87608/windows-install-download-size > > > * Some users don't realize Qt Creator != Qt. They install Qt Creator > without Qt and end up unable to build anything: > https://forum.qt.io/topic/84198/no-valid-kits-found > > > * Some users don't realize they need to install a compiler separately. > They also end up unable to build anything: > https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements > > > ====================================== > Ideas for improvement (some render others unnecessary): > > 1. Amalgamate and compress all metadata into one file (or at least one > file per "group"). > > 2. Cache metadata locally and use a hash to identify them; avoid > re-downloading metadata that's already available (Mitch Curtis > suggested this at QTIFW-975) > > 3. Avoid downloading metadata for archived/advanced packages by > default (Iikka Eklund said this is planned in QTIFW-975) > > 4a. Remember the which Repositories the user has deselected before, > and ignore them for future sessions. > > 4b. Let the user choose broad "groups" that they are interested in, > and remember this choice. For example, there is no point getting > metadata for Android/UWP packages or showing these packages in the > "Selection Tree" if I'm only interested in Desktop development. > > 5. Add a "Select/Deselect All" button to the Repositories page. > > 6. Allow retry/resume if the metadata download fails halfway. > > 7. Allow users to manually pick a mirror for binary download. > > 8a. Before the user is asked to "Select the components to install", > show a short page that to explain the difference between Qt and Qt > Creator and explain that a compiler must be installed separately > unless MinGW is used. > > 8b. Before the user is asked to "Select the components to install", > have a small wizard to ask a new user some questions -- Which > version(s): Latest version, LTS version, or older version? Which > target platforms? Which compiler? Or do they not care/know and want us > to suggest a good default? Use the answers to pre-fill the "Selection > Tree" and remind the user to download an external compiler if > necessary. > > 9. If no Qt version is selected (or if too many are selected), pop-up > a confirmation dialog before installing. > > 10. Expand the documentation at http://doc.qt.io/qt-5/gettingstarted.html > > > Since (3) is already being planned, please consider (4) which is a > generalization of (3). > > It would be fantastic to see a holistic approach that addresses (A) + > (B) + (C). For example, (8b) helps the user make the right selection > at the first try. At the same time, users' answers in (8b) feed into > (4b) to download fewer metadata files and trim the "Selection Tree". > This is further sped up by (1) + (2): Each "group" has its own > amalgamated metadata file, and these files are cached locally to avoid > re-downloading in the future. Once the selection is complete, (7) > ensures that the use can get binaries in a timely manner even if the > auto-selected mirror is no good. > > > Regards, > Sze-Howe > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From erikluor at gmail.com Tue Apr 3 05:40:22 2018 From: erikluor at gmail.com (Erik Luo) Date: Mon, 2 Apr 2018 21:40:22 -0600 Subject: [Development] To improve UX of the online installer In-Reply-To: References: Message-ID: I could be wrong, but from my observation, 1. sometimes the GUI components perform relatively abnormal comparing to Linux or OS X. Especially happen in the scaling and drawing parts. 2. When I worked within a team and different team members use different OS, the external libraries sometimes become unstable using MinGW or GCC compiler. On Mon, Apr 2, 2018 at 6:43 PM, Jason H wrote: > I'm not involved with the installer, but 2 points. > 1. Number of gets doesn't really matter as long as it's HTTP 1.1. yeah > it's not as optimal as a single compressed download, but it's not terrible. > If it's only 1.0, then that's a problem. Or it could be that the concurrent > connections are being limited, or the gets are just taking a fixed time to > get a response. Maybe memcached would help? > > 2. "Closest" mirror isn't what is important, it's speed. Though you may be > implying that the chosen mirror was still slower? It seemed that you argue > both? > > 3. I think the scope is ok. Qt is not a tool chain, it's a library with > tools. And the expectation is that Qt sits above the platform and > compiler(s). > > > > > > > > > Sent: Tuesday, April 03, 2018 at 2:14 AM > > From: "Sze Howe Koh" > > To: "Qt development mailing list" > > Subject: [Development] To improve UX of the online installer > > > > 3 broad issues impede new users who want to start using Qt and > > frustrate old users who want to update Qt: > > > > (A) Downloading metadata is very time-consuming. > > (B) The automatic mirror selection algorithm doesn't always pick > > the best mirror. > > (C) (New users) It's not clear how to choose what to install. > > > > > > ====================================== > > Factors that contribute to (A) include: > > > > * The metadata downloader opens lots of short-duration TCP > > connections. Wireshark revealed 2391 HTTP GET requests from > > 77.86.229.90 (download.qt.io) on Windows. This process is less painful > > on Linux (1205 GETs -- almost half of Windows') as there are fewer > > compilers/platforms. > > > > > > * Downloading many small files is very inefficient compared to > > downloading a few large files. While GET-ting metadata from > > download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten > > kibibytes). After this, the actual binaries download from my > > designated mirror at ~1 MiB/s, which shows that metadata downloader > > doesn't make good use of available bandwidth. I'm in Australia. > > > > > > * MaintenanceTool downloads metadata too frequently (QTIFW-975). > > > > > > * If the metadata download fails halfway (e.g. one file times out), > > the whole process needs to start from scratch. There is no > > retry/resume. This makes the online installer nigh unusable if the > > user's connection to download.qt.io is flaky: > > https://forum.qt.io/post/450076 > > > > > > * Currently, there is a way to manually avoid downloading unwanted > > metadata: Deselecting the unwanted Temporary Repositories. However, > > all 91 Repositories must be unchecked one-by-one, and this process > > must be repeated each time MaintenanceTool is restarted: > > https://forum.qt.io/post/450076 > > > > > > ====================================== > > Evidence for (B) include: > > > > * Geographical proximity does not imply mirror quality. E.g. a user > > from China finds Chinese mirrors too slow, and opts for non-Chinese > > mirrors instead: > > http://lists.qt-project.org/pipermail/interest/2013-December/010336.html > > > > > > * The algorithm doesn't pick the closest mirror anyway. E.g. a user > > from Israel was given a Japanese mirror instead of a European mirror: > > https://forum.qt.io/topic/87221/ > > > > > > ====================================== > > Examples of (C) include: > > > > * Some users don't realize there are multiple kits per Qt version. > > They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): > > https://forum.qt.io/topic/87608/windows-install-download-size > > > > > > * Some users don't realize Qt Creator != Qt. They install Qt Creator > > without Qt and end up unable to build anything: > > https://forum.qt.io/topic/84198/no-valid-kits-found > > > > > > * Some users don't realize they need to install a compiler separately. > > They also end up unable to build anything: > > https://forum.qt.io/topic/79532/msvc2015-64bit-compiler- > kit-installation-requirements > > > > > > ====================================== > > Ideas for improvement (some render others unnecessary): > > > > 1. Amalgamate and compress all metadata into one file (or at least one > > file per "group"). > > > > 2. Cache metadata locally and use a hash to identify them; avoid > > re-downloading metadata that's already available (Mitch Curtis > > suggested this at QTIFW-975) > > > > 3. Avoid downloading metadata for archived/advanced packages by > > default (Iikka Eklund said this is planned in QTIFW-975) > > > > 4a. Remember the which Repositories the user has deselected before, > > and ignore them for future sessions. > > > > 4b. Let the user choose broad "groups" that they are interested in, > > and remember this choice. For example, there is no point getting > > metadata for Android/UWP packages or showing these packages in the > > "Selection Tree" if I'm only interested in Desktop development. > > > > 5. Add a "Select/Deselect All" button to the Repositories page. > > > > 6. Allow retry/resume if the metadata download fails halfway. > > > > 7. Allow users to manually pick a mirror for binary download. > > > > 8a. Before the user is asked to "Select the components to install", > > show a short page that to explain the difference between Qt and Qt > > Creator and explain that a compiler must be installed separately > > unless MinGW is used. > > > > 8b. Before the user is asked to "Select the components to install", > > have a small wizard to ask a new user some questions -- Which > > version(s): Latest version, LTS version, or older version? Which > > target platforms? Which compiler? Or do they not care/know and want us > > to suggest a good default? Use the answers to pre-fill the "Selection > > Tree" and remind the user to download an external compiler if > > necessary. > > > > 9. If no Qt version is selected (or if too many are selected), pop-up > > a confirmation dialog before installing. > > > > 10. Expand the documentation at http://doc.qt.io/qt-5/ > gettingstarted.html > > > > > > Since (3) is already being planned, please consider (4) which is a > > generalization of (3). > > > > It would be fantastic to see a holistic approach that addresses (A) + > > (B) + (C). For example, (8b) helps the user make the right selection > > at the first try. At the same time, users' answers in (8b) feed into > > (4b) to download fewer metadata files and trim the "Selection Tree". > > This is further sped up by (1) + (2): Each "group" has its own > > amalgamated metadata file, and these files are cached locally to avoid > > re-downloading in the future. Once the selection is complete, (7) > > ensures that the use can get binaries in a timely manner even if the > > auto-selected mirror is no good. > > > > > > Regards, > > Sze-Howe > > _______________________________________________ > > 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 edward.welbourne at qt.io Tue Apr 3 10:10:55 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 3 Apr 2018 08:10:55 +0000 Subject: [Development] To improve UX of the online installer In-Reply-To: References: , Message-ID: Jason H (3 April 2018 02:43) wrote: > I'm not involved with the installer, but 2 points. > 1. Number of gets doesn't really matter as long as it's HTTP 1.1. yeah it's not as optimal as a single compressed download, but it's not terrible. If it's only 1.0, then that's a problem. Why do you believe this ? My first guess is that you're assuming keep-alive or related features. I'm also not involved with the installer, but that only works if all those GETs are done on the same connection. If they're done by separate invocations of wget or curl, they don't benefit from any of HTTP/1.1's features; nor will the installer benefit if it does the GETs internally but opens a fresh socket for each request. If the installer uses a single connection to do all the GETs, sure, this should be OK - but, if it's creating new a connection for each GET, we can speed it up considerably by consolidating to one connection. Eddy. From giuseppe.dangelo at kdab.com Tue Apr 3 11:08:05 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 3 Apr 2018 11:08:05 +0200 Subject: [Development] To improve UX of the online installer In-Reply-To: References: Message-ID: On 03/04/18 10:10, Edward Welbourne wrote: > Jason H (3 April 2018 02:43) wrote: >> I'm not involved with the installer, but 2 points. >> 1. Number of gets doesn't really matter as long as it's HTTP 1.1. yeah it's not as optimal as a single compressed download, but it's not terrible. If it's only 1.0, then that's a problem. > Why do you believe this ? > My first guess is that you're assuming keep-alive or related features. And indeed the installer's requests do use HTTP 1.1, but not keep-alive. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From szehowe.koh at gmail.com Tue Apr 3 11:24:18 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Tue, 3 Apr 2018 17:24:18 +0800 Subject: [Development] To improve UX of the online installer In-Reply-To: References: Message-ID: On 3 April 2018 at 08:43, Jason H wrote: > I'm not involved with the installer, but 2 points. > 1. Number of gets doesn't really matter as long as it's HTTP 1.1. yeah it's not as optimal as a single compressed download, but it's not terrible. If it's only 1.0, then that's a problem. Or it could be that the concurrent connections are being limited, or the gets are just taking a fixed time to get a response. Maybe memcached would help? I'm not familiar with the low-level details of HTTP, so I may have misinterpreted the symptoms. But judging from Eddy's and Giuseppe's posts, it sounds like MaintenanceTool is indeed being bogged down by opening one TCP connection per HTTP GET request. You can check this easily on Windows: Open Resource Monitor, go to the "Network" tab, and then start a metadata download session. The "TCP Connections" pane gets flooded with entries from MaintenanceTool.exe and the "Local Port" values increment rapidly. > 2. "Closest" mirror isn't what is important, it's speed. Though you may be implying that the chosen mirror was still slower? It seemed that you argue both? I'm mainly arguing that the automatic mirror selector makes bad choices for some users, which is why we need a way to manually choose our own mirror. A few years ago, I released a hack-tool to override the automatic selector: https://forum.qt.io/topic/43349/slow-downloads-with-the-online-installer-try-this-tool/ Even today, users regularly come to the forum reporting that the online installer is too slow. Even today, forum veterans recommend this tool to such users. Even today, users report that choosing their own mirror improves download speeds significantly. P.S. My impression is that the selector gives a lot of weight to "closeness" when choosing (see http://lists.qt-project.org/pipermail/development/2014-February/015614.html ). Yet, as you rightly said, "closeness" is not that important. > 3. I think the scope is ok. Qt is not a tool chain, it's a library with tools. And the expectation is that Qt sits above the platform and compiler(s). I agree with the principle. However, you'll be amazed at how frequently new users come to the forum asking why they can't build anything. Some of them lament that it's not straightforward to install and start using Qt. I don't have any stats, but it's plausible that Qt loses a significant number of potential users simply because they install Qt the "wrong way", can't get things to work within X hours/days, and end up walking away. I think it's worth providing small guideposts if it helps increase retention rate. We don't want to be some exclusive club that's inaccessible to newbies. In any case, I'd rather spend my forum time answering questions about how to use Qt features, not helping users with basic installation woes. Regards, Sze-Howe From tino.pyssysalo at qt.io Tue Apr 3 11:27:21 2018 From: tino.pyssysalo at qt.io (Tino Pyssysalo) Date: Tue, 3 Apr 2018 09:27:21 +0000 Subject: [Development] To improve UX of the online installer In-Reply-To: References: Message-ID: <7F84E236-8C76-4B45-A6B9-8273EB361915@qt.io> Thanks for your valuable comments and feedback. Please find my comments online > (A) Downloading metadata is very time-consuming. We have recognized the problem as well and considered several options to solve this issue https://bugreports.qt.io/browse/QTIFW-975. You have excellent points about how to group the repositories. We will take those into account when we plan metadata downloading further. Downloading less metadata, would make the whole download process less vulnerable to network errors. There have been discussions around a retry/resume button and we will evaluate its need after we have evaluated the effect of repository grouping on download time. Obviously, you other suggestions will be considered as well. > (B) The automatic mirror selection algorithm doesn't always pick the best mirror. Adding a select/deselect all button in the repositories view or allowing user to choose mirrors, should be rather easy to do. We will consider these. > (C) (New users) It's not clear how to choose what to install. There has been quite a lot of effort in planning and even implementing different approaches to tackle this. Simple default installation would be easy for newbies, but deciding what the default actually means, is challenging. User may have several toolchains installed and it's difficult to decide in the first installation, for which toolchain the user wants to install Qt libraries. This could be asked separately, but in the end the user would have the same component tree view anyway. To minimise the number of installable components in a Qt version, we have considered removing the checkbox, so that the user is forced to open Qt X.X node and choose components explicitly. However, we would lose the 'partially checked' feature, used by many. We could maybe implement something that the "Qt 5.9.4" node is not selectable but would still show the 'partially checked' mark. Showing additional screens before the component view, would move the complexity of component selection from the installer tree view to some screens. We have also received some feedback that the number of screens is already too high. So, we have been considering simplifying the views https://bugreports.qt.io/browse/QTBUG-62671 by using different categories/groups, which define the visible components to the user. This should simplify the first-time installation experience. Someone may want to install Qt Creator only, but giving a warning, if now Qt target is chosen is a good idea. --- Tino Pyssysalo Senior Manager Product management The Qt Company --- On 03/04/2018, 3.14, "Development on behalf of Sze Howe Koh" wrote: 3 broad issues impede new users who want to start using Qt and frustrate old users who want to update Qt: (A) Downloading metadata is very time-consuming. (B) The automatic mirror selection algorithm doesn't always pick the best mirror. (C) (New users) It's not clear how to choose what to install. ====================================== Factors that contribute to (A) include: * The metadata downloader opens lots of short-duration TCP connections. Wireshark revealed 2391 HTTP GET requests from 77.86.229.90 (download.qt.io) on Windows. This process is less painful on Linux (1205 GETs -- almost half of Windows') as there are fewer compilers/platforms. * Downloading many small files is very inefficient compared to downloading a few large files. While GET-ting metadata from download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten kibibytes). After this, the actual binaries download from my designated mirror at ~1 MiB/s, which shows that metadata downloader doesn't make good use of available bandwidth. I'm in Australia. * MaintenanceTool downloads metadata too frequently (QTIFW-975). * If the metadata download fails halfway (e.g. one file times out), the whole process needs to start from scratch. There is no retry/resume. This makes the online installer nigh unusable if the user's connection to download.qt.io is flaky: https://forum.qt.io/post/450076 * Currently, there is a way to manually avoid downloading unwanted metadata: Deselecting the unwanted Temporary Repositories. However, all 91 Repositories must be unchecked one-by-one, and this process must be repeated each time MaintenanceTool is restarted: https://forum.qt.io/post/450076 ====================================== Evidence for (B) include: * Geographical proximity does not imply mirror quality. E.g. a user from China finds Chinese mirrors too slow, and opts for non-Chinese mirrors instead: http://lists.qt-project.org/pipermail/interest/2013-December/010336.html * The algorithm doesn't pick the closest mirror anyway. E.g. a user from Israel was given a Japanese mirror instead of a European mirror: https://forum.qt.io/topic/87221/ ====================================== Examples of (C) include: * Some users don't realize there are multiple kits per Qt version. They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): https://forum.qt.io/topic/87608/windows-install-download-size * Some users don't realize Qt Creator != Qt. They install Qt Creator without Qt and end up unable to build anything: https://forum.qt.io/topic/84198/no-valid-kits-found * Some users don't realize they need to install a compiler separately. They also end up unable to build anything: https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements ====================================== Ideas for improvement (some render others unnecessary): 1. Amalgamate and compress all metadata into one file (or at least one file per "group"). 2. Cache metadata locally and use a hash to identify them; avoid re-downloading metadata that's already available (Mitch Curtis suggested this at QTIFW-975) 3. Avoid downloading metadata for archived/advanced packages by default (Iikka Eklund said this is planned in QTIFW-975) 4a. Remember the which Repositories the user has deselected before, and ignore them for future sessions. 4b. Let the user choose broad "groups" that they are interested in, and remember this choice. For example, there is no point getting metadata for Android/UWP packages or showing these packages in the "Selection Tree" if I'm only interested in Desktop development. 5. Add a "Select/Deselect All" button to the Repositories page. 6. Allow retry/resume if the metadata download fails halfway. 7. Allow users to manually pick a mirror for binary download. 8a. Before the user is asked to "Select the components to install", show a short page that to explain the difference between Qt and Qt Creator and explain that a compiler must be installed separately unless MinGW is used. 8b. Before the user is asked to "Select the components to install", have a small wizard to ask a new user some questions -- Which version(s): Latest version, LTS version, or older version? Which target platforms? Which compiler? Or do they not care/know and want us to suggest a good default? Use the answers to pre-fill the "Selection Tree" and remind the user to download an external compiler if necessary. 9. If no Qt version is selected (or if too many are selected), pop-up a confirmation dialog before installing. 10. Expand the documentation at http://doc.qt.io/qt-5/gettingstarted.html Since (3) is already being planned, please consider (4) which is a generalization of (3). It would be fantastic to see a holistic approach that addresses (A) + (B) + (C). For example, (8b) helps the user make the right selection at the first try. At the same time, users' answers in (8b) feed into (4b) to download fewer metadata files and trim the "Selection Tree". This is further sped up by (1) + (2): Each "group" has its own amalgamated metadata file, and these files are cached locally to avoid re-downloading in the future. Once the selection is complete, (7) ensures that the use can get binaries in a timely manner even if the auto-selected mirror is no good. Regards, Sze-Howe _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Tue Apr 3 12:13:13 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Tue, 3 Apr 2018 10:13:13 +0000 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: Message-ID: Hi Alexey. The controls look nice, but my concern is how relevant the Silica style is these days (in the context of how many people are developing apps for the Sailfish OS). For each style we currently have, I would justify their inclusion into qtquickcontrols2.git for the following reasons: Default - extremely high performance at the cost of a very basic appearance. Tries to be neutral in terms of looks. Fusion - bridges the gap in terms of Desktop styling. An additional/more specific point that I think it is important here is that the controls are more compact (smaller) than any other pre-built style we offer (the Material style has a dense variant now, but that’s still larger if I recall correctly). Imagine - puts power in the hands of designers, frees up time for developers. Material - very relevant in terms of Android market share. Looks really nice; a good candidate for “non-native” cross-platform apps. Universal - relevant in terms of Windows market share. As mentioned, I do think the Silica controls look nice, but that’s the only justification I could think of for including them in qtquickcontrols2.git. For each new style we add, the maintenance cost increases, so this is something that we need to consider. What is your opinion on this? Cheers. From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] Sent: Friday, 23 March 2018 8:49 PM To: Mitch Curtis Cc: development at qt-project.org Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style Thank you Mitch for the feedback! I've also tried to record current controls on a real device: https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >: Silica cheat sheet: https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png Theme cheat sheet: https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png Icon reference: https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png code example: https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 Youtube video with timestamp for platform-specific PulleyMenu element example: https://youtu.be/jByW7UNmbxU?t=11m38s 2018-03-23 21:40 GMT+03:00 Mitch Curtis >: Hello. Are there any screenshots of it? I read that entire page and the Silica docs but couldn’t see anything. Cheers. From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Alexey Andreyev Sent: Friday, 23 March 2018 5:39 PM To: development at qt-project.org Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style Hello! My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc project? I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ and want to create a proposal. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tantrido at ya.ru Tue Apr 3 12:38:37 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Tue, 03 Apr 2018 13:38:37 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: Message-ID: <3659321522751917@web57g.yandex.ru> Hi all, my 2 cents here: >The controls look nice, but my concern is how relevant the Silica style is these days (in the context of how many people are developing apps for the >Sailfish OS). Sailfish OS become VERY popular in Russia and in Latin America, and for people who wants their data and communication be secure. Market in Russia growing very fast, Sailfish OS devices are hits of sales, leading universities created courses for Sailfish OS, government certified it for corporate and government use and since 2019 all mobile applications from national software list (government and corporate use) should work in Sailfish OS (according to import replacing law all applications should be Russian-native and secure). --  Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 03.04.2018, 13:13, "Mitch Curtis" : > Hi Alexey. > > The controls look nice, but my concern is how relevant the Silica style is these days (in the context of how many people are developing apps for the Sailfish OS). > > For each style we currently have, I would justify their inclusion into qtquickcontrols2.git for the following reasons: > > Default - extremely high performance at the cost of a very basic appearance. Tries to be neutral in terms of looks. > > Fusion - bridges the gap in terms of Desktop styling. An additional/more specific point that I think it is important here is that the controls are more compact (smaller) than any other pre-built style we offer (the Material style has a dense variant now, but that’s still larger if I recall correctly). > > Imagine - puts power in the hands of designers, frees up time for developers. > > Material - very relevant in terms of Android market share. Looks really nice; a good candidate for “non-native” cross-platform apps. > > Universal - relevant in terms of Windows market share. > > As mentioned, I do think the Silica controls look nice, but that’s the only justification I could think of for including them in qtquickcontrols2.git. For each new style we add, the maintenance cost increases, so this is something that we need to consider. > > What is your opinion on this? > > Cheers. > > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] > Sent: Friday, 23 March 2018 8:49 PM > To: Mitch Curtis > Cc: development at qt-project.org > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style > > Thank you Mitch for the feedback! > I've also tried to record current controls on a real device: https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) > > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev : >> Silica cheat sheet: >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >> Theme cheat sheet: >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >> Icon reference: >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >> code example: >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >> >> Youtube video with timestamp for platform-specific PulleyMenu element example: https://youtu.be/jByW7UNmbxU?t=11m38s >> >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >>> Hello. >>> >>> Are there any screenshots of it? I read that entire page and the Silica docs but couldn’t see anything. >>> >>> Cheers. >>> >>> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Alexey Andreyev >>> Sent: Friday, 23 March 2018 5:39 PM >>> To: development at qt-project.org >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style >>> >>> Hello! >>> My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc project? >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>> >>> and want to create a proposal. > > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From yetanotherandreyev at gmail.com Tue Apr 3 14:13:56 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Tue, 3 Apr 2018 15:13:56 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: <3659321522751917@web57g.yandex.ru> References: <3659321522751917@web57g.yandex.ru> Message-ID: Hi, Aleksey Kontsevich! Thank you for your support, I do agree that Sailfish OS is receiving a huge contribution from Russian speaking developers and focusing on other local markets too. There's also related AsteroidOS community about smartwatches. They have a demo [1] Talking about popularity: from my point of view, while Microsoft is providing their Metro unified look for desktop and Intel-based tablets (and Xbox) for example, looks like they do not have any plans for new mobile devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I do not want to mislead anyone. Mitch Curtis, thank you for your feedback sincerely. I do understand your skepticism about yet another controls in mainline to support. (but I do not share this personally :) I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach (to play on my Arch Linux system). Dependency from some private APIs looks tricky for me at first glance. I'm trying to sort out. I'm not against providing silica style as some custom repo, the result I want to get is open source solution to run Qt application in my personal environment with native Silica look and feel. Will be happy to get any hints about basic repo draft in that case (should I look at Kirigami approach?) Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money support, I love Silica style, using Sailfish OS for several years and can't stand that no one is willing to port it to modern QQC2 approach :) I guess it could radically change skepticism about qt quick controls approach in general from ios and android developers. [1]: https://www.youtube.com/watch?v=Rd86KTs2Les [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : > Hi all, my 2 cents here: > > >The controls look nice, but my concern is how relevant the Silica style > is these days (in the context of how many people are developing apps for the > >Sailfish OS). > > Sailfish OS become VERY popular in Russia and in Latin America, and for > people who wants their data and communication be secure. Market in Russia > growing very fast, Sailfish OS devices are hits of sales, leading > universities created courses for Sailfish OS, government certified > it for corporate and government use and since 2019 all mobile applications > from national software list (government and corporate use) should work in > Sailfish OS (according to import replacing law all applications should be > Russian-native and secure). > > -- > Best regards, > Aleksey > Linked in https://www.linkedin.com/in/alekseykontsevich > > > > 03.04.2018, 13:13, "Mitch Curtis" : > > Hi Alexey. > > > > The controls look nice, but my concern is how relevant the Silica style > is these days (in the context of how many people are developing apps for > the Sailfish OS). > > > > For each style we currently have, I would justify their inclusion into > qtquickcontrols2.git for the following reasons: > > > > Default - extremely high performance at the cost of a very basic > appearance. Tries to be neutral in terms of looks. > > > > Fusion - bridges the gap in terms of Desktop styling. An additional/more > specific point that I think it is important here is that the controls are > more compact (smaller) than any other pre-built style we offer (the > Material style has a dense variant now, but that’s still larger if I recall > correctly). > > > > Imagine - puts power in the hands of designers, frees up time for > developers. > > > > Material - very relevant in terms of Android market share. Looks really > nice; a good candidate for “non-native” cross-platform apps. > > > > Universal - relevant in terms of Windows market share. > > > > As mentioned, I do think the Silica controls look nice, but that’s the > only justification I could think of for including them in > qtquickcontrols2.git. For each new style we add, the maintenance cost > increases, so this is something that we need to consider. > > > > What is your opinion on this? > > > > Cheers. > > > > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] > > Sent: Friday, 23 March 2018 8:49 PM > > To: Mitch Curtis > > Cc: development at qt-project.org > > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt > Quick Controls 2 Sailfish Silica Style > > > > Thank you Mitch for the feedback! > > I've also tried to record current controls on a real device: > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) > > > > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >: > >> Silica cheat sheet: > >> https://sailfishos.org/wp-content/uploads/2016/06/ > component_cheatsheet.png > >> Theme cheat sheet: > >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png > >> Icon reference: > >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png > >> code example: > >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 > >> > >> Youtube video with timestamp for platform-specific PulleyMenu element > example: https://youtu.be/jByW7UNmbxU?t=11m38s > >> > >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : > >>> Hello. > >>> > >>> Are there any screenshots of it? I read that entire page and the > Silica docs but couldn’t see anything. > >>> > >>> Cheers. > >>> > >>> From: Development [mailto:development-bounces+mitch.curtis= > qt.io at qt-project.org] On Behalf Of Alexey Andreyev > >>> Sent: Friday, 23 March 2018 5:39 PM > >>> To: development at qt-project.org > >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt > Quick Controls 2 Sailfish Silica Style > >>> > >>> Hello! > >>> My name is Alexey, what do you think about Silica Style for QQC2 as a > gsoc project? > >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ > >>> > >>> and want to create a proposal. > > > > , > > > > _______________________________________________ > > 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 jeanmichael.celerier at gmail.com Tue Apr 3 14:41:16 2018 From: jeanmichael.celerier at gmail.com (=?UTF-8?Q?Jean=2DMicha=C3=ABl_Celerier?=) Date: Tue, 3 Apr 2018 14:41:16 +0200 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> Message-ID: If the controls don't end up in qtquickcontrols2, please at least consider putting them in qpm (https://www.qpm.io/) so that other people can benefit from them easily :) ------- Jean-Michaël Celerier http://www.jcelerier.name On Tue, Apr 3, 2018 at 2:13 PM, Alexey Andreyev < yetanotherandreyev at gmail.com> wrote: > Hi, Aleksey Kontsevich! Thank you for your support, I do agree that > Sailfish OS is receiving a huge contribution from Russian speaking > developers and focusing on other local markets too. There's also related > AsteroidOS community about smartwatches. They have a demo [1] > > Talking about popularity: from my point of view, while Microsoft is > providing their Metro unified look for desktop and Intel-based tablets (and > Xbox) for example, looks like they do not have any plans for new mobile > devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with > GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, > I do not want to mislead anyone. > > Mitch Curtis, thank you for your feedback sincerely. I do understand your > skepticism about yet another controls in mainline to support. (but I do not > share this personally :) > I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach > (to play on my Arch Linux system). Dependency from some private APIs looks > tricky for me at first glance. I'm trying to sort out. I'm not against > providing silica style as some custom repo, the result I want to get is > open source solution to run Qt application in my personal environment with > native Silica look and feel. Will be happy to get any hints about basic > repo draft in that case (should I look at Kirigami approach?) > > Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money > support, I love Silica style, using Sailfish OS for several years and can't > stand that no one is willing to port it to modern QQC2 approach :) I guess > it could radically change skepticism about qt quick controls approach in > general from ios and android developers. > > [1]: https://www.youtube.com/watch?v=Rd86KTs2Les > [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris > > 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : > >> Hi all, my 2 cents here: >> >> >The controls look nice, but my concern is how relevant the Silica style >> is these days (in the context of how many people are developing apps for the >> >Sailfish OS). >> >> Sailfish OS become VERY popular in Russia and in Latin America, and for >> people who wants their data and communication be secure. Market in Russia >> growing very fast, Sailfish OS devices are hits of sales, leading >> universities created courses for Sailfish OS, government certified >> it for corporate and government use and since 2019 all mobile >> applications from national software list (government and corporate use) >> should work in Sailfish OS (according to import replacing law all >> applications should be Russian-native and secure). >> >> -- >> Best regards, >> Aleksey >> Linked in https://www.linkedin.com/in/alekseykontsevich >> >> >> >> 03.04.2018, 13:13, "Mitch Curtis" : >> > Hi Alexey. >> > >> > The controls look nice, but my concern is how relevant the Silica style >> is these days (in the context of how many people are developing apps for >> the Sailfish OS). >> > >> > For each style we currently have, I would justify their inclusion into >> qtquickcontrols2.git for the following reasons: >> > >> > Default - extremely high performance at the cost of a very basic >> appearance. Tries to be neutral in terms of looks. >> > >> > Fusion - bridges the gap in terms of Desktop styling. An >> additional/more specific point that I think it is important here is that >> the controls are more compact (smaller) than any other pre-built style we >> offer (the Material style has a dense variant now, but that’s still larger >> if I recall correctly). >> > >> > Imagine - puts power in the hands of designers, frees up time for >> developers. >> > >> > Material - very relevant in terms of Android market share. Looks really >> nice; a good candidate for “non-native” cross-platform apps. >> > >> > Universal - relevant in terms of Windows market share. >> > >> > As mentioned, I do think the Silica controls look nice, but that’s the >> only justification I could think of for including them in >> qtquickcontrols2.git. For each new style we add, the maintenance cost >> increases, so this is something that we need to consider. >> > >> > What is your opinion on this? >> > >> > Cheers. >> > >> > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >> > Sent: Friday, 23 March 2018 8:49 PM >> > To: Mitch Curtis >> > Cc: development at qt-project.org >> > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >> Quick Controls 2 Sailfish Silica Style >> > >> > Thank you Mitch for the feedback! >> > I've also tried to record current controls on a real device: >> https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >> > >> > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev < >> yetanotherandreyev at gmail.com>: >> >> Silica cheat sheet: >> >> https://sailfishos.org/wp-content/uploads/2016/06/component_ >> cheatsheet.png >> >> Theme cheat sheet: >> >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >> >> Icon reference: >> >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >> >> code example: >> >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >> >> >> >> Youtube video with timestamp for platform-specific PulleyMenu element >> example: https://youtu.be/jByW7UNmbxU?t=11m38s >> >> >> >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >> >>> Hello. >> >>> >> >>> Are there any screenshots of it? I read that entire page and the >> Silica docs but couldn’t see anything. >> >>> >> >>> Cheers. >> >>> >> >>> From: Development [mailto:development-bounces+mitch.curtis= >> qt.io at qt-project.org] On Behalf Of Alexey Andreyev >> >>> Sent: Friday, 23 March 2018 5:39 PM >> >>> To: development at qt-project.org >> >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt >> Quick Controls 2 Sailfish Silica Style >> >>> >> >>> Hello! >> >>> My name is Alexey, what do you think about Silica Style for QQC2 as a >> gsoc project? >> >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >> >>> >> >>> and want to create a proposal. >> > >> > , >> > >> > _______________________________________________ >> > 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 giuseppe.dangelo at kdab.com Tue Apr 3 16:52:41 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 3 Apr 2018 16:52:41 +0200 Subject: [Development] To improve UX of the online installer In-Reply-To: References: Message-ID: Hi, Il 03/04/2018 02:14, Sze Howe Koh ha scritto: > 3 broad issues impede new users who want to start using Qt and > frustrate old users who want to update Qt: > > (A) Downloading metadata is very time-consuming. > (B) The automatic mirror selection algorithm doesn't always pick > the best mirror. > (C) (New users) It's not clear how to choose what to install. May I suggest to file these issues on Jira? Otherwise, things tend to be forgotten / not acted upon. My 2 c, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From tantrido at ya.ru Tue Apr 3 19:42:59 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Tue, 03 Apr 2018 20:42:59 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> Message-ID: <788031522777379@web1j.yandex.ru> qpm for Qt is an npm analogue for Node.JS? Cool! --  Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 03.04.2018, 15:42, "Jean-Michaël Celerier" : > If the controls don't end up in qtquickcontrols2, please at least consider putting them in qpm (https://www.qpm.io/) so that other people can benefit from them easily :) > > ------- > Jean-Michaël Celerier > http://www.jcelerier.name > > On Tue, Apr 3, 2018 at 2:13 PM, Alexey Andreyev wrote: >> Hi, Aleksey Kontsevich! Thank you for your support, I do agree that Sailfish OS is receiving a huge contribution from Russian speaking developers and focusing on other local markets too. There's also related AsteroidOS community about smartwatches. They have a demo [1] >> >> Talking about popularity: from my point of view, while Microsoft is providing their Metro unified look for desktop and Intel-based tablets (and Xbox) for example, looks like they do not have any plans for new mobile devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I do not want to mislead anyone. >> >> Mitch Curtis, thank you for your feedback sincerely. I do understand your skepticism about yet another controls in mainline to support. (but I do not share this personally :) >> I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach (to play on my Arch Linux system). Dependency from some private APIs looks tricky for me at first glance. I'm trying to sort out. I'm not against providing silica style as some custom repo, the result I want to get is open source solution to run Qt application in my personal environment with native Silica look and feel. Will be happy to get any hints about basic repo draft in that case (should I look at Kirigami approach?) >> >> Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money support, I love Silica style, using Sailfish OS for several years and can't stand that no one is willing to port it to modern QQC2 approach :) I guess it could radically change skepticism about qt quick controls approach in general from ios and android developers. >> >> [1]: https://www.youtube.com/watch?v=Rd86KTs2Les >> [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris >> >> 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : >>> Hi all, my 2 cents here: >>> >>>>The controls look nice, but my concern is how relevant the Silica style is these days (in the context of how many people are developing apps for the >>>>Sailfish OS). >>> >>> Sailfish OS become VERY popular in Russia and in Latin America, and for people who wants their data and communication be secure. Market in Russia growing very fast, Sailfish OS devices are hits of sales, leading universities created courses for Sailfish OS, government certified >>> it for corporate and government use and since 2019 all mobile applications from national software list (government and corporate use) should work in Sailfish OS (according to import replacing law all applications should be Russian-native and secure). >>> >>> -- >>> Best regards, >>> Aleksey >>> Linked in  https://www.linkedin.com/in/alekseykontsevich >>> >>> 03.04.2018, 13:13, "Mitch Curtis" : >>>> Hi Alexey. >>>> >>>> The controls look nice, but my concern is how relevant the Silica style is these days (in the context of how many people are developing apps for the Sailfish OS). >>>> >>>> For each style we currently have, I would justify their inclusion into qtquickcontrols2.git for the following reasons: >>>> >>>> Default - extremely high performance at the cost of a very basic appearance. Tries to be neutral in terms of looks. >>>> >>>> Fusion - bridges the gap in terms of Desktop styling. An additional/more specific point that I think it is important here is that the controls are more compact (smaller) than any other pre-built style we offer (the Material style has a dense variant now, but that’s still larger if I recall correctly). >>>> >>>> Imagine - puts power in the hands of designers, frees up time for developers. >>>> >>>> Material - very relevant in terms of Android market share. Looks really nice; a good candidate for “non-native” cross-platform apps. >>>> >>>> Universal - relevant in terms of Windows market share. >>>> >>>> As mentioned, I do think the Silica controls look nice, but that’s the only justification I could think of for including them in qtquickcontrols2.git. For each new style we add, the maintenance cost increases, so this is something that we need to consider. >>>> >>>> What is your opinion on this? >>>> >>>> Cheers. >>>> >>>> From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>> Sent: Friday, 23 March 2018 8:49 PM >>>> To: Mitch Curtis >>>> Cc: development at qt-project.org >>>> Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style >>>> >>>> Thank you Mitch for the feedback! >>>> I've also tried to record current controls on a real device: https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >>>> >>>> 2018-03-23 21:55 GMT+03:00 Alexey Andreyev : >>>>> Silica cheat sheet: >>>>> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >>>>> Theme cheat sheet: >>>>> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >>>>> Icon reference: >>>>> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >>>>> code example: >>>>> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >>>>> >>>>> Youtube video with timestamp for platform-specific PulleyMenu element example: https://youtu.be/jByW7UNmbxU?t=11m38s >>>>> >>>>> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >>>>>> Hello. >>>>>> >>>>>> Are there any screenshots of it? I read that entire page and the Silica docs but couldn’t see anything. >>>>>> >>>>>> Cheers. >>>>>> >>>>>> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Alexey Andreyev >>>>>> Sent: Friday, 23 March 2018 5:39 PM >>>>>> To: development at qt-project.org >>>>>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style >>>>>> >>>>>> Hello! >>>>>> My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc project? >>>>>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>>>>> >>>>>> and want to create a proposal. >>>> >>> , >>> >>> _______________________________________________ >>> 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 yetanotherandreyev at gmail.com Tue Apr 3 23:11:02 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Wed, 4 Apr 2018 00:11:02 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: <788031522777379@web1j.yandex.ru> References: <3659321522751917@web57g.yandex.ru> <788031522777379@web1j.yandex.ru> Message-ID: Jean-Michaël, I've heard about qpm but never used it since I'm perfectly fine with my distro package manager :) But I'm ok to publish it there if we decide not to add the project to qtquickcontrols2 repo, thank you for the hint! 2018-04-03 20:42 GMT+03:00 Aleksey Kontsevich : > qpm for Qt is an npm analogue for Node.JS? Cool! > > -- > Best regards, > Aleksey > Linked in https://www.linkedin.com/in/alekseykontsevich > > > > 03.04.2018, 15:42, "Jean-Michaël Celerier" >: > > If the controls don't end up in qtquickcontrols2, please at least > consider putting them in qpm (https://www.qpm.io/) so that other people > can benefit from them easily :) > > > > ------- > > Jean-Michaël Celerier > > http://www.jcelerier.name > > > > On Tue, Apr 3, 2018 at 2:13 PM, Alexey Andreyev < > yetanotherandreyev at gmail.com> wrote: > >> Hi, Aleksey Kontsevich! Thank you for your support, I do agree that > Sailfish OS is receiving a huge contribution from Russian speaking > developers and focusing on other local markets too. There's also related > AsteroidOS community about smartwatches. They have a demo [1] > >> > >> Talking about popularity: from my point of view, while Microsoft is > providing their Metro unified look for desktop and Intel-based tablets (and > Xbox) for example, looks like they do not have any plans for new mobile > devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with > GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, > I do not want to mislead anyone. > >> > >> Mitch Curtis, thank you for your feedback sincerely. I do understand > your skepticism about yet another controls in mainline to support. (but I > do not share this personally :) > >> I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 > brach (to play on my Arch Linux system). Dependency from some private APIs > looks tricky for me at first glance. I'm trying to sort out. I'm not > against providing silica style as some custom repo, the result I want to > get is open source solution to run Qt application in my personal > environment with native Silica look and feel. Will be happy to get any > hints about basic repo draft in that case (should I look at Kirigami > approach?) > >> > >> Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money > support, I love Silica style, using Sailfish OS for several years and can't > stand that no one is willing to port it to modern QQC2 approach :) I guess > it could radically change skepticism about qt quick controls approach in > general from ios and android developers. > >> > >> [1]: https://www.youtube.com/watch?v=Rd86KTs2Les > >> [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris > >> > >> 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : > >>> Hi all, my 2 cents here: > >>> > >>>>The controls look nice, but my concern is how relevant the Silica > style is these days (in the context of how many people are developing apps > for the > >>>>Sailfish OS). > >>> > >>> Sailfish OS become VERY popular in Russia and in Latin America, and > for people who wants their data and communication be secure. Market in > Russia growing very fast, Sailfish OS devices are hits of sales, leading > universities created courses for Sailfish OS, government certified > >>> it for corporate and government use and since 2019 all mobile > applications from national software list (government and corporate use) > should work in Sailfish OS (according to import replacing law all > applications should be Russian-native and secure). > >>> > >>> -- > >>> Best regards, > >>> Aleksey > >>> Linked in https://www.linkedin.com/in/alekseykontsevich > >>> > >>> 03.04.2018, 13:13, "Mitch Curtis" : > >>>> Hi Alexey. > >>>> > >>>> The controls look nice, but my concern is how relevant the Silica > style is these days (in the context of how many people are developing apps > for the Sailfish OS). > >>>> > >>>> For each style we currently have, I would justify their inclusion > into qtquickcontrols2.git for the following reasons: > >>>> > >>>> Default - extremely high performance at the cost of a very basic > appearance. Tries to be neutral in terms of looks. > >>>> > >>>> Fusion - bridges the gap in terms of Desktop styling. An > additional/more specific point that I think it is important here is that > the controls are more compact (smaller) than any other pre-built style we > offer (the Material style has a dense variant now, but that’s still larger > if I recall correctly). > >>>> > >>>> Imagine - puts power in the hands of designers, frees up time for > developers. > >>>> > >>>> Material - very relevant in terms of Android market share. Looks > really nice; a good candidate for “non-native” cross-platform apps. > >>>> > >>>> Universal - relevant in terms of Windows market share. > >>>> > >>>> As mentioned, I do think the Silica controls look nice, but that’s > the only justification I could think of for including them in > qtquickcontrols2.git. For each new style we add, the maintenance cost > increases, so this is something that we need to consider. > >>>> > >>>> What is your opinion on this? > >>>> > >>>> Cheers. > >>>> > >>>> From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] > >>>> Sent: Friday, 23 March 2018 8:49 PM > >>>> To: Mitch Curtis > >>>> Cc: development at qt-project.org > >>>> Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt > Quick Controls 2 Sailfish Silica Style > >>>> > >>>> Thank you Mitch for the feedback! > >>>> I've also tried to record current controls on a real device: > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) > >>>> > >>>> 2018-03-23 21:55 GMT+03:00 Alexey Andreyev < > yetanotherandreyev at gmail.com>: > >>>>> Silica cheat sheet: > >>>>> https://sailfishos.org/wp-content/uploads/2016/06/ > component_cheatsheet.png > >>>>> Theme cheat sheet: > >>>>> https://sailfishos.org/wp-content/uploads/2016/06/theme_ > cheatsheet.png > >>>>> Icon reference: > >>>>> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png > >>>>> code example: > >>>>> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 > >>>>> > >>>>> Youtube video with timestamp for platform-specific PulleyMenu > element example: https://youtu.be/jByW7UNmbxU?t=11m38s > >>>>> > >>>>> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : > >>>>>> Hello. > >>>>>> > >>>>>> Are there any screenshots of it? I read that entire page and the > Silica docs but couldn’t see anything. > >>>>>> > >>>>>> Cheers. > >>>>>> > >>>>>> From: Development [mailto:development-bounces+mitch.curtis= > qt.io at qt-project.org] On Behalf Of Alexey Andreyev > >>>>>> Sent: Friday, 23 March 2018 5:39 PM > >>>>>> To: development at qt-project.org > >>>>>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt > Quick Controls 2 Sailfish Silica Style > >>>>>> > >>>>>> Hello! > >>>>>> My name is Alexey, what do you think about Silica Style for QQC2 as > a gsoc project? > >>>>>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ > >>>>>> > >>>>>> and want to create a proposal. > >>>> > >>> , > >>> > >>> _______________________________________________ > >>> 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 dominik.holland at pelagicore.com Wed Apr 4 10:14:07 2018 From: dominik.holland at pelagicore.com (Dominik Holland) Date: Wed, 4 Apr 2018 10:14:07 +0200 Subject: [Development] Qt Sanity Bot down Message-ID: <933c48b1-a5d3-3362-cc28-c21cf45fbd47@pelagicore.com> Hi, it looks like the Qt Sanity Bot is down for several days now. Is anyone working on this ? Or is this repository specific ? Atleast i can see some commits not having the bot as reviewer at all and adding it manually also doesn't help (https://codereview.qt-project.org/#/c/224989/) Dominik From cavendish.qi at gmail.com Wed Apr 4 10:28:15 2018 From: cavendish.qi at gmail.com (Liang Qi) Date: Wed, 4 Apr 2018 10:28:15 +0200 Subject: [Development] Qt Sanity Bot down In-Reply-To: <933c48b1-a5d3-3362-cc28-c21cf45fbd47@pelagicore.com> References: <933c48b1-a5d3-3362-cc28-c21cf45fbd47@pelagicore.com> Message-ID: When Qt Sanity Bot is on vacation, here is the temporary solution, click "Review" button, unfold the "Sanity-Review" section under "Code-Review", just do a "+1 Sanity review passed". --Liang On 4 April 2018 at 10:14, Dominik Holland wrote: > Hi, > > it looks like the Qt Sanity Bot is down for several days now. Is anyone > working on this ? Or is this repository specific ? > > Atleast i can see some commits not having the bot as reviewer at all and > adding it manually also doesn't help > (https://codereview.qt-project.org/#/c/224989/) > > Dominik > > _______________________________________________ > 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 qt.io Wed Apr 4 13:23:29 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Wed, 04 Apr 2018 13:23:29 +0200 Subject: [Development] Qt Sanity Bot down -> up again In-Reply-To: References: <933c48b1-a5d3-3362-cc28-c21cf45fbd47@pelagicore.com> Message-ID: <1948643.qBjxXKg2Qc@frederik-thinkcentre-m93p> I restarted the sanity bot just now, please give it a few minutes to catch up on your changes :) Cheers, Frederik On onsdag 4. april 2018 10.28.15 CEST Liang Qi wrote: > When Qt Sanity Bot is on vacation, here is the temporary solution, click > "Review" button, unfold the "Sanity-Review" section under "Code-Review", > just do a "+1 Sanity review passed". > > --Liang > > On 4 April 2018 at 10:14, Dominik Holland > > wrote: > > Hi, > > > > it looks like the Qt Sanity Bot is down for several days now. Is anyone > > working on this ? Or is this repository specific ? > > > > Atleast i can see some commits not having the bot as reviewer at all and > > adding it manually also doesn't help > > (https://codereview.qt-project.org/#/c/224989/) > > > > Dominik > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development From robert.loehning at qt.io Wed Apr 4 14:44:38 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Wed, 4 Apr 2018 14:44:38 +0200 Subject: [Development] To improve UX of the online installer In-Reply-To: <7F84E236-8C76-4B45-A6B9-8273EB361915@qt.io> References: <7F84E236-8C76-4B45-A6B9-8273EB361915@qt.io> Message-ID: Hi everybody, could (C) be improved by just swapping the order in the tree? Now we have something like: - Qt 5.10.1 + MSVC 2015 + MSVC 2017 + MinGW + Android - Qt 5.9.4 + MSVC 2015 + MSVC 2017 + MinGW + Android Instead this could be: - Qt for MSVC 2017 (partially checked if toolchain found) + Qt 5.10.1 (newest version checked by default) + Qt 5.9.4 (older versions unchecked by default) - Qt for MSVC 2015 (unchecked if toolchain not found) + Qt 5.10.1 + Qt 5.9.4 - Qt for MinGW (partially checked if no other toolchain found) + Qt 5.10.1 + Qt 5.9.4 - Tools + MinGW (checked if no other toolchain found) Pros: - Easier to uncheck all packages for a specific toolchain - Easier to select various Qt versions for a specific toolchain - Newbies who know their preferred toolchain find it more easily Cons: - Harder to install the same Qt version for various toolchains Does this make sense? Cheers, Robert Am 03.04.2018 um 11:27 schrieb Tino Pyssysalo: > Thanks for your valuable comments and feedback. Please find my comments online > >> (A) Downloading metadata is very time-consuming. > > We have recognized the problem as well and considered several options to solve this issue https://bugreports.qt.io/browse/QTIFW-975. You have excellent points about how to group the repositories. We will take those into account when we plan metadata downloading further. Downloading less metadata, would make the whole download process less vulnerable to network errors. There have been discussions around a retry/resume button and we will evaluate its need after we have evaluated the effect of repository grouping on download time. Obviously, you other suggestions will be considered as well. > >> (B) The automatic mirror selection algorithm doesn't always pick the best mirror. > > Adding a select/deselect all button in the repositories view or allowing user to choose mirrors, should be rather easy to do. We will consider these. > >> (C) (New users) It's not clear how to choose what to install. > > There has been quite a lot of effort in planning and even implementing different approaches to tackle this. Simple default installation would be easy for newbies, but deciding what the default actually means, is challenging. User may have several toolchains installed and it's difficult to decide in the first installation, for which toolchain the user wants to install Qt libraries. This could be asked separately, but in the end the user would have the same component tree view anyway. > > To minimise the number of installable components in a Qt version, we have considered removing the checkbox, so that the user is forced to open Qt X.X node and choose components explicitly. However, we would lose the 'partially checked' feature, used by many. We could maybe implement something that the "Qt 5.9.4" node is not selectable but would still show the 'partially checked' mark. > > Showing additional screens before the component view, would move the complexity of component selection from the installer tree view to some screens. We have also received some feedback that the number of screens is already too high. So, we have been considering simplifying the views https://bugreports.qt.io/browse/QTBUG-62671 by using different categories/groups, which define the visible components to the user. This should simplify the first-time installation experience. > > Someone may want to install Qt Creator only, but giving a warning, if now Qt target is chosen is a good idea. > > --- > Tino Pyssysalo > Senior Manager > Product management > > The Qt Company > --- > > > On 03/04/2018, 3.14, "Development on behalf of Sze Howe Koh" wrote: > > 3 broad issues impede new users who want to start using Qt and > frustrate old users who want to update Qt: > > (A) Downloading metadata is very time-consuming. > (B) The automatic mirror selection algorithm doesn't always pick > the best mirror. > (C) (New users) It's not clear how to choose what to install. > > > ====================================== > Factors that contribute to (A) include: > > * The metadata downloader opens lots of short-duration TCP > connections. Wireshark revealed 2391 HTTP GET requests from > 77.86.229.90 (download.qt.io) on Windows. This process is less painful > on Linux (1205 GETs -- almost half of Windows') as there are fewer > compilers/platforms. > > > * Downloading many small files is very inefficient compared to > downloading a few large files. While GET-ting metadata from > download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten > kibibytes). After this, the actual binaries download from my > designated mirror at ~1 MiB/s, which shows that metadata downloader > doesn't make good use of available bandwidth. I'm in Australia. > > > * MaintenanceTool downloads metadata too frequently (QTIFW-975). > > > * If the metadata download fails halfway (e.g. one file times out), > the whole process needs to start from scratch. There is no > retry/resume. This makes the online installer nigh unusable if the > user's connection to download.qt.io is flaky: > https://forum.qt.io/post/450076 > > > * Currently, there is a way to manually avoid downloading unwanted > metadata: Deselecting the unwanted Temporary Repositories. However, > all 91 Repositories must be unchecked one-by-one, and this process > must be repeated each time MaintenanceTool is restarted: > https://forum.qt.io/post/450076 > > > ====================================== > Evidence for (B) include: > > * Geographical proximity does not imply mirror quality. E.g. a user > from China finds Chinese mirrors too slow, and opts for non-Chinese > mirrors instead: > http://lists.qt-project.org/pipermail/interest/2013-December/010336.html > > > * The algorithm doesn't pick the closest mirror anyway. E.g. a user > from Israel was given a Japanese mirror instead of a European mirror: > https://forum.qt.io/topic/87221/ > > > ====================================== > Examples of (C) include: > > * Some users don't realize there are multiple kits per Qt version. > They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): > https://forum.qt.io/topic/87608/windows-install-download-size > > > * Some users don't realize Qt Creator != Qt. They install Qt Creator > without Qt and end up unable to build anything: > https://forum.qt.io/topic/84198/no-valid-kits-found > > > * Some users don't realize they need to install a compiler separately. > They also end up unable to build anything: > https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements > > > ====================================== > Ideas for improvement (some render others unnecessary): > > 1. Amalgamate and compress all metadata into one file (or at least one > file per "group"). > > 2. Cache metadata locally and use a hash to identify them; avoid > re-downloading metadata that's already available (Mitch Curtis > suggested this at QTIFW-975) > > 3. Avoid downloading metadata for archived/advanced packages by > default (Iikka Eklund said this is planned in QTIFW-975) > > 4a. Remember the which Repositories the user has deselected before, > and ignore them for future sessions. > > 4b. Let the user choose broad "groups" that they are interested in, > and remember this choice. For example, there is no point getting > metadata for Android/UWP packages or showing these packages in the > "Selection Tree" if I'm only interested in Desktop development. > > 5. Add a "Select/Deselect All" button to the Repositories page. > > 6. Allow retry/resume if the metadata download fails halfway. > > 7. Allow users to manually pick a mirror for binary download. > > 8a. Before the user is asked to "Select the components to install", > show a short page that to explain the difference between Qt and Qt > Creator and explain that a compiler must be installed separately > unless MinGW is used. > > 8b. Before the user is asked to "Select the components to install", > have a small wizard to ask a new user some questions -- Which > version(s): Latest version, LTS version, or older version? Which > target platforms? Which compiler? Or do they not care/know and want us > to suggest a good default? Use the answers to pre-fill the "Selection > Tree" and remind the user to download an external compiler if > necessary. > > 9. If no Qt version is selected (or if too many are selected), pop-up > a confirmation dialog before installing. > > 10. Expand the documentation at http://doc.qt.io/qt-5/gettingstarted.html > > > Since (3) is already being planned, please consider (4) which is a > generalization of (3). > > It would be fantastic to see a holistic approach that addresses (A) + > (B) + (C). For example, (8b) helps the user make the right selection > at the first try. At the same time, users' answers in (8b) feed into > (4b) to download fewer metadata files and trim the "Selection Tree". > This is further sped up by (1) + (2): Each "group" has its own > amalgamated metadata file, and these files are cached locally to avoid > re-downloading in the future. Once the selection is complete, (7) > ensures that the use can get binaries in a timely manner even if the > auto-selected mirror is no good. > > > Regards, > Sze-Howe From iikka.eklund at qt.io Thu Apr 5 14:24:10 2018 From: iikka.eklund at qt.io (Iikka Eklund) Date: Thu, 5 Apr 2018 12:24:10 +0000 Subject: [Development] To improve UX of the online installer In-Reply-To: References: <7F84E236-8C76-4B45-A6B9-8273EB361915@qt.io>, Message-ID: Hi, > could (C) be improved by just swapping the order in the tree? unfortunately not very feasible technically. IFW does does not separate model from view, the install tree is direct presentation of the data (online repositories). If we'd "drag & drop" the packages into new locations in the tree it would result for a sha1 checksum failure for each component. If we'd rebuild the online repositories from day 1 (i.e. all the qt releases till today) to make the install tree structure change, it would take huge effort and everybody would get all this promoted as updates via MaintenanceTool (gigabytes in worst case). (I'd vote for implementing view layer (or something similar) in the IFW so the UI adaptations (install-tree) would be much easier to be adapted.) Iikka Eklund Senior Software Engineer The Qt Company Elektroniikkatie 13 90590, Oulu, Finland iikka.eklund at qt.io http://qt.io [http://s3-eu-west-1.amazonaws.com/qt-files/logos/qt_logo_with_text_green_rgb_400x141.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_facebook.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_twitter.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_linkedin.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_googleplus.png] [http://s3-eu-west-1.amazonaws.com/qt-files/logos/SoMe/qt_youtube.png] ________________________________ From: Development on behalf of Robert Löhning Sent: Wednesday, April 4, 2018 3:44:38 PM To: development at qt-project.org Subject: Re: [Development] To improve UX of the online installer Hi everybody, could (C) be improved by just swapping the order in the tree? Now we have something like: - Qt 5.10.1 + MSVC 2015 + MSVC 2017 + MinGW + Android - Qt 5.9.4 + MSVC 2015 + MSVC 2017 + MinGW + Android Instead this could be: - Qt for MSVC 2017 (partially checked if toolchain found) + Qt 5.10.1 (newest version checked by default) + Qt 5.9.4 (older versions unchecked by default) - Qt for MSVC 2015 (unchecked if toolchain not found) + Qt 5.10.1 + Qt 5.9.4 - Qt for MinGW (partially checked if no other toolchain found) + Qt 5.10.1 + Qt 5.9.4 - Tools + MinGW (checked if no other toolchain found) Pros: - Easier to uncheck all packages for a specific toolchain - Easier to select various Qt versions for a specific toolchain - Newbies who know their preferred toolchain find it more easily Cons: - Harder to install the same Qt version for various toolchains Does this make sense? Cheers, Robert Am 03.04.2018 um 11:27 schrieb Tino Pyssysalo: > Thanks for your valuable comments and feedback. Please find my comments online > >> (A) Downloading metadata is very time-consuming. > > We have recognized the problem as well and considered several options to solve this issue https://bugreports.qt.io/browse/QTIFW-975. You have excellent points about how to group the repositories. We will take those into account when we plan metadata downloading further. Downloading less metadata, would make the whole download process less vulnerable to network errors. There have been discussions around a retry/resume button and we will evaluate its need after we have evaluated the effect of repository grouping on download time. Obviously, you other suggestions will be considered as well. > >> (B) The automatic mirror selection algorithm doesn't always pick the best mirror. > > Adding a select/deselect all button in the repositories view or allowing user to choose mirrors, should be rather easy to do. We will consider these. > >> (C) (New users) It's not clear how to choose what to install. > > There has been quite a lot of effort in planning and even implementing different approaches to tackle this. Simple default installation would be easy for newbies, but deciding what the default actually means, is challenging. User may have several toolchains installed and it's difficult to decide in the first installation, for which toolchain the user wants to install Qt libraries. This could be asked separately, but in the end the user would have the same component tree view anyway. > > To minimise the number of installable components in a Qt version, we have considered removing the checkbox, so that the user is forced to open Qt X.X node and choose components explicitly. However, we would lose the 'partially checked' feature, used by many. We could maybe implement something that the "Qt 5.9.4" node is not selectable but would still show the 'partially checked' mark. > > Showing additional screens before the component view, would move the complexity of component selection from the installer tree view to some screens. We have also received some feedback that the number of screens is already too high. So, we have been considering simplifying the views https://bugreports.qt.io/browse/QTBUG-62671 by using different categories/groups, which define the visible components to the user. This should simplify the first-time installation experience. > > Someone may want to install Qt Creator only, but giving a warning, if now Qt target is chosen is a good idea. > > --- > Tino Pyssysalo > Senior Manager > Product management > > The Qt Company > --- > > > On 03/04/2018, 3.14, "Development on behalf of Sze Howe Koh" wrote: > > 3 broad issues impede new users who want to start using Qt and > frustrate old users who want to update Qt: > > (A) Downloading metadata is very time-consuming. > (B) The automatic mirror selection algorithm doesn't always pick > the best mirror. > (C) (New users) It's not clear how to choose what to install. > > > ====================================== > Factors that contribute to (A) include: > > * The metadata downloader opens lots of short-duration TCP > connections. Wireshark revealed 2391 HTTP GET requests from > 77.86.229.90 (download.qt.io) on Windows. This process is less painful > on Linux (1205 GETs -- almost half of Windows') as there are fewer > compilers/platforms. > > > * Downloading many small files is very inefficient compared to > downloading a few large files. While GET-ting metadata from > download.qt.io, my network traffic crawls at ~10 KiB/s (yes, ten > kibibytes). After this, the actual binaries download from my > designated mirror at ~1 MiB/s, which shows that metadata downloader > doesn't make good use of available bandwidth. I'm in Australia. > > > * MaintenanceTool downloads metadata too frequently (QTIFW-975). > > > * If the metadata download fails halfway (e.g. one file times out), > the whole process needs to start from scratch. There is no > retry/resume. This makes the online installer nigh unusable if the > user's connection to download.qt.io is flaky: > https://forum.qt.io/post/450076 > > > * Currently, there is a way to manually avoid downloading unwanted > metadata: Deselecting the unwanted Temporary Repositories. However, > all 91 Repositories must be unchecked one-by-one, and this process > must be repeated each time MaintenanceTool is restarted: > https://forum.qt.io/post/450076 > > > ====================================== > Evidence for (B) include: > > * Geographical proximity does not imply mirror quality. E.g. a user > from China finds Chinese mirrors too slow, and opts for non-Chinese > mirrors instead: > http://lists.qt-project.org/pipermail/interest/2013-December/010336.html > > > * The algorithm doesn't pick the closest mirror anyway. E.g. a user > from Israel was given a Japanese mirror instead of a European mirror: > https://forum.qt.io/topic/87221/ > > > ====================================== > Examples of (C) include: > > * Some users don't realize there are multiple kits per Qt version. > They select "Qt 5.9.4" and then wonder why Qt is huge (35 GB): > https://forum.qt.io/topic/87608/windows-install-download-size > > > * Some users don't realize Qt Creator != Qt. They install Qt Creator > without Qt and end up unable to build anything: > https://forum.qt.io/topic/84198/no-valid-kits-found > > > * Some users don't realize they need to install a compiler separately. > They also end up unable to build anything: > https://forum.qt.io/topic/79532/msvc2015-64bit-compiler-kit-installation-requirements > > > ====================================== > Ideas for improvement (some render others unnecessary): > > 1. Amalgamate and compress all metadata into one file (or at least one > file per "group"). > > 2. Cache metadata locally and use a hash to identify them; avoid > re-downloading metadata that's already available (Mitch Curtis > suggested this at QTIFW-975) > > 3. Avoid downloading metadata for archived/advanced packages by > default (Iikka Eklund said this is planned in QTIFW-975) > > 4a. Remember the which Repositories the user has deselected before, > and ignore them for future sessions. > > 4b. Let the user choose broad "groups" that they are interested in, > and remember this choice. For example, there is no point getting > metadata for Android/UWP packages or showing these packages in the > "Selection Tree" if I'm only interested in Desktop development. > > 5. Add a "Select/Deselect All" button to the Repositories page. > > 6. Allow retry/resume if the metadata download fails halfway. > > 7. Allow users to manually pick a mirror for binary download. > > 8a. Before the user is asked to "Select the components to install", > show a short page that to explain the difference between Qt and Qt > Creator and explain that a compiler must be installed separately > unless MinGW is used. > > 8b. Before the user is asked to "Select the components to install", > have a small wizard to ask a new user some questions -- Which > version(s): Latest version, LTS version, or older version? Which > target platforms? Which compiler? Or do they not care/know and want us > to suggest a good default? Use the answers to pre-fill the "Selection > Tree" and remind the user to download an external compiler if > necessary. > > 9. If no Qt version is selected (or if too many are selected), pop-up > a confirmation dialog before installing. > > 10. Expand the documentation at http://doc.qt.io/qt-5/gettingstarted.html > > > Since (3) is already being planned, please consider (4) which is a > generalization of (3). > > It would be fantastic to see a holistic approach that addresses (A) + > (B) + (C). For example, (8b) helps the user make the right selection > at the first try. At the same time, users' answers in (8b) feed into > (4b) to download fewer metadata files and trim the "Selection Tree". > This is further sped up by (1) + (2): Each "group" has its own > amalgamated metadata file, and these files are cached locally to avoid > re-downloading in the future. Once the selection is complete, (7) > ensures that the use can get binaries in a timely manner even if the > auto-selected mirror is no good. > > > Regards, > Sze-Howe _______________________________________________ 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 tony.sarajarvi at qt.io Fri Apr 6 08:35:53 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Fri, 6 Apr 2018 06:35:53 +0000 Subject: [Development] Maintenance in network aprox between the 25th and 27th of April Message-ID: Hi We are going to perform maintenance on our switches which will probably cause interruptions in all Qt services not located in AWS. New switches are estimated to arrive so that the work can begin approximately on the 25th. We'll inform you with more precise data as we get it. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.blasche at qt.io Fri Apr 6 13:07:18 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Fri, 6 Apr 2018 11:07:18 +0000 Subject: [Development] Nominating people from our release team for approver rights In-Reply-To: <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> References: , <1754363.8F4aoW0erl@frederik-thinkcentre-m93p> Message-ID: Congratulations to Aapo. Jira and Gerrit rights have been adjusted. -- Alex ________________________________________ From: Development on behalf of Frederik Gladhorn Sent: Friday, 16 March 2018 12:44:23 PM To: development at qt-project.org; Aapo Keskimölö Subject: Re: [Development] Nominating people from our release team for approver rights Hello all, in 2014 we agreed to make the release team in The Qt Company approvers for the Qt Project to enable them to work efficiently. Since then we had Aapo join the team. Aapo is working hard on improving Coin and getting all our changes through CI smoothly. Sadly he doesn't have many commits in the public repos. Since he's been doing a lot of good work on Coin and the QA side of things, helping the release team, I'd like to propose him as approver. Cheers, Frederik On torsdag 9. januar 2014 15.18.56 CET Knoll Lars wrote: > Hi, > > I’d like to nominate a couple of people from the release team for approver > rights. They’ve been working for the last 14 month with our release and CI > infrastructure, and even though many of their contributions are not as > directly visible (and often aren’t visible in gerrit), they are highly > important to the project. I believe they all know the approval process > well, and them being Approvers will also make it easier to get releases > out in the future. > > The people I’d like to nominate are: > > Tony Sarajärvi > Simo Fält > Matti Paaso > Akseli Salovaara > Jani Heikkinen > > Cheers, > Lars > > > _______________________________________________ > 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 mitch.curtis at qt.io Fri Apr 6 14:47:05 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Fri, 6 Apr 2018 12:47:05 +0000 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> Message-ID: Hi. We think this would be best in a repo outside of qtquickcontrols2.git. The process for creating a playground repo is documented here: http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. Have you discussed this project with the Sailfish devs, by the way? Perhaps they would be interested in integrating your efforts upstream. One potential problem I see is that it seems that the source code is not public: https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/ The closest thing is this repo, which doesn’t seem to be complete: https://github.com/dm8tbr/sailfishsilica-qt5 How do you plan on implementing the style in light of this? Speaking for myself: I would be happy to answer any questions you may have with regards to implementing a Controls 2 style, but I don’t think I can put aside enough time to be a mentor for this. Cheers. From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] Sent: Tuesday, 3 April 2018 2:14 PM To: Aleksey Kontsevich Cc: Mitch Curtis ; development at qt-project.org Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style Hi, Aleksey Kontsevich! Thank you for your support, I do agree that Sailfish OS is receiving a huge contribution from Russian speaking developers and focusing on other local markets too. There's also related AsteroidOS community about smartwatches. They have a demo [1] Talking about popularity: from my point of view, while Microsoft is providing their Metro unified look for desktop and Intel-based tablets (and Xbox) for example, looks like they do not have any plans for new mobile devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I do not want to mislead anyone. Mitch Curtis, thank you for your feedback sincerely. I do understand your skepticism about yet another controls in mainline to support. (but I do not share this personally :) I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach (to play on my Arch Linux system). Dependency from some private APIs looks tricky for me at first glance. I'm trying to sort out. I'm not against providing silica style as some custom repo, the result I want to get is open source solution to run Qt application in my personal environment with native Silica look and feel. Will be happy to get any hints about basic repo draft in that case (should I look at Kirigami approach?) Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money support, I love Silica style, using Sailfish OS for several years and can't stand that no one is willing to port it to modern QQC2 approach :) I guess it could radically change skepticism about qt quick controls approach in general from ios and android developers. [1]: https://www.youtube.com/watch?v=Rd86KTs2Les [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich >: Hi all, my 2 cents here: >The controls look nice, but my concern is how relevant the Silica style is these days (in the context of how many people are developing apps for the >Sailfish OS). Sailfish OS become VERY popular in Russia and in Latin America, and for people who wants their data and communication be secure. Market in Russia growing very fast, Sailfish OS devices are hits of sales, leading universities created courses for Sailfish OS, government certified it for corporate and government use and since 2019 all mobile applications from national software list (government and corporate use) should work in Sailfish OS (according to import replacing law all applications should be Russian-native and secure). -- Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 03.04.2018, 13:13, "Mitch Curtis" >: > Hi Alexey. > > The controls look nice, but my concern is how relevant the Silica style is these days (in the context of how many people are developing apps for the Sailfish OS). > > For each style we currently have, I would justify their inclusion into qtquickcontrols2.git for the following reasons: > > Default - extremely high performance at the cost of a very basic appearance. Tries to be neutral in terms of looks. > > Fusion - bridges the gap in terms of Desktop styling. An additional/more specific point that I think it is important here is that the controls are more compact (smaller) than any other pre-built style we offer (the Material style has a dense variant now, but that’s still larger if I recall correctly). > > Imagine - puts power in the hands of designers, frees up time for developers. > > Material - very relevant in terms of Android market share. Looks really nice; a good candidate for “non-native” cross-platform apps. > > Universal - relevant in terms of Windows market share. > > As mentioned, I do think the Silica controls look nice, but that’s the only justification I could think of for including them in qtquickcontrols2.git. For each new style we add, the maintenance cost increases, so this is something that we need to consider. > > What is your opinion on this? > > Cheers. > > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] > Sent: Friday, 23 March 2018 8:49 PM > To: Mitch Curtis > > Cc: development at qt-project.org > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style > > Thank you Mitch for the feedback! > I've also tried to record current controls on a real device: https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) > > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >: >> Silica cheat sheet: >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >> Theme cheat sheet: >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >> Icon reference: >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >> code example: >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >> >> Youtube video with timestamp for platform-specific PulleyMenu element example: https://youtu.be/jByW7UNmbxU?t=11m38s >> >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis >: >>> Hello. >>> >>> Are there any screenshots of it? I read that entire page and the Silica docs but couldn’t see anything. >>> >>> Cheers. >>> >>> From: Development [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of Alexey Andreyev >>> Sent: Friday, 23 March 2018 5:39 PM >>> To: development at qt-project.org >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style >>> >>> Hello! >>> My name is Alexey, what do you think about Silica Style for QQC2 as a gsoc project? >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>> >>> and want to create a proposal. > > , > > _______________________________________________ > 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 aapo.keskimolo at qt.io Fri Apr 6 15:07:47 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Fri, 6 Apr 2018 13:07:47 +0000 Subject: [Development] Nominating people from our release team for approver rights In-Reply-To: References: , <1754363.8F4aoW0erl@frederik-thinkcentre-m93p>, Message-ID: <9D881469-710A-4E4E-989B-AD4DE8589943@qt.io> This is really great news! I will use these rights with pristine care. Thank you so much for the honors:) Kind regards/Ystävällisin terveisin, Aapo Keskimölö > On 6 Apr 2018, at 14.07, Alex Blasche wrote: > > Congratulations to Aapo. Jira and Gerrit rights have been adjusted. > > -- > Alex > > ________________________________________ > From: Development on behalf of Frederik Gladhorn > Sent: Friday, 16 March 2018 12:44:23 PM > To: development at qt-project.org; Aapo Keskimölö > Subject: Re: [Development] Nominating people from our release team for approver rights > > Hello all, > > in 2014 we agreed to make the release team in The Qt Company approvers for the > Qt Project to enable them to work efficiently. > > Since then we had Aapo join the team. Aapo is working hard on improving Coin > and getting all our changes through CI smoothly. Sadly he doesn't have many > commits in the public repos. > > Since he's been doing a lot of good work on Coin and the QA side of things, > helping the release team, I'd like to propose him as approver. > > Cheers, > Frederik > > > >> On torsdag 9. januar 2014 15.18.56 CET Knoll Lars wrote: >> Hi, >> >> I’d like to nominate a couple of people from the release team for approver >> rights. They’ve been working for the last 14 month with our release and CI >> infrastructure, and even though many of their contributions are not as >> directly visible (and often aren’t visible in gerrit), they are highly >> important to the project. I believe they all know the approval process >> well, and them being Approvers will also make it easier to get releases >> out in the future. >> >> The people I’d like to nominate are: >> >> Tony Sarajärvi >> Simo Fält >> Matti Paaso >> Akseli Salovaara >> Jani Heikkinen >> >> Cheers, >> Lars >> >> >> _______________________________________________ >> 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 yetanotherandreyev at gmail.com Fri Apr 6 15:11:32 2018 From: yetanotherandreyev at gmail.com (Alexey Andreyev) Date: Fri, 6 Apr 2018 16:11:32 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> Message-ID: Got it, thank you, Mitch! :) Yes, I have contacted Jolla devs, got answer: > Providing Sailfish support for Qt Quick Controls 2 would definitely be valuable. Sailfish OS cannot build app ecosystem alone, and improving the cross-platform story would help us getting Qt app contributions from other platforms, and help 3rd party developers target multiple platforms like Android and iOS with the same code base. > You are free to use what license you choose, but I would recommend something permissive like BSD3 or LGPL2, which we also use in Sailfish OS open source side Silica Componets source is not public, yes :( But I've got device where I have all up-to-date qml files and I'm it as hint. I've also played to run armv7h binaries from device repos (rpm packages) on archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage address patching for .so lib, it staring and not crashing but asking for more deps yet (like image resources deps, so work in progress) Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot too, he recently created: https://git.merproject.org/Kaffeine/qtsilicastyle So I'm going to contribute there. For now current state is: 5.10 private API chaged compating to 5.9: https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2 Alexander is testing with 5.9 LTS on SailfishOS and me with archlinuxarm 5.10 so I'm thinking now how to provide better compabilty for both :) looks like #ifdef approarch is not helping yet, should investigate more time 2018-04-06 15:47 GMT+03:00 Mitch Curtis : > Hi. > > > > We think this would be best in a repo outside of qtquickcontrols2.git. > > > > The process for creating a playground repo is documented here: > > > > http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt# > Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. > > > > Have you discussed this project with the Sailfish devs, by the way? > Perhaps they would be interested in integrating your efforts upstream. > > > > One potential problem I see is that it seems that the source code is not > public: > > > > https://together.jolla.com/question/6780/request- > sourcecode-for-silica-core-components/ > > > > The closest thing is this repo, which doesn’t seem to be complete: > > > > https://github.com/dm8tbr/sailfishsilica-qt5 > > > > How do you plan on implementing the style in light of this? > > > > Speaking for myself: I would be happy to answer any questions you may have > with regards to implementing a Controls 2 style, but I don’t think I can > put aside enough time to be a mentor for this. > > > > Cheers. > > > > *From:* Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] > *Sent:* Tuesday, 3 April 2018 2:14 PM > *To:* Aleksey Kontsevich > *Cc:* Mitch Curtis ; development at qt-project.org > > *Subject:* Re: [Development] [Google Summer of Code] [Project Ideas] Qt > Quick Controls 2 Sailfish Silica Style > > > > Hi, Aleksey Kontsevich! Thank you for your support, I do agree that > Sailfish OS is receiving a huge contribution from Russian speaking > developers and focusing on other local markets too. There's also related > AsteroidOS community about smartwatches. They have a demo [1] > > > > Talking about popularity: from my point of view, while Microsoft is > providing their Metro unified look for desktop and Intel-based tablets (and > Xbox) for example, looks like they do not have any plans for new mobile > devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with > GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, > I do not want to mislead anyone. > > > > Mitch Curtis, thank you for your feedback sincerely. I do understand your > skepticism about yet another controls in mainline to support. (but I do not > share this personally :) > > I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach > (to play on my Arch Linux system). Dependency from some private APIs looks > tricky for me at first glance. I'm trying to sort out. I'm not against > providing silica style as some custom repo, the result I want to get is > open source solution to run Qt application in my personal environment with > native Silica look and feel. Will be happy to get any hints about basic > repo draft in that case (should I look at Kirigami approach?) > > > > Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money > support, I love Silica style, using Sailfish OS for several years and can't > stand that no one is willing to port it to modern QQC2 approach :) I guess > it could radically change skepticism about qt quick controls approach in > general from ios and android developers. > > > > [1]: https://www.youtube.com/watch?v=Rd86KTs2Les > > [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris > > > > 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : > > Hi all, my 2 cents here: > > >The controls look nice, but my concern is how relevant the Silica style > is these days (in the context of how many people are developing apps for the > >Sailfish OS). > > Sailfish OS become VERY popular in Russia and in Latin America, and for > people who wants their data and communication be secure. Market in Russia > growing very fast, Sailfish OS devices are hits of sales, leading > universities created courses for Sailfish OS, government certified > it for corporate and government use and since 2019 all mobile applications > from national software list (government and corporate use) should work in > Sailfish OS (according to import replacing law all applications should be > Russian-native and secure). > > -- > Best regards, > Aleksey > Linked in https://www.linkedin.com/in/alekseykontsevich > > > > 03.04.2018, 13:13, "Mitch Curtis" : > > > Hi Alexey. > > > > The controls look nice, but my concern is how relevant the Silica style > is these days (in the context of how many people are developing apps for > the Sailfish OS). > > > > For each style we currently have, I would justify their inclusion into > qtquickcontrols2.git for the following reasons: > > > > Default - extremely high performance at the cost of a very basic > appearance. Tries to be neutral in terms of looks. > > > > Fusion - bridges the gap in terms of Desktop styling. An additional/more > specific point that I think it is important here is that the controls are > more compact (smaller) than any other pre-built style we offer (the > Material style has a dense variant now, but that’s still larger if I recall > correctly). > > > > Imagine - puts power in the hands of designers, frees up time for > developers. > > > > Material - very relevant in terms of Android market share. Looks really > nice; a good candidate for “non-native” cross-platform apps. > > > > Universal - relevant in terms of Windows market share. > > > > As mentioned, I do think the Silica controls look nice, but that’s the > only justification I could think of for including them in > qtquickcontrols2.git. For each new style we add, the maintenance cost > increases, so this is something that we need to consider. > > > > What is your opinion on this? > > > > Cheers. > > > > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] > > Sent: Friday, 23 March 2018 8:49 PM > > To: Mitch Curtis > > Cc: development at qt-project.org > > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt > Quick Controls 2 Sailfish Silica Style > > > > Thank you Mitch for the feedback! > > I've also tried to record current controls on a real device: > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) > > > > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >: > >> Silica cheat sheet: > >> https://sailfishos.org/wp-content/uploads/2016/06/ > component_cheatsheet.png > >> Theme cheat sheet: > >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png > >> Icon reference: > >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png > >> code example: > >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 > >> > >> Youtube video with timestamp for platform-specific PulleyMenu element > example: https://youtu.be/jByW7UNmbxU?t=11m38s > >> > >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : > >>> Hello. > >>> > >>> Are there any screenshots of it? I read that entire page and the > Silica docs but couldn’t see anything. > >>> > >>> Cheers. > >>> > >>> From: Development [mailto:development-bounces+mitch.curtis= > qt.io at qt-project.org] On Behalf Of Alexey Andreyev > >>> Sent: Friday, 23 March 2018 5:39 PM > >>> To: development at qt-project.org > >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt > Quick Controls 2 Sailfish Silica Style > >>> > >>> Hello! > >>> My name is Alexey, what do you think about Silica Style for QQC2 as a > gsoc project? > >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ > >>> > >>> and want to create a proposal. > > > > > , > > > > _______________________________________________ > > 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 akulichalexander at gmail.com Fri Apr 6 17:39:58 2018 From: akulichalexander at gmail.com (Alexander Akulich) Date: Fri, 6 Apr 2018 18:39:58 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> Message-ID: Hi all, I highly doubt that it can be done as a part of GSoC and I don't see any point in moving this to QtProject as we don't have Sailfish OS platform upstreamed. We just need this style to make QQC2 applications look native on Sailfish OS. I think that we'll have to rely on closed-yet components and the style is not going to look nice with mocks. That said, I see a number of issues and I hope that we'll discuss and agree on some changes to the QQC2 API: 1) I would like to propose ComboDelegate — a pair of ComboBox and Label, combined in a platform-specific way (similar to CheckDelegate and RadioDelegate). 2) We also need a delegate to display a label and an associated value. It is named "DetailItem" in Silica, but I would agree to go with a name like ValueDelegate. 3) Yet another point is that we need to properly style delegate descriptions, so I want to propose "description" property at least for Combo, Radio and Switch delegates (we even don't have a 'buddy' property here, though it still would be very hacky to go in this way). Probably it makes sense to start another thread to discuss Qt Quick Controls 2 API, but I need at least three weeks to think and experiment with what we have right now. :-) My work is available at https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt 5.9 and 5.10), but I don't think that it can be interesting for anyone in its current shape. On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev wrote: > Got it, thank you, Mitch! :) > > Yes, I have contacted Jolla devs, got answer: > >> Providing Sailfish support for Qt Quick Controls 2 would definitely be >> valuable. Sailfish OS cannot build app ecosystem alone, and improving the >> cross-platform story would help us getting Qt app contributions from other >> platforms, and help 3rd party developers target multiple platforms like >> Android and iOS with the same code base. > >> You are free to use what license you choose, but I would recommend >> something permissive like BSD3 or LGPL2, which we also use in Sailfish OS >> open source side > > Silica Componets source is not public, yes :( But I've got device where I > have all up-to-date qml files and I'm it as hint. > > I've also played to run armv7h binaries from device repos (rpm packages) on > archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage > address patching for .so lib, it staring and not crashing but asking for > more deps yet (like image resources deps, so work in progress) > > Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot > too, he recently created: > > https://git.merproject.org/Kaffeine/qtsilicastyle > > So I'm going to contribute there. > > For now current state is: > > 5.10 private API chaged compating to 5.9: > https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2 > > Alexander is testing with 5.9 LTS on SailfishOS > and me with archlinuxarm 5.10 > so I'm thinking now how to provide better compabilty for both :) > > looks like #ifdef approarch is not helping yet, should investigate more time > > > 2018-04-06 15:47 GMT+03:00 Mitch Curtis : >> >> Hi. >> >> >> >> We think this would be best in a repo outside of qtquickcontrols2.git. >> >> >> >> The process for creating a playground repo is documented here: >> >> >> >> >> http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. >> >> >> >> Have you discussed this project with the Sailfish devs, by the way? >> Perhaps they would be interested in integrating your efforts upstream. >> >> >> >> One potential problem I see is that it seems that the source code is not >> public: >> >> >> >> >> https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/ >> >> >> >> The closest thing is this repo, which doesn’t seem to be complete: >> >> >> >> https://github.com/dm8tbr/sailfishsilica-qt5 >> >> >> >> How do you plan on implementing the style in light of this? >> >> >> >> Speaking for myself: I would be happy to answer any questions you may have >> with regards to implementing a Controls 2 style, but I don’t think I can put >> aside enough time to be a mentor for this. >> >> >> >> Cheers. >> >> >> >> From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >> Sent: Tuesday, 3 April 2018 2:14 PM >> To: Aleksey Kontsevich >> Cc: Mitch Curtis ; development at qt-project.org >> >> >> Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >> Quick Controls 2 Sailfish Silica Style >> >> >> >> Hi, Aleksey Kontsevich! Thank you for your support, I do agree that >> Sailfish OS is receiving a huge contribution from Russian speaking >> developers and focusing on other local markets too. There's also related >> AsteroidOS community about smartwatches. They have a demo [1] >> >> >> >> Talking about popularity: from my point of view, while Microsoft is >> providing their Metro unified look for desktop and Intel-based tablets (and >> Xbox) for example, looks like they do not have any plans for new mobile >> devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with >> GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I >> do not want to mislead anyone. >> >> >> >> Mitch Curtis, thank you for your feedback sincerely. I do understand your >> skepticism about yet another controls in mainline to support. (but I do not >> share this personally :) >> >> I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach >> (to play on my Arch Linux system). Dependency from some private APIs looks >> tricky for me at first glance. I'm trying to sort out. I'm not against >> providing silica style as some custom repo, the result I want to get is open >> source solution to run Qt application in my personal environment with native >> Silica look and feel. Will be happy to get any hints about basic repo draft >> in that case (should I look at Kirigami approach?) >> >> >> >> Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money >> support, I love Silica style, using Sailfish OS for several years and can't >> stand that no one is willing to port it to modern QQC2 approach :) I guess >> it could radically change skepticism about qt quick controls approach in >> general from ios and android developers. >> >> >> >> [1]: https://www.youtube.com/watch?v=Rd86KTs2Les >> >> [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris >> >> >> >> 2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : >> >> Hi all, my 2 cents here: >> >> >The controls look nice, but my concern is how relevant the Silica style >> > is these days (in the context of how many people are developing apps for the >> >Sailfish OS). >> >> Sailfish OS become VERY popular in Russia and in Latin America, and for >> people who wants their data and communication be secure. Market in Russia >> growing very fast, Sailfish OS devices are hits of sales, leading >> universities created courses for Sailfish OS, government certified >> it for corporate and government use and since 2019 all mobile applications >> from national software list (government and corporate use) should work in >> Sailfish OS (according to import replacing law all applications should be >> Russian-native and secure). >> >> -- >> Best regards, >> Aleksey >> Linked in https://www.linkedin.com/in/alekseykontsevich >> >> >> >> 03.04.2018, 13:13, "Mitch Curtis" : >> >> > Hi Alexey. >> > >> > The controls look nice, but my concern is how relevant the Silica style >> > is these days (in the context of how many people are developing apps for the >> > Sailfish OS). >> > >> > For each style we currently have, I would justify their inclusion into >> > qtquickcontrols2.git for the following reasons: >> > >> > Default - extremely high performance at the cost of a very basic >> > appearance. Tries to be neutral in terms of looks. >> > >> > Fusion - bridges the gap in terms of Desktop styling. An additional/more >> > specific point that I think it is important here is that the controls are >> > more compact (smaller) than any other pre-built style we offer (the Material >> > style has a dense variant now, but that’s still larger if I recall >> > correctly). >> > >> > Imagine - puts power in the hands of designers, frees up time for >> > developers. >> > >> > Material - very relevant in terms of Android market share. Looks really >> > nice; a good candidate for “non-native” cross-platform apps. >> > >> > Universal - relevant in terms of Windows market share. >> > >> > As mentioned, I do think the Silica controls look nice, but that’s the >> > only justification I could think of for including them in >> > qtquickcontrols2.git. For each new style we add, the maintenance cost >> > increases, so this is something that we need to consider. >> > >> > What is your opinion on this? >> > >> > Cheers. >> > >> > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >> > Sent: Friday, 23 March 2018 8:49 PM >> > To: Mitch Curtis >> > Cc: development at qt-project.org >> > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >> > Quick Controls 2 Sailfish Silica Style >> > >> > Thank you Mitch for the feedback! >> > I've also tried to record current controls on a real device: >> > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >> > >> > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >> > : >> >> Silica cheat sheet: >> >> >> >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >> >> Theme cheat sheet: >> >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >> >> Icon reference: >> >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >> >> code example: >> >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >> >> >> >> Youtube video with timestamp for platform-specific PulleyMenu element >> >> example: https://youtu.be/jByW7UNmbxU?t=11m38s >> >> >> >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >> >>> Hello. >> >>> >> >>> Are there any screenshots of it? I read that entire page and the >> >>> Silica docs but couldn’t see anything. >> >>> >> >>> Cheers. >> >>> >> >>> From: Development >> >>> [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of >> >>> Alexey Andreyev >> >>> Sent: Friday, 23 March 2018 5:39 PM >> >>> To: development at qt-project.org >> >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt >> >>> Quick Controls 2 Sailfish Silica Style >> >>> >> >>> Hello! >> >>> My name is Alexey, what do you think about Silica Style for QQC2 as a >> >>> gsoc project? >> >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >> >>> >> >>> and want to create a proposal. >> > >> >> > , >> > >> > _______________________________________________ >> > 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 tantrido at ya.ru Fri Apr 6 20:18:27 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Fri, 06 Apr 2018 21:18:27 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> Message-ID: <11452561523038707@web14g.yandex.ru> Hi all, Only one argument. >I don't see any point in moving this to QtProject as we don't have Sailfish OS platform upstreamed. Just let's not miss the moment when it become upstreamed. :-) Things move very fast recent days. Rostelecom and Russian universities make much effort to promote and advance it. Since it is the only mobile OS certified by FSS, and only approved by government - it will be the primary OS applications will be developed for in government and corporate sectors where security is a corner stone. It is sales hit in Russia currently among civilian users (https://buyon.ru/1311520/inoi-r7/) and become upstreamed very fast with and like Russia become upstreamed already and become much more developed in nearest future. Or You mean upstreamed in QtProject? :-) Let's make it upstream then! :-) Agree with the rest. --  Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 06.04.2018, 18:40, "Alexander Akulich" : > Hi all, > > I highly doubt that it can be done as a part of GSoC and I don't see > any point in moving this to QtProject as we don't have Sailfish OS > platform upstreamed. We just need this style to make QQC2 applications > look native on Sailfish OS. I think that we'll have to rely on > closed-yet components and the style is not going to look nice with > mocks. > > That said, I see a number of issues and I hope that we'll discuss and > agree on some changes to the QQC2 API: > 1) I would like to propose ComboDelegate — a pair of ComboBox and > Label, combined in a platform-specific way (similar to CheckDelegate > and RadioDelegate). > 2) We also need a delegate to display a label and an associated value. > It is named "DetailItem" in Silica, but I would agree to go with a > name like ValueDelegate. > 3) Yet another point is that we need to properly style delegate > descriptions, so I want to propose "description" property at least for > Combo, Radio and Switch delegates (we even don't have a 'buddy' > property here, though it still would be very hacky to go in this way). > > Probably it makes sense to start another thread to discuss Qt Quick > Controls 2 API, but I need at least three weeks to think and > experiment with what we have right now. :-) > > My work is available at > https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt > 5.9 and 5.10), but I don't think that it can be interesting for anyone > in its current shape. > > On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev > wrote: >>  Got it, thank you, Mitch! :) >> >>  Yes, I have contacted Jolla devs, got answer: >> >>>   Providing Sailfish support for Qt Quick Controls 2 would definitely be >>>  valuable. Sailfish OS cannot build app ecosystem alone, and improving the >>>  cross-platform story would help us getting Qt app contributions from other >>>  platforms, and help 3rd party developers target multiple platforms like >>>  Android and iOS with the same code base. >> >>>  You are free to use what license you choose, but I would recommend >>>  something permissive like BSD3 or LGPL2, which we also use in Sailfish OS >>>  open source side >> >>  Silica Componets source is not public, yes :( But I've got device where I >>  have all up-to-date qml files and I'm it as hint. >> >>  I've also played to run armv7h binaries from device repos (rpm packages) on >>  archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage >>  address patching for .so lib, it staring and not crashing but asking for >>  more deps yet (like image resources deps, so work in progress) >> >>  Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot >>  too, he recently created: >> >>  https://git.merproject.org/Kaffeine/qtsilicastyle >> >>  So I'm going to contribute there. >> >>  For now current state is: >> >>  5.10 private API chaged compating to 5.9: >>  https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2 >> >>  Alexander is testing with 5.9 LTS on SailfishOS >>  and me with archlinuxarm 5.10 >>  so I'm thinking now how to provide better compabilty for both :) >> >>  looks like #ifdef approarch is not helping yet, should investigate more time >> >>  2018-04-06 15:47 GMT+03:00 Mitch Curtis : >> >>>  Hi. >>> >>>  We think this would be best in a repo outside of qtquickcontrols2.git. >>> >>>  The process for creating a playground repo is documented here: >>> >>>  http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. >>> >>>  Have you discussed this project with the Sailfish devs, by the way? >>>  Perhaps they would be interested in integrating your efforts upstream. >>> >>>  One potential problem I see is that it seems that the source code is not >>>  public: >>> >>>  https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/ >>> >>>  The closest thing is this repo, which doesn’t seem to be complete: >>> >>>  https://github.com/dm8tbr/sailfishsilica-qt5 >>> >>>  How do you plan on implementing the style in light of this? >>> >>>  Speaking for myself: I would be happy to answer any questions you may have >>>  with regards to implementing a Controls 2 style, but I don’t think I can put >>>  aside enough time to be a mentor for this. >>> >>>  Cheers. >>> >>>  From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>  Sent: Tuesday, 3 April 2018 2:14 PM >>>  To: Aleksey Kontsevich >>>  Cc: Mitch Curtis ; development at qt-project.org >>> >>>  Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>  Quick Controls 2 Sailfish Silica Style >>> >>>  Hi, Aleksey Kontsevich! Thank you for your support, I do agree that >>>  Sailfish OS is receiving a huge contribution from Russian speaking >>>  developers and focusing on other local markets too. There's also related >>>  AsteroidOS community about smartwatches. They have a demo [1] >>> >>>  Talking about popularity: from my point of view, while Microsoft is >>>  providing their Metro unified look for desktop and Intel-based tablets (and >>>  Xbox) for example, looks like they do not have any plans for new mobile >>>  devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with >>>  GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I >>>  do not want to mislead anyone. >>> >>>  Mitch Curtis, thank you for your feedback sincerely. I do understand your >>>  skepticism about yet another controls in mainline to support. (but I do not >>>  share this personally :) >>> >>>  I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach >>>  (to play on my Arch Linux system). Dependency from some private APIs looks >>>  tricky for me at first glance. I'm trying to sort out. I'm not against >>>  providing silica style as some custom repo, the result I want to get is open >>>  source solution to run Qt application in my personal environment with native >>>  Silica look and feel. Will be happy to get any hints about basic repo draft >>>  in that case (should I look at Kirigami approach?) >>> >>>  Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money >>>  support, I love Silica style, using Sailfish OS for several years and can't >>>  stand that no one is willing to port it to modern QQC2 approach :) I guess >>>  it could radically change skepticism about qt quick controls approach in >>>  general from ios and android developers. >>> >>>  [1]: https://www.youtube.com/watch?v=Rd86KTs2Les >>> >>>  [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris >>> >>>  2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : >>> >>>  Hi all, my 2 cents here: >>> >>>  >The controls look nice, but my concern is how relevant the Silica style >>>  > is these days (in the context of how many people are developing apps for the >>>  >Sailfish OS). >>> >>>  Sailfish OS become VERY popular in Russia and in Latin America, and for >>>  people who wants their data and communication be secure. Market in Russia >>>  growing very fast, Sailfish OS devices are hits of sales, leading >>>  universities created courses for Sailfish OS, government certified >>>  it for corporate and government use and since 2019 all mobile applications >>>  from national software list (government and corporate use) should work in >>>  Sailfish OS (according to import replacing law all applications should be >>>  Russian-native and secure). >>> >>>  -- >>>  Best regards, >>>  Aleksey >>>  Linked in https://www.linkedin.com/in/alekseykontsevich >>> >>>  03.04.2018, 13:13, "Mitch Curtis" : >>> >>>  > Hi Alexey. >>>  > >>>  > The controls look nice, but my concern is how relevant the Silica style >>>  > is these days (in the context of how many people are developing apps for the >>>  > Sailfish OS). >>>  > >>>  > For each style we currently have, I would justify their inclusion into >>>  > qtquickcontrols2.git for the following reasons: >>>  > >>>  > Default - extremely high performance at the cost of a very basic >>>  > appearance. Tries to be neutral in terms of looks. >>>  > >>>  > Fusion - bridges the gap in terms of Desktop styling. An additional/more >>>  > specific point that I think it is important here is that the controls are >>>  > more compact (smaller) than any other pre-built style we offer (the Material >>>  > style has a dense variant now, but that’s still larger if I recall >>>  > correctly). >>>  > >>>  > Imagine - puts power in the hands of designers, frees up time for >>>  > developers. >>>  > >>>  > Material - very relevant in terms of Android market share. Looks really >>>  > nice; a good candidate for “non-native” cross-platform apps. >>>  > >>>  > Universal - relevant in terms of Windows market share. >>>  > >>>  > As mentioned, I do think the Silica controls look nice, but that’s the >>>  > only justification I could think of for including them in >>>  > qtquickcontrols2.git. For each new style we add, the maintenance cost >>>  > increases, so this is something that we need to consider. >>>  > >>>  > What is your opinion on this? >>>  > >>>  > Cheers. >>>  > >>>  > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>  > Sent: Friday, 23 March 2018 8:49 PM >>>  > To: Mitch Curtis >>>  > Cc: development at qt-project.org >>>  > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>  > Quick Controls 2 Sailfish Silica Style >>>  > >>>  > Thank you Mitch for the feedback! >>>  > I've also tried to record current controls on a real device: >>>  > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >>>  > >>>  > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >>>  > : >>>  >> Silica cheat sheet: >>>  >> >>>  >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >>>  >> Theme cheat sheet: >>>  >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >>>  >> Icon reference: >>>  >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >>>  >> code example: >>>  >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >>>  >> >>>  >> Youtube video with timestamp for platform-specific PulleyMenu element >>>  >> example: https://youtu.be/jByW7UNmbxU?t=11m38s >>>  >> >>>  >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >>>  >>> Hello. >>>  >>> >>>  >>> Are there any screenshots of it? I read that entire page and the >>>  >>> Silica docs but couldn’t see anything. >>>  >>> >>>  >>> Cheers. >>>  >>> >>>  >>> From: Development >>>  >>> [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of >>>  >>> Alexey Andreyev >>>  >>> Sent: Friday, 23 March 2018 5:39 PM >>>  >>> To: development at qt-project.org >>>  >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt >>>  >>> Quick Controls 2 Sailfish Silica Style >>>  >>> >>>  >>> Hello! >>>  >>> My name is Alexey, what do you think about Silica Style for QQC2 as a >>>  >>> gsoc project? >>>  >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>>  >>> >>>  >>> and want to create a proposal. >>>  > >>> >>>  > , >>>  > >>>  > _______________________________________________ >>>  > Development mailing list >>>  > Development at qt-project.org >>>  > http://lists.qt-project.org/mailman/listinfo/development >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From annulen at yandex.ru Fri Apr 6 20:35:12 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Fri, 06 Apr 2018 21:35:12 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: <11452561523038707@web14g.yandex.ru> References: <3659321522751917@web57g.yandex.ru> <11452561523038707@web14g.yandex.ru> Message-ID: <9411731523039712@web51j.yandex.ru> 06.04.2018, 21:18, "Aleksey Kontsevich" : > Hi all, > > Only one argument. > >> I don't see any point in moving this to QtProject as we don't have Sailfish OS platform upstreamed. > > Just let's not miss the moment when it become upstreamed. :-) Things move very fast recent days. Rostelecom and Russian universities make much effort to promote and advance it. Since it is the only mobile OS certified by FSS, and only approved by government - it will be the primary OS applications will be developed for in government and corporate sectors where security is a corner stone. It is sales hit in Russia currently among civilian users (https://buyon.ru/1311520/inoi-r7/) Really? Almost nobody is aware of its existence, even in IT circles, and the only device can be bought in one place. AFAIK it has no presence in mobile shops > and become upstreamed very fast with and like Russia become upstreamed already and become much more developed in nearest future. > > Or You mean upstreamed in QtProject? :-) Let's make it upstream then! :-) > > Agree with the rest. > > -- > Best regards, > Aleksey > Linked in https://www.linkedin.com/in/alekseykontsevich > > 06.04.2018, 18:40, "Alexander Akulich" : >>  Hi all, >> >>  I highly doubt that it can be done as a part of GSoC and I don't see >>  any point in moving this to QtProject as we don't have Sailfish OS >>  platform upstreamed. We just need this style to make QQC2 applications >>  look native on Sailfish OS. I think that we'll have to rely on >>  closed-yet components and the style is not going to look nice with >>  mocks. >> >>  That said, I see a number of issues and I hope that we'll discuss and >>  agree on some changes to the QQC2 API: >>  1) I would like to propose ComboDelegate — a pair of ComboBox and >>  Label, combined in a platform-specific way (similar to CheckDelegate >>  and RadioDelegate). >>  2) We also need a delegate to display a label and an associated value. >>  It is named "DetailItem" in Silica, but I would agree to go with a >>  name like ValueDelegate. >>  3) Yet another point is that we need to properly style delegate >>  descriptions, so I want to propose "description" property at least for >>  Combo, Radio and Switch delegates (we even don't have a 'buddy' >>  property here, though it still would be very hacky to go in this way). >> >>  Probably it makes sense to start another thread to discuss Qt Quick >>  Controls 2 API, but I need at least three weeks to think and >>  experiment with what we have right now. :-) >> >>  My work is available at >>  https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt >>  5.9 and 5.10), but I don't think that it can be interesting for anyone >>  in its current shape. >> >>  On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev >>   wrote: >>>   Got it, thank you, Mitch! :) >>> >>>   Yes, I have contacted Jolla devs, got answer: >>> >>>>    Providing Sailfish support for Qt Quick Controls 2 would definitely be >>>>   valuable. Sailfish OS cannot build app ecosystem alone, and improving the >>>>   cross-platform story would help us getting Qt app contributions from other >>>>   platforms, and help 3rd party developers target multiple platforms like >>>>   Android and iOS with the same code base. >>> >>>>   You are free to use what license you choose, but I would recommend >>>>   something permissive like BSD3 or LGPL2, which we also use in Sailfish OS >>>>   open source side >>> >>>   Silica Componets source is not public, yes :( But I've got device where I >>>   have all up-to-date qml files and I'm it as hint. >>> >>>   I've also played to run armv7h binaries from device repos (rpm packages) on >>>   archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage >>>   address patching for .so lib, it staring and not crashing but asking for >>>   more deps yet (like image resources deps, so work in progress) >>> >>>   Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot >>>   too, he recently created: >>> >>>   https://git.merproject.org/Kaffeine/qtsilicastyle >>> >>>   So I'm going to contribute there. >>> >>>   For now current state is: >>> >>>   5.10 private API chaged compating to 5.9: >>>   https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2 >>> >>>   Alexander is testing with 5.9 LTS on SailfishOS >>>   and me with archlinuxarm 5.10 >>>   so I'm thinking now how to provide better compabilty for both :) >>> >>>   looks like #ifdef approarch is not helping yet, should investigate more time >>> >>>   2018-04-06 15:47 GMT+03:00 Mitch Curtis : >>> >>>>   Hi. >>>> >>>>   We think this would be best in a repo outside of qtquickcontrols2.git. >>>> >>>>   The process for creating a playground repo is documented here: >>>> >>>>   http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. >>>> >>>>   Have you discussed this project with the Sailfish devs, by the way? >>>>   Perhaps they would be interested in integrating your efforts upstream. >>>> >>>>   One potential problem I see is that it seems that the source code is not >>>>   public: >>>> >>>>   https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/ >>>> >>>>   The closest thing is this repo, which doesn’t seem to be complete: >>>> >>>>   https://github.com/dm8tbr/sailfishsilica-qt5 >>>> >>>>   How do you plan on implementing the style in light of this? >>>> >>>>   Speaking for myself: I would be happy to answer any questions you may have >>>>   with regards to implementing a Controls 2 style, but I don’t think I can put >>>>   aside enough time to be a mentor for this. >>>> >>>>   Cheers. >>>> >>>>   From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>   Sent: Tuesday, 3 April 2018 2:14 PM >>>>   To: Aleksey Kontsevich >>>>   Cc: Mitch Curtis ; development at qt-project.org >>>> >>>>   Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>   Quick Controls 2 Sailfish Silica Style >>>> >>>>   Hi, Aleksey Kontsevich! Thank you for your support, I do agree that >>>>   Sailfish OS is receiving a huge contribution from Russian speaking >>>>   developers and focusing on other local markets too. There's also related >>>>   AsteroidOS community about smartwatches. They have a demo [1] >>>> >>>>   Talking about popularity: from my point of view, while Microsoft is >>>>   providing their Metro unified look for desktop and Intel-based tablets (and >>>>   Xbox) for example, looks like they do not have any plans for new mobile >>>>   devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with >>>>   GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I >>>>   do not want to mislead anyone. >>>> >>>>   Mitch Curtis, thank you for your feedback sincerely. I do understand your >>>>   skepticism about yet another controls in mainline to support. (but I do not >>>>   share this personally :) >>>> >>>>   I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach >>>>   (to play on my Arch Linux system). Dependency from some private APIs looks >>>>   tricky for me at first glance. I'm trying to sort out. I'm not against >>>>   providing silica style as some custom repo, the result I want to get is open >>>>   source solution to run Qt application in my personal environment with native >>>>   Silica look and feel. Will be happy to get any hints about basic repo draft >>>>   in that case (should I look at Kirigami approach?) >>>> >>>>   Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money >>>>   support, I love Silica style, using Sailfish OS for several years and can't >>>>   stand that no one is willing to port it to modern QQC2 approach :) I guess >>>>   it could radically change skepticism about qt quick controls approach in >>>>   general from ios and android developers. >>>> >>>>   [1]: https://www.youtube.com/watch?v=Rd86KTs2Les >>>> >>>>   [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris >>>> >>>>   2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : >>>> >>>>   Hi all, my 2 cents here: >>>> >>>>   >The controls look nice, but my concern is how relevant the Silica style >>>>   > is these days (in the context of how many people are developing apps for the >>>>   >Sailfish OS). >>>> >>>>   Sailfish OS become VERY popular in Russia and in Latin America, and for >>>>   people who wants their data and communication be secure. Market in Russia >>>>   growing very fast, Sailfish OS devices are hits of sales, leading >>>>   universities created courses for Sailfish OS, government certified >>>>   it for corporate and government use and since 2019 all mobile applications >>>>   from national software list (government and corporate use) should work in >>>>   Sailfish OS (according to import replacing law all applications should be >>>>   Russian-native and secure). >>>> >>>>   -- >>>>   Best regards, >>>>   Aleksey >>>>   Linked in https://www.linkedin.com/in/alekseykontsevich >>>> >>>>   03.04.2018, 13:13, "Mitch Curtis" : >>>> >>>>   > Hi Alexey. >>>>   > >>>>   > The controls look nice, but my concern is how relevant the Silica style >>>>   > is these days (in the context of how many people are developing apps for the >>>>   > Sailfish OS). >>>>   > >>>>   > For each style we currently have, I would justify their inclusion into >>>>   > qtquickcontrols2.git for the following reasons: >>>>   > >>>>   > Default - extremely high performance at the cost of a very basic >>>>   > appearance. Tries to be neutral in terms of looks. >>>>   > >>>>   > Fusion - bridges the gap in terms of Desktop styling. An additional/more >>>>   > specific point that I think it is important here is that the controls are >>>>   > more compact (smaller) than any other pre-built style we offer (the Material >>>>   > style has a dense variant now, but that’s still larger if I recall >>>>   > correctly). >>>>   > >>>>   > Imagine - puts power in the hands of designers, frees up time for >>>>   > developers. >>>>   > >>>>   > Material - very relevant in terms of Android market share. Looks really >>>>   > nice; a good candidate for “non-native” cross-platform apps. >>>>   > >>>>   > Universal - relevant in terms of Windows market share. >>>>   > >>>>   > As mentioned, I do think the Silica controls look nice, but that’s the >>>>   > only justification I could think of for including them in >>>>   > qtquickcontrols2.git. For each new style we add, the maintenance cost >>>>   > increases, so this is something that we need to consider. >>>>   > >>>>   > What is your opinion on this? >>>>   > >>>>   > Cheers. >>>>   > >>>>   > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>   > Sent: Friday, 23 March 2018 8:49 PM >>>>   > To: Mitch Curtis >>>>   > Cc: development at qt-project.org >>>>   > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>   > Quick Controls 2 Sailfish Silica Style >>>>   > >>>>   > Thank you Mitch for the feedback! >>>>   > I've also tried to record current controls on a real device: >>>>   > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >>>>   > >>>>   > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >>>>   > : >>>>   >> Silica cheat sheet: >>>>   >> >>>>   >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >>>>   >> Theme cheat sheet: >>>>   >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >>>>   >> Icon reference: >>>>   >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >>>>   >> code example: >>>>   >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >>>>   >> >>>>   >> Youtube video with timestamp for platform-specific PulleyMenu element >>>>   >> example: https://youtu.be/jByW7UNmbxU?t=11m38s >>>>   >> >>>>   >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >>>>   >>> Hello. >>>>   >>> >>>>   >>> Are there any screenshots of it? I read that entire page and the >>>>   >>> Silica docs but couldn’t see anything. >>>>   >>> >>>>   >>> Cheers. >>>>   >>> >>>>   >>> From: Development >>>>   >>> [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of >>>>   >>> Alexey Andreyev >>>>   >>> Sent: Friday, 23 March 2018 5:39 PM >>>>   >>> To: development at qt-project.org >>>>   >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>   >>> Quick Controls 2 Sailfish Silica Style >>>>   >>> >>>>   >>> Hello! >>>>   >>> My name is Alexey, what do you think about Silica Style for QQC2 as a >>>>   >>> gsoc project? >>>>   >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>>>   >>> >>>>   >>> and want to create a proposal. >>>>   > >>>> >>>>   > , >>>>   > >>>>   > _______________________________________________ >>>>   > Development mailing list >>>>   > Development at qt-project.org >>>>   > http://lists.qt-project.org/mailman/listinfo/development >>> >>>   _______________________________________________ >>>   Development mailing list >>>   Development at qt-project.org >>>   http://lists.qt-project.org/mailman/listinfo/development >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From tantrido at ya.ru Fri Apr 6 20:52:27 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Fri, 06 Apr 2018 21:52:27 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: <9411731523039712@web51j.yandex.ru> References: <3659321522751917@web57g.yandex.ru> <11452561523038707@web14g.yandex.ru> <9411731523039712@web51j.yandex.ru> Message-ID: <10116101523040747@web49g.yandex.ru> Really! I have other information. Many people in IT know about and search for Android or iOS alternatives when want to make stuff secure. Also people who tried SailfishOS found it very convenient and fast in usage and do not realize how they worked without it and with Android before :) And I'm mostly talking about tendency, trend not some changing or fixed "current" state. --  Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 06.04.2018, 21:35, "Konstantin Tokarev" : > 06.04.2018, 21:18, "Aleksey Kontsevich" : >>  Hi all, >> >>  Only one argument. >> >>>  I don't see any point in moving this to QtProject as we don't have Sailfish OS platform upstreamed. >> >>  Just let's not miss the moment when it become upstreamed. :-) Things move very fast recent days. Rostelecom and Russian universities make much effort to promote and advance it. Since it is the only mobile OS certified by FSS, and only approved by government - it will be the primary OS applications will be developed for in government and corporate sectors where security is a corner stone. It is sales hit in Russia currently among civilian users (https://buyon.ru/1311520/inoi-r7/) > > Really? Almost nobody is aware of its existence, even in IT circles, and the only device can be bought in one place. AFAIK it has no presence in mobile shops > >>  and become upstreamed very fast with and like Russia become upstreamed already and become much more developed in nearest future. >> >>  Or You mean upstreamed in QtProject? :-) Let's make it upstream then! :-) >> >>  Agree with the rest. >> >>  -- >>  Best regards, >>  Aleksey >>  Linked in https://www.linkedin.com/in/alekseykontsevich >> >>  06.04.2018, 18:40, "Alexander Akulich" : >>>   Hi all, >>> >>>   I highly doubt that it can be done as a part of GSoC and I don't see >>>   any point in moving this to QtProject as we don't have Sailfish OS >>>   platform upstreamed. We just need this style to make QQC2 applications >>>   look native on Sailfish OS. I think that we'll have to rely on >>>   closed-yet components and the style is not going to look nice with >>>   mocks. >>> >>>   That said, I see a number of issues and I hope that we'll discuss and >>>   agree on some changes to the QQC2 API: >>>   1) I would like to propose ComboDelegate — a pair of ComboBox and >>>   Label, combined in a platform-specific way (similar to CheckDelegate >>>   and RadioDelegate). >>>   2) We also need a delegate to display a label and an associated value. >>>   It is named "DetailItem" in Silica, but I would agree to go with a >>>   name like ValueDelegate. >>>   3) Yet another point is that we need to properly style delegate >>>   descriptions, so I want to propose "description" property at least for >>>   Combo, Radio and Switch delegates (we even don't have a 'buddy' >>>   property here, though it still would be very hacky to go in this way). >>> >>>   Probably it makes sense to start another thread to discuss Qt Quick >>>   Controls 2 API, but I need at least three weeks to think and >>>   experiment with what we have right now. :-) >>> >>>   My work is available at >>>   https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt >>>   5.9 and 5.10), but I don't think that it can be interesting for anyone >>>   in its current shape. >>> >>>   On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev >>>    wrote: >>>>    Got it, thank you, Mitch! :) >>>> >>>>    Yes, I have contacted Jolla devs, got answer: >>>> >>>>>     Providing Sailfish support for Qt Quick Controls 2 would definitely be >>>>>    valuable. Sailfish OS cannot build app ecosystem alone, and improving the >>>>>    cross-platform story would help us getting Qt app contributions from other >>>>>    platforms, and help 3rd party developers target multiple platforms like >>>>>    Android and iOS with the same code base. >>>> >>>>>    You are free to use what license you choose, but I would recommend >>>>>    something permissive like BSD3 or LGPL2, which we also use in Sailfish OS >>>>>    open source side >>>> >>>>    Silica Componets source is not public, yes :( But I've got device where I >>>>    have all up-to-date qml files and I'm it as hint. >>>> >>>>    I've also played to run armv7h binaries from device repos (rpm packages) on >>>>    archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage >>>>    address patching for .so lib, it staring and not crashing but asking for >>>>    more deps yet (like image resources deps, so work in progress) >>>> >>>>    Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot >>>>    too, he recently created: >>>> >>>>    https://git.merproject.org/Kaffeine/qtsilicastyle >>>> >>>>    So I'm going to contribute there. >>>> >>>>    For now current state is: >>>> >>>>    5.10 private API chaged compating to 5.9: >>>>    https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2 >>>> >>>>    Alexander is testing with 5.9 LTS on SailfishOS >>>>    and me with archlinuxarm 5.10 >>>>    so I'm thinking now how to provide better compabilty for both :) >>>> >>>>    looks like #ifdef approarch is not helping yet, should investigate more time >>>> >>>>    2018-04-06 15:47 GMT+03:00 Mitch Curtis : >>>> >>>>>    Hi. >>>>> >>>>>    We think this would be best in a repo outside of qtquickcontrols2.git. >>>>> >>>>>    The process for creating a playground repo is documented here: >>>>> >>>>>    http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. >>>>> >>>>>    Have you discussed this project with the Sailfish devs, by the way? >>>>>    Perhaps they would be interested in integrating your efforts upstream. >>>>> >>>>>    One potential problem I see is that it seems that the source code is not >>>>>    public: >>>>> >>>>>    https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/ >>>>> >>>>>    The closest thing is this repo, which doesn’t seem to be complete: >>>>> >>>>>    https://github.com/dm8tbr/sailfishsilica-qt5 >>>>> >>>>>    How do you plan on implementing the style in light of this? >>>>> >>>>>    Speaking for myself: I would be happy to answer any questions you may have >>>>>    with regards to implementing a Controls 2 style, but I don’t think I can put >>>>>    aside enough time to be a mentor for this. >>>>> >>>>>    Cheers. >>>>> >>>>>    From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>>    Sent: Tuesday, 3 April 2018 2:14 PM >>>>>    To: Aleksey Kontsevich >>>>>    Cc: Mitch Curtis ; development at qt-project.org >>>>> >>>>>    Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>    Quick Controls 2 Sailfish Silica Style >>>>> >>>>>    Hi, Aleksey Kontsevich! Thank you for your support, I do agree that >>>>>    Sailfish OS is receiving a huge contribution from Russian speaking >>>>>    developers and focusing on other local markets too. There's also related >>>>>    AsteroidOS community about smartwatches. They have a demo [1] >>>>> >>>>>    Talking about popularity: from my point of view, while Microsoft is >>>>>    providing their Metro unified look for desktop and Intel-based tablets (and >>>>>    Xbox) for example, looks like they do not have any plans for new mobile >>>>>    devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with >>>>>    GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I >>>>>    do not want to mislead anyone. >>>>> >>>>>    Mitch Curtis, thank you for your feedback sincerely. I do understand your >>>>>    skepticism about yet another controls in mainline to support. (but I do not >>>>>    share this personally :) >>>>> >>>>>    I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach >>>>>    (to play on my Arch Linux system). Dependency from some private APIs looks >>>>>    tricky for me at first glance. I'm trying to sort out. I'm not against >>>>>    providing silica style as some custom repo, the result I want to get is open >>>>>    source solution to run Qt application in my personal environment with native >>>>>    Silica look and feel. Will be happy to get any hints about basic repo draft >>>>>    in that case (should I look at Kirigami approach?) >>>>> >>>>>    Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money >>>>>    support, I love Silica style, using Sailfish OS for several years and can't >>>>>    stand that no one is willing to port it to modern QQC2 approach :) I guess >>>>>    it could radically change skepticism about qt quick controls approach in >>>>>    general from ios and android developers. >>>>> >>>>>    [1]: https://www.youtube.com/watch?v=Rd86KTs2Les >>>>> >>>>>    [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris >>>>> >>>>>    2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : >>>>> >>>>>    Hi all, my 2 cents here: >>>>> >>>>>    >The controls look nice, but my concern is how relevant the Silica style >>>>>    > is these days (in the context of how many people are developing apps for the >>>>>    >Sailfish OS). >>>>> >>>>>    Sailfish OS become VERY popular in Russia and in Latin America, and for >>>>>    people who wants their data and communication be secure. Market in Russia >>>>>    growing very fast, Sailfish OS devices are hits of sales, leading >>>>>    universities created courses for Sailfish OS, government certified >>>>>    it for corporate and government use and since 2019 all mobile applications >>>>>    from national software list (government and corporate use) should work in >>>>>    Sailfish OS (according to import replacing law all applications should be >>>>>    Russian-native and secure). >>>>> >>>>>    -- >>>>>    Best regards, >>>>>    Aleksey >>>>>    Linked in https://www.linkedin.com/in/alekseykontsevich >>>>> >>>>>    03.04.2018, 13:13, "Mitch Curtis" : >>>>> >>>>>    > Hi Alexey. >>>>>    > >>>>>    > The controls look nice, but my concern is how relevant the Silica style >>>>>    > is these days (in the context of how many people are developing apps for the >>>>>    > Sailfish OS). >>>>>    > >>>>>    > For each style we currently have, I would justify their inclusion into >>>>>    > qtquickcontrols2.git for the following reasons: >>>>>    > >>>>>    > Default - extremely high performance at the cost of a very basic >>>>>    > appearance. Tries to be neutral in terms of looks. >>>>>    > >>>>>    > Fusion - bridges the gap in terms of Desktop styling. An additional/more >>>>>    > specific point that I think it is important here is that the controls are >>>>>    > more compact (smaller) than any other pre-built style we offer (the Material >>>>>    > style has a dense variant now, but that’s still larger if I recall >>>>>    > correctly). >>>>>    > >>>>>    > Imagine - puts power in the hands of designers, frees up time for >>>>>    > developers. >>>>>    > >>>>>    > Material - very relevant in terms of Android market share. Looks really >>>>>    > nice; a good candidate for “non-native” cross-platform apps. >>>>>    > >>>>>    > Universal - relevant in terms of Windows market share. >>>>>    > >>>>>    > As mentioned, I do think the Silica controls look nice, but that’s the >>>>>    > only justification I could think of for including them in >>>>>    > qtquickcontrols2.git. For each new style we add, the maintenance cost >>>>>    > increases, so this is something that we need to consider. >>>>>    > >>>>>    > What is your opinion on this? >>>>>    > >>>>>    > Cheers. >>>>>    > >>>>>    > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>>    > Sent: Friday, 23 March 2018 8:49 PM >>>>>    > To: Mitch Curtis >>>>>    > Cc: development at qt-project.org >>>>>    > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>    > Quick Controls 2 Sailfish Silica Style >>>>>    > >>>>>    > Thank you Mitch for the feedback! >>>>>    > I've also tried to record current controls on a real device: >>>>>    > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >>>>>    > >>>>>    > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >>>>>    > : >>>>>    >> Silica cheat sheet: >>>>>    >> >>>>>    >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >>>>>    >> Theme cheat sheet: >>>>>    >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >>>>>    >> Icon reference: >>>>>    >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >>>>>    >> code example: >>>>>    >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >>>>>    >> >>>>>    >> Youtube video with timestamp for platform-specific PulleyMenu element >>>>>    >> example: https://youtu.be/jByW7UNmbxU?t=11m38s >>>>>    >> >>>>>    >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >>>>>    >>> Hello. >>>>>    >>> >>>>>    >>> Are there any screenshots of it? I read that entire page and the >>>>>    >>> Silica docs but couldn’t see anything. >>>>>    >>> >>>>>    >>> Cheers. >>>>>    >>> >>>>>    >>> From: Development >>>>>    >>> [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of >>>>>    >>> Alexey Andreyev >>>>>    >>> Sent: Friday, 23 March 2018 5:39 PM >>>>>    >>> To: development at qt-project.org >>>>>    >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>    >>> Quick Controls 2 Sailfish Silica Style >>>>>    >>> >>>>>    >>> Hello! >>>>>    >>> My name is Alexey, what do you think about Silica Style for QQC2 as a >>>>>    >>> gsoc project? >>>>>    >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>>>>    >>> >>>>>    >>> and want to create a proposal. >>>>>    > >>>>> >>>>>    > , >>>>>    > >>>>>    > _______________________________________________ >>>>>    > Development mailing list >>>>>    > Development at qt-project.org >>>>>    > http://lists.qt-project.org/mailman/listinfo/development >>>> >>>>    _______________________________________________ >>>>    Development mailing list >>>>    Development at qt-project.org >>>>    http://lists.qt-project.org/mailman/listinfo/development >>> >>>   _______________________________________________ >>>   Development mailing list >>>   Development at qt-project.org >>>   http://lists.qt-project.org/mailman/listinfo/development >> >>  _______________________________________________ >>  Development mailing list >>  Development at qt-project.org >>  http://lists.qt-project.org/mailman/listinfo/development > > -- > Regards, > Konstantin From akulichalexander at gmail.com Fri Apr 6 21:19:05 2018 From: akulichalexander at gmail.com (Alexander Akulich) Date: Fri, 6 Apr 2018 22:19:05 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: <10116101523040747@web49g.yandex.ru> References: <3659321522751917@web57g.yandex.ru> <11452561523038707@web14g.yandex.ru> <9411731523039712@web51j.yandex.ru> <10116101523040747@web49g.yandex.ru> Message-ID: On Fri, Apr 6, 2018 at 9:35 PM, "Konstantin Tokarev" : > Really? Almost nobody is aware of its existence, even in IT circles, and the only device can be bought in one place. AFAIK it has no presence in mobile shops On Fri, Apr 6, 2018 at 9:52 PM, Aleksey Kontsevich wrote: > I'm mostly talking about tendency, trend not some changing or fixed "current" state. I like Sailfish OS and I work on it in my spare time, but we should be honest and talk about the actual situation. Nobody cares about government approval and the numbers are much less than GNU/Linux share on Steam. It is barely possible to grow up to 1% of the Russian market share by the end of this year. If you think that the situation is different — please come with big numbers instead of loud words. From alexander.blasche at qt.io Mon Apr 9 08:37:23 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 9 Apr 2018 06:37:23 +0000 Subject: [Development] Stepping down as maintainer In-Reply-To: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> References: <3B7614FE-934A-41F3-8892-24D0769D0832@crimson.no> Message-ID: All required Jira and https://wiki.qt.io/Maintainers updates have been done. -- Alex ________________________________________ From: Development on behalf of Gunnar Sletta Sent: Monday, 19 March 2018 1:39:50 PM To: development Subject: [Development] Stepping down as maintainer Hi, After quite some time of not being active in Qt, I am now formally stepping down as maintainer. It has been a great ride, but I simply don't have time to follow up Gui and Scene Graph and it makes sense that the people who are active in these areas also become the go-to guys. I've already spoken with Eskil and Lars, and propose the following list of people to formally take over my areas: Tor Arne Vestby - QPA and window system integration Laszlo Agocs - OpenGL/Vulkan Eirik Aavitsland - Image Formats and QPainter Andy Nichols - Scene Graph (Other specific maintainers in QtGui stay unchanged) Thanks, Gunnar _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From Maurice.Kalinowski at qt.io Mon Apr 9 14:17:34 2018 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Mon, 9 Apr 2018 12:17:34 +0000 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP Message-ID: Hi, As some might have recognized my focus inside the Qt Company has shifted from WinRT/UWP towards our Automation related offering. While I still review many patches for this platform, my effort in terms of active development have significantly reduced. Consequently, I would like to propose Oliver Wolff to take over the role as platform maintainer. Oliver has been part of the team for years and (besides lots of other things) has been taking care of the networking parts. In addition to that, he has been "shadow-maintaining" the port over the last year, so this would rather reflect reality. https://codereview.qt-project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolff%2540qt.io%253E%22,n,z BR, Maurice P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the maintainer list, contrary to me when I took it over from Andrew :) -- Maurice Kalinowski Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin maurice.kalinowski at qt.io http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From alexander.blasche at qt.io Mon Apr 9 15:48:46 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 9 Apr 2018 13:48:46 +0000 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: +1 from me -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Maurice > Kalinowski > Sent: Monday, 9 April 2018 14:18 > To: development at qt-project.org > Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP > > Hi, > > As some might have recognized my focus inside the Qt Company has shifted > from WinRT/UWP towards our Automation related offering. While I still review > many patches for this platform, my effort in terms of active development have > significantly reduced. > > Consequently, I would like to propose Oliver Wolff to take over the role as > platform maintainer. Oliver has been part of the team for years and (besides lots > of other things) has been taking care of the networking parts. In addition to > that, he has been "shadow-maintaining" the port over the last year, so this > would rather reflect reality. > > https://codereview.qt- > project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolff%2540qt.io%253E% > 22,n,z > > BR, > Maurice > > P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the > maintainer list, contrary to me when I took it over from Andrew :) > > -- > Maurice Kalinowski > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > maurice.kalinowski at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From fanda.vacek at volny.cz Mon Apr 9 15:50:49 2018 From: fanda.vacek at volny.cz (Fanda Vacek) Date: Mon, 9 Apr 2018 15:50:49 +0200 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: <9411731523039712@web51j.yandex.ru> References: <3659321522751917@web57g.yandex.ru> <11452561523038707@web14g.yandex.ru> <9411731523039712@web51j.yandex.ru> Message-ID: On 04/06/2018 08:35 PM, Konstantin Tokarev wrote: > > 06.04.2018, 21:18, "Aleksey Kontsevich" : >> Hi all, >> >> Only one argument. >> >>> I don't see any point in moving this to QtProject as we don't have Sailfish OS platform upstreamed. >> Just let's not miss the moment when it become upstreamed. :-) Things move very fast recent days. Rostelecom and Russian universities make much effort to promote and advance it. Since it is the only mobile OS certified by FSS, and only approved by government - it will be the primary OS applications will be developed for in government and corporate sectors where security is a corner stone. It is sales hit in Russia currently among civilian users (https://buyon.ru/1311520/inoi-r7/) > Really? Almost nobody is aware of its existence, even in IT circles, and the only device can be bought in one place. AFAIK it has no presence in mobile shops You can buy Sony Xperia X and install SailfishOS X on it, I did it this way. Sony Xperia XA2 port is on the way. > >> and become upstreamed very fast with and like Russia become upstreamed already and become much more developed in nearest future. >> >> Or You mean upstreamed in QtProject? :-) Let's make it upstream then! :-) >> >> Agree with the rest. >> >> -- >> Best regards, >> Aleksey >> Linked in https://www.linkedin.com/in/alekseykontsevich >> >> 06.04.2018, 18:40, "Alexander Akulich" : >>>  Hi all, >>> >>>  I highly doubt that it can be done as a part of GSoC and I don't see >>>  any point in moving this to QtProject as we don't have Sailfish OS >>>  platform upstreamed. We just need this style to make QQC2 applications >>>  look native on Sailfish OS. I think that we'll have to rely on >>>  closed-yet components and the style is not going to look nice with >>>  mocks. >>> >>>  That said, I see a number of issues and I hope that we'll discuss and >>>  agree on some changes to the QQC2 API: >>>  1) I would like to propose ComboDelegate — a pair of ComboBox and >>>  Label, combined in a platform-specific way (similar to CheckDelegate >>>  and RadioDelegate). >>>  2) We also need a delegate to display a label and an associated value. >>>  It is named "DetailItem" in Silica, but I would agree to go with a >>>  name like ValueDelegate. >>>  3) Yet another point is that we need to properly style delegate >>>  descriptions, so I want to propose "description" property at least for >>>  Combo, Radio and Switch delegates (we even don't have a 'buddy' >>>  property here, though it still would be very hacky to go in this way). >>> >>>  Probably it makes sense to start another thread to discuss Qt Quick >>>  Controls 2 API, but I need at least three weeks to think and >>>  experiment with what we have right now. :-) >>> >>>  My work is available at >>>  https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt >>>  5.9 and 5.10), but I don't think that it can be interesting for anyone >>>  in its current shape. >>> >>>  On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev >>>   wrote: >>>>   Got it, thank you, Mitch! :) >>>> >>>>   Yes, I have contacted Jolla devs, got answer: >>>> >>>>>    Providing Sailfish support for Qt Quick Controls 2 would definitely be >>>>>   valuable. Sailfish OS cannot build app ecosystem alone, and improving the >>>>>   cross-platform story would help us getting Qt app contributions from other >>>>>   platforms, and help 3rd party developers target multiple platforms like >>>>>   Android and iOS with the same code base. >>>>>   You are free to use what license you choose, but I would recommend >>>>>   something permissive like BSD3 or LGPL2, which we also use in Sailfish OS >>>>>   open source side >>>>   Silica Componets source is not public, yes :( But I've got device where I >>>>   have all up-to-date qml files and I'm it as hint. >>>> >>>>   I've also played to run armv7h binaries from device repos (rpm packages) on >>>>   archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage >>>>   address patching for .so lib, it staring and not crashing but asking for >>>>   more deps yet (like image resources deps, so work in progress) >>>> >>>>   Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot >>>>   too, he recently created: >>>> >>>>   https://git.merproject.org/Kaffeine/qtsilicastyle >>>> >>>>   So I'm going to contribute there. >>>> >>>>   For now current state is: >>>> >>>>   5.10 private API chaged compating to 5.9: >>>>   https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2 >>>> >>>>   Alexander is testing with 5.9 LTS on SailfishOS >>>>   and me with archlinuxarm 5.10 >>>>   so I'm thinking now how to provide better compabilty for both :) >>>> >>>>   looks like #ifdef approarch is not helping yet, should investigate more time >>>> >>>>   2018-04-06 15:47 GMT+03:00 Mitch Curtis : >>>> >>>>>   Hi. >>>>> >>>>>   We think this would be best in a repo outside of qtquickcontrols2.git. >>>>> >>>>>   The process for creating a playground repo is documented here: >>>>> >>>>>   http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. >>>>> >>>>>   Have you discussed this project with the Sailfish devs, by the way? >>>>>   Perhaps they would be interested in integrating your efforts upstream. >>>>> >>>>>   One potential problem I see is that it seems that the source code is not >>>>>   public: >>>>> >>>>>   https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/ >>>>> >>>>>   The closest thing is this repo, which doesn’t seem to be complete: >>>>> >>>>>   https://github.com/dm8tbr/sailfishsilica-qt5 >>>>> >>>>>   How do you plan on implementing the style in light of this? >>>>> >>>>>   Speaking for myself: I would be happy to answer any questions you may have >>>>>   with regards to implementing a Controls 2 style, but I don’t think I can put >>>>>   aside enough time to be a mentor for this. >>>>> >>>>>   Cheers. >>>>> >>>>>   From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>>   Sent: Tuesday, 3 April 2018 2:14 PM >>>>>   To: Aleksey Kontsevich >>>>>   Cc: Mitch Curtis ; development at qt-project.org >>>>> >>>>>   Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>   Quick Controls 2 Sailfish Silica Style >>>>> >>>>>   Hi, Aleksey Kontsevich! Thank you for your support, I do agree that >>>>>   Sailfish OS is receiving a huge contribution from Russian speaking >>>>>   developers and focusing on other local markets too. There's also related >>>>>   AsteroidOS community about smartwatches. They have a demo [1] >>>>> >>>>>   Talking about popularity: from my point of view, while Microsoft is >>>>>   providing their Metro unified look for desktop and Intel-based tablets (and >>>>>   Xbox) for example, looks like they do not have any plans for new mobile >>>>>   devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with >>>>>   GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I >>>>>   do not want to mislead anyone. >>>>> >>>>>   Mitch Curtis, thank you for your feedback sincerely. I do understand your >>>>>   skepticism about yet another controls in mainline to support. (but I do not >>>>>   share this personally :) >>>>> >>>>>   I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach >>>>>   (to play on my Arch Linux system). Dependency from some private APIs looks >>>>>   tricky for me at first glance. I'm trying to sort out. I'm not against >>>>>   providing silica style as some custom repo, the result I want to get is open >>>>>   source solution to run Qt application in my personal environment with native >>>>>   Silica look and feel. Will be happy to get any hints about basic repo draft >>>>>   in that case (should I look at Kirigami approach?) >>>>> >>>>>   Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money >>>>>   support, I love Silica style, using Sailfish OS for several years and can't >>>>>   stand that no one is willing to port it to modern QQC2 approach :) I guess >>>>>   it could radically change skepticism about qt quick controls approach in >>>>>   general from ios and android developers. >>>>> >>>>>   [1]: https://www.youtube.com/watch?v=Rd86KTs2Les >>>>> >>>>>   [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris >>>>> >>>>>   2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : >>>>> >>>>>   Hi all, my 2 cents here: >>>>> >>>>>   >The controls look nice, but my concern is how relevant the Silica style >>>>>   > is these days (in the context of how many people are developing apps for the >>>>>   >Sailfish OS). >>>>> >>>>>   Sailfish OS become VERY popular in Russia and in Latin America, and for >>>>>   people who wants their data and communication be secure. Market in Russia >>>>>   growing very fast, Sailfish OS devices are hits of sales, leading >>>>>   universities created courses for Sailfish OS, government certified >>>>>   it for corporate and government use and since 2019 all mobile applications >>>>>   from national software list (government and corporate use) should work in >>>>>   Sailfish OS (according to import replacing law all applications should be >>>>>   Russian-native and secure). >>>>> >>>>>   -- >>>>>   Best regards, >>>>>   Aleksey >>>>>   Linked in https://www.linkedin.com/in/alekseykontsevich >>>>> >>>>>   03.04.2018, 13:13, "Mitch Curtis" : >>>>> >>>>>   > Hi Alexey. >>>>>   > >>>>>   > The controls look nice, but my concern is how relevant the Silica style >>>>>   > is these days (in the context of how many people are developing apps for the >>>>>   > Sailfish OS). >>>>>   > >>>>>   > For each style we currently have, I would justify their inclusion into >>>>>   > qtquickcontrols2.git for the following reasons: >>>>>   > >>>>>   > Default - extremely high performance at the cost of a very basic >>>>>   > appearance. Tries to be neutral in terms of looks. >>>>>   > >>>>>   > Fusion - bridges the gap in terms of Desktop styling. An additional/more >>>>>   > specific point that I think it is important here is that the controls are >>>>>   > more compact (smaller) than any other pre-built style we offer (the Material >>>>>   > style has a dense variant now, but that’s still larger if I recall >>>>>   > correctly). >>>>>   > >>>>>   > Imagine - puts power in the hands of designers, frees up time for >>>>>   > developers. >>>>>   > >>>>>   > Material - very relevant in terms of Android market share. Looks really >>>>>   > nice; a good candidate for “non-native” cross-platform apps. >>>>>   > >>>>>   > Universal - relevant in terms of Windows market share. >>>>>   > >>>>>   > As mentioned, I do think the Silica controls look nice, but that’s the >>>>>   > only justification I could think of for including them in >>>>>   > qtquickcontrols2.git. For each new style we add, the maintenance cost >>>>>   > increases, so this is something that we need to consider. >>>>>   > >>>>>   > What is your opinion on this? >>>>>   > >>>>>   > Cheers. >>>>>   > >>>>>   > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>>   > Sent: Friday, 23 March 2018 8:49 PM >>>>>   > To: Mitch Curtis >>>>>   > Cc: development at qt-project.org >>>>>   > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>   > Quick Controls 2 Sailfish Silica Style >>>>>   > >>>>>   > Thank you Mitch for the feedback! >>>>>   > I've also tried to record current controls on a real device: >>>>>   > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >>>>>   > >>>>>   > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >>>>>   > : >>>>>   >> Silica cheat sheet: >>>>>   >> >>>>>   >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >>>>>   >> Theme cheat sheet: >>>>>   >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >>>>>   >> Icon reference: >>>>>   >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >>>>>   >> code example: >>>>>   >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >>>>>   >> >>>>>   >> Youtube video with timestamp for platform-specific PulleyMenu element >>>>>   >> example: https://youtu.be/jByW7UNmbxU?t=11m38s >>>>>   >> >>>>>   >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >>>>>   >>> Hello. >>>>>   >>> >>>>>   >>> Are there any screenshots of it? I read that entire page and the >>>>>   >>> Silica docs but couldn’t see anything. >>>>>   >>> >>>>>   >>> Cheers. >>>>>   >>> >>>>>   >>> From: Development >>>>>   >>> [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of >>>>>   >>> Alexey Andreyev >>>>>   >>> Sent: Friday, 23 March 2018 5:39 PM >>>>>   >>> To: development at qt-project.org >>>>>   >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>   >>> Quick Controls 2 Sailfish Silica Style >>>>>   >>> >>>>>   >>> Hello! >>>>>   >>> My name is Alexey, what do you think about Silica Style for QQC2 as a >>>>>   >>> gsoc project? >>>>>   >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>>>>   >>> >>>>>   >>> and want to create a proposal. >>>>>   > >>>>> >>>>>   > , >>>>>   > >>>>>   > _______________________________________________ >>>>>   > Development mailing list >>>>>   > Development at qt-project.org >>>>>   > http://lists.qt-project.org/mailman/listinfo/development >>>>   _______________________________________________ >>>>   Development mailing list >>>>   Development at qt-project.org >>>>   http://lists.qt-project.org/mailman/listinfo/development >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development From szehowe.koh at gmail.com Mon Apr 9 16:14:18 2018 From: szehowe.koh at gmail.com (Sze Howe Koh) Date: Mon, 9 Apr 2018 22:14:18 +0800 Subject: [Development] To improve UX of the online installer In-Reply-To: <87e57495-666b-742c-171f-97d7cd8d13d3@tungware.se> References: <87e57495-666b-742c-171f-97d7cd8d13d3@tungware.se> Message-ID: Thanks for chiming in, Henry. I've started filing bug reports, as Giuseppe suggested. On 3 April 2018 at 08:29, Henry Skoglund wrote: > > Hi, excellent initiative, a better MaintenanceTool UX would also improve the general opinion of Qt I think. > > Just one to add 2 things to Sze Howe's list: > > 8c. For the users that, in search of a 32-bit MSVC2017-flavored Qt version, downloads the UWP x86 (MSVC 2017) version of Qt, and then tries to run it on Windows 7: please explain that the UWP stuff only runs on Windows 10. Added as part of https://bugreports.qt.io/browse/QTIFW-1125 > 11. Please make 'Update components' the default selection once you've logged in, or 'Add or remove components'. Anything but 'Remove all components' !!! https://bugreports.qt.io/browse/QTIFW-1122 > Rgrds Henry Regards, Sze-Howe From annulen at yandex.ru Mon Apr 9 16:40:22 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Mon, 09 Apr 2018 17:40:22 +0300 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> <11452561523038707@web14g.yandex.ru> <9411731523039712@web51j.yandex.ru> Message-ID: <2634521523284822@web37g.yandex.ru> 09.04.2018, 16:51, "Fanda Vacek" : > On 04/06/2018 08:35 PM, Konstantin Tokarev wrote: >>  06.04.2018, 21:18, "Aleksey Kontsevich" : >>>  Hi all, >>> >>>  Only one argument. >>> >>>>  I don't see any point in moving this to QtProject as we don't have Sailfish OS platform upstreamed. >>>  Just let's not miss the moment when it become upstreamed. :-) Things move very fast recent days. Rostelecom and Russian universities make much effort to promote and advance it. Since it is the only mobile OS certified by FSS, and only approved by government - it will be the primary OS applications will be developed for in government and corporate sectors where security is a corner stone. It is sales hit in Russia currently among civilian users (https://buyon.ru/1311520/inoi-r7/) >>  Really? Almost nobody is aware of its existence, even in IT circles, and the only device can be bought in one place. AFAIK it has no presence in mobile shops > > You can buy Sony Xperia X and install SailfishOS X on it, I did it this > way. Sony Xperia XA2 port is on the way. https://shop.jolla.com/ says "Sorry, not available in your country" > >>>  and become upstreamed very fast with and like Russia become upstreamed already and become much more developed in nearest future. >>> >>>  Or You mean upstreamed in QtProject? :-) Let's make it upstream then! :-) >>> >>>  Agree with the rest. >>> >>>  -- >>>  Best regards, >>>  Aleksey >>>  Linked in https://www.linkedin.com/in/alekseykontsevich >>> >>>  06.04.2018, 18:40, "Alexander Akulich" : >>>>    Hi all, >>>> >>>>    I highly doubt that it can be done as a part of GSoC and I don't see >>>>    any point in moving this to QtProject as we don't have Sailfish OS >>>>    platform upstreamed. We just need this style to make QQC2 applications >>>>    look native on Sailfish OS. I think that we'll have to rely on >>>>    closed-yet components and the style is not going to look nice with >>>>    mocks. >>>> >>>>    That said, I see a number of issues and I hope that we'll discuss and >>>>    agree on some changes to the QQC2 API: >>>>    1) I would like to propose ComboDelegate — a pair of ComboBox and >>>>    Label, combined in a platform-specific way (similar to CheckDelegate >>>>    and RadioDelegate). >>>>    2) We also need a delegate to display a label and an associated value. >>>>    It is named "DetailItem" in Silica, but I would agree to go with a >>>>    name like ValueDelegate. >>>>    3) Yet another point is that we need to properly style delegate >>>>    descriptions, so I want to propose "description" property at least for >>>>    Combo, Radio and Switch delegates (we even don't have a 'buddy' >>>>    property here, though it still would be very hacky to go in this way). >>>> >>>>    Probably it makes sense to start another thread to discuss Qt Quick >>>>    Controls 2 API, but I need at least three weeks to think and >>>>    experiment with what we have right now. :-) >>>> >>>>    My work is available at >>>>    https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt >>>>    5.9 and 5.10), but I don't think that it can be interesting for anyone >>>>    in its current shape. >>>> >>>>    On Fri, Apr 6, 2018 at 4:11 PM, Alexey Andreyev >>>>     wrote: >>>>>     Got it, thank you, Mitch! :) >>>>> >>>>>     Yes, I have contacted Jolla devs, got answer: >>>>> >>>>>>      Providing Sailfish support for Qt Quick Controls 2 would definitely be >>>>>>     valuable. Sailfish OS cannot build app ecosystem alone, and improving the >>>>>>     cross-platform story would help us getting Qt app contributions from other >>>>>>     platforms, and help 3rd party developers target multiple platforms like >>>>>>     Android and iOS with the same code base. >>>>>>     You are free to use what license you choose, but I would recommend >>>>>>     something permissive like BSD3 or LGPL2, which we also use in Sailfish OS >>>>>>     open source side >>>>>     Silica Componets source is not public, yes :( But I've got device where I >>>>>     have all up-to-date qml files and I'm it as hint. >>>>> >>>>>     I've also played to run armv7h binaries from device repos (rpm packages) on >>>>>     archlinuxarm (wrote PKGBUILDs) with all the deps and some hacky qt5 linkage >>>>>     address patching for .so lib, it staring and not crashing but asking for >>>>>     more deps yet (like image resources deps, so work in progress) >>>>> >>>>>     Alexander Akulich (Kaffeine) from Open Mobile Platform is helping me a lot >>>>>     too, he recently created: >>>>> >>>>>     https://git.merproject.org/Kaffeine/qtsilicastyle >>>>> >>>>>     So I'm going to contribute there. >>>>> >>>>>     For now current state is: >>>>> >>>>>     5.10 private API chaged compating to 5.9: >>>>>     https://github.com/qt/qtquickcontrols2/commit/b18b6375d170ce02dc5a627bfb69ca49046ee05c#diff-7467cf01ad998520d6d9d2995867e8e2 >>>>> >>>>>     Alexander is testing with 5.9 LTS on SailfishOS >>>>>     and me with archlinuxarm 5.10 >>>>>     so I'm thinking now how to provide better compabilty for both :) >>>>> >>>>>     looks like #ifdef approarch is not helping yet, should investigate more time >>>>> >>>>>     2018-04-06 15:47 GMT+03:00 Mitch Curtis : >>>>> >>>>>>     Hi. >>>>>> >>>>>>     We think this would be best in a repo outside of qtquickcontrols2.git. >>>>>> >>>>>>     The process for creating a playground repo is documented here: >>>>>> >>>>>>     http://wiki.qt.io/Creating_a_new_module_or_tool_for_Qt#Getting_started_with_new_ideas_on_Qt_Project.27s_Playground. >>>>>> >>>>>>     Have you discussed this project with the Sailfish devs, by the way? >>>>>>     Perhaps they would be interested in integrating your efforts upstream. >>>>>> >>>>>>     One potential problem I see is that it seems that the source code is not >>>>>>     public: >>>>>> >>>>>>     https://together.jolla.com/question/6780/request-sourcecode-for-silica-core-components/ >>>>>> >>>>>>     The closest thing is this repo, which doesn’t seem to be complete: >>>>>> >>>>>>     https://github.com/dm8tbr/sailfishsilica-qt5 >>>>>> >>>>>>     How do you plan on implementing the style in light of this? >>>>>> >>>>>>     Speaking for myself: I would be happy to answer any questions you may have >>>>>>     with regards to implementing a Controls 2 style, but I don’t think I can put >>>>>>     aside enough time to be a mentor for this. >>>>>> >>>>>>     Cheers. >>>>>> >>>>>>     From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>>>     Sent: Tuesday, 3 April 2018 2:14 PM >>>>>>     To: Aleksey Kontsevich >>>>>>     Cc: Mitch Curtis ; development at qt-project.org >>>>>> >>>>>>     Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>>     Quick Controls 2 Sailfish Silica Style >>>>>> >>>>>>     Hi, Aleksey Kontsevich! Thank you for your support, I do agree that >>>>>>     Sailfish OS is receiving a huge contribution from Russian speaking >>>>>>     developers and focusing on other local markets too. There's also related >>>>>>     AsteroidOS community about smartwatches. They have a demo [1] >>>>>> >>>>>>     Talking about popularity: from my point of view, while Microsoft is >>>>>>     providing their Metro unified look for desktop and Intel-based tablets (and >>>>>>     Xbox) for example, looks like they do not have any plans for new mobile >>>>>>     devices (I mean arm-based) to provide. While Sailfish OS is mobile OS with >>>>>>     GSM-stack support for real arm-based systems. [1] Correct me if I'm wrong, I >>>>>>     do not want to mislead anyone. >>>>>> >>>>>>     Mitch Curtis, thank you for your feedback sincerely. I do understand your >>>>>>     skepticism about yet another controls in mainline to support. (but I do not >>>>>>     share this personally :) >>>>>> >>>>>>     I'm new to qqc2 internals. I've cloned qtquickcontrols2 repo 5.10.1 brach >>>>>>     (to play on my Arch Linux system). Dependency from some private APIs looks >>>>>>     tricky for me at first glance. I'm trying to sort out. I'm not against >>>>>>     providing silica style as some custom repo, the result I want to get is open >>>>>>     source solution to run Qt application in my personal environment with native >>>>>>     Silica look and feel. Will be happy to get any hints about basic repo draft >>>>>>     in that case (should I look at Kirigami approach?) >>>>>> >>>>>>     Anyway, as I wrote at my GSoC proposal, GSoC campaign is just money >>>>>>     support, I love Silica style, using Sailfish OS for several years and can't >>>>>>     stand that no one is willing to port it to modern QQC2 approach :) I guess >>>>>>     it could radically change skepticism about qt quick controls approach in >>>>>>     general from ios and android developers. >>>>>> >>>>>>     [1]: https://www.youtube.com/watch?v=Rd86KTs2Les >>>>>> >>>>>>     [2]: https://wiki.merproject.org/wiki/Adaptations/libhybris >>>>>> >>>>>>     2018-04-03 13:38 GMT+03:00 Aleksey Kontsevich : >>>>>> >>>>>>     Hi all, my 2 cents here: >>>>>> >>>>>>     >The controls look nice, but my concern is how relevant the Silica style >>>>>>     > is these days (in the context of how many people are developing apps for the >>>>>>     >Sailfish OS). >>>>>> >>>>>>     Sailfish OS become VERY popular in Russia and in Latin America, and for >>>>>>     people who wants their data and communication be secure. Market in Russia >>>>>>     growing very fast, Sailfish OS devices are hits of sales, leading >>>>>>     universities created courses for Sailfish OS, government certified >>>>>>     it for corporate and government use and since 2019 all mobile applications >>>>>>     from national software list (government and corporate use) should work in >>>>>>     Sailfish OS (according to import replacing law all applications should be >>>>>>     Russian-native and secure). >>>>>> >>>>>>     -- >>>>>>     Best regards, >>>>>>     Aleksey >>>>>>     Linked in https://www.linkedin.com/in/alekseykontsevich >>>>>> >>>>>>     03.04.2018, 13:13, "Mitch Curtis" : >>>>>> >>>>>>     > Hi Alexey. >>>>>>     > >>>>>>     > The controls look nice, but my concern is how relevant the Silica style >>>>>>     > is these days (in the context of how many people are developing apps for the >>>>>>     > Sailfish OS). >>>>>>     > >>>>>>     > For each style we currently have, I would justify their inclusion into >>>>>>     > qtquickcontrols2.git for the following reasons: >>>>>>     > >>>>>>     > Default - extremely high performance at the cost of a very basic >>>>>>     > appearance. Tries to be neutral in terms of looks. >>>>>>     > >>>>>>     > Fusion - bridges the gap in terms of Desktop styling. An additional/more >>>>>>     > specific point that I think it is important here is that the controls are >>>>>>     > more compact (smaller) than any other pre-built style we offer (the Material >>>>>>     > style has a dense variant now, but that’s still larger if I recall >>>>>>     > correctly). >>>>>>     > >>>>>>     > Imagine - puts power in the hands of designers, frees up time for >>>>>>     > developers. >>>>>>     > >>>>>>     > Material - very relevant in terms of Android market share. Looks really >>>>>>     > nice; a good candidate for “non-native” cross-platform apps. >>>>>>     > >>>>>>     > Universal - relevant in terms of Windows market share. >>>>>>     > >>>>>>     > As mentioned, I do think the Silica controls look nice, but that’s the >>>>>>     > only justification I could think of for including them in >>>>>>     > qtquickcontrols2.git. For each new style we add, the maintenance cost >>>>>>     > increases, so this is something that we need to consider. >>>>>>     > >>>>>>     > What is your opinion on this? >>>>>>     > >>>>>>     > Cheers. >>>>>>     > >>>>>>     > From: Alexey Andreyev [mailto:yetanotherandreyev at gmail.com] >>>>>>     > Sent: Friday, 23 March 2018 8:49 PM >>>>>>     > To: Mitch Curtis >>>>>>     > Cc: development at qt-project.org >>>>>>     > Subject: Re: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>>     > Quick Controls 2 Sailfish Silica Style >>>>>>     > >>>>>>     > Thank you Mitch for the feedback! >>>>>>     > I've also tried to record current controls on a real device: >>>>>>     > https://youtu.be/T-qUZMuTGqw (hope not only 360p will be available soon) >>>>>>     > >>>>>>     > 2018-03-23 21:55 GMT+03:00 Alexey Andreyev >>>>>>     > : >>>>>>     >> Silica cheat sheet: >>>>>>     >> >>>>>>     >> https://sailfishos.org/wp-content/uploads/2016/06/component_cheatsheet.png >>>>>>     >> Theme cheat sheet: >>>>>>     >> https://sailfishos.org/wp-content/uploads/2016/06/theme_cheatsheet.png >>>>>>     >> Icon reference: >>>>>>     >> https://sailfishos.org/wp-content/uploads/2016/06/icon_reference.png >>>>>>     >> code example: >>>>>>     >> https://gist.github.com/jaymzznoori/a980314f8248e0a1e7904c29c88ecdf3 >>>>>>     >> >>>>>>     >> Youtube video with timestamp for platform-specific PulleyMenu element >>>>>>     >> example: https://youtu.be/jByW7UNmbxU?t=11m38s >>>>>>     >> >>>>>>     >> 2018-03-23 21:40 GMT+03:00 Mitch Curtis : >>>>>>     >>> Hello. >>>>>>     >>> >>>>>>     >>> Are there any screenshots of it? I read that entire page and the >>>>>>     >>> Silica docs but couldn’t see anything. >>>>>>     >>> >>>>>>     >>> Cheers. >>>>>>     >>> >>>>>>     >>> From: Development >>>>>>     >>> [mailto:development-bounces+mitch.curtis=qt.io at qt-project.org] On Behalf Of >>>>>>     >>> Alexey Andreyev >>>>>>     >>> Sent: Friday, 23 March 2018 5:39 PM >>>>>>     >>> To: development at qt-project.org >>>>>>     >>> Subject: [Development] [Google Summer of Code] [Project Ideas] Qt >>>>>>     >>> Quick Controls 2 Sailfish Silica Style >>>>>>     >>> >>>>>>     >>> Hello! >>>>>>     >>> My name is Alexey, what do you think about Silica Style for QQC2 as a >>>>>>     >>> gsoc project? >>>>>>     >>> I have some notes here: http://aa13q.ru/qqc2-silica-style-en/ >>>>>>     >>> >>>>>>     >>> and want to create a proposal. >>>>>>     > >>>>>> >>>>>>     > , >>>>>>     > >>>>>>     > _______________________________________________ >>>>>>     > Development mailing list >>>>>>     > Development at qt-project.org >>>>>>     > http://lists.qt-project.org/mailman/listinfo/development >>>>>     _______________________________________________ >>>>>     Development mailing list >>>>>     Development at qt-project.org >>>>>     http://lists.qt-project.org/mailman/listinfo/development >>>>    _______________________________________________ >>>>    Development mailing list >>>>    Development at qt-project.org >>>>    http://lists.qt-project.org/mailman/listinfo/development >>>  _______________________________________________ >>>  Development mailing list >>>  Development at qt-project.org >>>  http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Regards, Konstantin From thiago.macieira at intel.com Mon Apr 9 18:00:23 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 9 Apr 2018 09:00:23 -0700 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: <1667141.rMRKHF6Ymi@tjmaciei-mobl1> On Monday, 9 April 2018 05:17:34 PDT Maurice Kalinowski wrote: > Hi, > > As some might have recognized my focus inside the Qt Company has shifted > from WinRT/UWP towards our Automation related offering. While I still > review many patches for this platform, my effort in terms of active > development have significantly reduced. > > Consequently, I would like to propose Oliver Wolff to take over the role as > platform maintainer. Oliver has been part of the team for years and > (besides lots of other things) has been taking care of the networking > parts. In addition to that, he has been "shadow-maintaining" the port over > the last year, so this would rather reflect reality. > > https://codereview.qt-project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolf > f%2540qt.io%253E%22,n,z +1 Thanks Maurice and Oliver for the effort so far. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From robert.loehning at qt.io Mon Apr 9 19:02:49 2018 From: robert.loehning at qt.io (=?UTF-8?Q?Robert_L=c3=b6hning?=) Date: Mon, 9 Apr 2018 19:02:49 +0200 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: +1 Am 09.04.2018 um 14:17 schrieb Maurice Kalinowski: > Hi, > > As some might have recognized my focus inside the Qt Company has shifted from WinRT/UWP towards our Automation related offering. While I still review many patches for this platform, my effort in terms of active development have significantly reduced. > > Consequently, I would like to propose Oliver Wolff to take over the role as platform maintainer. Oliver has been part of the team for years and (besides lots of other things) has been taking care of the networking parts. In addition to that, he has been "shadow-maintaining" the port over the last year, so this would rather reflect reality. > > https://codereview.qt-project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolff%2540qt.io%253E%22,n,z > > BR, > Maurice > > P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the maintainer list, contrary to me when I took it over from Andrew :) > > -- > Maurice Kalinowski > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > maurice.kalinowski at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > From jpnurmi at qt.io Mon Apr 9 20:31:18 2018 From: jpnurmi at qt.io (J-P Nurmi) Date: Mon, 9 Apr 2018 18:31:18 +0000 Subject: [Development] [Google Summer of Code] [Project Ideas] Qt Quick Controls 2 Sailfish Silica Style In-Reply-To: References: <3659321522751917@web57g.yandex.ru> Message-ID: <12A34806-C2EA-4FB1-A9A6-F3E1B3DABBEA@qt.io> > On 6 Apr 2018, at 17:39, Alexander Akulich wrote: > > Hi all, > > I highly doubt that it can be done as a part of GSoC and I don't see > any point in moving this to QtProject as we don't have Sailfish OS > platform upstreamed. We just need this style to make QQC2 applications > look native on Sailfish OS. I think that we'll have to rely on > closed-yet components and the style is not going to look nice with > mocks. > > That said, I see a number of issues and I hope that we'll discuss and > agree on some changes to the QQC2 API: > 1) I would like to propose ComboDelegate — a pair of ComboBox and > Label, combined in a platform-specific way (similar to CheckDelegate > and RadioDelegate). > 2) We also need a delegate to display a label and an associated value. > It is named "DetailItem" in Silica, but I would agree to go with a > name like ValueDelegate. > 3) Yet another point is that we need to properly style delegate > descriptions, so I want to propose "description" property at least for > Combo, Radio and Switch delegates (we even don't have a 'buddy' > property here, though it still would be very hacky to go in this way). > > Probably it makes sense to start another thread to discuss Qt Quick > Controls 2 API, but I need at least three weeks to think and > experiment with what we have right now. :-) > > My work is available at > https://git.merproject.org/Kaffeine/qtsilicastyle (compatible with Qt > 5.9 and 5.10), but I don't think that it can be interesting for anyone > in its current shape. Hi all, +1 for any QQC2 additions and enablers that make it easier to implement the Silica style. That is, as long as the changes make sense from cross-platform perspective i.e. make sense for the other styles too. The proposed changes sound like they do. :) -- J-P Nurmi From jpnurmi at qt.io Mon Apr 9 20:40:10 2018 From: jpnurmi at qt.io (J-P Nurmi) Date: Mon, 9 Apr 2018 18:40:10 +0000 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: > On 9 Apr 2018, at 14:17, Maurice Kalinowski wrote: > > Hi, > > As some might have recognized my focus inside the Qt Company has shifted from WinRT/UWP towards our Automation related offering. While I still review many patches for this platform, my effort in terms of active development have significantly reduced. > > Consequently, I would like to propose Oliver Wolff to take over the role as platform maintainer. Oliver has been part of the team for years and (besides lots of other things) has been taking care of the networking parts. In addition to that, he has been "shadow-maintaining" the port over the last year, so this would rather reflect reality. > > https://codereview.qt-project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolff%2540qt.io%253E%22,n,z +1 -- J-P Nurmi From Shawn.Rutledge at qt.io Mon Apr 9 20:41:31 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Mon, 9 Apr 2018 18:41:31 +0000 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: <9432EF09-E262-4B19-BC7B-C07E84F500D7@qt.io> > On 9 Apr 2018, at 14:17, Maurice Kalinowski wrote: > > Hi, > > As some might have recognized my focus inside the Qt Company has shifted from WinRT/UWP towards our Automation related offering. While I still review many patches for this platform, my effort in terms of active development have significantly reduced. > > Consequently, I would like to propose Oliver Wolff to take over the role as platform maintainer. +1 From lars.knoll at qt.io Tue Apr 10 07:58:14 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Tue, 10 Apr 2018 05:58:14 +0000 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: <9432EF09-E262-4B19-BC7B-C07E84F500D7@qt.io> References: <9432EF09-E262-4B19-BC7B-C07E84F500D7@qt.io> Message-ID: Another +1. Cheers, Lars > On 9 Apr 2018, at 20:41, Shawn Rutledge wrote: > > >> On 9 Apr 2018, at 14:17, Maurice Kalinowski wrote: >> >> Hi, >> >> As some might have recognized my focus inside the Qt Company has shifted from WinRT/UWP towards our Automation related offering. While I still review many patches for this platform, my effort in terms of active development have significantly reduced. >> >> Consequently, I would like to propose Oliver Wolff to take over the role as platform maintainer. > > +1 > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From alexander.blasche at qt.io Tue Apr 10 08:26:53 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 10 Apr 2018 06:26:53 +0000 Subject: [Development] Nominating Valentyn Doroshchuk for Approver status In-Reply-To: References: Message-ID: Congratulations to Valentyn. Approver rights have been set. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Christian > Strømme > Sent: Tuesday, 20 March 2018 13:56 > To: development at qt-project.org > Subject: [Development] Nominating Valentyn Doroshchuk for Approver status > > Hi, > > I'd like to nominate Valentyn Doroshchuk for Approver status. Val has been > working full time for The Qt Company since mid 2017, and has and has actively > been fixing and improving QtMultimedia since (which includes upstream fixes to > GStreamer). > > This is his dashboard: > https://codereview.qt- > project.org/#/q/owner:%22VaL+Doroshchuk%22+status:merged,n,z > > > -- > Christian > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Tue Apr 10 10:56:35 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 10 Apr 2018 08:56:35 +0000 Subject: [Development] Qt 5.11 Beta3 released In-Reply-To: References: Message-ID: Hi all, Qt 5.11 beta3 is released today. As usual you can get it via online installer. Delta to beta2 as an attachment. Please test the release now. It seems we are really close to RC already so please make sure all release blockers are visible in RC blocker list (https://bugreports.qt.io/issues/?filter=19209). And also fix all blockers from the list immediately. We will start preparations for RC soon and I hope there won't be any late blocker findings at this time... br, Jani -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delta_qt511-beta2-qt511-beta3_changes.txt URL: From alexander.blasche at qt.io Wed Apr 11 08:38:09 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Wed, 11 Apr 2018 06:38:09 +0000 Subject: [Development] Proposing Albert Astals Cid for Approver In-Reply-To: <7768537419eb3a899b639c7172d353cd@kdab.com> References: <7768537419eb3a899b639c7172d353cd@kdab.com> Message-ID: Congratulations. Rights have been adjusted. -- Alex ________________________________________ From: Development on behalf of Sérgio Martins Sent: Wednesday, 21 March 2018 12:33:06 PM To: development at qt-project.org Subject: [Development] Proposing Albert Astals Cid for Approver Hi, Albert has been a long time contributor to KDE and Qt and very well known in the community. His dashboards speak for himself, with many bugs fixed: (For some reason pasting-and-opening URLs from gerrit is broken, so you'll have to search yourself) at KDAB: owner:"Albert Astals Cid " at Canonical: owner:albert.astals at canonical.com on his free-time with KDE hat: owner:"Albert Astals Cid " And recently he was tricked into fixing many printing and CUPS bugs, so thanks Albert! Disclaimer: He's a collegue of mine at KDAB, knew him from KDE and lives somewhat near me, in the Iberian peninsula. Regards, -- Sérgio Martins | sergio.martins at kdab.com | Senior 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, C++ and OpenGL Experts _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From arichardson.kde at gmail.com Wed Apr 11 10:13:09 2018 From: arichardson.kde at gmail.com (Alexander Richardson) Date: Wed, 11 Apr 2018 09:13:09 +0100 Subject: [Development] How to run QtBase autotests on a remote machine? Message-ID: Hello, I am currently trying to get Qt to work on the CHERI CPU (http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html) running a modified version of FreeBSD. CHERI is a capability architecture with 128-bit pointers (memory capabilities) and unlike on most other CPU architectures pointers are *not* the same as a integers [1]. Compared to other programs and libraries that I have modified to run on CHERI QtCore has been quite straightforward [2]. I was pleasantly surprised by how easy it was to get the configure checks to pass and add the required custom command line flags to the build systems. I have now managed to get the first few unit tests to build and run as CHERI pure capability programs so I would like to run the full test suite. Currently I build the tests and then scp individual tst_foo binaries to the host and run them manually. In order to fix the initial porting problems that will show up in most tests this is fine. However, now I would like to run the full test suite to find any other issues in Qt and/or our compiler/OS libraries/kernel. I cannot run the compiler on the target platform due to memory and CPU speed constraints so I need to cross-compile everything [3]. Is there any existing mechanism to run the unit tests on a machine other than the compilation host? I have noticed that there is a target_wrapper.sh script in every test directory. Can that be modified to execute scp and ssh to run the test remotely? Currently, I am only attempting to run statically linked tests, but once I have managed that I would also like to run them dynamically linked which will probably require copying more files and setting QT_PLUGIN_PATH. Thanks, Alex [1] In CHERI we use capabilities instead of pointers. Our capabilities hold a virtual address as well as metadata describing the memory resources referenced by the pointer (bounds, permissions, ...) and also a 1-bit tag that protects the pointer itself (integrity, valid provenance, ...). This tag bit is cleared when a capability is overwritten with plain data so there is no way integers and pointers can be confused. [2] The only real incompatibility I have found so far is that QArrayData::data() stores an offset to the data instead of a pointer. On CHERI pointers can only be created by subsetting an existing capability. For the common case where the string data is part of the same allocation as the QArrayData header using `return (char*)this + offset` also works since it is just setting an offset in the allocated memory region. However, the fromRawData() case does not work since that requires creating a pointer that is out of bounds of the QArrayData allocation and will cause a trap when accessed. Other than this the majority of the work so far was changes to our compiler+linker and the OS libraries. We have so far focussed mostly on software written in C (and the libc++ testsuite) so compiling Qt has exposed quite a few compiler crashes since it is the first big C++ project we have attempted to port. [3] We can currently run CHERI code on QEMU (https://github.com/CTSRD-CHERI/qemu) or on an FPGA running at about 100MHz. I could theoretically attempt to run a MIPS version of clang in QEMU but it is so slow that using that approach is not feasible. From olszak.tomasz at gmail.com Wed Apr 11 11:00:59 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 11 Apr 2018 11:00:59 +0200 Subject: [Development] Conventions for using qmlRegisterType in qtdeclarative Message-ID: Hello, In [1] Michael Brasser pointed out that I should introduce new revision after adding new property to QQmlLoggingCategory. First question: 1. Why in [2] QQuickTextInput is registered for versions > 9 with revision 0? I would expect that it should be registered with revision 9 for imports >= 2.9. Am I missing something? 2. What is the convention regarding revisions? What should be QQmlLoggingCategory::defaultLogLevel revision if I add the property in Qt 5.12 (1 or 12) I would like to kindly ask someone experienced in this area to review [1] [1] https://codereview.qt-project.org/#/c/224198 [1] https://code.woboq.org/qt5/qtdeclarative/src/quick/items/qquickitemsmodule.cpp.html Thanks in advance From olivier at woboq.com Wed Apr 11 14:06:40 2018 From: olivier at woboq.com (Olivier Goffart) Date: Wed, 11 Apr 2018 14:06:40 +0200 Subject: [Development] Conventions for using qmlRegisterType in qtdeclarative In-Reply-To: References: Message-ID: <15ae4b29-89c9-d04f-d767-f056b5fe1e7b@woboq.com> On 2018-04-11 11:00, Tomasz Olszak wrote: > Hello, > In [1] Michael Brasser pointed out that I should introduce new > revision after adding new property to QQmlLoggingCategory. > > First question: > 1. Why in [2] QQuickTextInput is registered for versions > 9 with > revision 0? I would expect that it should be registered with revision > 9 for imports >= 2.9. Am I missing something? > 2. What is the convention regarding revisions? What should be > QQmlLoggingCategory::defaultLogLevel revision if I add the property in > Qt 5.12 (1 or 12) > > I would like to kindly ask someone experienced in this area to review [1] > > [1] https://codereview.qt-project.org/#/c/224198 > [1] https://code.woboq.org/qt5/qtdeclarative/src/quick/items/qquickitemsmodule.cpp.html That's because this revision thingy is both confusing, error prone, and IMHO useless. If it was me, this should never have been done. To answer your question more precisely: 1. It apprars QQuickTextInput is not explicitly registered for version > 9, so it is implicitly the same as the version 9 which is fine for there are no revision higher than 9 in that class 2. From what I can see, the usage in qquickitemsmodule.cpp is mixed. I'd argue that 12 would make it less confusing and error prone. You may want to hear another more objective opinion though :-). -- Olivier Woboq - Qt services and support - https://woboq.com - https://code.woboq.org From edward.welbourne at qt.io Wed Apr 11 14:06:43 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 11 Apr 2018 12:06:43 +0000 Subject: [Development] How to run QtBase autotests on a remote machine? In-Reply-To: References: Message-ID: Alexander Richardson (11 April 2018 10:13) > I am currently trying to get Qt to work on the CHERI CPU > (http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html) Sounds interesting. > I have now managed to get the first few unit tests to build and run as > CHERI pure capability programs Impressive :^> > so I would like to run the full test suite. Makes sense. > Currently I build the tests and then scp individual tst_foo binaries > to the host and run them manually. In order to fix the initial porting > problems that will show up in most tests this is fine. Some tests shall need more than the binary; e.g. data files to act on. > Is there any existing mechanism to run the unit tests on a machine > other than the compilation host? I hope so - does anyone know how we test on Android, iOS or any other cross-compilation target ? Or do we even support testing on them ? > I have noticed that there is a target_wrapper.sh script in every test > directory. Can that be modified to execute scp and ssh to run the test > remotely? That sounds like a promising line of enquiry - except that I can't find where we generate target_wrapper.sh - the word target_wrapper doesn't appear to exist in our source tree (aside from a couple of .gitignore files). If you can find what creates these scripts, hacking it would be one way to go. However, finding out how we test on other cross-compilation platforms may save you a whole lot of work ... Eddy. From olszak.tomasz at gmail.com Wed Apr 11 14:17:34 2018 From: olszak.tomasz at gmail.com (Tomasz Olszak) Date: Wed, 11 Apr 2018 14:17:34 +0200 Subject: [Development] Conventions for using qmlRegisterType in qtdeclarative In-Reply-To: <15ae4b29-89c9-d04f-d767-f056b5fe1e7b@woboq.com> References: <15ae4b29-89c9-d04f-d767-f056b5fe1e7b@woboq.com> Message-ID: Thanks Oliver, Some things has been cleared out in gerrit comments. I would like to thank Mitch Curtis and J-P Nurmi for help! I stayed with revision 1 for the time being. 2018-04-11 14:06 GMT+02:00 Olivier Goffart : > On 2018-04-11 11:00, Tomasz Olszak wrote: >> >> Hello, >> In [1] Michael Brasser pointed out that I should introduce new >> revision after adding new property to QQmlLoggingCategory. >> >> First question: >> 1. Why in [2] QQuickTextInput is registered for versions > 9 with >> revision 0? I would expect that it should be registered with revision >> 9 for imports >= 2.9. Am I missing something? >> 2. What is the convention regarding revisions? What should be >> QQmlLoggingCategory::defaultLogLevel revision if I add the property in >> Qt 5.12 (1 or 12) >> >> I would like to kindly ask someone experienced in this area to review [1] >> >> [1] https://codereview.qt-project.org/#/c/224198 >> [1] >> https://code.woboq.org/qt5/qtdeclarative/src/quick/items/qquickitemsmodule.cpp.html > > > That's because this revision thingy is both confusing, error prone, and IMHO > useless. > If it was me, this should never have been done. > > To answer your question more precisely: > > 1. It apprars QQuickTextInput is not explicitly registered for version > 9, > so it is implicitly the same as the version 9 which is fine for there are no > revision higher than 9 in that class > > 2. From what I can see, the usage in qquickitemsmodule.cpp is mixed. I'd > argue that 12 would make it less confusing and error prone. > You may want to hear another more objective opinion though :-). > > -- > Olivier > > Woboq - Qt services and support - https://woboq.com - https://code.woboq.org > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Tor.arne.Vestbo at qt.io Wed Apr 11 14:22:16 2018 From: Tor.arne.Vestbo at qt.io (=?iso-8859-1?Q?Tor_Arne_Vestb=F8?=) Date: Wed, 11 Apr 2018 12:22:16 +0000 Subject: [Development] How to run QtBase autotests on a remote machine? In-Reply-To: References: Message-ID: <36848084-96A7-404C-BB04-29BA9446CDF5@qt.io> > > I cannot run the compiler on the target platform due to memory and CPU > speed constraints so I need to cross-compile everything [3]. > Is there any existing mechanism to run the unit tests on a machine > other than the compilation host? Mount the tests on the device (sshfs e.g.), and run the tests there. Or, if you want to be fancy, on the host, export TESTRUNNER=wrapper.sh, where wrapper.sh does something like ssh device $* Tor Arne From joerg.bornemann at qt.io Thu Apr 12 07:29:51 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Thu, 12 Apr 2018 07:29:51 +0200 Subject: [Development] How to run QtBase autotests on a remote machine? In-Reply-To: References: Message-ID: <5118723d-a07b-1b8b-6fa5-e57b152e9ec0@qt.io> On 04/11/2018 02:06 PM, Edward Welbourne wrote: > That sounds like a promising line of enquiry - except that I can't find > where we generate target_wrapper.sh - the word target_wrapper doesn't > appear to exist in our source tree (aside from a couple of .gitignore > files). The wrapper script is generated in qtbase/mkspecs/features/qt_functions.prf by qtAddToolEnv. The qtPrepareTool calls in our project files trigger the wrapper generation. Cheers, Joerg From kari.oikarinen at qt.io Thu Apr 12 08:02:21 2018 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Thu, 12 Apr 2018 09:02:21 +0300 Subject: [Development] How to run QtBase autotests on a remote machine? In-Reply-To: References: Message-ID: <2a573ef2-4f76-d2c0-ba8e-91d3e1419bb3@qt.io> On 11.04.2018 15:06, Edward Welbourne wrote: > Alexander Richardson (11 April 2018 10:13) >> I am currently trying to get Qt to work on the CHERI CPU >> (http://www.cl.cam.ac.uk/research/security/ctsrd/cheri/cheri-faq.html) > > Sounds interesting. > >> I have now managed to get the first few unit tests to build and run as >> CHERI pure capability programs > > Impressive :^> > >> so I would like to run the full test suite. > > Makes sense. > >> Currently I build the tests and then scp individual tst_foo binaries >> to the host and run them manually. In order to fix the initial porting >> problems that will show up in most tests this is fine. > > Some tests shall need more than the binary; e.g. data files to act on. Unfortunately I don't know of a better way. I asked people who have been working on the INTEGRITY port and they've also just made static builds of test executables and then copied them over to the device to be run. > >> Is there any existing mechanism to run the unit tests on a machine >> other than the compilation host? > > I hope so - does anyone know how we test on Android, iOS or any other > cross-compilation target ? Or do we even support testing on them ? > When it comes to CI, tests don't seem to be run on Android and iOS targets. There are two cross-compilation targets (Linux arm64 and armv7) that are tested, but those are under QEMU emulation, not on real hardware. For QEMU tests the tests are run in the folder they were built in under emulation, so they don't offer any hints on a good process for testing in a real device. -- Kari From Maurice.Kalinowski at qt.io Thu Apr 12 08:06:16 2018 From: Maurice.Kalinowski at qt.io (Maurice Kalinowski) Date: Thu, 12 Apr 2018 06:06:16 +0000 Subject: [Development] How to run QtBase autotests on a remote machine? In-Reply-To: <2a573ef2-4f76-d2c0-ba8e-91d3e1419bb3@qt.io> References: <2a573ef2-4f76-d2c0-ba8e-91d3e1419bb3@qt.io> Message-ID: Hi, > >> Currently I build the tests and then scp individual tst_foo binaries >> to the > host and run them manually. In order to fix the initial porting >> problems that > will show up in most tests this is fine. > > > > Some tests shall need more than the binary; e.g. data files to act on. > [Kalinowski Maurice] Check for testdata or builtin_testdata, I do not recall the precise name right now. Basically you can specify whether you want the data to be copied or use qrc to integrate it to the app. The test system then automatically extracts it on the target hardware during execution and uses it. > > > > When it comes to CI, tests don't seem to be run on Android and iOS targets. > There are two cross-compilation targets (Linux arm64 and armv7) that are > tested, but those are under QEMU emulation, not on real hardware. [Kalinowski Maurice] Correct, Oliver is currently working on getting UWP into it, it shares a lot of concepts with other remote targets. So when we started on it there were a couple of infrastructural things to clarify (like builtin_testdata from above). >From what I know the other platforms might come at a later point, but should be easier to do, as the technical building blocks are available. Maurice From jani.heikkinen at qt.io Thu Apr 12 10:42:29 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 12 Apr 2018 08:42:29 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: Message-ID: Hi, It is time to start freezing Qt 5.12 schedule. We have the same "limitation" as earlier; we should get the release out well before Christmas time. And it seems we can't cut the time needed from FF to final release that much. It seems we aren't necessarily needing those 17 weeks as before but quite close. So here is my proposal for the schedule: - Soft branching from 'dev' to '5.12' starts 13.8.2018 - Qt 5.12 Feature freeze & finalize branching 20.8.2018 - Final release 29.11.2018 And at this same time I want to propose that we stop delivering alpha or beta releases and just do snapshots instead. Publishing regular snapshots should be done until we are ready for RC. That because I don't see that much need for those anymore. Those are nowadays kind of milestones and in my opinion makes whole process a bit unclear/difficult (we don't have very good definitions for Alpha and Beta releases). So my proposal is: - We start creating (regular) snapshots for Qt 5.12 as soon as possible & continue to publish those until we are ready for RC. - When branching from 'dev' to '5.12' is ready FF is in effect. As earlier new features can't go in after this & we are focusing to fix the bugs & maturing the release - We do API review for release immediately after FF. Discussion about API review process here: http://lists.qt-project.org/pipermail/development/2018-March/032338.html - String freeze will be in effect few weeks (4?) after FF - We keep release blocker list as earlier and when list is clear we branch from 5.12 -> 5.12.0 and do the first RC from release branch - If RC isn't good enough for the final release we just fix those remaining issues and do new RC(s) until we are ready for final release br, Jani Heikkinen Release Manager From jani.heikkinen at qt.io Thu Apr 12 11:18:19 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 12 Apr 2018 09:18:19 +0000 Subject: [Development] Maintainers, your action needed: Please check if 3rd party components needs to be updated for Qt 5.11 release Message-ID: Hi! Please check if some 3rd party component needs to be updated for Qt 5.11 release. And of course do needed updates now :D List of 3rd party components here: http://doc.qt.io/qt-5/licenses-used-in-qt.html br, Jani From frederik.gladhorn at qt.io Thu Apr 12 13:26:29 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Thu, 12 Apr 2018 13:26:29 +0200 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: <2447224.V4FPlrJP6q@frederik-thinkcentre-m93p> +1 Cheers, Frederik (And a big thank you to both Oliver and Maurice for cleaning up all kinds of provisioning stuff on Windows lately!) On mandag 9. april 2018 14.17.34 CEST Maurice Kalinowski wrote: > Hi, > > As some might have recognized my focus inside the Qt Company has shifted > from WinRT/UWP towards our Automation related offering. While I still > review many patches for this platform, my effort in terms of active > development have significantly reduced. > > Consequently, I would like to propose Oliver Wolff to take over the role as > platform maintainer. Oliver has been part of the team for years and > (besides lots of other things) has been taking care of the networking > parts. In addition to that, he has been "shadow-maintaining" the port over > the last year, so this would rather reflect reality. > > https://codereview.qt-project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolf > f%2540qt.io%253E%22,n,z > > BR, > Maurice > > P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the > maintainer list, contrary to me when I took it over from Andrew :) > > -- > Maurice Kalinowski > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > maurice.kalinowski at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, > HRB 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Thu Apr 12 13:46:46 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 12 Apr 2018 11:46:46 +0000 Subject: [Development] Qt 5.9.5 released In-Reply-To: References: Message-ID: Hi all, We have release Qt 5.9.5 today, see http://blog.qt.io/blog/2018/04/12/qt-5-9-5-released/ . Big thanks to everyone involved! Br, Jani From bstottle at ford.com Thu Apr 12 14:29:02 2018 From: bstottle at ford.com (Stottlemyer, Brett (B.S.)) Date: Thu, 12 Apr 2018 12:29:02 +0000 Subject: [Development] How to run QtBase autotests on a remote machine? In-Reply-To: References: <2a573ef2-4f76-d2c0-ba8e-91d3e1419bb3@qt.io> Message-ID: <7144B5A7-233F-4542-BAC8-B62E47BB9A2E@ford.com> On 4/12/18, 2:07 AM, "Development on behalf of Maurice Kalinowski" wrote: > > > Some tests shall need more than the binary; e.g. data files to act on. > > > [Kalinowski Maurice] > Check for testdata or builtin_testdata, I do not recall the precise name right now. > > Basically you can specify whether you want the data to be copied or use qrc to integrate it to the app. The test system then automatically extracts it on the target hardware during execution and uses it. > Oliver is currently working on getting UWP into it, it shares a lot of concepts with other remote targets. So when we started on it there were a couple of infrastructural things to clarify (like builtin_testdata from above). > From what I know the other platforms might come at a later point, but should be easier to do, as the technical building blocks are available. I tested out a different approach, although it is not clear if the above work will end up making it obsolete. I added another subproject to QtCreator to build a headless application/tool that could leverage the code in QtC to parse .pro files and run ssh/scp functions. Given a source and build directory, it could detect the files that should be copied to target move them, then optionally run additional commands over ssh. The idea being that if QtC is smart enough to deploy from the IDE, make the same functionality accessible from the command line. Unfortunately, QtC doesn’t not have the same binary compatibility constraints of Qt libs, so it seemed to need updates for every new QtC version. IIRC, having it parse the project file with `QT_BUILD_PARTS+=tests` would include the test executables and dependencies. The idea was to have some that ran from the command line and could be integrated with CI, although we haven’t had time to do that integration. It had code paths for Qt modules as well as end-user projects. If there is interest in making this part of QtC itself, I could push the code (built against QtC 4.4.1) to gerrit for review. Regards, Brett From jani.heikkinen at qt.io Thu Apr 12 15:52:53 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Thu, 12 Apr 2018 13:52:53 +0000 Subject: [Development] HEADS-UP: Branching '5.11.0' from '5.11' started Message-ID: Hi all, We have soft branched '5.11.0' from '5.11'. Please start using '5.11.0' for new changes targeted to Qt 5.11.0 release. Final downmerge from '5.11' to '5.11.0' will happen Thursday 19th April so there should be enough time to finalize ongoing changes in '5.11' and start using '5.11.0' for new ones. We are targeting to release Qt 5.11.0 rc before end of April so please make sure all blockers are fixed immediately. Qt 5.11.0 RC blocker list here: https://bugreports.qt.io/issues/?filter=19209 br, Jani Heikkinen Release Manager From thiago.macieira at intel.com Thu Apr 12 17:44:25 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Thu, 12 Apr 2018 08:44:25 -0700 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: Message-ID: <1691604.Q5BBe59CSV@tjmaciei-mobl1> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: > And at this same time I want to propose that we stop delivering alpha or > beta releases and just do snapshots instead. Publishing regular snapshots > should be done until we are ready for RC. That because I don't see that > much need for those anymore. Those are nowadays kind of milestones and in > my opinion makes whole process a bit unclear/difficult (we don't have very > good definitions for Alpha and Beta releases). Yes we do. Alpha means feature complete, asking for feedback on the API and new functionality. Beta means implementation complete, asking for feedback on the quality of the implementation, seeking bugs and regressions to be fixed. RC means we've fixed everything we knew. So I don't agree with calling those releases snapshots. The naming is just a convention to let people know what the current state is. We already have too few people who test our betas, so if we stop calling them that, we'll have even fewer. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From maxim.like.python at ya.ru Fri Apr 13 21:06:45 2018 From: maxim.like.python at ya.ru (=?utf-8?B?0KHQvNC40YDQvdC+0LIg0JzQsNC60YHQuNC8?=) Date: Fri, 13 Apr 2018 22:06:45 +0300 Subject: [Development] Qt3D - QTextureLoader feature request Message-ID: <2407571523646405@web39j.yandex.ru> An HTML attachment was scrubbed... URL: From erikluor at gmail.com Sun Apr 15 07:22:51 2018 From: erikluor at gmail.com (Erik Luo) Date: Sat, 14 Apr 2018 23:22:51 -0600 Subject: [Development] Language server for Qt Creator IDE Message-ID: Hi all, I am pretty interested in the language server for Qt Creator IDE. I have learned the functionality on other related IDEs. I hope I can add this functionality perfectly into Qt Creator. Is there a more detailed introduction about how should this language server behave in Qt Creator? So I can implement the language server right away and test it as soon as possible. I am willing to contribute on this part for my favorite IDE! Thank you! Cheers, Erik -------------- next part -------------- An HTML attachment was scrubbed... URL: From abbapoh at gmail.com Sun Apr 15 17:32:30 2018 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sun, 15 Apr 2018 18:32:30 +0300 Subject: [Development] qdds image format Message-ID: Hello, what happened to the qdds image plugin? I found the note in the docs: "For security reasons, the Direct Draw Surface (DDS) handler is not built by default since Qt 5.8" but could not find any open issues. Does anyone know what are those "security reasons"? What need to be done to return the plugin to the default build? -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Sun Apr 15 17:59:45 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 15 Apr 2018 17:59:45 +0200 Subject: [Development] qdds image format In-Reply-To: References: Message-ID: <38ccf018-6455-5750-0d19-4e462cabca8f@kdab.com> Il 15/04/2018 17:32, Иван Комиссаров ha scritto: > Hello, what happened to the qdds image plugin? > I found the note in the docs: "For security reasons, the Direct Draw > Surface (DDS) handler is not built by default since Qt 5.8" but could > not find any open issues. > Does anyone know what are those "security reasons"? The usual amount of parsing a file without doing bounds checks, so making the user vulnerable to crashes / code execution / overflows and the like. > What need to be done to return the plugin to the default build? Build it yourself; as far as I know it's still shipped as part of qtimageformats. Apart from the quality of the implementation, there is close to zero reasons to use DDS as an image format plugin in Qt: a DDS file represents a texture, not an image (so the generic access through QImageReader isn't enough), and QImage can't represent the formats that you can store in a DDS anyhow. Note that the above has nothing to do with DDS support in Qt3D, which has never used the image format plugin. Hope this helps, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From abbapoh at gmail.com Sun Apr 15 18:14:02 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Sun, 15 Apr 2018 19:14:02 +0300 Subject: [Development] qdds image format In-Reply-To: <38ccf018-6455-5750-0d19-4e462cabca8f@kdab.com> References: <38ccf018-6455-5750-0d19-4e462cabca8f@kdab.com> Message-ID: > 15 апр. 2018 г., в 18:59, Giuseppe D'Angelo написал(а): > > Il 15/04/2018 17:32, Иван Комиссаров ha scritto: >> Hello, what happened to the qdds image plugin? >> I found the note in the docs: "For security reasons, the Direct Draw Surface (DDS) handler is not built by default since Qt 5.8" but could not find any open issues. >> Does anyone know what are those "security reasons"? > > The usual amount of parsing a file without doing bounds checks, so making the user vulnerable to crashes / code execution / overflows and the like. Are there any tickets on Jira related? All tickets i found are fixed and closed long ago (Qt5.5) > >> What need to be done to return the plugin to the default build? > > Build it yourself; as far as I know it's still shipped as part of qtimageformats. I’m asking because I’m, the original author of the DDS plugin and I’m disappointed my work is thrown away:( > > Apart from the quality of the implementation, there is close to zero reasons to use DDS as an image format plugin in Qt: a DDS file represents a texture, not an image (so the generic access through QImageReader isn't enough), and QImage can't represent the formats that you can store in a DDS anyhow. The reason i started the work is to convert to/from DDS files because existing converters (PS/GIMP plugins and microsoft tool are not ideal, GIMP plugin is really buggy). However, i stucked because of the limitations of the QImageWriter API (which can’t be changedun till Qt6). I can fix the security issues and move the dds reading/writing code to the separate lib so it can be shared with Qt 3d (i saw the duplication of the DDSHeader at least) and not be dependent on the QImageIoPlugin API which is flawed. > > Note that the above has nothing to do with DDS support in Qt3D, which has never used the image format plugin. Yep, it used the DDSHeader only when i looked at the code From giuseppe.dangelo at kdab.com Sun Apr 15 21:59:35 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Sun, 15 Apr 2018 21:59:35 +0200 Subject: [Development] qdds image format In-Reply-To: References: <38ccf018-6455-5750-0d19-4e462cabca8f@kdab.com> Message-ID: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> Hello, Il 15/04/2018 18:14, Иван Комиссаров ha scritto: >> The usual amount of parsing a file without doing bounds checks, so making the user vulnerable to crashes / code execution / overflows and the like. > > Are there any tickets on Jira related? All tickets i found are fixed and closed long ago (Qt5.5) I'm not sure if it was reported on Jira or through a security notification. I'm thinking about the latter, around the time where we fuzzed Qt's image formats. >>> What need to be done to return the plugin to the default build? >> >> Build it yourself; as far as I know it's still shipped as part of qtimageformats. > > I’m asking because I’m, the original author of the DDS plugin and I’m disappointed my work is thrown away:( Sorry about that... just a matter of evolution of the code. But, as I said, the code itself should be still shipped, just not built by default. > The reason i started the work is to convert to/from DDS files because existing converters (PS/GIMP plugins and microsoft tool are not ideal, GIMP plugin is really buggy). However, i stucked because of the limitations of the QImageWriter API (which can’t be changedun till Qt6). What do you mean? What has Qt to do in terms of converters? From my personal experience texconv / texassemble are probably the best tools in terms of creating DDS files. Recently ImageMagick also has got some support, however I found it still extremely buggy. > I can fix the security issues and move the dds reading/writing code to the separate lib so it can be shared with Qt 3d (i saw the duplication of the DDSHeader at least) and not be dependent on the QImageIoPlugin API which is flawed. In the broader plan of things Qt should get some convenience APIs for loading from texture files; these APIs should sit in QtGui and then be used by Qt3D, QtQuick and so on. I don't see it useful to revamp the DDS image loader just for this purpose. To say it all: such a thing in QtGui (QOpenGLTexture::loadFromFile?) should just use GLI or some other similar library, so we make it SEP and also support a bunch of formats in one go. My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: Firma crittografica S/MIME URL: From thiago.macieira at intel.com Sun Apr 15 23:41:30 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 15 Apr 2018 14:41:30 -0700 Subject: [Development] qdds image format In-Reply-To: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> Message-ID: <1729744.hIf54J7YqV@tjmaciei-mobl1> On Sunday, 15 April 2018 12:59:35 PDT Giuseppe D'Angelo wrote: > Hello, > > Il 15/04/2018 18:14, Иван Комиссаров ha scritto: > >> The usual amount of parsing a file without doing bounds checks, so making > >> the user vulnerable to crashes / code execution / overflows and the > >> like.> > > Are there any tickets on Jira related? All tickets i found are fixed and > > closed long ago (Qt5.5) > I'm not sure if it was reported on Jira or through a security > notification. I'm thinking about the latter, around the time where we > fuzzed Qt's image formats. I don't think it was reported against DDS. We fuzzed all the image format readers after a report against one of them. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From thiago.macieira at intel.com Mon Apr 16 05:41:22 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Sun, 15 Apr 2018 20:41:22 -0700 Subject: [Development] FYI: MSVC 2017 15.7 should fix static libraries Message-ID: <1720051.ZFHTqy9zqq@tjmaciei-mobl1> See https://developercommunity.visualstudio.com/content/problem/76198/vs-2017-compiler-creates-broken-debug-build-using.html The fix is slated for 15.7. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From alexander.blasche at qt.io Mon Apr 16 08:12:37 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 16 Apr 2018 06:12:37 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: <1691604.Q5BBe59CSV@tjmaciei-mobl1> References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> Message-ID: > -----Original Message----- > On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: > > And at this same time I want to propose that we stop delivering alpha > > or beta releases and just do snapshots instead. Publishing regular > > snapshots should be done until we are ready for RC. That because I > > don't see that much need for those anymore. Those are nowadays kind of > > milestones and in my opinion makes whole process a bit > > unclear/difficult (we don't have very good definitions for Alpha and Beta > releases). > > Yes we do. > > Alpha means feature complete, asking for feedback on the API and new > functionality. > > Beta means implementation complete, asking for feedback on the quality of the > implementation, seeking bugs and regressions to be fixed. > > RC means we've fixed everything we knew. I wholeheartedly agree with Thiago. The distinction may not make a difference from the release team perspective but it makes a world of difference for developers (who have different limitations for each step) and the world as they can decide how bleeding edge the code is that they want to test. I have a problem with the motivation behind this suggestion too (don't understand it). The naming makes no difference for you as release manager (afaict just a label). Why suggesting it aka what do you want to gain by doing snapshots only? -- Alex From Simon.Hausmann at qt.io Mon Apr 16 08:43:50 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Mon, 16 Apr 2018 06:43:50 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1>, Message-ID: <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> Hi, Same here. At first this seemed like a good idea, but it becomes awkward when you look at it from the dev workflow point of view: After fixing a bug, what is the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? That sounds like it would create a mess in JIRA. Unless of course the task of assigning the fix version field was automated. Simon On 16. Apr 2018, at 08:12, Alex Blasche wrote: >> -----Original Message----- >>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: >>> And at this same time I want to propose that we stop delivering alpha >>> or beta releases and just do snapshots instead. Publishing regular >>> snapshots should be done until we are ready for RC. That because I >>> don't see that much need for those anymore. Those are nowadays kind of >>> milestones and in my opinion makes whole process a bit >>> unclear/difficult (we don't have very good definitions for Alpha and Beta >> releases). >> >> Yes we do. >> >> Alpha means feature complete, asking for feedback on the API and new >> functionality. >> >> Beta means implementation complete, asking for feedback on the quality of the >> implementation, seeking bugs and regressions to be fixed. >> >> RC means we've fixed everything we knew. > > I wholeheartedly agree with Thiago. The distinction may not make a difference from the release team perspective but it makes a world of difference for developers (who have different limitations for each step) and the world as they can decide how bleeding edge the code is that they want to test. > > I have a problem with the motivation behind this suggestion too (don't understand it). The naming makes no difference for you as release manager (afaict just a label). Why suggesting it aka what do you want to gain by doing snapshots only? > -- > Alex > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From tuukka.turunen at qt.io Mon Apr 16 08:59:36 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Mon, 16 Apr 2018 06:59:36 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> Message-ID: Hi, I very much like continuous flow of snapshots. Sometimes we have a tendency to fall into a "let's wait and get still this one fix in" mode, which is very inefficient. It is beneficial when making .x patch releases and the fix is for a regression. But in other situations, it is typically more important to have a frequent flow of releases. From that viewpoint I support what Jani proposed. Every period of wait we add makes the release process: 1. longer and 2. unpredicted. We should aim to make the process of creating a new feature release of Qt faster than it is today, so challenging the current process is a good thing. We are working on enabling regular snapshots from dev, with target of moving more development and interoperability testing to dev (and thus adding the maturity of dev, making it easier to develop with etc). After these are in place, we have snapshots rolling from all branches of a release. With dev snapshots in place, I agree with Jani and think we could: - Discontinue the concept of an 'Alpha' release of a new Qt version starting from Qt 5.12 (in a way every dev snapshot is a pre-release of Qt 5.12) - After branching to 5.12, call the first released snapshot Qt 5.12 Beta 1 (or use build number) - After branching to 5.12.0, call the first released snapshot Qt 5.12 RC 1 (or use build number) With this we would focus the activities more into moving to a new branch - and of course keep (and even improve) the existing criteria when we are ready to branch. Use of build numbers instead of Beta 1 etc is also fine for me, if preferred. Yours, Tuukka On 16/04/2018, 9.44, "Development on behalf of Simon Hausmann" wrote: Hi, Same here. At first this seemed like a good idea, but it becomes awkward when you look at it from the dev workflow point of view: After fixing a bug, what is the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? That sounds like it would create a mess in JIRA. Unless of course the task of assigning the fix version field was automated. Simon On 16. Apr 2018, at 08:12, Alex Blasche wrote: >> -----Original Message----- >>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: >>> And at this same time I want to propose that we stop delivering alpha >>> or beta releases and just do snapshots instead. Publishing regular >>> snapshots should be done until we are ready for RC. That because I >>> don't see that much need for those anymore. Those are nowadays kind of >>> milestones and in my opinion makes whole process a bit >>> unclear/difficult (we don't have very good definitions for Alpha and Beta >> releases). >> >> Yes we do. >> >> Alpha means feature complete, asking for feedback on the API and new >> functionality. >> >> Beta means implementation complete, asking for feedback on the quality of the >> implementation, seeking bugs and regressions to be fixed. >> >> RC means we've fixed everything we knew. > > I wholeheartedly agree with Thiago. The distinction may not make a difference from the release team perspective but it makes a world of difference for developers (who have different limitations for each step) and the world as they can decide how bleeding edge the code is that they want to test. > > I have a problem with the motivation behind this suggestion too (don't understand it). The naming makes no difference for you as release manager (afaict just a label). Why suggesting it aka what do you want to gain by doing snapshots only? > -- > Alex > > _______________________________________________ > 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 ville.voutilainen at gmail.com Mon Apr 16 09:00:03 2018 From: ville.voutilainen at gmail.com (Ville Voutilainen) Date: Mon, 16 Apr 2018 10:00:03 +0300 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> Message-ID: On 16 April 2018 at 09:43, Simon Hausmann wrote: > Hi, > > Same here. At first this seemed like a good idea, but it becomes awkward when you look at it from the dev workflow point of view: After fixing a bug, what is the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? That sounds like it would create a mess in JIRA. That problem seems surmountable; if I have a fix for a bug that appears in an "5.9.6 alpha", I'm not going to set its fix version to "5.9.6 beta", I'm going to set it to 5.9.6. From lars.knoll at qt.io Mon Apr 16 09:03:00 2018 From: lars.knoll at qt.io (Lars Knoll) Date: Mon, 16 Apr 2018 07:03:00 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> Message-ID: <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> Hi, From a releasing perspective I agree that the set we should update our packages often. We should also stop delivering source only alpha packages, and have binaries from the get go. But from a user perspective, I agree that it's good and important to put a name to those releases so people know what to expect from them. Snapshots as long as the packages are created from the dev branch, then alpha, beta, RC and final. We could discuss whether we need the alpha label, or whether we can go directly to beta, but I believe that we do need the other tags. But I do agree with releasing packages as often as possible, and we should have them already before FF from the dev branch (if possible). So I’d propose to have our packages updated often. But we do keep the ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags. - Snapshot packages from the dev branch - FF and branching occur together and packages are getting the ‘alpha’ tag - Agree that we should start with the API review immediately. - Beta once API review is done - RC once we have the release branch and all currently known blockers are fixed That should be pretty close to what Jani described, only that we keep the tags for our users. Cheers, Lars > On 16 Apr 2018, at 08:43, Simon Hausmann wrote: > > Hi, > > Same here. At first this seemed like a good idea, but it becomes awkward when you look at it from the dev workflow point of view: After fixing a bug, what is the fix version? Reported in snapshot-24062918 and fixed in snapshot-14072918? That sounds like it would create a mess in JIRA. > > Unless of course the task of assigning the fix version field was automated. > > Simon > > On 16. Apr 2018, at 08:12, Alex Blasche wrote: > >>> -----Original Message----- >>>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: >>>> And at this same time I want to propose that we stop delivering alpha >>>> or beta releases and just do snapshots instead. Publishing regular >>>> snapshots should be done until we are ready for RC. That because I >>>> don't see that much need for those anymore. Those are nowadays kind of >>>> milestones and in my opinion makes whole process a bit >>>> unclear/difficult (we don't have very good definitions for Alpha and Beta >>> releases). >>> >>> Yes we do. >>> >>> Alpha means feature complete, asking for feedback on the API and new >>> functionality. >>> >>> Beta means implementation complete, asking for feedback on the quality of the >>> implementation, seeking bugs and regressions to be fixed. >>> >>> RC means we've fixed everything we knew. >> >> I wholeheartedly agree with Thiago. The distinction may not make a difference from the release team perspective but it makes a world of difference for developers (who have different limitations for each step) and the world as they can decide how bleeding edge the code is that they want to test. >> >> I have a problem with the motivation behind this suggestion too (don't understand it). The naming makes no difference for you as release manager (afaict just a label). Why suggesting it aka what do you want to gain by doing snapshots only? >> -- >> Alex >> >> _______________________________________________ >> 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 qt.io Mon Apr 16 11:25:06 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 16 Apr 2018 09:25:06 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io>, Message-ID: Tuukka Turunen (16 April 2018 08:59) > I very much like continuous flow of snapshots. I don't think anyone is challenging that part of the plan. The only objection to the plan has been to the change in naming. > Sometimes we have a tendency to fall into a "let's wait and get still > this one fix in" mode, which is very inefficient. It is beneficial > when making .x patch releases and the fix is for a regression. But in > other situations, it is typically more important to have a frequent > flow of releases. Frequency of builds is orthogonal to how we name them. Build early, build often. That is good. Make the status of each build clear by tagging it alpha, beta or RC if it meets the criteria Thiago gave. Number them any way you like, but keep these distinctions. They are useful to consumers. Eddy. From jani.heikkinen at qt.io Mon Apr 16 11:35:28 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 16 Apr 2018 09:35:28 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> Message-ID: Hi! Keeping release tags is OK for me. Motivation behind my proposal was to stop planning other release dates than FF & final target. Currently we are trying to estimate also alpha, beta and RC release dates and it seems to cause some delays for us: persons aren't fixing blocker issues or doing the test because it seems there is a time to do that later (because e.g RC date is planned to be after a month). So if the way to go is to do these "releases" immediately when ready it might help us to get fixes in earlier and so on also get releases out quicker... But this change doesn't meant we need to stop calling those releases as Alpha or Betas so we can continue labeling those as earlier. br, Jani > -----Original Message----- > From: Development project.org> On Behalf Of Lars Knoll > Sent: maanantai 16. huhtikuuta 2018 10.03 > To: Simon Hausmann > Cc: Qt development mailing list > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release > process change > > Hi, > > From a releasing perspective I agree that the set we should update our > packages often. We should also stop delivering source only alpha packages, > and have binaries from the get go. > > But from a user perspective, I agree that it's good and important to put a > name to those releases so people know what to expect from them. > Snapshots as long as the packages are created from the dev branch, then > alpha, beta, RC and final. We could discuss whether we need the alpha label, > or whether we can go directly to beta, but I believe that we do need the > other tags. > > But I do agree with releasing packages as often as possible, and we should > have them already before FF from the dev branch (if possible). > > So I’d propose to have our packages updated often. But we do keep the > ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags. > > - Snapshot packages from the dev branch > - FF and branching occur together and packages are getting the ‘alpha’ tag > - Agree that we should start with the API review immediately. > - Beta once API review is done > - RC once we have the release branch and all currently known blockers are > fixed > > That should be pretty close to what Jani described, only that we keep the > tags for our users. > > Cheers, > Lars > > > On 16 Apr 2018, at 08:43, Simon Hausmann > wrote: > > > > Hi, > > > > Same here. At first this seemed like a good idea, but it becomes awkward > when you look at it from the dev workflow point of view: After fixing a bug, > what is the fix version? Reported in snapshot-24062918 and fixed in > snapshot-14072918? That sounds like it would create a mess in JIRA. > > > > Unless of course the task of assigning the fix version field was automated. > > > > Simon > > > > On 16. Apr 2018, at 08:12, Alex Blasche wrote: > > > >>> -----Original Message----- > >>>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: > >>>> And at this same time I want to propose that we stop delivering > >>>> alpha or beta releases and just do snapshots instead. Publishing > >>>> regular snapshots should be done until we are ready for RC. That > >>>> because I don't see that much need for those anymore. Those are > >>>> nowadays kind of milestones and in my opinion makes whole process a > >>>> bit unclear/difficult (we don't have very good definitions for > >>>> Alpha and Beta > >>> releases). > >>> > >>> Yes we do. > >>> > >>> Alpha means feature complete, asking for feedback on the API and new > >>> functionality. > >>> > >>> Beta means implementation complete, asking for feedback on the > >>> quality of the implementation, seeking bugs and regressions to be fixed. > >>> > >>> RC means we've fixed everything we knew. > >> > >> I wholeheartedly agree with Thiago. The distinction may not make a > difference from the release team perspective but it makes a world of > difference for developers (who have different limitations for each step) and > the world as they can decide how bleeding edge the code is that they want > to test. > >> > >> I have a problem with the motivation behind this suggestion too (don't > understand it). The naming makes no difference for you as release manager > (afaict just a label). Why suggesting it aka what do you want to gain by doing > snapshots only? > >> -- > >> Alex > >> > >> _______________________________________________ > >> Development mailing list > >> Development at qt-project.org > >> http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From mitch.curtis at qt.io Mon Apr 16 11:56:56 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 16 Apr 2018 09:56:56 +0000 Subject: [Development] QTestLib: sending mouse move and release events outside windows Message-ID: https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a // canvas should scroll the canvas). QTest::mousePress(&window, Qt::LeftButton, Qt::NoModifier, QPoint(200, 200)); const QRegularExpression regex(".*Mouse event at .* occurs outside of target window.*"); QVERIFY(regex.isValid()); const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 occurs outside of target window (400x400).")); QVERIFY(match.hasMatch()); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseMove(&window, QPoint(600, 600)); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseRelease(&window, Qt::LeftButton, Qt::NoModifier, QPoint(600, 600)); } Output: ********* Start testing of Test ********* Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 shared (dynamic) debug build; by MSVC 2017) PASS : Test::initTestCase() WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" FAIL! : Test::test_case1() Not all expected messages were received PASS : Test::cleanupTestCase() Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms ********* Finished testing of Test ********* Mouse move and release events occurring outside of a window is not uncommon, so there should be a way to disable these warnings. Using QTest::ignoreWarning() has no effect here, because the message logger system is (probably intentionally) bypassed. Does anyone know why this is the case? Also, does anyone have any ideas about how to solve this? One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow halfway through a "drag" loop. Another idea could be to have a flag or construct that only applies for the duration of a test function, and is reset at the end of that function. I think something like this could also be useful for the opposite use case: failing a test upon any warnings (something that would be useful for QML applications). Something like https://codereview.qt-project.org/#/c/89178/ except it's automatically reset for you at the end of each test. From abbapoh at gmail.com Mon Apr 16 12:23:24 2018 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Mon, 16 Apr 2018 13:23:24 +0300 Subject: [Development] qdds image format In-Reply-To: <1729744.hIf54J7YqV@tjmaciei-mobl1> References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> Message-ID: So, how those issues are checked? Any tool or what? 2018-04-16 0:41 GMT+03:00 Thiago Macieira : > On Sunday, 15 April 2018 12:59:35 PDT Giuseppe D'Angelo wrote: > > Hello, > > > > Il 15/04/2018 18:14, Иван Комиссаров ha scritto: > > >> The usual amount of parsing a file without doing bounds checks, so > making > > >> the user vulnerable to crashes / code execution / overflows and the > > >> like.> > > > Are there any tickets on Jira related? All tickets i found are fixed > and > > > closed long ago (Qt5.5) > > I'm not sure if it was reported on Jira or through a security > > notification. I'm thinking about the latter, around the time where we > > fuzzed Qt's image formats. > > I don't think it was reported against DDS. We fuzzed all the image format > readers after a report against one of them. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com > Software Architect - Intel Open Source Technology Center > > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gatis.Paeglis at qt.io Mon Apr 16 12:28:42 2018 From: Gatis.Paeglis at qt.io (Gatis Paeglis) Date: Mon, 16 Apr 2018 10:28:42 +0000 Subject: [Development] QTestLib: sending mouse move and release events outside windows In-Reply-To: References: Message-ID: That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... but it won't work AFAICT 😊 see [3], if we don't find a window under mouse, then QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we send the event? [1] https://codereview.qt-project.org/#/c/53474/ [2] http://doc.qt.io/qt-5/qtest.html#mouseMove [3] http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021 ________________________________ From: Development on behalf of Mitch Curtis Sent: Monday, April 16, 2018 11:56:56 AM To: development at qt-project.org Subject: [Development] QTestLib: sending mouse move and release events outside windows https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a // canvas should scroll the canvas). QTest::mousePress(&window, Qt::LeftButton, Qt::NoModifier, QPoint(200, 200)); const QRegularExpression regex(".*Mouse event at .* occurs outside of target window.*"); QVERIFY(regex.isValid()); const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 occurs outside of target window (400x400).")); QVERIFY(match.hasMatch()); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseMove(&window, QPoint(600, 600)); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseRelease(&window, Qt::LeftButton, Qt::NoModifier, QPoint(600, 600)); } Output: ********* Start testing of Test ********* Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 shared (dynamic) debug build; by MSVC 2017) PASS : Test::initTestCase() WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" FAIL! : Test::test_case1() Not all expected messages were received PASS : Test::cleanupTestCase() Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms ********* Finished testing of Test ********* Mouse move and release events occurring outside of a window is not uncommon, so there should be a way to disable these warnings. Using QTest::ignoreWarning() has no effect here, because the message logger system is (probably intentionally) bypassed. Does anyone know why this is the case? Also, does anyone have any ideas about how to solve this? One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow halfway through a "drag" loop. Another idea could be to have a flag or construct that only applies for the duration of a test function, and is reset at the end of that function. I think something like this could also be useful for the opposite use case: failing a test upon any warnings (something that would be useful for QML applications). Something like https://codereview.qt-project.org/#/c/89178/ except it's automatically reset for you at the end of each test. _______________________________________________ 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 mitch.curtis at qt.io Mon Apr 16 13:14:23 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 16 Apr 2018 11:14:23 +0000 Subject: [Development] QTestLib: sending mouse move and release events outside windows In-Reply-To: References: Message-ID: > That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. I suppose it could be useful if you didn’t intend to send events outside of the window. > QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. What do you think about a flag that can be set for the duration of a function (i.e. automatically reset at the end of that function)? setWarnOnEventsOutsideWindow? Or, to involve the discussion about failing on warnings, we could add a more generic flag getter/setter. We already have [1] a bunch of currentTestFunction functions: const char *currentAppName() const char *currentDataTag() bool currentTestFailed() const char *currentTestFunction() So, perhaps we could add currentTestFunctionFlags()/setCurrentTestFunctionFlags(). TestFunctionFlag { WarnOnEventsOutsideWindow = 0x01, // enabled by default FailOnWarnings = 0x02 // disabled by default }; [1] http://doc.qt.io/qt-5/qtest.html#keyClicks From: Gatis Paeglis Sent: Monday, 16 April 2018 12:29 PM To: Mitch Curtis ; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... but it won't work AFAICT 😊 see [3], if we don't find a window under mouse, then QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we send the event? [1] https://codereview.qt-project.org/#/c/53474/ [2] http://doc.qt.io/qt-5/qtest.html#mouseMove [3] http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021 ________________________________ From: Development > on behalf of Mitch Curtis > Sent: Monday, April 16, 2018 11:56:56 AM To: development at qt-project.org Subject: [Development] QTestLib: sending mouse move and release events outside windows https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a // canvas should scroll the canvas). QTest::mousePress(&window, Qt::LeftButton, Qt::NoModifier, QPoint(200, 200)); const QRegularExpression regex(".*Mouse event at .* occurs outside of target window.*"); QVERIFY(regex.isValid()); const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 occurs outside of target window (400x400).")); QVERIFY(match.hasMatch()); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseMove(&window, QPoint(600, 600)); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseRelease(&window, Qt::LeftButton, Qt::NoModifier, QPoint(600, 600)); } Output: ********* Start testing of Test ********* Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 shared (dynamic) debug build; by MSVC 2017) PASS : Test::initTestCase() WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" FAIL! : Test::test_case1() Not all expected messages were received PASS : Test::cleanupTestCase() Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms ********* Finished testing of Test ********* Mouse move and release events occurring outside of a window is not uncommon, so there should be a way to disable these warnings. Using QTest::ignoreWarning() has no effect here, because the message logger system is (probably intentionally) bypassed. Does anyone know why this is the case? Also, does anyone have any ideas about how to solve this? One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow halfway through a "drag" loop. Another idea could be to have a flag or construct that only applies for the duration of a test function, and is reset at the end of that function. I think something like this could also be useful for the opposite use case: failing a test upon any warnings (something that would be useful for QML applications). Something like https://codereview.qt-project.org/#/c/89178/ except it's automatically reset for you at the end of each test. _______________________________________________ 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 qt.io Mon Apr 16 14:10:52 2018 From: frederik.gladhorn at qt.io (Frederik Gladhorn) Date: Mon, 16 Apr 2018 14:10:52 +0200 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> Message-ID: <1835224.YB7rYgWsEd@frederik-thinkcentre-m93p> On mandag 16. april 2018 11.35.28 CEST Jani Heikkinen wrote: > Hi! > > Keeping release tags is OK for me. Motivation behind my proposal was to stop > planning other release dates than FF & final target. Currently we are > trying to estimate also alpha, beta and RC release dates and it seems to > cause some delays for us: persons aren't fixing blocker issues or doing the > test because it seems there is a time to do that later (because e.g RC date > is planned to be after a month). So if the way to go is to do these > "releases" immediately when ready it might help us to get fixes in earlier > and so on also get releases out quicker... This sounds like it is the real issue. In my opinion, we should have a list of "known issues for betas" (does anyone know of a good way of tracking these, so that it's obvious and little work?). JIRA? Somewhere else? I think each beta is for finding more issues (if we consider it necessary), but we should not have anything block a beta from going out (OK, maybe if it doesn't compile, but how did we end up in such a bad state?). So there is the beta with a potentially growing and then shrinking list of release blockers. This means we may have critical bugs not fixed in the next beta, only in the RC latest. At the same time, I do wonder how strong the argument for more than one beta release really is. We should rather offer continuous post-beta snapshots, but IMHO we should only ask to test exactly once, during one beta. If we then trust that we fix the issues that were uncovered, we should move to the RC phase, without another beta (beta2/3/4/... contain very few changes compared to the first one anyway). There is little value in asking a great amount of people to re-test. The bad issues uncovered in the beta can be tested using post-beta snapshots, as needed. The only thing that can be blocked imho is the release candidate. We should never have a release candidate that does not include fixes for all known issues. The release candidate should then turn into the final release after a brief sanity check. There must not be any changes from release candidate to release. If it turns out that we really messed up badly, we'll have another RC + release. I think this would help us get releases out quickly. It would mean, we really need to play by our own rules: after alpha: no more API changes, unless fixing new API. All new features must be _complete_, with no known big bugs (or thrown out again). I am certainly guilty of breaking this rule in the past and delaying releases... after beta: no more changes, except for fixes for release blockers release candidate: no more changes, unless brown paper bag issues are found Cheers, Frederik > > But this change doesn't meant we need to stop calling those releases as > Alpha or Betas so we can continue labeling those as earlier. > > br, > Jani > > > -----Original Message----- > > From: Development > project.org> On Behalf Of Lars Knoll > > Sent: maanantai 16. huhtikuuta 2018 10.03 > > To: Simon Hausmann > > Cc: Qt development mailing list > > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for > > release > > process change > > > > Hi, > > > > From a releasing perspective I agree that the set we should update our > > packages often. We should also stop delivering source only alpha packages, > > and have binaries from the get go. > > > > But from a user perspective, I agree that it's good and important to put a > > name to those releases so people know what to expect from them. > > Snapshots as long as the packages are created from the dev branch, then > > alpha, beta, RC and final. We could discuss whether we need the alpha > > label, or whether we can go directly to beta, but I believe that we do > > need the other tags. > > > > But I do agree with releasing packages as often as possible, and we should > > have them already before FF from the dev branch (if possible). > > > > So I’d propose to have our packages updated often. But we do keep the > > ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags. > > > > - Snapshot packages from the dev branch > > - FF and branching occur together and packages are getting the ‘alpha’ tag > > - Agree that we should start with the API review immediately. > > - Beta once API review is done > > - RC once we have the release branch and all currently known blockers are > > fixed > > > > That should be pretty close to what Jani described, only that we keep the > > tags for our users. > > > > Cheers, > > Lars > > > > > On 16 Apr 2018, at 08:43, Simon Hausmann > > > > wrote: > > > Hi, > > > > > > Same here. At first this seemed like a good idea, but it becomes awkward > > > > when you look at it from the dev workflow point of view: After fixing a > > bug, what is the fix version? Reported in snapshot-24062918 and fixed in > > snapshot-14072918? That sounds like it would create a mess in JIRA.> > > > Unless of course the task of assigning the fix version field was > > > automated. > > > > > > Simon > > > > > > On 16. Apr 2018, at 08:12, Alex Blasche wrote: > > >>> -----Original Message----- > > >>> > > >>>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: > > >>>> And at this same time I want to propose that we stop delivering > > >>>> alpha or beta releases and just do snapshots instead. Publishing > > >>>> regular snapshots should be done until we are ready for RC. That > > >>>> because I don't see that much need for those anymore. Those are > > >>>> nowadays kind of milestones and in my opinion makes whole process a > > >>>> bit unclear/difficult (we don't have very good definitions for > > >>>> Alpha and Beta > > >>> > > >>> releases). > > >>> > > >>> Yes we do. > > >>> > > >>> Alpha means feature complete, asking for feedback on the API and new > > >>> functionality. > > >>> > > >>> Beta means implementation complete, asking for feedback on the > > >>> quality of the implementation, seeking bugs and regressions to be > > >>> fixed. > > >>> > > >>> RC means we've fixed everything we knew. > > >> > > >> I wholeheartedly agree with Thiago. The distinction may not make a > > > > difference from the release team perspective but it makes a world of > > difference for developers (who have different limitations for each step) > > and the world as they can decide how bleeding edge the code is that they > > want to test. > > > > >> I have a problem with the motivation behind this suggestion too (don't > > > > understand it). The naming makes no difference for you as release manager > > (afaict just a label). Why suggesting it aka what do you want to gain by > > doing snapshots only? > > > > >> -- > > >> Alex > > >> > > >> _______________________________________________ > > >> Development mailing list > > >> Development at qt-project.org > > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From giuseppe.dangelo at kdab.com Mon Apr 16 15:03:30 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Mon, 16 Apr 2018 15:03:30 +0200 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> Message-ID: On 16/04/18 12:23, Иван Комиссаров wrote: > So, how those issues are checked? Any tool or what? Looking at the email archives: it was fuzzed through AFL. I don't have the test images still around, but in my experience a simple multi-image file was enough to trigger a crash. (I used to see this in Creator, when accidentally opening a DDS in its builtin image preview). But again, why having such an image loader in Qt? It's not going to be useful in 99.9% of the use cases where you use a DDS file. Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From alexander.blasche at qt.io Mon Apr 16 15:47:08 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 16 Apr 2018 13:47:08 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> Message-ID: > -----Original Message----- > From: Development [mailto:development- > Keeping release tags is OK for me. Motivation behind my proposal was to stop > planning other release dates than FF & final target. Currently we are trying to > estimate also alpha, beta and RC release dates and it seems to cause some > delays for us: persons aren't fixing blocker issues or doing the test because it > seems there is a time to do that later (because e.g RC date is planned to be after > a month). So if the way to go is to do these "releases" immediately when ready > it might help us to get fixes in earlier and so on also get releases out quicker... At large I agree with Frederik. The bug side of thing (which delays) we could handle in a flexible manor exactly as described by Frederik. I do like to emphasize though that the dates for first beta and first RC are important (and FF is alpha) because they define times when certain level of changes are no longer permitted (e.g. after first beta no API changes). Therefore, you will not get around setting a target date for first Beta and RC. -- Alex From Gatis.Paeglis at qt.io Mon Apr 16 17:08:11 2018 From: Gatis.Paeglis at qt.io (Gatis Paeglis) Date: Mon, 16 Apr 2018 15:08:11 +0000 Subject: [Development] QTestLib: sending mouse move and release events outside windows In-Reply-To: References: , Message-ID: > I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. That kind of API I think requires serious redesign in qtestlib. If you want to drag outside a window and then back to test Enter/Leave events (system generated, not the synthetic ones for alien widgets), then we have to use system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking events. Both modes are useful, mocked vs system events, but that is another story. If you want to move outside a window and keep on receiving all mouse events, then you need to grab the mouse/pointer. That is different API from the above Enter/Leave scenario. QTestLib currently does not support any of the above. ________________________________ From: Mitch Curtis Sent: Monday, April 16, 2018 1:14:23 PM To: Gatis Paeglis; development at qt-project.org Subject: RE: QTestLib: sending mouse move and release events outside windows > That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. I suppose it could be useful if you didn’t intend to send events outside of the window. > QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. What do you think about a flag that can be set for the duration of a function (i.e. automatically reset at the end of that function)? setWarnOnEventsOutsideWindow? Or, to involve the discussion about failing on warnings, we could add a more generic flag getter/setter. We already have [1] a bunch of currentTestFunction functions: const char *currentAppName() const char *currentDataTag() bool currentTestFailed() const char *currentTestFunction() So, perhaps we could add currentTestFunctionFlags()/setCurrentTestFunctionFlags(). TestFunctionFlag { WarnOnEventsOutsideWindow = 0x01, // enabled by default FailOnWarnings = 0x02 // disabled by default }; [1] http://doc.qt.io/qt-5/qtest.html#keyClicks From: Gatis Paeglis Sent: Monday, 16 April 2018 12:29 PM To: Mitch Curtis ; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... but it won't work AFAICT ?? see [3], if we don't find a window under mouse, then QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we send the event? [1] https://codereview.qt-project.org/#/c/53474/ [2] http://doc.qt.io/qt-5/qtest.html#mouseMove [3] http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021 ________________________________ From: Development > on behalf of Mitch Curtis > Sent: Monday, April 16, 2018 11:56:56 AM To: development at qt-project.org Subject: [Development] QTestLib: sending mouse move and release events outside windows https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a // canvas should scroll the canvas). QTest::mousePress(&window, Qt::LeftButton, Qt::NoModifier, QPoint(200, 200)); const QRegularExpression regex(".*Mouse event at .* occurs outside of target window.*"); QVERIFY(regex.isValid()); const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 occurs outside of target window (400x400).")); QVERIFY(match.hasMatch()); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseMove(&window, QPoint(600, 600)); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseRelease(&window, Qt::LeftButton, Qt::NoModifier, QPoint(600, 600)); } Output: ********* Start testing of Test ********* Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 shared (dynamic) debug build; by MSVC 2017) PASS : Test::initTestCase() WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" FAIL! : Test::test_case1() Not all expected messages were received PASS : Test::cleanupTestCase() Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms ********* Finished testing of Test ********* Mouse move and release events occurring outside of a window is not uncommon, so there should be a way to disable these warnings. Using QTest::ignoreWarning() has no effect here, because the message logger system is (probably intentionally) bypassed. Does anyone know why this is the case? Also, does anyone have any ideas about how to solve this? One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow halfway through a "drag" loop. Another idea could be to have a flag or construct that only applies for the duration of a test function, and is reset at the end of that function. I think something like this could also be useful for the opposite use case: failing a test upon any warnings (something that would be useful for QML applications). Something like https://codereview.qt-project.org/#/c/89178/ except it's automatically reset for you at the end of each test. _______________________________________________ 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 aapo.keskimolo at qt.io Mon Apr 16 17:28:09 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Mon, 16 Apr 2018 15:28:09 +0000 Subject: [Development] Coin maintenance notification Message-ID: Coin production has been updated with a new baseline today. These are the most fundamental improvements: - Coin now supports common folder split (for instance, changing Linux common scripts no longer causes reprovisioning Mac and Windows machines, etc) - Performance improvements in creation of workitems should make scheduling of qt5 integration faster - Better asynchronous task scheduling of scheduler and storage operations - Lots of small bug fixes The applied amount of patches was 171 in total, thus we do not expect this to go out without experiencing some problems. In case you are not able to merge changes and you think CI is causing the issue, you may give drop by at #qtci or if you are an external user, you may create a JIRA ticket https://wiki.qt.io/Reporting_Bugs#Reporting_bugs_for_Coin Kind regards/Ystävällisin terveisin, Aapo Keskimölö -------------- next part -------------- A non-text attachment was scrubbed... Name: product_baseline_20180416.log Type: application/octet-stream Size: 79721 bytes Desc: product_baseline_20180416.log URL: From mitch.curtis at qt.io Mon Apr 16 17:28:07 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 16 Apr 2018 15:28:07 +0000 Subject: [Development] QTestLib: sending mouse move and release events outside windows In-Reply-To: References: , Message-ID: I think that maybe we’re talking about different things, because the functionality works for me (both in the app and testlib), I just want to disable the warnings. :) From: Gatis Paeglis Sent: Monday, 16 April 2018 5:08 PM To: Mitch Curtis ; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows > I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. That kind of API I think requires serious redesign in qtestlib. If you want to drag outside a window and then back to test Enter/Leave events (system generated, not the synthetic ones for alien widgets), then we have to use system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking events. Both modes are useful, mocked vs system events, but that is another story. If you want to move outside a window and keep on receiving all mouse events, then you need to grab the mouse/pointer. That is different API from the above Enter/Leave scenario. QTestLib currently does not support any of the above. ________________________________ From: Mitch Curtis Sent: Monday, April 16, 2018 1:14:23 PM To: Gatis Paeglis; development at qt-project.org Subject: RE: QTestLib: sending mouse move and release events outside windows > That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. I suppose it could be useful if you didn’t intend to send events outside of the window. > QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. What do you think about a flag that can be set for the duration of a function (i.e. automatically reset at the end of that function)? setWarnOnEventsOutsideWindow? Or, to involve the discussion about failing on warnings, we could add a more generic flag getter/setter. We already have [1] a bunch of currentTestFunction functions: const char *currentAppName() const char *currentDataTag() bool currentTestFailed() const char *currentTestFunction() So, perhaps we could add currentTestFunctionFlags()/setCurrentTestFunctionFlags(). TestFunctionFlag { WarnOnEventsOutsideWindow = 0x01, // enabled by default FailOnWarnings = 0x02 // disabled by default }; [1] http://doc.qt.io/qt-5/qtest.html#keyClicks From: Gatis Paeglis Sent: Monday, 16 April 2018 12:29 PM To: Mitch Curtis >; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... but it won't work AFAICT 😊 see [3], if we don't find a window under mouse, then QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we send the event? [1] https://codereview.qt-project.org/#/c/53474/ [2] http://doc.qt.io/qt-5/qtest.html#mouseMove [3] http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021 ________________________________ From: Development > on behalf of Mitch Curtis > Sent: Monday, April 16, 2018 11:56:56 AM To: development at qt-project.org Subject: [Development] QTestLib: sending mouse move and release events outside windows https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a // canvas should scroll the canvas). QTest::mousePress(&window, Qt::LeftButton, Qt::NoModifier, QPoint(200, 200)); const QRegularExpression regex(".*Mouse event at .* occurs outside of target window.*"); QVERIFY(regex.isValid()); const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 occurs outside of target window (400x400).")); QVERIFY(match.hasMatch()); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseMove(&window, QPoint(600, 600)); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseRelease(&window, Qt::LeftButton, Qt::NoModifier, QPoint(600, 600)); } Output: ********* Start testing of Test ********* Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 shared (dynamic) debug build; by MSVC 2017) PASS : Test::initTestCase() WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" FAIL! : Test::test_case1() Not all expected messages were received PASS : Test::cleanupTestCase() Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms ********* Finished testing of Test ********* Mouse move and release events occurring outside of a window is not uncommon, so there should be a way to disable these warnings. Using QTest::ignoreWarning() has no effect here, because the message logger system is (probably intentionally) bypassed. Does anyone know why this is the case? Also, does anyone have any ideas about how to solve this? One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow halfway through a "drag" loop. Another idea could be to have a flag or construct that only applies for the duration of a test function, and is reset at the end of that function. I think something like this could also be useful for the opposite use case: failing a test upon any warnings (something that would be useful for QML applications). Something like https://codereview.qt-project.org/#/c/89178/ except it's automatically reset for you at the end of each test. _______________________________________________ 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 Gatis.Paeglis at qt.io Mon Apr 16 17:38:34 2018 From: Gatis.Paeglis at qt.io (Gatis Paeglis) Date: Mon, 16 Apr 2018 15:38:34 +0000 Subject: [Development] QTestLib: sending mouse move and release events outside windows In-Reply-To: References: , , Message-ID: > I think that maybe we’re talking about different things, because the functionality works for me (both in the app and testlib), I just want to disable the warnings. :) Its all related :) > QTest::mouseMove(&window, QPoint(600, 600)); It is not clear to me what is the expected to happen after this call: a) Documentation in incomplete. b) Warning is not critical (it does not return from the function). c) Looking at the source code this calls ends up doing nothing. So I was wondering if there is a bigger issue and hiding a warning might not be the right solution. But if it works, it works. ________________________________ From: Mitch Curtis Sent: Monday, April 16, 2018 5:28:07 PM To: Gatis Paeglis; development at qt-project.org Subject: RE: QTestLib: sending mouse move and release events outside windows I think that maybe we’re talking about different things, because the functionality works for me (both in the app and testlib), I just want to disable the warnings. :) From: Gatis Paeglis Sent: Monday, 16 April 2018 5:08 PM To: Mitch Curtis ; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows > I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. That kind of API I think requires serious redesign in qtestlib. If you want to drag outside a window and then back to test Enter/Leave events (system generated, not the synthetic ones for alien widgets), then we have to use system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking events. Both modes are useful, mocked vs system events, but that is another story. If you want to move outside a window and keep on receiving all mouse events, then you need to grab the mouse/pointer. That is different API from the above Enter/Leave scenario. QTestLib currently does not support any of the above. ________________________________ From: Mitch Curtis Sent: Monday, April 16, 2018 1:14:23 PM To: Gatis Paeglis; development at qt-project.org Subject: RE: QTestLib: sending mouse move and release events outside windows > That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. I suppose it could be useful if you didn’t intend to send events outside of the window. > QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. What do you think about a flag that can be set for the duration of a function (i.e. automatically reset at the end of that function)? setWarnOnEventsOutsideWindow? Or, to involve the discussion about failing on warnings, we could add a more generic flag getter/setter. We already have [1] a bunch of currentTestFunction functions: const char *currentAppName() const char *currentDataTag() bool currentTestFailed() const char *currentTestFunction() So, perhaps we could add currentTestFunctionFlags()/setCurrentTestFunctionFlags(). TestFunctionFlag { WarnOnEventsOutsideWindow = 0x01, // enabled by default FailOnWarnings = 0x02 // disabled by default }; [1] http://doc.qt.io/qt-5/qtest.html#keyClicks From: Gatis Paeglis Sent: Monday, 16 April 2018 12:29 PM To: Mitch Curtis >; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... but it won't work AFAICT ?? see [3], if we don't find a window under mouse, then QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we send the event? [1] https://codereview.qt-project.org/#/c/53474/ [2] http://doc.qt.io/qt-5/qtest.html#mouseMove [3] http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021 ________________________________ From: Development > on behalf of Mitch Curtis > Sent: Monday, April 16, 2018 11:56:56 AM To: development at qt-project.org Subject: [Development] QTestLib: sending mouse move and release events outside windows https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a // canvas should scroll the canvas). QTest::mousePress(&window, Qt::LeftButton, Qt::NoModifier, QPoint(200, 200)); const QRegularExpression regex(".*Mouse event at .* occurs outside of target window.*"); QVERIFY(regex.isValid()); const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 occurs outside of target window (400x400).")); QVERIFY(match.hasMatch()); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseMove(&window, QPoint(600, 600)); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseRelease(&window, Qt::LeftButton, Qt::NoModifier, QPoint(600, 600)); } Output: ********* Start testing of Test ********* Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 shared (dynamic) debug build; by MSVC 2017) PASS : Test::initTestCase() WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" FAIL! : Test::test_case1() Not all expected messages were received PASS : Test::cleanupTestCase() Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms ********* Finished testing of Test ********* Mouse move and release events occurring outside of a window is not uncommon, so there should be a way to disable these warnings. Using QTest::ignoreWarning() has no effect here, because the message logger system is (probably intentionally) bypassed. Does anyone know why this is the case? Also, does anyone have any ideas about how to solve this? One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow halfway through a "drag" loop. Another idea could be to have a flag or construct that only applies for the duration of a test function, and is reset at the end of that function. I think something like this could also be useful for the opposite use case: failing a test upon any warnings (something that would be useful for QML applications). Something like https://codereview.qt-project.org/#/c/89178/ except it's automatically reset for you at the end of each test. _______________________________________________ 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 mitch.curtis at qt.io Mon Apr 16 17:45:15 2018 From: mitch.curtis at qt.io (Mitch Curtis) Date: Mon, 16 Apr 2018 15:45:15 +0000 Subject: [Development] QTestLib: sending mouse move and release events outside windows In-Reply-To: References: , , Message-ID: Ahhh, right. Well, I hope someone who knows this code well can chime in. From: Gatis Paeglis Sent: Monday, 16 April 2018 5:39 PM To: Mitch Curtis ; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows > I think that maybe we’re talking about different things, because the functionality works for me (both in the app and testlib), I just want to disable the warnings. :) Its all related :) > QTest::mouseMove(&window, QPoint(600, 600)); It is not clear to me what is the expected to happen after this call: a) Documentation in incomplete. b) Warning is not critical (it does not return from the function). c) Looking at the source code this calls ends up doing nothing. So I was wondering if there is a bigger issue and hiding a warning might not be the right solution. But if it works, it works. ________________________________ From: Mitch Curtis Sent: Monday, April 16, 2018 5:28:07 PM To: Gatis Paeglis; development at qt-project.org Subject: RE: QTestLib: sending mouse move and release events outside windows I think that maybe we’re talking about different things, because the functionality works for me (both in the app and testlib), I just want to disable the warnings. :) From: Gatis Paeglis Sent: Monday, 16 April 2018 5:08 PM To: Mitch Curtis >; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows > I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. That kind of API I think requires serious redesign in qtestlib. If you want to drag outside a window and then back to test Enter/Leave events (system generated, not the synthetic ones for alien widgets), then we have to use system APIs to emulate mouse (e.g. via XTest on X11), instead of mocking events. Both modes are useful, mocked vs system events, but that is another story. If you want to move outside a window and keep on receiving all mouse events, then you need to grab the mouse/pointer. That is different API from the above Enter/Leave scenario. QTestLib currently does not support any of the above. ________________________________ From: Mitch Curtis Sent: Monday, April 16, 2018 1:14:23 PM To: Gatis Paeglis; development at qt-project.org Subject: RE: QTestLib: sending mouse move and release events outside windows > That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. I suppose it could be useful if you didn’t intend to send events outside of the window. > QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... I was thinking of something that would be public API, as any user who wants to tests drags that end up outside a window will run into the same issue. What do you think about a flag that can be set for the duration of a function (i.e. automatically reset at the end of that function)? setWarnOnEventsOutsideWindow? Or, to involve the discussion about failing on warnings, we could add a more generic flag getter/setter. We already have [1] a bunch of currentTestFunction functions: const char *currentAppName() const char *currentDataTag() bool currentTestFailed() const char *currentTestFunction() So, perhaps we could add currentTestFunctionFlags()/setCurrentTestFunctionFlags(). TestFunctionFlag { WarnOnEventsOutsideWindow = 0x01, // enabled by default FailOnWarnings = 0x02 // disabled by default }; [1] http://doc.qt.io/qt-5/qtest.html#keyClicks From: Gatis Paeglis Sent: Monday, 16 April 2018 12:29 PM To: Mitch Curtis >; development at qt-project.org Subject: Re: QTestLib: sending mouse move and release events outside windows That warning message was added by [1]. I have never fully understood the motivation for that warning. The documentation from [2] does not say if global coordinates are allowed. QTest sends all mouse events down to QWindowSystemInterface, which does expect a window as an argument, or nullptr on window-less systems (eglfs). So if you want to simulate a mouse move/press/release outside a window you could try to use that code path... but it won't work AFAICT 😊 see [3], if we don't find a window under mouse, then QGuiApplicationPrivate::processMouseEvent() returns. Otherwise, where should we send the event? [1] https://codereview.qt-project.org/#/c/53474/ [2] http://doc.qt.io/qt-5/qtest.html#mouseMove [3] http://code.qt.io/cgit/qt/qtbase.git/tree/src/gui/kernel/qguiapplication.cpp#n2021 ________________________________ From: Development > on behalf of Mitch Curtis > Sent: Monday, April 16, 2018 11:56:56 AM To: development at qt-project.org Subject: [Development] QTestLib: sending mouse move and release events outside windows https://bugreports.qt.io/browse/QTBUG-67702 explains that sending mouse move and release events outside of a window causes warnings: void Test::test_case1() { QWindow window; window.resize(400, 400); // Start inside and drag outside (e.g. moving a selection to the edge of a // canvas should scroll the canvas). QTest::mousePress(&window, Qt::LeftButton, Qt::NoModifier, QPoint(200, 200)); const QRegularExpression regex(".*Mouse event at .* occurs outside of target window.*"); QVERIFY(regex.isValid()); const QRegularExpressionMatch match(regex.match("Mouse event at 600, 600 occurs outside of target window (400x400).")); QVERIFY(match.hasMatch()); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseMove(&window, QPoint(600, 600)); QTest::ignoreMessage(QtWarningMsg, regex); QTest::mouseRelease(&window, Qt::LeftButton, Qt::NoModifier, QPoint(600, 600)); } Output: ********* Start testing of Test ********* Config: Using QtTest library 5.11.0, Qt 5.11.0 (x86_64-little_endian-llp64 shared (dynamic) debug build; by MSVC 2017) PASS : Test::initTestCase() WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). WARNING: Test::test_case1() Mouse event at 600, 600 occurs outside of target window (400x400). INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" INFO : Test::test_case1() Did not receive any message matching: ".*Mouse event at .* occurs outside of target window.*" FAIL! : Test::test_case1() Not all expected messages were received PASS : Test::cleanupTestCase() Totals: 2 passed, 1 failed, 0 skipped, 0 blacklisted, 1ms ********* Finished testing of Test ********* Mouse move and release events occurring outside of a window is not uncommon, so there should be a way to disable these warnings. Using QTest::ignoreWarning() has no effect here, because the message logger system is (probably intentionally) bypassed. Does anyone know why this is the case? Also, does anyone have any ideas about how to solve this? One suggestion was QTest::mouse*OutsideWindow(), which would work, but could be a bit cumbersome if you need to switch from mouseMove to mouseMoveOutsideWindow halfway through a "drag" loop. Another idea could be to have a flag or construct that only applies for the duration of a test function, and is reset at the end of that function. I think something like this could also be useful for the opposite use case: failing a test upon any warnings (something that would be useful for QML applications). Something like https://codereview.qt-project.org/#/c/89178/ except it's automatically reset for you at the end of each test. _______________________________________________ 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 jani.heikkinen at qt.io Tue Apr 17 08:05:25 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 17 Apr 2018 06:05:25 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: <1835224.YB7rYgWsEd@frederik-thinkcentre-m93p> References: <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> <1835224.YB7rYgWsEd@frederik-thinkcentre-m93p> Message-ID: > -----Original Message----- > From: Development project.org> On Behalf Of Frederik Gladhorn > Sent: maanantai 16. huhtikuuta 2018 15.11 > To: development at qt-project.org > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release > process change > > On mandag 16. april 2018 11.35.28 CEST Jani Heikkinen wrote: > > Hi! > > > > Keeping release tags is OK for me. Motivation behind my proposal was > > to stop planning other release dates than FF & final target. Currently > > we are trying to estimate also alpha, beta and RC release dates and it > > seems to cause some delays for us: persons aren't fixing blocker > > issues or doing the test because it seems there is a time to do that > > later (because e.g RC date is planned to be after a month). So if the > > way to go is to do these "releases" immediately when ready it might > > help us to get fixes in earlier and so on also get releases out quicker... > > This sounds like it is the real issue. In my opinion, we should have a list of > "known issues for betas" (does anyone know of a good way of tracking > these, so that it's obvious and little work?). JIRA? Somewhere else? Hmm, we have this already in jira; we just need to create a proper filter for it. And in addition we have that blocker list in the use where all release (==RC) blockers should be visible and which is used to track when we are ready for RC. > > I think each beta is for finding more issues (if we consider it necessary), but > we should not have anything block a beta from going out (OK, maybe if it > doesn't compile, but how did we end up in such a bad state?). So there is the > beta with a potentially growing and then shrinking list of release blockers. Actually we are already working pretty much like this: We don't have a blocker list for beta n release. For beta1 we have and it is to make sure beta1 will be good enough. But after that we just put new beta n out when packages ready. And target is to get these out within 2 weeks. > > This means we may have critical bugs not fixed in the next beta, only in the > RC latest. As written above we don't have blocker lists for beta n; just for RC > At the same time, I do wonder how strong the argument for more than one > beta release really is. We should rather offer continuous post-beta > snapshots, but IMHO we should only ask to test exactly once, during one > beta. > If we then trust that we fix the issues that were uncovered, we should move > to the RC phase, without another beta (beta2/3/4/... contain very few > changes compared to the first one anyway). There is little value in asking a > great amount of people to re-test. The bad issues uncovered in the beta can > be tested using post-beta snapshots, as needed. Yeah, I agree this at least some level. I think it doesn't matter how the packages are called. And that's why I proposed to stop releasing these. But now I understand that most probably we need those milestones and phases. And so on it is most clear to call releases as alpha or beta... But I think it would be pretty confusing if we release beta1 and then beta snapshots. We have used snapshot term for releases which aren't ready yet (alpha snapshot == pre-alpha, beta snapshot == pre beta1 etc) and so on publishing beta snapshot after beta1 would be a somehow confusing. Ok it could be e.g 5.12 snapshot (after beta release) but I don't see that much sense to stop delivering beta n releases if we continue these alpha and beta phases: next delivery after beta(1) release is naturally beta2 etc. And what comes to beta n changes: I wouldn't say there is very few changes in beta n compared to beta1. 5.11 alpha -> beta1:400 changes 5.11 beta1 ->beta2: 310 changes 5.11 beta2 ->beta3: 516 changes So I would say beta n:s are as necessary as beta1... > > The only thing that can be blocked imho is the release candidate. We should > never have a release candidate that does not include fixes for all known > issues. The release candidate should then turn into the final release after a > brief sanity check. There must not be any changes from release candidate to > release. If it turns out that we really messed up badly, we'll have another RC > + release. I totally agree with this. And this is what I have tried to do. With 5.10 this worked already quite well but still there is room for improvements: If we found some new blocker from RC(n) we should fix just it and nothing else. And then release RC n+1. And as I propose we should release RC immediately when blockers are fixed. And that's why I don't like to plan the date for it because it seems to slow down the process with fixing the release blockers. > > I think this would help us get releases out quickly. It would mean, we really > need to play by our own rules: > after alpha: no more API changes, unless fixing new API. All new features > must be _complete_, with no known big bugs (or thrown out again). I am > certainly guilty of breaking this rule in the past and delaying releases... > after beta: no more changes, except for fixes for release blockers release > candidate: no more changes, unless brown paper bag issues are found Yes please :D Br, Jani > > Cheers, > Frederik > > > > > > > But this change doesn't meant we need to stop calling those releases > > as Alpha or Betas so we can continue labeling those as earlier. > > > > br, > > Jani > > > > > -----Original Message----- > > > From: Development > > project.org> On Behalf Of Lars Knoll > > > Sent: maanantai 16. huhtikuuta 2018 10.03 > > > To: Simon Hausmann > > > Cc: Qt development mailing list > > > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for > > > release process change > > > > > > Hi, > > > > > > From a releasing perspective I agree that the set we should update > > > our packages often. We should also stop delivering source only alpha > > > packages, and have binaries from the get go. > > > > > > But from a user perspective, I agree that it's good and important to > > > put a name to those releases so people know what to expect from them. > > > Snapshots as long as the packages are created from the dev branch, > > > then alpha, beta, RC and final. We could discuss whether we need the > > > alpha label, or whether we can go directly to beta, but I believe > > > that we do need the other tags. > > > > > > But I do agree with releasing packages as often as possible, and we > > > should have them already before FF from the dev branch (if possible). > > > > > > So I’d propose to have our packages updated often. But we do keep > > > the ‘snapshot’, ‘alpha’, ‘beta’ and ‘RC’ tags. > > > > > > - Snapshot packages from the dev branch > > > - FF and branching occur together and packages are getting the > > > ‘alpha’ tag > > > - Agree that we should start with the API review immediately. > > > - Beta once API review is done > > > - RC once we have the release branch and all currently known > > > blockers are fixed > > > > > > That should be pretty close to what Jani described, only that we > > > keep the tags for our users. > > > > > > Cheers, > > > Lars > > > > > > > On 16 Apr 2018, at 08:43, Simon Hausmann > > > > > > wrote: > > > > Hi, > > > > > > > > Same here. At first this seemed like a good idea, but it becomes > > > > awkward > > > > > > when you look at it from the dev workflow point of view: After > > > fixing a bug, what is the fix version? Reported in snapshot-24062918 > > > and fixed in snapshot-14072918? That sounds like it would create a > > > mess in JIRA.> > > > > Unless of course the task of assigning the fix version field was > > > > automated. > > > > > > > > Simon > > > > > > > > On 16. Apr 2018, at 08:12, Alex Blasche > wrote: > > > >>> -----Original Message----- > > > >>> > > > >>>> On Thursday, 12 April 2018 01:42:29 PDT Jani Heikkinen wrote: > > > >>>> And at this same time I want to propose that we stop delivering > > > >>>> alpha or beta releases and just do snapshots instead. > > > >>>> Publishing regular snapshots should be done until we are ready > > > >>>> for RC. That because I don't see that much need for those > > > >>>> anymore. Those are nowadays kind of milestones and in my > > > >>>> opinion makes whole process a bit unclear/difficult (we don't > > > >>>> have very good definitions for Alpha and Beta > > > >>> > > > >>> releases). > > > >>> > > > >>> Yes we do. > > > >>> > > > >>> Alpha means feature complete, asking for feedback on the API and > > > >>> new functionality. > > > >>> > > > >>> Beta means implementation complete, asking for feedback on the > > > >>> quality of the implementation, seeking bugs and regressions to > > > >>> be fixed. > > > >>> > > > >>> RC means we've fixed everything we knew. > > > >> > > > >> I wholeheartedly agree with Thiago. The distinction may not make > > > >> a > > > > > > difference from the release team perspective but it makes a world of > > > difference for developers (who have different limitations for each > > > step) and the world as they can decide how bleeding edge the code is > > > that they want to test. > > > > > > >> I have a problem with the motivation behind this suggestion too > > > >> (don't > > > > > > understand it). The naming makes no difference for you as release > > > manager (afaict just a label). Why suggesting it aka what do you > > > want to gain by doing snapshots only? > > > > > > >> -- > > > >> Alex > > > >> > > > >> _______________________________________________ > > > >> Development mailing list > > > >> Development at qt-project.org > > > >> http://lists.qt-project.org/mailman/listinfo/development > > > > > > > > _______________________________________________ > > > > Development mailing list > > > > Development at qt-project.org > > > > http://lists.qt-project.org/mailman/listinfo/development > > > > > > _______________________________________________ > > > Development mailing list > > > Development at qt-project.org > > > http://lists.qt-project.org/mailman/listinfo/development > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From abbapoh at gmail.com Tue Apr 17 08:09:25 2018 From: abbapoh at gmail.com (=?utf-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 17 Apr 2018 09:09:25 +0300 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> Message-ID: <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> > 16 апр. 2018 г., в 16:03, Giuseppe D'Angelo написал(а): > > On 16/04/18 12:23, Иван Комиссаров wrote: >> So, how those issues are checked? Any tool or what? > > Looking at the email archives: it was fuzzed through AFL. I don't have the test images still around, but in my experience a simple multi-image file was enough to trigger a crash. (I used to see this in Creator, when accidentally opening a DDS in its builtin image preview). What is AFP? Looking at the code, i found at some bugs (unchecked using scanline when image is null), i can easily fix that. A multiimage files are not implemnted (the code is supposed to read first image, still i don’t see why it can crash, i’ll try to generate such file and see what happens) > But again, why having such an image loader in Qt? It's not going to be useful in 99.9% of the use cases where you use a DDS file. Well, opening DDS file in Qt Creator is that «0.01%» usecase, but it’s quite convenient to do such thing. In case it doesn’t crash, though:( Or you’re developing a game and you need a map/level qwidget-based editor - it definitely should be able to open (and save) such textures. Or you’re writing an archiver for a game with a file preview. I don’t like reimplementing a wheel but i constantly have to because of that 0.01% of that «features that nobody needs»:) From jani.heikkinen at qt.io Tue Apr 17 08:28:06 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 17 Apr 2018 06:28:06 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> Message-ID: > -----Original Message----- > From: Alex Blasche > Sent: maanantai 16. huhtikuuta 2018 16.47 > To: Jani Heikkinen > Cc: Qt development mailing list > Subject: RE: [Development] Qt 5.12 schedule proposal & proposal for release > process change > > > -----Original Message----- > > From: Development [mailto:development- Keeping release tags is OK for > > me. Motivation behind my proposal was to stop planning other release > > dates than FF & final target. Currently we are trying to estimate also > > alpha, beta and RC release dates and it seems to cause some delays for > > us: persons aren't fixing blocker issues or doing the test because it > > seems there is a time to do that later (because e.g RC date is planned > > to be after a month). So if the way to go is to do these "releases" > > immediately when ready it might help us to get fixes in earlier and so on > also get releases out quicker... > > At large I agree with Frederik. The bug side of thing (which delays) we could > handle in a flexible manor exactly as described by Frederik. I do like to > emphasize though that the dates for first beta and first RC are important > (and FF is alpha) because they define times when certain level of changes are > no longer permitted (e.g. after first beta no API changes). Therefore, you will > not get around setting a target date for first Beta and RC. I have to disagree a bit: Alpha and beta phases are important and schedule for FF (and Alpha) as well. But for beta and RC we really don't need it: After API review is done we will enter in beta phase (and at this same time beta1 is released). And we should release RC when all blockers are fixed. If we schedule the RC beforehand it seems to affect how developers are prioritizing their work. And that's why I think we shouldn't even estimate when the RC is going to be happen: It is released when we are ready for it. So I think the way to proceed with this should be like Lars proposed: - Snapshot packages from the dev branch - FF and branching occur together and packages are getting the ‘alpha’ tag - Agree that we should start with the API review immediately. - Beta once API review is done. Lets agree the 'Done' properly to get it clear for everyone. I already tried to start discussion about it in http://lists.qt- > project.org/pipermail/development/2018-March/032338.html - RC once we have the release branch and all currently known blockers are fixed br, Jani > > -- > Alex From alexander.blasche at qt.io Tue Apr 17 09:51:08 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Tue, 17 Apr 2018 07:51:08 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> Message-ID: > -----Original Message----- > From: Jani Heikkinen > I have to disagree a bit: Alpha and beta phases are important and schedule for FF > (and Alpha) as well. But for beta and RC we really don't need it: After API review > is done we will enter in beta phase (and at this same time beta1 is released). And > we should release RC when all blockers are fixed. If we schedule the RC > beforehand it seems to affect how developers are prioritizing their work. And > that's why I think we shouldn't even estimate when the RC is going to be > happen: It is released when we are ready for it. > > So I think the way to proceed with this should be like Lars proposed: > - Snapshot packages from the dev branch > - FF and branching occur together and packages are getting the 'alpha' tag > - Agree that we should start with the API review immediately. > - Beta once API review is done. Lets agree the 'Done' properly to get it clear for > everyone. I already tried to start discussion about it in http://lists.qt- > > project.org/pipermail/development/2018-March/032338.html Developers get a window of time between Alpha and Beta to do finishing work on the API. This may include the API review or self-motivated changes. The review can only finish once the changes have finished. The above suggestion shrinks the window of opportunity for proper API down to the time of the review. That's not sufficient. In fact, that's not even a time based release process. At alpha time people focus on feature completion and API is not the absolute primary focus. That focus shifts after Alpha. Not setting a Beta target makes it impossible to plan post-alpha changes and as a matter of fact, it removes the deadline to finish up the official reviews too. Lars' suggestion does not imply that the only API changes after Alpha are the review changes. Lars also does not state that we shouldn't set a target date for beta. It may even mean that it shifts out when the review is not done. In summary let's not shift away from a time-based release process to a "when it's done" process (even for Beta or RC). It is hard to predict a time for you and it's equally hard for the engineers to stick to time. We all must shoulder a burden. When the time slips then it slips but there must be a min time frame given in advance for each release step. Then we can plan work. -- Alex From giuseppe.dangelo at kdab.com Tue Apr 17 10:02:09 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 17 Apr 2018 10:02:09 +0200 Subject: [Development] qdds image format In-Reply-To: <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> Message-ID: <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> On 17/04/18 08:09, Иван Комиссаров wrote: >> Looking at the email archives: it was fuzzed through AFL. I don't have the test images still around, but in my experience a simple multi-image file was enough to trigger a crash. (I used to see this in Creator, when accidentally opening a DDS in its builtin image preview). > What is AFP? American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/ >> But again, why having such an image loader in Qt? It's not going to be useful in 99.9% of the use cases where you use a DDS file. > Well, opening DDS file in Qt Creator is that «0.01%» usecase, but it’s quite convenient to do such thing. In case it doesn’t crash, though:( I wasn't trying to open it to do anything meaningful, it was because the DDS was in a resource file and Creator tries to build an icon for it or tries to visualize it when clicked. This triggered the crash in the DDS imageformat plugin. > Or you’re developing a game and you need a map/level qwidget-based editor - it definitely should be able to open (and save) such textures. > Or you’re writing an archiver for a game with a file preview. The problem I'm talking about is the API, not the feature itself: to properly handle DDS files you can't use QImage and QImageReader. So why having such support in a qtimageformat? We're talking about a format meant to store textures: how do you retrieve a mipmap chain using QImageReader? How do you retrieve a specific array level? How do you retrieve a specific cubemap face? How do you handle the formats that DDS can store and QImage can't represent? If the idea is to use a more specialized API for DDS files, I'm all for it -- as I said before, let's add it to QtGui, and work with other texture containers (KTX, etc.). My concern is about using QImage and its APIs for this. My 2 cents, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From abbapoh at gmail.com Tue Apr 17 10:48:55 2018 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 17 Apr 2018 11:48:55 +0300 Subject: [Development] qdds image format In-Reply-To: <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> Message-ID: 2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo : > On 17/04/18 08:09, Иван Комиссаров wrote: > >> Looking at the email archives: it was fuzzed through AFL. I don't have >>> the test images still around, but in my experience a simple multi-image >>> file was enough to trigger a crash. (I used to see this in Creator, when >>> accidentally opening a DDS in its builtin image preview). >>> >> What is AFP? >> > > American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/ > > But again, why having such an image loader in Qt? It's not going to be >>> useful in 99.9% of the use cases where you use a DDS file. >>> >> Well, opening DDS file in Qt Creator is that «0.01%» usecase, but it’s >> quite convenient to do such thing. In case it doesn’t crash, though:( >> > > I wasn't trying to open it to do anything meaningful, it was because the > DDS was in a resource file and Creator tries to build an icon for it or > tries to visualize it when clicked. This triggered the crash in the DDS > imageformat plugin. > Yeah, that's bad > > Or you’re developing a game and you need a map/level qwidget-based editor >> - it definitely should be able to open (and save) such textures. > Or >> you’re writing an archiver for a game with a file preview. >> > > The problem I'm talking about is the API, not the feature itself: to > properly handle DDS files you can't use QImage and QImageReader. So why > having such support in a qtimageformat? > > We're talking about a format meant to store textures: how do you retrieve > a mipmap chain using QImageReader? How do you retrieve a specific array > level? How do you retrieve a specific cubemap face? How do you handle the > formats that DDS can store and QImage can't represent? > > If the idea is to use a more specialized API for DDS files, I'm all for it > -- as I said before, let's add it to QtGui, and work with other texture > containers (KTX, etc.). My concern is about using QImage and its APIs for > this. > Well, i'm fully aware of the limitations of the QImageReader/Writer API and i one of the reasons i wrote DDS plugin is to see them *on practice*. I'm not sure if the API should be completely rewritten to support textures or slightly modified, but the truth is that current API doesn't even allow to implement writing plain-array files like GIF's *sigh*. I like the idea moving DDS suppport to a separate lib (and QImageReader can use that lib for preview purposes in QtCreator/QFileSystemModel within it's limited capabilities). About your concerns about QImage and DDS - i guess it can be used for textures, but it requires adding more values to the QImage::Format enum. After all, QImage is just an array of bits like any texture. Am i missing something? (yep, volume texture is not a QImage, but it can be represented using slices or as a separate class like QImage3d/QVolumeTexture) > > My 2 cents, > > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Tue Apr 17 11:08:32 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 17 Apr 2018 09:08:32 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> , Message-ID: Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) >>... I do like to emphasize though that the dates for first beta and >>first RC are important (and FF is alpha) because they define times >>when certain level of changes are no longer permitted (e.g. after >>first beta no API changes). Therefore, you will not get around setting >>a target date for first Beta and RC. Jani Heikkinen (17 April 2018 08:28) > I have to disagree a bit: Alpha and beta phases are important and > schedule for FF (and Alpha) as well. But for beta and RC we really > don't need it: After API review is done we will enter in beta phase > (and at this same time beta1 is released). And we should release RC > when all blockers are fixed. If we schedule the RC beforehand it > seems to affect how developers are prioritizing their work. And that's > why I think we shouldn't even estimate when the RC is going to be > happen: It is released when we are ready for it. Interesting reasoning. There is a degree to which, for each of these transitions, "it's ready when it's ready"; but that doesn't mean we shouldn't even attempt to guess when that'll be in advance. Perhaps rather than a "planned date" we should work with the date we hope for, as that may focus folk's attention more closely on getting things fixed early. > So I think the way to proceed with this should be like Lars proposed: > - Snapshot packages from the dev branch > - FF and branching occur together and packages are getting the ‘alpha’ tag > - Agree that we should start with the API review immediately. > - Beta once API review is done. Lets agree the 'Done' properly to get > it clear for everyone. I already tried to start discussion about it in > http://lists.qt-project.org/pipermail/development/2018-March/032338.html As noted in [0], this looks like QUIP material. Kai proposed, in a reply to [0], having a Jira ticket to track the review, with each issue it raises being turned into a sub-task of it. Your Done condition would then be the closing of that ticket, which would happen when every API review has got a +2, upon which I abandon it. I'll re-open a review, though, if I see any further apparently-material API changes, when I'm preparing updates to other reviews. I don't see anyone volunteering to write that QUIP, so I'll do so when time permits, unless someone else speaks up first. * [0] http://lists.qt-project.org/pipermail/development/2018-March/032362.html > - RC once we have the release branch and all currently known blockers are fixed You'll have the release branch just after alpha, if you follow the plan above, so the only condition left here is the known blockers. Even on those, we've had some flexibility in the past - some blockers do get downgraded sometimes - which can serve to steer a release towards fitting a schedule. To paraphrase and possibly mangle Jani's plan (without opinion on whether I like it; this is about making sure I understand the plan): Summary: * Make snapshots and FF, not release, the time-based part of our process. Details: * Make snap-shots regularly, merely changing their naming as we move through the phases below. * Branch, release first alpha and start API review at FF. Ever step after this takes as long as it does; and we try to keep each short. * Name snap-shots alpha n; all API changes must be notified to the review for their module, prompting an update to that review. * When API review is complete and all features are completely implemented, transition to beta. Only bug-fixes come in after this. * Name snap-shots beta n after this; ask folk to test beta 1 and report bugs; triage bugs, fix blockers. * When the blocker list is empty, transition to RC. If we can't find any "brown paper bag" issues, ship it; otherwise, fix, rinse and repeat. Jani: how far have I mangled your intent in expressing it thus ? Eddy. From jani.heikkinen at qt.io Tue Apr 17 11:40:10 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Tue, 17 Apr 2018 09:40:10 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> , Message-ID: > -----Original Message----- > From: Edward Welbourne > Sent: tiistai 17. huhtikuuta 2018 12.09 > To: Jani Heikkinen ; Alex Blasche > > Cc: Qt development mailing list > Subject: Re: [Development] Qt 5.12 schedule proposal & proposal for release > process change > > To paraphrase and possibly mangle Jani's plan (without opinion on whether I > like it; this is about making sure I understand the plan): > > Summary: > * Make snapshots and FF, not release, the time-based part of our process. > > Details: > * Make snap-shots regularly, merely changing their naming as we move > through the phases below. > * Branch, release first alpha and start API review at FF. Ever step > after this takes as long as it does; and we try to keep each short. > * Name snap-shots alpha n; all API changes must be notified to the > review for their module, prompting an update to that review. > * When API review is complete and all features are completely > implemented, transition to beta. Only bug-fixes come in after this. > * Name snap-shots beta n after this; ask folk to test beta 1 and report > bugs; triage bugs, fix blockers. > * When the blocker list is empty, transition to RC. If we can't find > any "brown paper bag" issues, ship it; otherwise, fix, rinse and > repeat. > > Jani: how far have I mangled your intent in expressing it thus ? > > Eddy. This is exactly what I meant. br, Jani From kari.oikarinen at qt.io Tue Apr 17 12:18:40 2018 From: kari.oikarinen at qt.io (Kari Oikarinen) Date: Tue, 17 Apr 2018 13:18:40 +0300 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> Message-ID: On 17.04.2018 12:08, Edward Welbourne wrote: > Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) >>> ... I do like to emphasize though that the dates for first beta and >>> first RC are important (and FF is alpha) because they define times >>> when certain level of changes are no longer permitted (e.g. after >>> first beta no API changes). Therefore, you will not get around setting >>> a target date for first Beta and RC. > > Jani Heikkinen (17 April 2018 08:28) >> So I think the way to proceed with this should be like Lars proposed: >> - Snapshot packages from the dev branch >> - FF and branching occur together and packages are getting the ‘alpha’ tag >> - Agree that we should start with the API review immediately. >> - Beta once API review is done. Lets agree the 'Done' properly to get >> it clear for everyone. I already tried to start discussion about it in >> http://lists.qt-project.org/pipermail/development/2018-March/032338.html >> - RC once we have the release branch and all currently known blockers are fixed > > You'll have the release branch just after alpha, if you follow the plan > above, so the only condition left here is the known blockers. Even on > those, we've had some flexibility in the past - some blockers do get > downgraded sometimes - which can serve to steer a release towards > fitting a schedule. For example with 5.11.0 release there's two branching points for branches 5.11 and 5.11.0. Maybe with release branch the latter is meant? So dev -> 5.12 branching would happen at feature freeze and 5.12 -> 5.12.0 branching would happen in the transition to RC? A good naming convention for those branches might help keep them separate. "Minor branches" and "release branches" maybe? -- Kari From abbapoh at gmail.com Tue Apr 17 13:21:25 2018 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 17 Apr 2018 14:21:25 +0300 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> Message-ID: Ok, there's another problem with QImage - ARGB64 and friends... This can be solved adding QImage::pixel64() or something like that... or use QTexture with 64bit "pixel" 2018-04-17 11:48 GMT+03:00 Иван Комиссаров : > > > 2018-04-17 11:02 GMT+03:00 Giuseppe D'Angelo : > >> On 17/04/18 08:09, Иван Комиссаров wrote: >> >>> Looking at the email archives: it was fuzzed through AFL. I don't have >>>> the test images still around, but in my experience a simple multi-image >>>> file was enough to trigger a crash. (I used to see this in Creator, when >>>> accidentally opening a DDS in its builtin image preview). >>>> >>> What is AFP? >>> >> >> American Fuzzy Lop: http://lcamtuf.coredump.cx/afl/ >> >> But again, why having such an image loader in Qt? It's not going to be >>>> useful in 99.9% of the use cases where you use a DDS file. >>>> >>> Well, opening DDS file in Qt Creator is that «0.01%» usecase, but it’s >>> quite convenient to do such thing. In case it doesn’t crash, though:( >>> >> >> I wasn't trying to open it to do anything meaningful, it was because the >> DDS was in a resource file and Creator tries to build an icon for it or >> tries to visualize it when clicked. This triggered the crash in the DDS >> imageformat plugin. >> > > Yeah, that's bad > > >> >> Or you’re developing a game and you need a map/level qwidget-based editor >>> - it definitely should be able to open (and save) such textures. > Or >>> you’re writing an archiver for a game with a file preview. >>> >> >> The problem I'm talking about is the API, not the feature itself: to >> properly handle DDS files you can't use QImage and QImageReader. So why >> having such support in a qtimageformat? >> >> We're talking about a format meant to store textures: how do you retrieve >> a mipmap chain using QImageReader? How do you retrieve a specific array >> level? How do you retrieve a specific cubemap face? How do you handle the >> formats that DDS can store and QImage can't represent? >> >> If the idea is to use a more specialized API for DDS files, I'm all for >> it -- as I said before, let's add it to QtGui, and work with other texture >> containers (KTX, etc.). My concern is about using QImage and its APIs for >> this. >> > > Well, i'm fully aware of the limitations of the QImageReader/Writer API > and i one of the reasons i wrote DDS plugin is to see them *on practice*. > I'm not sure if the API should be completely rewritten to support textures > or slightly modified, but the truth is that current API doesn't even allow > to implement writing plain-array files like GIF's *sigh*. > I like the idea moving DDS suppport to a separate lib (and QImageReader > can use that lib for preview purposes in QtCreator/QFileSystemModel within > it's limited capabilities). > About your concerns about QImage and DDS - i guess it can be used for > textures, but it requires adding more values to the QImage::Format enum. > After all, QImage is just an array of bits like any texture. Am i missing > something? (yep, volume texture is not a QImage, but it can be represented > using slices or as a separate class like QImage3d/QVolumeTexture) > > >> >> My 2 cents, >> >> -- >> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer >> KDAB (France) S.A.S., a KDAB Group company >> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com >> KDAB - The Qt, C++ and OpenGL Experts >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From giuseppe.dangelo at kdab.com Tue Apr 17 13:28:10 2018 From: giuseppe.dangelo at kdab.com (Giuseppe D'Angelo) Date: Tue, 17 Apr 2018 13:28:10 +0200 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> Message-ID: On 17/04/18 13:21, Иван Комиссаров wrote: > Ok, there's another problem with QImage - ARGB64 and friends... This can > be solved adding QImage::pixel64() or something like that... or use > QTexture with 64bit "pixel" And a bunch of packed formats not currently supported, and floating point channels, and compressed texture formats. I stand my point: DDS files are not meant to be handled by QImage. What is your use case exactly for wanting this support? Cheers, -- Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4007 bytes Desc: S/MIME Cryptographic Signature URL: From jhihn at gmx.com Tue Apr 17 16:19:27 2018 From: jhihn at gmx.com (Jason H) Date: Tue, 17 Apr 2018 16:19:27 +0200 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> Message-ID: > From: "Giuseppe D'Angelo" > On 17/04/18 13:21, Иван Комиссаров wrote: > > Ok, there's another problem with QImage - ARGB64 and friends... This can > > be solved adding QImage::pixel64() or something like that... or use > > QTexture with 64bit "pixel" > > And a bunch of packed formats not currently supported, and floating > point channels, and compressed texture formats. I stand my point: DDS > files are not meant to be handled by QImage. > > What is your use case exactly for wanting this support? Sorry to hijack this, but adding YUV support to QImage (or anywhere in Qt, really) would be a welcome addition for those of is wanting to capture images from video devices. I keep having to code my own YUV decoder for whatever frames I need to support (Currently, NV21, BGR32, though in the past YUV420). I'm sure the trolls could do a better job at it than I. Having them supported would be a boon to anyone using QVideoFilterRunnable, QAbstractVideoFilter, QVideoProbe classes. From abbapoh at gmail.com Tue Apr 17 16:33:22 2018 From: abbapoh at gmail.com (=?UTF-8?B?0JjQstCw0L0g0JrQvtC80LjRgdGB0LDRgNC+0LI=?=) Date: Tue, 17 Apr 2018 17:33:22 +0300 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> Message-ID: At the point i wrote the plugin, my usecase was simple - to convert plain QImages to and from DDS icons (used in starcraft2, which uses quite a few formats DDS can handle). But yes, i forgot floating point textures. Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody uses compressed jpeg, it is decompressed before usage (correct me if i'm wrong, but videocards uses DDS because it's decompression algorithm can be easily implemented in hardware) 2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo : > On 17/04/18 13:21, Иван Комиссаров wrote: > >> Ok, there's another problem with QImage - ARGB64 and friends... This can >> be solved adding QImage::pixel64() or something like that... or use >> QTexture with 64bit "pixel" >> > > And a bunch of packed formats not currently supported, and floating point > channels, and compressed texture formats. I stand my point: DDS files are > not meant to be handled by QImage. > > What is your use case exactly for wanting this support? > > Cheers, > > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From annulen at yandex.ru Tue Apr 17 16:35:44 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Tue, 17 Apr 2018 17:35:44 +0300 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> Message-ID: <942821523975744@web51g.yandex.ru> 17.04.2018, 17:33, "Иван Комиссаров" : > At the point i wrote the plugin, my usecase was simple - to convert plain QImages to and from DDS icons (used in starcraft2, which uses quite a few formats DDS can handle). > But yes, i forgot floating point textures. > Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody uses compressed jpeg, it is decompressed before usage (correct me if i'm wrong, but videocards uses DDS because it's decompression algorithm can be easily implemented in hardware) FWIW, hardware decoding of JPEG is usually supported by devices featuring hardware video decoding support. > > 2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo : >> On 17/04/18 13:21, Иван Комиссаров wrote: >> Ok, there's another problem with QImage - ARGB64 and friends... This can be solved adding QImage::pixel64() or something like that... or use QTexture with 64bit "pixel" >> >> And a bunch of packed formats not currently supported, and floating point channels, and compressed texture formats. I stand my point: DDS files are not meant to be handled by QImage. >> >> What is your use case exactly for wanting this support? >> >> Cheers, >> >> -- >> Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer >> KDAB (France) S.A.S., a KDAB Group company >> Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com >> KDAB - The Qt, C++ and OpenGL Experts > , > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development --  Regards, Konstantin From edward.welbourne at qt.io Tue Apr 17 16:48:08 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 17 Apr 2018 14:48:08 +0000 Subject: [Development] Qt 5.12 schedule proposal & proposal for release process change In-Reply-To: References: <1691604.Q5BBe59CSV@tjmaciei-mobl1> <199E23D9-47C1-4891-A70C-F2465269B377@qt.io> <40E8206F-6D35-4F99-95C8-E22CCCD8CC6D@qt.io> , , Message-ID: Alex Blasche (maanantai 16. huhtikuuta 2018 16.47) >>> ... I do like to emphasize though that the dates for first beta and >>> first RC are important (and FF is alpha) because they define times >>> when certain level of changes are no longer permitted (e.g. after >>> first beta no API changes). Therefore, you will not get around >>> setting a target date for first Beta and RC. Jani Heikkinen (17 April 2018 08:28) >> - Agree that we should start with the API review immediately. >> - Beta once API review is done. Lets agree the 'Done' properly to get >> it clear for everyone. I already tried to start discussion about it in >> http://lists.qt-project.org/pipermail/development/2018-March/032338.html Edward Welbourne (17 April 2018 11:08) > As noted in [0], this looks like QUIP material. Kai proposed, in a > reply to [0], having a Jira ticket to track the review, with each issue > it raises being turned into a sub-task of it. Your Done condition would > then be the closing of that ticket, which would happen when every API > review has got a +2, upon which I abandon it. I'll re-open a review, > though, if I see any further apparently-material API changes, when I'm > preparing updates to other reviews. > > * [0] http://lists.qt-project.org/pipermail/development/2018-March/032362.html > > I don't see anyone volunteering to write that QUIP, so I'll do so when > time permits, unless someone else speaks up first. Here's my first attempt at that QUIP: https://codereview.qt-project.org/226574 Eddy. From thiago.macieira at intel.com Tue Apr 17 17:26:45 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 17 Apr 2018 08:26:45 -0700 Subject: [Development] qdds image format In-Reply-To: <942821523975744@web51g.yandex.ru> References: <942821523975744@web51g.yandex.ru> Message-ID: <2337815.18jJGFbr55@tjmaciei-mobl1> On Tuesday, 17 April 2018 07:35:44 PDT Konstantin Tokarev wrote: > FWIW, hardware decoding of JPEG is usually supported by devices featuring > hardware video decoding support. But that's still decompressing it. You're just using the HW to do it faster. The only use-case I can easily think of for using the compressed JPEG data is lossless rotation in multiples of 90°. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From Kai.Koehne at qt.io Wed Apr 18 09:52:27 2018 From: Kai.Koehne at qt.io (Kai Koehne) Date: Wed, 18 Apr 2018 07:52:27 +0000 Subject: [Development] Maintainers: Make sure QML import in documentation and plugins.qmltypes are up to date for 5.11 Message-ID: Hi, If your respective module has a QML import and there's new API / a new import version, please make sure now that both the documentation and the tooling support accommodates for that. For documentation, it is usually enough to bump the import in the "\qmlmodule XXX major.minor" declaration, and in the module description. See e.g. https://codereview.qt-project.org/#/c/226631/1 . This will make sure that the 'landing page' of your module recommends the latest import, and that documentation for every single qml type will start with the latest up to date import statement. plugins.qmltypes is the mechanism how Qt Creator knows about new types and properties. That is, if it doesn't get updated, the new import and new types, properties and methods will be underlined as unknown in Qt Creator. To update it, it is usually enough to run [n]make qmltypes In the build folder where the plugins.qmltypes file belongs to. This is btw also a good way to do an API review. In particular, to check whether all new properties, signals ... have a proper REVISION / are properly versioned. Regards Kai -- Kai Koehne, Senior Manager R&D | The Qt Company The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho. Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B From sean.harmer at kdab.com Thu Apr 19 12:36:01 2018 From: sean.harmer at kdab.com (Sean Harmer) Date: Thu, 19 Apr 2018 11:36:01 +0100 Subject: [Development] qdds image format In-Reply-To: References: <29e722c1-8dce-a876-5a93-2649b5d79cb5@kdab.com> <1729744.hIf54J7YqV@tjmaciei-mobl1> <15BC8365-6E6A-482D-B45F-7AE8B7D258AD@gmail.com> <0fa1dd60-4864-dd7e-060c-7889541bb87b@kdab.com> Message-ID: <67e0ad84-d8b1-9a7b-7928-1470e6a3fbd5@kdab.com> On 17/04/2018 15:33, Иван Комиссаров wrote: > At the point i wrote the plugin, my usecase was simple - to convert > plain QImages to and from DDS icons (used in starcraft2, which uses > quite a few formats DDS can handle). > But yes, i forgot floating point textures. > Compressed textures (DXTN/ATI2) are just compressed (a)rgb32, nobody > uses compressed jpeg, it is decompressed before usage (correct me if i'm > wrong, but videocards uses DDS because it's decompression algorithm can > be easily implemented in hardware) DDS is just a container format. Peppe's point stands, QImage and friends are the wrong vehicle for supporting this. They simply do not offer enough degrees of freedom in the API to do so properly. And adding them would be changing what QImage is designed for. QImage is designed to represent a single image in one of a few supported formats. Proper texture support needs to be able to address images by mip level, array layer and cubemap face in any of the formats supported. The compressions used by various formats supported within a DDS (or KTX) file are designed so they can be decompressed on the fly for a small block of pixels. These block compression algorithms do not offer such on-disk savings as png/jpeg but are much easier to sample from in access patterns typically required by fragment shaders. I'm not saying a tool to convert to/from dds/some other format would not be useful. Just that QImage is the wrong way to approach this due to the above. Sean > > 2018-04-17 14:28 GMT+03:00 Giuseppe D'Angelo >: > > On 17/04/18 13:21, Иван Комиссаров wrote: > > Ok, there's another problem with QImage - ARGB64 and friends... > This can be solved adding QImage::pixel64() or something like > that... or use QTexture with 64bit "pixel" > > > And a bunch of packed formats not currently supported, and floating > point channels, and compressed texture formats. I stand my point: > DDS files are not meant to be handled by QImage. > > What is your use case exactly for wanting this support? > > Cheers, > > -- > Giuseppe D'Angelo | giuseppe.dangelo at kdab.com > | Senior Software Engineer > KDAB (France) S.A.S., a KDAB Group company > Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com > KDAB - The Qt, C++ and OpenGL Experts > > > > > _______________________________________________ > 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 hello at mnafees.me Fri Apr 20 05:29:21 2018 From: hello at mnafees.me (Mohammed Nafees) Date: Thu, 19 Apr 2018 23:29:21 -0400 Subject: [Development] Google Summer of Code 2018 Message-ID: <162e1196a30.11de2c189156527.644549615725432520@mnafees.me> Hello, I am Mohammed Nafees, a 2nd year CS student at the University of Waterloo and I had applied to GSoC 2018 for The Qt Project to work on porting Qt to IncludeOS. Earlier today I was notified that my project has not been selected by the mentors as one of the projects for GSoC 2018. I was notified that there were 2 slots given and one was selected for Qt Creator related project and the other was selected for Qt, in general. My project was for Qt and the selection process between me and another project was a coin flip. I find this criterion of selection absolutely ridiculous, I'm sorry. First of all, organisations can ask Google to increase their number of slots. There was especially a date set just for that in the timeline. Secondly, I was the one to notify on the IRC channel that the Ideas URL for the organisation in GSoC's website was wrong. I helped change it to the actual one. I am a Qt veteran and have been using it for the past 5+ years. I am a former Google Code-in champion and a GSoC 2017 alumnus. I have the right to be disappointed because I was the one overjoyed about seeing The Qt Project in this year's GSoC. I am highly disappointed by how you have rejected my project based on a coin flip. I was looking forward to work for my favorite toolkit so much so that I did not apply to any other organisation. Nafees. -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.astals.cid at kdab.com Fri Apr 20 10:15:26 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Fri, 20 Apr 2018 10:15:26 +0200 Subject: [Development] Google Summer of Code 2018 In-Reply-To: <162e1196a30.11de2c189156527.644549615725432520@mnafees.me> References: <162e1196a30.11de2c189156527.644549615725432520@mnafees.me> Message-ID: <1742970.OzVi15i1Bz@yoga> El divendres, 20 d’abril de 2018, a les 5:29:21 CEST, Mohammed Nafees va escriure: > Hello, > > > > I am Mohammed Nafees, a 2nd year CS student at the University of Waterloo > and I had applied to GSoC 2018 for The Qt Project to work on porting Qt to > IncludeOS. Earlier today I was notified that my project has not been > selected by the mentors as one of the projects for GSoC 2018. I was > notified that there were 2 slots given and one was selected for Qt Creator > related project and the other was selected for Qt, in general. My project > was for Qt and the selection process between me and another project was a > coin flip. I find this criterion of selection absolutely ridiculous, I'm > sorry. > > > > First of all, organisations can ask Google to increase their number of > slots. There was especially a date set just for that in the timeline. > Secondly, I was the one to notify on the IRC channel that the Ideas URL for > the organisation in GSoC's website was wrong. I helped change it to the > actual one. I am a Qt veteran and have been using it for the past 5+ years. > I am a former Google Code-in champion and a GSoC 2017 alumnus. I have the > right to be disappointed because I was the one overjoyed about seeing The > Qt Project in this year's GSoC. > > > > I am highly disappointed by how you have rejected my project based on a coin > flip. I was looking forward to work for my favorite toolkit so much so that > I did not apply to any other organisation. I understand you are disappointed, but you should understand this email reflects poorly on you and if i was involved in the GSOC organization it would make you lose points for next year. How do you know the organization didn't ask for an increase of slots and Google simply refused? Then you list all your "merits" as a way of saying "no way the other person was as good as me", that's a severe lack of self awareness, we all think we're good at something, yet for the most part, the world is full of people that are better than us at that very same thing. As said i understand frustation when you're not selected, but this is not the email you should have written. The email you should have written is something along the lines of "how can improve for next year so my proposal is stronger and then not a coin flip is needed?". Cheers, Albert P.S: I'm not involved in GSOC for Qt. > > > > Nafees. From jani.heikkinen at qt.io Fri Apr 20 11:02:37 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 20 Apr 2018 09:02:37 +0000 Subject: [Development] Qt 5.11 Beta4 released In-Reply-To: References: Message-ID: Hi all, Qt 5.11 beta4 is released today. As usual you can get it via online installer. Delta to beta3 as an attachment. We are planning to release RC at the end of April so please make sure all release blockers are visible in RC blocker list (https://bugreports.qt.io/issues/?filter=19209). And also fix all blockers from the list immediately. We will start preparations for RC soon and I hope there won't be any late blocker findings at this time... br, Jani -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: delta_qt511-beta3-qt511-beta4.txt URL: From hello at mnafees.me Fri Apr 20 11:23:51 2018 From: hello at mnafees.me (Mohammed Nafees) Date: Fri, 20 Apr 2018 05:23:51 -0400 Subject: [Development] Google Summer of Code 2018 In-Reply-To: <1742970.OzVi15i1Bz@yoga> References: <162e1196a30.11de2c189156527.644549615725432520@mnafees.me> <1742970.OzVi15i1Bz@yoga> Message-ID: <162e25df4c7.c32fec7c290229.7064634089463041231@mnafees.me> I am sorry if the tone of my email sounds rude. I have no say as to what an organisation chooses to do. I have not listed anything to show that I am the best candidate they could have chosen. I know there are much better candidates out there. My main focus for the email was the way the project was selected - a coin flip. I think there should have been a better way to select / reject a project and that the project proposal should've been taken into account as well.As said earlier, I'm sorry to sound rude and I have no intention to hurt anyone. This was my last year of GSoC, hence the added frustration. But I'd like to congratulate the selected students and hope they have an amazing time working on Qt with GSoC.Best,Nafees.---- On Fri, 20 Apr 2018 04:15:26 -0400 Albert Astals Cid wrote ----El divendres, 20 d’abril de 2018, a les 5:29:21 CEST, Mohammed Nafees va escriure:> Hello,> > > > I am Mohammed Nafees, a 2nd year CS student at the University of Waterloo> and I had applied to GSoC 2018 for The Qt Project to work on porting Qt to> IncludeOS. Earlier today I was notified that my project has not been> selected by the mentors as one of the projects for GSoC 2018. I was> notified that there were 2 slots given and one was selected for Qt Creator> related project and the other was selected for Qt, in general. My project> was for Qt and the selection process between me and another project was a> coin flip. I find this criterion of selection absolutely ridiculous, I'm> sorry.> > > > First of all, organisations can ask Google to increase their number of> slots. There was especially a date set just for that in the timeline.> Secondly, I was the one to notify on the IRC channel that the Ideas URL for> the organisation in GSoC's website was wrong. I helped change it to the> actual one. I am a Qt veteran and have been using it for the past 5+ years.> I am a former Google Code-in champion and a GSoC 2017 alumnus. I have the> right to be disappointed because I was the one overjoyed about seeing The> Qt Project in this year's GSoC.> > > > I am highly disappointed by how you have rejected my project based on a coin> flip. I was looking forward to work for my favorite toolkit so much so that> I did not apply to any other organisation.I understand you are disappointed, but you should understand this email reflects poorly on you and if i was involved in the GSOC organization it would make you lose points for next year.How do you know the organization didn't ask for an increase of slots and Google simply refused?Then you list all your "merits" as a way of saying "no way the other person was as good as me", that's a severe lack of self awareness, we all think we're good at something, yet for the most part, the world is full of people that are better than us at that very same thing.As said i understand frustation when you're not selected, but this is not the email you should have written. The email you should have written is something along the lines of "how can improve for next year so my proposal is stronger and then not a coin flip is needed?".Cheers, AlbertP.S: I'm not involved in GSOC for Qt.> > > > Nafees._______________________________________________Development mailing listDevelopment at qt-project.orghttp://lists.qt-project.org/mailman/listinfo/development -------------- next part -------------- An HTML attachment was scrubbed... URL: From albert.astals.cid at kdab.com Fri Apr 20 11:58:49 2018 From: albert.astals.cid at kdab.com (Albert Astals Cid) Date: Fri, 20 Apr 2018 11:58:49 +0200 Subject: [Development] Google Summer of Code 2018 In-Reply-To: <162e25df4c7.c32fec7c290229.7064634089463041231@mnafees.me> References: <162e1196a30.11de2c189156527.644549615725432520@mnafees.me> <1742970.OzVi15i1Bz@yoga> <162e25df4c7.c32fec7c290229.7064634089463041231@mnafees.me> Message-ID: <3587410.EPrK8tkIti@yoga> El divendres, 20 d’abril de 2018, a les 11:23:51 CEST, Mohammed Nafees va escriure: > I am sorry if the tone of my email sounds rude. I have no say as > to what an organisation chooses to do. I have not listed anything to show > that I am the best candidate they could have chosen. I know there are much > better candidates out there. My main focus for the email was the way the > project was selected - a coin flip. I think there should have been a better > way to select / reject a project and that the project proposal should've > been taken into account as well. As said I'm not involved in the selection process, but if you've been told a coin flip was used as selection process, logic says it's because both project proposals were evaluated and deemed to be as good as the other, and given one had to be chosen, coin flip was the fairest method. Best Regards, Albert -- Albert Astals Cid | albert.astals.cid 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, C++ and OpenGL Experts From jani.heikkinen at qt.io Fri Apr 20 12:28:58 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 20 Apr 2018 10:28:58 +0000 Subject: [Development] HEADS-UP: Branching '5.11.0' from '5.11' completed In-Reply-To: References: Message-ID: Hi! Branching from '5.11' to '5.11.0' is now ready. From now on '5.11' is for Qt 5.11.1 and all changes targeted to Qt 5.11.0 release must be done in '5.11.0'. And remember: We are trying to get RC out at the end of April so no any nice-to-haves in anymore. As usual release team will create initial changes files for Qt 5.11.0 as soon as possible. Please make sure you will do needed modifications there without any delay br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Thursday, April 12, 2018 4:52 PM To: development at qt-project.org Cc: releasing at qt-project.org Subject: [Development] HEADS-UP: Branching '5.11.0' from '5.11' started Hi all, We have soft branched '5.11.0' from '5.11'. Please start using '5.11.0' for new changes targeted to Qt 5.11.0 release. Final downmerge from '5.11' to '5.11.0' will happen Thursday 19th April so there should be enough time to finalize ongoing changes in '5.11' and start using '5.11.0' for new ones. We are targeting to release Qt 5.11.0 rc before end of April so please make sure all blockers are fixed immediately. Qt 5.11.0 RC blocker list here: https://bugreports.qt.io/issues/?filter=19209 br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From jani.heikkinen at qt.io Fri Apr 20 14:22:32 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Fri, 20 Apr 2018 12:22:32 +0000 Subject: [Development] Qt 5.11.0 changes files Message-ID: Hi all, initial ones available, see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.11.0%22,n,z Maintainers, please do needed modifications immediately & get '+2' br, Jani Heikkinen Release Manager From jakabac at gmail.com Fri Apr 20 15:03:08 2018 From: jakabac at gmail.com (Jaka Bac) Date: Fri, 20 Apr 2018 15:03:08 +0200 Subject: [Development] Why Widget::grabMouse() installs WH_JOURNALRECORD hook on Windows in Qt 4.8.x Message-ID: In Qt 4.8.x Widget::grabMouse() does this on Windows: void QWidget::grabMouse() { if (!qt_nograb()) { if (mouseGrb) mouseGrb->releaseMouse(); journalRec = SetWindowsHookEx(WH_JOURNALRECORD, (HOOKPROC)qJournalRecordProc, GetModuleHandle(0), 0); Q_ASSERT(testAttribute(Qt::WA_WState_Created)); SetCapture(effectiveWinId()); mouseGrb = this; #ifndef QT_NO_CURSOR mouseGrbCur = new QCursor(mouseGrb->cursor()); #endif } } qJournalRecordProc is defined as: // The procedure does nothing, but is required for mousegrabbing to work #ifndef Q_WS_WINCE LRESULT QT_WIN_CALLBACK qJournalRecordProc(int nCode, WPARAM wParam, LPARAM lParam) { return CallNextHookEx(journalRec, nCode, wParam, lParam); } #endif //Q_WS_WINCE I know that Qt 4.8.x is long out of support and Qt 5 does not do this anymore, but... WH_JOURNALRECORD hooks are subjected to various security requirements since Vista or the SetWindowsHookEx call simply fails. The thing is, that in some cases it does not fail, but messes up the complete Desktop (until hook is removed by pressing Ctrl+Esc). If the hook/unhook calls fail or are removed, applications that call grabMouse still work without any noticeable issues. Since this clearly a hack that was obviously needed to make mouse grabbing working, I would very much like to know why it was done in this way and what was the original problem. I would be very grateful if someone could spare some time to answer my question since this "issue" literally drove me nuts while debugging a legacy application. To the point of tracing windows kernel side related to the hooks. Thanks a lot and a nice weekend, Jaka -------------- next part -------------- An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Fri Apr 20 16:22:40 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 20 Apr 2018 14:22:40 +0000 Subject: [Development] Qt 5.11 Alpha released In-Reply-To: References: , , Message-ID: Jani Heikkinen (20 February 2018 11:14) >> We have release Qt 5.11 Alpha today, see http://blog.qt.io/blog/2018/02/20/qt-5-11-alpha-released/ I wrote (21 February 2018 17:43) > and so, of course, we also have 5.11 API reviews, vs v5.10.1: and while eight of these are resolved, https://codereview.qt-project.org/221041 qtmultimedia https://codereview.qt-project.org/221043 qtxmlpatterns https://codereview.qt-project.org/221045 qtconnectivity https://codereview.qt-project.org/221048 qtserialbus https://codereview.qt-project.org/221049 qtandroidextras https://codereview.qt-project.org/221051 qtcharts https://codereview.qt-project.org/221052 qtgamepad https://codereview.qt-project.org/221053 qtremoteobjects seven remain unresolved. I've updated these to the 5.11.0 branch, to pick up any changes since my last update: https://codereview.qt-project.org/221039 qtbase https://codereview.qt-project.org/221040 qtdeclarative https://codereview.qt-project.org/221042 qttools https://codereview.qt-project.org/221044 qtlocation https://codereview.qt-project.org/221046 qtwayland https://codereview.qt-project.org/221047 qt3d https://codereview.qt-project.org/221050 qtwebengine Please take a look at those and deal with any outstanding issues - sooner rather than later. Please file sub-tasks of QTBUG-67191 for any issues you raise: it should raise their visibility, as this task is a P1 blocker for the release ! Eddy. From Jan.Murawski at governikus.de Mon Apr 23 10:11:20 2018 From: Jan.Murawski at governikus.de (Murawski, Jan) Date: Mon, 23 Apr 2018 08:11:20 +0000 Subject: [Development] How to run qtbase/tests/auto/network ? Message-ID: <88385bc1-72a9-75e1-b8b7-9d5d2db88cee@governikus.de> I have build the test and running “make check” fails with: ##snip## FAIL! : tst_QHttpNetworkConnection::initTestCase() 'QtNetworkSettings::verifyTestNetworkSettings()' returned FALSE. () Loc: [/home/jm/qt.git/qt5/qtbase/tests/auto/network/access/qhttpnetworkconnection/tst_qhttpnetworkconnection.cpp(104)] ##snip## So far I failed to find information on the required setup online. Might someone point me at instructions on how to setup the required test server(s)? :) Cheers, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: From Jan.Murawski at governikus.de Mon Apr 23 11:03:58 2018 From: Jan.Murawski at governikus.de (Murawski, Jan) Date: Mon, 23 Apr 2018 09:03:58 +0000 Subject: [Development] How to run qtbase/tests/auto/network ? In-Reply-To: <88385bc1-72a9-75e1-b8b7-9d5d2db88cee@governikus.de> References: <88385bc1-72a9-75e1-b8b7-9d5d2db88cee@governikus.de> Message-ID: Posting the question helped. I finally stumbled upon https://wiki.qt.io/Qt_Autotest_Environment . On 23.04.2018 10:11, Murawski, Jan wrote: I have build the test and running “make check” fails with: ##snip## FAIL! : tst_QHttpNetworkConnection::initTestCase() 'QtNetworkSettings::verifyTestNetworkSettings()' returned FALSE. () Loc: [/home/jm/qt.git/qt5/qtbase/tests/auto/network/access/qhttpnetworkconnection/tst_qhttpnetworkconnection.cpp(104)] ##snip## So far I failed to find information on the required setup online. Might someone point me at instructions on how to setup the required test server(s)? :) Cheers, Jan _______________________________________________ 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 edward.welbourne at qt.io Mon Apr 23 11:17:35 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Mon, 23 Apr 2018 09:17:35 +0000 Subject: [Development] How to run qtbase/tests/auto/network ? In-Reply-To: <88385bc1-72a9-75e1-b8b7-9d5d2db88cee@governikus.de> References: <88385bc1-72a9-75e1-b8b7-9d5d2db88cee@governikus.de> Message-ID: Murawski, Jan (23 April 2018 10:11): > I have build the test and running “make check” fails with: > > ##snip## > FAIL! : tst_QHttpNetworkConnection::initTestCase() 'QtNetworkSettings::verifyTestNetworkSettings()' returned FALSE. () > Loc: [.../tests/auto/network/access/qhttpnetworkconnection/tst_qhttpnetworkconnection.cpp(104)] > ##snip## > > So far I failed to find information on the required setup > online. Might someone point me at instructions on how to setup the > required test server(s)? :) It's tricky. We have a network test server accessible from TQtC's internal network; and (IIUC) one or two other developers have managed to set up matching servers of their own; but it's non-trivial and the test server in question is out of date and clunky. Attempts to migrate to an updated version of it have run into random differences in how tests behave, just due to the server being more up-to-date, and an attempt to replace it with a Vagrant ran into the same problems. It's not pretty. We do now, however, have a project under way to (incrementally, one test at a time) migrate to a new system of container-based servers (one per service or small group of them) so that anyone and everyone (at least, as long as they're on a platform which has docker) can do their own testing: https://bugreports.qt.io/browse/QTQAINFRA-1686 In the mean time, if those outside TQtC want network tests run, the best approach is to put your change on gerrit (as a draft, if you prefer) and ask one of us that's inside to get Coin to run testing on it - please say which platforms you want testing on. Note that, unlike integration testing, such a test runs on the commit of qtbase that's in the review, not on the result of cherry-picking it to the branch it's destined for, so you do need to rebase past any relevant bug-fixes that you know have gone into the integrated branch. Sorry we can't (yet) do better, but we are working on fixing that ;-) Eddy. From jani.heikkinen at qt.io Mon Apr 23 13:52:38 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Mon, 23 Apr 2018 11:52:38 +0000 Subject: [Development] MAINTAINERS, your actions needed: Qt 5.11.0 changes files In-Reply-To: References: Message-ID: Hi! Just a kindly reminder: We don't want to delay RC because of these so please make sure these changes files will be checked & modified now. We will put those in as it is Wed 25.4.2018 EOB if there isn't clear message in the change ('-1') that it isn't ready yet br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, April 20, 2018 3:22 PM To: development at qt-project.org Subject: [Development] Qt 5.11.0 changes files Hi all, initial ones available, see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.11.0%22,n,z Maintainers, please do needed modifications immediately & get '+2' br, Jani Heikkinen Release Manager _______________________________________________ Development mailing list Development at qt-project.org http://lists.qt-project.org/mailman/listinfo/development From aapo.keskimolo at qt.io Mon Apr 23 14:27:43 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Mon, 23 Apr 2018 12:27:43 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Due to source archive creation failures that effect multiple qt modules, we have had to restart the Coin service multiple times because we are working on a solution. We apologize for the inconvenience. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From philippeb8 at gmail.com Tue Apr 24 03:08:19 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 23 Apr 2018 21:08:19 -0400 Subject: [Development] Fornux C++ Superset Message-ID: Greetings, Because Qt is very powerful, I would like to clarify the importance of the following problems despite my previous informal attempts: - The recent Qt 5.10.1 still randomly crashes for apps written on the iPhone and for the Android as well. - QML is an interpreted language thus it can be reverse engineered and plagiarized quite easily. As you know 1 crash makes your application worthless. Those are facts, whether today's mainstream developers like it or not. I have a solution that solves those problems and it's called: "Fornux C++ Superset": - Fornux C++ Superset harnesses the power of Clang. - It now supports, as you have guessed, C++98 syntax. - It's deterministic so it will not slow down your application randomly like with Java. - You can see attached examples memory leaks in C & C++ with cyclic references which are correctly handled and the memory usage never increases. Like I mentioned previously, I am working hard on a free version I will be able to share in a month or two. Regards, Phil Bouchard www.fornux.com -------------- next part -------------- A non-text attachment was scrubbed... Name: memoryleak.cpp Type: text/x-c++src Size: 1321 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: memoryleak.c Type: text/x-csrc Size: 1336 bytes Desc: not available URL: From thiago.macieira at intel.com Tue Apr 24 03:29:03 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 23 Apr 2018 18:29:03 -0700 Subject: [Development] Fornux C++ Superset In-Reply-To: References: Message-ID: <1675379.mWTH3mOQWM@tjmaciei-mobl1> On Monday, 23 April 2018 18:08:19 PDT Phil Bouchard wrote: > Greetings, > > Because Qt is very powerful, I would like to clarify the importance of > the following problems despite my previous informal attempts: > - The recent Qt 5.10.1 still randomly crashes for apps written on the > iPhone and for the Android as well. Do we have bug reports for those? I doubt the crashes are random, they only appear to be. They are likely very deterministic and most of them are easy to fix, if the issue is in Qt. > - QML is an interpreted language thus it can be reverse engineered and > plagiarized quite easily. There's a QML compiler. > As you know 1 crash makes your application worthless. Those are facts, > whether today's mainstream developers like it or not. Those are not the facts. I've seen Windows, Linux and macOS operating system crashes. Those are hardly worthless. They're worth billions. My apps on my phone crash sometimes too, and yet I still use them. > I have a solution that solves those problems and it's called: "Fornux > C++ Superset": I doubt it. > - Fornux C++ Superset harnesses the power of Clang. Does it mean other compilers are not supported? That's a showstopper. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Tue Apr 24 03:46:05 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 23 Apr 2018 21:46:05 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: <1675379.mWTH3mOQWM@tjmaciei-mobl1> References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> Message-ID: On 04/23/2018 09:29 PM, Thiago Macieira wrote: > On Monday, 23 April 2018 18:08:19 PDT Phil Bouchard wrote: >> Greetings, >> >> Because Qt is very powerful, I would like to clarify the importance of >> the following problems despite my previous informal attempts: >> - The recent Qt 5.10.1 still randomly crashes for apps written on the >> iPhone and for the Android as well. > > Do we have bug reports for those? I doubt the crashes are random, they only > appear to be. They are likely very deterministic and most of them are easy to > fix, if the issue is in Qt. I programmed a Facebook-like interface where I scroll up and down very fast and it ends up crashing. I can try to get a backtrace on the iOS and file a bug report. But that's a head's up. >> - QML is an interpreted language thus it can be reverse engineered and >> plagiarized quite easily. > > There's a QML compiler. Which is great but does it compile the Javascript code as well? >> As you know 1 crash makes your application worthless. Those are facts, >> whether today's mainstream developers like it or not. > > Those are not the facts. I've seen Windows, Linux and macOS operating system > crashes. Those are hardly worthless. They're worth billions. My apps on my > phone crash sometimes too, and yet I still use them. Remember when Wordperfect kept crashing in Windows 3.1 for some strange reason back in the days? People ended up using MS Word. The same with Netscape... >> I have a solution that solves those problems and it's called: "Fornux >> C++ Superset": > > I doubt it. As you know I have tested it with a much more complex software called: "libarchive" and it works flawlessly: https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b >> - Fornux C++ Superset harnesses the power of Clang. > > Does it mean other compilers are not supported? That's a showstopper. No it's just a Clang-based layer that injects complex C++ code into existing C & C++98 projects. You can use any C++11 compiler to compile the resulting code. Regards, -Phil From philippeb8 at gmail.com Tue Apr 24 04:08:09 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 23 Apr 2018 22:08:09 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> Message-ID: On 04/23/2018 09:46 PM, Phil Bouchard wrote: >>> - Fornux C++ Superset harnesses the power of Clang. >> >> Does it mean other compilers are not supported? That's a showstopper. > > No it's just a Clang-based layer that injects complex C++ code into > existing C & C++98 projects. You can use any C++11 compiler to compile > the resulting code. It is what we call: "static program analysis", which is the corporations works nowadays as you know: https://en.wikipedia.org/wiki/Static_program_analysis Here is why: https://hackernoon.com/why-you-should-really-care-about-c-c-static-analysis-db13f4463b2d Regards, -Phil From thiago.macieira at intel.com Tue Apr 24 04:34:37 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 23 Apr 2018 19:34:37 -0700 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> Message-ID: <4388948.g8Bl6hTZpn@tjmaciei-mobl1> On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote: > >> - QML is an interpreted language thus it can be reverse engineered and > >> plagiarized quite easily. > > > > There's a QML compiler. > > Which is great but does it compile the Javascript code as well? Yes, to an extent. > Remember when Wordperfect kept crashing in Windows 3.1 for some strange > reason back in the days? People ended up using MS Word. The same with > Netscape... There are a lot of reasons why people chose MS Word, not just crashes on Wordperfect. Not to mention that Word crashes too. > > >> I have a solution that solves those problems and it's called: "Fornux > > > >> C++ Superset": > > I doubt it. > > As you know I have tested it with a much more complex software called: > "libarchive" and it works flawlessly: > https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7 > d191829d5a9b My point is: I doubt that you have solved all crashes. You have not. Your framework may be a huge improvement over a lot of techniques people use today, but your claims are not believable. You should be more precise in your wording. > >> - Fornux C++ Superset harnesses the power of Clang. > > > > Does it mean other compilers are not supported? That's a showstopper. > > No it's just a Clang-based layer that injects complex C++ code into > existing C & C++98 projects. You can use any C++11 compiler to compile > the resulting code. So I need Clang to parse my code. Will it parse Microsoft headers properly? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Tue Apr 24 07:35:36 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 24 Apr 2018 01:35:36 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: <4388948.g8Bl6hTZpn@tjmaciei-mobl1> References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/23/2018 10:34 PM, Thiago Macieira wrote: > On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote: >>>> - QML is an interpreted language thus it can be reverse engineered and >>>> plagiarized quite easily. >>> >>> There's a QML compiler. >> >> Which is great but does it compile the Javascript code as well? > > Yes, to an extent. Okay but one way or the other it'll always use the garbage collector as a backend. >> Remember when Wordperfect kept crashing in Windows 3.1 for some strange >> reason back in the days? People ended up using MS Word. The same with >> Netscape... > > There are a lot of reasons why people chose MS Word, not just crashes on > Wordperfect. Not to mention that Word crashes too. Well crashes don't help either. >>>> I have a solution that solves those problems and it's called: "Fornux >>> >>>> C++ Superset": >>> I doubt it. >> >> As you know I have tested it with a much more complex software called: >> "libarchive" and it works flawlessly: >> https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7 >> d191829d5a9b > > My point is: I doubt that you have solved all crashes. You have not. Your > framework may be a huge improvement over a lot of techniques people use today, > but your claims are not believable. You should be more precise in your > wording. Here are the different ways to make an application crash: http://forum.codecall.net/topic/71995-understanding-memory-leaks-and-crashes-in-c/ - You are free to modify the provided headers to throw an exception on buffer overflows and the dereferencing of null pointers but I prefer to keep the provided headers free from exceptions to favor speed. - Explicit free() or delete are ignored and handled implicitly by the generated code. - The code that was modified by the parser interacts perfectly well with system headers or external libraries that weren't modified at all. - There are minor rules you need to follow to make the code compile correctly, like nested structures aren't supported, etc. but you'll get the errors at compile-time thus when it runs then it cannot crash. - You are free to write any kernel module, AI engine, etc. without any explicit call to free() and the parser will handle it correctly. >>>> - Fornux C++ Superset harnesses the power of Clang. >>> >>> Does it mean other compilers are not supported? That's a showstopper. >> >> No it's just a Clang-based layer that injects complex C++ code into >> existing C & C++98 projects. You can use any C++11 compiler to compile >> the resulting code. > > So I need Clang to parse my code. Will it parse Microsoft headers properly? The generated code keeps headers that aren't part of your project as include statements so your compiler / cross-compiler will expand these headers normally. Regards, -Phil From bogdan.vatra at kdab.com Tue Apr 24 08:00:08 2018 From: bogdan.vatra at kdab.com (Bogdan Vatra) Date: Tue, 24 Apr 2018 09:00:08 +0300 Subject: [Development] Fornux C++ Superset In-Reply-To: References: Message-ID: <2081767.244KttjBif@zmeu> Hi, În ziua de marți, 24 aprilie 2018, la 04:08:19 EEST, Phil Bouchard a scris: > Greetings, > > Because Qt is very powerful, I would like to clarify the importance of > the following problems despite my previous informal attempts: > - The recent Qt 5.10.1 still randomly crashes for apps written on the > iPhone and for the Android as well. Is there any bug report(s) on this matter? Can you please provide some links(s) to the bug reports and a way to "randomly" reproduce these problems? [...] Cheers, BogDan. From thiago.macieira at intel.com Tue Apr 24 07:51:26 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Mon, 23 Apr 2018 22:51:26 -0700 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: <1855077.HXvTdg7G5T@tjmaciei-mobl1> On Monday, 23 April 2018 22:35:36 PDT Phil Bouchard wrote: > On 04/23/2018 10:34 PM, Thiago Macieira wrote: > > On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote: > >>>> - QML is an interpreted language thus it can be reverse engineered and > >>>> plagiarized quite easily. > >>> > >>> There's a QML compiler. > >> > >> Which is great but does it compile the Javascript code as well? > > > > Yes, to an extent. > > Okay but one way or the other it'll always use the garbage collector as > a backend. Correct. But that has nothing to do with your argument of reverse engineering. > > My point is: I doubt that you have solved all crashes. You have not. Your > > framework may be a huge improvement over a lot of techniques people use > > today, but your claims are not believable. You should be more precise in > > your wording. > > Here are the different ways to make an application crash: > http://forum.codecall.net/topic/71995-understanding-memory-leaks-and-crashes > -in-c/ Dereferencing dangling pointers is not the only way to cause crashes. In fact, depending on when it happens, that usually has no effect. Memory overruns cause way more problems. Your solution won't fix that. Use of uninitialised memory almost always causes immediate crashes. Your solution won't fix that because, by definition, those cause *because* they happened before your solution. There's always more code that you need to interface with, so unless you convert EVERYTHING to a safe language (and you won't), you won't fix all crashes. Crashes also happen because of use of improper instructions. That has nothing to do with memory. > - The code that was modified by the parser interacts perfectly well with > system headers or external libraries that weren't modified at all. Which can crash. > The generated code keeps headers that aren't part of your project as > include statements so your compiler / cross-compiler will expand these > headers normally. I can tell you right now Qt is not interested in switching languages. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From edward.welbourne at qt.io Tue Apr 24 10:01:52 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Tue, 24 Apr 2018 08:01:52 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1>, Message-ID: On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote: >>> Remember when Wordperfect kept crashing in Windows 3.1 for some strange >>> reason back in the days? People ended up using MS Word. The same with >>> Netscape... On 04/23/2018 10:34 PM, Thiago Macieira wrote: >> There are a lot of reasons why people chose MS Word, not just crashes on >> Wordperfect. Not to mention that Word crashes too. Phil Bouchard (24 April 2018 07:35) > Well crashes don't help either. None the less, "1 crash makes your application worthless" grossly exaggerates the severity of a crash. A crash that happens reliably on start-up makes an application useless, to be sure, but I have often learned to not do that one thing that triggers a crash in a piece of software that I routinely find very useful (despite the fact that I have to take care to not do that one thing). Meanwhile, many defects that aren't crashes limit the value of software by significantly more - these needn't even be bugs; simply not doing a thing that I find too useful to do without, even if it's omitted for a Good Reason, is enough to make a piece of software useless - at least in the presence of a competitor which does the thing it doesn't. Speaking of which: > - There are minor rules you need to follow to make the code compile > correctly, like nested structures aren't supported, etc. but you'll get > the errors at compile-time thus when it runs then it cannot crash. That is not a minor rule. That is a show-stoppper. We're not about to give up nested structures ! I think you'll find there are *many* programmers who would sooner have a few sporadic crashes than limit themselves to the programs they can write without nested structures (either in their own code or in any libraries their code is a client of). So the lack of that feature is a prime example of a defect in software that's worse than a crash - your users would sooner inflict sporadic crashes on their users than live without this feature. Furthermore, the vast majority of users would sooner have a program that sporadically crashes, as long as it's tolerably rare, than have one with fewer features because it was written by a programmer who was missing a language feature that would have made it easier to do more with less. The reason why the software industry is a bit slap-dash about bugs is that the market encourages shipping something that works adequately to do something more useful, for the user, than the competition offers: those who ship something useful (but a bit buggy) get large market share before those who ship (less useful but) bug-free software even get their products to market - which, in fact, they seldom do. I know one or two programmers who, when they promise to deliver bug-free software, can actually be trusted to do so (they'll also be charging highly for that; and promising to, in the event of any bug, give back all the money and fix the bug); but most programmers are *not capable* of that, for any non-trivial program, and I doubt any software team of any size can be confident of delivering entirely bug-free software. As it happens, delivering engaging, useful software - that delivers value to its users - tends to take a fairly large team (or take so long that the market has been captured by someone else, who had a large team, before you ship). Eddy. From tony.sarajarvi at qt.io Tue Apr 24 13:24:12 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Tue, 24 Apr 2018 11:24:12 +0000 Subject: [Development] Maintenance in network aprox between the 25th and 27th of April In-Reply-To: References: Message-ID: Hi This is a reminder of the service break we are going to be having the next few days. A brief summary of what's going to change and what they affect: Wednesday: * New switches are being installed * Side by side with the current ones, no interruptions as such * New hosts are being connected to the CI * This increases our capacity in the CI after they get deployed * Our blade chassis hosting our infra is going to be moved * This cuts of everyone from our infra for a minute (This includes our VPN, and some external services like testresults.qt.io) Thursday: * All CI hosts are going down for upgrade * Affects CI in such that our 20 hosts have to be taken out of service one by one * Bringing them back takes ~2h per host * MacMinis are taken down and re-routed * This prevents macOS builds in our Jenkins farm Friday: * MacMinis are brought back online * Troubleshooting In case of questions, contact qt-ci at qt.io With regards, -Tony From: Tony Sarajärvi Sent: perjantai 6. huhtikuuta 2018 9.36 To: 'development at qt-project.org' Subject: Maintenance in network aprox between the 25th and 27th of April Hi We are going to perform maintenance on our switches which will probably cause interruptions in all Qt services not located in AWS. New switches are estimated to arrive so that the work can begin approximately on the 25th. We'll inform you with more precise data as we get it. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Tue Apr 24 15:13:39 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 24 Apr 2018 09:13:39 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: <1855077.HXvTdg7G5T@tjmaciei-mobl1> References: <4388948.g8Bl6hTZpn@tjmaciei-mobl1> <1855077.HXvTdg7G5T@tjmaciei-mobl1> Message-ID: On 04/24/2018 01:51 AM, Thiago Macieira wrote: > On Monday, 23 April 2018 22:35:36 PDT Phil Bouchard wrote: >> On 04/23/2018 10:34 PM, Thiago Macieira wrote: >>> On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote: >>>>>> - QML is an interpreted language thus it can be reverse engineered and >>>>>> plagiarized quite easily. >>>>> >>>>> There's a QML compiler. >>>> >>>> Which is great but does it compile the Javascript code as well? >>> >>> Yes, to an extent. >> >> Okay but one way or the other it'll always use the garbage collector as >> a backend. > > Correct. But that has nothing to do with your argument of reverse engineering. I am extending my arguments because they weren't well articulated. >>> My point is: I doubt that you have solved all crashes. You have not. Your >>> framework may be a huge improvement over a lot of techniques people use >>> today, but your claims are not believable. You should be more precise in >>> your wording. >> >> Here are the different ways to make an application crash: >> http://forum.codecall.net/topic/71995-understanding-memory-leaks-and-crashes >> -in-c/ Here are better summaries: https://www.ibm.com/developerworks/aix/library/au-toughgame/ https://software.intel.com/en-us/inspector-user-guide-windows-problem-type-reference > Dereferencing dangling pointers is not the only way to cause crashes. In fact, > depending on when it happens, that usually has no effect. > > Memory overruns cause way more problems. Your solution won't fix that. I am trying quickly to find the crash statistics and according to the following research: "Memory leaks are one of the primary causes of software aging.": https://www.researchgate.net/publication/319980827_Detection_of_Memory_Leaks_in_CC_Code_via_Machine_Learning > Use of uninitialised memory almost always causes immediate crashes. Your > solution won't fix that because, by definition, those cause *because* they > happened before your solution. There's always more code that you need to > interface with, so unless you convert EVERYTHING to a safe language (and you > won't), you won't fix all crashes. All structures and all atomic types are properly initialized to their default values with the parser... even for C apps. > Crashes also happen because of use of improper instructions. That has nothing > to do with memory. > >> - The code that was modified by the parser interacts perfectly well with >> system headers or external libraries that weren't modified at all. > > Which can crash. There is only 1 std C call that uses malloc() under the hood that is problematic, like strdup(), but it is overwritten by the parser. Other C calls like printf() are properly handled. Again, worse case you will get compilation errors, not run-time errors. >> The generated code keeps headers that aren't part of your project as >> include statements so your compiler / cross-compiler will expand these >> headers normally. > > I can tell you right now Qt is not interested in switching languages. You mean switching Javascript? I already started working in a compiled language to replace Javascript in the past, so perhaps I can resume these efforts. Anyway I have high hopes for Qt as I am using it since January 2000. Regards, -Phil From thiago.macieira at intel.com Tue Apr 24 17:50:40 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 24 Apr 2018 08:50:40 -0700 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1855077.HXvTdg7G5T@tjmaciei-mobl1> Message-ID: <2131519.Qv4pNdoy55@tjmaciei-mobl1> On Tuesday, 24 April 2018 06:13:39 PDT Phil Bouchard wrote: > > I can tell you right now Qt is not interested in switching languages. > > You mean switching Javascript? I already started working in a compiled > language to replace Javascript in the past, so perhaps I can resume > these efforts. > > Anyway I have high hopes for Qt as I am using it since January 2000. I meant C++. We'll continue using C++ and have no intention of changing. Your solution is technically a new language. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From philippeb8 at gmail.com Tue Apr 24 18:54:24 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 24 Apr 2018 16:54:24 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1855077.HXvTdg7G5T@tjmaciei-mobl1> <2131519.Qv4pNdoy55@tjmaciei-mobl1> Message-ID: Thiago Macieira wrote: > On Tuesday, 24 April 2018 06:13:39 PDT Phil Bouchard wrote: >>> I can tell you right now Qt is not interested in switching languages. >> >> You mean switching Javascript? I already started working in a compiled >> language to replace Javascript in the past, so perhaps I can resume >> these efforts. >> >> Anyway I have high hopes for Qt as I am using it since January 2000. > > I meant C++. > > We'll continue using C++ and have no intention of changing. > > Your solution is technically a new language. > It sure is a new language as it adds meta-data in a top-level namespace and solves what the committee is looking for in the long term. I understand the changes required are non-negligible for Qt and that’s unfortunate. But thanks for your time I really appreciate and good luck to Qt! Regards, -Phil From philippeb8 at gmail.com Tue Apr 24 19:05:57 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Tue, 24 Apr 2018 17:05:57 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1>, Message-ID: Edward Welbourne wrote: > On Monday, 23 April 2018 18:46:05 PDT Phil Bouchard wrote: >>>> Remember when Wordperfect kept crashing in Windows 3.1 for some strange >>>> reason back in the days? People ended up using MS Word. The same with >>>> Netscape... > > On 04/23/2018 10:34 PM, Thiago Macieira wrote: >>> There are a lot of reasons why people chose MS Word, not just crashes on >>> Wordperfect. Not to mention that Word crashes too. > > Phil Bouchard (24 April 2018 07:35) >> Well crashes don't help either. > > None the less, "1 crash makes your application worthless" grossly > exaggerates the severity of a crash. A crash that happens reliably on > start-up makes an application useless, to be sure, but I have often > learned to not do that one thing that triggers a crash in a piece of > software that I routinely find very useful (despite the fact that I have > to take care to not do that one thing). Meanwhile, many defects that > aren't crashes limit the value of software by significantly more - these > needn't even be bugs; simply not doing a thing that I find too useful to > do without, even if it's omitted for a Good Reason, is enough to make a > piece of software useless - at least in the presence of a competitor > which does the thing it doesn't. Speaking of which: > >> - There are minor rules you need to follow to make the code compile >> correctly, like nested structures aren't supported, etc. but you'll get >> the errors at compile-time thus when it runs then it cannot crash. > > That is not a minor rule. > That is a show-stoppper. > We're not about to give up nested structures ! > > I think you'll find there are *many* programmers who would sooner have a > few sporadic crashes than limit themselves to the programs they can > write without nested structures (either in their own code or in any > libraries their code is a client of). So the lack of that feature is a > prime example of a defect in software that's worse than a crash - your > users would sooner inflict sporadic crashes on their users than live > without this feature. Furthermore, the vast majority of users would > sooner have a program that sporadically crashes, as long as it's > tolerably rare, than have one with fewer features because it was written > by a programmer who was missing a language feature that would have made > it easier to do more with less. > > The reason why the software industry is a bit slap-dash about bugs is > that the market encourages shipping something that works adequately to > do something more useful, for the user, than the competition offers: > those who ship something useful (but a bit buggy) get large market share > before those who ship (less useful but) bug-free software even get their > products to market - which, in fact, they seldom do. I know one or two > programmers who, when they promise to deliver bug-free software, can > actually be trusted to do so (they'll also be charging highly for that; > and promising to, in the event of any bug, give back all the money and > fix the bug); but most programmers are *not capable* of that, for any > non-trivial program, and I doubt any software team of any size can be > confident of delivering entirely bug-free software. As it happens, > delivering engaging, useful software - that delivers value to its users > - tends to take a fairly large team (or take so long that the market has > been captured by someone else, who had a large team, before you ship). > > Eddy. > I’m not sure if you read the link I posted about static analysis but a software bug can cause billion dollar projects like space shuttles to fail. Maybe MS Word was a bad example but they can be very costly. Also it is possible for me to support nested structures by prefixing class names so that their meta-data fits into the top-level namespace but for the moment they’re not. But those are personal preferences like not using underscores in function names, etc. From d3faultdotxbe at gmail.com Wed Apr 25 03:41:55 2018 From: d3faultdotxbe at gmail.com (d3fault) Date: Tue, 24 Apr 2018 18:41:55 -0700 Subject: [Development] Why waste energy supporting Python? Message-ID: Supporting Python first class dilutes Qt, please don't. What's next, Qt for Java? It's one thing to collect community-developed bindings for various other languages into a single place... but something else entirely to pay an entire "team" of developers to work on what is essentially duplicated effort. That money could instead be spent on new Qt features and/or fixing the ever growing list of bugs (supporting Python first class will only add to that list of bugs). Also, will Python/Qt libs be easily usable from Qt/C++? I doubt it, at least not without deploying a python interpreter (and we already have to deploy a JavaScript interpreter if we want to use QtQuick). Modern C++ has come leaps and bounds over recent years in improving code simplicity and safety (clang-tidy QtCreator integration FTW)... whereas afaik Python still crashes if you don't have your WHITESPACE perfectly organized.... bleh. Simply put, encouraging the use of Python is the same thing as discouraging the use of Modern, Simple, and Safe C++. d3fault From jani.heikkinen at qt.io Wed Apr 25 06:29:25 2018 From: jani.heikkinen at qt.io (Jani Heikkinen) Date: Wed, 25 Apr 2018 04:29:25 +0000 Subject: [Development] MAINTAINERS, your actions needed: Qt 5.11.0 changes files In-Reply-To: References: , Message-ID: Hi all, Still quite many changes file without '+2' (see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.11.0%22,n,z) * qt/qtserialport * qt/qtdoc * qt/qtbase * qt/qtlocation * qt/qtscxml * qt/qttools * qt/qtremoteobjects * qt/qtwebengine * qt/qtsensors * qt/qtvirtualkeyboard * qt/qtwinextras * qt/qtwebsockets * qt/qtwebchannel * qt/qtgamepad * qt/qtdeclarative * qt/qt3d Please make sure these ones will be finalized and approved today; we need to get these in now br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Monday, April 23, 2018 2:52 PM To: development at qt-project.org Subject: [Development] MAINTAINERS, your actions needed: Qt 5.11.0 changes files Hi! Just a kindly reminder: We don't want to delay RC because of these so please make sure these changes files will be checked & modified now. We will put those in as it is Wed 25.4.2018 EOB if there isn't clear message in the change ('-1') that it isn't ready yet br, Jani ________________________________________ From: Development on behalf of Jani Heikkinen Sent: Friday, April 20, 2018 3:22 PM To: development at qt-project.org Subject: [Development] Qt 5.11.0 changes files Hi all, initial ones available, see https://codereview.qt-project.org/#/q/message:%22Add+changes+file+for+Qt+5.11.0%22,n,z Maintainers, please do needed modifications immediately & get '+2' br, Jani Heikkinen Release Manager _______________________________________________ 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 trr at cadence.com Wed Apr 25 07:37:33 2018 From: trr at cadence.com (Thiago Radicchi Roque) Date: Wed, 25 Apr 2018 05:37:33 +0000 Subject: [Development] Qt bug (crash on drag-n-drop on QPlainTextEdit) Message-ID: <91D41F71-8347-4D9F-A6AB-6239BF805465@cadence.com> Hi, Recently I ran into a crash while doing drag-n-drop on some application that uses QPlainTextEdit from Qt 4.6.3. The crash happens when the text being dropped is large, causing the QPlainTextEdit to have a vertical scroll bar. I was able to fix it with the following patch: diff -r 15465e31ff34 -r f8e5f70a5f95 src/gui/widgets/qplaintextedit.cpp --- a/src/gui/widgets/qplaintextedit.cpp Thu Apr 12 14:41:58 2018 -0700 +++ b/src/gui/widgets/qplaintextedit.cpp Mon Apr 23 16:21:28 2018 +0530 @@ -673,7 +673,8 @@ return; QRectF lr = br; QTextLine line = block.layout()->lineForTextPosition(position - block.position()); - Q_ASSERT(line.isValid()); + if (!line.isValid()) + return; lr = line.naturalTextRect().translated(br.topLeft()); if (lr.bottom() >= visible.bottom() || (center && lr.top() < visible.top()) || forceCenter){ Apparently this has been reported before here https://bugreports.qt.io/browse/QTBUG-30018 , and fixed only in the Qt Creator. I didn’t run into the Q_ASSERT because I didn’t try it with a debug version of Qt. Questions: 1. Is this the right way to fix the problem? 2. Is it fixed in Qt5? I don’t think so, but I am not sure. 3. If this is the right fix, can someone please submit it on my behalf? Regards, Thiago -------------- next part -------------- An HTML attachment was scrubbed... URL: From chgans at gmail.com Wed Apr 25 08:19:51 2018 From: chgans at gmail.com (Christian Gagneraud) Date: Wed, 25 Apr 2018 18:19:51 +1200 Subject: [Development] Why waste energy supporting Python? In-Reply-To: References: Message-ID: On 25 April 2018 at 13:41, d3fault wrote: > Supporting Python first class dilutes Qt, please don't. What's next, > Qt for Java? It's one thing to collect community-developed bindings > for various other languages into a single place... but something else > entirely to pay an entire "team" of developers to work on what is > essentially duplicated effort. That money could instead be spent on > new Qt features and/or fixing the ever growing list of bugs > (supporting Python first class will only add to that list of bugs). > Also, will Python/Qt libs be easily usable from Qt/C++? I doubt it, at Maybe it's not the goal. > least not without deploying a python interpreter (and we already have > to deploy a JavaScript interpreter if we want to use QtQuick). > > Modern C++ has come leaps and bounds over recent years in improving > code simplicity and safety (clang-tidy QtCreator integration FTW)... > whereas afaik Python still crashes if you don't have your WHITESPACE > perfectly organized.... bleh. Simply put, encouraging the use of It doesn't crash, it errors out with an Exception that tell you what is wrong. Messing with white space in python is like messing with curly braces in C++. When you think about it, C++ for human is really stupid: - The machine language dictates you to match your curly braces, - and the human brain dictates you to keep your white spaces (visual indentation). Python has merged the 2 concepts into one. You should try. > Python is the same thing as discouraging the use of Modern, Simple, > and Safe C++. Keep safe man, and sweet dreams... Chris > > d3fault > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Wed Apr 25 08:22:09 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Tue, 24 Apr 2018 23:22:09 -0700 Subject: [Development] Qt bug (crash on drag-n-drop on QPlainTextEdit) In-Reply-To: <91D41F71-8347-4D9F-A6AB-6239BF805465@cadence.com> References: <91D41F71-8347-4D9F-A6AB-6239BF805465@cadence.com> Message-ID: <5509256.SLojV8XoC7@tjmaciei-mobl1> On Tuesday, 24 April 2018 22:37:33 PDT Thiago Radicchi Roque wrote: > 1. Is this the right way to fix the problem? From a quick look at the code, no. The construction is basically: QTextBlock block = control->document()->findBlock(position); if (!block.isValid()) return; [...] QTextLine line = block.layout()->lineForTextPosition(position - block.position()); lineForTextPosition() can only return invalid if the position passed is not in the block in question. But findBlock() returned this block for that position, so that position should be in this block. That means the problem is elsewhere. There's something else at work here. > 2. Is it fixed in Qt5? I don’t think so, but I am not sure. You have to test. The code above is pasted from Qt 5.11, but since the problem is unlikely to be in this piece of code, I can't tell from looking at the code if the problem is still there. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center From denis.shienkov at gmail.com Wed Apr 25 09:37:27 2018 From: denis.shienkov at gmail.com (Denis Shienkov) Date: Wed, 25 Apr 2018 10:37:27 +0300 Subject: [Development] Free VPN server required Message-ID: Hi guys, Is it possible to pick-up a free VPN server on your side (on Qt-company side) and give for some maintainers the login/password (e.g. for me)? Because reason is that (ours russian goverment) blockes the some other resources. The Qt resources fall into this by accident, and then it is not possible to contribute to Qt at all (the git && qt doc and other Qt's resources are blocked). ((( BR, Denis -------------- next part -------------- An HTML attachment was scrubbed... URL: From tantrido at ya.ru Wed Apr 25 10:02:07 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Wed, 25 Apr 2018 11:02:07 +0300 Subject: [Development] Free VPN server required In-Reply-To: References: Message-ID: <498451524643327@web60j.yandex.ru> An HTML attachment was scrubbed... URL: From edward.welbourne at qt.io Wed Apr 25 10:46:42 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 25 Apr 2018 08:46:42 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1>, , Message-ID: Phil Bouchard (24 April 2018 19:05) > I’m not sure if you read the link I posted about static analysis but a > software bug can cause billion dollar projects like space shuttles to fail. > Maybe MS Word was a bad example but they can be very costly. The Columbia crash wasn't a (computer) software issue. One can think of the organisational failure that lead to it as a (human) software issue, but I don't think we have static analysis software for that. The closest you'll get is an ISO 9000 compliance auditor. The Ariane 5 crash was a software error, but it wasn't a memory abuse; it was using an under-sized integer to hold a value that overflowed. With luck, static analysis would find that, but it's a pointer abuse. The loss of the Mars Climate Orbiter involved a software bug, but it was a wrong choice of units rather than a pointer abuse. Mixing archaic silly units with sensible SI ones has caused more grief for space missions than pointer abuses. So bugs can have disastrous consequences, sure; but fixing all pointer abuses won't stop that from being the case. Meanwhile, in the world of most programmers, most bugs are more or less endurable and most users would sooner have something that ships today with a few endurable bugs than not have the software that helps them do whatever it is they do until someone is sure there are no bugs in it. Buts aren't the only thing that can cause a software project to fail. > Also it is possible for me to support nested structures by prefixing class > names so that their meta-data fits into the top-level namespace but for the > moment they’re not. But those are personal preferences like not using > underscores in function names, etc. Well, if you can support nested structures, you might have a better chance of persuading folk to port to your new language; but those with large code-bases aren't about to re-write them to eliminate nested structures just because you regard that choice as a personal preference. I note that Qt has plenty of nested structures. I'm not volunteering to refactor them away. Eddy. From kevin.kofler at chello.at Wed Apr 25 12:29:21 2018 From: kevin.kofler at chello.at (Kevin Kofler) Date: Wed, 25 Apr 2018 12:29:21 +0200 Subject: [Development] Why waste energy supporting Python? References: Message-ID: d3fault wrote: > Supporting Python first class dilutes Qt, please don't. What's next, > Qt for Java? https://en.wikipedia.org/wiki/Qt_Jambi :-) Kevin Kofler From edward.welbourne at qt.io Wed Apr 25 13:40:41 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 25 Apr 2018 11:40:41 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_M=E5rten_Nordheim_as_an_a?= =?iso-8859-1?q?pprover?= Message-ID: Hi all, I'd like to nominate Mårten Nordheim for Approver. We've had him here at TQtC, in the Core & Network team, for a bit over a year; he's been reviewing steadily and finding mistakes I miss. As well as diverse work in qtbase, he's also dabbled in the qtnetworkauth and qtwebsockets modules. Here's his list of changes in gerrit: https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z and the (somewhat busier) list of what he's reviewed: https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z Eddy. From philippeb8 at gmail.com Wed Apr 25 14:02:54 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 25 Apr 2018 08:02:54 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/25/2018 04:46 AM, Edward Welbourne wrote: > Phil Bouchard (24 April 2018 19:05) >> I’m not sure if you read the link I posted about static analysis but a >> software bug can cause billion dollar projects like space shuttles to fail. >> Maybe MS Word was a bad example but they can be very costly. > > The Columbia crash wasn't a (computer) software issue. One can think of > the organisational failure that lead to it as a (human) software issue, > but I don't think we have static analysis software for that. The > closest you'll get is an ISO 9000 compliance auditor. > > The Ariane 5 crash was a software error, but it wasn't a memory abuse; > it was using an under-sized integer to hold a value that overflowed. > With luck, static analysis would find that, but it's a pointer abuse. > > The loss of the Mars Climate Orbiter involved a software bug, but it was > a wrong choice of units rather than a pointer abuse. Mixing archaic > silly units with sensible SI ones has caused more grief for space > missions than pointer abuses. You need to see the big picture; memory leaks are the most difficult problems to solve. In the labs you stress-test your software for a few days but in real life your software is going to run for a few months consecutively. I was working for a WebKit-based browser for TVs for a software company and the browser kept crashing after a day of usage because of memory leaks. I mean how are you supposed to watch TV if you need to reboot the set-top box every day at a random time? Also do you really want to spend time running Valgrind on iPhones or Androids to find these problems? First Valgrind won't fix the problem, second it is not giving always the same answer and third it doesn't run on all embedded devices. There is more you can read about the subject here: "Real Production Issue - Hard to find memory leaks" https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh And BTW: "Garbage collection is out the window, because you cannot know when it is going to happen or how long it will take, which leads to stuttering frame rates." https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games > So bugs can have disastrous consequences, sure; but fixing all pointer > abuses won't stop that from being the case. Meanwhile, in the world of > most programmers, most bugs are more or less endurable and most users > would sooner have something that ships today with a few endurable bugs > than not have the software that helps them do whatever it is they do > until someone is sure there are no bugs in it. Buts aren't the only > thing that can cause a software project to fail. > >> Also it is possible for me to support nested structures by prefixing class >> names so that their meta-data fits into the top-level namespace but for the >> moment they’re not. But those are personal preferences like not using >> underscores in function names, etc. > > Well, if you can support nested structures, you might have a better > chance of persuading folk to port to your new language; but those with > large code-bases aren't about to re-write them to eliminate nested > structures just because you regard that choice as a personal preference. > I note that Qt has plenty of nested structures. > I'm not volunteering to refactor them away. Support for nested structures is easy to fix and will just take a day or two to do so. For example: struct A { struct B { }; }; Will be converted into the following so that I can have their specialization in a top-level namespace: struct A__B { }; struct A { }; Since there is no hidden catch then I will tell you right now that: - NULL C pointers will need to be typed - pointer casts to their encompassing structure needs to use _containerof() macro - C-style array parameters needs to be converted to pointers - Types instantiated in the same statement need not be different (Ex.: int * i, j[4]; // needs to be 2 different statements) That's about it. It took me 1 week to adapt "libarchive" to follow the aforementioned rules: https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b Regards, -Phil From viktor.engelmann at qt.io Wed Apr 25 14:08:36 2018 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Wed, 25 Apr 2018 14:08:36 +0200 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 25.04.2018 14:02, Phil Bouchard wrote: > You need to see the big picture; memory leaks are the most difficult > problems to solve. You have clearly never solved a cycle-lock. -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com From timur.pocheptsov at qt.io Wed Apr 25 14:09:22 2018 From: timur.pocheptsov at qt.io (Timur Pocheptsov) Date: Wed, 25 Apr 2018 12:09:22 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_M=E5rten_Nordheim_as_an_?= =?iso-8859-1?q?approver?= In-Reply-To: References: Message-ID: + 1 from me, fully agree with every statement Edward made. Best regards, Timur. ________________________________ From: Development on behalf of Edward Welbourne Sent: Wednesday, April 25, 2018 1:40:41 PM To: development at qt-project.org Subject: [Development] Nominating Mårten Nordheim as an approver Hi all, I'd like to nominate Mårten Nordheim for Approver. We've had him here at TQtC, in the Core & Network team, for a bit over a year; he's been reviewing steadily and finding mistakes I miss. As well as diverse work in qtbase, he's also dabbled in the qtnetworkauth and qtwebsockets modules. Here's his list of changes in gerrit: https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z and the (somewhat busier) list of what he's reviewed: https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z Eddy. _______________________________________________ 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 Gatis.Paeglis at qt.io Wed Apr 25 14:12:17 2018 From: Gatis.Paeglis at qt.io (Gatis Paeglis) Date: Wed, 25 Apr 2018 12:12:17 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_M=E5rten_Nordheim_as_an_?= =?iso-8859-1?q?approver?= In-Reply-To: References: , Message-ID: +1 from me too. ________________________________ From: Development on behalf of Timur Pocheptsov Sent: Wednesday, April 25, 2018 2:09:22 PM To: Edward Welbourne; development at qt-project.org Subject: Re: [Development] Nominating Mårten Nordheim as an approver + 1 from me, fully agree with every statement Edward made. Best regards, Timur. ________________________________ From: Development on behalf of Edward Welbourne Sent: Wednesday, April 25, 2018 1:40:41 PM To: development at qt-project.org Subject: [Development] Nominating Mårten Nordheim as an approver Hi all, I'd like to nominate Mårten Nordheim for Approver. We've had him here at TQtC, in the Core & Network team, for a bit over a year; he's been reviewing steadily and finding mistakes I miss. As well as diverse work in qtbase, he's also dabbled in the qtnetworkauth and qtwebsockets modules. Here's his list of changes in gerrit: https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z and the (somewhat busier) list of what he's reviewed: https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z Eddy. _______________________________________________ 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 eric.lemanissier at gmail.com Wed Apr 25 14:17:42 2018 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Wed, 25 Apr 2018 12:17:42 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: Le mer. 25 avr. 2018 à 14:03, Phil Bouchard a écrit : > On 04/25/2018 04:46 AM, Edward Welbourne wrote: > > Phil Bouchard (24 April 2018 19:05) > >> I’m not sure if you read the link I posted about static analysis but a > >> software bug can cause billion dollar projects like space shuttles to > fail. > >> Maybe MS Word was a bad example but they can be very costly. > > > > The Columbia crash wasn't a (computer) software issue. One can think of > > the organisational failure that lead to it as a (human) software issue, > > but I don't think we have static analysis software for that. The > > closest you'll get is an ISO 9000 compliance auditor. > > > > The Ariane 5 crash was a software error, but it wasn't a memory abuse; > > it was using an under-sized integer to hold a value that overflowed. > > With luck, static analysis would find that, but it's a pointer abuse. > > > > The loss of the Mars Climate Orbiter involved a software bug, but it was > > a wrong choice of units rather than a pointer abuse. Mixing archaic > > silly units with sensible SI ones has caused more grief for space > > missions than pointer abuses. > > You need to see the big picture; memory leaks are the most difficult > problems to solve. In the labs you stress-test your software for a few > days but in real life your software is going to run for a few months > consecutively. > > I was working for a WebKit-based browser for TVs for a software company > and the browser kept crashing after a day of usage because of memory > leaks. I mean how are you supposed to watch TV if you need to reboot the > set-top box every day at a random time? > > Also do you really want to spend time running Valgrind on iPhones or > Androids to find these problems? First Valgrind won't fix the problem, > second it is not giving always the same answer and third it doesn't run > on all embedded devices. > > There is more you can read about the subject here: > > "Real Production Issue - Hard to find memory leaks" > https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh > > And BTW: > > "Garbage collection is out the window, because you cannot know when it > is going to happen or how long it will take, which leads to stuttering > frame rates." > > https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games > > > So bugs can have disastrous consequences, sure; but fixing all pointer > > abuses won't stop that from being the case. Meanwhile, in the world of > > most programmers, most bugs are more or less endurable and most users > > would sooner have something that ships today with a few endurable bugs > > than not have the software that helps them do whatever it is they do > > until someone is sure there are no bugs in it. Buts aren't the only > > thing that can cause a software project to fail. > > > >> Also it is possible for me to support nested structures by prefixing > class > >> names so that their meta-data fits into the top-level namespace but for > the > >> moment they’re not. But those are personal preferences like not using > >> underscores in function names, etc. > > > > Well, if you can support nested structures, you might have a better > > chance of persuading folk to port to your new language; but those with > > large code-bases aren't about to re-write them to eliminate nested > > structures just because you regard that choice as a personal preference. > > I note that Qt has plenty of nested structures. > > I'm not volunteering to refactor them away. > > Support for nested structures is easy to fix and will just take a day or > two to do so. For example: > > struct A > { > struct B > { > }; > }; > > Will be converted into the following so that I can have their > specialization in a top-level namespace: > > struct A__B > { > }; > > struct A > { > }; > > This would break existing code, as name lookup from nested class should visit first enclosing class before visiting namespace. Also, the nested class must have access to all names (private, protected, etc) to which the enclosing class has access ( http://en.cppreference.com/w/cpp/language/nested_types) Since there is no hidden catch then I will tell you right now that: > - NULL C pointers will need to be typed > - pointer casts to their encompassing structure needs to use > _containerof() macro > - C-style array parameters needs to be converted to pointers > What for ? you loose the size information by doing so. > - Types instantiated in the same statement need not be different (Ex.: > int * i, j[4]; // needs to be 2 different statements) > > That's about it. It took me 1 week to adapt "libarchive" to follow the > aforementioned rules: > > https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b > > > Regards, > -Phil > > _______________________________________________ > 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 philippeb8 at gmail.com Wed Apr 25 14:20:39 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 25 Apr 2018 08:20:39 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/25/2018 08:17 AM, Eric Lemanisser wrote: > > Support for nested structures is easy to fix and will just take a > day or > two to do so. For example: > > struct A > { >    struct B >    { >    }; > }; > > Will be converted into the following so that I can have their > specialization in a top-level namespace: > > struct A__B > { > }; > > struct A > { > }; > > > This would break existing code, as name lookup from nested class should > visit first enclosing class before visiting namespace. Also, the nested > class must have access to all names (private, protected, etc) to which > the enclosing class has access > (http://en.cppreference.com/w/cpp/language/nested_types) I forgot to mention that these rewritten structures are used to hold meta-data only, used internally. Regards, -Phil From philwave at gmail.com Wed Apr 25 14:28:19 2018 From: philwave at gmail.com (Philippe) Date: Wed, 25 Apr 2018 14:28:19 +0200 Subject: [Development] Fornux C++ Superset In-Reply-To: References: Message-ID: <20180425142818.F0D0.6F0322A@gmail.com> >> memory leaks are the most difficult problems to solve Really NOT ! Philippe On Wed, 25 Apr 2018 08:02:54 -0400 Phil Bouchard wrote: > On 04/25/2018 04:46 AM, Edward Welbourne wrote: > > Phil Bouchard (24 April 2018 19:05) > >> I’m not sure if you read the link I posted about static analysis but a > >> software bug can cause billion dollar projects like space shuttles to fail. > >> Maybe MS Word was a bad example but they can be very costly. > > > > The Columbia crash wasn't a (computer) software issue. One can think of > > the organisational failure that lead to it as a (human) software issue, > > but I don't think we have static analysis software for that. The > > closest you'll get is an ISO 9000 compliance auditor. > > > > The Ariane 5 crash was a software error, but it wasn't a memory abuse; > > it was using an under-sized integer to hold a value that overflowed. > > With luck, static analysis would find that, but it's a pointer abuse. > > > > The loss of the Mars Climate Orbiter involved a software bug, but it was > > a wrong choice of units rather than a pointer abuse. Mixing archaic > > silly units with sensible SI ones has caused more grief for space > > missions than pointer abuses. > > You need to see the big picture; memory leaks are the most difficult problems to solve. In the labs you stress-test your software for a few days but in real life your software is going to run for a few months consecutively. > > I was working for a WebKit-based browser for TVs for a software company and the browser kept crashing after a day of usage because of memory leaks. I mean how are you supposed to watch TV if you need to reboot the set-top box every day at a random time? > > Also do you really want to spend time running Valgrind on iPhones or Androids to find these problems? First Valgrind won't fix the problem, second it is not giving always the same answer and third it doesn't run on all embedded devices. > > There is more you can read about the subject here: > > "Real Production Issue - Hard to find memory leaks" > https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh > > And BTW: > > "Garbage collection is out the window, because you cannot know when it is going to happen or how long it will take, which leads to stuttering frame rates." > https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games > > > So bugs can have disastrous consequences, sure; but fixing all pointer > > abuses won't stop that from being the case. Meanwhile, in the world of > > most programmers, most bugs are more or less endurable and most users > > would sooner have something that ships today with a few endurable bugs > > than not have the software that helps them do whatever it is they do > > until someone is sure there are no bugs in it. Buts aren't the only > > thing that can cause a software project to fail. > > > >> Also it is possible for me to support nested structures by prefixing class > >> names so that their meta-data fits into the top-level namespace but for the > >> moment they’re not. But those are personal preferences like not using > >> underscores in function names, etc. > > > > Well, if you can support nested structures, you might have a better > > chance of persuading folk to port to your new language; but those with > > large code-bases aren't about to re-write them to eliminate nested > > structures just because you regard that choice as a personal preference. > > I note that Qt has plenty of nested structures. > > I'm not volunteering to refactor them away. > > Support for nested structures is easy to fix and will just take a day or two to do so. For example: > > struct A > { > struct B > { > }; > }; > > Will be converted into the following so that I can have their specialization in a top-level namespace: > > struct A__B > { > }; > > struct A > { > }; > > Since there is no hidden catch then I will tell you right now that: > - NULL C pointers will need to be typed > - pointer casts to their encompassing structure needs to use _containerof() macro > - C-style array parameters needs to be converted to pointers > - Types instantiated in the same statement need not be different (Ex.: int * i, j[4]; // needs to be 2 different statements) > > That's about it. It took me 1 week to adapt "libarchive" to follow the aforementioned rules: > https://github.com/philippeb8/libarchive/commit/5858b5c047301123ffdf05f247f7d191829d5a9b > > > Regards, > -Phil > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From philippeb8 at gmail.com Wed Apr 25 14:56:21 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 25 Apr 2018 12:56:21 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: Eric Lemanisser wrote: > Le mer. 25 avr. 2018 à 14:03, Phil Bouchard a écrit : > >> On 04/25/2018 04:46 AM, Edward Welbourne wrote: >>> Phil Bouchard (24 April 2018 19:05) >>>> I’m not sure if you read the link I posted about static analysis but a >>>> software bug can cause billion dollar projects like space shuttles to >> fail. >>>> Maybe MS Word was a bad example but they can be very costly. >>> >>> The Columbia crash wasn't a (computer) software issue. One can think of >>> the organisational failure that lead to it as a (human) software issue, >>> but I don't think we have static analysis software for that. The >>> closest you'll get is an ISO 9000 compliance auditor. >>> >>> The Ariane 5 crash was a software error, but it wasn't a memory abuse; >>> it was using an under-sized integer to hold a value that overflowed. >>> With luck, static analysis would find that, but it's a pointer abuse. >>> >>> The loss of the Mars Climate Orbiter involved a software bug, but it was >>> a wrong choice of units rather than a pointer abuse. Mixing archaic >>> silly units with sensible SI ones has caused more grief for space >>> missions than pointer abuses. >> >> You need to see the big picture; memory leaks are the most difficult >> problems to solve. In the labs you stress-test your software for a few >> days but in real life your software is going to run for a few months >> consecutively. >> >> I was working for a WebKit-based browser for TVs for a software company >> and the browser kept crashing after a day of usage because of memory >> leaks. I mean how are you supposed to watch TV if you need to reboot the >> set-top box every day at a random time? >> >> Also do you really want to spend time running Valgrind on iPhones or >> Androids to find these problems? First Valgrind won't fix the problem, >> second it is not giving always the same answer and third it doesn't run >> on all embedded devices. >> >> There is more you can read about the subject here: >> >> "Real Production Issue - Hard to find memory leaks" >> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh >> >> And BTW: >> >> "Garbage collection is out the window, because you cannot know when it >> is going to happen or how long it will take, which leads to stuttering >> frame rates." >> >> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games >> >>> So bugs can have disastrous consequences, sure; but fixing all pointer >>> abuses won't stop that from being the case. Meanwhile, in the world of >>> most programmers, most bugs are more or less endurable and most users >>> would sooner have something that ships today with a few endurable bugs >>> than not have the software that helps them do whatever it is they do >>> until someone is sure there are no bugs in it. Buts aren't the only >>> thing that can cause a software project to fail. >>> >>>> Also it is possible for me to support nested structures by prefixing >> class >>>> names so that their meta-data fits into the top-level namespace but for >> the >>>> moment they’re not. But those are personal preferences like not using >>>> underscores in function names, etc. >>> >>> Well, if you can support nested structures, you might have a better >>> chance of persuading folk to port to your new language; but those with >>> large code-bases aren't about to re-write them to eliminate nested >>> structures just because you regard that choice as a personal preference. >>> I note that Qt has plenty of nested structures. >>> I'm not volunteering to refactor them away. >> >> Support for nested structures is easy to fix and will just take a day or >> two to do so. For example: >> >> struct A >> { >> struct B >> { >> }; >> }; >> >> Will be converted into the following so that I can have their >> specialization in a top-level namespace: >> >> struct A__B >> { >> }; >> >> struct A >> { >> }; >> >> > This would break existing code, as name lookup from nested class should > visit first enclosing class before visiting namespace. Also, the nested > class must have access to all names (private, protected, etc) to which the > enclosing class has access ( > http://en.cppreference.com/w/cpp/language/nested_types) > > Since there is no hidden catch then I will tell you right now that: >> - NULL C pointers will need to be typed >> - pointer casts to their encompassing structure needs to use >> _containerof() macro >> - C-style array parameters needs to be converted to pointers >> > What for ? you loose the size information by doing so. No: void foo(int array[]) {...} void foo(int * array) {...} Are the same thing. Regards, -Phil From eric.lemanissier at gmail.com Wed Apr 25 15:45:41 2018 From: eric.lemanissier at gmail.com (Eric Lemanisser) Date: Wed, 25 Apr 2018 13:45:41 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: What about void foo(int (&array)[3]) and template void foo(int (&array)[N]) ? Both of these functions make sure the caller and the callee use the same array size at compile time. I don't see anybody giving away this kind of security, especially fro functions called across translation units. Does your system store the length of the array next to the pointer at runtime ? What is the cost of this ? Le mer. 25 avr. 2018 à 14:58, Phil Bouchard a écrit : > Eric Lemanisser wrote: > > Le mer. 25 avr. 2018 à 14:03, Phil Bouchard a > écrit : > > > >> On 04/25/2018 04:46 AM, Edward Welbourne wrote: > >>> Phil Bouchard (24 April 2018 19:05) > >>>> I’m not sure if you read the link I posted about static analysis but a > >>>> software bug can cause billion dollar projects like space shuttles to > >> fail. > >>>> Maybe MS Word was a bad example but they can be very costly. > >>> > >>> The Columbia crash wasn't a (computer) software issue. One can think > of > >>> the organisational failure that lead to it as a (human) software issue, > >>> but I don't think we have static analysis software for that. The > >>> closest you'll get is an ISO 9000 compliance auditor. > >>> > >>> The Ariane 5 crash was a software error, but it wasn't a memory abuse; > >>> it was using an under-sized integer to hold a value that overflowed. > >>> With luck, static analysis would find that, but it's a pointer abuse. > >>> > >>> The loss of the Mars Climate Orbiter involved a software bug, but it > was > >>> a wrong choice of units rather than a pointer abuse. Mixing archaic > >>> silly units with sensible SI ones has caused more grief for space > >>> missions than pointer abuses. > >> > >> You need to see the big picture; memory leaks are the most difficult > >> problems to solve. In the labs you stress-test your software for a few > >> days but in real life your software is going to run for a few months > >> consecutively. > >> > >> I was working for a WebKit-based browser for TVs for a software company > >> and the browser kept crashing after a day of usage because of memory > >> leaks. I mean how are you supposed to watch TV if you need to reboot the > >> set-top box every day at a random time? > >> > >> Also do you really want to spend time running Valgrind on iPhones or > >> Androids to find these problems? First Valgrind won't fix the problem, > >> second it is not giving always the same answer and third it doesn't run > >> on all embedded devices. > >> > >> There is more you can read about the subject here: > >> > >> "Real Production Issue - Hard to find memory leaks" > >> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh > >> > >> And BTW: > >> > >> "Garbage collection is out the window, because you cannot know when it > >> is going to happen or how long it will take, which leads to stuttering > >> frame rates." > >> > >> > https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games > >> > >>> So bugs can have disastrous consequences, sure; but fixing all pointer > >>> abuses won't stop that from being the case. Meanwhile, in the world of > >>> most programmers, most bugs are more or less endurable and most users > >>> would sooner have something that ships today with a few endurable bugs > >>> than not have the software that helps them do whatever it is they do > >>> until someone is sure there are no bugs in it. Buts aren't the only > >>> thing that can cause a software project to fail. > >>> > >>>> Also it is possible for me to support nested structures by prefixing > >> class > >>>> names so that their meta-data fits into the top-level namespace but > for > >> the > >>>> moment they’re not. But those are personal preferences like not using > >>>> underscores in function names, etc. > >>> > >>> Well, if you can support nested structures, you might have a better > >>> chance of persuading folk to port to your new language; but those with > >>> large code-bases aren't about to re-write them to eliminate nested > >>> structures just because you regard that choice as a personal > preference. > >>> I note that Qt has plenty of nested structures. > >>> I'm not volunteering to refactor them away. > >> > >> Support for nested structures is easy to fix and will just take a day or > >> two to do so. For example: > >> > >> struct A > >> { > >> struct B > >> { > >> }; > >> }; > >> > >> Will be converted into the following so that I can have their > >> specialization in a top-level namespace: > >> > >> struct A__B > >> { > >> }; > >> > >> struct A > >> { > >> }; > >> > >> > > This would break existing code, as name lookup from nested class should > > visit first enclosing class before visiting namespace. Also, the nested > > class must have access to all names (private, protected, etc) to which > the > > enclosing class has access ( > > http://en.cppreference.com/w/cpp/language/nested_types) > > > > Since there is no hidden catch then I will tell you right now that: > >> - NULL C pointers will need to be typed > >> - pointer casts to their encompassing structure needs to use > >> _containerof() macro > >> - C-style array parameters needs to be converted to pointers > >> > > What for ? you loose the size information by doing so. > > No: > > void foo(int array[]) > {...} > > void foo(int * array) > {...} > > Are the same thing. > > > Regards, > -Phil > > _______________________________________________ > 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 annulen at yandex.ru Wed Apr 25 15:48:09 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 25 Apr 2018 16:48:09 +0300 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: <636461524664089@web3g.yandex.ru> 25.04.2018, 16:46, "Eric Lemanisser" : > What about > void foo(int (&array)[3]) > and > template > void foo(int (&array)[N]) ? > Both of these functions make sure the caller and the callee use the same array size at compile time. I don't see anybody giving away this kind of security, especially fro functions called across translation units. Does your system store the length of the array next to the pointer at runtime ? What is the cost of this ? Also, compiler might do additional optimizations for arrays when everything happens in the same translation unit, or when LTO is used. > > Le mer. 25 avr. 2018 à 14:58, Phil Bouchard a écrit : >> Eric Lemanisser wrote: >>> Le mer. 25 avr. 2018 à 14:03, Phil Bouchard a écrit : >>> >>>> On 04/25/2018 04:46 AM, Edward Welbourne wrote: >>>>> Phil Bouchard (24 April 2018 19:05) >>>>>> I’m not sure if you read the link I posted about static analysis but a >>>>>> software bug can cause billion dollar projects like space shuttles to >>>> fail. >>>>>> Maybe MS Word was a bad example but they can be very costly. >>>>> >>>>> The Columbia crash wasn't a (computer) software issue.  One can think of >>>>> the organisational failure that lead to it as a (human) software issue, >>>>> but I don't think we have static analysis software for that.  The >>>>> closest you'll get is an ISO 9000 compliance auditor. >>>>> >>>>> The Ariane 5 crash was a software error, but it wasn't a memory abuse; >>>>> it was using an under-sized integer to hold a value that overflowed. >>>>> With luck, static analysis would find that, but it's a pointer abuse. >>>>> >>>>> The loss of the Mars Climate Orbiter involved a software bug, but it was >>>>> a wrong choice of units rather than a pointer abuse.  Mixing archaic >>>>> silly units with sensible SI ones has caused more grief for space >>>>> missions than pointer abuses. >>>> >>>> You need to see the big picture; memory leaks are the most difficult >>>> problems to solve. In the labs you stress-test your software for a few >>>> days but in real life your software is going to run for a few months >>>> consecutively. >>>> >>>> I was working for a WebKit-based browser for TVs for a software company >>>> and the browser kept crashing after a day of usage because of memory >>>> leaks. I mean how are you supposed to watch TV if you need to reboot the >>>> set-top box every day at a random time? >>>> >>>> Also do you really want to spend time running Valgrind on iPhones or >>>> Androids to find these problems? First Valgrind won't fix the problem, >>>> second it is not giving always the same answer and third it doesn't run >>>> on all embedded devices. >>>> >>>> There is more you can read about the subject here: >>>> >>>> "Real Production Issue - Hard to find memory leaks" >>>> https://www.linkedin.com/pulse/c-hard-find-memory-leaks-vidhut-singh >>>> >>>> And BTW: >>>> >>>> "Garbage collection is out the window, because you cannot know when it >>>> is going to happen or how long it will take, which leads to stuttering >>>> frame rates." >>>> >>>> https://www.quora.com/How-do-game-studios-prevent-memory-leaks-in-complex-C++-games >>>> >>>>> So bugs can have disastrous consequences, sure; but fixing all pointer >>>>> abuses won't stop that from being the case.  Meanwhile, in the world of >>>>> most programmers, most bugs are more or less endurable and most users >>>>> would sooner have something that ships today with a few endurable bugs >>>>> than not have the software that helps them do whatever it is they do >>>>> until someone is sure there are no bugs in it.  Buts aren't the only >>>>> thing that can cause a software project to fail. >>>>> >>>>>> Also it is possible for me to support nested structures by prefixing >>>> class >>>>>> names so that their meta-data fits into the top-level namespace but for >>>> the >>>>>> moment they’re not. But those are personal preferences like not using >>>>>> underscores in function names, etc. >>>>> >>>>> Well, if you can support nested structures, you might have a better >>>>> chance of persuading folk to port to your new language; but those with >>>>> large code-bases aren't about to re-write them to eliminate nested >>>>> structures just because you regard that choice as a personal preference. >>>>> I note that Qt has plenty of nested structures. >>>>> I'm not volunteering to refactor them away. >>>> >>>> Support for nested structures is easy to fix and will just take a day or >>>> two to do so. For example: >>>> >>>> struct A >>>> { >>>> struct B >>>> { >>>> }; >>>> }; >>>> >>>> Will be converted into the following so that I can have their >>>> specialization in a top-level namespace: >>>> >>>> struct A__B >>>> { >>>> }; >>>> >>>> struct A >>>> { >>>> }; >>>> >>>> >>> This would break existing code, as name lookup from nested class should >>> visit first enclosing class before visiting namespace. Also, the nested >>> class must have access to all names (private, protected, etc) to which the >>> enclosing class has access ( >>> http://en.cppreference.com/w/cpp/language/nested_types) >>> >>> Since there is no hidden catch then I will tell you right now that: >>>> - NULL C pointers will need to be typed >>>> - pointer casts to their encompassing structure needs to use >>>> _containerof() macro >>>> - C-style array parameters needs to be converted to pointers >>>> >>> What for ? you loose the size information by doing so. >> >> No: >> >> void foo(int array[]) >> {...} >> >> void foo(int * array) >> {...} >> >> Are the same thing. >> >> Regards, >> -Phil >> >> _______________________________________________ >> 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 --  Regards, Konstantin From annulen at yandex.ru Wed Apr 25 15:54:50 2018 From: annulen at yandex.ru (Konstantin Tokarev) Date: Wed, 25 Apr 2018 16:54:50 +0300 Subject: [Development] Why waste energy supporting Python? In-Reply-To: References: Message-ID: <676871524664490@web3g.yandex.ru> 25.04.2018, 04:42, "d3fault" : > Supporting Python first class dilutes Qt, please don't. What's next, > Qt for Java? It's one thing to collect community-developed bindings > for various other languages into a single place... but something else > entirely to pay an entire "team" of developers to work on what is > essentially duplicated effort. That money could instead be spent on > new Qt features and/or fixing the ever growing list of bugs > (supporting Python first class will only add to that list of bugs). > Also, will Python/Qt libs be easily usable from Qt/C++? I doubt it, at > least not without deploying a python interpreter (and we already have > to deploy a JavaScript interpreter if we want to use QtQuick). > > Modern C++ has come leaps and bounds over recent years in improving > code simplicity and safety (clang-tidy QtCreator integration FTW)... > whereas afaik Python still crashes if you don't have your WHITESPACE > perfectly organized.... bleh. Simply put, encouraging the use of > Python is the same thing as discouraging the use of Modern, Simple, > and Safe C++. 1. C++ is not modern, not safe, and by far not simple language (despite having a lot of strengths in different areas) 2. A lot of people complain that Qt has very weak support for bindings to languages other than C++, unlike e.g. GTK+ -- Regards, Konstantin From philippeb8 at gmail.com Wed Apr 25 16:23:08 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 25 Apr 2018 14:23:08 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: Eric Lemanisser wrote: > What about > void foo(int (&array)[3]) > and > template > void foo(int (&array)[N]) ? > Both of these functions make sure the caller and the callee use the same > array size at compile time. I don't see anybody giving away this kind of > security, especially fro functions called across translation units. Does > your system store the length of the array next to the pointer at runtime ? > What is the cost of this ? I think it’ll be fine but let me confirm tonight. Thanks. Regards, -Phil From jesus.fernandez at qt.io Wed Apr 25 16:58:41 2018 From: jesus.fernandez at qt.io (Jesus Fernandez) Date: Wed, 25 Apr 2018 14:58:41 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_M=E5rten_Nordheim_as_an_?= =?iso-8859-1?q?approver?= In-Reply-To: References: Message-ID: +1! Best regards, Jesús ________________________________ From: Development on behalf of Edward Welbourne Sent: Wednesday, April 25, 2018 13:40 To: development at qt-project.org Subject: [Development] Nominating Mårten Nordheim as an approver Hi all, I'd like to nominate Mårten Nordheim for Approver. We've had him here at TQtC, in the Core & Network team, for a bit over a year; he's been reviewing steadily and finding mistakes I miss. As well as diverse work in qtbase, he's also dabbled in the qtnetworkauth and qtwebsockets modules. Here's his list of changes in gerrit: https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z Gerrit Code Review codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser and the (somewhat busier) list of what he's reviewed: https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z Eddy. _______________________________________________ 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 edward.welbourne at qt.io Wed Apr 25 18:36:51 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Wed, 25 Apr 2018 16:36:51 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , Message-ID: Phil Bouchard (24 April 2018 19:05) >>> I’m not sure if you read the link I posted about static analysis but a >>> software bug can cause billion dollar projects like space shuttles to fail. >>> Maybe MS Word was a bad example but they can be very costly. On 04/25/2018 04:46 AM, Edward Welbourne wrote: >> The Columbia crash wasn't a (computer) software issue. One can think of >> the organisational failure that lead to it as a (human) software issue, >> but I don't think we have static analysis software for that. The >> closest you'll get is an ISO 9000 compliance auditor. > >> The Ariane 5 crash was a software error, but it wasn't a memory abuse; >> it was using an under-sized integer to hold a value that overflowed. >> With luck, static analysis would find that, but it's a pointer abuse. > >> The loss of the Mars Climate Orbiter involved a software bug, but it was >> a wrong choice of units rather than a pointer abuse. Mixing archaic >> silly units with sensible SI ones has caused more grief for space >> missions than pointer abuses. Phil Bouchard (25 April 2018 14:02) > You need to see the big picture; Fun fact: when someone gives an example and I debunk it completely, they always claim that I'm looking at the wrong example. I'm never impressed. Now, as concerns looking at "big pictures": I've been working in the software industry for three decades (spread over three dozen years), in a wide diversity of sub-industries, so I will hazard a guess that I have a better grasp of the big picture than you're exhibiting. In particular, the market realities of the software industry are (by no means the whole of, but still) a pretty important part of the big picture. If you ship something tolerably usable that solves problems for real users today, you can use feed-back and/or revenue from those users to improve your product rapidly, which wins the loyalty of users, while your competitors who are still obsessing about not shipping until they can't find any more bugs are getting no users and shall have an inferior feature-set by the time they do ship; and may well have more bugs, that they didn't find but the users will, than yours (in which you fixed the bugs the users found already). Buggy, useful and in the app-store today beats vapourware that claims it'll be bug-free and along "real soon", especially after the latter has been making those claims for any length of time. I note that C++ and Qt are "in the app store today". > memory leaks are the most difficult problems to solve. Well, no, they're not. I've fixed *lots and lots* of memory leaks. Some of them were a little tricky: most were trivial. I can *see* memory leaks just by reading code. It's one of the reasons code review makes memory leaks rare. That and nice sensible disciplines like RAII. Use-after-free is usually harder to solve than a leak. Deadlocks are almost always harder to solve. Some software teams (perhaps because their managers fear the costs) don't adopt the widely-understood best practices that make leaks rare and easy to solve. Those teams end up with leaky code; and the leaks are their biggest problem. However, extrapolating from these poorly run teams to the whole industry is misguided. Those who've endured such teams surely think leaks are the worst, but that's only because they've taken a false economy: the (modest, up-front) cost of Doing The Job Right In The First Place is dwarfed by the price of cutting corners. The Dunning-Kruger effect then promises us that they'll write articles in which they tell the rest of us that the consequences of their own incompetence are the biggest problem facing the industry today. They are, none the less, wrong. > In the labs you stress-test your software for a few days but in real > life your software is going to run for a few months consecutively. I've had to fix the time-reporting code on a web server so that it correctly handled DST transitions as they happened (without burdening its performance in between transitions); this was necessary because we measured expected uptime in years. We did not have problems with memory leaks. We had problems with log messages with timestamps off by an hour for half of each year (until I fixed this). Incidentally, getting *that* right was also harder than fixing memory leaks. (If you think it's easy - just send a message to the right code to tzset() just after the next transition - you've forgotten that the date of next transition is controlled by capricious politicians who may have moved the transition before that event triggers. I coded round that.) > I was working for a WebKit-based browser for TVs for a software company > and the browser kept crashing after a day of usage because of memory > leaks. I mean how are you supposed to watch TV if you need to reboot the > set-top box every day at a random time? I worked on the Opera browser, back when its engine was Presto, and we fixed our share of leaks; which is one of the things that prompted us to adopt code review, after which the overwhelming majority of leaks got caught in review. There were still plenty of other ways to crash, though; and plenty of non-crash bugs that were potentially more annoying for users. (If the only work-around is to exit the browser and restart, it may be better to have crashed so the user got the work-around when the browser auto-relaunched itself, phoenix-like, from the ashes.) > Also do you really want to spend time running Valgrind on iPhones or > Androids to find these problems? First Valgrind won't fix the problem, > second it is not giving always the same answer and third it doesn't run > on all embedded devices. Well, your life is a lot easier if most of your code is cross-platform, so that your builds for desktop are using most of the same code that your device builds use; that way, Valgrind testing on desktop will fix all the memory leaks in the cross-platform code and you only need to find the leaks in your device-specific code. Meanwhile, before I'd ever heard of Valgrind, I was hunting subtle memory abuses on bitty little devices (compared to which Android and iOS are luxurious palaces) where gdbserver was my friend and judicious output streamed over netcat helped us to track down what was going wrong. Leaks were less of an issue than use-after-free and kindred abuses of pointers. Oh, and image-handling code that assumes it's running on a little-endian processor. I believe you over-estimate the difficulty of finding memory leaks, or of *avoiding writing them in the first place*, which is usually a better plan. Mature software development teams have solved this problem. We don't need garbage-collection: we can do it in C++ or C just fine; it's all a matter of appropriate discipline. Meanwhile, the many other kinds of bugs may be more troublesome than the authors you quote understand, Eddy. From philippeb8 at gmail.com Thu Apr 26 05:35:46 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Wed, 25 Apr 2018 23:35:46 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/25/2018 09:45 AM, Eric Lemanisser wrote: > What about > void foo(int (&array)[3]) This one works fine: void foo(int (&array)[10]) { cout << __PRETTY_FUNCTION__ << endl; } int main() { int array[10]; foo(array); return 0; } Correctly outputs: void foo(const boost::node_proxy &, boost::root_array, 10> (&)) > and > template > void foo(int (&array)[N]) ? Since I just started testing C++98 as of last week, I haven't yet had a chance to test templates thoroughly. So this one is buggy and I'll have to fix it. > Both of these functions make sure the caller and the callee use the same > array size at compile time. I don't see anybody giving away this kind of > security, especially fro functions called across translation units. Does > your system store the length of the array next to the pointer at runtime > ? What is the cost of this ? root_array<> looks like this: template class root_array : public boost::root_ptr { typedef boost::root_ptr base; public: root_array(base const & p) : base(p) { } root_array(boost::node_proxy const & __y) : base(__y, "", boost::create()(__y, S)) { } [...] }; So it knows the length of the array at compile-time but it really creates a root_ptr pointing to a std::vector of size S allocated at runtime. This is the lowest common factor necessary to make a smooth conversion to a root_ptr. Regards, -Phil From philippeb8 at gmail.com Thu Apr 26 06:35:55 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 26 Apr 2018 00:35:55 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/25/2018 12:36 PM, Edward Welbourne wrote: >> memory leaks are the most difficult problems to solve. > > Well, no, they're not. > I've fixed *lots and lots* of memory leaks. > Some of them were a little tricky: most were trivial. > I can *see* memory leaks just by reading code. > It's one of the reasons code review makes memory leaks rare. > That and nice sensible disciplines like RAII. > > Use-after-free is usually harder to solve than a leak. > Deadlocks are almost always harder to solve. You're right: 1) Deadlocks are much more difficult to find 2) Then comes the use-after-free but they can be easily detected by throwing an exception with root_ptr 3) Then we have the memory leaks... You're a smart person there's no doubt about that and I respect that but people like you aren't cheap either. - Your salary could easily be up to $300k in New York or San Francisco. - It's going to take at least 6 months to learn the code base correctly. - Then you can start doing code reviews once a month for 4 different authors. The software I propose is 1% of the price and works right off the bat with no learning curve for as much authors as you want. Furthermore wouldn't you rather do "constructive programming" like coding a solid 3D web engine using WebAssembly or an AI engine than fixing memory leaks on the iPhone? The industry needs to jump start to the next level! >> Also do you really want to spend time running Valgrind on iPhones or >> Androids to find these problems? First Valgrind won't fix the problem, >> second it is not giving always the same answer and third it doesn't run >> on all embedded devices. > > Well, your life is a lot easier if most of your code is cross-platform, > so that your builds for desktop are using most of the same code that > your device builds use; that way, Valgrind testing on desktop will fix > all the memory leaks in the cross-platform code and you only need to > find the leaks in your device-specific code. The software for radios used by the military for example cannot be tested on the desktop; it needs to be tested on the device itself. Furthermore the desktop, the Android and the iPhone don't use the same memory management so we have flaky results. > Meanwhile, before I'd ever heard of Valgrind, I was hunting subtle > memory abuses on bitty little devices (compared to which Android and iOS > are luxurious palaces) where gdbserver was my friend and judicious > output streamed over netcat helped us to track down what was going > wrong. Leaks were less of an issue than use-after-free and kindred > abuses of pointers. Oh, and image-handling code that assumes it's > running on a little-endian processor. Luckily gdbserver worked in your case because it mostly always hung in mine. > I believe you over-estimate the difficulty of finding memory leaks, or > of *avoiding writing them in the first place*, which is usually a better > plan. Mature software development teams have solved this problem. > We don't need garbage-collection: we can do it in C++ or C just fine; > it's all a matter of appropriate discipline. Meanwhile, the many other > kinds of bugs may be more troublesome than the authors you quote > understand, Most of the college graduates these days don't even know C++ very well because they think it's old fashioned and they don't want to deal with these types of memory problems. I am offering a solution to this problem so that the entire industry can focus on efficient "constructive programming". And I put Qt on top of the list because you already have all the necessary layers to jump start to the next level. Regards, -Phil From Oliver.Wolff at qt.io Thu Apr 26 07:12:17 2018 From: Oliver.Wolff at qt.io (Oliver Wolff) Date: Thu, 26 Apr 2018 07:12:17 +0200 Subject: [Development] =?utf-8?q?Nominating_M=C3=A5rten_Nordheim_as_an_ap?= =?utf-8?q?prover?= In-Reply-To: References: Message-ID: <36d99f9f-651c-f09f-8aee-4253f034b4be@qt.io> +1 from me as well. He is one of the brave souls who had a look at beautiful winrt code voluntarily (and gave valuable feedback on it) On 25/04/2018 13:40, Edward Welbourne wrote: > Hi all, > > I'd like to nominate Mårten Nordheim for Approver. > > We've had him here at TQtC, in the Core & Network team, for a bit over a > year; he's been reviewing steadily and finding mistakes I miss. As well > as diverse work in qtbase, he's also dabbled in the qtnetworkauth and > qtwebsockets modules. Here's his list of changes in gerrit: > > https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z > > and the (somewhat busier) list of what he's reviewed: > > https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Martin.Smith at qt.io Thu Apr 26 07:27:58 2018 From: Martin.Smith at qt.io (Martin Smith) Date: Thu, 26 Apr 2018 05:27:58 +0000 Subject: [Development] =?iso-8859-1?q?Nominating_M=E5rten_Nordheim_as_an_?= =?iso-8859-1?q?approver?= In-Reply-To: <36d99f9f-651c-f09f-8aee-4253f034b4be@qt.io> References: , <36d99f9f-651c-f09f-8aee-4253f034b4be@qt.io> Message-ID: +1 ________________________________________ From: Development on behalf of Oliver Wolff Sent: Thursday, April 26, 2018 7:12:17 AM To: development at qt-project.org Subject: Re: [Development] Nominating Mårten Nordheim as an approver +1 from me as well. He is one of the brave souls who had a look at beautiful winrt code voluntarily (and gave valuable feedback on it) On 25/04/2018 13:40, Edward Welbourne wrote: > Hi all, > > I'd like to nominate Mårten Nordheim for Approver. > > We've had him here at TQtC, in the Core & Network team, for a bit over a > year; he's been reviewing steadily and finding mistakes I miss. As well > as diverse work in qtbase, he's also dabbled in the qtnetworkauth and > qtwebsockets modules. Here's his list of changes in gerrit: > > https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z > > and the (somewhat busier) list of what he's reviewed: > > https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z > > Eddy. > _______________________________________________ > 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 Shawn.Rutledge at qt.io Thu Apr 26 08:06:48 2018 From: Shawn.Rutledge at qt.io (Shawn Rutledge) Date: Thu, 26 Apr 2018 06:06:48 +0000 Subject: [Development] =?utf-8?q?Nominating_M=C3=A5rten_Nordheim_as_an_ap?= =?utf-8?q?prover?= In-Reply-To: References: Message-ID: <99577FDA-2977-4F1A-949A-32B1209D5890@qt.io> +1 > On 25 Apr 2018, at 13:40, Edward Welbourne wrote: > > Hi all, > > I'd like to nominate Mårten Nordheim for Approver. > > We've had him here at TQtC, in the Core & Network team, for a bit over a > year; he's been reviewing steadily and finding mistakes I miss. As well > as diverse work in qtbase, he's also dabbled in the qtnetworkauth and > qtwebsockets modules. Here's his list of changes in gerrit: > > https://codereview.qt-project.org/#/q/owner:"M%25C3%25A5rten+Nordheim",n,z > > and the (somewhat busier) list of what he's reviewed: > > https://codereview.qt-project.org/#/q/reviewer:"M%25C3%25A5rten+Nordheim",n,z > > Eddy. > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From aapo.keskimolo at qt.io Thu Apr 26 08:28:20 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Thu, 26 Apr 2018 06:28:20 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: The Coin service will go down until we fix the broken storage. We apologize for the inconvenience. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From aapo.keskimolo at qt.io Thu Apr 26 10:32:07 2018 From: aapo.keskimolo at qt.io (=?utf-8?B?QWFwbyBLZXNraW3DtmzDtg==?=) Date: Thu, 26 Apr 2018 08:32:07 +0000 Subject: [Development] Coin maintenance notification In-Reply-To: References: Message-ID: Coin is back in operation and the storage should be fixed, now. Please check your staged commits. -----Original Message----- From: Aapo Keskimölö Sent: torstai 26. huhtikuuta 2018 9.28 To: 'development at qt-project.org' Subject: Coin maintenance notification The Coin service will go down until we fix the broken storage. We apologize for the inconvenience. Kind regards/Ystävällisin terveisin, Aapo Keskimölö From jhihn at gmx.com Thu Apr 26 10:59:22 2018 From: jhihn at gmx.com (Jason H) Date: Thu, 26 Apr 2018 10:59:22 +0200 Subject: [Development] Why waste energy supporting Python? In-Reply-To: <676871524664490@web3g.yandex.ru> References: <676871524664490@web3g.yandex.ru> Message-ID: > Sent: Wednesday, April 25, 2018 at 3:54 PM > From: "Konstantin Tokarev" > To: d3fault , "development at qt-project.org" > Subject: Re: [Development] Why waste energy supporting Python? > > > > 25.04.2018, 04:42, "d3fault" : > > Supporting Python first class dilutes Qt, please don't. What's next, > > Qt for Java? It's one thing to collect community-developed bindings > > for various other languages into a single place... but something else > > entirely to pay an entire "team" of developers to work on what is > > essentially duplicated effort. That money could instead be spent on > > new Qt features and/or fixing the ever growing list of bugs > > (supporting Python first class will only add to that list of bugs). > > Also, will Python/Qt libs be easily usable from Qt/C++? I doubt it, at > > least not without deploying a python interpreter (and we already have > > to deploy a JavaScript interpreter if we want to use QtQuick). > > > > Modern C++ has come leaps and bounds over recent years in improving > > code simplicity and safety (clang-tidy QtCreator integration FTW)... > > whereas afaik Python still crashes if you don't have your WHITESPACE > > perfectly organized.... bleh. Simply put, encouraging the use of > > Python is the same thing as discouraging the use of Modern, Simple, > > and Safe C++. > > 1. C++ is not modern, not safe, and by far not simple language > (despite having a lot of strengths in different areas) > > 2. A lot of people complain that Qt has very weak support for bindings to > languages other than C++, unlike e.g. GTK+ "The fact that Python is one of the fastest growing programming languages, measured in popularity, is probably also old news in most communities. " It is a mistake to interpret the increased popularity of python as that people are developing apps with it. They are not. The bump in python is solely due to machine learning. However, I first used Qt with Python back in 2005. It was a hoot! But it doesn't make much sense with QML which is even easier. We'd better off putting the resources that would be devoted to python to improving Qt proper, not another language binding. I've given up, quite willingly, Qt+python for QML. I even looked at qml+python but that makes even less sense. If you want to do something with Python, rip JS out of QML and replace it with Python. Continuing to support Python bindings and QML is counter productive. From david.lenz at aid-driving.eu Thu Apr 26 14:27:12 2018 From: david.lenz at aid-driving.eu (David Lenz) Date: Thu, 26 Apr 2018 12:27:12 +0000 Subject: [Development] Qt3DRender Texture Update synchronous with Mesh/Transform changes Message-ID: Hi all, I am writing a QML application making use of Qt3D for the rendering of 3D objects. In my scene I want to display a stream of QImages, therefore I subclassed Qt3DRender::QPaintedTextureImage to paint the QImage on the texture every time the image changes. I added this texture to a PlaneMesh and place it in the scene. So far so good, this works. Now as a next step, the QImage size AND the position of the PlaneMesh are dynamic. So if i update the QImage and the transform of the PlaneMesh simultaneously, the update of the texture gets delayed (because the real update and upload to GPU happens in a background thread some time later) This leads to constant flickering of the texture which is pretty annoying. So my question: Is there a way to either: 1. Update the texture synchronously so I know that it will be updated in the next frame? 2. Get notified as soon as the texture was updated, so that i can update my transform a little later? Thanks for your support David -------------- next part -------------- An HTML attachment was scrubbed... URL: From tony.sarajarvi at qt.io Thu Apr 26 16:58:26 2018 From: tony.sarajarvi at qt.io (=?iso-8859-1?Q?Tony_Saraj=E4rvi?=) Date: Thu, 26 Apr 2018 14:58:26 +0000 Subject: [Development] Maintenance in network aprox between the 25th and 27th of April In-Reply-To: References: Message-ID: Hi We are right in the middle of redeploying all the hosts currently. So ATM capacity is down by 50%, but I won't bring it down from that before we get updated hardware online. However, due to problems left and right (as usual), the deployment back takes time. With so much going on, I really don't even know why hosts don't come back online. The new capacity we have has been set up, but the hardware has been wired differently than the previous batch we got. So we are using a different RAID controller, and you can guess twice how MAAS deployment works with it. -Tony From: Tony Sarajärvi Sent: tiistai 24. huhtikuuta 2018 14.24 To: 'development at qt-project.org' Subject: RE: Maintenance in network aprox between the 25th and 27th of April Hi This is a reminder of the service break we are going to be having the next few days. A brief summary of what's going to change and what they affect: Wednesday: * New switches are being installed * Side by side with the current ones, no interruptions as such * New hosts are being connected to the CI * This increases our capacity in the CI after they get deployed * Our blade chassis hosting our infra is going to be moved * This cuts of everyone from our infra for a minute (This includes our VPN, and some external services like testresults.qt.io) Thursday: * All CI hosts are going down for upgrade * Affects CI in such that our 20 hosts have to be taken out of service one by one * Bringing them back takes ~2h per host * MacMinis are taken down and re-routed * This prevents macOS builds in our Jenkins farm Friday: * MacMinis are brought back online * Troubleshooting In case of questions, contact qt-ci at qt.io With regards, -Tony From: Tony Sarajärvi Sent: perjantai 6. huhtikuuta 2018 9.36 To: 'development at qt-project.org' > Subject: Maintenance in network aprox between the 25th and 27th of April Hi We are going to perform maintenance on our switches which will probably cause interruptions in all Qt services not located in AWS. New switches are estimated to arrive so that the work can begin approximately on the 25th. We'll inform you with more precise data as we get it. -Tony -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Fri Apr 27 00:06:33 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Thu, 26 Apr 2018 22:06:33 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: Phil Bouchard wrote: > And I put Qt on top of the list because you already have all the > necessary layers to jump start to the next level. What I meant by that is Qt could create the ultimate “holodeck” with a mixture of: - Virtual reality headsets - WebAssembly - Qt / QML supporting 3D effects - Some external AI engine - Fornux C++ Superset I think that’s much better than wasting your time supporting Python or Javascript that can be easily reverse engineered because of their interpreted nature. Regards, -Phil From Friedemann.Kleint at qt.io Fri Apr 27 08:37:50 2018 From: Friedemann.Kleint at qt.io (Friedemann Kleint) Date: Fri, 27 Apr 2018 08:37:50 +0200 Subject: [Development] Why Widget::grabMouse() installs WH_JOURNALRECORD hook on Windows in Qt 4.8.x In-Reply-To: References: Message-ID: Hi, >    journalRec = SetWindowsHookEx(WH_JOURNALRECORD, (HOOKPROC)qJournalRecordProc, GetModuleHandle(0), 0); >   Since this clearly a hack that was obviously needed to make mouse grabbing working, I would very much like to know why it was done in this way and what was the original problem. some digging in the history failed to reveal any information on why  this done; the code can be safely removed, I think. Regards, Friedemann -- Friedemann Kleint The Qt Company GmbH From edward.welbourne at qt.io Fri Apr 27 10:18:21 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 27 Apr 2018 08:18:21 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , Message-ID: Phil Bouchard wrote: >> And I put Qt on top of the list because you already have all the >> necessary layers to jump start to the next level. Phil Bouchard (27 April 2018 00:06) > What I meant by that is Qt could create the ultimate “holodeck” with a > mixture of: > - Virtual reality headsets > - WebAssembly > - Qt / QML supporting 3D effects Well, those are all, in some sense, on their way. > - Some external AI engine We might just leave the folk with the AI engines to work out how to use Qt to give them nice UIs. > - Fornux C++ Superset Nothing as yet persuades me that we need this one. Of course, once your compiler can handle Qt's C++ code, you'll be at liberty to combine the first three above with whatever you like, including your favourite AI engine. > I think that’s much better than wasting your time supporting Python or > Javascript that can be easily reverse engineered because of their > interpreted nature. Your obsession with not being easy to reverse engineer suggests you don't really understand the nature of Free Software; our source code is publicly available, so who would need to reverse-engineer it ? We gladly share it and save them the bother, Eddy. From michal.klocek at qt.io Fri Apr 27 10:58:20 2018 From: michal.klocek at qt.io (Michal Klocek) Date: Fri, 27 Apr 2018 10:58:20 +0200 Subject: [Development] =?utf-8?q?Nominating_J=C3=BCri_Valdmann_for_Approve?= =?utf-8?q?r_status?= Message-ID: Hi I would like to nominate Jüri Valdmann for Approver. He joined The Qt Company more than one year ago and he's been doing most of his excellent work for QtWebEngine. You can see his contributions here: https://codereview.qt-project.org/#/q/owner:%22J%C3%BCri%20Valdmann%22,n,z Br Michal From qt at colby.id.au Fri Apr 27 10:52:34 2018 From: qt at colby.id.au (Paul Colby) Date: Fri, 27 Apr 2018 08:52:34 +0000 Subject: [Development] Which gerrit branch for minor bug fix? Message-ID: Hi, I want submit a very small bug fix to the QtXmlPatterns module. I think I have git and Gerrit all setup, but just wanted to confirm a two things. The bug to be fixed has been present, untouched since at least Qt 4.6. Looking at the QUIP5 guidelines, I'd say its classified as "Bugs: Other" (ie, not a regression, or crash), which suggests the Gerrit ref should be "Stable". So then, should I be doing: git push gerrit HEAD:refs/for/5.10 Also, is it considered helpful / good practice to create a bugreport in JIRA to associate with the push, or that considered unecessary noise? Thanks! :) Paul. -------------- next part -------------- An HTML attachment was scrubbed... URL: From viktor.engelmann at qt.io Fri Apr 27 10:53:48 2018 From: viktor.engelmann at qt.io (Viktor Engelmann) Date: Fri, 27 Apr 2018 10:53:48 +0200 Subject: [Development] =?utf-8?q?Nominating_J=C3=BCri_Valdmann_for_Approv?= =?utf-8?q?er_status?= In-Reply-To: References: Message-ID: <2fed8d05-e4a8-890e-0c01-19c8775134f3@qt.io> +1 from me. He does a very good job. On 27.04.2018 10:58, Michal Klocek wrote: > Hi > > I would like to nominate Jüri Valdmann for Approver. > > He joined The Qt Company more than one year ago and he's been doing most > of his excellent work for QtWebEngine. > > You can see his contributions here: > > https://codereview.qt-project.org/#/q/owner:%22J%C3%BCri%20Valdmann%22,n,z > > Br > > Michal > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development -- Viktor Engelmann Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin Viktor.Engelmann at qt.io +49 151 26784521 http://qt.io Geschäftsführer: Mika Pälsi, Juha Varelius, Mika Harjuaho Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B The Future is Written with Qt www.qtworldsummit.com From alexandru.croitor at qt.io Fri Apr 27 10:56:58 2018 From: alexandru.croitor at qt.io (Alexandru Croitor) Date: Fri, 27 Apr 2018 08:56:58 +0000 Subject: [Development] =?utf-8?q?Nominating_J=C3=BCri_Valdmann_for_Approv?= =?utf-8?q?er_status?= In-Reply-To: References: Message-ID: <59B762A0-4BF8-4CFB-91B0-70AF04CE86B8@qt.io> +1 from me > On 27. Apr 2018, at 10:58, Michal Klocek wrote: > > Hi > > I would like to nominate Jüri Valdmann for Approver. > > He joined The Qt Company more than one year ago and he's been doing most > of his excellent work for QtWebEngine. > > You can see his contributions here: > > https://codereview.qt-project.org/#/q/owner:%22J%C3%BCri%20Valdmann%22,n,z > > Br > > Michal > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From joerg.bornemann at qt.io Fri Apr 27 10:59:39 2018 From: joerg.bornemann at qt.io (Joerg Bornemann) Date: Fri, 27 Apr 2018 10:59:39 +0200 Subject: [Development] =?utf-8?q?Nominating_J=C3=BCri_Valdmann_for_Approv?= =?utf-8?q?er_status?= In-Reply-To: References: Message-ID: <9c302ae5-b147-fcb8-5668-0e17631b3914@qt.io> On 04/27/2018 10:58 AM, Michal Klocek wrote: > I would like to nominate Jüri Valdmann for Approver. +1 Disclaimer: he's sitting next to me. BR, Joerg From andre.hartmann at iseg-hv.de Fri Apr 27 11:43:43 2018 From: andre.hartmann at iseg-hv.de (=?UTF-8?Q?Andr=c3=a9_Hartmann?=) Date: Fri, 27 Apr 2018 11:43:43 +0200 Subject: [Development] Which gerrit branch for minor bug fix? In-Reply-To: References: Message-ID: <353ac664-f41a-275c-7be0-fff35b34830a@iseg-hv.de> Hi Paul, Am 27.04.2018 um 10:52 schrieb Paul Colby: > Hi, > > I want submit a very small bug fix to the QtXmlPatterns module.  I think > I have git and Gerrit all setup, but just wanted to confirm a two things. > > The bug to be fixed has been present, untouched since at least Qt 4.6. > Looking at the QUIP5 guidelines, I'd say its classified as "Bugs: Other" > (ie, not a regression, or crash), which suggests the Gerrit ref should > be "Stable".  So then, should I be doing: > > git push gerrit HEAD:refs/for/5.10 That would be correct in principle, but 5.10 is already closed. Please use 5.11. (Please note that we can move patches later easily within Gerrit also). > Also, is it considered helpful / good practice to create a bugreport in > JIRA to associate with the push, or that considered unecessary noise? If it's a small fix, then usually not. You can of course search if someone else has reported it already and then integrate a Task-number: QTBUG-12345 in your commit message, directly above the Change-Id line. > Thanks! :) You're welcome :) André > > Paul. > > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development > -- Dipl.-Ing. (FH) André Hartmann Softwareentwicklung / Software Development E-Mail: andre.hartmann at iseg-hv.de | Tel: +49 351 26996-43 | Fax: +49 351 26996-21 iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY. iseg-hv.de | iseg-hv.com | download.iseg-hv.com Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim Pöthig Amtsgericht / Lower district court: Dresden HRB 16250 Umsatzsteuer-Id: / VAT-ID: DE812508942 News / Information https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - Unified Control Software https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep the price https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM Detectors https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! Product catalog 2017 / 2018 released https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with reversible polarity Links https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay connected! https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE | Tutorials and more ... https://www.twitter.com/iseg_hv iseg on TWITTER | please follow! https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg CATALOG | download product catalog as PDF http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, firmware and more... Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser Mail ist nicht gestattet. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden. From allan.jensen at qt.io Fri Apr 27 11:45:12 2018 From: allan.jensen at qt.io (Allan Sandfeld Jensen) Date: Fri, 27 Apr 2018 11:45:12 +0200 Subject: [Development] =?utf-8?q?Nominating_J=C3=BCri_Valdmann_for_Approv?= =?utf-8?q?er_status?= In-Reply-To: References: Message-ID: <1666471.cCssul70LY@twilight> On Freitag, 27. April 2018 10:58:20 CEST Michal Klocek wrote: > Hi > > I would like to nominate Jüri Valdmann for Approver. > > He joined The Qt Company more than one year ago and he's been doing most > of his excellent work for QtWebEngine. > > You can see his contributions here: > > https://codereview.qt-project.org/#/q/owner:%22J%C3%BCri%20Valdmann%22,n,z > +1 'Allan From qt at colby.id.au Fri Apr 27 11:51:37 2018 From: qt at colby.id.au (Paul Colby) Date: Fri, 27 Apr 2018 09:51:37 +0000 Subject: [Development] Which gerrit branch for minor bug fix? In-Reply-To: <353ac664-f41a-275c-7be0-fff35b34830a@iseg-hv.de> References: <353ac664-f41a-275c-7be0-fff35b34830a@iseg-hv.de> Message-ID: Thanks André, On Fri, Apr 27, 2018 at 7:40 PM André Hartmann wrote: > Hi Paul, > > Am 27.04.2018 um 10:52 schrieb Paul Colby: > > Hi, > > > > I want submit a very small bug fix to the QtXmlPatterns module. I think > > I have git and Gerrit all setup, but just wanted to confirm a two things. > > > > The bug to be fixed has been present, untouched since at least Qt 4.6. > > Looking at the QUIP5 guidelines, I'd say its classified as "Bugs: Other" > > (ie, not a regression, or crash), which suggests the Gerrit ref should > > be "Stable". So then, should I be doing: > > > > git push gerrit HEAD:refs/for/5.10 > > That would be correct in principle, but 5.10 is already closed. > > Please use 5.11. (Please note that we can move patches later easily > within Gerrit also). > Great, will do :) > > > Also, is it considered helpful / good practice to create a bugreport in > > JIRA to associate with the push, or that considered unecessary noise? > > If it's a small fix, then usually not. You can of course search if > someone else has reported it already and then integrate a > I did a quick search to begin with, just in case is was already a known issue (and/or someone else could already be working on it). > Task-number: QTBUG-12345 > > in your commit message, directly above the Change-Id line. > Ah, good to know for future :) Thanks again, Paul. > > > Thanks! :) > > You're welcome :) > > André > > > > > Paul. > > > > > > _______________________________________________ > > Development mailing list > > Development at qt-project.org > > http://lists.qt-project.org/mailman/listinfo/development > > > > > -- > Dipl.-Ing. (FH) André Hartmann > Softwareentwicklung / Software Development > > E-Mail: andre.hartmann at iseg-hv.de | Tel: +49 351 26996-43 > <+49%20351%202699643> | Fax: +49 351 > 26996-21 > > iseg Spezialelektronik GmbH - HIGH VOLTAGE. EXACTLY. > iseg-hv.de | iseg-hv.com | download.iseg-hv.com > > Bautzner Landstr. 23, 01454 Radeberg / Rossendorf, Germany > Geschäftsführer / Managing directors: Dr. Frank Gleisberg, Dr. Joachim > Pöthig > Amtsgericht / Lower district court: Dresden HRB 16250 > Umsatzsteuer-Id: / VAT-ID: DE812508942 > > News / Information > https://iseg-hv.com/en/products/control#isegControl2 isegControl2 - > Unified Control Software > https://iseg-hv.com/en/products/detail/EHS EHS FLEX - Customize and keep > the price > https://iseg-hv.com/en/products/detail/EHS EHS STACK - Perfect for GEM > Detectors > https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf NEW! > Product catalog 2017 / 2018 released > https://iseg-hv.com/en/products/detail/NHR NHR - NIM HV-Supply with > reversible polarity > > Links > https://www.linkedin.com/company/12726924 iseg on LINKEDIN | Let's stay > connected! > https://www.youtube.com/channel/UC5AL-ZgOqSim_1gYNnndyzQ iseg on YOUTUBE > | Tutorials and more ... > https://www.twitter.com/iseg_hv iseg on TWITTER | please follow! > https://iseg-hv.com/files/iseg-high-voltage-power-supplies.pdf iseg > CATALOG | download product catalog as PDF > http://download.iseg-hv.com/ iseg DOWNLOADS | manuals, software, > firmware and more... > > Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte > Informationen. Wenn Sie nicht der richtige > Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren > Sie bitte sofort den Absender und > vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte > Weitergabe dieser Mail ist nicht > gestattet. > > This e-mail may contain confidential and/or privileged information. If > you are not the intended recipient > (or have received this e-mail in error) please notify the sender > immediately and destroy this e-mail. > Any unauthorized copying, disclosure or distribution of the material in > this e-mail is strictly forbidden. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Simon.Hausmann at qt.io Fri Apr 27 11:54:11 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Fri, 27 Apr 2018 09:54:11 +0000 Subject: [Development] CI "wave-through" Message-ID: Hi, Since yesterday afternoon around 15:30 central european time the CI has experienced a "failure" that resulted in each and all tests being skipped. So if a change broke the build, the CI would reject it. But if the change would normally result in a test failing, then the CI waved the change through regardless as it did not run any tests at all (apart from the BIC tests). The issue has been corrected as of a few minutes ago, but there is a non-zero chance that faulty changes may have slipped through and may result in test failures that are not related to changes you're trying to integrate. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From sami.nurmenniemi at qt.io Fri Apr 27 12:06:26 2018 From: sami.nurmenniemi at qt.io (Sami Nurmenniemi) Date: Fri, 27 Apr 2018 10:06:26 +0000 Subject: [Development] CI "wave-through" In-Reply-To: References: Message-ID: Hi, Increasing the "non-zero change" there a bit, the "wave-through window" was from "25th of April 15:30 CET" to "27th of April 12:00 CET". Best Regards, Sami ________________________________ Lähettäjä: Development käyttäjän Simon Hausmann puolesta Lähetetty: 27. huhtikuuta 2018 12:54:11 Vastaanottaja: development at qt-project.org Kopio: Qt CI Aihe: [Development] CI "wave-through" Hi, Since yesterday afternoon around 15:30 central european time the CI has experienced a "failure" that resulted in each and all tests being skipped. So if a change broke the build, the CI would reject it. But if the change would normally result in a test failing, then the CI waved the change through regardless as it did not run any tests at all (apart from the BIC tests). The issue has been corrected as of a few minutes ago, but there is a non-zero chance that faulty changes may have slipped through and may result in test failures that are not related to changes you're trying to integrate. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From tuukka.turunen at qt.io Fri Apr 27 12:28:45 2018 From: tuukka.turunen at qt.io (Tuukka Turunen) Date: Fri, 27 Apr 2018 10:28:45 +0000 Subject: [Development] CI "wave-through" Message-ID: <1FD5F2C3-7520-4FB7-8193-36977F579BCA@qt.io> Hi, So we should probably restart https://codereview.qt-project.org/#/c/227410/ and re-run other qt5.git runs to make sure all tests are properly run in those? Yours, Tuukka From: Development on behalf of Sami Nurmenniemi Date: Friday, 27 April 2018 at 13.06 To: Simon Hausmann , "development at qt-project.org" Cc: Qt CI Subject: Re: [Development] CI "wave-through" Hi, Increasing the "non-zero change" there a bit, the "wave-through window" was from "25th of April 15:30 CET" to "27th of April 12:00 CET". Best Regards, Sami ________________________________ Lähettäjä: Development käyttäjän Simon Hausmann puolesta Lähetetty: 27. huhtikuuta 2018 12:54:11 Vastaanottaja: development at qt-project.org Kopio: Qt CI Aihe: [Development] CI "wave-through" Hi, Since yesterday afternoon around 15:30 central european time the CI has experienced a "failure" that resulted in each and all tests being skipped. So if a change broke the build, the CI would reject it. But if the change would normally result in a test failing, then the CI waved the change through regardless as it did not run any tests at all (apart from the BIC tests). The issue has been corrected as of a few minutes ago, but there is a non-zero chance that faulty changes may have slipped through and may result in test failures that are not related to changes you're trying to integrate. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From philippeb8 at gmail.com Fri Apr 27 14:20:39 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 27 Apr 2018 08:20:39 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/27/2018 04:18 AM, Edward Welbourne wrote: > Phil Bouchard wrote: >>> And I put Qt on top of the list because you already have all the >>> necessary layers to jump start to the next level. > > Phil Bouchard (27 April 2018 00:06) >> What I meant by that is Qt could create the ultimate “holodeck” with a >> mixture of: >> - Virtual reality headsets >> - WebAssembly >> - Qt / QML supporting 3D effects > > Well, those are all, in some sense, on their way. Nice... >> - Some external AI engine > > We might just leave the folk with the AI engines to work out how to use > Qt to give them nice UIs. Definitely. >> - Fornux C++ Superset > > Nothing as yet persuades me that we need this one. Of course, once your > compiler can handle Qt's C++ code, you'll be at liberty to combine the > first three above with whatever you like, including your favourite AI > engine. I'm just trying to help speeding up development here. >> I think that’s much better than wasting your time supporting Python or >> Javascript that can be easily reverse engineered because of their >> interpreted nature. > > Your obsession with not being easy to reverse engineer suggests you > don't really understand the nature of Free Software; our source code is > publicly available, so who would need to reverse-engineer it ? > We gladly share it and save them the bother, I'm referring to Qt's customers who wants to release commercial apps; they won't like to know part of their code can be deciphered. Performance does play a role as well; you don't want to bottleneck the app with any garbage collector at all. Regards, -Phil From edward.welbourne at qt.io Fri Apr 27 14:59:32 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 27 Apr 2018 12:59:32 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , Message-ID: Phil Bouchard wrote: >>> - Fornux C++ Superset On 04/27/2018 04:18 AM, Edward Welbourne wrote: >> Nothing as yet persuades me that we need this one. Of course, once your >> compiler can handle Qt's C++ code, you'll be at liberty to combine the >> first three above with whatever you like, including your favourite AI >> engine. Phil Bouchard (27 April 2018 14:20) > I'm just trying to help speeding up development here. It remains that you have failed to persuade folk on this list that Fornux would in fact speed up development. >>> I think that’s much better than wasting your time supporting Python or >>> Javascript that can be easily reverse engineered because of their >>> interpreted nature. >> >> Your obsession with not being easy to reverse engineer suggests you >> don't really understand the nature of Free Software; our source code is >> publicly available, so who would need to reverse-engineer it ? >> We gladly share it and save them the bother, > I'm referring to Qt's customers who wants to release commercial apps; > they won't like to know part of their code can be deciphered. Well, first: copyright protects their work. The fact that someone else can decipher it is incidental - even if they publish their source code, no-one else can *use* that without their permission. Beyond that, as long as the code runs on users' computers, some form or another of the code is out there and the folk who are any good at reverse engineering are going to discover its secrets, if they care to do so. Trying to keep your implementation secret is consequently mostly pointless. > Performance does play a role as well; you don't want to bottleneck the > app with any garbage collector at all. Garbage collectors have their advantages and their costs; the principal advantage is that developing in a garbage-collected language is significantly easier (you have fewer irrelevancies to pay attention to), which means a broader pool of authors can contribute - notably, those who are good at UX/UI design aren't always also good at the finicky details of keeping track of memory allocations. So garbage-collected laguages tend to be good for rapid prototyping. That's good, because you get to ship a useful (and useable) product sooner than your competitors. Of course, the haphazard timing of garbage-collection runs can be an issue, although many garbage-collected systems seem to manage this without ever causing me annoyance (e.g. web browser ECMAScript engines, most obviously). Java programs sporadically annoy me with this. Still, with QML, you then have the option of moving the performance-critical parts of the code (once the UX-competent developers have prototyped it) from interpreted JavaScript to compiled C++. So you get the advantages of rapid development and deployment, combined with the ability to fix the performance issues that go with garbage-collection. Python, similarly, lets one recode a module in C. Performance of your development team (getting a useful product to market quickly) is at least as important as performance of your run-time program: and, with an interpreted language layered on top of an engine that you can augment in a compiled language, you can have both in practice, Eddy. From philippeb8 at gmail.com Fri Apr 27 15:36:20 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 27 Apr 2018 13:36:20 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , Message-ID: Edward Welbourne wrote: > Phil Bouchard wrote: >>>> - Fornux C++ Superset > > On 04/27/2018 04:18 AM, Edward Welbourne wrote: >>> Nothing as yet persuades me that we need this one. Of course, once your >>> compiler can handle Qt's C++ code, you'll be at liberty to combine the >>> first three above with whatever you like, including your favourite AI >>> engine. > > Phil Bouchard (27 April 2018 14:20) >> I'm just trying to help speeding up development here. > > It remains that you have failed to persuade folk on this list that > Fornux would in fact speed up development. That’s because: - I am putting the cart before the horse and I haven’t provided a trial version yet - The projects need to be reasonably complex to notice a divergence in development speed >>>> I think that’s much better than wasting your time supporting Python or >>>> Javascript that can be easily reverse engineered because of their >>>> interpreted nature. >>> >>> Your obsession with not being easy to reverse engineer suggests you >>> don't really understand the nature of Free Software; our source code is >>> publicly available, so who would need to reverse-engineer it ? >>> We gladly share it and save them the bother, > >> I'm referring to Qt's customers who wants to release commercial apps; >> they won't like to know part of their code can be deciphered. > > Well, first: copyright protects their work. The fact that someone else > can decipher it is incidental - even if they publish their source code, > no-one else can *use* that without their permission. Beyond that, as > long as the code runs on users' computers, some form or another of the > code is out there and the folk who are any good at reverse engineering > are going to discover its secrets, if they care to do so. Trying to > keep your implementation secret is consequently mostly pointless. - It’s always better to patent important algorithms - But outside North-America and Europe, companies do not care about copyrights and patents - That’s why there are tools to protect your software from being reverse engineered such as: https://www.intertrust.com/products/application-shielding/ >> Performance does play a role as well; you don't want to bottleneck the >> app with any garbage collector at all. > > Garbage collectors have their advantages and their costs; the principal > advantage is that developing in a garbage-collected language is > significantly easier (you have fewer irrelevancies to pay attention to), > which means a broader pool of authors can contribute - notably, those > who are good at UX/UI design aren't always also good at the finicky > details of keeping track of memory allocations. So garbage-collected > laguages tend to be good for rapid prototyping. That's good, because > you get to ship a useful (and useable) product sooner than your > competitors. > > Of course, the haphazard timing of garbage-collection runs can be an > issue, although many garbage-collected systems seem to manage this > without ever causing me annoyance (e.g. web browser ECMAScript engines, > most obviously). Java programs sporadically annoy me with this. I would then suggest GC languages should be optional and not mandatory. At the present time, QML forces us to use JS. > Still, with QML, you then have the option of moving the > performance-critical parts of the code (once the UX-competent developers > have prototyped it) from interpreted JavaScript to compiled C++. So you > get the advantages of rapid development and deployment, combined with > the ability to fix the performance issues that go with > garbage-collection. Python, similarly, lets one recode a module in C. > > Performance of your development team (getting a useful product to market > quickly) is at least as important as performance of your run-time > program: and, with an interpreted language layered on top of an engine > that you can augment in a compiled language, you can have both in > practice, Agreed. Regards, -Phil From edward.welbourne at qt.io Fri Apr 27 16:02:04 2018 From: edward.welbourne at qt.io (Edward Welbourne) Date: Fri, 27 Apr 2018 14:02:04 +0000 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , , Message-ID: Phil Bouchard (27 April 2018 15:36) > - It’s always better to patent important algorithms Those of us who believe in the freedom of ideas disagree. It is better to publish important algorithms, so that no-one else can patent them. > - But outside North-America and Europe, companies do not care about > copyrights and patents Even in Europe and North America, companies will get away with what they can. However, if they're copying your code in a reverse-engineerable language, reverse-engineering of their code will reveal the copying. > - That’s why there are tools to protect your software from being reverse > engineered such as: > https://www.intertrust.com/products/application-shielding/ I confess I have not looked at it. I am profoundly sceptical of its ability to be more than a speed-bump to the genuinely committed reverse engineer, just like DRM on music and movies. Copy-protection is pretty much always futile, if you're putting a copy into the hands of the user, no matter how much you obfuscate it. > I would then suggest GC languages should be optional and not mandatory. At > the present time, QML forces us to use JS. I believe it is entirely possible to write purely declarative QML, which makes no use of JS. By judicious use of C++ classes below the bonnet, you can get all the complexity of behaviour that JS would bring. However, you'll almost certainly get to this state faster by first prototyping in JS and then coding C++ classes to make the JS that leaves you with redundant. Eddy. From philippeb8 at gmail.com Fri Apr 27 18:22:39 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Fri, 27 Apr 2018 16:22:39 +0000 (UTC) Subject: [Development] Fornux C++ Superset References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> , , Message-ID: Edward Welbourne wrote: > Phil Bouchard (27 April 2018 15:36) >> - It’s always better to patent important algorithms > > Those of us who believe in the freedom of ideas disagree. It is better > to publish important algorithms, so that no-one else can patent them. Good point but I personally believe a balance between capitalism and socialism is the best approach because it’s a case by case situation. For example the military don’t want their code to be outsourced and competition in general speeds up development but “has been” word processors can definitely be outsourced. Also I did my fair amount of contributions to science with: - the root_ptr memory manager - the astrophysics theory currently being peer-reviewed by the “Monthly Notices of the Royal Astronomical Society” So having a commercial parser is natural. The Clang team encourages it. >> - But outside North-America and Europe, companies do not care about >> copyrights and patents > > Even in Europe and North America, companies will get away with what they > can. However, if they're copying your code in a reverse-engineerable > language, reverse-engineering of their code will reveal the copying. We don’t live in a perfect world and therefore all we can do is minimize the chances we get plagiarized, specially by some random hacker. >> - That’s why there are tools to protect your software from being reverse >> engineered such as: >> https://www.intertrust.com/products/application-shielding/ > > I confess I have not looked at it. I am profoundly sceptical of its > ability to be more than a speed-bump to the genuinely committed reverse > engineer, just like DRM on music and movies. Copy-protection is pretty > much always futile, if you're putting a copy into the hands of the user, > no matter how much you obfuscate it. > >> I would then suggest GC languages should be optional and not mandatory. At >> the present time, QML forces us to use JS. > > I believe it is entirely possible to write purely declarative QML, which > makes no use of JS. By judicious use of C++ classes below the bonnet, > you can get all the complexity of behaviour that JS would bring. > However, you'll almost certainly get to this state faster by first > prototyping in JS and then coding C++ classes to make the JS that leaves > you with redundant. Good to know. Regards, -Phil From tantrido at ya.ru Fri Apr 27 19:11:52 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Fri, 27 Apr 2018 19:11:52 +0200 Subject: [Development] Qt library link errors under Windows Message-ID: <1631061524849112@web57o.yandex.ru> Project builds just fine in Linux, however fails to link under Windows. Building with Qt 5.10.1 and MSVC 2015. 1st issue (solved) Solved here: https://stackoverflow.com/q/50064670/630169 -------------------------------------------------------------------------------------------------------------- 2nd issue: In the library .pro file VERSION variable is defined and resulting library has name MyLibrary1.lib. Thereafter I get error: :-1: error: LNK1181: cannot open input file 'MyLibrary.lib' What is better way to solve the problem here: remove VERSION or fix .pro file? How? -------------------------------------------------------------------------------------------------------------- 3rd issue: Another link error: mydialog.obj:-1: error: LNK2001: unresolved external symbol "struct QMetaObject const MyLibrary::staticMetaObject" (?staticMetaObject at MyLibrary@@3UQMetaObject@@B) Error happen because of the following line in code (disappears when commented out): ## mydialog.cpp: QMetaEnum myEnum = QMetaEnum::fromType(); ## mylibrary.cpp: namespace MyLibrary { Q_NAMESPACE enum class MYLIBRARYSHARED_EXPORT MyEnumClass { ... }; Q_ENUM_NS(MyEnumClass) ... } // namespace MyLibrary And how to solve the 3rd one? What is it: Qt or Windows (MSVC) bug? Code or link flags problem? Thanks! --  Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich From tantrido at ya.ru Fri Apr 27 22:19:38 2018 From: tantrido at ya.ru (Aleksey Kontsevich) Date: Fri, 27 Apr 2018 22:19:38 +0200 Subject: [Development] Qt library link errors under Windows In-Reply-To: <1974559.9RNg519nYO@tjmaciei-mobl1> References: <1631061524849112@web57o.yandex.ru> <1974559.9RNg519nYO@tjmaciei-mobl1> Message-ID: <269521524860378@web33g.yandex.ru> Thiago, Of course all these 1-5 points are followed as You can see visiting 1st mentioned link: https://stackoverflow.com/q/50064670/630169 https://stackoverflow.com/a/50064976/630169 Please take a look at the line which causes the link problem: QMetaEnum myEnum = QMetaEnum::fromType(); It happen only for combination: Q_NAMESPACE, Q_ENUM_NS(MyEnumClass), build under Windows. You may try it to build yourself under Windows to see the problem: https://github.com/akontsevich/ConnectedCreatorPlugin Thanks! :) --  Best regards, Aleksey Linked in https://www.linkedin.com/in/alekseykontsevich 27.04.2018, 21:18, "Thiago Macieira" : > Hello Aleksey > > None of your questions looks like problems in Qt itself, so I've taken the > liberty of replying to the interest mailing list (discussion about *using* > Qt). > > On Friday, 27 April 2018 10:11:52 PDT Aleksey Kontsevich wrote: >>  mydialog.obj:-1: error: LNK2001: unresolved external symbol >>  "struct QMetaObject const MyLibrary::staticMetaObject" >>  (?staticMetaObject at MyLibrary@@3UQMetaObject@@B) > > Make sure that: > > 1) class MyLibrary is in a header file > 2) that header file is listed in the library's .pro file HEADERS line > 3) moc was run in the header and the resulting output was compiled > 4) your definition contains an export macro: > >   class MY_LIBRARY_EXPORT MyLibrary : .... > > 5) said macro is __declspec(dllexport) when compiling the library and > __declspec(dllimport) when linking the library. This is "Windows DLL Basics" > and you need to learn it. > > -- > Thiago Macieira - thiago.macieira (AT) intel.com >   Software Architect - Intel Open Source Technology Center From Liang.Qi at qt.io Sat Apr 28 21:51:12 2018 From: Liang.Qi at qt.io (Liang Qi) Date: Sat, 28 Apr 2018 19:51:12 +0000 Subject: [Development] CI "wave-through" In-Reply-To: <1FD5F2C3-7520-4FB7-8193-36977F579BCA@qt.io> References: <1FD5F2C3-7520-4FB7-8193-36977F579BCA@qt.io> Message-ID: 5.11.0 is fine. Latest one is successful, https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525572833 But looks like there are issues in qt5 dev integration, please check https://codereview.qt-project.org/#/c/227670/ and https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525573813 . My proposal is switch qtdeclarative back to 913dc3f4f2be7c2c23237bcb9bffb3192cb10d60 . The new patch set PS5 is pushed there, and have a background build(status check) running, looks good by now. — Liang > On 27 Apr 2018, at 12:28, Tuukka Turunen wrote: > > > Hi, > > So we should probably restart https://codereview.qt-project.org/#/c/227410/ and re-run other qt5.git runs to make sure all tests are properly run in those? > > Yours, > > Tuukka > > From: Development on behalf of Sami Nurmenniemi > Date: Friday, 27 April 2018 at 13.06 > To: Simon Hausmann , "development at qt-project.org" > Cc: Qt CI > Subject: Re: [Development] CI "wave-through" > > Hi, > > > > Increasing the "non-zero change" there a bit, the "wave-through window" was from "25th of April 15:30 CET" to "27th of April 12:00 CET". > > > > Best Regards, > > Sami > > Lähettäjä: Development käyttäjän Simon Hausmann puolesta > Lähetetty: 27. huhtikuuta 2018 12:54:11 > Vastaanottaja: development at qt-project.org > Kopio: Qt CI > Aihe: [Development] CI "wave-through" > > Hi, > > > > Since yesterday afternoon around 15:30 central european time the CI has experienced a "failure" that resulted in each and all tests being skipped. So if a change broke the build, the CI would reject it. But if the change would normally result in a test failing, then the CI waved the change through regardless as it did not run any tests at all (apart from the BIC tests). > > > > The issue has been corrected as of a few minutes ago, but there is a non-zero chance that faulty changes may have slipped through and may result in test failures that are not related to changes you're trying to integrate. > > > > > > Simon > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From Simon.Hausmann at qt.io Sat Apr 28 22:36:10 2018 From: Simon.Hausmann at qt.io (Simon Hausmann) Date: Sat, 28 Apr 2018 20:36:10 +0000 Subject: [Development] CI "wave-through" In-Reply-To: References: <1FD5F2C3-7520-4FB7-8193-36977F579BCA@qt.io>, Message-ID: <2799E665-7B41-4676-9A78-DBF0F9797A62@qt.io> Hi, Yeah, declarative dev is busted. I’ll look into it on Monday. Meanwhile I support pinning to an older sha1 in qt5. Simon > On 28. Apr 2018, at 21:51, Liang Qi wrote: > > 5.11.0 is fine. Latest one is successful, https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525572833 > > But looks like there are issues in qt5 dev integration, please check https://codereview.qt-project.org/#/c/227670/ and https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525573813 . > > My proposal is switch qtdeclarative back to 913dc3f4f2be7c2c23237bcb9bffb3192cb10d60 . The new patch set PS5 is pushed there, and have a background build(status check) running, looks good by now. > > — Liang > >> On 27 Apr 2018, at 12:28, Tuukka Turunen wrote: >> >> >> Hi, >> >> So we should probably restart https://codereview.qt-project.org/#/c/227410/ and re-run other qt5.git runs to make sure all tests are properly run in those? >> >> Yours, >> >> Tuukka >> >> From: Development on behalf of Sami Nurmenniemi >> Date: Friday, 27 April 2018 at 13.06 >> To: Simon Hausmann , "development at qt-project.org" >> Cc: Qt CI >> Subject: Re: [Development] CI "wave-through" >> >> Hi, >> >> >> >> Increasing the "non-zero change" there a bit, the "wave-through window" was from "25th of April 15:30 CET" to "27th of April 12:00 CET". >> >> >> >> Best Regards, >> >> Sami >> >> Lähettäjä: Development käyttäjän Simon Hausmann puolesta >> Lähetetty: 27. huhtikuuta 2018 12:54:11 >> Vastaanottaja: development at qt-project.org >> Kopio: Qt CI >> Aihe: [Development] CI "wave-through" >> >> Hi, >> >> >> >> Since yesterday afternoon around 15:30 central european time the CI has experienced a "failure" that resulted in each and all tests being skipped. So if a change broke the build, the CI would reject it. But if the change would normally result in a test failing, then the CI waved the change through regardless as it did not run any tests at all (apart from the BIC tests). >> >> >> >> The issue has been corrected as of a few minutes ago, but there is a non-zero chance that faulty changes may have slipped through and may result in test failures that are not related to changes you're trying to integrate. >> >> >> >> >> >> Simon >> >> _______________________________________________ >> Development mailing list >> Development at qt-project.org >> http://lists.qt-project.org/mailman/listinfo/development > From kde at carewolf.com Sun Apr 29 11:00:24 2018 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Sun, 29 Apr 2018 11:00:24 +0200 Subject: [Development] CI "wave-through" In-Reply-To: References: <1FD5F2C3-7520-4FB7-8193-36977F579BCA@qt.io> Message-ID: <1882825.tO0sVR1ktC@twilight> On Samstag, 28. April 2018 21:51:12 CEST Liang Qi wrote: > 5.11.0 is fine. Latest one is successful, > https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525572833 > But looks like there are issues in qt5 dev integration, please check > https://codereview.qt-project.org/#/c/227670/ and > https://testresults.qt.io/coin/integration/qt/qt5/tasks/1525573813 . > My proposal is switch qtdeclarative back to > 913dc3f4f2be7c2c23237bcb9bffb3192cb10d60 . The new patch set PS5 is pushed > there, and have a background build(status check) running, looks good by > now. Pretty sure qtbase dev is also busted nothing is integrating anymore and all integrations fail with the same error, see https://codereview.qt-project.org/#/c/227814/ and https://codereview.qt-project.org/#/c/225146/ for instance From philippeb8 at gmail.com Mon Apr 30 06:16:40 2018 From: philippeb8 at gmail.com (Phil Bouchard) Date: Mon, 30 Apr 2018 00:16:40 -0400 Subject: [Development] Fornux C++ Superset In-Reply-To: References: <1675379.mWTH3mOQWM@tjmaciei-mobl1> <4388948.g8Bl6hTZpn@tjmaciei-mobl1> Message-ID: On 04/25/2018 11:35 PM, Phil Bouchard wrote: >> template >> void foo(int (&array)[N]) ? > > Since I just started testing C++98 as of last week, I haven't yet had a > chance to test templates thoroughly. So this one is buggy and I'll have > to fix it. I already fixed the problem. The following code: template void foo(T (&array)[S]) { cout << __PRETTY_FUNCTION__ << endl; } int main() { int array[10]; foo(array); return 0; } Now correctly outputs: void foo(const boost::node_proxy &, boost::root_array, 10> (&)) Regards, -Phil From alexander.blasche at qt.io Mon Apr 30 10:54:04 2018 From: alexander.blasche at qt.io (Alex Blasche) Date: Mon, 30 Apr 2018 08:54:04 +0000 Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP In-Reply-To: References: Message-ID: Congratulations to Oliver. The wiki was updated. -- Alex > -----Original Message----- > From: Development [mailto:development- > bounces+alexander.blasche=qt.io at qt-project.org] On Behalf Of Maurice > Kalinowski > Sent: Monday, 9 April 2018 14:18 > To: development at qt-project.org > Subject: [Development] Proposing Oliver Wolff as platform maintainer for UWP > > Hi, > > As some might have recognized my focus inside the Qt Company has shifted > from WinRT/UWP towards our Automation related offering. While I still review > many patches for this platform, my effort in terms of active development have > significantly reduced. > > Consequently, I would like to propose Oliver Wolff to take over the role as > platform maintainer. Oliver has been part of the team for years and (besides lots > of other things) has been taking care of the networking parts. In addition to > that, he has been "shadow-maintaining" the port over the last year, so this > would rather reflect reality. > > https://codereview.qt- > project.org/#/q/owner:%22Oliver+Wolff+%253Coliver.wolff%2540qt.io%253E% > 22,n,z > > BR, > Maurice > > P.S.: Perhaps he manages to get sufficient agreement to be mentioned on the > maintainer list, contrary to me when I took it over from Andrew :) > > -- > Maurice Kalinowski > Principal Software Engineer > > The Qt Company GmbH > Rudower Chaussee 13 > D-12489 Berlin > maurice.kalinowski at qt.io > http://qt.io > Geschäftsführer: Mika Pälsi, > Juha Varelius, Mika Harjuaho > Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB > 144331 B > > _______________________________________________ > Development mailing list > Development at qt-project.org > http://lists.qt-project.org/mailman/listinfo/development From thiago.macieira at intel.com Fri Apr 27 21:26:04 2018 From: thiago.macieira at intel.com (Thiago Macieira) Date: Fri, 27 Apr 2018 19:26:04 -0000 Subject: [Development] Qt library link errors under Windows In-Reply-To: <1631061524849112@web57o.yandex.ru> References: <1631061524849112@web57o.yandex.ru> Message-ID: <1974559.9RNg519nYO@tjmaciei-mobl1> Hello Aleksey None of your questions looks like problems in Qt itself, so I've taken the liberty of replying to the interest mailing list (discussion about *using* Qt). On Friday, 27 April 2018 10:11:52 PDT Aleksey Kontsevich wrote: > mydialog.obj:-1: error: LNK2001: unresolved external symbol > "struct QMetaObject const MyLibrary::staticMetaObject" > (?staticMetaObject at MyLibrary@@3UQMetaObject@@B) Make sure that: 1) class MyLibrary is in a header file 2) that header file is listed in the library's .pro file HEADERS line 3) moc was run in the header and the resulting output was compiled 4) your definition contains an export macro: class MY_LIBRARY_EXPORT MyLibrary : .... 5) said macro is __declspec(dllexport) when compiling the library and __declspec(dllimport) when linking the library. This is "Windows DLL Basics" and you need to learn it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center