Re: [Development] Renaming QGenericItemModel

On 20/05/2025 10:26, Richard Gustavsen wrote: Would it be more convenient to put the range API directly on QRangeModel instead? E.g: QRangeModel model({1, 2, 3, 4, 5}); listView.setModel(&model); model.erase(model.begin()); model[0] = x; model.push_back(y); Yes, this is an important question

Re: [Development] Renaming QGenericItemModel

On 12/05/2025 09:53, Volker Hilsheimer wrote: Would a simple QRangeItemModel be clear enough? The “Based” doesn’t seem to add a lot of clarity. It does what it says, though. But before discussing this further... Also, as discussed at Qt CS (and mentioned in the last point of the notes ath

Re: [Development] Renaming QGenericItemModel

Il 09/05/25 17:26, Edward Welbourne ha scritto: The only issue I have is with the name. QRangeAdaptorItemModel ? Just reading your words back at you ... Well, maybe the authors of the class wanted to defend their naming choice. :-) QRangeAdaptorItemModel or QRangeBasedItemModel work for me.

[Development] Renaming QGenericItemModel

Hi, QGenericItemModel is a new API (TP?) in 6.10: https://doc-snapshots.qt.io/qt6-dev/qgenericitemmodel.html In a nutshell, it's an adaptor that wraps a range and exposes it through the QAIM API. This allows to expose e.g. a std::vector to the model/view framework without writing boilerplate.

Re: [Development] download.qt.io partially down

Hi, On 17/04/2025 12:51, Axel Spoerl via Development wrote: Hi all, the opensource download site http://download.qt.io is partially down due to traffic overload. Intermittent outages can be regional. We outages reported from Berlin and Boston, while the site was reachab

Re: [Development] PSA: symbol visibility and export macros need to be re-thought for clang/libc++

Il 04/04/25 20:15, Thiago Macieira ha scritto: The QMetaType registration process takes type names into account to determine if two types are the same or not. That may be the right thing for the majority of types, but it's not for everything. For example, if two libraries have two different "str

Re: [Development] PSA: symbol visibility and export macros need to be re-thought for clang/libc++

On 04/04/2025 17:44, Thiago Macieira wrote: The conclusion from this is that, from the point of view of the C++ language, they*are* different types, even if they have the same mangling and can (and are) passed across library boundaries in by value, by pointer, in containers, etc. The big proble

Re: [Development] PSA: Lack of Coverity Scan builds

On 18/03/2025 12:01, Marc Mutz via Development wrote: As I said, I'm skipping qtdeclarative and its dependencies. Not ideal but better than nothing.  :( Looks like it stopped working again? The last scan is from eight days ago? Genuine build errors now. Last one failed in qtwayland: https://c

Re: [Development] Why does QQuickImageProvider not support SVG images?

Il 12/03/25 09:46, Schimkowitsch Robert ha scritto: I immediately jumped on the brand-new VectorImage, and quickly found, to my disappointment, that I cannot use it, because I am missing an important piece. How am I supposed to pass a memory-generated SVG via URL? Normally, I would do that vi

Re: [Development] [Windows] State of the Qt6 natvis file

Il 21/02/25 19:00, Philippe ha scritto: /You can't just copy and use the file because of the "##NAMESPACE##:: everywhere/ You can find/replace this token all over the file. Easy and it works (using Visual Studio). Considering PDB has support for embedding natvis files, they should be patched

Re: [Development] Capturing and overlaying in QtQuick using RHI

Hi, On 17/02/2025 00:15, Jean-Michaël Celerier wrote: I think I have something close to that there: https://github.com/ossia/score/blob/master/src/plugins/score-plugin-js/JS/Executor/GPUNode.cpp#L284 Line 289 the rendertarget on which QtQuick is going to be rendered. Then the actual rendering

[Development] Capturing and overlaying in QtQuick using RHI

Hi, When using QQuickWindow with RHI, I'm wondering what would be the best way to capture the contents drawn by QtQuick (1), and also overlay some further drawing on top of those contents (2). The tricky bit is that I'd like the capture _not to_ include the further drawing -- I've solved (1)

Re: [Development] PSA: Lack of Coverity Scan builds

