Roland, I'll start off by acknowledging your points, but we will just agree to disagree. I acknowledge that you have a *lot* of years making/maintaining software for medical devices. But I'm with Hamish on this. I don't understand.
What you are saying is that Qt was designed "perfectly" from day one with no extra API, not one bad API implementation and no cruft. Qt should never be updated to run on modern compilers against modern C++ specifications. Updated to run on modern operating systems. Qt should not explore adding APIs/Toolkits to the Qt ecosystem to allow Qt to be used on the billions of devices that we use every day. Qt should just stick with its technology from 20 years ago. TQtC shouldn't go after paying customers in order to, you know, pay its developers. TQtC should rely solely on an industry that, by your own writings, have a 15 year horizon. Not much of a business case for that. (For the record, I don't particularly agree with TQtC current licensing or LTS strategy.) I also don't understand your argument that you want to update a medical device from 20 years ago with the latest and greatest toolkits. I can't imagine anything electronic from 20 years ago being able to actually load and run anything like Qt? How is the hardware even powerful enough to do this? You can't convince me that the medical hardware device manufacturers were thinking 15 years into the future for the next upgrade, 15 years ago. 50 Year Old equipment. You make the case even more for TQtC to pursue customers with a much shorter timeline. If TQtC concentrated on markets with 20-50 year timelines for updates how much revenue do you think they would make? Enough to sustain Qt development in any real capacity? Doubtful. Some of us like to create cross platform desktop applications that inspire our users to create the next cool thing. For that Qt is just about the only viable toolkit out there although others are coming on strong. We would like to see Qt keeping up with the latest C++ specs so we can use all the cool new APIs. Both our software development worlds are important to each of us. We are almost diametrically opposed in what we want from the same toolkit. Neither is 100% right and neither is 100% wrong. Only TQtC can decide where to put their resources so that they make enough revenue to continue the development of Qt. I'm not going to comment on the Fortran thing. It isn't relevant to this conversation. Again, this is *not* an endorsement of the current licensing issues with Qt 5.15 and 6.0. I'm just enough put off to find something else after 15 years of using Qt. -- Michael Jackson | Owner, President BlueQuartz Software [e] mike.jack...@bluequartz.net [w] www.bluequartz.net On 3/26/21, 9:45 AM, "Interest on behalf of Roland Hughes" <interest-boun...@qt-project.org on behalf of rol...@logikalsolutions.com> wrote: On 3/26/21 6:00 AM, Hamish Moffatt wrote: > I really don't understand your arguments Roland. You say you need Qt > support for 15 years, but you can't actually change one bit of your > software without FDA approval, so presumably this means you aren't > upgrading Qt anyway. Then after 15 years you want to work on a new model > of the device, starting with your existing code, and you expect it to > compile with the latest Qt unchanged? Stable API. By definition a Stable API only has additions. In incredibly rare isolated cases things get deleted ___AFTER__ they have a direct or mostly direct replacement. I was involved in a discussion a couple months ago with someone who just that morning cracked open 50 year old FORTRAN that compiled with the latest FORTRAN compiler just fine. The code had been running in production unchanged for 50 years. That's ordinary in the deep pockets world, not an exception, the rule. > Someone else was talking about support for RHEL 6. Why do you expect to > use the latest Qt with an ancient OS? Is it reasonable to expect to use > new Qt with an ancient OS? Qt actively pursued these markets and then abandoned them. Multi-million dollar investments (if I remember what Scott wrote correctly, a billion with a B dollar investment) on long term projects. Well, ordinary term for our worlds but beyond the Arc of Time for what Qt now pursues. These investments got made because the stuff was supposed to be supported for the duration. Our worlds last longer than a gallon of milk and they were actively pursued. > > I see that the latest Microsoft Visual C++ compiler toolset (v142) > doesn't support building for Windows XP. You can still use an older > compiler. That seems like a reasonable compromise. > When you come from a short lived world, that would seem reasonable. We walk in worlds where stuff routinely runs 30-50 years. It's a requirement. The gist of this thread seems to be, from Thiago and others, is that those who need Qt to be a viable product with a stable API need to fork it into a completely separate project that doesn't delete anything without querying the installed base. You want to see how viable companies and products are managed. ======= Hi Roland, We'll soon be making decisions about Synergy/DE product direction in a number of areas, as well as about potential new products, and we're very interested in your input. Please complete this brief survey to help us determine our priorities and future development direction. Start Survey Or use this link: https://survey.sogosurvey.com/k/QsQWSXRSsRWsSUXUSWVQTsP SURVEY DEADLINE: Tuesday, March 30 (end of day) Everyone who completes the survey will be entered into a raffle to win a $250 gift card. Thank you for participating, The Synergex Team ======= I haven't done squat with DIBOL in years. I did write Synergex a nice "how to use it on VMS" chapter some years ago that they are free to use however they want. Every time they are ready for major changes one of these things comes out. They understand that the care and feeding of the installed base is what keeps a roof over their head and food on their table. That once you pursue an industry and get it to invest in your product, you don't abandon it. The mantra from the Qt project, and Digia for that matter, is "Sucks to be you!" You want the Cliff Notes response? Qt as a community and commercial product pursued the medical device and SAFETY industries because of their deep pockets. They pursued these industries knowing full well that, baring a product with adverse outcomes, 15 years would be the soonest redevelopment would happen. From time to time we get hit with new industry regulations and have to tweak something. During those times we tend to update any libraries because we are going to have to bite the bullet on some level of approval anyway. We can successfully do this when we have a stable API. What you can't generally do is slip in a new OS. Here is a real life real world example. Most every medical device manufacturer that had touch screens on their devices had super secret field service screens on the device. When the devices had an external USB or other connection it was customized to have extra pins and those screens couldn't be accessed unless you had the "key" so to speak. In addition to the "key" you had to know the field service access code. Usually a 4-6 digit code. For devices that didn't have external ports you had to have the proper tool to crack up the case so you could install the field service card that had the port. Most considered bifurcated security good enough. Everybody overlooked the fact that XYZ corporation's products all used 1709 as their access code and Harry Widgets medical devices all used 4591. Not just one model, all models. In the Post 9/11 cyber security changes that started coming down the FDA decided that each customer should be able to set their own field service code and that field service would need to request it from the administrators. Every major customer decided they wanted that code pre-configured so their people could just unbox a new one and start using it. Every little customer wanted to set the code themselves as part of the initial setup. Pretty obvious a lot of new screen work had to happen when you consider it impacted every device ever made that had field service screens. Devices currently in the field had to be retrofited as well. Almost every manufacturer updated what they were using for screen libraries at this time. Even the device manufacturers using Qt 4.8 and sharing fixes with other manufacturers did this. Some tried to go to the latest Qt only to find the journey perilous. I will let Scott and others give examples from their worlds if they choose. There is a huge embedded device industry that doesn't make disposable products. It appears the Qt project is only pursuing disposable products at this point. -- 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 _______________________________________________ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest