Re: [Development] Question about tests/manual folders
On Friday, 20 September 2019 02:26:34 PDT Edward Welbourne wrote: > The qtbase/tests/manual/corelib/ tests all date back to 2013 (aside from > some copyright header updates). Some of them are actually much older: https://code.qt.io/cgit/qt/qt.git/tree/tests/manual The whole point of a manual test is for things that can't be reliably tested in an automated way. Take two examples: QSysInfo and QStorageInfo. There are some aspects of both classes that can be tested in an automated way, like the consistency of results, but most of it can't. So we have manual test tools that allow us to quickly get all the output from those classes and see if there's something unexpected, compared to other tools and system configuration. Ditto for highdpi. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] INTEGRITY
Hi, Documentation is the authorative source. It is maintained and checked for each Qt release. We should make sure the platform notes are correct and complete. Misleading information in wiki should be deleted or marked as deprecated. Similar activity has been done to other pages, sometimes we may even want to move items from the wiki to docs. It is fine to have wiki to support, but there is high risk of wiki content to become outdated. Yours, Tuukka On 20/09/2019, 12.03, "Development on behalf of Giuseppe D'Angelo via Development" wrote: Il 20/09/19 07:53, Tuukka Turunen ha scritto: > Or remove the wiki entry and make sure platform notes in documentation are in shape? > > No need for duplicated info on these basic items. It's a bigger problem -- the *same* wiki is used for official information (e.g. releasing info; coding guidelines; security policies) as well as for unofficial, community-driven content. Nobody knows the official status of any individual page just by looking at it. So now there's information on the wiki AND in the docs about Qt on INTEGRITY, they both appear on Google search results, and of course they're in contradiction with each other (wiki says that Qt on INTEGRITY is community-driven, docs say it's officially supported; wiki does a shared build, docs say only static builds work). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Question about tests/manual folders
Asmo Saarela (20 September 2019 08:30) > I would like to understand the content and the use of the manual test assets > in the Qt modules. > Could you provide a few examples of how you are using, maintaining, and > developing those? The qtbase/tests/manual/corelib/ tests all date back to 2013 (aside from some copyright header updates). They look suspiciously like they could be automated - I haven't studied them closely (or tried running them) but they look like crash-tests. I can't think of any reason why any container in corelib/tools/ (which is what they all test) would need a manual test. Perhaps their author, Thorbjørn Martsum, is still about and can comment; or someone else might know these tests better. Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] INTEGRITY
Il 20/09/19 07:53, Tuukka Turunen ha scritto: Or remove the wiki entry and make sure platform notes in documentation are in shape? No need for duplicated info on these basic items. It's a bigger problem -- the *same* wiki is used for official information (e.g. releasing info; coding guidelines; security policies) as well as for unofficial, community-driven content. Nobody knows the official status of any individual page just by looking at it. So now there's information on the wiki AND in the docs about Qt on INTEGRITY, they both appear on Google search results, and of course they're in contradiction with each other (wiki says that Qt on INTEGRITY is community-driven, docs say it's officially supported; wiki does a shared build, docs say only static builds work). My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@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 smime.p7s Description: Firma crittografica S/MIME ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] INTEGRITY
On Fri, 20 Sep 2019 at 10:10, Allan Sandfeld Jensen wrote: > I am pretty sure we strongly depend on some of those features now. > Realistically I don't think we support any compiler older than what the CI > tests for which I believe is GCC 4.9. Close enough, 4.8. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Question about tests/manual folders
> -Original Message- > From: Development On Behalf Of > Asmo Saarela > Sent: Friday, 20 September 2019 8:30 AM > To: development@qt-project.org > Subject: [Development] Question about tests/manual folders > > Hi all, > > > > I would like to understand the content and the use of the manual test assets > in the Qt modules. > > Could you provide a few examples of how you are using, maintaining, and > developing those? > > > > It seems that there are some 439 folders related to the manual tests in the > repositories: /tests/manual/* > > > > When are you executing these manual tests? What do you do with the > information from the test execution? In qtquickcontrols2: - buttons - similar to testbench but specifically for buttons. - fonts - shows how changing font sizes affects controls. - gifs - simulates events on controls and records them (on Linux) as GIFs for use in documentation. - screenshots - allows loading code snippets from the doc directory to take screenshots of them for use in documentation. - styles - used for the screenshots of each style on this page: https://doc.qt.io/qt-5/qtquickcontrols2-styles.html - systemtrayicon - tests that system tray icons work. - testbench - quickly checking that all controls in various states look and function as expected. I used it quite a lot when working on the Imagine style, for example. - viewinqwidget - tests controls with QQuickWidget. I haven't used the fonts, systemtrayicon and viewinqwidget tests before, or don't use them very often, but can see how they'd be useful. The gifs, screenshots and styles tests are used whenever doc images need to be added or updated. The buttons and especially testbench tests I have used before and will use again. > > > Best regards, Asmo Saarela > > Test Lead ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] INTEGRITY
On Friday, 20 September 2019 00:07:38 CEST Thiago Macieira wrote: > On Thursday, 19 September 2019 03:17:12 PDT Giuseppe D'Angelo via > Development > wrote: > > On 18/09/2019 17:33, Thiago Macieira wrote: > > >>> We've never required C++11 Standard Library. We've only required the > > >>> core > > >>> language and the integrity compiler does support it just fine. > > >> > > >> Not really, it also fails on constexpr: > > >> > > >> https://codereview.qt-project.org/c/qt/qtbase/+/264550 > > > > > > No, it has a bug in its existing constexpr implementation. That's > > > different. MSVC 2015 officially supported constexpr, but we turned it > > > off > > > for them because it was too buggy. > > > > it still means that we can't require core language > > conformity from our compilers. And we're talking about C++11's > > constexpr, not C++14's. > > I've just checked our changelogs and we've never raised the minimum version > of GCC from 4.7. That means we can't officially depend on anything that GCC > 4.8 added to the Core Language. They are: > > - attributes > - alignas & alignof > - inheriting constructors > - thread_local > - ref qualifiers (4.8.1) > > Attributes is a non-issue because we have __has_cpp_attribute / > QT_HAS_ATTRIBUTE so we end up with macros for most attributes anyway. > Alignas and alignof are also non-issues because they're rare enough. > I am pretty sure we strongly depend on some of those features now. Realistically I don't think we support any compiler older than what the CI tests for which I believe is GCC 4.9. Allan ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