On 04/02/2025 14:16, Volker Hilsheimer wrote: Well, the tool itself is built just fine; it's binary identical to one built without Coverity. It's more likely that Coverity is doing something like tracing it during the build process and something goes wrong there, so host tools aren't going to

Re: [Development] PSA: Lack of Coverity Scan builds

On 30/01/2025 18:45, Thiago Macieira wrote: On Thursday 30 January 2025 09:09:47 Pacific Standard Time Giuseppe D'Angelo via Development wrote: Some of you may have noticed the lack of reports by Coverity Scan in the last couple of weeks. The reason is that Coverity updated their scanning

[Development] PSA: Lack of Coverity Scan builds

Hi, Some of you may have noticed the lack of reports by Coverity Scan in the last couple of weeks. The reason is that Coverity updated their scanning tool to the 2024.6 version (on Jan 11th), and the new tool crashes qsb when building qtdeclarative. The old version of the tool still builds Q

Re: [Development] API style guide: scoped enum or not?

Hi, On 16/01/2025 16:29, Marc Mutz wrote: On 16.01.25 15:05, Thiago Macieira wrote: On Thursday 16 January 2025 04:55:56 Pacific Standard Time Marc Mutz via Development wrote: https://gcc.godbolt.org/z/6exEonP5o, maybe? Yes. @Ville, @Peppe: do you happen to know whether this is supposed to w

Re: [Development] Shaders in QRhi

Hello, On 21/12/2024 09:18, Harald Vistnes wrote: I've seen some notes that geometry shaders are not supported in QRhi, but I don't know if that is outdated or not. Can geometry and tessellation shaders be used with QRhi? Yes, although with lots of limitations, and they're still half-exper

Re: [Development] Switching Qt default builds to C++20 where supported

Hello, Il 28/10/24 16:39, Fabian Kosmale via Development ha scritto: However, if it comes to ABI, I'm not convinced that we have a solution. As long as e.g. libstdc++ declares its support experimental, are we really willing to export C++20 symbols from Qt? If not, do we have strategy to prevent

Re: [Development] format-like tr()

Il 25/10/24 10:03, David C. Partridge ha scritto: While I applaud the thought of using std::format where appropriate, I can't see what converting the existing tr() mechanism to that will gain Qt Development or Qt Users One would be the compile-time check on the format strings and its replaceme

Re: [Development] format-like tr()

Il 24/10/24 19:04, Edward Welbourne ha scritto: Given that that does also substitute the relevant number into the string, I offer: tr("The apple(s) you bought cost %L1", n).arg(price); where the number controlling the singular/plural choice isn't inserted into the result, but something else

Re: [Development] format-like tr()

Il 24/10/24 18:23, Thiago Macieira ha scritto: On Thursday 24 October 2024 05:19:45 Pacific Daylight Time Giuseppe D'Angelo via Development wrote: Btw, where does the “tr” go? Is it going to be tr(std::format(…)) or std::vformat(tr(…))? In the former, we’d have to pass the value twice

Re: [Development] format-like tr()

Hi, Thanks for summarizing my very thoughts. Il 24/10/24 13:23, Volker Hilsheimer via Development ha scritto: Btw, where does the “tr” go? Is it going to be tr(std::format(…)) or std::vformat(tr(…))? In the former, we’d have to pass the value twice (once for std::format to substitute, once fo

Re: [Development] Switching Qt default builds to C++20 where supported

On 14/10/2024 20:46, Mathias Hasselmann via Development wrote: The QtCS24 misses the single one big reason you want to switch C++20 now and whenever possible: Concepts. They indeed are a total game changer and I'd boldy predict that 80% of all meta-programming helpers in Qt's headers could be re

Re: [Development] Switching Qt default builds to C++20 where supported

On 14/10/2024 16:56, Vladimir Minenko via Development wrote: Effectively, I don't see much difference from the current situation, where we "pretend" that we require C++17 but in reality we just check that we can pass `-std=c++17` to the compiler. Any usage in Qt code of individual language/li

Re: [Development] Switching Qt default builds to C++20 where supported

On 10/10/2024 18:57, Thiago Macieira wrote: Re: https://codereview.qt-project.org/c/qt/qtbase/+/463425 TL;DR: for some std::format functionality, we really want to have out-of-line implementations, which requires QtCore compiled with C++20. See https://codereview.qt-project.org/c/qt/qtbase/+/595

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

On 27/08/2024 04:03, Thiago Macieira wrote: I also urge you to expand on the case of std::vector::operator[]. Are you proposing that it a) become non-noexcept, b) have its UB not defined by the boundary of the precondition, or c) have a precondition that cannot be turned into an exception? It's

