Re: [Development] Resizing borders for dock widgets
On 2023-02-18 13:42, Axel Spoerl via Development wrote: Hi David, The margin for recognizing a mouse resize is handled by the window manager, hence not controlled by Qt. (...) That depends if the QDockWidget is using native decorations or not, see [1]. When not using native decos, Qt::FramelessWindowHint is used and resizing is done via QWidgetResizeHandler, which has 4px of margin [2], but I think only inwards, since if the mouse is outside the window won't receive the event. Maybe needs mouse grab. [1] - https://codebrowser.dev/qt5/qtbase/src/widgets/widgets/qdockwidget.cpp.html#299 [2] - https://codebrowser.dev/qt5/qtbase/src/widgets/widgets/qwidgetresizehandler.cpp.html#_M/RANGE Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CMake UNITY_BUILD ( QTBUG-109394 )
On 2023-01-23 14:25, Jörg Bornemann via Development wrote: (...) One ugliness I've noticed: CMAKE_UNITY_BUILD is documented to not play well with CMAKE_EXPORT_COMPILE_COMMANDS. This might hurt users of clangd (using clangd with Qt's sources). Yes, but probably you won't be developing with CMAKE_UNITY_BUILD, since it ruins incremental build times anyway. It's great for compiling 3rdparty and any module you're *not* developing. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Compilation Speed
On 2022-01-03 13:40, Lars Knoll wrote: (...) One other possible solution to improve compile times is the hack we used 15 years ago in KDE, where we grouped many .cpp files into one compilation unit. There’s however a balance needed here, as it reduces the efficiency of -j, but maybe compiling 4-8 .cpp files as one unit could help. Hello Lars, "unity builds" were added to CMake by Christian Adam, you should read your company blog :D It seems to adjust the size of the amalgamations so all your CPU cores are still used. The results are astonishing, clazy builds almost 100% faster. However, clazy does use a lot of LLVM headers, which are known to be slow to compile. So your mileage will vary. It does make incremental builds slower, as then you need to recompile the entire amalgamation. For this reason I don't think it's a silver bullet. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt Compilation Speed
On 2022-01-03 08:43, Marc Mutz wrote: Hi, The Qt Creator folks have noted that compilation of Qt projects against Qt 6.2 is sometimes almost twice as slow as it was in 5.15: https://bugreports.qt.io/browse/QTBUG-97601 While we have some ideas where this may come from (including more std headers, qmetatype compile-time typename construction, qglobal.h becoming larger and larger), most of these should be fixed by PCH, yet PCH builds are also slower. The questions that we face now are a) do we care and b) if we do, then what metrics should we use to define success? Hi Marc, Better first check what the problem is. You can use "clang -ftime-trace" [1] or Microsoft's own thing [2] Both were easy to use and helped for customer project's build times. [1] https://aras-p.info/blog/2019/01/16/time-trace-timeline-flame-chart-profiler-for-Clang/ [2] https://devblogs.microsoft.com/cppblog/introducing-c-build-insights/ Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QThread::create mandatory in Qt 6?
On 2020-11-18 07:34, Oliver Wolff wrote: Hi On 16/11/2020 23:29, Sérgio Martins via Development wrote: On 2020-11-16 21:57, Thiago Macieira wrote: On Monday, 16 November 2020 13:38:06 PST Cristian Adam wrote: LLVM.org clang.exe binary reports the x86_64-pc-windows-msvc target, which is Clang/MSVC. clang-cl is just a different command line options parser, which always sets the *-msvc target. Clang/MinGW is something that ends up in *-gnu as target. That's the case for winlibs and llvm-mingw. I see, thanks. So, what's wrong with llvm-mingw? Probably the prebuilt toolchain Tony is using (WinLibs) has an old standard library. The problem is not specific to Clang perse. But why do we want clang-MinGW to begin with ? MinGW is niche as it is. I don't see anyone wanting this combo. clang-MSVC on the other hand is useful as it means a better compiler frontend (clang) using a better standard library on Windows (msvc). As far as I know, people *do* want an open alternative that does not involve Microsoft software. That's where mingw comes into play. I agree we want MinGW, but we already have it in the CI (gcc-mingw). clang-mingw won't add much value, as it overlaps a lot with the existing gcc-mingw. clang-cl.exe however has a bigger delta over cl.exe. As we cannot support an unlimited amount of configurations, it looks like we will go the clang-mingw route instead of clang-msvc. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QThread::create mandatory in Qt 6?
On 2020-11-16 21:57, Thiago Macieira wrote: On Monday, 16 November 2020 13:38:06 PST Cristian Adam wrote: LLVM.org clang.exe binary reports the x86_64-pc-windows-msvc target, which is Clang/MSVC. clang-cl is just a different command line options parser, which always sets the *-msvc target. Clang/MinGW is something that ends up in *-gnu as target. That's the case for winlibs and llvm-mingw. I see, thanks. So, what's wrong with llvm-mingw? Probably the prebuilt toolchain Tony is using (WinLibs) has an old standard library. The problem is not specific to Clang perse. But why do we want clang-MinGW to begin with ? MinGW is niche as it is. I don't see anyone wanting this combo. clang-MSVC on the other hand is useful as it means a better compiler frontend (clang) using a better standard library on Windows (msvc). Friedmann also mentions "We want clang.cl only (as discussed many times already)." (QTQAINFRA-2139) Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QThread::create mandatory in Qt 6?
On 2020-11-15 16:29, Thiago Macieira wrote: On Sunday, 15 November 2020 04:34:49 PST Kevin Kofler via Development wrote: Thiago Macieira wrote: > At least one platform -- not a main one -- will stop working. IMHO, it would be useful in such cases to specify which platform you are talking about, so others can get a better picture of: * whether the change affects them personally, * how many affected users we are talking about, and most importantly clang-cl How is clang-cl broken if it uses the same std library as MSVC ? QTBUG-88392 is about clang/MinGW, not clang/MSVC Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Clang-based refactoring to Qt 6 (Proposal: Deprecate QVector in Qt 6)
On 2020-04-23 14:55, Thiago Macieira wrote: On Thursday, 23 April 2020 05:25:33 PDT Vitaly Fanaskov wrote: Provide clang-based tools to (semi-)automatically port users' code bases to a new version of Qt. These tools might either fix a code or at least add a comment in potentially problematic places where a user should correct the code. A developer who changes API should also implement a rule for these tools. This was discussed in a QtCS two or three years ago. There are two huge problems with that: 1) Clang cannot compile all Qt-using codebases. Therefore, its tooling cannot work in all cases either. This is less of a problem nowadays, where clang can even be a drop-in replacement for MSVC. Embedded requires hacked mkspecs though (QNX for example). 2) No one has volunteered to write such conversion scripts. And a minor (3) is that automatic conversions seldom look nice and will require manual retouching anyway. Specially when talking about QList -> QVector, as QVector doesn't guarantee the stability of references due to reallocation. Tooling could still flag the places where you're taking references so you can do a manual verification though. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 2020-02-28 18:32, Thiago Macieira wrote: On Friday, 28 February 2020 07:28:34 PST Matthew Woehlke wrote: If we had to do it over again, it might make sense to follow Python and make signals *objects* instead of *methods*. Then the code would look like: this->emptied.emit(...); Binary compatibility issue: if it's a member of the class, it can't be added or removed without changing the class's size and layout, so it would tie our hands for future improvements. You'd see instead: this->emptied().emit(...); connect(foo, foo->emptied(), ...); I like this, then we could finally (and without hacks) have protected and private signals like in Qt 4. Would also solve the need for qOverload ? Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 2020-02-21 13:00, Ville Voutilainen wrote: On Fri, 21 Feb 2020 at 14:58, Sérgio Martins wrote: > Why do I need to know that it's a signal being emitted? How is that > "vital information"? I could just as well > invoke any other callback, but I find myself not exactly yearning for > being able to write > callback somethingHappened(); Signals have different semantics than regular functions. In what way? If I'm reading the body of makePlane() I can ignore the signal emissions, as they aren't important for how a plane is made, they just inform whoever is listening. That doesn't seem to be correct in general. Some signals absolutely must be emitted for clients to work correctly. Signals in the public interface of a self-contained class are not important to understand the implementation of said class. Example: https://code.woboq.org/qt5/qtbase/src/widgets/widgets/qabstractslider.cpp.html#_ZN15QAbstractSlider17setSliderPositionEi When reading what QAbstractSlider::setSliderPosition() does, I won't check which slots "emit sliderMoved" triggers, but I will step into triggerAction(SliderMove); I'm sure you can find counter-examples where the triggered slot does something very important for the class that's emitting, I wouldn't call it self-contained though. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] A modest proposal: disable lower-case keywords (emit, foreach, forever, signals, slots) by default
On 2020-02-21 12:41, Ville Voutilainen wrote: On Fri, 21 Feb 2020 at 14:30, Mitch Curtis wrote: > > without any annotation is not what we want. We'd miss vital information > and reduce readability. > Can you please explain what that vital information is? How can you tell if it's a signal being emitted or just a function call without the emit syntax? With the emit syntax before the signal emission, it's immediately obvious that it's a signal. Not all signals follow the *Changed() naming convention, nor should they, so it becomes even less obvious in those cases. Why do I need to know that it's a signal being emitted? How is that "vital information"? I could just as well invoke any other callback, but I find myself not exactly yearning for being able to write callback somethingHappened(); Signals have different semantics than regular functions. If I'm reading the body of makePlane() I can ignore the signal emissions, as they aren't important for how a plane is made, they just inform whoever is listening. And I'd argue that the emitter shouldn't even know who or how many slots are connected to the signal, might even be zero, it shouldn't matter. If you really need to execute a piece of code, call a normal function, don't emit a signal. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5.14 MinGW debug build doesn't add debug suffix
On 2020-01-07 12:52, Roland Winklmeier wrote: Second, I switched my nightly build to 5.14 branch and was building debug binaries as usual. Configure arguments: configureArguments=-developer-build -debug -opensource -nomake examples -nomake tests -confirm-license -opengl desktop -dbus -openssl -I D:\Downloads\openssl-1.1.1d-win32-mingw/include The config summary seems to agree with me Build options: Mode ... debug; optimized tools however, the binaries don't have the typical debug suffix: $ ls Qt5* Qt5Core.dll* Wondering if there's a reason why the suffix is needed in the first place... I thought only MSVC had problems mixing debug and release runtimes. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QT_GCC_MAJOR_VERSION and building with clang...
On 2019-12-06 16:42, René J.V. Bertin wrote: Hi, (...) This was after I got this error from an attempt to build QtWebEngine 5.12.6 with /usr/bin/c++ which points to GCC 8: So you're building QtWebEngine with GCC 8 while Qt was built with clang mkspec ? ``` Using gcc version 4.2, but at least gcc version 5 is required to build Qt WebEngine. QtWebEngine will not be built. ``` Anyway, FWIW, I've built QtWebEngine with clang 8.0 + linux-clang mkspec not too long ago and it worked fine. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Removing overloaded signals in Qt6
On 2019-11-29 08:15, Ville Voutilainen wrote: On Wed, 27 Nov 2019 at 17:52, Sérgio Martins via Development wrote: (...) I suggest we rename such signals, as KDE is already doing for KF6 (maybe leave the old signatures there, to reduce Qt6 SIC) There's also a new clazy check 'overloaded-signal' to help finding them. (...) Any thoughts on overloaded slots, or overloaded member functions as slot-targets? The latter are a tad harder to diagnose. slots are a different case, since you can simply connect to a lamdba that calls the slot. Which is already what you do when the slot arguments don't match, too. Another difference is that many slots are setters. Renaming setters starts to feel weird. So I would leave the slots alone. List of overloaded stuff in qtbase: slots: https://paste.ubuntu.com/p/5q2n9r3F5D/ signals: https://paste.ubuntu.com/p/cSd9hVPb9Z/ Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
[Development] Removing overloaded signals in Qt6
Hi, The Qt5 PMF connect syntax is wonderful and very elegant compared to Qt 4. Unless, ofc, you have overloaded signals, which makes it painful to write and read. Not even qOverload makes it look much better. I suggest we rename such signals, as KDE is already doing for KF6 (maybe leave the old signatures there, to reduce Qt6 SIC) There's also a new clazy check 'overloaded-signal' to help finding them. Relevant bug report: QTBUG-47225 I know there are downsides, but keeping things as they are is just worse. Signals and slots are the bread of butter of Qt. Syntax for overloading signals is just too much of a barrier for new-comers, who currently aren't even able to connect a QComboBox without much hassle. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] HEADS-UP: QStringLiteral
On 2019-08-20 16:56, Bogdan Vatra via Development wrote: Hi, Isn't silly to have so many wrappers around a such a simple thing as strings? All the major frameworks out there (i.e. Java, C#) they have a single String which does all the magic. We do have a single one that does all the magic: QString. A Qt user can ignore all others. The difference between Qt and Java or C# is that we also offer non-allocating alternatives for users who care. And if they care, they need to learn them. For the case that triggered this discussion, the androiddeployqt executable, I wouldn't bother with optimizations and just use what's more readable, even raw strings. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] is it possible to increase the max. document size for the JSON parser?
On 2019-08-06 22:49, Sérgio Martins via Development wrote: On 2019-08-06 13:48, René J. V. Bertin wrote: Joerg Bornemann wrote: Unfortunately, this isn't possible at the moment. This issue is tracked in QTBUG-47629. Thanks, I'll try the patch! Can you also check how much memory is occupied by reading that 100 MB file ? My memory is hazy but I think it was several GBs. I looked at it again and the test-case was flawed, it was using unneeded QStrings and QString::toUtf8(). By reading directly from the file heaptrack now reports only 300 MB peak. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] is it possible to increase the max. document size for the JSON parser?
On 2019-08-06 13:48, René J. V. Bertin wrote: Joerg Bornemann wrote: Unfortunately, this isn't possible at the moment. This issue is tracked in QTBUG-47629. Thanks, I'll try the patch! Can you also check how much memory is occupied by reading that 100 MB file ? My memory is hazy but I think it was several GBs. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposing CMake as build tool for Qt 6
On 2019-06-15 07:45, Bogdan Vatra via Development wrote: Hi, În ziua de joi, 13 iunie 2019, la 18:22:14 EEST, Thiago Macieira a scris: On Thursday, 13 June 2019 01:06:06 PDT Bogdan Vatra via Development wrote: > Hi, > > There is one more missing feature to add to your list: build & debug > > builds for msvc in one go (same as qmake does now, a single "make" command > will build both targets). I wouldn't call that a hard requirement. Separate builds for debug and for release are acceptable, the same way that we've ostensibly had support for shared-and-release builds but in practice they're always built separately. The only difficult part I see is enforcing the suffix. On Mac we've had problems with this, since a debug-only build is un-suffixed. Maybe it's time to rethink the strategy and make the suffix optional altogether (using the lib infix feature). On Windows, we should stop enforcing that unoptimised builds be -MDd and make it easy for people to debug into -MD libraries. Hardly anyone ever debugs into Microsoft's libraries... I think libs built with -MDd are a must to enable debug builds for your application. AFAIK (if I'm wrong I apologize) you can't mix debug apps with release libs. So, as long as we need to provide libs, (qml) plugins for debug & release I think building them in one go is a must have feature. Depends what you mean by "debug build". The current definition of "debug" for MSVC Qt is: 1) Unoptimized (via /O flags) 2) Has debug symbols 3) Links to another c++ runtime library, which lets you debug into (/MDd). (And this is what prevents you from mixing release Qt with debug app) The idea above would be to drop 3). On linux you don't link to a debug libstdc++ either and you don't complain :) But there might be problems: - cmake -DCMAKE_BUILD_TYPE=Debug means /MDd ? - The _DEBUG macro currently comes from /MDd, some users might be using it to detect debug builds. - MDd is useful to enable asserts in the C++ library. This argument is strong on Windows, as you don't have valgrind there (or at least an equivalent that doesn't suck too much). Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
On 2019-05-25 21:55, Bernhard Lindner wrote: Using XML without using a schema validator is (or at least should be) a no-go. So even if the Qt XML component should be continued in some way, Qt should also not lack a schema validator. Have you tried other C++ schema validators ? We should be careful when deciding to duplicate other C++ libraries and only do it if can do a better job (and at least maintain it). Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: Using Gerrit for new approver proposals?
On 2019-05-22 09:09, Alex Blasche wrote: From: Volker Hilsheimer A version-controlled configuration file with user names and privileges would provide that, with the added benefit of making the list of approvers easily visible to everyone with read-access to the respective repo. Right now, only Gerrit-admins have that kind of insight, which is at the very least impractical. It is readable for all just not editable: https://codereview.qt-project.org/admin/groups/12,members The maintainers one [1] is very outdated, many people in [2] are missing. From KDAB remove: - Björn Breitmeyer , he's not maintaining WinCE anymore and add: milian.wo...@kdab.com, giulio.camu...@kdab.com, bog...@kdab.com, mike.k...@kdab.com, sean.har...@kdab.com Thanks, Sergio [1] https://codereview.qt-project.org/admin/groups/13,members [2] https://wiki.qt.io/Maintainers Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt XML and Qt Xml Patterns
On 2019-05-21 15:58, Thiago Macieira wrote: On Tuesday, 21 May 2019 00:15:04 PDT Bernhard Lindner wrote: Unlucky me. Deprecation of these two components literally broke every application I have ever written using Qt. I hope they will have new maintainers some day. Note I said QtXml is deprecated, but it might actually be in Done state. I don't remember. Does anyone? Where's our authoritative source? Yes, they were done, not deprecated. See https://wiki.qt.io/Qt_Modules_Maturity_Level I don't think the "Done" nomenclature stuck though. In half the cases it just meant unmaintained rather than actually done. That page should probably be archived, as it's not much of an authority anymore. Some random incorrect statements: " QtSVG (Deprecated) Reasoning: SVG Full (as opposed to SVG Tiny) functionality available in Qt WebKit, which should be used instead; Qt Designer (Done) Reasoning: Qt Quick is recommended for developing UIs from now on, so the new Qt Quick Designer should take over the capabilities of the classic Qt Designer. " https://doc.qt.io/qt-5/qtmodules.html seems to more accurate nowadays Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QDateTime addDays logic
On 2018-12-13 13:48, NIkolai Marchenko wrote: This non obvious (from function name) behaviour actually caused infinite loop regression in our code just recently. The person used it inside a while loop thinking it will loop upwards and stop. If your compiler supports it, you should get a warning such as: warning: ignoring return value of ‘QDateTime QDateTime::addDays(qint64) const’, declared with attribute nodiscard [-Wunused-result] Also useful for many other Qt classes. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Christian Ehrlicher for Approver
On 2018-11-20 08:38, Richard Gustavsen wrote: Hi, I'd like to nominate Christian Ehrlicher for approver rights. +1 Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] who generates gui/text/qcssparser.cpp
On 2018-10-31 11:40, Martin Koller wrote: In this file I find: // auto generated. DO NOT EDIT. class QCssScanner_Generated Who/what generates this file ? Looks like is generated by util/lexgen $ cd util/lexgen $ qmake && make $ ./lexgen css3-simplified.lexgen Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] qMoveToConst helper for rvalue references to movable Qt containers?
On 2018-10-29 15:56, Thiago Macieira wrote: On Monday, 29 October 2018 04:43:09 PDT Olivier Goffart wrote: > 1) it will copy containers. For Qt containers, that's rather cheap (two > atomic refcount operations), but it's not free. And for Standard Library > containers, that is likely very expensive. But using for(:) with a Qt container will cause a detach in the most common case, so I'd say is even worse. Which is why i'm saying using this reason is a bit ironic. True, which is why we didn't deprecate, but did add qAsConst. > 2) it's implemented by way of a for loop inside a for loop, which is known > to throw optimisers out, generating slightly worse code I would consider that the missed optimization is quite small, if not negligible. And it can be solved in C++17: https://codereview.qt-project.org/243984/ I'd solve this the other way around, by making the macro: if (const auto &_container_ = (container); true) \ for (variable : _container_) That's not behaviour-compatible and will introduce bugs where users rely on iterating over a copy. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using #pragma once
On 2018-10-07 09:56, Lars Knoll wrote: IMO #pragma once is both safer and nicer to use than classic header guards. Regarding safety, clang has -Wheader-guard which catches typos in header guards, so most of our codebase should be ok. (Would be nice to have clang-cl -Werror builds on our Windows CI though!) Inspired by this I quickly hacked a clazy check to find typos in all ifndef/define pairs, since clang only does it for include guards. It found this https://codereview.qt-project.org/#/c/242090/ Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Using #pragma once
On 2018-10-07 09:56, Lars Knoll wrote: Hi, Just a quick question: Does anybody have any good arguments against us starting to use #pragma once instead of header guards throughout our code base? Hi Lars, This was already discussed back in January: https://lists.qt-project.org/pipermail/development/2018-January/031966.html The conclusion was to keep using header guards. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] iMX6 EGLGS 2D (QtWidgets) painting acceleration
On 2018-09-05 06:58, Uwe Rathmann wrote: On Tue, 04 Sep 2018 20:51:38 +0200, Martin Koller wrote: added the native X11 graphicssystem support from Qt4 to Qt5 Very cool. Andrew told me that there were 2 concurrent attempts to revive X11 as the situation for running widget applications on remote desktops is simply not good, when using Raster. But I never realized, that finally something went into the Qt code base. What needs to be done to make it become effective ? export QT_XCB_NATIVE_PAINTING=1 Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
[Development] override keyword on destructors
Hi, Looks like some 'override' keywords crept into a few destructors. This is probably because clang-tidy warns about it (and now QtCreator). IMO we should avoid it, as it's misleading. Dtors are a special case and have completely different semantics. They don't replace their base class dtors. They're chained instead. This is not 100% consensual, some people like to use it. But it's discouraged by the Cpp Core Guidelines [1] ; gcc's -Wsuggest-override doesn't suggest it for dtors and neither does clang's -Winconsistent-missing-override. So clang-tidy is the one odd out. I'll update the coding conventions if nobody opposes. [1] - https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Rh-override Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] gsl::owner (Was: Setters: Clarifying the ownership)
On 2018-01-19 18:32, Thiago Macieira wrote: On Friday, 19 January 2018 09:26:10 PST Edward Welbourne wrote: Jaroslaw Kobus (19 January 2018 17:09) > "give" may be confused with "get", which is usually an accessor. I may > also think "Am I giving (to QCoreApplication)" or "The > QCoreApplication is giving (me)". Maybe it is just a matter of the > other verb? Absorb, hand over, hand on, suck in, swallow... However, we have plenty of take functions, where the caller takes ownership from the object on which the method is called; so it makes sense that a give function would be the caller giving ownership to the object on wich the method is called. Thus we'd keep child.setParent(newParent), since the child doesn't take ownership of the parent; but QMainWindow's setCentralWidget() would become giveCentralWidget(), matching its takeCentralWidget(). This would save the search for its doc, to find that it does indeed take ownership. The signature is, in any case, always sufficient to make clear that a give()r isn't a get()ter. Let's stop the discussion about method *naming* right here. We're not going to change hundreds of getters and setters now or even in Qt 6. Let's instead find a solution that either uses macros or uses simple binary- compatible pointer wrappers like GST. And be careful with template functions. Changing from T to Something may change what gets deduced. Nuno experienced a crash [1] which could have been easily caught by a compiler plugin or clang-tidy if we used gsl::owner or similar. So to try to move things forward I asked Marc to restore his gsl::owner change [2]. I would recommend however that our docs show T* instead of gsl::owner and continue to include "Takes ownership of foo" in the text. While I believe in self-documenting signatures I think it's too much noise and hurts readability, and most devs never heard of gsl. Should be just an aid for tooling IMO. [1] http://lists.qt-project.org/pipermail/interest/2018-July/030530.html [2] https://codereview.qt-project.org/#/c/178107/ Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Android binary size with Clang
On 2018-06-21 04:40, Thiago Macieira wrote: Hello Yesterday during the PDXCPP Meet Up, I was asked if we had come up with a good solution to the increase in size of native binaries on Android when switching from GCC to Clang. I reported I had no idea there was even a problem. So, what's the status here? -fno-exceptions was missing and someone discovered -Oz (you actually?), so it's not so bad now. Around 10% binary increase instead of 40% IIRC. QtXmlPatterns suffers much more than 10% for some reason though, so mileage might vary. As far as qt-project is concerned the status is SOLVED IMHO. Users should pressure google directly for further improvement. Regards, -- Sérgio Martins | sergio.mart...@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@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] clang-format
On 2018-06-18 10:04, Frederik Gladhorn wrote:
Hi all,
as part of the closing ceremony of this year's Qt Contributors' Summit
we
agreed to start using clang-format, to have fewer discussions around
coding
style and rather focus on the actual code.
I have not yet thought about all angles, how to best implement this,
here are
some notes:
We have a clang-format file in qtrepotools. You can use it today,
simply make
sure it's in any parent directory of the files you are editing. I'd
actually
propose simply moving this into the root directory of qt5.git.
https://code.qt.io/cgit/qt/qtrepotools.git/tree/config/_clang-format
If you want to clean one file:
clang-format -i myfile.cpp/h
To clean a commit (only modifies the working tree):
git clang-format
Getting clang-format seems easy enough:
On macOS: brew install clang-format
Linux: install clang-format
Windows: it comes with normal clang
Then there is the tooling/workflow perspective. Creator and other IDEs
have
support (you may need to enable the beautifier plugin in about
plugins).
I imagine we add this to the sanity bot ("git clang-format --diff -q"
should
return empty, otherwise post a message).
Local hooks are basically the same, any ideas how to best set up the
git hooks
appreciated :)
And then there is the big question when we run it once over the entire
codebase.
I find clang-format a bit limited and always need to manually format
some things that clang-format doesn't allow to tune.
It's quite useful when integrated with gerrit so it can automatically -1
the most common mistakes, but I wouldn't run it on the entire codebase.
So YES to all you said, except the massive cleanup.
Regards,
--
Sérgio Martins | sergio.mart...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
