Re: [Development] Deprecation/removal model going into Qt 6
On Wed, Jun 5, 2019 at 9:44 PM André Pönitz wrote: > On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote: > > 2. Delete all uses of the deprecated API from Qt itself > > ... and that *before* the deprecation happens. > > Lately the deprecations left Qt in a state that was still using deprecated > API all over the place, with the people driving the deprecation generally > leaving "fixing" Qt itself and other Qt Project to others. > > To put it bluntly: I consider this anti-social behaviour that is absolutely > *not* in line with the spirit of the Qt Project. > I'd have to agree on that. In general that is, because there are some cases where it's not possible; e.g. when the deprecated class/function is exported for the user and due to our compatibility promises we can't remove it immediately. Before we require the user to clean up their house it'd be really in line for us to do the same. Not to mention that leaving usage of deprecated APis inside the library unnecessarily creates technical debt, which is going to bite sooner or later; if we are lucky, sooner rather than later. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Wednesday, 5 June 2019 13:36:01 PDT André Pönitz wrote: > > Yes, I've complained that most distros can't seem to compile them to be > > compatible correctly. But that's not Qt's problem that one (or most) of > > them fail to do their job properly. > > It's not "Qt's problem" per se, but it's becoming the problem of Qt _users_ > once Qt is not shielding them anymore. Technically true, but I don't think it's actually a very relevant fact, for two reasons: 1) no one really wants to mix C++ standard libraries, despite the option being there 2) the boat has sailed: people use other libraries like Boost that do use C++ Standard Library API, which means those codebases are already affected > > In a properly configured environment, there could be users who want to > > perform this mixing. > > > > But no, I don't think we should use that as an argument for avoiding > > Standard Library API in our classes. > > Neither me, actually. But it should also not serve as an excuse to run a > "quixotic crusade to de-Qt Qt" [1] I agree with you. You know I dislike the Standard Library API and I really wish not to read ".empty()" in Qt code and wonder if that is in the imperative. After all, if it's ok for "clear", why not "empty"? But I am not in the mood for reimplementing perfectly good API. I may find that std::chrono is overengineered, but it is something I can work with. And I am not above wrapping bad Standard Library API when I think we can do better. Quod vide QRandomGenerator. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Wed, Jun 05, 2019 at 01:41:25PM +0200, Mutz, Marc via Development wrote: > On 2019-06-05 10:40, Edward Welbourne wrote: > [...] > > If some things are deprecated and never removed (QRegEx springs to > > mind), while others get removed (comparably) soon after deprecation > > (e.g. everything we're currently deprecating with intent to remove in Qt > > 6), maintainers of client code get mixed signals. The slow removals may > > give them an impression that they can take their time, that'll lead to a > > violation of the principle of least surprise when they trip over one of > > the fast removals having suddenly gone away. > > There are no mixed signals. I see no contradiction in deprecating QRegExp > and keeping it around for a lng time. See the other thread. Deprecation > means the API is bad, for a certain definition of bad. Keep using it at your > own peril, think twice before you do, but do keep using it if that's what > you must do (like Qt itself uses QRegExp). Wrong. The "mixed signal" here is that someone in an ivory tower decided to deprecate something but was not able to offer a viable alternative. Either because there simply was none (in which case the deprecation was wrong, and should be undone) or because the work-around was too much hassle (in which case the deprecation was wrong, and should be un-done) or for some other reason that nobody cited so far. As a matter of fact, some of the previous deprecations, e.g. the removal of qalgorithm, triggered re-implementing the deprecated functionality downstream, effectively shifting the burden of doing (or, rather, *keeping*) them once centrally to all users who need it decentrally. All in all, this is devaluating the overall Qt offering. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Tue, Jun 04, 2019 at 09:58:18PM -0700, Thiago Macieira wrote: > On Tuesday, 4 June 2019 12:57:36 PDT Mutz, Marc via Development wrote: > > You talk about a particular incarnation of stdlibs, I was talking about > > the general case. Yes, in the case you describe, and _if_ libc++ is > > configured to be compatible (which in the past you have complained is not > > done correctly), then it may work. But take STLport vs. Rougewave on > > older SunCC. Or Dinkumware vs. GCC on QNX. > > Yes, I've complained that most distros can't seem to compile them to be > compatible correctly. But that's not Qt's problem that one (or most) of > them fail to do their job properly. It's not "Qt's problem" per se, but it's becoming the problem of Qt _users_ once Qt is not shielding them anymore. And once that happens, Qt's utility for those user decreases, and *that* in turn *might* become Qt's problem. I am not saying it *will*, but it's a thing that needs to be taken into consideration. And so far all real world data points I have is that the ongoing deprecations are a major pain, continously eating into *my* time, and none of the alledged advantages *including run time performance* ever came to state where it was noticable, let alone obvious, in my daytime work, which incidentally happens to a large degree within Qt Project code. > In a properly configured environment, there could be users who want to > perform > this mixing. > > But no, I don't think we should use that as an argument for avoiding Standard > Library API in our classes. Neither me, actually. But it should also not serve as an excuse to run a "quixotic crusade to de-Qt Qt" [1] > For example, we should use std::unique_ptr. ... "when it makes sense". Not just because of IFONP. Andre' [1] See https://valdyas.org/fading/hacking/happy-porting/ for a definition. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
AFAIK -R . is used to load that icu libraries I told you about in Gerrit. Otherwise it will try to load the system ones instead of the shipped ones with Qt. > 5 июня 2019 г., в 14:46, Richard Weickelt написал(а): > >> Excellent yes. That was a recent addition to the installer framework, >> very useful for exactly that purpose. > > Thanks for _all_ replies! Actually, the configure command line in the COIN > logs differs from > https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config?h=v5.12.3-packaging > so I rather used the ones from the COIN logs. > > Could somebody explain why the Linux release explicitly specifies "-R ." as > configure option? I have never seen that being used before. > > Richard > ___ > Development mailing list > Development@qt-project.org > https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Tue, Jun 04, 2019 at 06:45:26PM +0200, Mutz, Marc via Development wrote: > = The meaning of deprecation > > I think of deprecation as a means to tell users that the designers of the > deprecated API think that there is some deep flaw in the API that makes it > harder to use correctly or easier to use incorrectly. Or lacking in any > other desirable software quality realm, and yes that includes performance. Correct. That *includes* (run time) performance. But it also includes other aspects, like API consistency, time to market, cost of maintenance, etc. etc. Different people certainly weigh different aspects differently, but in no case we are in a situation where "run time performance trumps everything". > One important aspect of deprecation, IMO, is that the deprecated API will be > less likely to be properly maintained. So, e.g. by deprecating QLinkedList, > we tell the users that we do _not_ intend to make it feature-compatible with > std::list, e.g. by adding splice(). Deprecating the class is plain overkill for that, it it positively hurts as it makes the Qt offering (and this includes, *again*, a consistent API) less complete. All that's required for "telling the user" is one sentence in the docs, even exactly the one you've just used. > Users may continue to use the class, but they will not enjoy the same > progress that other Qt classes or std::list will exhibit. The continued use would be possible without the deprecation. > I don't think, that, apart from the usual nay-sayers who don't want anything > to change, but also don't contribute, there's much disagreement over how and > what to _deprecate_. I am afraid you are completely wrong on this one, too: You apparently aim at deprecating anything that's not part of your personal usage pattern and/or that is designed to strike another balance between run time performance, maintenance cost, API consistency etc. than the one you personally prefer (which is, I take, "run time performance is all that counts"). There's fundamental disagreement with your views on the reasons of deprecation as such, and this attempt to stamp "naysayers" as irrelevant one way or the other shows a fundamental misunderstanding of the Qt Governance Model, which specifically mentions "Giving the community feedback" as a "Common User contributions". So everyone you try to mark as "naysayer" here is _by definition_ contributing. > = The deprecation life-cycle: > > The question really is: if an API is deprecated, then what? We have, so far, > removed deprecated APIs from the library, or moved it to a QtXSupport > library, which later got removed, too. I think the most Angst comes from the > removal part here. > > Let me try to define the deprecated API lifecycle as follows (dare I call it > 4D? :) > > 1. Deprecate the API in Qt vX.Y, add the new API (if any, some APIs many > simply move down a storey into C++, like Q_FOREACH vs. ranged for-loops; > sometimes, Qt will realise that it's not able to support some API any > longer, like XMLPatterns, or, I'd say, Q*SharedDataPointer) > > 2. Delete all uses of the deprecated API from Qt itself ... and that *before* the deprecation happens. Lately the deprecations left Qt in a state that was still using deprecated API all over the place, with the people driving the deprecation generally leaving "fixing" Qt itself and other Qt Project to others. To put it bluntly: I consider this anti-social behaviour that is absolutely *not* in line with the spirit of the Qt Project. [...] > = Summary > > We should come to a conclusion about the meaning of deprecation, the > life-cycle of deprecated APIs (e.g. how maintained are they, from > deprecation to decommissioning?), the time-spans between the four D's, and, > as a corollary, the weakening of our BC guarantees to exclude deprecated > API. Fine. > Personally, I have no problem with disentangling the API sooner, like > vX.(Y+3) Fine with me in principle, except that I'd suggest to only consider LTS releases for Y. > Personally, I also have no problem with decommissioning the API later (like > not drop stuff first deprecated in vX.Y before v(X+2).0), but this does not > seem to be the plan atm. *dropping* deprecated API should noy happen in minor releases, except when there's strict consensus on the list to do that. > But once an API has been identified as ... for want of a better word: bad, > and a better alternative added, we should never hesitate to deprecate the > old one. Only when there's consensus what "bad" means. And please note that consensus is not established as long as there are "naysayers" that you chose to dismiss. Andre' ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Views
On 2019-05-16 20:18, Mutz, Marc wrote:
[...]
[1] Paraphrasing what Alex Stepanov teaches in his A9 courses: No C
programmer would _ever_ get the idea to use a self-rebalancing
red-black tree for something that holds a dozen elements. Because once
you understand what is required to implement one, you'd shy away from
the sheer complexity. Yet, in C++, just typing QMap makes the compiler
do all that stuff for you. Don't use a map or a hash just because you
can and the API is convenient. Use it when it makes sense, given what
data is expected to be stored. And you will invariably end up with
using vectors all over the place. According to Stepanov, developers
wishing to use a map should seek a face-to-face meeting with their
manager to explain why they need it :)
If you ever needed more convincing than an Alex Stepanov quote:
https://codereview.qt-project.org/c/qt/qtwayland/+/264069
I repeat here what I said in the commit message, only stronger:
As a library implementer, you are simply not _allowed_ the freedom to
use a convenient tool over the most efficient one. That is, to put it
mildly, a disservice to users and a disgrace to the profession of
programmers. 8KiB just to look up a pointer in a map of {string, int}?
That's 1/4th of the icache size of many processors!
And I'm not git-blaming to look up who wrote that QMap in the first
place. Qt is *full* of this stuff and you all should really understand
one thing: It's not about _your_ convenience. You are working for your
_users_. And this isn't rocket science. Almost _twenty_ years ago, Scott
Meyers wrote in Effective STL: "Prefer to use a sorted vector".
Is this code performance-critical? Probably not. But ... I mean ... 8
fscking Kilobytes. That's two pages that don't need to be paged in.
Multiply that by a 100 or so uses of QMap in a normal Qt application and
you see where this is going.
Please, think of yours truly what you want, but keep your _users_ in
mind. Users who need to strip down Qt so it fits on their devices
because ... well, because you were too lazy to pick the right data
structure.
Thanks,
Marc
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Wednesday, 5 June 2019 06:31:25 PDT Olivier Goffart wrote:
> That's where inline namespaces could help. (You'd change the name of the
> inline namespace as well so you could link to two libraries that use
> different version of Qt, and it would work. (as long as each of these
> library don't expose Qt in their interface))
Yes and no. Yes, you could use inline namespaces to allow both libraries to be
loaded into memory at the same time.
But this is of limited usefulness if the entire library is namespaced, since
you can't exchange data from one to the other, except using non-Qt data
structures. If you accidentally loaded a plugin linking to the wrong version,
the act of loading wouldn't cause a crash. But you may well do so because
plugins usually have a C interface to provide an access point, which will
cause a loss of the actual type information.
For example, if the plugin has
extern "C" QObject *interface();
and QObject is inline-namespaced into v1 and v2, then if he caller does:
using Fptr = QObject *(*)();
auto init = reinterpret_cast(library.symbol("interface"));
That reinterpret-cast is causing a problem and could cause a crash.
Instead, the entry point needs to carry no C++ symbol, such as:
extern "C" void initPlugin();
And with that, the proper symbols are found by the correct namespaces.
And still cause problems. Imagine one of them needs qApp, but since it's the
wrong version, qApp == nullptr.
Conclusion: you can prevent immediate crash in the case of accidental loading
of the wrong version, but it's still such a horribly bad idea to make that
load, to the point that it's not worth our time.
> Having inline namespace could also in theory then allow to link both with
> Qt5 and Qt6 in the same process.
The ELF symbol versioning can already do that.
> But a namespace has the other inconvenient to break every forward
> declaration.
And that.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel System Software Products
___
Development mailing list
Development@qt-project.org
https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
Den ons 5 juni 2019 kl 12:59 skrev Mutz, Marc via Development : > > On 2019-06-03 14:27, Bernhard Lindner wrote: > >> > > > So, yes, this is borne out of frustration with the lack of > >> > > > maintenance > >> > > > of QtCore plumbing. I don't see that changing and I acknowledge and > >> > > > understand that the focus of development has shifted towards QML. > >> > > Suppose you implement all planned actions for Qt6 (see your original > >> > > e-mail). Are > >> > > the > >> > > remaining components (those that are neither deprecated nor removed) > >> > > of Qt6 well > >> > > maintained and are there enough staff available not only to maintain > >> > > them > >> > > indefinitely > >> > > but to actively develop them further? > >> > > >> > No answer to my question above? > >> > >> Who do you expect an answer to this question from? > >> > >> The Qt Company? The Qt community? Marc? Thiago? > > > > Whoever believes being able to make a realistic assessment. > > > > If there is no such person/group in this list, which can do an > > estimate how much of Qt is > > affordable, an important aspect of the Qt 6 discussion can not > > actually be discussed. How > > can Marc think about removing (or significantly changing) Qt due to > > ressource limits or > > new strategic goals if the limits or goals are unknown? > > > > Actions out of frustration are never a good idea. And pushing into a > > (technical) direction > > that does not solve the underlying (strategical) problem is futile. > > I think it's pretty clear that some parts of Qt thrive (e.g. QString) > and others, incl. the other containers, lag behind. I can't speak for > TQC, but I do wonder where all the manpower that is now proposed to make > Qt containers wrappers around std ones, etc, suddenly should come from > when it was lacking for the last decade. > > An example: The Qt docs made fun of how hard it is to iterate backwards > using STL containers, as opposed to Java-Style ones > (https://doc.qt.io/archives/qt-4.8/containers.html#java-style-iterators), > yet, in roughly the same time it took to write that nonsense, a > developer could have implemented rbegin()/rend() on Qt containers. > Likewise, since I added rvalue-push_back to QVector a few years ago, > no-one stepped up to implement this for everyone's favourite container, > QList. Nor any other Qt container. Not _one_. This, and many other such > instances, show me that the Qt containers are considered good enough, > and there's absolutely no interest in bringing them forward into the > 21st century. If you believe otherwise, prove it. > > But containers are one of the cornerstones of programming, and there's a > reason that we now have emplacement, node_handle, move-only payload type > support, splicing, etc. etc. Where are those functions on Qt containers? > For that matter, why is there no Qt version of std::set? I removed at > lest three implementation of an OrderedSet that used a QMap to > imitate a std::set from QtCore alone. Where is that container, please? > Where is QDeque? Where is QForwardList? Where is the 25-year-old > optimisation that implements Container in terms of Container. > IIRC, even the original STL had that. Where is the const_iterator > overload of QVector::erase()? In particular with CoW, only detaching if > you actually found the object should be something that everyone yearns > for. People complain that std::mutex is slower than QMutex, but they > don't complain that erase(const_iterator) is missing. > > You don't need a crystal ball to see that there's not even enough > manpower to bring in the "recent" (well, C++98 is 20 years ago) changes > from the STL, let alone innovate. > > If users use a QMap because they have an aversion against > std::set, for one reason or another, where _is_ the Qt answer? Since > 4.0, the answer has been "you're on your own". So, the honest answer > would be that Qt doesn't care about it's container classes any more, and > recommends every user to move over to the STL versions where-ever they > can. > > But some people still live in a bubble universe where, contrary to > historic proof, the Qt containers will be made great again, any-time > soon now. Just wait for it... I think you said it near the beginning of your mail: > [...] This, and many other such instances, show me that the Qt containers are > considered good enough [...] I guess that is the case. At least I haven't craved for any of the features you list in the 15 or so year's I've developed with Qt. The plumbing has been good enough both for my personal and professional projects, and I guess that may be the case for many others as well. Don't get me wrong, I absolutely think there are cases where the lack of these container features is a sore point, just wanted to say that I haven't spent a lot of time thinking about it, and the same may be true for many others as well. Elvis > > Thanks, > Marc > ___ > Development mailing
[Development] Use qt5 without udev
Hello Qt community, I am an open source enthusiast and a qt5 beginner. I want to use qt5 in a fast boot linux system and I am searching a way to use qt5 without udev, instead use devtmpfs because the system boots faster. In order to achieve this, I need a parameter in qt5 similar to export QWS_MOUSE_PROTO=Auto:/dev/input/mice but I have not found it. Is there any way to use qt5 to achieve this? Thank you and best regards, L-C. Duca ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On 05.06.19 07:24, Thiago Macieira wrote: On Tuesday, 4 June 2019 10:07:46 PDT Lisandro Damián Nicanor Pérez Meyer wrote: $ objdump -x /usr/lib/x86_64-linux-gnu/libQt5Core.so.5.11.3 | grep SONAME SONAME libQt5Core.so.5 Note the two numbers in the SONAME. They mean two different thing. Right now, they are equal but they don't have to be. The first one, the one that is part of the library name itself, as found in the -l switch to the compiler, is the *source* version. Newer releases of a library that keeps the same source version indicate that they retained source compatibility with older versions of that library. The second one, the one that only appears after you link, is the binary version. Whenever we break source compatibility, that number changes. So we could have libQt6Core.so.0 released in Qt 6.0, then ibQt6Core.so.1 in Qt 6.3. This would allow both libraries to be co-installable, so applications and libraries that haven't been recompiled can still run, without getting broken. However, the two libraries are not loadable at the same time into memory. And there's also no mechanism that would prevent that from happening. So it's entirely up to the distributor or integrator to make sure that is properly done, including by way of a plugin load. If two binary incompatible versions of the same library get accidentally loaded into memory, very weird things will happen, with really hard to debug issues. So, no, I do not recommend doing this. That's where inline namespaces could help. (You'd change the name of the inline namespace as well so you could link to two libraries that use different version of Qt, and it would work. (as long as each of these library don't expose Qt in their interface)) Having inline namespace could also in theory then allow to link both with Qt5 and Qt6 in the same process. But a namespace has the other inconvenient to break every forward declaration. -- Olivier ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
Yes, don't use the ones from this packaging-tools/bld_config thing. That's outdated and certainly not used for Qt 5 releases today. Regarding -R . : This specifies the rpath as a relative path, which enables qmake to use origin rpaths (or equivalents on macos) instead of absolute paths, plus the relative path specified (but as that's a dot it's a noop). Simon From: Richard Weickelt Sent: Wednesday, June 5, 2019 14:46 To: Simon Hausmann; Markus Haberlander Cc: development@qt-project.org Subject: Re: [Development] Configure command lines of official Qt releases > Excellent yes. That was a recent addition to the installer framework, > very useful for exactly that purpose. Thanks for _all_ replies! Actually, the configure command line in the COIN logs differs from https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config?h=v5.12.3-packaging so I rather used the ones from the COIN logs. Could somebody explain why the Linux release explicitly specifies "-R ." as configure option? I have never seen that being used before. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Configure command lines of official Qt releases
> Excellent yes. That was a recent addition to the installer framework, > very useful for exactly that purpose. Thanks for _all_ replies! Actually, the configure command line in the COIN logs differs from https://code.qt.io/cgit/qtsdk/qtsdk.git/tree/packaging-tools/bld_config?h=v5.12.3-packaging so I rather used the ones from the COIN logs. Could somebody explain why the Linux release explicitly specifies "-R ." as configure option? I have never seen that being used before. Richard ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On 2019-06-05 10:40, Edward Welbourne wrote: [...] If some things are deprecated and never removed (QRegEx springs to mind), while others get removed (comparably) soon after deprecation (e.g. everything we're currently deprecating with intent to remove in Qt 6), maintainers of client code get mixed signals. The slow removals may give them an impression that they can take their time, that'll lead to a violation of the principle of least surprise when they trip over one of the fast removals having suddenly gone away. There are no mixed signals. I see no contradiction in deprecating QRegExp and keeping it around for a lng time. See the other thread. Deprecation means the API is bad, for a certain definition of bad. Keep using it at your own peril, think twice before you do, but do keep using it if that's what you must do (like Qt itself uses QRegExp). Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On 2019-06-03 14:27, Bernhard Lindner wrote: > > > So, yes, this is borne out of frustration with the lack of maintenance > > > of QtCore plumbing. I don't see that changing and I acknowledge and > > > understand that the focus of development has shifted towards QML. > > Suppose you implement all planned actions for Qt6 (see your original e-mail). Are > > the > > remaining components (those that are neither deprecated nor removed) of Qt6 well > > maintained and are there enough staff available not only to maintain them > > indefinitely > > but to actively develop them further? > > No answer to my question above? Who do you expect an answer to this question from? The Qt Company? The Qt community? Marc? Thiago? Whoever believes being able to make a realistic assessment. If there is no such person/group in this list, which can do an estimate how much of Qt is affordable, an important aspect of the Qt 6 discussion can not actually be discussed. How can Marc think about removing (or significantly changing) Qt due to ressource limits or new strategic goals if the limits or goals are unknown? Actions out of frustration are never a good idea. And pushing into a (technical) direction that does not solve the underlying (strategical) problem is futile. I think it's pretty clear that some parts of Qt thrive (e.g. QString) and others, incl. the other containers, lag behind. I can't speak for TQC, but I do wonder where all the manpower that is now proposed to make Qt containers wrappers around std ones, etc, suddenly should come from when it was lacking for the last decade. An example: The Qt docs made fun of how hard it is to iterate backwards using STL containers, as opposed to Java-Style ones (https://doc.qt.io/archives/qt-4.8/containers.html#java-style-iterators), yet, in roughly the same time it took to write that nonsense, a developer could have implemented rbegin()/rend() on Qt containers. Likewise, since I added rvalue-push_back to QVector a few years ago, no-one stepped up to implement this for everyone's favourite container, QList. Nor any other Qt container. Not _one_. This, and many other such instances, show me that the Qt containers are considered good enough, and there's absolutely no interest in bringing them forward into the 21st century. If you believe otherwise, prove it. But containers are one of the cornerstones of programming, and there's a reason that we now have emplacement, node_handle, move-only payload type support, splicing, etc. etc. Where are those functions on Qt containers? For that matter, why is there no Qt version of std::set? I removed at lest three implementation of an OrderedSet that used a QMap to imitate a std::set from QtCore alone. Where is that container, please? Where is QDeque? Where is QForwardList? Where is the 25-year-old optimisation that implements Container in terms of Container. IIRC, even the original STL had that. Where is the const_iterator overload of QVector::erase()? In particular with CoW, only detaching if you actually found the object should be something that everyone yearns for. People complain that std::mutex is slower than QMutex, but they don't complain that erase(const_iterator) is missing. You don't need a crystal ball to see that there's not even enough manpower to bring in the "recent" (well, C++98 is 20 years ago) changes from the STL, let alone innovate. If users use a QMap because they have an aversion against std::set, for one reason or another, where _is_ the Qt answer? Since 4.0, the answer has been "you're on your own". So, the honest answer would be that Qt doesn't care about it's container classes any more, and recommends every user to move over to the STL versions where-ever they can. But some people still live in a bubble universe where, contrary to historic proof, the Qt containers will be made great again, any-time soon now. Just wait for it... Thanks, Marc ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Deprecation/removal model going into Qt 6
On Wed, Jun 5, 2019 at 12:57 AM Kevin Kofler wrote: > IMHO, major versions with source compatibility need to actually > live > much LONGER, not shorter. At least 20-30 years, with the time at least > doubling with every new major release. Or just stop doing compatibility > breaks entirely. > This isn't possible by any practical measure. Unless the API design was so good that it encompassed every possible case and it was designed in such a way that nothing changes, then it could live forever (and yes 20 years is forever). Since the API need to get fixed, polished, refactored and improved, compatibility needs to break from time to time. Keeping compatibility is simply not maintainable and honestly a chimera. Can we drop that topic branch now? Shorter binary-incompatibility cycles, no matter whether you call them > major > versions or start breaking binary compatibility in minor versions (ewww!) > are going to make Qt entirely unmanageable for distributions. Somewhat harder. Entirely unmanageable is an unjustified exaggeration. > We already > have to maintain Qt 3, 4, 5, and soon 6. > Actually we have to maintain 5, we should've moved away from 4 (and I personally know that can be a pain for some codebases), and honestly if you're using (and requiring) Qt3 then you really need to rethink your approach. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
Samuel Gaist wrote: >> On 5 Jun 2019, at 00:39, Kevin Kofler wrote: >> Can't we just add a keySet() method (named after the Java one that does >> something similar) that returns a wrapper object that just forwards >> begin() to the map's keyBegin() etc.? Then you could just write something >> like: for (auto key : map.keySet()) >> and it should do conceptually the same as: >> for (auto key : map.keys()) >> but without ever having to build the list of keys as a list. >> >> Or, probably even more efficiently, add cursorBegin() etc. iterator >> methods that return iterators returning key-value pairs as QPair, and a >> cursorSet() that returns a wrapper object for them like keySet() above. >> Then: for (auto cursor : map.cursorSet()) >> would get you key-value pairs, wouldn't it? > > Since Qt 5.10, QHash and QMap have something for that: > > https://doc.qt.io/qt-5/qhash.html#keyValueBegin > https://doc.qt.io/qt-5/qhash.html#keyValueEnd > > And their corresponding const versions. So only the keyValueSet() wrapper object for ranged for (that I described above) is missing. > Note that the iterator returns a std::pair. Ewww, why? Qt APIs should return Qt classes, not STL classes! Kevin Kofler ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] minicoin (was: Configure command lines of official Qt releases)
Taking the liberty to starting a new thread for the minicoin related discussion... On 4th of June 2019 at 6:09 PM, Konstantin Tokarev wrote: > 04.06.2019, 17:01, "Volker Hilsheimer" : >>> 04.06.2019, 16:41, "Volker Hilsheimer" : > "Why don’t we make the exact way of turning a clean Linux > distro-install into a "Qt reference configuration" available to > everyone else? The way build machines are provisioned in Coin is > rather opaque, even with some of the respective provisioning scripts > available in the qt5.git repo [1]. Having to document on a > (notoriously outdated) wiki how to set up things to build Qt from > source, when we have that knowledge literally codified somewhere for > Coin, doesn’t seem effective." Since I’m being quoted, I might just as well use the opportunity to announce that I’ve just made the repo where I’ve been tinkinering on a solution to this problem for a while now public on the Qt gitlab instance, accompanied by a little blog post: https://blog.qt.io/blog/2019/06/04/introducing-minicoin/ >>> >>> Can this project be used to test provisioning changes before submitting >>> them to the "big" Coin, >>> or there may be behavior differences? >>> >>> Either way, nice job! >> >> Thanks! >> >> Testing provisioning scripts and making sure that they result in a working >> setup is definitely one of the use cases for minicoin. I found it very >> useful to be able to have a fast loop of “minicoin up/try to build >> stuff/minicoin destroy/improve script”, e.g when trying to build Qt for >> Android locally. >> >> There are however some key differences in the assumptions Coin and minicoin >> make; for example, Coin has a few helper scripts that are used to download >> version-pinned packages from a Qt-internal cache, which is the kind of stuff >> minicoin doesn’t care about, so scripts at this point don’t translate 1:1. >> >> But If you run “minicoin status” you see that a bunch of coin-* machines are >> defined, which will run the provisioning scripts from >> qt5.git/coin/provisioning. So there is some basic scaffolding, and perhaps >> stuff that lives in the qt5.git open source repo should be useful by anyone, >> even if they don’t run their code within The Qt Company network :) > > I guess it won't be possible to obtain some OS images like Windows or macOS > outside of The Qt Company network because of licensing issues, however it > would be great to have at least Linux and Android. Indeed, we can't make the Windows or macOS images publicly accessible, which is a shame since a lot of work and yak-shaving went into building and packaging those boxes. FWIW, for macOS images I just used the ones you can download from AppStore; general Apple-restrictions about virtualising macOS apply anyway. For Windows, there are a few images on the Vagrant cloud, and I might try to add some of the setting-up scripts to the "basebox” repo. One challenge is as well that those OS images are huge. For Linux - you can just use what's publicly available on the Vagrant cloud. The stuff in the "generic" namespace is very well maintained, and packaged using Packer with all source code available here: https://github.com/lavabit/robox You can be pretty certain that you are not downloading some malicious malware in a black box to your system. These are all based on server-images, which makes them fairly small and lean; installing a Linux desktop and X11 or Wayland server etc should be done when provisioning, using roles (I’ve started with a generic linux-desktop role). That way you don't have to download a lot of prepackaged GBs of software that you often don't need anyway. For Android - to build Qt for Android, I'm using generic/ubuntu1804 and install the SDK/NDK toolchain. See the "android-builder" box definition: https://git.qt.io/vohilshe/minicoin/blob/master/minicoin/boxes.yml#L76 https://git.qt.io/vohilshe/minicoin/blob/master/minicoin/roles/android-builder/provision.sh For running things on Android, the idea is then to use the emulator within that VM; that doesn't work with VirtualBox, as it doesn't support nested virtualisation; hence the VMware provider is preferred for this box. This is still work in progress. I might misunderstand your request though... > BTW, what about supporting KVM? Unlike VirtualBox, it supports > paravirtualized disk I/O which should make very positive impact on build > times. I have not tested anything with other Vagrant providers than VirtualBox or VMware yet, but there are provider plugins for qemu, libvirt, and kvm. Box availability will vary, but the generic/ boxes are available for libvirt at least: https://app.vagrantup.com/boxes/search?provider=libvirt=generic The multi-machine Vagrantfile used by minicoin uses provider specific configurations and stuff to implement some features, so you'd need to add relevant sections for other providers, ie.
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
[...] >>> == Java-style iteration >>> (https://codereview.qt-project.org/c/qt/qtbase/+/262344) == [...] On 2019-06-03 11:26, Lars Knoll wrote: >> I’m a bit torn here. On code review I gave a +1 on deprecating them, >> but I see that this could lead to a lot of porting effort on user >> code that makes extensive use of them. And the problem is that the >> porting can be non-trivial in cases where the list gets modified >> while iterating. So I think we should most likely keep them for Qt 6. Mutz, Marc (4 June 2019 22:41) replied: > As I wrote in the other thread, I'm ok with keeping them. I'd like to > deprecate them, though. If it's going to be a lot of effort to port away from them, partly because there are use-cases where it's easier to use (e.g. iteration while modifying, apparently), then there are going to be folk who don't do that porting and just endure the deprecation warnings, at least until they get wind of the deprecation actually turning into removal. That, in turn, inures them to deprecation warnings (indeed, they'll probably turn them off), so that they won't notice other deprecations that we intend to act on more promptly. In effect, by crying "wolf!", we'll be teaching them to ignore our warnings. If we're going to deprecate things, we should have a clear plan for when they'll be removed, so that those who see deprecation warnings consistently learn that they do need to plan to act on them and so that they know how soon they'll need to do so. If some things are deprecated and never removed (QRegEx springs to mind), while others get removed (comparably) soon after deprecation (e.g. everything we're currently deprecating with intent to remove in Qt 6), maintainers of client code get mixed signals. The slow removals may give them an impression that they can take their time, that'll lead to a violation of the principle of least surprise when they trip over one of the fast removals having suddenly gone away. So please think carefully before deprecating without a plan for when to remove. Perhaps we should have a policy that every deprecation *should* come with a "### Qt x.y Remove" comment, with the choice of which x.y being one of the things reviewers are expected to scrutinise. And, of course, we should act on all those comments at the same time that dev sets its version to x.y, absent very strong reasons (that should lead to updates to those comments). Eddy. ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Nominating Ryan Chu for Approvership
Congratulations to Ryan, all rights have been adjusted. -- Alex From: Development on behalf of Paul Wicking Sent: Wednesday, 15 May 2019 1:11:43 PM To: development@qt-project.org Subject: [Development] Nominating Ryan Chu for Approvership I'd like to nominate Ryan Chu for approvership. He's been an active contributor since January 2018, working mostly on the Docker-based test server and network-related code. He is also an active reviewer, and his manner of communication upholds the values as set forth by the Qt Code of Conduct. I know Ryan as a humble and honest person. I trust he will treat this role with the utmost respect and care, as is required. If you're curious, here's a list of his changes: https://codereview.qt-project.org/#/q/owner:%22Ryan+Chu%22,n,z and a list of changes he's on as a reviewer: https://codereview.qt-project.org/#/q/reviewer:%22Ryan+Chu%22,n,z Disclaimer: he sits 4 offices down the hall from me, and we're both on the Core & Network team. -- Paul Wicking Documentation Engineer The Qt Company Sandakerveien 116 0484, Oslo, Norway paul.wick...@qt.io +47 90 500 666 http://qt.io ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Gerrit: Sanity-Review is lost after moving changes
Or if it is, the sanity bot should probably be triggered again. > yes, make a jira task for qtqainfra/sanity bot. Done: https://bugreports.qt.io/browse/QTQAINFRA-3026 ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
> On 5 Jun 2019, at 00:39, Kevin Kofler wrote: > > Mutz, Marc via Development wrote: >> I'd still like to deprecate them. QSDP is issuing atomic operations on >> each mutable access hurting code-gen, > > Well yes, you have to use constData() or cast to const where needed. That > does not reduce QSharedDataPointer's usefulness. It is an implementation > tool for people who know what they are doing. > >> and produces surprises such as >> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=96dc9a19ae11ca140d681f0e2605b5f4b953e581 > > My existing QSharedDataPointer code always checks truth with > if (d.constData()) and never if (d). > >> or >> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=a2cdfd23d61c8dd3a346982caaf1e846e30513b0 > > I haven't had a need for this idiom in my code yet, but instead of using > QExplicitlySharedDataPointer, I would have fixed it by adding some casts to > const for the read-only checks (probably with something like: > #define CD ((const QSharedDataPointer &)(d)) > to cut down on copy). > >> or >> https://codereview.qt-project.org/gitweb?p=qt%2Fqtbase.git;a=commit;h=188eea0eb47c499f70a60f573948d529089d93b1. > > I'm not sure I understand the issue there. Thanks to the atomic reference > counts, implicitly-shared classes are as thread-safe as plain classes > without the CoW magic. But writing to the same object from 2 threads without > some form of mutex will work in neither case. Just don't do that. > >> QESDP has the bug that it doesn't propagate const. We could fix that, >> but it would be SiC, too. So, my idea was to keep them both, deprecate >> them, and use something much more cumbersome to use outside of Qt for >> Qt's own classes. I'd also be ok with keeping a fixed QESDP, but QSDP >> should go sooner rather than later. > > No, QSharedDataPointer must not go away, not now… > >> That said, I'm ok with keeping them until Qt 7, but deprecated. > > … and not in Qt 7 either! > == Java-style iteration (https://codereview.qt-project.org/c/qt/qtbase/+/262344) == >> [...] >>> I’m a bit torn here. On code review I gave a +1 on deprecating them, >>> but I see that this could lead to a lot of porting effort on user code >>> that makes extensive use of them. And the problem is that the porting >>> can be non-trivial in cases where the list gets modified while >>> iterating. So I think we should most likely keep them for Qt 6. >> >> As I wrote in the other thread, I'm ok with keeping them. I'd like to >> deprecate them, though. > > Deprecating them means you don't want to keep them permanently though, and I > don't see why. They not only help developers coming from a Java background, > but are also more intuitive for new developers. > > Yes, the STL-style iterators are more powerful in some ways, and yes, they > are needed to use STL algorithms on the Qt containers. But nobody is taking > them away from you anyway. It just does not preclude also offering a more > developer-friendly API. > == QLinkedList -> std::list (https://codereview.qt-project.org/c/qt/qtbase/+/261421) == >> [...] >>> It’s not used a whole lot, and I’m not against deprecating it. But do >>> we need to remove it for 6.0? Or maybe go the route we thought about >>> for other containers as well and have it wrap a std::list. ie. remove >>> our implementation, keep our API. >> >> I'd just let it sit in it's place, deprecated, untouched. It's not used >> in any Qt API, and the uses which I found in Qt are questionable to >> begin with. > > There too, "just let it sit in it's place, deprecated, untouched" is a > contradiction: if you deprecate it, it is not going to "sit in its place" > forever. But a data structure as common as a linked list should not go away. > (Especially not if the datastructure with the next-fastest random-access > inserts and removals, the array of pointers, is also going away.) > >> I'm concerned about their use in APIs. I don't know any other library >> that is passing hash tables around through the API for small things like >> mapping role indexes to role names. That's an array of struct job. > > Passing around a map is exactly what a hash table like QHash or a tree map > like QMap are for. I have seen lots of APIs in various programming languages > using them for the purpose they were designed for, and even written some of > them myself (both in C++ with Qt and in other programming languages). > >> How do you intend to address the problem that QHash/QMap are all but >> unusable in C++11 ranged for loops, because of decltype(*it)? > > Can't we just add a keySet() method (named after the Java one that does > something similar) that returns a wrapper object that just forwards begin() > to the map's keyBegin() etc.? Then you could just write something like: > for (auto key : map.keySet()) > and it should do conceptually the same as: > for (auto key : map.keys()) > but without ever having to build the list of keys as a
Re: [Development] Qt 5 types under consideration for deprecation / removal in Qt 6
On Monday, 3 June 2019 19:10:12 PDT Thiago Macieira wrote: > First, I want to pass the XML source through > xml sel -D -B -t -c / > > That will minify the source. That reduces the uncompressed size by about > 10%. > > Second, I'm also thinking of compressing with gzip or zstd. The problem with > that is that the tool may be present in the system but not the headers, > which would cause decompression to fail. So I'm not sure this is a good > idea. > > Of course, on Windows/MSVC you'd get neither minification nor compression. Ok, updated to a working version that works on Linux and on Windows, with MSVC. It can even compress on Windows, if you have gzip.exe in $PATH, which you will if you're in a Git Bash shell. https://codereview.qt-project.org/c/qt/qtbase/+/263548 It doesn't use Git Bash's sh.exe because nmake kept giving me a meaningless error that I didn't have time to purse. So exercise left to the reader, if wished. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel System Software Products ___ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