Re: [Development] Disavowing the Lakos Rule for Q_ASSERT

Il 26/08/24 19:56, Thiago Macieira ha scritto: I'd like to request Qt code not obey that rule. In my opinion, it's a defect in the contract implementation rather than on Qt code. The*pre* condition indicates something that must be true before the method is called and therefore the method's own n

Re: [Development] QVariant and types with throwing dtors

Il 26/08/24 19:49, Thiago Macieira ha scritto: A runtime warning is unacceptable because it adds to the cost of the 99.99% who don't have a throwing destructor. A compile-time warning implies having a way to disable it with "I know that, just ignore it" which is maintenance for us. My problem wi

Re: [Development] QVariant and types with throwing dtors

Il 26/08/24 07:24, Marc Mutz via Development ha scritto: IMHO, (1) is not an acceptable option. Us C++ professionals having identified this problem after years of it lying dormant, it behooves us, at the very least, to educate our users about this, e.g. by adding docs, and maybe a qWarning() in ~

Re: [Development] How to skip write property in qml's property binding?

On 22/07/2024 07:11, André Somers via Development wrote: On 19-07-2024 11:25, JiDe Zhang wrote: Thank you, but I can't use `text: fooObject?.foo ?? ""`, because I would not the `text` property change if when fooObject change to null. If fooObject's new value is null, I want the |text|​ property

Re: [Development] Proposing QUIP-23: Qt-Security header in source code files

On 11/07/2024 15:21, Volker Hilsheimer wrote: For many APIs, application code provides the data (perhaps indirectly), e.g. to QDateTime::fromString. In that case we can assume that the application had at least some chance to scrub the input, or at the very least control where that string comes fr

Re: [Development] Proposing QUIP-23: Qt-Security header in source code files

On 10/07/2024 19:08, Kai Köhne via Development wrote: That's a lot of questions. But a lot comes down to: Can we agree on parts of Qt that are more critical and, therefore, should be subject to additional security (in terms of approvers, coding standards, fuzzing ...)? And can we then document

Re: [Development] std::format support for Qt string types

Hi, On 19/06/2024 11:23, Alexey Edelev via Development wrote: Hi, I have a side question for this discussion(raised by Ivan in personal conversation): Should we also force the -fexec-charset= for the gcc-like compilers? Currently we use the system default one, which in most cases is UTF-8.

Re: [Development] Changing Qt's Binary Compatibility policy

Hi, On 18/06/2024 10:15, Alex Blasche via Development wrote: Our biggest issue is the adoption of Qt by users moving from one major release to the next. The deprecations start to become a liability and while they keep SC compatibility in check for Qt 6 they become a serious concern for any ado

Re: [Development] Are char literals L1 or U8 in Qt?

On 12/06/2024 10:51, Edward Welbourne wrote: I'll trust Peppe's count is thus of bytes in UTF-8. No, it's 7 code *points*. Regional flags have a complicated encoding scheme. Wales' flag is encoded as: U+1F3F4 WAVING BLACK FLAG U+E0067 TAG LATIN SMALL LETTER G U+E0062 TAG LATIN SMALL LETTER B

Re: [Development] Are char literals L1 or U8 in Qt?

Il 11/06/24 11:36, David C. Partridge ha scritto: Anyone iterating bytewise over a char[] in UTF-8 has also got serious bugs given that a UTF-8 "graphic character" can be up to 8 bytes (national flags comprise two UTF-8 code points). There's no such thing as a UTF-8 "graphic character". Graphem

Re: [Development] Are char literals L1 or U8 in Qt?

