[Interest] My first 5 years with Qt and 2 suggestions

[Michael Jackson]

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, 
    uninstall/download/reinstall only.
    
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.

----
Mike Jackson


    
    Rgrds Henry
    
    _______________________________________________
    Interest mailing list
    Interest at qt-project.org
    https://lists.qt-project.org/listinfo/interest