Re: [Development] Should QObject::event() be protected or public?
On 15/3/24 19:57, Jean-Michaël Celerier wrote: There's nothing more frustrating that instantiating a C++ type on the stack like MyType foo; and having to call a function with: static_cast(foo).someVirtualMethod(); Or: foo.Base::someVirtualMethod(); [..] -- Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising the minimum to C++20
On 9/2/24 16:45, Volker Hilsheimer via Development wrote: I haven’t heard any convincing argument for us raising the minimum to C++ 20 in the foreseeable future. Not for building Qt, and not for using Qt. At most we get some convenience constructs for ourselves. There’s value in that, of course. But unless I miss something huge, then that value is quite small. We have a working implementation of e.g. atomics that is sufficient for our own needs; we have our own implementation of . We now also have QSpan, which we practically don’t use anywhere in Qt so far. And that value is of practically no relevance to users of Qt - they can use C++20 in their application, together with Qt. The 3 big C++20 features people ask us about are modules, co-routines, and concepts. We have no compelling answers here. You can’t build Qt into a set of modules; we have no APIs using co-routines; none of our template constraints are expressed, or at least documented, as concepts, and there is no draft of a concept library for things that might be interesting for Qt users. Do we really want to go out and say that C++20 is now mandatory to build or use Qt, while we have no convincing story on any of that? Do we want to ask people to make a significant investment if they want to work with the latest Qt version, but even then they don’t get any support for any of the big three features? So, as much as I’d like for some of the things I’m working on to be able to benefit from C++ 20, I’d also say that we should rather slow down, and only require C++20 if we have something to show for it. We can perhaps still make improvements to better enable C++20 features, such as std::ranges, in application code; but that should neither require Qt to be built with C++20, nor require applications that don’t use std::ranges to use C++20. Volker The way KDE Frameworks and Plasma have raised the minimum required C++ version was asking distributions "do you have a problem if we require C++17?" and the answer was "we have recent enough gcc/clang, so go ahead if you want", so Plasma 5 and KF5 raised the minimum required to C++17 during the lifetime of KF5 (with the caveat, IIRC, of not using C++17-only headers unconditionally in public header files). Last time I checked, Plasma 6.0 now requires C++20, using the same process outlined above. I wonder if this can be done here too. Can you survey Linux distro developers/maintainers, your customers and other point-of-contacts? This way you will have a clearer picture of the situation, and can make an informed decision. For example I've started compiling with C++20 locally about 4-5 months ago, the CI still uses C++17, I have seen very few issues. My 2p's. Regards, Ahmad Samir On 9 Feb 2024, at 10:41, Vladimir Minenko via Development wrote: Just as a reminder, the "C++20 is mandatory for users of Qt (Phase III)” (https://bugreports.qt.io/browse/QTBUG-109362) says "The tentative plan is Qt 6.12+” and "C++20 is required for the development and buiding of Qt itself (Phase II)” (https://bugreports.qt.io/browse/QTBUG-109361) - "The tentative plan is Qt 6.9-6.11” With all the respect to the power of C++20 and enthusiasm to use it from Qt Project developers, what should we expect from all other users if we would make this change in 6.8, considering: a) just 4 months left to the Feature Freeze for 6.8 b) there is zero communication to users beyond the above issues on Qt But Reports and discussions on this mailing list (which is actually for Qt developers and not Qt users, BTW) c) there is no other communication about the done and ongoing works introducing C++20 in Qt and plans for future versions, beyond the talk from Mark at QtWS22 and careful reading of “What’s New” pages Qt crashed such a change on users with C++11 and with C++17 in the past. Each time after this, there were much more negative responses than “thank you”s. I still hope we find a way to do this better this time. And just “faster” is not “better" In the current shape, my vote is “no”. -- Vladimir On 3. Feb 2024, at 18:15, Thiago Macieira wrote: On Tuesday, 2 May 2023 17:39:01 PST Thiago Macieira wrote: I don't have access to QNX and INTEGRITY toolchain information, so I'd like to request that they simply match the feature list above, with minimal workarounds. What's the current state for those, for supporting Qt 6.8 or 6.9? We have VxWorks coming in and I'd like it to meet a higher minimum bar than "legacy". That is, I'd like VxWorks to require a C++20-compliant compiler before being enabled in our CI, but that's only fair if we have a line-of- sight to bringing everyone to C++20. -- Thiago Macieira - thiago.macieira (AT) intel.com Cloud Software Architect - Intel DCAI Cloud Engineering -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development -- Development mailing list
Re: [Development] Removal/deprecation of OpenSSL 1 in Qt
On 30/11/23 12:49, Giuseppe D'Angelo via Development wrote: Hi, OpenSSL 1 has reached EOL last September: https://www.openssl.org/blog/blog/2023/09/11/eol-111/ Qt has supported OpenSSL 3 for a while, and so last week I pushed a patch to drop OpenSSL 1 support from Qt. "This has made a lot of people very angry and been widely regarded as a bad move." It turns out that not every platform officially supported by Qt ships OpenSSL 3 yet. Some of these platforms are promising to maintain OpenSSL 1 for a little while longer, for instance Ubuntu 20.04 LTS: https://canonical.com/blog/running-openssl-1-1-1-after-eol-with-ubuntu-pro See this thread started by Albert on the kde-distributions ML about the same issue https://mail.kde.org/pipermail/distributions/2023-November/001459.html Typically when you plan to support EOL software, you do the extra work on your own, that should include e.g. patching Qt to get that support back, and you maintain the patches to Qt code on your own too. That is my understanding of how corporate Linux support works, and it's confirmed by what Jan Grulich posted in a reply to the above KDE ML thread: https://mail.kde.org/pipermail/distributions/2023-December/thread.html (pipermail doesn't show links to the rest of the thread if it spans multiple months). How to move forward from here: "revert the patch", sure, but also not so fast: * First and foremost, I'd like a semi-formal insurance from Qt SSL maintainers that they're willing to maintain OpenSSL 1 code in Qt as long as needed. This should be done publicly, in docs + blog posts, because users are going to depend on this information. * For "how long" is that exactly? Also a very good question. Can we gather 1) which supported platforms are still offering only OpenSSL 1, and 2) for how long do they plan to support OpenSSL 1, and 3) for how long Qt would like to support these platforms? (Basically, assessing whether the "insurance" above is realistic) [...] * Then, a plain revert isn't a good idea either: the whole point of the original commit is that using OpenSSL 1 is outright dangerous if you don't know what you're doing. (Using unmaintained security-sensitive code is a terrible idea). Therefore, a revert must also include make OpenSSL 1 entirely opt-in (cmake switch), and not using any automatic detection whatsoever: users of Qt should never ever be enabling it "by accident". Just stating the obvious: I agree, must be opt-in with a clear disclaimer "You're on your own, if it breaks, you get to keep the pieces". [...] My 2p's worth. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 11:06, Ivan Solovev via Development wrote: I would therefore propose to remove the file from qt5.git: +1 from my side. I believe I simply do not have the clang-format tool installed on my system, because it usually breaks the formatting of the patches, not improves them. One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". The problem is that we have a pre-commit (I believe) git-hook, which checks the formatting and nags if it does not match to what we have in the _clang-format file. This basically forces the new or drive-by contributors to submit the patch with an incorrect formatting, which then leads to a bunch of review comments about code-style. I think that it's better to give no hints, rather than misleading hints. [...] I think the best way to find out is indeed removing the file, then one of two things will happen: - we'll get less formatting issues in reviews (especially from new contributors) - or we'll still get formatting issues, just different ones than what clang-format currently does So 6-12 months, and we'll have a definite answer. :) Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 09:13, Paul Wicking wrote: On 12 Sep 2023, at 22:33, Ahmad Samir wrote: _clang-format isn't picked up by clang-format by default, you'd have to rename it to .clang-format. clang-format reads either of them [0]. It's unnecessary to rename the configuration file. [0] - https://clang.llvm.org/docs/ClangFormat.html#standalone-tool I didn't know that, thanks for the clarification (from other projects, it's always .clang-format, never prefixed with _). //! Paul Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 01:46, Marc Mutz via Development wrote: [I didn't get André's Email...] On 12.09.23 23:40, Ahmad Samir wrote: On 13/9/23 00:11, apoenitz wrote: On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote: A config file that is 80-90% correct is better than nothing. I disagree. The result of such a thing is that people submit patches matching the config 100%, deviating from the wanted style by 10-20%. Numbers are arbitrary here, but the effect is that in practice even long-term contributors start to submit "wrong" auto-formatted patches causing needless review roundtrips. The alternative is patches with arbitrary formatting; that's not better. Sorry, no. If you submit a patch, you should just use whatever style you find in the file. If there's a mix, use whatever is adjacent to where you're coding. It's that simple. That shouldn't be too much to ask, and I, for one, am fine going into the Gerrit editor and fixing things for the submitter if that's the only thing holding me back from a +2. It's when people insist on rewriting lines because that's how QtCreator or git-clang-format format it, that the discussions start. > And a clang-format file doesn't actually help here, because we have already introduced inconsistencies in qtbase and whatever we select in .clang-format will be wrong 50% of the time. Assuming, of course, that you can get it configured to be close enough to the prevailing style, which I have not seen proof of. If anyone thinks it's possible, there's a simple litmus test: apply your config to all of qt(base) and look at the diff: Is it just fixing some outliers, or is it rewriting the world? Without testing, I am sure it's the latter. :) On top of that repeatedly discussion are started about adjusting the style to the tool, because "the tool can't be adjusted". True, but style arguments arise on their own too, tool or no tool. It only arises because the tool cannot represent what we traditionally call the Qt style. If there are disagreements on what that means, it's easy to draw upon a majority vote of Qt 4 code to break the tie, disregarding clang-format-infected files. I should also point out that the discussions a few years ago were nitpicking about Qt coding style violations, and the expected response from the submitter was to fix them. These days, everything is called into question because clang-format does it differently, ie. wrongly. And I'm kinda getting tired commenting on all these clang-format idiosyncrasies. If the tool was truly configurable, e.g. with an example [...] (Are most of those idiosyncrasies about 'template <>' in qtbase reviews? if so, then that's because qtbase doesn't have its own .clang-format with that style, because that's actually something the tool can do). I _know_ there is no perfect solution, I've spent some time trying to tweak the clang-format config in Qt and other projects/repos, there is no way to get a dumb formatting tool to do exactly what you want in all cases, partly because it can't read minds, and partly because it can't know things like "breaking this line of code here is really stoopid". One way to address these problems, especially for new devs or drive-by contributions, is stating clearly in the wiki page: "use clang-format, it should get you at least half way there, but you still should/must also override it to match the style of surrounding code, as much as possible, in the file(s) you're editing, that's kinder to reviewers". Technically, that's what I personally do, it's the same as having bash scripts, even if I can get it to do 50% of what I want, just not having to repeat myself to run some chain of commands 10 times a day is good enough. file from which it would pick formatting, we wouldn't have this discussion, either. But what I read between the lines is that Google is happy that it can reproduce their style, and contributions to extend it are not welcome. One way to stop the recurring discussions would be to reach a majority consensus about a clang-format config file, format the whole code base of each module in one go, then apply the formatting for each new commit, less discussions. Is that ideal? no, because reaching a consensus about coding style is not easy. There _is_ consensus. It's in the wiki. And in older modules not infected by the _clang-format file. Discussions arise because of .clang-format, not despite it. Afaict, there never was a discussion about how faithful the _clang-format represents the Qt style before it was added. If there was _any_ attempt at the above-mentioned litmus test, the template<> issue and others would have been detected immediately. I could format it manually, probably two steps, or let the tool do it That assumes the tool can be configured to reproduce the style. Until proven, you have to do the work 50% of the time, anyway. Tool won't help. It can/is configured to reprodu
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 13/9/23 00:11, apoenitz wrote:
On Tue, Sep 12, 2023 at 11:33:17PM +0300, Ahmad Samir wrote:
A config file that is 80-90% correct is better than nothing.
I disagree.
The result of such a thing is that people submit patches matching the config
100%, deviating from the wanted style by 10-20%. Numbers are arbitrary
here, but the effect is that in practice even long-term contributors start
to submit "wrong" auto-formatted patches causing needless review roundtrips.
The alternative is patches with arbitrary formatting; that's not better.
On top of that repeatedly discussion are started about adjusting the style to
the tool, because "the tool can't be adjusted".
True, but style arguments arise on their own too, tool or no tool.
One way to stop the recurring discussions would be to reach a majority consensus
about a clang-format config file, format the whole code base of each module in one
go, then apply the formatting for each new commit, less discussions. Is that
ideal? no, because reaching a consensus about coding style is not easy.
For example I have copied that file to qtbase/.clang-format and changed that
`template <>` part, it's still useful for me to have the file there as I
could select some text and format only that part in e.g. KDE's Kate. I can
override the changes to conform to qtbase's coding style, but I don't have to
do it all manually.
It's not /that/ hard to follow the /one/ code style that's uses in one's main
project. I have some sympathy for cases where people submit occasional patches
in a side project with some odd style rules, but for the day-time project
typing code in its preferred style should become second nature - independent
of any possible quirks and oddities there.
Examples:
- typos (no space):
if (foo && bar){
//
}
- lengthy lines of code:
static QMetaObject::Connection connect(const QObject *sender,
PointerToMemberFunction signal, const QObject *receiver, PointerToMemberFunction
method, Qt::ConnectionType type = Qt::AutoConnection);
I could format it manually, probably two steps, or let the tool do it
- debating about where to break the line:
bool inSenderThread = currentThreadId ==
QObjectPrivate::get(sender)->threadData.loadRelaxed()->threadId.loadRelaxed();
after the assign =, or after == or ...etc; or just let a tool do it, I can
disagree and override it if it looks too bad.
Andre'
D
PS:
Drive-by suggestion: each module should also have a .git-blame-ignore-revs
file (name should be unified in all Qt repos), to put commit hashes that
git-blame should ignore. (See 'git blame --ignore-revs-file').
Why?
Useful when using git-blame, e.g.:
- the commit that moved inline keyword to fix MinGW warnings in qstring.h, seeing
any line from that commit in git blame isn't useful/informative
- Formatting a repo with clang-format, that commit isn't useful in git blame
context
Regards,
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Proposal: (re)move qt5.git/_clang-format
On 12/9/23 20:29, Marc Mutz via Development wrote: Hi, TL;DR: - remove _clang-format in qt5.git - add it instead to submodules which conform to it The clang-format philosophy is that you pick a config and stick to it. If your personal preferences are different, you use a different configuration locally and re-format on check-in and check-out. This means that the source code in the VCS must always conform to the clang-format configuration in effect in that branch. It also means that when and if you make changes to the clang-format configuration, you need to re-run the tool over the whole code base and apply the changed configuration, otherwise the clang-format workflow doesn't work (produces unrelated white-space changes). We have for quite some time had a _clang-format config file in qt5.git. After many attempts by many people, it has become clear that a) it has completely wrong settings (e.g. template<> vs. template <>), This particular issue with template<> has been "fixed" recently thanks to Mårten https://codereview.qt-project.org/c/qt/qt5/+/433720. leading to a complete formatting mess in modules that predate the addition of the file and more discussions around formatting than before, because there appear to be two true styles, and b) we can't seem to hammer clang-format into reproducing what we traditionally understand as the Qt style. In addition, the position in qt5.git means that if you edit files in submodules of qt5.git, the config is in effect, if you just checkout qtbase, it is not. _clang-format isn't picked up by clang-format by default, you'd have to rename it to .clang-format. I would therefore propose to remove the file from qt5.git: https://codereview.qt-project.org/c/qt/qt5/+/503430 I propose leaving that _clang-format file as the default clang-format config file, but each repo should have a .clang-format committed in git where the module maintainers/powers-to-be can put the code style that they want in their module. Some repos in Qt already do that. One of them has the max line length set to way more than 100, with a comment (paraphrased): "most lines in this repo are long, we have to live with with, move on" which is perfectly fine, the tool will pick up the config file and act accordingly. You can even have a .clang-format per dir in each module. So, remove it if you want, but a precursor to that is copying it to each Qt module, new _and_ old. It's OK for each module to change its own copy to fit its own style, but there should be a .clang-format, because it's much easier to let it format a diff, e.g. `git clang-format`, and override the few places that the tool got "wrong". This is more important for new devs who aren't familiar with the current coding style (yes, there is a good wiki page about the Qt coding style, but no it's not enough, there so much code and too many quirks to cover in one wiki page). Modules that don't have a .clang-format in git are implying "use the default config file". With a .clang-format committed to git, you get it any which way you checkout a Qt repo, `init-reporistory` or `git clone`. A config file that is 80-90% correct is better than nothing. For example I have copied that file to qtbase/.clang-format and changed that `template <>` part, it's still useful for me to have the file there as I could select some text and format only that part in e.g. KDE's Kate. I can override the changes to conform to qtbase's coding style, but I don't have to do it all manually. Drive-by suggestion: each module should also have a .git-blame-ignore-revs file (name should be unified in all Qt repos), to put commit hashes that git-blame should ignore. (See 'git blame --ignore-revs-file'). Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] CI failing due to ASan tst_selftest
On 27/8/23 05:36, Thiago Macieira wrote: See https://testresults.qt.io/coin/integration/qt/qtbase/tasks/1698516419 [...] Looking at this log: ==19313==ERROR: LeakSanitizer: detected memory leaks agent:2023/08/26 21:36:18 build.go:405: 3: agent:2023/08/26 21:36:18 build.go:405: 3: Direct leak of 258 byte(s) in 1 object(s) allocated from: agent:2023/08/26 21:36:18 build.go:405: 3: #0 0x7ffa505c8e48 in __interceptor_malloc (/usr/lib64/libasan.so.5+0x109e48) agent:2023/08/26 21:36:18 build.go:405: 3: #1 0x7ffa4f2d7ff9 (/home/qt/work/install/lib/libQt6Core.so.6+0x896ff9) agent:2023/08/26 21:36:18 build.go:405: 3: #2 0x7ffa4f2d834d in QArrayData::allocate(QArrayData**, long long, long long, long long, QArrayData::AllocationOption) (/home/qt/work/install/lib/libQt6Core.so.6+0x89734d) agent:2023/08/26 21:36:18 build.go:405: 3: #3 0x7ffa4f23b700 (/home/qt/work/install/lib/libQt6Core.so.6+0x7fa700) agent:2023/08/26 21:36:18 build.go:405: 3: #4 0x7ffa4f1f6cc8 in QString::reallocData(long long, QArrayData::AllocationOption) (/home/qt/work/install/lib/libQt6Core.so.6+0x7b5cc8) agent:2023/08/26 21:36:18 build.go:405: 3: #5 0x7ffa4f1f68a7 in QString::resize(long long) (/home/qt/work/install/lib/libQt6Core.so.6+0x7b58a7) agent:2023/08/26 21:36:18 build.go:405: 3: #6 0x7ffa4f2092ff (/home/qt/work/install/lib/libQt6Core.so.6+0x7c82ff) agent:2023/08/26 21:36:18 build.go:405: 3: #7 0x7ffa4f209e09 in QString::vasprintf(char const*, __va_list_tag*) (/home/qt/work/install/lib/libQt6Core.so.6+0x7c8e09) agent:2023/08/26 21:36:18 build.go:405: 3: #8 0x7ffa4ed0d83d (/home/qt/work/install/lib/libQt6Core.so.6+0x2cc83d) agent:2023/08/26 21:36:18 build.go:405: 3: #9 0x7ffa4ed114a9 in QMessageLogger::fatal(char const*, ...) const (/home/qt/work/install/lib/libQt6Core.so.6+0x2d04a9) agent:2023/08/26 21:36:18 build.go:405: 3: #10 0x5641d2604c40 in tst_Silent::messages() /home/qt/work/qt/qtbase/tests/auto/testlib/selftests/silent/tst_silent.cpp:77 I see the same issue locally, so I used `git bisect`, which showed it's because in `checkErrorOutput(const QString , const QByteArray )` in tst_selftests.cpp, the code should return early for "silent" test, because the latter calls qFatal, that doesn't seem to happen on Linux any more. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] On the use of the inline keyword
On 26/8/23 11:51, Volker Hilsheimer wrote:
On 25 Aug 2023, at 14:20, Ahmad Samir wrote:
On 25/8/23 14:11, Cristian Adam via Development wrote:
The other way of fixing this is by using ... macros. The article at c++ - Importing
inline functions in MinGW - Stack
Overflow<https://stackoverflow.com/questions/11546403/importing-inline-functions-in-mingw>
mentions using inline in the class declaration.
Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is
also fine:
#ifdef _WIN32
#define Q_EXPORT_INLINE inline
#else
#define Q_EXPORT_INLINE
#endif
class __declspec(dllimport) MyClass {
public:
Q_EXPORT_INLINE int myFunc2();
Q_EXPORT_INLINE int myFunc1();
};
inline int MyClass::myFunc2(void) {
return myFunc1();
}
inline int MyClass::myFunc1(void) {
return 0;
}
[...]
The main deterrent to not fix it like the qstring.h patch[1] is the churn
caused by changing many lines, in many files, right?
But if affected code is going to be changed anyway to fix it with macros, it
makes more sense to fix it like [1]; if you're changing those lines, may as
well adhere to more standard guidelines: inline keyword is only used on
function declaration and _not_ the definition.
My 2p's.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/498739
Yes, if we have to change the code to fix the warnings, then the way Marc
proposes, and how it has now been done for qstring.h, seems to be the way to go.
But yes, my concern is the work (I expect this can be easily automated with
clazy, but still need to be reviewed), and the code churn that goes with it
(the impact on `git blame`, and the inevitable conflicts when cherry-picking).
Tentative clazy check: https://invent.kde.org/sdk/clazy/-/merge_requests/84
IIUC, the `git blame` issue can be mitigated by adding those commits to e.g. a
.git-blame-ignore-revs file in each repo, see `git blame --ignore-revs-file` [1].
I saw something like that in one of Qt's repos, but can't remember which one...
it's also used in almost all KDE's Frameworks repos.
Conflicts when cherry-picking could be a problem. But the changes can be limited
to the bare minimum, i.e. only add inline keyword to declaration of affected
methods (ignoring constexpr and function templates, both are implicitly inline IIUC).
(I'd rather the whole thing is done like qstring.h).
It seems to be a rare issue, triggered by specific circumstances. With the
knowledge that we have now, we can fix issues when they arise, and don’t have
to change all the problematic use right now.
That’s my understanding at least; I might be wrong, but we have been building
Qt for a few decades on MinGW without this constantly blocking us.
FWIW, that's my understanding too.
I've used that clazy check linked above (via clazy-standalone) on qtbase, it
doesn't look too bad... if you ignore src/opengl, that dir alone:
$ git show --stat
26 files changed, 14857 insertions(+), 14857 deletions(-)
I've no idea about OpenGL, but it looks like that is generated code, so maybe `git
blame` doesn't matter there that much.
[1] https://git-scm.com/docs/git-blame
Regards,
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] On the use of the inline keyword
On 25/8/23 14:11, Cristian Adam via Development wrote:
The other way of fixing this is by using ... macros. The article at c++ - Importing
inline functions in MinGW - Stack
Overflow<https://stackoverflow.com/questions/11546403/importing-inline-functions-in-mingw>
mentions using inline in the class declaration.
Their example works fine with both GCC MinGW and Clang MinGW. Visual C++ is
also fine:
#ifdef _WIN32
#define Q_EXPORT_INLINE inline
#else
#define Q_EXPORT_INLINE
#endif
class __declspec(dllimport) MyClass {
public:
Q_EXPORT_INLINE int myFunc2();
Q_EXPORT_INLINE int myFunc1();
};
inline int MyClass::myFunc2(void) {
return myFunc1();
}
inline int MyClass::myFunc1(void) {
return 0;
}
[...]
The main deterrent to not fix it like the qstring.h patch[1] is the churn caused
by changing many lines, in many files, right?
But if affected code is going to be changed anyway to fix it with macros, it makes
more sense to fix it like [1]; if you're changing those lines, may as well adhere
to more standard guidelines: inline keyword is only used on function declaration
and _not_ the definition.
My 2p's.
[1] https://codereview.qt-project.org/c/qt/qtbase/+/498739
Regards,
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Q_FOREACH, again
On 14/8/23 21:46, Thiago Macieira wrote: On Monday, 14 August 2023 10:32:36 PDT Marc Mutz via Development wrote: It does _not_ have any influence on user code. Except where accidentally the QT_NO_FOREACH gets copied to the library's CMake INTERFACE. Then it does. This happened for QT_NO_CONTEXTLESS_CONNECT when it was applied to Qt6UiPlugin. We don't understand why it happened there (didn't bother to investigate), so be aware that your claim may be incorrect and that user code may be affected regardless of your intention. See 93de403391b59acf90fbe7319a059382dfe458a6 in the qt-creator repository. Thanks to Giuseppe for poking the issue, Alexandru figured it out a while ago: https://codereview.qt-project.org/c/qt/qttools/+/491477/2/src/uiplugin/CMakeLists.txt#16 The issue seen in Qt Creator 93de403391b59acf90fbe7319a059382dfe458a6 (the QT_NO_CONTEXTLESS_CONNECT leaking to user code) was "fixed" by https://codereview.qt-project.org/c/qt/qttools/+/492556 The "gist" of it is, don't use qt_internal_add_module + HEADER_MODULE + DEFINES, because those DEFINES could be leaked into user code that links to the plugin in question. HEADER_MODULE isn't used that many times in Qt code, and typically where it's used there is no SOURCES arg passed to qt_internal_add_module, however it's a corner case to look out for when adding DEFINES to qt_internal_add_module. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Failed to build Qt6 Documentation from qt/qtbase sources?
On 1/8/23 15:22, Haowei Hsu wrote:
Hello, Qt Development Team.
Recently, I tried to build the Qt6 Documentation from qt/qtbase
<https://github.com/qt/qtbase> sources. In order to
build Qt6 Documentation more conveniently, I prepared a
*CMakeUserPresets.json*
in the root directory with some required configurations introduced in:
- Building Qt Documentation - Qt Wiki
<https://wiki.qt.io/Building_Qt_Documentation#Building_Qt_6_Documentation>
- Qt Build System Glossary - Qt Wiki
<https://wiki.qt.io/Qt_Build_System_Glossary#Documentation-only_Build>
The following is the content of my *CMakeUserPresets.json*:
{
"version": 4,
"cmakeMinimumRequired": {
"major": 3,
"minor": 23,
"patch": 0
},
"configurePresets": [
{
"name": "win32",
"description": "Windows",
"binaryDir": "${sourceDir}/build/${presetName}",
"generator": "Ninja",
"toolset": {
"value": "v142,host=x64",
"strategy": "external"
},
"architecture": {
"value": "x64",
"strategy": "external"
},
"cacheVariables": {
"CMAKE_C_COMPILER": "cl.exe",
"CMAKE_CXX_COMPILER": "cl.exe",
"QT_HOST_PATH": "C:/Qt/6.3.2/msvc2019_64",
"QT_NO_PACKAGE_VERSION_CHECK": true
},
"environment": {
"LLVM_INSTALL_DIR": "C:\\Program Files\\LLVM"
}
}
]
}
The followings are the steps I used to build *docs_Core* target
1. Run: *git clone https://github.com/qt/qtbase.git
<https://github.com/qt/qtbase.git>*
2. Run: *cd qtbase*
3. Run: *git checkout 6.5*
4. Add the above custom *CMakeUserPresets.json*
5. Run: *vcvarsall.bat x64*
6. Run: *cmake --preset win32*
7. Run: *cmake --build build/win32 --target docs_Core*
However, it turns out that there is an error in the Step 7:
[image: image.png]
What happened? What did I miss? Can you help me to figure out this problem?
You can see the attachment with the full log: *log-build-qt6-docs.txt*
---
Haowei Hsu
From the build log:
D:/Repo/GitHub/testing/qtbase/src/corelib/doc/qtcore.qdocconf:1: (qdoc) error:
Cannot open file 'C:/Qt/Qt-6.5.3/./doc/global/qt-module-defaults.qdocconf':
???
Cannot open file 'C:/Qt/Qt-6.5.3/./doc/global/qt-module-defaults.qdocconf':
???
I don't use Windows so I am not sure how this can be fixed; it's looking for the
.qdocconf file in the installation path rather than the source dir (in the git
checkout).
Regards
Ahmad Samir
OpenPGP_signature
Description: OpenPGP digital signature
--
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
On 9/3/23 10:14, Marc Mutz via Development wrote: On 08.03.23 15:30, Ahmad Samir wrote: So, named casts (static_cast) are better in such cases, as searching for them in source code is much easier than searching for: - int(foo) - (int)foo - (int)(foo) In which situation would you want to search for all casts in a piece of source code? Without the use of a semantic grep tool? The tool (in this case compiling with -Wshorten-64-to-32, then checking with clangd or the build log ...etc) would warn about implicit casts, but not explicit ones? now if there is a named cast, then I can search for that much easier than I would for the C-style cast (int)foo, or int(foo). (I haven't checked clang-tidy, but I am guessing it won't be that much different than clangd). I wouldn't like the extra noise of a static_cast when a constructor call would suffice. Obviously, C-style casts should be avoided (in headers, IIRC, they're caught by headerscheck). Good luck with avoiding C-style casts in a huge codebase, e.g. qtbase, there is code that's been there since the 90's, and any attempt to "fix" C-style casts in the whole codebase would be seen as "churn". Thanks, Marc Thanks, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] qsizetype
On 1/9/22 12:15, Marc Mutz wrote: This should be non-issue for function parameters, because widening isn't an error. The value is less pronounced for return values, because widening those may cause narrowing in user code, but the hope is that once we've progressed somewhat, we can enlist compiler support by globally enabling warnings such as -Wshorten-64-to-32, even though, as the porting guide included in the https://bugreports.qt.io/browse/QTBUG-102461 epic describes, this will not catch manual casts, which is why, sadly, one needs to look at every int/uint manually. Sorry for bringing this thread back up from the archives. So, named casts (static_cast) are better in such cases, as searching for them in source code is much easier than searching for: - int(foo) - (int)foo - (int)(foo) multiplied by the number of other integral types in Qt (qint32, qint64, uint, qlonglong, qulonglong... etc). Thanks, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature -- Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] [Announce] Security advisory: Freetype in Qt
On 27/7/22 19:15, Thiago Macieira wrote: On Wednesday, 27 July 2022 09:43:32 PDT Albert Astals Cid wrote: 5.15: https://download.qt.io/official_releases/qt/5.15/CVE-2022-27404-27405-2740 6 -qtbase-5.15.diff This patch doesn't seem to apply over the v5.15.5-lts-lgpl tag for me, can someone please double check in case I'm doing something wrong? Looks like Freetype in the current 5.15 branch does not match what's in the patch. $ git show origin/5.15:src/3rdparty/freetype/docs/CHANGES | head -2 CHANGES BETWEEN 2.10.0 and 2.10.1 $ curl -sL https://download.qt.io/official_releases/qt/5.15/ CVE-2022-27404-27405-27406-qtbase-5.15.diff | \ grep -A3 b/src/3rdparty/freetype/docs/CHANGES diff --git a/src/3rdparty/freetype/docs/CHANGES b/src/3rdparty/freetype/docs/ CHANGES index 3bd5291ae1..3ad7ec4333 100644 --- a/src/3rdparty/freetype/docs/CHANGES +++ b/src/3rdparty/freetype/docs/CHANGES @@ -1,4 +1,235 @@ -CHANGES BETWEEN 2.10.3 and 2.10.4 +CHANGES BETWEEN 2.12.0 and 2.12.1 The patch was created on top of FreeType 2.10.3, while the branch has 2.10.1. I repeat :stop using the bundled third party content unless you're willing to update it yourself. In which case, you should simply update to 2.12.1 on your own. Ignore the patches in the CVE. Going forward, don't ship/bundle 3rd party libs, instead add scripts (shell or CMake (the latter has support to fetch remote stuff https://cmake.org/cmake/help/latest/module/FetchContent.html)) that download that source code from git (at a specific commit hash) or as tarballs and unpack them ...etc. This approach means you would only need to change one line in a script and users will get the latest stable source code of a 3rd party lib the next time they build. "Does the next version of lib A build?" that's a question Linux distributions will usually have an answer for; and you will have an answer for it too if you use those same scripts to fetch those sources in your e.g. Windows CI. If you keep bundling them, then the burden of pacthing CVE's in those bundles libs, falls on you (any which way you want to look at it, license-wise, morally, legally...). My 2p's. Regards, Ahmad Samir OpenPGP_signature Description: OpenPGP digital signature ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] QKeySequenceEdit questions
On 16/5/22 19:12, Laszlo Papp wrote: On Mon, May 16, 2022 at 2:57 PM Volker Hilsheimer wrote: On 11 May 2022, at 16:02, Laszlo Papp wrote: Hi, 1. I would like QKeySequenceEdit to block the processing of hotkeys while recording, so that the new hotkey being recorded is not getting handled (e.g. cmd+q does not close the Qt app in this mode). Is this already possible to achieve? I think that modal dialogs work ok for example. But in my case, I am not using a model dialog. Here is a testbed where you can reproduce the issue: https://github.com/lpapp/examples/tree/main/qt-hotkey-editor Hi Laszlo, I’ll have to look a bit more, but looking at the code I see that QKeySequenceEdit accepts both the ShortcutOverride and the Shortcut event, so it should take precedence over any application-defined shortcut. If/since that doesn’t work, But since you write cmd+q (and considering your recent patches) I think that perhaps you are on macOS, and it might be that our macOS shortcut code doesn't respect the focus widget’s override for application level shortcuts. Bottom line anyway: this should already work, so if it doesn’t, I’d consider that a bug. Yes, it seems to work on Windows and Mac. I have not noticed until you mentioned it. Thanks for pointing that out. 1. Is there an easy workaround until this gets fixed in Qt? 2. Where would I need to look if I wanted to help you out by sending a patch for Qt so that future versions will work on Mac? 2. Is it possible to configure QKeySequenceEdit not to support multiple keypresses as a shortcut for an action? It seems to be the default behaviour and it feels a bit odd at first. At least, not how we would like to use this. I am referring to the "A, B, C" setup that is possible. If not, is this something that should be configurable? Making it possible to configure the max length of the recorded QKeySequence could be a useful feature addition. I don’t see that this is possible today, but implementing it might not require much more than replacing the use of QKeySequencePrivate::MaxKeyCount with a property. So, you would propose to do that in QtGui::QKeySequence then, I assume, rather than QtWidgets::QKeySequenceEdit, right? Thanks. As a datapoint https://api.kde.org/frameworks/kguiaddons/html/classKeySequenceRecorder.html (which supports single letter shortcuts, used by KShortcutsDialog and co.). Best regards Ahmad Samir ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 6 not seeing the same DPI as Qt 5
On 29/11/21 18:41, Thiago Macieira wrote: I'll probably have to report this as a bug, but just in case someone has seen it before: $ diff -u qtdiag5 qtdiag6 [...] Geometry: 1920x1200+0+0 (native: 3840x2400+0+0) Available: 1920x1200+0+0 Virtual geometry: 5760x1200+0+0 Available: 5760x1200+0+0 2 virtual siblings - Physical size: 288x180 mm Refresh: 59.9939 Hz Power state: 0 - Physical DPI: 169.333,169.333 Logical DPI: 120.118,120 (native: 240.236,240) Subpixel_None + Physical size: 406x228.6 mm Refresh: 29.9806 Hz Power state: 0 + Physical DPI: 120.118,120 Logical DPI: 96,96 Subpixel_None High DPI scaling factor: 2 DevicePixelRatio: 2 Do the - and + lines represent the same monitor? one says refresh rate is ~60Hz, the other says ~30Hz. [...] -- Ahmad Samir ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Raising minimum CMake version to 3.16 for Qt6
On 05/05/2021 19:58, Thiago Macieira wrote: On Tuesday, 4 May 2021 21:51:36 PDT EXT Craig Scott wrote: Given that we haven’t received any reports about this from user projects in the year since the code added this constraint, and that we expect to rely more on the metatypes going forward rather than less, the CMake Ports team proposes to raise the minimum CMake version for user projects to CMake 3.16. From what we can tell, the original target of 3.14 was likely based on the CMake versions available in major Linux distributions at the time, but 3.16 or later now seems to be widely enough available (Ubuntu 20.04 is the main blocker for being able to go any higher than 3.16). 3.16.0 was tagged on Nov 2019, which is a little too close for comfort. For comparison, we require GCC 8, which was released in May 2018. However, given that no one has apparently complained and that upgrading cmake is far easier than the compiler, I have no objections. FWIW, on the Linux side, for KDE Frameworks we asked on the distributi...@kde.org ML that same question recently, maybe the answers in that thread can help you: https://mail.kde.org/pipermail/distributions/2021-March/000970.html Have a good day. -- Ahmad Samir ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