Il 11/06/24 07:12, Thiago Macieira ha scritto: I'm arguing that such code is likely already broken (producing mojibake) for non-US-ASCII content, so having U+FFFD instead of mojibake is not worse. You wouldn't be able to work around the issue by un-doing the improper encoding, which means it woul

Re: [Development] std::format support for Qt string types

On 07/06/2024 10:53, Ivan Solovev via Development wrote: Hi > I think we should conceptually separate formatting from printing on a > terminal. std::format isn't /_just_/ for printing on terminals I agree. But the same question about encoding to be used is still valid here. > What do you

Re: [Development] std::format support for Qt string types

Hello, On 05/06/2024 15:18, Ivan Solovev via Development wrote: Hi, I'm now working on introducing std::format support for some of the Qt types. I decided to start with the variety of Qt string types, and I have some open question regarding the implementation that I want to discuss. First, I'd

[Development] Feature freeze exception: PDF/X-4 support

Hi, Last week I pushed a series of patches to add PDF/X-4 support (for color-managed PDFs). https://codereview.qt-project.org/q/topic:%22pdfx4%22 Some of them have already been merged, some have +1s. I'd like to have these in 6.8 and so I'm asking for a FF exception. The impact is extremely

Re: [Development] Changing Qt's Binary Compatibility policy

Hi, On 25/05/2024 13:03, apoenitz wrote: As an open source application developer I mostly care about SC, as SC breakages means actual work for/me/. To better understand: when you talk about SC, are you referring to literally source compatibility (application can be recompiled with newer vers

[Development] Changing Qt's Binary Compatibility policy

Hi, One of the discussions at the past Qt Contributors' Summit was about our BC policy: https://wiki.qt.io/Two-way_BC_in_Patch_Releases We had a consensus for implementing some changes, but I don't remember the action points have been taken, so here we are. We propose to change Qt's BC po

Re: [Development] New survey roll-out on doc.qt.io

Il 02/05/24 14:58, Safiyyah Moosa via Development ha scritto: Hi All The Documentation team has launched a new survey on doc.qt.io. Help us to improve our documentation by filling out the survey and letting us know your thoughts! This should be probably cross-posted on interest@ and other en

[Development] Module maintainers: please prepare for [[nodiscard]] QFile::open

Hi, https://codereview.qt-project.org/c/qt/qtbase/+/550842 has just been merged. TL;DR: this patch will make QFile::open [[nodiscard]] by default starting from Qt 6.10 (*). While there's some time before that happens, it also means that as soon as the Qt version is bumped to 6.10 in dev,

Re: [Development] Using string literals in autotests

Il 28/03/24 12:14, Friedemann Kleint via Development ha scritto: Hi, I'd say performance should be a consideration for autotests since they are compiled and run over and over again in the CI. So, string theory should be applied to avoid unnecessary conversions and allocations. Even it is conside

Re: [Development] Using string literals in autotests

On 28/03/2024 10:36, Axel Spoerl via Development wrote: Since _L1 usage is massive in corelib, I wonder whether there is a standard that everyone can apply when writing or reviewing autotests. If it exists and I have overlooked it, please forgive my negligence and point me to it. * Wh

Re: [Development] Removing Qt 3D from release configuration in dev branch

Hi, On 27/03/2024 09:39, Tuukka Turunen via Development wrote: # Qt 3D module is removed from official release configuration in the dev branch, i.e. no longer part of the releases from Qt 6.8 onwards # Qt 3D continues to be part of Qt project, it continues to be covered by CI, and available in

Re: [Development] Should QObject::event() be protected or public?

On 18/03/2024 13:34, André Somers wrote: While I know it's easy to work around, I sometimes find myself doing it anyway. To me, it signals what API is intended to be used in what way. That a class overrides `event`  (or any other public virtual method) does not mean that that method is then inten

Re: [Development] Should QObject::event() be protected or public?

Il 15/03/24 21:21, Jaroslaw Kobus via Development ha scritto: To the point: we are talking here about decreasing the visibility of a member function in a subclass. The virtuality of the method isn't relevant I guess, is it? It is relevant, since that's the whole problem: since event() is a vir

Re: [Development] Should QObject::event() be protected or public?

Il 15/03/24 19:22, Giuseppe D'Angelo via Development ha scritto: Il 15/03/24 19:17, Jaroslaw Kobus via Development ha scritto: +1. Typically, the designer of a subclass knows what he is doing. But it also happens that users of this class know better how to use it :) I'm not sure

Re: [Development] Should QObject::event() be protected or public?

Il 15/03/24 19:17, Jaroslaw Kobus via Development ha scritto: +1. Typically, the designer of a subclass knows what he is doing. But it also happens that users of this class know better how to use it :) I'm not sure what this means. If you override `event()` (public in QObject) as e.g. protec

