[Interest] My first 5 years with Qt and 2 suggestions
mike.jackson at bluequartz.net
Thu May 9 13:57:06 CEST 2019
Nice to have such a strong supporter in the Qt community, my opinions are in line...
On 5/8/19, 8:09 PM, "Interest on behalf of Henry Skoglund" <interest-bounces at qt-project.org on behalf of fromqt at tungware.se> wrote:
Hi, 5 years ago I started with Qt, it's been a very nice ride, thank
you! Looking forward to the next 5. Got 2 suggestions:
1) Make Qt more easily accessable for first timers:
Why not introduce a Qt Starter Pack?
I'm thinking of an *extremely* simplified installation tool. For
Windows, it could be Qt LTS version bundled with the 32-bit MinGW compiler.
No login, no selection of kits and no selection of a directory where to
install (instead hardwired to C:\Qt). Just one big button: "Install".
Uninstall is done through the control panel. No updates possible,
Great Idea. One problem with the scheme is that most enterprises do _not_ allow write access to the C: drive so the installer must at least allow this one single choice to be made.
2) Improved Qt DLL morphology: for a given DLL, today we have very
coarse naming schemes, it's either Qt4Core.dll, Qt5Core.dll or
Qt6Core.dll (and similar namings on the other platforms).
On the Qt forums I see questions, they have the MinGW version installed,
and instead of windeployqt, for deployment they have manually copied the
DLLs from the QtCreator bin directory --> DLL hell.
This is how we create our own application package. The Qt DLL's are copied from the Qt installation into the build directory. Long ago I learned this was pretty much the only way to prevent DLL hell. Keep the system path clean, don't let anything put their own paths into the System path. At the time we supported 32 and 64 bit on both VS2008 and VS2012 and it was absolute DLL hell. We learned to just NOT put anything on the system path and to create build rules to copy the proper DLLs into the build directory so that we knew for sure which DLLs were getting loaded.
Or they have a Qt program like Krita installed on their C:, and some
PATH setting causes Qt DLLs to clash with their Qt installation or
deployment --> DLL hell.
See above. I would argue if Krita is "installing" Qt DLLs into a system directory they are simply doing it wrong. They should package the DLL's into their app package and distribute it that way. If the user is adjusting their system path to make Krita work, there is something wrong.
Or they have copied Qt5Core.dll with wrong bitness, 64 instead of 32 etc.
This is just a basic mistake that we all make at some point during our development. I think we have all done it at some point. I tend to miss the "d" in the name when copying the DLLs manually (which is why one creates build rules for your build system to always get the correct DLL copied).
At some point some of the issues are just user errors and the Qt devs can't be expected to make up for that. Better documentation and examples would help to alleviate those mistakes.
For that last syndrome, I remember from my Visual Basic days, there were
16-bit and 32-bit versions, but Microsoft had different DLL names then,
either VBRUN40016.DLL or VBRUN40032.DLL. (Today for example
vcruntime140.dll has the same name regardless of bitness, 32-bit version
is in C:\Windows\SysWOW64 and 64-bit version is in C:\Windows\System32,
if this seems logical you need to change medication.)
So my suggestion is, let's reverse this trend, introduce a much more
fine-grained naming scheme, examples:
Qt5Core.dll for Qt 5.12.3 MSVC2017 32-bit --> QtCore51203MS1732.dll
Qt5Core.dll for Qt 5.12.3 MSVC2017 64-bit --> QtCore51203MS1764.dll
Qt5Core.dll for Qt 5.12.3 MinGW7.3.0 32 bit --> QtCore51203GW7332.dll
Qt5Core.dll for Qt 5.12.3 MinGW7.3.0 64 bit --> QtCore51203GW7364.dll
Qt5Gui.dll for Qt 5.12.3 MSVC2017 32-bit --> QtGui51203MS1732.dll
Qt5Gui.dll for Qt 5.12.3 MSVC2017 64-bit --> QtGui51203MS1764.dll
Qt5Gui.dll for Qt 5.12.3 MinGW7.3.0 32 bit --> QtGui51203GW7332.dll
Qt5Gui.dll for Qt 5.12.3 MinGW7.3.0 64 bit --> QtGui51203GW7364.dll
and so on.
This naming scheme would eliminate lots of DLL hells occurring today in
Windows, and would be much more tolerant/allowing to a Windows system
having multiple Qt installations of different versions.
VS2017 and VS2019 have compatible runtime libraries so your naming scheme already causes confusion. Qt 5.12.x are all ABI compatible so 5.12.1, 5.12.2, 5.12.3 are all compatible so it does not really matter the naming for Qt 5.12.x. GW is confusing (MGW might be better). QtGui512VC14x64(_debug).DLL might be an alternate scheme if you really want to go down that road but the current naming scheme I think works for the vast majority of developers (we know better) and a "user" of an application built on top of Qt should not have to know the difference.
Interest mailing list
Interest at qt-project.org
More information about the Interest