Re: [Development] File Selectors API, still for 5.1?
Whoops, re-sending to dev... On Tue, Mar 26, 2013 at 1:38 PM, Alan Alpert <4163654...@gmail.com> wrote: > On Tue, Mar 26, 2013 at 12:32 AM, Stephen Kelly > wrote: >> On Monday, March 25, 2013 18:19:57 Alan Alpert wrote: >>> More time to iterate is always welcomed. This may lead to a >>> source-incompatible change in Plasma Packages though, ideally we'd >>> only do that once with the existing incompatible change of KDE >>> Frameworks 5. Would that be using the 5.1 or 5.2 APIs? >> >> KDE Frameworks 5 will use the qt5.git dev branch until that has the features >> it needs. KDE won't release plasma+frameworks5 on top of Qt 5.1 because it >> doesn't have the required features. >> >> Whether Qt 5.2 will have all required features remains to be seen. The todo >> list is long: http://community.kde.org/Frameworks/Epics/Qt_5.1_Merging and >> even that list is only 'things needed in Qt before a release can be made'. >> The >> list of 'things to do in the KDE libraries before we can release' is also a >> long one. >> >> So, don't worry about release-timing relating to this issue. Whenever this >> feature reaches the qt5.git dev branch, the plasma developers can start using >> it in parallel development. Oh good. I misread that page as "aiming to release on top of 5.1". >>> BlackBerry has run into performance issues reading from the >>> filesystem, but it's still not something to worry about until an API >>> is sorted out. >> >> Those problems were solved already, right? > In general, yes. But I'm still not happy with the costs of unnecessary file access in the QML engine so I've been working on reducing those (it's not a BlackBerry specific performance cost or fix, it's just one that's been noticed by BlackBerry apps). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] File Selectors API, still for 5.1?
On Tue, Mar 26, 2013 at 11:04 AM, Thiago Macieira wrote: > On segunda-feira, 25 de março de 2013 10.42.27, Alan Alpert wrote: >> > This is not good enough a reason. Any new feature can only be accepted in >> > *dev* once it's complete: that is, it is there, works, unit-tested, >> > documented, with examples if necessary, and an initial API review has been >> > done. If your feature is still discussing the class name, it indicates >> > that >> > the initial API review is not concluded. >> >> I got the impression that the initial API review was done. Then >> someone brought up that they didn't like the name... > > Ok, that sounds more like nitpicking. We can always rename a class before it's > released. That doesn't stop the integration, though, if everything else is > fine. > > Unfortunately, the rest of the email thread doesn't lead me to believe that it > is. > >> >> 2) What to call it? >> >> Oswald suggested "QPathSelector. or QPathSwitch[er]. or >> >> QPathMultiplexer." I'm still leaning towards QFileSelectors, but I'd >> >> also be happy with Q[File|Path]Switcher or QPathMultiplexer. I know >> >> that everyone has an opinion on naming matters, is there something >> >> even better that we haven't thought of yet? >> > >> > Explain here in a few words what the class is meant to do and how it does >> > that. That's two things I'm asking for: what and how. The name should come >> > from one or both. >> >> Applies selectors to file paths. Hence QFileSelectors (QPathSelectors >> maybe). > > What is a selector? Maybe I should just read the documentation... > > "QFileSelectors provides a convenient way of selecting file variants based > on platform or device characteristics." > > (BTW, the docs are missing the \brief) > > "Multiplexer" is too complex a term. "Switcher" gives the impression that you > can switch it -- as in switching from Android to iOS to QNX. That doesn't look > right to me. So "Selector" is better -- singular since it's what the class > does, not that it applies "selectors" to the name. Okay, maybe I'm too close to the issue. I'll rename it QFileSelector (and add the \brief). -- Alan Alpert ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On terça-feira, 26 de março de 2013 14.07.56, Sergio Ahumada wrote: > As far as I understand, the CI is all in Finland, so GMT +2. In other words, the tests are effectively disabled. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] File Selectors API, still for 5.1?
On segunda-feira, 25 de março de 2013 18.19.57, Alan Alpert wrote: > tl;dr -> Okay, let's make it private for 5.1 (also works for > BlackBerry) and aim to polish it for 5.2. Maintainer agrees. Go for it. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] File Selectors API, still for 5.1?
On segunda-feira, 25 de março de 2013 10.42.27, Alan Alpert wrote: > > This is not good enough a reason. Any new feature can only be accepted in > > *dev* once it's complete: that is, it is there, works, unit-tested, > > documented, with examples if necessary, and an initial API review has been > > done. If your feature is still discussing the class name, it indicates > > that > > the initial API review is not concluded. > > I got the impression that the initial API review was done. Then > someone brought up that they didn't like the name... Ok, that sounds more like nitpicking. We can always rename a class before it's released. That doesn't stop the integration, though, if everything else is fine. Unfortunately, the rest of the email thread doesn't lead me to believe that it is. > >> 2) What to call it? > >> Oswald suggested "QPathSelector. or QPathSwitch[er]. or > >> QPathMultiplexer." I'm still leaning towards QFileSelectors, but I'd > >> also be happy with Q[File|Path]Switcher or QPathMultiplexer. I know > >> that everyone has an opinion on naming matters, is there something > >> even better that we haven't thought of yet? > > > > Explain here in a few words what the class is meant to do and how it does > > that. That's two things I'm asking for: what and how. The name should come > > from one or both. > > Applies selectors to file paths. Hence QFileSelectors (QPathSelectors > maybe). What is a selector? Maybe I should just read the documentation... "QFileSelectors provides a convenient way of selecting file variants based on platform or device characteristics." (BTW, the docs are missing the \brief) "Multiplexer" is too complex a term. "Switcher" gives the impression that you can switch it -- as in switching from Android to iOS to QNX. That doesn't look right to me. So "Selector" is better -- singular since it's what the class does, not that it applies "selectors" to the name. > > As I told you on IRC, I'd like you to give me one use-case or example of > > the new API being used for something completely and entirely > > non-graphical, like translations. If you can come up with an example, > > then I'll have no objections of it belonging to QtCore. It can be with an > > imagined future extension to the API too. > > > > That doesn't mean that it must move if you can't find a good example. > > The examples in the API docs switched to locale and platform. They no > longer reference graphical assets. You could use this for locale > related data to store it alongside translations, or you could use it > for platform-specific assets for a consistent file structure. > > There are future imagined uses of tooling support where the tools > (like QtCreator) make cross-platform development easier by combining > this and a platform specific data url (like androids asset://) so that > you have a readable directory structure when developing, both on > desktop and on device, but for final deployment QRC files are built > automatically and the appropriate one is dynamically loaded. With that > level of convenience, file selectors would likely replace #ifdefs for > loading platform specific data in non-graphical situations. Ok, then I agree the class belongs in QtCore. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
> > It fails for me, too; the tests are off by 1 hour, it seems. > > This is indeed a mystery. Is the CI in a "European" timezone? > > > > the CI log shows: > > -- > Testing tst_QDateTime > Totals: 350 passed, 0 failed, 34 skipped > -- > > for all the windows configurations (mingw47 and mscv2010 on Win7; > msvc2012 on Win8). > > As far as I understand, the CI is all in Finland, so GMT +2. > This test contains a number of test cases that are only run if the local timezone is CET. They are silently skipped otherwise (test rows not added, rather than QSKIP) It certainly used to fail around the times of year that DST changes happen, when the CI was in Oslo. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise confidential information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the e-mail by you is prohibited. Where allowed by local law, electronic communications with Accenture and its affiliates, including e-mail and instant messaging (including content), may be scanned by our systems for the purposes of information security and assessment of internal compliance with Accenture policy. __ www.accenture.com ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] staging in qt dev branches temporarily disabled
On terça-feira, 26 de março de 2013 15.30.42, David Faure wrote: > > correct (though, if it really is a performance *fix*, you should > > consider 5.1/stable). > > Well, performance *improvements*. > > AFAIU these should go into dev, because of the higher risk of regressions. Depends on the change. It's up to the contributor and reviewers to decide whether the change is too complex for stable. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] staging in qt dev branches temporarily disabled
On Tuesday 26 March 2013 14:25:35 Oswald Buddenhagen wrote: > On Tue, Mar 26, 2013 at 01:30:26PM +0100, David Faure wrote: > > On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote: > > > the "lock" can be removed on friday evening, i think. at least i hope > > > all integrations are done and everyone got that by this time. > > > > Now that all modules have had dev merged into stable, could the lock be > > removed? > > yes, removed now. let's hope everyone got the correct branches now. Thanks! > > "dev" is Qt 5.2 now, so new features (or performance fixes, for instance) > > should be fine, right? > > correct (though, if it really is a performance *fix*, you should > consider 5.1/stable). Well, performance *improvements*. AFAIU these should go into dev, because of the higher risk of regressions. -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] staging in qt dev branches temporarily disabled
On Tue, Mar 26, 2013 at 01:30:26PM +0100, David Faure wrote: > On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote: > > the "lock" can be removed on friday evening, i think. at least i hope > > all integrations are done and everyone got that by this time. > > Now that all modules have had dev merged into stable, could the lock be > removed? > yes, removed now. let's hope everyone got the correct branches now. > "dev" is Qt 5.2 now, so new features (or performance fixes, for instance) > should be fine, right? > correct (though, if it really is a performance *fix*, you should consider 5.1/stable). ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
On 03/26/2013 01:48 PM, Friedemann Kleint wrote: > Hi, > > > tst_qdatetime on Windows with a European time zone throws up 8 > failures for > > me on a clean build without my changes. Does this happen for anyone > else? Is > > this test disabled in CI, because I don't see how anything could be > passing > > otherwise? > > It fails for me, too; the tests are off by 1 hour, it seems. > This is indeed a mystery. Is the CI in a "European" timezone? > the CI log shows: -- Testing tst_QDateTime Totals: 350 passed, 0 failed, 34 skipped -- for all the windows configurations (mingw47 and mscv2010 on Win7; msvc2012 on Win8). As far as I understand, the CI is all in Finland, so GMT +2. Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] Change Logs for Qt 5.0.2
Hi, I've pushed (and merge) most of the changelogs for 5.0.2 release. The only missing one (in terms of completeness) is the one from qtbase.git So please (Maintainers in particular) go and check that all the changelogs are correct and fill up the missing bit and pieces for qtbase.git - https://qt.gitorious.org/qt/qtactiveqt/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtbase/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtdeclarative/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtdoc/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtgraphicaleffects/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtimageformats/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtmultimedia/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtquick1/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtscript/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtsvg/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qttools/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtwebkit-examples-and-demos/blobs/release/dist/changes-5.0.2 - https://qt.gitorious.org/qt/qtxmlpatterns/blobs/release/dist/changes-5.0.2 Cheers, -- Sergio Ahumada Release Engineer - Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Status of QTimeZone
Hi, > tst_qdatetime on Windows with a European time zone throws up 8 failures for > me on a clean build without my changes. Does this happen for anyone else? Is > this test disabled in CI, because I don't see how anything could be passing > otherwise? It fails for me, too; the tests are off by 1 hour, it seems. This is indeed a mystery. Is the CI in a "European" timezone? Regards, Friedemann -- Friedemann Kleint Digia, Qt ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [IMPORTANT] staging in qt dev branches temporarily disabled
On Wednesday 20 March 2013 15:53:38 Oswald Buddenhagen wrote: > the "lock" can be removed on friday evening, i think. at least i hope > all integrations are done and everyone got that by this time. Now that all modules have had dev merged into stable, could the lock be removed? "dev" is Qt 5.2 now, so new features (or performance fixes, for instance) should be fine, right? -- David Faure | david.fa...@kdab.com | Managing Director KDAB France KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-independent software solutions ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Updating third-parties
> qtbase: > Freetype (*) https://codereview.qt-project.org/#change,52240 + https://codereview.qt-project.org/52241 Konstantin ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] File Selectors API, still for 5.1?
On Monday, March 25, 2013 18:19:57 Alan Alpert wrote: > More time to iterate is always welcomed. This may lead to a > source-incompatible change in Plasma Packages though, ideally we'd > only do that once with the existing incompatible change of KDE > Frameworks 5. Would that be using the 5.1 or 5.2 APIs? KDE Frameworks 5 will use the qt5.git dev branch until that has the features it needs. KDE won't release plasma+frameworks5 on top of Qt 5.1 because it doesn't have the required features. Whether Qt 5.2 will have all required features remains to be seen. The todo list is long: http://community.kde.org/Frameworks/Epics/Qt_5.1_Merging and even that list is only 'things needed in Qt before a release can be made'. The list of 'things to do in the KDE libraries before we can release' is also a long one. So, don't worry about release-timing relating to this issue. Whenever this feature reaches the qt5.git dev branch, the plasma developers can start using it in parallel development. > BlackBerry has run into performance issues reading from the > filesystem, but it's still not something to worry about until an API > is sorted out. Those problems were solved already, right? Thanks, -- Stephen Kelly | Software Engineer KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company www.kdab.com || Germany +49-30-521325470 || Sweden (HQ) +46-563-540090 KDAB - Qt Experts - Platform-Independent Software Solutions signature.asc Description: This is a digitally signed message part. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