Re: [Development] Should QObject::event() be protected or public?

Il 13/03/24 08:58, Marc Mutz via Development ha scritto: If you see any reason for QObject::event() to stay public in Qt 7 and not become protected, please speak up before we fork Qt 7.0 :) I am *positive* that there's code out there that just calls event() to deliver an event. (Maybe there

Re: [Development] Can we remove recommendation against unnamed namespaces from Qt coding conventions?

On 21/02/2024 17:26, Jøger Hansegård via Development wrote: Our Qt coding conventions (https://wiki.qt.io/Coding_Conventions ) has a statement on the use of unnamed (anonymous) namespaces. As far as I understand, this statement is now outdated. Can we dele

Re: [Development] Decrease amount of qt releases in online installer

Hello, On 21/02/2024 11:42, Jani Heikkinen via Development wrote: Currently, more than 60 Qt releases can be installed from the Qt open source online installer (if all installation categories are selected). This requires a huge amount of disk space on the mirrors and also causes some performan

Re: [Development] Raising the minimum to C++20

Il 09/02/24 15:45, Volker Hilsheimer via Development ha scritto: 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 i

Re: [Development] What's our policy on changing the result of qHash(T, 0) between major releases?

Il 03/02/24 22:08, Thiago Macieira ha scritto: But what about a zero seed? It's what we call a "deterministic hashing". We have changed the algorithms on .0 releases (in both 5.0 and 6.0 for QString). I don't think it means "deterministic" in the sense that the output will never change across

Re: [Development] Marking the Tech Preview APIs as such

Il 22/01/24 19:03, Shawn Rutledge via Development ha scritto: I guess your goal is to be able to see it in the header rather than having to look up the docs in the cpp file or online?  (Alternatively we could write all docs in headers, but then the headers get to be large, take storage space

[Development] Marking the Tech Preview APIs as such

Hi, A number of classes and functions that are going to be introduced in 6.7 are meant to be "tech preview", and thus they may pass the header review even if we are aware of some limitations or issues with their design. I propose to introduce a macro, QT_TECH_PREVIEW_API (bikeshed please),

Re: [Development] Multiple QML engines with different import paths, file selectors, etc

On 09/01/2024 10:49, Ulf Hermann via Development wrote: So, to clarify this some more ... If: 1. you use_multiple_ QML engines in the same process at the same time, 2. you have_different_ import paths, plugin paths, URL interceptors or network access managers for those engines, 3. you rely on

Re: [Development] QML Rectangle corner radius API for Qt 6.7

Il 22/12/23 17:08, Pierre-Yves Siret ha scritto: I wouldn't want a radii grouped property just because of its name. I much prefer writing topLeftRadius: 10 than radii.topLeft: 10. The pedantic latin syntax doesn't help with the readability. Maybe that's just because I am not a native English sp

Re: [Development] QML Rectangle corner radius API for Qt 6.7

Il 22/12/23 11:15, André Somers ha scritto: I can see two options. The simplest option is to have a `radii` property, which is a grouped property containing the `topLeft`, `topRight`, `bottomLeft` and `bottomRight` properties as a floating point value as we have now. I think that would be cleaner

Re: [Development] Request for early MOC support for C++20 Modules

Il 15/12/23 21:33, Thiago Macieira ha scritto: Is the file format for the imported modules already standardised? Is it in the C++ standard? I don't remember seeing it there. If it's not a standard (ISO C++ standard or otherwise), we'd need to write format parsers for each compiler, which raises

Re: [Development] 6.7 FF vs. C++20 comparisons

Il 13/12/23 18:36, Thiago Macieira ha scritto: On Wednesday, 13 December 2023 08:46:57 -03 Marc Mutz via Development wrote: The question I have, therefore, is the following: is converting more classes to the new framework considered a feature as in "affected by FF"? I'd say simple changes shoul

Re: [Development] Houston, qint128 has a problem

Il 09/12/23 03:51, Marc Mutz via Development ha scritto: After spending countless hours between Ivan and myself fighting GCC's mysteriously-vanishing support for __int128_t (= qint128), it turns out that with -ansi/-std=c++NN, not even the most basic of work: std::is_signed_v is_false_! I repea

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

Il 07/12/23 13:55, Kevin Kofler via Development ha scritto: Why is that Qt's problem? Qt does not and cannot check that all security updates for all dependencies have been applied, even when using a branch supported by upstream, so I do not see why this case would be any different. Because 1) Q

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

Hello, On 07/12/2023 09:50, Ville Voutilainen wrote: Well, this is straightforward in the sense that QNX doesn't support openssl3 yet. Dropping OpenSSL1 support is dropping support for TLS on QNX, and we don't want to do that. Sure, this is the premise of my mail, revert the change. What abou

Re: [Development] Future of java-style iterators?

Hello, Il 05/12/23 22:15, Mathias Hasselmann via Development ha scritto: would QDirIterator[1] be part of this deprecation? Its API clearly seems be inspired by the Java-style iterators. While I do not care much about the other Java-style iterators, I really like this iterator and use it a lot.

Re: [Development] Future of java-style iterators?

Il 05/12/23 03:52, Kevin Kofler via Development ha scritto: Marc Mutz via Development wrote: Until then, either you want to be notified of sub-optimal APIs asap, What is "suboptimal" about Java-style iterators, other than that they do not work the same way as the STL ones? I find the Java-style

Re: [Development] Future of java-style iterators?

Hello, On 03/12/2023 21:56, Christian Ehrlicher wrote: Some days ago we got an error report in the forum about QHashIterator, turned out to be a missing documentation for a complete class which remained unnoticed since Qt 6.0 (https://bugreports.qt.io/browse/QTBUG-119461). This leads to the ques

Re: [Development] Proposing new Qt Creator module: Qt Creator Solutions

On 30/11/2023 19:39, apoenitz wrote: I propose to make this setup an official Module of Qt Creator, and herewith also nominate Jarek as Maintainer. Jarek has been pushing the idea and is the author of the biggest existing Qt Creator Solution: TaskTree[2], so for me this is the obvious choice. Co

Re: [Development] Removal/deprecation of OpenSSL 1 in Qt

Il 30/11/23 11:49, Giuseppe D'Angelo via Development ha scritto: 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, Orthogonal but related, the patch kind of expo

[Development] Removal/deprecation of OpenSSL 1 in Qt

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.

Re: [Development] C++20 comparisons @ Qt (was: Re: C++20 @ Qt)

Il 14/11/23 09:12, Marc Mutz via Development ha scritto: Given that this is an API that is going to stay with us for at least a decade, I'd rather get it right than getting it soon. We're discussing various tangential aspects for half a year now. At some point, all the cards are on the table and

Re: [Development] Removal of Non-deprecated API Elements in v6.6.0

On 19/10/2023 12:07, Phil Thompson via Development wrote: Up until v6.6 upgrading to a new version was relatively low risk but this will just encourage people to stay on older versions. Is this a mistake or a change in policy? There is actually a policy document that says that certain source b

Re: [Development] Copying a struct the easy (perhaps too easy) way

Wrong mailing list? Il 16/09/23 01:41, Henry Skoglund ha scritto: S a; S b = a.clone(); it seems to work like a charm (6.5.2 on Linux and the Mac. 5.15.2 on Windows) but my question is if it's kosher? You class has value semantics, so: S b = a; I have bad memories from my MFC days in the

Re: [Development] Nominating Ahmad Samir for approver

On 12/09/2023 14:00, Marc Mutz via Development wrote: I would have a waited a bit longer with the proposal, but considering what little Qt code some TQtC approvers have under their belt... Hell, YES! Ahmad has more than earned his stripes. He's persistent, patient and industrious to the point tha

Re: [Development] Using DMA instead of SHM in non OpenGL apps (Linux/Wayland)

Hi, On 25/08/2023 12:34, Vlad Zahorodnii wrote: I'm really curious here, and these aren't rhetorical questions: why would anyone expect to be a difference in performance, as far as QPainter is concerned? Isn't it ultimately just using a CPU-based renderer onto a block of memory? Why should it ma

Re: [Development] Using DMA instead of SHM in non OpenGL apps (Linux/Wayland)

On 24/08/2023 21:37, Eduardo Hopperdietzel wrote: The results show that there's no significant difference in the time it takes for read and write operations using QPainter in SHM and DMA maps. I'm really curious here, and these aren't rhetorical questions: why would anyone expect to be a diffe

Re: [Development] BC/SC in patch releases

On 24/08/2023 17:36, Volker Hilsheimer wrote: On platforms where Qt is a system library, being able to at least launch your application if the system has a lower patch level than what the binary was built against sounds nice. But in practice, it’s rolling dice - the application might work fin

Re: [Development] BC/SC in patch releases

On 22/08/2023 23:27, Marc Mutz via Development wrote: We have https://community.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B for backwards binary compatibility issues and we have https://contribute.qt-project.org/quips/6 for acceptable and unacceptable backwards source compatibil

Re: [Development] std::optional for Q_PROPERTY

On 21/07/2023 11:01, Volker Hilsheimer via Development wrote: How about conversion: I, for one, would like to stop seeing magic conversions added into QVariant, and keep breaking stuff at every Qt major release because we realize we went overboard and have to remove features. Now, one coul

[Development] Module maintainers: QT_NO_CONTEXTLESS_CONNECT in your modules

Hi, https://codereview.qt-project.org/c/qt/qtbase/+/487560 introduces QT_NO_CONTEXTLESS_CONNECT , a macro that disables the 3-arguments connect -- in other words, it disables the QObject::connect(sender, signal, functor) overload, leaving only 4/5 argument(s) overloads QObject::connect

Re: [Development] API style guide: scoped enum or not?

Il 14/06/23 14:59, Marc Mutz via Development ha scritto: A) new enums MUST have an explicit underlying type¹² For unscoped enums, the compiler otherwise picks one, possibly resulting in BiC when new addtions change the underlying type or otherwise just warnings because one compiler uses a signed

Re: [Development] C++20 ctor-level [[nodiscard]] (was: Re: C++20 @ Qt)

On 16/06/2023 18:00, Thiago Macieira wrote: On Friday, 16 June 2023 01:06:33 PDT Stephen Kelly wrote: Make sure you're not hitting https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96117 We are indeed hitting that. But there's nothing we can currently do about it. Why can't we turn Q_DECL_EXPORT

Re: [Development] API style guide: scoped enum or not?

Il 14/06/23 22:15, Volker Hilsheimer via Development ha scritto: -1 to B from me as well. We can allow unscoped enum as an acceptable (if explained) exception from the rule of using scoped enums. Otherwise we remove a tool from our toolbox, even if it has it’s uses in certain (increasingly rar

Re: [Development] Recommended way to take in strings

On 10/06/2023 09:40, A. Pönitz wrote: For the "rare": I'd like to re-iterate that introducing the/first/ overload for/anything/ is source-incompatible. I was reminded/again/ of that after updating to current Qt dev and finding out the hard way that some code that compiled for ages (using "&QV

[Development] FF exception for QMultiMap/Hash support in Qvariant

Hi, https://codereview.qt-project.org/c/qt/qtbase/+/308602 has been "ready" for a while, but got stalled because I'm unsure I want to implement the proposed changes. I'd like QVariantMultiMap and QVariantMultiHash to be first-class, just like QVariantMap and QVariantHash. That includes a const

Re: [Development] API style guide: scoped enum or not?

Il 04/05/23 09:10, Marc Mutz via Development ha scritto: With the same trick that C++20 did for std::memory_order? That's an additional step we can take, but if clang-tidy has a modernize-scope-enums (or we could write it), then it would be preferable to just automatically port all users instead

Re: [Development] API style guide: scoped enum or not?

Il 04/05/23 15:51, Sune Vuorela ha scritto: On 2023-05-04, Marc Mutz via Development wrote: that keeps unported code running. The main issue isn't the scoping, the main issue will be the missing implicit conversion to underlying_type. In few cases the implicit conversion to underlying_type is

Re: [Development] Nominating Edward Welbourne as QLocale / date/time maintainer

Il 04/05/23 12:10, Marc Mutz via Development ha scritto: Hi, I'd like to nominate Eddy as the maintainer for the QLocale and src/corelib/time QtCore subsystems. Eddy is filling that role de-facto already; making it de-jure sounds only logical. I asked, and he'd be on board, if we'd have him. A

Re: [Development] API style guide: scoped enum or not?

Il 02/05/23 10:58, Volker Hilsheimer via Development ha scritto: During the header review, but also in API discussions leading up to it, we had a few cases where it would have helped if we had clearer guidelines about when to use scoped enums, and when not. Scoped enums have some clear technic

Re: [Development] Changes to QObject::connect and other functor-taking API implementations

Il 02/05/23 12:34, Volker Hilsheimer via Development ha scritto: What started as an attempt to provide a few building blocks for making it easier to build asynchronous APIs taking any kind of callable (like QTimer::singleShot or QHostInfo::lookupHost) [1] has turned into a bit of a longer jou

Re: [Development] libQt6Core.so links against both libpcre.so.3 and libpcre2-16.so.0

On 08/03/2023 11:16, Marc Mutz via Development wrote: I assume they live in different "namespaces" and so it's ok to link both? Well, they're C libraries, so no namespaces, but the functions have different names. For each XXX function in the library: * PCRE1 uses pcre_XXX for the 8 bit vers

Re: [Development] Do we need VS2019 for Qt 6.6?

On 30/01/2023 09:07, Allan Sandfeld Jensen wrote: I would add my support to removing it from 6.6, It would simplify the continued updating of Chromium that is starting to depend on c++20 features that doesn't work well in VS2019. Out of curiosity, how does this interact with the plans of having

Re: [Development] New Qt example development guideline and revamping examples

Il 19/01/23 10:27, Tor Arne Vestbø ha scritto: All the contrary, do NOT do that, as it results in 200+ lines unnamed lambdas. Strongly prefer named slots. Keep the lambdas short and to the point. Do not use unnamed lambdas. No, strongly prefer lambdas if they are within a reasonable size. No-o

Re: [Development] New Qt example development guideline and revamping examples

Il 18/01/23 17:10, Kai Köhne ha scritto: (A nasty feature of uic is btw that it also does generate C++ code inside QT_BEGIN_NAMESPACE, QT_END_NAMESPACE. That is, if you have a .ui file for a Dialog, and you want to pre-declare the type generated by uic, you have to also put it in QT_BEGIN_NAME

Re: [Development] New Qt example development guideline and revamping examples

Il 18/01/23 17:10, Kai Köhne ha scritto: Do not use QT_BEGIN_NAMESPACE ... QT_END_NAMESPACE for example types. This namespace is exclusively for types in the Qt libraries. This is broken. How is one going to correctly forward declare Qt names in a namespaced build of Qt without using those

Re: [Development] New Qt example development guideline and revamping examples

On 18/01/2023 10:51, Kimmo Leppälä via Development wrote: Also, the guideline is a living document in wiki and we would be happy to hear feedback and proposals for it! Here's a few considerations: RECOMMENDED Consider also compiling with the more strict warning flags and fix any issues th

Re: [Development] Update on C bindings idea

On 13/01/2023 02:38, samuel ammonius wrote: Hello, About a year ago, I emailed here asking if C bindings could be added to Qt's official repo, and since then I've written a pretty large python script that generates the wrappers by reading Qt's header files. I originally thought that "inline e

Re: [Development] How to fix TableView's API break?

Hi, Il 19/12/22 18:21, Richard Gustavsen ha scritto: Does anyone know? The rationale behind it is that you normally would like to address a cell in a table using x, y coordinates. x maps horizontally and y maps vertically (to be consistent with e.g Item.x and Item.y). This means that x maps

  1   2   3   4   5   6   >