I apologize in advance as this will probably be long. I have been involved in many long rants on qt-interest mailing list about the lack of stability in the API and the continual Easter Egg hunt as each minor release seems to restructure at least a single header directory breaking builds wholesale. There has been a current discussion about the dropping of win 7 that has brought up many of these topics again.
https://lists.qt-project.org/pipermail/interest/ "Windows 7 support will be, dropped in Qt 6"
I believe that conversation started last month. Basically "the kids" (I'm old!) making the decisions seem to care not about the installed base when chasing features for a new phone. Yes, I'm on record stating repeatedly that the introduction of QML and JavaScript was a wretched idea. I'm kicking the tires on CopperSpice because I hope against hope that this will be the product for grown ups.
The big ticket world of medical devices and industrial controls needs API stability. What they really need is a 15+ year LTS but barring that, they can get by with being able to compile their 15+ year old code with the latest version of the libraries. That means:
- header files don't change location.
- methods don't disappear from classes
- classes don't get renamed or removed
Here is a "brief" snippet from one of my messages:
=====
It must have a stable API. Classes don't get renamed and methods don't
get dropped from those classes.
They must never allow the search for a header file to become an Easter
Egg hunt as it has with Qt release to release.
That's really the two requirements.
This ensures a program written today on some OS will be able to compile
against a release 30+ years from now even if it is a different OS the
program is running on. This is a cross platform library after all.
Have you been using Qt long enough to remember when multiple inheritance
got butchered because the powers that be wanted to lower the bar for
Java developers?
Code: Select all
/****************************************************************************
* Originally created by Roland Hughes at Logikal Solutions.
* Project is being released under GPL2 license.
*
* At some point in the future either Logikal Solutions or Roland Hughes
* may elect to publish a book with this original source code in it. If
* the book is written it will be part of "The Minimum You Need to Know"
* book series.
****************************************************************************/
#ifndef CATEGORIESDIALOG_H
#define CATEGORIESDIALOG_H
#include <QDialog>
#include <QtSql>
#include "ui_CategoryDialog.h"
class CategoryDialog : public QDialog, public Ui::categoryDialog
{
Q_OBJECT
public:
CategoryDialog( QWidget *parent, const QString &qtDbName);
QString getEnteredCategory() { return m_category;};
private slots:
void addCategory();
private:
QString m_qtDbName;
QSqlDatabase m_categoryDb;
QString m_category;
};
#endif
millions) of lines of code in the field and to make Java developers feel
warm and fuzzy that was just dropped. Kids today who started with 5.x or
later have no ability to function in that world. They have no frame of
reference to get a handle on it. If they can't see and use this:
Code: Select all
/****************************************************************************
* Originally created by Roland Hughes at Logikal Solutions.
* Project is being released under GPL2 license.
*
* At some point in the future either Logikal Solutions or Roland Hughes
* may elect to publish a book with this original source code in it. If
* the book is written it will be part of "The Minimum You Need to Know"
* book series.
****************************************************************************/
#ifndef CATEGORIESDIALOG_H
#define CATEGORIESDIALOG_H
#include <QDialog>
#include "ui_categorydialog.h"
QT_BEGIN_NAMESPACE
namespace Ui { class CategoryDialog; }
QT_END_NAMESPACE
class CategoryDialog : public QDialog
{
Q_OBJECT
public:
CategoryDialog(QWidget *parent, const QString &qtDbName);
~CategoryDialog();
QString getEnteredCategory();
private slots:
void addCategory();
private:
Ui::CategoryDialog *ui=nullptr;
QString qtDbName;
QString category;
};
#endif
They simply cannot function. That may seem like minor little thing, but
when you have a device in production and a code base exceeding a million
lines in a regulated world, that change locked you. Bringing in the new
version of Qt (even if it ran on your OS) would require changing every
module when all you were trying to do was update the device to support
one shiny new thermometer or other device.
Once that barrier came down; the flood gates opened; scripting languages
washing in like a tidal flood and with them, an ocean of developers not
formally trained.
Had the barrier of multiple inheritance being a requirement not been
removed, we wouldn't have veered this far into the weeds.
I cannot, in good conscience, despite all my years of using it,
recommend Qt to any paying client. The licensing, royalties, and lack of
good direction make this a tool they should not spend money on. Medical
devices will be deployed in primary market countries for 10-18 years
then refurbished and redeployed to third and fourth world markets where
they will serve another 10-20 years and still need to be supported.
The market that pays long term support contracts (medical and industrial
devices mainly) needs a tool set guided by people who were formally
trained. That hasn't been happening with Qt. It's not an elitist
comment. Formally trained people remember the installed base is sacred.
You don't sacrifice it without a massively good reason. Adding Java and
scripting languages was not a massively good reason.
=====
Another conversation thread has also popped up and I'm actually not a participant in it.
https://lists.qt-project.org/pipermail/interest/ "Set manipulation in Qt 6"
-----
While I sympathize to some degree with the performance motivation behind this
kind of removal of convenience functionality this has to be put into perspective
of the price you charge:
We had to spent a significant amount of our time during the last year to
keep up with the deprecations within the last releases in the 5.x series.
This includes re-inventing parts of the abandoned qalgorithm as part of
our code base.
The toSet/toList changes alone involved touching 200+ locations in the code
base and I am not aware of even a single noticable performance improvement
as a result.
A back-of-the-envelope calculation with generous assumptions on user count and
usage frequency makes me believe that the accumulated win on saved computer
time does not even offset the amount of manual work that had to be spent
on these changes.
-----
Is the focus of the CopperSpice project going to be supporting the large medical device/industrial controls industry with such a stable API?
If you visit the interest archive and read some of the messages for the past two months you will get the sense a large chunk of the Qt community is about to kick it to the curb. One poor schmoe is trying to support a big ticket client running their applications on CentOS 5. There was some debate as to whether a C++17 compiler could be installed on that rev, but so far I don't think anyone has actually tried.
The problem isn't just keeping "old stuff." The problem is the farther the API moves the lower one's chances are of being able to hire a new API developer and have them function in the old environment. To save you the trouble of reading all those messages, one of the medical device companies I brought up seems to run contract postings every 18 months or so trying to get Qt3 under OS/2. Yes, there are still a few out there, but that company isn't willing to pay anywhere near the hundreds of dollars per hour they cost. Adding insult to injury, a very large segment of "Qt Developer" only know QML and JavaScript so they don't know Qt at all.
Given all of the recent licensing changes with Qt and the constant disregard for the installed base when making enhancements, the medical device and industrial controls segments or their customer base is looking for a new tool. The "just use the old versions" philosophy isn't a long term solution as the Qt3 OS/2 customer should make abundantly clear. They can't get new people unless they either let them spend hundreds of hours learning Qt3 from scratch or pay hundreds of dollars per hour. Given the age of those who actually ran OS/2 (myself included) the hundreds of dollars per hour solution won't be viable much longer either.
Thoughts?