Re: [Interest] The willy-nilly deletion of convenience, methods (was: Mixing Commercial and Open...)
On Monday, 22 March 2021 14:55:04 PDT Roland Hughes wrote: > A deprecation message at compile time is __not__ a warning to the > installed base. This is especially true for things that were built with > earlier versions of Qt and are now just being recompiled with a much > later version. > > A message in interest saying "Hey! We are about to nuke this, is anyone > actually using it?" The exact opposite is the correct thing: - deprecation messages while compiling the source code are correct - messages to the mailing list are not sufficient The sample of developers in this mailing list is far too small. Any reply we got from here would not be significative. Warnings posted here would not reach the majority of the audience either. But creating warnings when you compile your code is a good way to let people know that they have to take action at some time. No function can be removed until the next major version, so you have until then to figure out. At that point, the decision has already been made. I am not discussing how to make the decision on deprecation. That's not a vote either: we don't remove things because we think no one uses them, with very few exceptions (like QLinkedList). We remove things because they are badly named, have flawed API or design, result in improper code, make progress impossible otherwise, etc. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience methods
On Monday, 22 March 2021 14:29:14 PDT Thorsten Glaser wrote: > On Mon, 22 Mar 2021, Thiago Macieira wrote: > > accomplish the same goal. As shown by the example of the KWallet CLI, > > there > > may be a much better and much simpler solution once the need is > > understood. > > I wouldn’t call shouting “API abuse!” at me a “much better” solution. > I’m a user here, neither a KDE nor Qt developer, not even really a C++ > developer (I *do* C). The much better solution was to understand that you didn't have to abuse the API, and instead you can simply pass 0. You hadn't understood the API that you were using, possibly because it wasn't properly documented and, as you said you're not a C++ developer, you couldn't read the source code for the target function. So you didn't know how to do what you wanted and you didn't even know you were abusing the API. But that doesn't make what I said any less valid: once we understood what you needed to do, we could help you find a better solution. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel DPG Cloud Engineering ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Paying customers (was Re: The willy-nilly deletion of convenience, methods)
On Wed, 24 Mar 2021 at 04:49, Roland Hughes wrote: > On 3/23/2021 8:57 AM, Matthew Woehlke wrote: [...] > > I'm not actually convinced that paying Qt customers aren't getting the > > support they paid for; that information is generally not going to be > > publicly available. [...] > The complete information will never be publicly available but many > paying customers have come here to bitch about bugs open for over a year. I've never heard anyone complaining about Qt tech support in my company (a paying customer). And we do a lot of weird things, pushing Qt to the limits on our embedded devices. I'm not too involved with the platform aspect, but my last experience was related to QtWayland, we had problems, requested support, got help and solved the problems. Happy as Larry on that one. Chris ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
> I don't know about other parts of the world, but in the U.S.A. the FDA > is very adamant. Only the binary set that they have tested gets installed. Pretty much the same in Germany. Also for other safety related (non-medical) industries. -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
> Raise your hands. > > How many of you have reported bugs that have sat open for over a year? A year? LOL. 1 year is the age of the newest unresolved issue I have. Most of them are many years old, including multiple issues dated 2012. > Raise your hands. > > How many of you have bugs reported against earlier versions of Qt that sat > open until > they were closed as being against an unsupported version? Actually this did not happen to me as far as I can remember. LOL! Probably because most of my unresolved issue are rotting in the issue tracker as "Reported" and are ignored forever. > How many of you have had to scrap products or features because bugs you > reported were > blockers and they were just rotting in the bug database? How many of those > bugs are > still rotting? Not scraped anything. But rewritten a lot. Hunted long known bugs. Reinvented the wheel and wrote horrible work arounds. > The only thing that is going to work for the big ticket companies is a 100% > commercial > product that happens to release its older stuff as OpenSource and sometimes > accepts > software developed by others for free. Nobody wants to hear that, but that is > the only > model that works. With that model comes fixing all bugs inside 90 days. None > of this > hoping someone in the OpenSource community fixes it for free. You are right. But that has nothing to do with "Open Source" in the first place. I have seen larger companies that insisted in "Open Source" for critical components - still with the full, the reliably commercial support you are talking about. I think you are mixing "Open Source" and "Community driven" here. > That QML stuff really has to be ripped out and put into its own commercial > package so > the rest of the world doesn't have to pay the heavy price. +1 > The Wolfe oven needed a stacked widget, not a state machine. Project craters > like these > aren't helping the reputation of Qt. Can you explain that? I have seen software going down the drain because people didn't use state machines. I have seen software using state machines without urgend need. But I have never seen a software that failed *due to* using state machines (at least not when fully understood). > Roughly half of my bugs reported via the forum are fixed within a couple of > days. Seriously? Wow. What kind of bugs? What impact? > Phones only care about what is shipping next week. > As I said before, those are diametrically opposed markets. I agree? > Just my 0.0002 cents. How do to change that? LOL, SCNR -- Best Regards, Bernhard Lindner ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
> -Original Message- > From: Sérgio Martins > Sent: Dienstag, 23. März 2021 20:40 > To: Maurice Kalinowski > Cc: Matthew Woehlke ; Volker Hilsheimer > ; Qt Interest > Subject: Re: [Interest] The willy-nilly deletion of convenience, methods > > On Tue, Mar 23, 2021 at 6:23 PM Maurice Kalinowski > wrote: > > > > > > > > Not all deprecations are bad. However, I still maintain that *some* > > > of the Qt > > > 6 changes are problematic. Also, TBH, I think the real issue is less > > > that Qt 6 made changes, and more that Qt 5 support got pulled well > > > before Qt 6 is viable for most folks. That didn't happen with Qt 4 → 5. > > > > > > I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff > > > that was immediately removed in Qt 5.0, although I may be wrong about > that. > > > > > [Maurice Kalinowski] > > There was, plenty of them, more than from Qt 5 to Qt 6. > > And even more so, we had not the time to do deprecation warnings, like > you can enable now when building against 5.15. > > Hence, the migration should be (and according to user discussions is) much > easier for this major release. > > > > Another aspect I would like to reiterate is why not all modules are > > available > with the initial 6.0 release. > > > > For Qt 5.0 we tried to get everything over in one big go. The problem was > that many of the features and behavior changes did not get fully executed > through the leaf modules. That led to the situation that we couldn't do many > modernizations afterwards again due to binary compatibility promises in the > Qt 5 series. Thus, the approach was/is to have 6.0 with the set of most used > modules. > > From there get verification by users, that the changes have been in the > right direction and broaden the module support then. As that allows to focus > on bringing over modernization to those leaf modules, but also have > dedicated time to modernize these as well. > > > > From what we've seen on reviews on blogs/articles/tweets/... this > approach works. Admittedly, with not everyone being able to migrate as of > now. But I strongly believe that with 6.2 we will have a much better Qt > compared to taking the same approach as with Qt 4->5, even at 5.2 times. > > That's not a fair comparison. And I don't think it is fair to now merge a separate discussion into this. Generally, this thread contains way too many topics at once to be able to keep a streamlined discussion. > After Qt 5.0 was released in 2012 we still saw several Qt 4 bugfix releases > (up > until 2015). > With the situation now, we're in a limbo, there's no 6.2 and there's no Qt5 > open-source bugfix releases. > I can see this concern from your side, totally. But as mentioned above, I commented on the part whether removals have happened between Qt 4 and 5. And they did, in worse fashion. Maurice ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On Tue, Mar 23, 2021 at 6:23 PM Maurice Kalinowski wrote: > > > > > Not all deprecations are bad. However, I still maintain that *some* of the > > Qt > > 6 changes are problematic. Also, TBH, I think the real issue is less that > > Qt 6 > > made changes, and more that Qt 5 support got pulled well before Qt 6 is > > viable for most folks. That didn't happen with Qt 4 → 5. > > > > I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that was > > immediately removed in Qt 5.0, although I may be wrong about that. > > > [Maurice Kalinowski] > There was, plenty of them, more than from Qt 5 to Qt 6. > And even more so, we had not the time to do deprecation warnings, like you > can enable now when building against 5.15. > Hence, the migration should be (and according to user discussions is) much > easier for this major release. > > Another aspect I would like to reiterate is why not all modules are available > with the initial 6.0 release. > > For Qt 5.0 we tried to get everything over in one big go. The problem was > that many of the features and behavior changes did not get fully executed > through the leaf modules. That led to the situation that we couldn't do many > modernizations afterwards again due to binary compatibility promises in the > Qt 5 series. Thus, the approach was/is to have 6.0 with the set of most used > modules. > From there get verification by users, that the changes have been in the right > direction and broaden the module support then. As that allows to focus on > bringing over modernization to those leaf modules, but also have dedicated > time to modernize these as well. > > From what we've seen on reviews on blogs/articles/tweets/... this approach > works. Admittedly, with not everyone being able to migrate as of now. But I > strongly believe that with 6.2 we will have a much better Qt compared to > taking the same approach as with Qt 4->5, even at 5.2 times. That's not a fair comparison. After Qt 5.0 was released in 2012 we still saw several Qt 4 bugfix releases (up until 2015). With the situation now, we're in a limbo, there's no 6.2 and there's no Qt5 open-source bugfix releases. Very unfortunate timing. What's sad, is that this probably wasn't done by incompetence, but intentionally: Cripple the open-source version to make the commercial offering look better. Prioritizing short term profits over long term. And it's ironic, the commercial offering wouldn't be so good if it wasn't for the open source version (and vice-versa). Each made the other grow. Regards, Sérgio ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
> > Not all deprecations are bad. However, I still maintain that *some* of the Qt > 6 changes are problematic. Also, TBH, I think the real issue is less that Qt 6 > made changes, and more that Qt 5 support got pulled well before Qt 6 is > viable for most folks. That didn't happen with Qt 4 → 5. > > I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that was > immediately removed in Qt 5.0, although I may be wrong about that. > [Maurice Kalinowski] There was, plenty of them, more than from Qt 5 to Qt 6. And even more so, we had not the time to do deprecation warnings, like you can enable now when building against 5.15. Hence, the migration should be (and according to user discussions is) much easier for this major release. Another aspect I would like to reiterate is why not all modules are available with the initial 6.0 release. For Qt 5.0 we tried to get everything over in one big go. The problem was that many of the features and behavior changes did not get fully executed through the leaf modules. That led to the situation that we couldn't do many modernizations afterwards again due to binary compatibility promises in the Qt 5 series. Thus, the approach was/is to have 6.0 with the set of most used modules. From there get verification by users, that the changes have been in the right direction and broaden the module support then. As that allows to focus on bringing over modernization to those leaf modules, but also have dedicated time to modernize these as well. From what we've seen on reviews on blogs/articles/tweets/... this approach works. Admittedly, with not everyone being able to migrate as of now. But I strongly believe that with 6.2 we will have a much better Qt compared to taking the same approach as with Qt 4->5, even at 5.2 times. BR, Maurice ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 3/23/2021 11:47 AM, Jason H wrote: QML is a binding environment, and a handy one at that. It is not just GUI. I have Websocket servers that interact with non-visual classes with bindings provided in QML. It's great. Yeah the QtQuick controls 1 were terrible and 2 are pretty bad, but I think things are getting better. You think it is great. My world knows it to be useless trash ruining the product. Your world is completely different than mine. I've had to sweep up behind people who thought they could use QML and JavaScript for medical device work. More specifically, like 90% of the device. It is irreparable at this point. Whatever Qt becomes, it cannot have any current or former Digia people involved. Deep pocket customers won't come back. The Digia crew is 0 for 2. It's reparable. Such things can be fixed with a stroke of a pen, like when Nokia LGPLd it. It's just that Digia/QtCo/Weyland-Yutani corp is running Qt as an open source project into the ground. I wasn't talking about the license. The *reputation* of Qt is not fixable at this point. If 100% of the bugs were fixed tomorrow and the license was done correctly, a huge chunk of the market is __still__ not coming back all because of wretched management and worthless decisions. I liked QML as a way to get those JS devs into Qt. Cheap and putting out low quality systems. That's a market where no matter how much you pay you can't buy good. I believe that if we could pull that off, Qt can still have a bright future. We can't. The thing has to fork and split. I really hate fragmentation. I'd rather convince Digia that their licensing decisions are ultimately hurting the community and sales. But the embedded market wants QML in its own hermetically sealed environment with all contaminants removed from the C++ code. Removal of QML and an intelligent license is why CopperSpice now has a lot of former Qt customers. I like Jason. He's a nice guy, but he wants to use Qt on phones and to have QML. He's not alone. That's how this got so busted in the first place. That write-once-run-anywhere myth surrounding Java back in the day. As someone who has done it, it's not myth* *for parts that Qt supports, but not nearly enough is supported on mobile. Yeah. "Hello World!" works! :) The OpenSource community was blind, deaf, and dumb when they railed against Tivo locking down their devices and came up with all of these poisoned pills in OpenSource licenses mandating users be able to modify the software. In medical devices, that's illegal. In industrial control systems where SAFETY is mandated, that's illegal. Not exactly. To use it comply with the license and you would have to provide configuration management and source to generate the same binary. You misinterpret what I mean by illegal. Understandable since we've been talking software license. If I'm an employee of St. Nowhere Hospital and I pull down the latest OpenSSL (or whatever) OpenSource Linux library because I think it is needed and install it on an FDA tested and approved medical device the *act* of doing that is a crime. The device doesn't even have to be used, just remain in the hospital or other medical facility where it *could* be used. I don't know about other parts of the world, but in the U.S.A. the FDA is very adamant. Only the binary set that they have tested gets installed. Now, if the device gets used you are looking at a minimum of attempted manslaughter. If there is an "adverse outcome" and where you live has a really good prosecutor, you could be facing murder one. I don't remember what the regulations/legal liability is for industrial control where SAFETY in mandated but it isn't far off. If you tweak the firmware on something like the safety sensors that drop the steel safety nets in a paper mill, guys can literally get cut in half in a fraction of a second. The nets and sensors are there to stop that. Any new/different OpenSource license __MUST__ remove the Tivo poison pill at least for the regulated environments where physically changing the software is illegal. Hey, you want to hose up your own Tivo, have at it. You just won't get to watch TV. You hose up the surgical robot they are going to use for my mom's open heart surgery I'll throw the lever in that chamber myself and sleep good that night. Your "rights" just needlessly took an innocent life. I can forgive a drunk driver easier than I can forgive you. No, I don't for a moment think QML is on that list :-). +1000 -- Roland Hughes, President Logikal Solutions (630)-205-1593 https://theminimumyouneedtoknow.com https://infiniteexposure.net https://lesedi.us https://johnsmith-book.com https://logikalblog.com https://interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
> Now, the "commercial license" simply could be the Boot2Qt stuff with all > of Qt being 100% OpenSource. This would provide additional incentive to > rip QML out so it isn't bastardizing the rest of the product and QML > could then be its own commercial thing, just for phones. I have lost > track of other little things that Digia might have spun up for > additional cash. QML is a binding environment, and a handy one at that. It is not just GUI. I have Websocket servers that interact with non-visual classes with bindings provided in QML. It's great. Yeah the QtQuick controls 1 were terrible and 2 are pretty bad, but I think things are getting better. > > I'm not actually convinced that paying Qt customers aren't getting the > > support they paid for; that information is generally not going to be > > publicly available. > > Pull down a couple years worth of the interest archives and unzip them > into a directory. Let grep search for bug or customer. As a multiple-time commercial customer the bug/issue support has been great, but the meta-narrative (previously Mobile in nature) was very lacking. Lars/Digia is going to to do what they want, and Open Governance is a joke. > https://lists.qt-project.org/pipermail/interest/ > > The complete information will never be publicly available but many > paying customers have come here to bitch about bugs open for over a year. Not just a year, try 3. I usually was able to come up with a work-around so that I was not blocked for 3 years though. The more critical stuff did get fixed timely. > > What *is* broken is the alimony licensing model and all the > > fear-mongering around the licensing terms. > +12 > > *Proper* commercial support for open source products lets you try > > before you buy with no punishment afterward, no penalties if you want > > to drop support later, or drop it and pick it up again. You pay, you > > get support, *period*. > +24 > > > > For that matter, it seems like Qt's commercial model is working just > > fine *for them*, at least at the moment. Ironically, the arguments you > > are making probably are *why* it's working. The problem is that > > they're busy killing the community and doing severe, possibly > > irreparable damage to Qt's reputation. > It is irreparable at this point. Whatever Qt becomes, it cannot have any > current or former Digia people involved. Deep pocket customers won't > come back. The Digia crew is 0 for 2. It's reparable. Such things can be fixed with a stroke of a pen, like when Nokia LGPLd it. It's just that Digia/QtCo/Weyland-Yutani corp is running Qt as an open source project into the ground. They (IMO) don't see opensource as a way cultivate an ecosystem that pumps the sales pipeline. And they won't question it until the big customers dry up, look to the community and realize they turned everyone off from it and they already went to HTML5, where HTML/JS people are cheap and plentiful. Meanwhile their C++ tooklit gets them a steady decline: https://www.tiobe.com/tiobe-index/cplusplus/ that peaked 20 years ago. I liked QML as a way to get those JS devs into Qt. They are familiar with JS bindings, be them React, Angular, Knockout, Vue, etc. PySide seems to be well-informed because that's the only language (Python) that is steadily increasing. They do seem to know HTML5 is a threat (they have whitepapers on it) but have yet to really take it on meaningfully. > >> It's highly doubtful that any company could pull in the staff to > >> maintain all of the markets and eliminate all of the bugs, but that > >> would have to be the starting point for such a venture. > > > > Right, which is why we *need* a community, or a consortium, or > > something of that nature. We need everyone that cares about what Qt > > *could* be, without Digia's efforts to break it, to pool their resources. > > > > I believe that if we could pull that off, Qt can still have a bright > > future. > > We can't. > > The thing has to fork and split. I really hate fragmentation. I'd rather convince Digia that their licensing decisions are ultimately hurting the community and sales. > I like Jason. He's a nice guy, but he wants to use Qt on phones and to > have QML. He's not alone. That's how this got so busted in the first > place. That write-once-run-anywhere myth surrounding Java back in the day. As someone who has done it, it's not myth* *for parts that Qt supports, but not nearly enough is supported on mobile. > The OpenSource community was blind, deaf, and dumb when they railed > against Tivo locking down their devices and came up with all of these > poisoned pills in OpenSource licenses mandating users be able to modify > the software. > > In medical devices, that's illegal. > > In industrial control systems where SAFETY is mandated, that's illegal. Not exactly. To use it comply with the license and you would have to provide configuration management and source to generate the same binary. However it would be a huge risk on their part to
Re: [Interest] Interest Digest, Vol 114, Issue 28
On 3/23/2021 10:44 AM, interest-requ...@qt-project.org wrote: Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any change, not just on a mailing list, but in person. Anyone can, in theory (in practice, depending on where you live, there may be a non-trivial membership fee required)*vote* against a change. We, as the committee, generally try to be considerate of the community when making changes, and there is quite a lot of emphasis on not breaking existing code, even as far back as C++98. How many C++ devs are on those? Likely only those whose companies are paying them to be, and a few that got there via academics (I've personally known and worked with one person; outside of the folks I've seen here on the Qt lists.) Well, when you sign up to build a DEB and a custom ISO for a client. Both of which can be popped open on a server to have additional marketing stuff dumped in you don't have to. When said client wants the DEB to install on Ubuntu 12, 13, 14, 15, 16; both 32 and 64-bit I can tell you now that, after hundreds of experimental builds, C++98 on Ubuntu 15 is what you will use to create the 32-bit executable, then you will stuff all of the libraries into the DEB because you are straddling an ABI change as well as the systemd debacle https://wiki.ubuntu.com/systemd Fun times in Kiosk land. -- Roland Hughes, President Logikal Solutions (630)-205-1593 https://theminimumyouneedtoknow.com https://infiniteexposure.net https://lesedi.us https://johnsmith-book.com https://logikalblog.com https://interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 11.44, Volker Hilsheimer wrote: I wished I had seen the level of energy y’all are putting right now into this email thread over the last two years when we discussed where to go with Qt 6, and when the work actually happened. IIRC, I complained plenty about QList at the time. I wouldn't be surprised if I complained about QHash also. One of the reasons I don't try to contribute more than I do is because, when I *have* contributed patches, it hasn't accomplished anything. So far, all I've seen is "C++ also deprecates stuff". You haven't shown that the deprecations are actually *harmful* to the C++ community. > Personally, I’m siding with those folks in the committee that believe that not changing things (ref ABI discussion) is more harmful than if we’d be able to fix now and again what is objectively broken. Likewise. I've even said before that it might be beneficial if C++ could more aggressively deprecate bad stuff, even mentioning Qt as an example to follow. Not all deprecations are bad. However, I still maintain that *some* of the Qt 6 changes are problematic. Also, TBH, I think the real issue is less that Qt 6 made changes, and more that Qt 5 support got pulled well before Qt 6 is viable for most folks. That didn't happen with Qt 4 → 5. I also don't recall Qt 4.8 suddenly deprecating a bunch of stuff that was immediately removed in Qt 5.0, although I may be wrong about that. I personally wonder why people that never want to change what they built last year want to develop software development. Isn’t that what makes building stuff out of bits and ideas so much more interesting than building stuff out of sticks and stones? Is this really so surprising? People want to spend their time making *their* software better, not chasing an ever-shifting foundation on which their software is *built*. Time spent adapting to library changes, especially changes seen as unnecessary or actively harmful, is time *not* spent developing new and exciting features, or even squashing existing bugs. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience,, methods
On 3/23/2021 8:24 AM, interest-requ...@qt-project.org wrote: Having read this entire conversation I find it interesting that we as developers are complaining about features being deprecated and removed in Qt but yet where is the anger when C++ spec removes features? https://en.wikipedia.org/wiki/C%2B%2B20#Removed_features_and_deprecation Don't know of anybody that actually used any of that. volatile was "iffy" the day they added it to the language standard. The definition seemed to change compiler to compiler. Good riddance. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html#removed Couldn't reach, but I only allow https anymore. http://www.cplusplus2017.info/removed-features-from-c17/ Ditto http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html#removed Ditto -- Roland Hughes, President Logikal Solutions (630)-205-1593 https://theminimumyouneedtoknow.com https://infiniteexposure.net https://lesedi.us https://johnsmith-book.com https://logikalblog.com https://interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
> On 23 Mar 2021, at 15:49, Matthew Woehlke wrote: > > On 23/03/2021 10.36, Benjamen Meyer via Interest wrote: >> On 3/23/21 10:09 AM, Matthew Woehlke wrote: >>> Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any >>> change, not just on a mailing list, but in person. Anyone can, in theory >>> (in practice, depending on where you live, there may be a non-trivial >>> membership fee required) *vote* against a change. We, as the committee, >>> generally try to be considerate of the community when making changes, >>> and there is quite a lot of emphasis on not breaking existing code, even >>> as far back as C++98. >> How many C++ devs are on those? > > Hundreds, which is probably more than the number of people making decisions > for Qt. > >> Likely only those whose companies are paying them to be, and a few >> that got there via academics (I've personally known and worked with >> one person; outside of the folks I've seen here on the Qt lists.) > > Even so, that's a lower bar than "you must be an employee of TQtC" (and even > that is probably not sufficient). The bar also happens to be much lower right > now due to COVID, since there are no in-person meetings happening. I wished I had seen the level of energy y’all are putting right now into this email thread over the last two years when we discussed where to go with Qt 6, and when the work actually happened. Code and header reviews are all done in public, and it’s usually the same small handful of people that put an effort into those. And I’m extremely grateful to those people who do, and there were tons of occasion during the Qt 6 development where someone outside The Qt Company criticised a change, perhaps even -2’ed it, and made things better by putting their git (or at least gerrit) credentials next to their opinion. Of course, The Qt Company paying several dozens of software engineers to work full-time on the various parts of Qt (the framework, the tools, the CI system) has a big momentum, and yes we have colleagues that can approve changes quickly. But the deprecations that seem to cause the most controversy right now - like removing toContainer helpers - were not implemented by a TQtC employee, and neither is the maintainer of the Qt Core module on TQtC payroll. As the one who killed QDesktopWidget and a bunch of other, previously deprecated APIs for Qt 6 - I personally prefer to not have my code compile anymore if it wouldn't work as it needs to anyway. That’s better than code that builds, but doesn’t work, or doesn’t scale, or prevents long-term improvements. Yes, that’s to some degree my personal opinion, but it’s evidently also the general principle of The Qt Project (even if not written down in some quip or manifest) and it’s also the opinion of the folks in the Qt Project that +2’ed my changes. Maybe ideally nobody would have to change anything ever, and we only get to use new things that work perfectly with the old stuff all the time. But knowing about what it costs to build software this way, we have decided that this is not how we are building Qt. This is not exactly a surprise, after 25 years and 6 major Qt releases, all of which have removed old APIs. > In any case, you've made an unsubstantiated allegation that the committee > does not care about C++ users. And you have made the unsubstantiated claim that people outside of The Qt Company have no influence on the direction The Qt Project is (technically) taking - yes, the licensing shenanigans excluded. > Please provide evidence to back that up. So far, all I've seen is "C++ also > deprecates stuff". You haven't shown that the deprecations are actually > *harmful* to the C++ community on anything like the scale to which Qt's > recent changes have been harmful. Personally, I’m siding with those folks in the committee that believe that not changing things (ref ABI discussion) is more harmful than if we’d be able to fix now and again what is objectively broken. > Deprecations, even in Qt, aren't always bad. Some recent Qt deprecations, > however, have caused major pain. Now you are apparently claiming that C++ is > "just as bad", but I have yet to see that claim substantiated. I personally wonder why people that never want to change what they built last year want to develop software development. Isn’t that what makes building stuff out of bits and ideas so much more interesting than building stuff out of sticks and stones? Volker ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 3/23/2021 8:57 AM, Matthew Woehlke wrote: On 23/03/2021 06.59, Roland Hughes wrote: 30 years is __nothing__ for production systems. It is ordinary for a well developed system to run 10+ years without any modifications. On that note, how many people are aware there's a computer that has been running non-stop for almost 45 years? :-D Oh. Another DEC-ky Techie. Shouldn't say that too loud. One minor it, if that is the Irish Railway system. It's actually a cluster. Once every so many years they take one of the nodes down for hardware and other maintenance but the cluster operates the rail system 24x7x365 and change. If memory serves, up for 10 years before the first node got maintenance. You kids and your uptime measured in hours... +12 The Qt OpenSource model simply does not work. It cannot really be made to work. You can't pursue licensing from lone wolfs and shoestring startups and expect well run legitimate companies to have any respect for you. It's not going to happen. The only thing that is going to work for the big ticket companies is a 100% commercial product that happens to release its older stuff as OpenSource and sometimes accepts software developed by others for free. Nobody wants to hear that, but that is the only model that works. With that model comes fixing all bugs inside 90 days. None of this hoping someone in the OpenSource community fixes it for free. Here, however, I'm going to have to disagree. I fail to see why the open source version can't be the latest and greatest, so long as the paid support *does* actually provide support, as you're saying. (Dislaimer: This is my employer's business model. It seems to be working quite well for us.) *If* one is going to have a commercial license with full support, that _has_ to be the tip of the tip. You have to actually get something for the additional fee rather than Digia executives getting a new 'Cedes and you the shaft which kind of feels like the business model now. Now, the "commercial license" simply could be the Boot2Qt stuff with all of Qt being 100% OpenSource. This would provide additional incentive to rip QML out so it isn't bastardizing the rest of the product and QML could then be its own commercial thing, just for phones. I have lost track of other little things that Digia might have spun up for additional cash. What I think it broken is the commercial licensing model. Either pay for support (and *get* support), or don't pay, and get whatever the community gives you. Okay, that's the point of disagreement. Kind of what I suspected. The problem with that is one has to __START__ with all of the known bugs fixed, not just deleted. Ripping QML out into its own universe will go a long way to emptying the bug database *provided QML and JavaScript are ripped out root and stem not just deleted leaving support in the class and header code.* I'm not actually convinced that paying Qt customers aren't getting the support they paid for; that information is generally not going to be publicly available. Pull down a couple years worth of the interest archives and unzip them into a directory. Let grep search for bug or customer. https://lists.qt-project.org/pipermail/interest/ The complete information will never be publicly available but many paying customers have come here to bitch about bugs open for over a year. Hey! "That guy again" needs to chime in here. Unless his company has also abandoned Qt as so many have. What *is* broken is the alimony licensing model and all the fear-mongering around the licensing terms. +12 *Proper* commercial support for open source products lets you try before you buy with no punishment afterward, no penalties if you want to drop support later, or drop it and pick it up again. You pay, you get support, *period*. +24 For that matter, it seems like Qt's commercial model is working just fine *for them*, at least at the moment. Ironically, the arguments you are making probably are *why* it's working. The problem is that they're busy killing the community and doing severe, possibly irreparable damage to Qt's reputation. It is irreparable at this point. Whatever Qt becomes, it cannot have any current or former Digia people involved. Deep pocket customers won't come back. The Digia crew is 0 for 2. It's highly doubtful that any company could pull in the staff to maintain all of the markets and eliminate all of the bugs, but that would have to be the starting point for such a venture. Right, which is why we *need* a community, or a consortium, or something of that nature. We need everyone that cares about what Qt *could* be, without Digia's efforts to break it, to pool their resources. I believe that if we could pull that off, Qt can still have a bright future. We can't. The thing has to fork and split. I like Jason. He's a nice guy, but he wants to use Qt on phones and to have QML. He's not alone. That's
Re: [Interest] QML Image size vs sourceSize strange things
Yes good point, take care those built-in size attributes are optional, might not be there into an SVG, you might not want to count on it. From: Interest on behalf of Giuseppe D'Angelo via Interest Date: Tuesday, March 23, 2021 at 10:53 AM To: interest@qt-project.org Subject: Re: [Interest] QML Image size vs sourceSize strange things Il 23/03/21 14:16, Jérôme Godbout ha scritto: > Do you really need to same memory by reducing the source size? I think > you should left the source size alone and sample the image from the full > source. Source size for SVG doesn’t make any sense, it’s vectoriel, > doesn’t have any size, it can scale to any dimension. This isn't accurate. SVG files have a builtin "wanted" size, which is IIRC what Qt would use by default: > https://www.w3.org/TR/SVG11/struct.html#SVGElementWidthAttribute By explictly setting `sourceSize` you're asking Qt to rasterize the SVG at a different resolution rather than the wanted one (and downscaling when rendering). My 2 c, -- 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, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QML Image size vs sourceSize strange things
Il 23/03/21 14:16, Jérôme Godbout ha scritto: Do you really need to same memory by reducing the source size? I think you should left the source size alone and sample the image from the full source. Source size for SVG doesn’t make any sense, it’s vectoriel, doesn’t have any size, it can scale to any dimension. This isn't accurate. SVG files have a builtin "wanted" size, which is IIRC what Qt would use by default: https://www.w3.org/TR/SVG11/struct.html#SVGElementWidthAttribute By explictly setting `sourceSize` you're asking Qt to rasterize the SVG at a different resolution rather than the wanted one (and downscaling when rendering). My 2 c, -- 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, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 10.36, Benjamen Meyer via Interest wrote: On 3/23/21 10:09 AM, Matthew Woehlke wrote: Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any change, not just on a mailing list, but in person. Anyone can, in theory (in practice, depending on where you live, there may be a non-trivial membership fee required) *vote* against a change. We, as the committee, generally try to be considerate of the community when making changes, and there is quite a lot of emphasis on not breaking existing code, even as far back as C++98. How many C++ devs are on those? Hundreds, which is probably more than the number of people making decisions for Qt. Likely only those whose companies are paying them to be, and a few that got there via academics (I've personally known and worked with one person; outside of the folks I've seen here on the Qt lists.) Even so, that's a lower bar than "you must be an employee of TQtC" (and even that is probably not sufficient). The bar also happens to be much lower right now due to COVID, since there are no in-person meetings happening. In any case, you've made an unsubstantiated allegation that the committee does not care about C++ users. Please provide evidence to back that up. So far, all I've seen is "C++ also deprecates stuff". You haven't shown that the deprecations are actually *harmful* to the C++ community on anything like the scale to which Qt's recent changes have been harmful. Deprecations, even in Qt, aren't always bad. Some recent Qt deprecations, however, have caused major pain. Now you are apparently claiming that C++ is "just as bad", but I have yet to see that claim substantiated. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 3/23/21 10:09 AM, Matthew Woehlke wrote: > On 23/03/2021 09.16, Michael Jackson wrote: >> Having read this entire conversation I find it interesting that we as >> developers are complaining about features being deprecated and >> removed in Qt but yet where is the anger when C++ spec removes >> features? > Oh, it's there. > > However, C++ is *far* more conservative than Qt about what it removes, > and most of the removals are genuinely unuseful. (Seriously, > *trigraphs*? Are *you* using trigraphs? Or auto_ptr?) > > If you're seriously going to advance this argument, you need to point > out one or more *specific* changes that you believe are harmful. Even > then, chances are your compiler will continue to support that stuff for > another 10 years. The change of `auto` from a scope function to a variable type is certainly harmful, especially since there was no version in between where it wasn't defined at all; it was just changed. Granted the argument was "no one uses it", but if you're porting an old application that _did_ use it you'll get all kinds of junk quickly. And yes, there was a type when I was learning about the various scoping aspects of variables that I did learn about and use it; and I'm sure there is legacy code out there that uses it. Honestly, there hasn't been much added to C++ since C++98 that was useful. std::string is one exception, as is standardizing on using Boost - but you don't need to make Boost part of the C++ standards to achieve that. > Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any > change, not just on a mailing list, but in person. Anyone can, in theory > (in practice, depending on where you live, there may be a non-trivial > membership fee required) *vote* against a change. We, as the committee, > generally try to be considerate of the community when making changes, > and there is quite a lot of emphasis on not breaking existing code, even > as far back as C++98. > How many C++ devs are on those? Likely only those whose companies are paying them to be, and a few that got there via academics (I've personally known and worked with one person; outside of the folks I've seen here on the Qt lists.) In all honesty, it comes down to those who are paying to vote - which is certainly not the vast majority of C++ devs. -- Ben Meyer Software Engineer (703)901-2797 bm_witn...@yahoo.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 114, Issue 23
On 3/23/21 9:25 AM, Matthew Woehlke wrote: > On 23/03/2021 01.21, Tuukka Turunen wrote: >> Feedback on the Qt 6 API is valuable and we are very interested in it. >> Portability was one of the key design principles and we have avoided >> making changes when not needed. That said, there can surely >> be some items that are unnecessarily changed. > > Why are the QHash changes needed? The main outcome of that seems to be > encouraging people to use std::unordered_map instead and destroying > trust in Qt's API. > > Why is QList removed? (I don't mean the *name* "QList", I mean the > container with indirect storage and reference stability. It's useful, > and unlike QHash, there is no STL equivalent available.) I always switched between std::deque and QList. So there is something available, but it's not a straight forward thing or logical by names. Honestly, C++'s standards committee got wrong the design and naming of std::list and std::deque since you cannot access random elements in std::list (and you should in a list) but you can in std::deque (and you shouldn't be able to in a deque). Yeah, I read their reasoning; but it doesn't fit how people things of those two things. Guess I'll have to dig in an port https://github.com/BenjamenMeyer/qtmd5gui to Qt5/6 to see the damage done. Honestly, I was hoping to be able to convert a number of utilities in https://github.com/vegastrike/Vega-Strike-Engine-Source from Gtk to Qt; but after reading this discussion any hope there is almost certainly down the drain. -- Ben Meyer Software Engineer bm_witn...@yahoo.com ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 09.16, Michael Jackson wrote: Having read this entire conversation I find it interesting that we as developers are complaining about features being deprecated and removed in Qt but yet where is the anger when C++ spec removes features? Oh, it's there. However, C++ is *far* more conservative than Qt about what it removes, and most of the removals are genuinely unuseful. (Seriously, *trigraphs*? Are *you* using trigraphs? Or auto_ptr?) If you're seriously going to advance this argument, you need to point out one or more *specific* changes that you believe are harmful. Even then, chances are your compiler will continue to support that stuff for another 10 years. Also, C++ isn't a dictatorship the way Qt is. Anyone can object to any change, not just on a mailing list, but in person. Anyone can, in theory (in practice, depending on where you live, there may be a non-trivial membership fee required) *vote* against a change. We, as the committee, generally try to be considerate of the community when making changes, and there is quite a lot of emphasis on not breaking existing code, even as far back as C++98. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Missing QMap Algebra?
Hello!
QMap::insert(const QMap &) was added in 5.15. No operator+ though.
https://doc.qt.io/qt-5/qmap.html#insert-2
From: Interest on behalf of Jason H
Sent: Tuesday, March 23, 2021 14:52
To: interestqt-project.org
Subject: [Interest] Missing QMap Algebra?
I've been in the python world lately and python has a dict.update()
https://python-reference.readthedocs.io/en/latest/docs/dict/update.html
It seems that QMap has no such function anymore, but it also never did? unite()
would make a QMultiMap, so there would be multiple entries rather than one.
Which has me asking the question, do I have to provide this myself? Seems a
pretty trivial thing to have to provide?
QVariantMap map_a, map_b;
...
auto combined_map = map_a;
for (const QString& key: map_b.keys()) {
combined_map[key] = map_b[key];
}
Additionally there is no + operator for it, which is actually what I want:
combined_map = map_a + map_b;
But I would be happy with:
combined_map.update(map_b);
Additionally if we're trying to provide as much algebra as possible:
map_a = combined_map - map_b.keys() // remove by matching key
map_a = combined_map - map_b; // remove by matching key-value pairs
In Python, these are doable in a 1-line list/dict comprehension.
Thoughts?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 23/03/2021 06.59, Roland Hughes wrote: 30 years is __nothing__ for production systems. It is ordinary for a well developed system to run 10+ years without any modifications. On that note, how many people are aware there's a computer that has been running non-stop for almost 45 years? :-D You kids and your uptime measured in hours... The phone world [...] [is] actually how this downward spiral started, with the introduction of QML and forcing people to re-write, re-write, re-write. That does, indeed, seem to have been the turning point. The Qt OpenSource model simply does not work. It cannot really be made to work. You can't pursue licensing from lone wolfs and shoestring startups and expect well run legitimate companies to have any respect for you. It's not going to happen. The only thing that is going to work for the big ticket companies is a 100% commercial product that happens to release its older stuff as OpenSource and sometimes accepts software developed by others for free. Nobody wants to hear that, but that is the only model that works. With that model comes fixing all bugs inside 90 days. None of this hoping someone in the OpenSource community fixes it for free. Here, however, I'm going to have to disagree. I fail to see why the open source version can't be the latest and greatest, so long as the paid support *does* actually provide support, as you're saying. (Dislaimer: This is my employer's business model. It seems to be working quite well for us.) What I think it broken is the commercial licensing model. Either pay for support (and *get* support), or don't pay, and get whatever the community gives you. I'm not actually convinced that paying Qt customers aren't getting the support they paid for; that information is generally not going to be publicly available. What *is* broken is the alimony licensing model and all the fear-mongering around the licensing terms. *Proper* commercial support for open source products lets you try before you buy with no punishment afterward, no penalties if you want to drop support later, or drop it and pick it up again. You pay, you get support, *period*. For that matter, it seems like Qt's commercial model is working just fine *for them*, at least at the moment. Ironically, the arguments you are making probably are *why* it's working. The problem is that they're busy killing the community and doing severe, possibly irreparable damage to Qt's reputation. It's highly doubtful that any company could pull in the staff to maintain all of the markets and eliminate all of the bugs, but that would have to be the starting point for such a venture. Right, which is why we *need* a community, or a consortium, or something of that nature. We need everyone that cares about what Qt *could* be, without Digia's efforts to break it, to pool their resources. I believe that if we could pull that off, Qt can still have a bright future. Because they don't have bugs that have been rotting for over a decade, CopperSpice went to a support and consulting contract only model. It seems to be working. I haven't much looked into CS, but that sounds plausible. Again, that's basically how my own employer works. It's a perfectly functional business model for organizations with the commitment and ethos to pull it off. I'm also not sure how much I *want* to look into CS. The CoW stuff scares me, and I think they've gone too far in throwing out the good parts of Qt with the bad. There are quite a few changes in Qt5 that are good (the new OpenGL framework for one, not to mention all the C++11 related changes). Ditching MOC is IMO questionable, especially when the overhead of MOC is so negligible these days. No, I don't for a moment think QML is on that list :-). I looked at it once, briefly, and didn't see the point, and you're probably right about how it adds too much complexity for whatever dubious value proposition it might have. (For that matter, I'd like to see all the style sheet crud ripped out of Widgets as well.) Medical devices, industrial controls, even desktop apps want a long stable platform. Phones only care about what is shipping next week. Yup, and this is the same reason why I loathe and want nothing to do with web development. Learning a new "platform" every month is a waste of time. -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Missing QMap Algebra?
I've been in the python world lately and python has a dict.update()
https://python-reference.readthedocs.io/en/latest/docs/dict/update.html
It seems that QMap has no such function anymore, but it also never did? unite()
would make a QMultiMap, so there would be multiple entries rather than one.
Which has me asking the question, do I have to provide this myself? Seems a
pretty trivial thing to have to provide?
QVariantMap map_a, map_b;
...
auto combined_map = map_a;
for (const QString& key: map_b.keys()) {
combined_map[key] = map_b[key];
}
Additionally there is no + operator for it, which is actually what I want:
combined_map = map_a + map_b;
But I would be happy with:
combined_map.update(map_b);
Additionally if we're trying to provide as much algebra as possible:
map_a = combined_map - map_b.keys() // remove by matching key
map_a = combined_map - map_b; // remove by matching key-value pairs
In Python, these are doable in a 1-line list/dict comprehension.
Thoughts?
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 114, Issue 23
On 23/03/2021 01.21, Tuukka Turunen wrote: Feedback on the Qt 6 API is valuable and we are very interested in it. Portability was one of the key design principles and we have avoided making changes when not needed. That said, there can surely be some items that are unnecessarily changed. Why are the QHash changes needed? The main outcome of that seems to be encouraging people to use std::unordered_map instead and destroying trust in Qt's API. Why is QList removed? (I don't mean the *name* "QList", I mean the container with indirect storage and reference stability. It's useful, and unlike QHash, there is no STL equivalent available.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator is so buggy and so slow...
Not sure if it's an option for you guys, but I've been very impressed by the rapid pace of improvement of Qt/CMake/Git/Linux x-compilation tools in MSVC over the past couple of years. They have all gone from being semi-supported add-ons to fully-integrated and functional in the IDE (including even a nested QtDesigner window). I've been working on a CMake/QWidget project and have not had to open up QtCreator itself in about half a year. MS has also really improved its support game. I'm just a lowly open-source "Community Edition" user and my bug reports have all been reproduced/addressed within a day or two. Best, Eric -Original Message- From: Interest On Behalf Of Max Paperno Sent: Tuesday, March 23, 2021 7:42 AM To: interest@qt-project.org Subject: Re: [Interest] Qt Creator is so buggy and so slow... > On 3/18/2021 8:38 PM, Alexander Dyagilev wrote: >> Hello, >> >> Often it just stops to suggest code, syntax highlighted stops working >> (at least for a part of the code) for no apparent reason. >> >> It takes apporx. 10 seconds to parse c++ file for c++ tools to start >> working. If you open/close/open same c++ it can stop parsing it until >> app restart. >> >> App restart often helps to fix these bugs, but they do return in a >> small amount of time... >> >> Any suggestions? >> I often disable the "new" clang-based parser when I'm working on a project of any significant size/complexity. The extra hinting and some other features it provides are nice, but not really worth the expense. 8 x 3.5GHz cores I guess aren't enough to parse my code in real time. I can edit 4K video in real time on this computer, but not really use the clang-parsing in QtC on a "big" project where it would be most useful. All my "valuable feedback" on the issue was summarily ignored, and unfortunately the old code model is no longer maintained (despite some pleas to keep it current), and has some minor issues. But it's fast and still works good enough (last I checked). The clang parser/analyzer can then be run manually as needed to catch any possible outlier issues. I absolutely can't stand having to restart my editors (tools) all the time. And this stuff typically happens when I'm right in mid-flow of work. It's like being 25' up on a ladder with a screw gun that only sometimes works... yea that's getting tossed in the rubbish bin. Cheers, -Max ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience methods
On 22/03/2021 23.18, Jason H wrote: Qt needs to go back to LGPL, or risk getting abandoned/replaced. Seems like some of the long time users here on this list have come to a similar conclusion. I've said this before, and I'll say it again: Qt needs to go the way of OpenOffice.org. That is, we need some folks to step up and decide that we're through with TQtC and we're going to continue Qt on our own, very possibly from 5.15, as pure LGPL. It probably isn't possible for contributors to retract rights already given to TQtC, but stop giving them new rights. Stop contributing under a CLA. It would help tremendously if KDE was on board; wherever they go, the community will probably follow. Right now I'm worried that they're headed toward oblivion, which would make me really sad, because I do *not* care for Gnome. (That's not to say I think Gnome developers or users are terrible people, I just *personally* don't care for it.) (I'd love to take CMake from 6.x, but I'm not exactly neutral in that respect, particularly as I've never used qmake. I'm not sure how much else from 6.x would be worth keeping. *Maybe* some of the move toward QVector. *Not* the total removal of QList, or the changes to QHash.) -- Matthew ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
Having read this entire conversation I find it interesting that we as developers are complaining about features being deprecated and removed in Qt but yet where is the anger when C++ spec removes features? https://en.wikipedia.org/wiki/C%2B%2B20#Removed_features_and_deprecation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2131r0.html#removed http://www.cplusplus2017.info/removed-features-from-c17/ http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1319r0.html#removed I have also been caught when trying to upgrade some legacy codes that were written well over 15 years ago by compiling with a “modern” C++ Compiler. We complain when the API gets bloated and slow then we complain when it gets trimmed down to be fast again. Pick something. I’m not disagreeing with the license issue. I’m not disagreeing with the “Qt6 is a mess”. Just pointing out that even C++ undergoes changes where features that people may have used get’s removed. -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jack...@bluequartz.net [w] www.bluequartz.net From: Interest on behalf of Roland Hughes Date: Tuesday, March 23, 2021 at 7:02 AM To: , Subject: Re: [Interest] The willy-nilly deletion of convenience, methods On 3/23/21 2:31 AM, interest-requ...@qt-project.org wrote: On 3/22/2021 7:32 PM, Turtle Creek Software wrote: Re: willy-nilly I can relate to anyone who is unhappy about deprecated functions. It is never fun when existing code breaks. We want to be inventing new stuff, not going back and fixing old code just to stay in the same place. The C++ language has been decent about advancing, but still keeping ancient code stable. Windows bends over backwards to stay backwards compatible. I think it's a basic courtesy that all platforms owe to developers. Programming is hard. Doing things once should be enough. Amen brother, +100. Life's too short for that BS, and computers are supposed to make our lives easier in the first place. 20 years in the life of a language or API or library is nothing (I'm over 50, which gives me some perspective). Assuming anyone actually uses it for more than a weather app or media browser. Something like that needs to last for as long as anyone uses it, and if it's time for it to die or be replaced then let it go in peace instead of gutting it and pretending it's still the same animal. And yes I do think Windows has done us a great service in this regard... just talk to any non-fanboy MacOS developer who is older than 30. And on *nix of course everyone still uses utilities written before they were born. Stability, baby. Dear QtC: Just call Qt6 a new library and make it all clean and sexy and commercial, or whatever. But at least do right by everyone who's put their time into earlier versions, including by using them, and finish it up in style instead of scandal & annoyance. Not only would all the users appreciate it, but it just may make you seem more reliable going forward. For me personally 5.12.x is the last Qt branch I will trust (until maybe someday all the 5.15 fixes are OS). +1000 Amen! Can I get a witness? Welcome to the north of 50 club, not far from the north of 60 club. The entire problem is this x86-wanna-be-a-real-computer-when-it-grows-up mentality. Real products have to have 30+ years of stability, not be gutted every few years. For those too young to understand, this is where AGILE and Iterative Development fail spectacularly. You are constantly putting out things that aren't going to last. By definition unstable. 30 years is __nothing__ for production systems. It is ordinary for a well developed system to run 10+ years without any modifications. Yeah, you really do need both doc and comments in the code because even if you wrote it, ten years later you are a different person. You can't chase the phone market __and__ serve actual business. These are diametrically opposed goals. When a company puts a surgical robot in the field it has to be maintainable for at least 20 years. They can't afford a gut & rewrite. Yes, over the course of a 20+ year life a robot will "get taught new tricks" but those will be additional tricks. Even something as "simple" as a patient monitor will have to have minor software upgrades due to new FDA/HIPPA regulations. Here's the 8000 pound Elephant in the room. Cross platform isn't needed. Ain't nobody going to put Android or Windows behind a touch screen on a medical device. That's always going to be a Yocto Linux build. The dev host is always going to be a YABU or some other Linux distro. Cross platform has very little meaning in the embedded medical, industrial controls, test equipment world. Cross platform had meaning in the desktop world. It's become a limited meaning though. Yeah, it's nice that I can run text editor A on Windows, Linux, and that obscure platform. The sad reality is they rarely run
Re: [Interest] QML Image size vs sourceSize strange things
Do you really need to same memory by reducing the source size? I think you
should left the source size alone and sample the image from the full source.
Source size for SVG doesn’t make any sense, it’s vectoriel, doesn’t have any
size, it can scale to any dimension. When playing with the image size (not the
source) it will sample the source for each pixel, not sure about the algorithm
but you might need an higher source resolution to get a proper image without
artifact. I would at least take the Screen.devicePixelRatio into the source
size into account and even add a x2 to ensure proper sampling, but I don’t see
any real advantage to play with the source size unless you really are consuming
way too much memory.
This might slow you down if the same image is using different sourceSize:
Note: Changing this property dynamically causes the image source to be
reloaded, potentially even from the network, if it is not in the disk cache.
On Mar 23, 2021, at 3:31 AM, Alexander Dyagilev
mailto:alervd...@gmail.com>> wrote:
Hello,
We had a strange problem with blurred images under Retina displays. Left part
of the image - before, right one - after the fix.
Our QML code was using with to show images:
Image {
anchors.verticalCenter: parent.verticalCenter
sourceSize.width: 25
sourceSize.height: 25
source: preview.url
}
I've tried to multiply sourceSize by Screen.devicePixelRatio - images became
bigger so they did not fit their places.
Then I've replaced sourceSize.width with just width and the same for height.
And it works fine now.
My questions is:
1) Is it required to multiply sourceSize by devicePixelRatio? Or is it managed
automatically? It seems that it is managed automatically for PNG and NOT
managed for SVG.
2) If it is already managed automatically for PNG (these images preview.url are
PNGs) then why was it blurred? The original PNG image is of size 64x64 pixels
under Retina displays.
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Jerome Godbout
Software/Firmare Lead Amotus
C: (581) 777-0050
O: (418) 800-1073 ext.: 114
godbo...@amotus.ca
[cid:image007.png@01D70B66.39FB01C0]
dimonoff.com |amotus.ca
We have moved!
1015 Avenue Wilfrid-Pelletier, Québec, QC G1W 0C4, 4e étage
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator is so buggy and so slow...
I have never had this experience. > Sent: Tuesday, March 23, 2021 at 8:12 AM > From: "Alexander Dyagilev" > To: interest@qt-project.org > Subject: Re: [Interest] Qt Creator is so buggy and so slow... > > When I press F2 it takes 5 seconds for it to go to symbol definition... > Constantly using 100% of CPU. Such a low quality code... > > On 3/18/2021 8:38 PM, Alexander Dyagilev wrote: > > Hello, > > > > Often it just stops to suggest code, syntax highlighted stops working > > (at least for a part of the code) for no apparent reason. > > > > It takes apporx. 10 seconds to parse c++ file for c++ tools to start > > working. If you open/close/open same c++ it can stop parsing it until > > app restart. > > > > App restart often helps to fix these bugs, but they do return in a > > small amount of time... > > > > Any suggestions? > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator is so buggy and so slow...
> -Ursprüngliche Nachricht- > Von: Interest Im Auftrag von Alexander > Dyagilev > Gesendet: Dienstag, 23. März 2021 13:13 > An: interest@qt-project.org > Betreff: Re: [Interest] Qt Creator is so buggy and so slow... > > When I press F2 it takes 5 seconds for it to go to symbol definition... > Constantly using 100% of CPU. Such a low quality code... Hi, The 100% CPU sounds like a bug to me. Is that also on macOS? Are you using the latest Qt Creator? And finally, is it reproducible also for a code base one can try out? Kai > On 3/18/2021 8:38 PM, Alexander Dyagilev wrote: > > Hello, > > > > Often it just stops to suggest code, syntax highlighted stops working > > (at least for a part of the code) for no apparent reason. > > > > It takes apporx. 10 seconds to parse c++ file for c++ tools to start > > working. If you open/close/open same c++ it can stop parsing it until > > app restart. > > > > App restart often helps to fix these bugs, but they do return in a > > small amount of time... > > > > Any suggestions? > > > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator is so buggy and so slow...
On 3/18/2021 8:38 PM, Alexander Dyagilev wrote: Hello, Often it just stops to suggest code, syntax highlighted stops working (at least for a part of the code) for no apparent reason. It takes apporx. 10 seconds to parse c++ file for c++ tools to start working. If you open/close/open same c++ it can stop parsing it until app restart. App restart often helps to fix these bugs, but they do return in a small amount of time... Any suggestions? I often disable the "new" clang-based parser when I'm working on a project of any significant size/complexity. The extra hinting and some other features it provides are nice, but not really worth the expense. 8 x 3.5GHz cores I guess aren't enough to parse my code in real time. I can edit 4K video in real time on this computer, but not really use the clang-parsing in QtC on a "big" project where it would be most useful. All my "valuable feedback" on the issue was summarily ignored, and unfortunately the old code model is no longer maintained (despite some pleas to keep it current), and has some minor issues. But it's fast and still works good enough (last I checked). The clang parser/analyzer can then be run manually as needed to catch any possible outlier issues. I absolutely can't stand having to restart my editors (tools) all the time. And this stuff typically happens when I'm right in mid-flow of work. It's like being 25' up on a ladder with a screw gun that only sometimes works... yea that's getting tossed in the rubbish bin. Cheers, -Max ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Qt Creator is so buggy and so slow...
When I press F2 it takes 5 seconds for it to go to symbol definition... Constantly using 100% of CPU. Such a low quality code... On 3/18/2021 8:38 PM, Alexander Dyagilev wrote: Hello, Often it just stops to suggest code, syntax highlighted stops working (at least for a part of the code) for no apparent reason. It takes apporx. 10 seconds to parse c++ file for c++ tools to start working. If you open/close/open same c++ it can stop parsing it until app restart. App restart often helps to fix these bugs, but they do return in a small amount of time... Any suggestions? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Crash in Qt OpenSSL thread
I am assuming that running the application under Valgrind at the client site to catch the crash is not an option. Suggestions in order of least amount of pain. Since I see .dll in your output I will also assume Windows platform. 1.) Run CppCheck and other static source analysis tools to make certain you don't have an uninitialized member variable. If you are open to purchasing a commercial one, Gimpel's PC-lint used to be one of the best on the market back when I still did development on the evil OS. 2.) Run your application under Valgrind like the user has been and check for memory leaks. "Rare crash" failing on an allocation usually means "slow leak" and a long-run application. Eventually you exceed the memory allowed the user account or in the entire machine. Bounds Checker used to be really great for this and it didn't bury the application like Valgrind does. https://en.wikipedia.org/wiki/BoundsChecker 3.) I don't think they have added it to QSysInfo (or any other) class yet, a platform independent way of getting current free memory in some unit. I've had to add this to many embedded systems. If your application already has logging then this is the cats meow. a.) add a configurable timer. b.) add lastFreeSize and initial to zero c.) write a slot that is the target of the timer. Every N minutes grab the amount of free RAM. If it is different by y% write an entry to the log. Don't be tempted to write it each and every time as you can chew up quite a bit of disk if the application starts and runs forever. When your application already has some kind of logging you can get some idea if the problem is either your code or something else on the computer. It's possible they tried to open a 5 million row spreadsheet or something like that. Pesky Windows users, always opening a hundred funny cat videos. The timer slot thing is kind of nice because you can set some minimum threshold and pop up a warning message to the user that their computer is low on memory and ask them to close half of those funny cat videos. On 3/23/21 6:00 AM, interest-requ...@qt-project.org wrote: We use Qt 5.12.10. It seems it's a rare crash. Any thoughts what can be the cause of it and can it be fixed somehow? -- Roland Hughes, President Logikal Solutions (630)-205-1593 http://www.theminimumyouneedtoknow.com http://www.infiniteexposure.net http://www.johnsmith-book.com http://www.logikalblog.com http://www.interestingauthors.com/blog ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] The willy-nilly deletion of convenience, methods
On 3/23/21 2:31 AM, interest-requ...@qt-project.org wrote: On 3/22/2021 7:32 PM, Turtle Creek Software wrote: Re: willy-nilly I can relate to anyone who is unhappy about deprecated functions. It is never fun when existing code breaks. We want to be inventing new stuff, not going back and fixing old code just to stay in the same place. The C++ language has been decent about advancing, but still keeping ancient code stable. Windows bends over backwards to stay backwards compatible. I think it's a basic courtesy that all platforms owe to developers. Programming is hard. Doing things once should be enough. Amen brother, +100. Life's too short for that BS, and computers are supposed to make our lives easier in the first place. 20 years in the life of a language or API or library is nothing (I'm over 50, which gives me some perspective). Assuming anyone actually uses it for more than a weather app or media browser. Something like that needs to last for as long as anyone uses it, and if it's time for it to die or be replaced then let it go in peace instead of gutting it and pretending it's still the same animal. And yes I do think Windows has done us a great service in this regard... just talk to any non-fanboy MacOS developer who is older than 30. And on *nix of course everyone still uses utilities written before they were born. Stability, baby. Dear QtC: Just call Qt6 a new library and make it all clean and sexy and commercial, or whatever. But at least do right by everyone who's put their time into earlier versions, including by using them, and finish it up in style instead of scandal & annoyance. Not only would all the users appreciate it, but it just may make you seem more reliable going forward. For me personally 5.12.x is the last Qt branch I will trust (until maybe someday all the 5.15 fixes are OS). +1000 Amen! Can I get a witness? Welcome to the north of 50 club, not far from the north of 60 club. The entire problem is this x86-wanna-be-a-real-computer-when-it-grows-up mentality. Real products have to have 30+ years of stability, not be gutted every few years. For those too young to understand, this is where AGILE and Iterative Development fail spectacularly. You are constantly putting out things that aren't going to last. By definition unstable. 30 years is __nothing__ for production systems. It is ordinary for a well developed system to run 10+ years without any modifications. Yeah, you really do need both doc and comments in the code because even if you wrote it, ten years later you are a different person. You can't chase the phone market __and__ serve actual business. These are diametrically opposed goals. When a company puts a surgical robot in the field it has to be maintainable for at least 20 years. They can't afford a gut & rewrite. Yes, over the course of a 20+ year life a robot will "get taught new tricks" but those will be additional tricks. Even something as "simple" as a patient monitor will have to have minor software upgrades due to new FDA/HIPPA regulations. Here's the 8000 pound Elephant in the room. Cross platform isn't needed. Ain't nobody going to put Android or Windows behind a touch screen on a medical device. That's always going to be a Yocto Linux build. The dev host is always going to be a YABU or some other Linux distro. Cross platform has very little meaning in the embedded medical, industrial controls, test equipment world. Cross platform had meaning in the desktop world. It's become a limited meaning though. Yeah, it's nice that I can run text editor A on Windows, Linux, and that obscure platform. The sad reality is they rarely run the same. Just try KATE on Windows. So, yes. A browser, an editor, a music player, in short, tiny "consumer apps" have some need for cross platform. The real business apps just don't do it. A front end for a medical records system simply isn't going to run on Mac or Linux unless they went with a browser interface. The phone world is just an alternate reality. That's actually how this downward spiral started, with the introduction of QML and forcing people to re-write, re-write, re-write. People poke fun at COBOL, but the reason it still today has more lines of code in production than any other language is the fact COBOL doesn't delete anything until the hardware and OS it was added to support can only be found in a museum. The compiler vendors also send out technical bulletins to their customers when considering changes. If it is not forced on them by a language standards committee they query the customer base before doing it. This isn't a deprecation warning someone stumbles into when they try to compile something old. It's actual communication. All of this is too late of course. For roughly the past two years there has been zero management of Qt in general. That's why I only see medical device projects still using Qt 4.8 OpenSource or a token few that are trying
Re: [Interest] Crash in Qt OpenSSL thread
Hello! Given the issue (heap corruption) and lack of symbols for openssl it's somewhat hard to determine. With heap corruption it could be a buffer overflow somewhere else in the application which is then caught during the malloc call. Mårten From: Interest on behalf of Alexander Dyagilev Sent: Sunday, March 21, 2021 20:32 To: Interests Qt Subject: [Interest] Crash in Qt OpenSSL thread Hello, One of our users reported the following crash: Unhandled exception at 0x7FF82C50EF89 (ntdll.dll) in fdm.exe.3964.dmp: 0xC374: A heap has been corrupted (parameters: 0x7FF82C5777F0). With the following stack trace: ntdll.dll!RtlReportFatalFailure ()Unknown ntdll.dll!RtlReportCriticalFailure ()Unknown ntdll.dll!RtlpHeapHandleError ()Unknown ntdll.dll!RtlpHpHeapHandleError ()Unknown ntdll.dll!RtlpLogHeapFailure ()Unknown ntdll.dll!RtlpLowFragHeapAllocFromContext()Unknown ntdll.dll!RtlpAllocateHeapInternal ()Unknown ucrtbase.dll!_malloc_base()Unknown libcrypto-1_1-x64.dll!7fffc4a6f16e()Unknown libcrypto-1_1-x64.dll!7fffc4a719b9()Unknown libssl-1_1-x64.dll!7ff813f6e166()Unknown libssl-1_1-x64.dll!7ff813f85f3f()Unknown libssl-1_1-x64.dll!7ff813f66d0c()Unknown Qt5Network.dll!QSslSocketBackendPrivate::startHandshake() Line 1011C++ Qt5Network.dll!QSslSocketBackendPrivate::startServerEncryption() Line 695C++ Qt5Network.dll!QSslSocket::startClientEncryption() Line 1855 C++ Qt5Network.dll!QSslSocket::qt_static_metacall(QObject * _o, QMetaObject::Call _c, int _id, void * * _a) Line 180C++ Qt5Core.dll!QMetaObject::activate(QObject * sender, int signalOffset, int local_signal_index, void * * argv) Line 3807 C++ Qt5Network.dll!QAbstractSocketPrivate::_q_testConnection() Line 1181C++ Qt5Network.dll!QWriteNotifier::event(QEvent * e) Line 1310C++ Qt5Widgets.dll!QApplicationPrivate::notify_helper(QObject * receiver, QEvent * e) Line 3652C++ Qt5Widgets.dll!QApplication::notify(QObject * receiver, QEvent * e) Line 3604C++ Qt5Core.dll!QCoreApplication::notifyInternal2(QObject * receiver, QEvent * event) Line 1088C++ Qt5Core.dll!qt_internal_proc(HWND__ * hwnd, unsigned int message, unsigned __int64 wp, __int64 lp) Line 204C++ user32.dll!UserCallWinProcCheckWow()Unknown user32.dll!DispatchMessageWorker()Unknown Qt5Core.dll!QEventDispatcherWin32::processEvents(QFlags flags) Line 650C++ Qt5Core.dll!QEventLoop::exec(QFlags flags) Line 225C++ Qt5Core.dll!QThread::exec() Line 531C++ Qt5Core.dll!QThreadPrivate::start(void * arg) Line 405C++ kernel32.dll!BaseThreadInitThunk ()Unknown ntdll.dll!RtlUserThreadStart ()Unknown We use Qt 5.12.10. It seems it's a rare crash. Any thoughts what can be the cause of it and can it be fixed somehow? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Interest Digest, Vol 114, Issue 23
On Tue, 23 Mar 2021 at 15:24, Tuukka Turunen wrote: > > > Hi, > > Feedback on the Qt 6 API is valuable and we are very interested in it. > Portability was one of the key design principles and we have avoided making > changes when not needed. That said, there can surely be some items that are > unnecessarily changed. > > Knowing what is the problem and the intended use case helps to have this > discussion. Our API review process is fully open, but it is natural that > users do not want to necessarily engage in it. So we welcome the feedback on > the API also now and will try to seek ways to improve based on it. Please Tuukka, your open-source users are BEGGING you to revisit the 5.15 LTR policy. Regardless of how actively we maintain our codebases and how proactively we've been at removing deprecated API the reality is that the vast majority of us just can't move to Qt 6 yet due to a whole range of reasons. PLEASE PLEASE PLEASE revisit this decision and open the 5.15.3+ patch releases for open source developers and projects. Nyall ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
