[Interest] the path forward - that 7 year thing - was, willy-nilly

Fri Mar 26 19:39:42 CET 2021

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.jackson at bluequartz.net
[w] www.bluequartz.net

On 3/26/21, 9:45 AM, "Interest on behalf of Roland Hughes" <interest-bounces at qt-project.org on behalf of roland at 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 at qt-project.org
    https://lists.qt-project.org/listinfo/interest