[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

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

[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

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. *

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

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

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 what

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.

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

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

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

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

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

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

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

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

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)

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

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

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

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

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.

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 exposed

[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

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

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

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

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

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

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

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

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

[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

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

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

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

[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

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

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.

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

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

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

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

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.

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

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

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

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

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

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

On 19/12/2022 11:18, Richard Gustavsen wrote: Item itemAtCell(int column, int row) positionViewAtCell(int column, int row, PositionMode mode, point offset, rect subRect) To me this is quite weird. This must be the *only* place in Qt model/view APIs where (column,row) is used instead of

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

Hi, Between 6.3 and 6.4 there's been an API break in QtQuick's TreeView: its modelIndex(row,column) function got moved into its base class (TableView), and the arguments swapped for it, so now it's TableView::modelIndex(column,row). This is of course an API break, and needs to be fixed.

Re: [Development] Updates to QUIP-6: Acceptable Source-Incompatible changes

On 16/12/2022 22:49, Marc Mutz via Development wrote: The recent episode with qVersion() moving from qglobal.h to qlibraryinfo.h, a header not included in qglobal.h, has shown that QUIP-6 SiC A are too broad a category. As per QUIP-6, I'm proposing to add a new entry to the table that bans

Re: [Development] How qAsConst and qExchange lead to qNN

Il 10/11/22 20:27, Thiago Macieira ha scritto: (We end up with these overload sets because right now we have tons of f(QString), and we're slowly moving them to f(QStringView) if it does make sense for them. Due to the BC promise we can't just_remove_ f(QString).) And we shouldn't. So we

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

Il 10/11/22 09:25, Marc Mutz via Development ha scritto: unconditionally and we will detect post-C++17 library features only this way, going forward: #ifdef __cpp_lib_foo # include #endif and no longer this way: #if __has_include() && __cplusplus > 201703L # include

Re: [Development] How qAsConst and qExchange lead to qNN

On 09/11/2022 20:25, Thiago Macieira wrote: Our API should default to passing QStrings for simplicity and not to confuse the user. The fact that I cannot wrote: foo(u"bar'); if foo takes a QString is MESSED UP. Is this because we deliberately didn't add a QString(const char16_t *)

Re: [Development] Print Screen does not work with Qt context menus

Il 19/10/22 17:50, Thiago Macieira ha scritto: Welcome to X11. Menus work by grabbing the keyboard and mouse exclusively so they can be dismissed if you click outside of it or press any key. That means the menu is eating the Print Screen button. To screenshot a menu, configure your screenshot

Re: [Development] QTranslator - line feed character

On 11/10/2022 11:19, EXT Panajotis Daras via Development wrote: I wanted to ask whether the current behavior in the translation module is correct. In short, the question is about the line feed character in the translation file: // hellotr_la.ts file    

Re: [Development] Nominating David and Eskil as Qt Wayland maintainers

Il 24/08/22 13:24, Thiago Macieira ha scritto: +11 (because it's two people) +1x2 (Jokes aside: +1 to these nominations). Thanks, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53,

Re: [Development] Challenge: adding new method overloads when existing consumers use {} with args

Hi, On 30/07/2022 14:13, A. Pönitz wrote: Ultimately, I think that we simply don't "really" deal with this particular problem, and may accept the SIC. For instance, if we add a QStringView overload to a function taking QString, this is a SIC but I don't think we would reject the addition. I

Re: [Development] Challenge: adding new method overloads when existing consumers use {} with args

On 28/07/2022 22:54, Thiago Macieira wrote: This case can be considered a Category B source incompatible change as per https://quips-qt-io.herokuapp.com/quip-0006.html, because it clearly introduces ambiguity. But {} is particularly special, so I don't know how we'd deal with it. I don't think

Re: [Development] [Announce] Security advisory: Freetype in Qt

Hi, On 27/07/2022 22:23, Thiago Macieira wrote: On Wednesday, 27 July 2022 11:47:20 PDT Giuseppe D'Angelo via Development wrote: Right now, if one selects "LTS" and "Latest releases" (and *not* "Archive"), one gets * 6.3.1 * 6.2.4 * 5.15.2 all of which are b

Re: [Development] [Announce] Security advisory: Freetype in Qt

Il 27/07/22 16:53, Thiago Macieira ha scritto: On Wednesday, 27 July 2022 05:20:59 PDT Giuseppe D'Angelo via Development wrote: Does this mean that the currently available opensource binary downloads (through the official installer) of Qt 5.15(.2) and 6.2 are affected by the CVE

Re: [Development] [Announce] Security advisory: Freetype in Qt

Hello, Il 27/07/22 14:00, List for announcements regarding Qt releases and development via Development ha scritto: These effects configurations of Qt that have been built against the bundled version of FreeType. If you are using a pre-built version of Qt then this will be using the bundled

Re: [Development] Rvalue pinning in Qt

Hi, On 20/06/2022 17:39, Thiago Macieira wrote: On Monday, 20 June 2022 07:46:57 PDT Giuseppe D'Angelo via Development wrote: A fancy name for: "if a function/class is operating on a rvalue, should it store a copy of it in order to keep it alive?". Consider In other words, remove

[Development] Rvalue pinning in Qt

Hello, In the discussion for QTBUG-103940 it has been pointed out that we did not have a formal discussion regarding rvalue pinning in Qt facilities. We are actually inconsistent in its support, as we do use it in some places and do not use it elsewhere.

Re: [Development] QPushButton: drag and drop

On 10/06/2022 06:48, Laszlo Papp wrote: I do not know what you mean. From what I can see, it is not going to break anything. Those customers who worked around the design flaw, in my opinion (you are free to disagree of course), they will not notice the fix because they have not started

Re: [Development] QPushButton: drag and drop

Hi, On 09/06/2022 17:20, Volker Hilsheimer wrote: Let’s put things into a perspective here. You are proposing a flag that we perhaps flip on by default within Qt 6, and that might break a whole ton of widgets out there that today correctly implement drag’n’drop and that will start failing in

Re: [Development] Asking for a FF exception for ICU based QStringConverter

Hi, On 09/06/2022 11:57, Fabian Kosmale wrote: QSettings doesn't have a way to change the codec at all as far as I can tell, and is UTF-8 only, so I'm not sure how relevant that is for the discussion. Just replying to this point: it's another API that used to accept an encoding in Qt 5

Re: [Development] Asking for a FF exception for ICU based QStringConverter

Il 09/06/22 01:48, Thiago Macieira ha scritto: d) Because if this, code using QStringConverter with non-builtin encodings will leak resources unless it's recompiled for 6.4. No source changes are necessary. I am saying that (d) is an acceptable situation because of (a) and (b), and in spite of

Re: [Development] Asking for a FF exception for ICU based QStringConverter

Hi, On 08/06/2022 18:40, Thiago Macieira wrote: On Wednesday, 8 June 2022 07:17:29 PDT Fabian Kosmale wrote: - There are concerns that mixing Qt versions might lead to an unbounded memory leak with the current implementation. I don't think that's actually the case (but if it is, then we need a

Re: [Development] Qt 5.15.10 LTS Commercial released

On 08/06/2022 07:58, Tuukka Turunen wrote: Hi, The release notes are stored within Qt Account (under Downloads, select /Product: Qt/ and /Version: 5.15.10/), i.e. one needs to have a commercial license to see those. Is there any reason not to publish them as usual in dist /

Re: [Development] QPushButton: drag and drop

Il 07/06/22 20:57, Laszlo Papp ha scritto: Just checked the Qt wiki, but it does not seem to speak about this rule. Only binary and source compatibility. No behaviour compatibility. And by the way, fixing the bug to match the documentation and therefore intended behaviour would not even be

Re: [Development] 回复: QPushButton: drag and drop

On 06/06/2022 10:49, Zhang JiDe wrote: I agree that we should fix this, but it's not as simple as passing the mouseReleaseEvent to the QPushButton, but we should make sure that for a QWidget, whatever happens, the mouse press and release are paired, always notify the mouse release to the

Re: [Development] Qt/Quick and VNC [ was: damage tracking ... ]

Il 04/06/22 19:59, Uwe Rathmann ha scritto: [ Giuseppe D'Angelo wrote: ] Properly signalling damage areas has a lot of interesting use cases, from compositors to efficiently enable remoting solutions (frame streaming/VNC/etc.). Well, Qt/Quick is usually for modern user interfaces with smooth

Re: [Development] QPushButton: drag and drop

Il 04/06/22 00:39, Shawn Rutledge ha scritto: This might resemble the case when a TouchCancel event is sent: it means the receiver should be un-pressed, undo whatever was done on press, and don’t react otherwise (e.g. a Button does not get clicked, it’s just not pressed anymore). This is an

Re: [Development] QPushButton: drag and drop

On 03/06/2022 23:05, Volker Hilsheimer wrote: If we were to deliver a mouseReleaseEvent to the widget that initiated the drag via QDrag::exec after the exec returns, then we handle the mouseReleaseEvent twice. Why twice? It receives only one? Note that the infrastructure for sending a

Re: [Development] QPushButton: drag and drop

On 03/06/2022 14:20, Laszlo Papp wrote: I do not know the details very well, but from a user point of view, it would be good to either let mouseReleaseEvent get triggered as usual after the dragging has finished or at least not to have artifacts like the above around. I have also noticed

Re: [Development] Do we have some plans about the damage tracking of QtQuick's scene graphics?

On 02/06/2022 12:53, Shawn Rutledge wrote: In Qt Quick the strategy has been to build a complete scene graph for all the contents of all visible items that you declared, and during rending, the SG nodes that are not visible get culled; so we didn’t have anything like QPaintEvent::region() to

Re: [Development] QtCS2022 - Sessions and Timeslots

Hi, Il 19/05/22 18:43, Pedro Bessa ha scritto: Hi everyone, Thank you for submitting your sessions. I kindly ask you to now add your session to a desired timeslot. Just its title is necessary; I will merge our tables later. Please keep in mind a few things: * taking feedback into

Re: [Development] QtCS2022 - Sessions and Timeslots

Hi, On 19/05/2022 18:52, Giuseppe D'Angelo via Development wrote: * could it be possible to adjust the timeslots in order to optimize for the majority of the developers, who are in the CEST timezone? Rechecking the wiki page, I think there's a confusing bit of information that threw me off

Re: [Development] QtCS2022 - Sessions and Timeslots

Hello, Il 19/05/22 18:43, Pedro Bessa ha scritto: Thank you for submitting your sessions. I kindly ask you to now add your session to a desired timeslot. Just its title is necessary; I will merge our tables later. Please keep in mind a few things: * taking feedback into consideration,

Re: [Development] QRect::contains and undocumented(?) edge

On 21/04/2022 16:09, Thiago Macieira wrote: It has some unintuitive defects and flaws, but they can't be fixed because this class is OLD. We can improve documentation, but that's all. If drawing the chess board as a stand-in for the pixel helps understand, then it might be a good idea. There

Re: [Development] QRect::contains and undocumented(?) edge

Hi, On 20/04/2022 17:50, Tomi Pannila wrote: thank you for the explanations. I guess Eirik kind of guessed right that I view QRect from $\mathbb{R}^2$ point of view. I'm a mathematician and this is the most natural point of view for me. For me, rectangles have edges=boundary which are measure

Re: [Development] Qt UDL operators

Hi, On 05/04/2022 14:28, Sona Kurazyan wrote: I'm not sure how this work: unless the new _s takes another kind input (e.g. number literals), you can't add it no matter what, as users under "using namespace Qt;" would then get a conflict...? Right, it will work only if the types of the

Re: [Development] Qt UDL operators

Hi, Il 04/04/22 15:53, Sona Kurazyan ha scritto: I see two main issues with keeping both: - If we want to add UDLs with same names for different domains in future, adding the "q"-prefixed counterparts will be problematic. For example, let's say we want to add Qt::inline Literals::inline

Re: [Development] Qt UDL operators

Il 30/03/22 15:44, Sona Kurazyan ha scritto: # keep _qs, _qba, add _qL1, keep Qt::StringLiterals::_L1, add Qt::StringLiterals::{_s, _ba} (https://codereview.qt-project.org/c/qt/qtbase/+/402948 +

Re: [Development] Proposals for changes to "Precheck" feature

On 25/03/2022 17:54, Alexandru Croitor wrote: I would prefer a comment-based precheck system instead, and keep the existing precheck as-is. https://bugreports.qt.io/browse/QTQAINFRA-4419 See also the other ideas in that bug report, most notably also allowing to somehow select a subset of

Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

On 16/02/2022 01:21, Thiago Macieira wrote: On Tuesday, 15 February 2022 11:37:30 PST Giuseppe D'Angelo via Development wrote: First and foremost, does anyone know whether QtWayland is under any BC promise at all? The question must be turned around: does anyone know of an explicit exception

Re: [Development] Requesting forward BC exception for QtWaylandCompositor in 6.2 and 5.15

On 15/02/2022 16:54, Marc Mutz wrote: So, I'd like to ask for permission to add the full set of {mut, const} × {==, !=} × {mut, const} to 6.2 and 5.15 (two are present, so six are missing), and then rebasing https://codereview.qt-project.org/c/qt/qtwayland/+/395784

Re: [Development] Proposing to officially allow C++20 types in Qt 6 ABIs

On 31/01/2022 17:36, Thiago Macieira wrote: On Monday, 31 January 2022 05:23:45 PST Giuseppe D'Angelo via Development wrote: 1) Does a build of Qt default to C++17 or C++-latest? Qt 5 did the latter, Qt 6 does the former. I would be fine at restoring C++-latest, with command line switches

  1   2   3   4   5   >