[Development] Online installer no longer lets users choose between Qt 5.3.0 and Qt 5.3.1

[Ziller Eike]

On Jul 16, 2014, at 4:03 PM, Sze Howe Koh <szehowe.koh at gmail.com> wrote:

> On 7 July 2014 19:11, Frederik Gladhorn <frederik.gladhorn at digia.com> wrote:
>> Mandag 7. juli 2014 10.02.55 skrev Ziller Eike:
>>> On Jul 7, 2014, at 11:17 AM, Frederik Gladhorn <frederik.gladhorn at digia.com>
>> wrote:
>>>> Mandag 7. juli 2014 07.10.00 skrev Koehne Kai:
> 
>>>>>> No. When running an installer (online or offline), Qt Creator is a
>>>>>> compulsory component (although Qt itself is non-compulsory). I remember
>>>>>> someone saying that Qt Creator is made compulsory because of
>>>>>> interdependencies between the Maintenance Tool and Qt Creator.
>>>>>> 
>>>>>> What are these dependencies? I'm willing to have a go at reducing this
>>>>>> coupling, if I know where to look. I believe one of them is for the
>>>>>> installer to register "auto-detected" kits. Instead of having the
>>>>>> installer perform this registration, would it make sense for it to
>>>>>> simply
>>>>>> add a "search path" to a global Qt Creator config file, and let Qt
>>>>>> Creator search for and register new copies of Qt at startup?
>>>>> 
>>>>> Registration of Qt versions, kits, and toolchains is indeed the primary
>>>>> problem. We call Qt Creator's sdktool.exe in the
>>>>> installation/deinstallation scripts of the Qt versions & the mingw
>>>>> toolchains .
>>>>> 
>>>>> I'm not sure doing too much (file system) magic on Qt Creator startup
>>>>> though is the right thing to do, since it will slow down every launch.
>>>>> 
>>>>> Alternatives that have been discussed in the past:
>>>>> 
>>>>> 1. Move the sdktool.exe out of the Qt Creator package, into a separate
>>>>> one,
>>>>> and only make this one mandatory. That means though we'd need to ship
>>>>> separate Qt libraries for this tool only, effectively increasing the size
>>>>> of a 'default' installation.
>>>>> 
>>>>> 2. Don't deregister/register toolchains and kits in the qt packages, but
>>>>> in
>>>>> separate virtual (i.e., hidden) packages that are only installed if both
>>>>> the resp. Qt version package and the Qt Creator package gets installed
>>>>> (AutoDependOn in IFW speak). This will only be a workaround though for
>>>>> new
>>>>> packages ... already released qt versions will still have a hard
>>>>> dependency
>>>>> on Qt Creator.
>>>>> 
>>>>> 3. Accept the fact that, if people first install a Qt version / toolchain
>>>>> and _later on_ install Qt Creator, the toolchain & Qt version won't show
>>>>> up.
>>>> 
>>>> 4. I still think on Windows using the registry would be the way around
>>>> this. On Linux and Mac the respective .config dirs. Python for examples
>>>> does this on installation on Windows and can then be found by looking it
>>>> up in the registry.
>>>> This solution is imho portable and allows all Qt versions to be found by
>>>> all Creator instances as well as other tools (qtchooser would be a good
>>>> candidate to make use of the same mechanism).
>>> 
>>> Since there are no “system wide” config dirs that would mean using something
>>> like /etc (/opt ? /usr/local?) on Linux, /Library/Preferences on Mac, and
>>> “current_machine” registry on Windows for “system wide” installations, and
>>> “.config” on Unix and “current_user” registry on Windows for “user”
>>> installations.
>> 
>> Qt should offer a good enough settings API for this. That said, I guess it's
>> currently not the case and we should polish/rewrite/replace/extend QSettings
>> to make it work.
> 
> Not quite system-wide, but Qt Creator already uses a profile-wide
> config dir, no? I was under the impression that
> %APPDATA%/Roaming/QtProject was the place where all Qt Creator
> instances store their settings (on Windows).

That’s per user, so it cannot be used for an installer that installs for all users.


>>> That would make things much more complicated, and possibly force that
>>> information to be compatible between versions of Qt Creator (it’s btw not
>>> only about Qt versions here, also all the other things that are specified
>>> for kits).
>> 
>> This is a valid point. I wonder if it wouldn't be possible to use XML/JSON in
>> a way that it's extensible enough. Worst case the settings need a migration
>> path to newer versions - many tools do that - let you upgrade but now
>> downgrade. Should you then want to downgrade to older Qt Creator versions you
>> may have to re-configure the kits.
> 
> I think that's a reasonable compromise. I don't imagine that
> downgrading Qt Creator would be a frequent activity, especially after
> it becomes a deselectable component of Qt installers.

Especially if Qt Creator can be deselected, and all Qt Creator installs read the same configuration for the Qt versions, it becomes vital that installing a newer Qt does not make the global Qt Creator configuration unreadable by older Qt Creator versions. Assume I have a Qt Creator install that I use and that works, now I want to try some newer or other Qt, and install that without upgrading my Qt Creator (why should I). That’s exactly my point.

>>> Also, I currently have 5 offline Qt installers installed simultaneously for
>>> testing. Using a “machine/user wide” registration mechanism, instead of an
>>> “installation wide” registration mechanism would basically disallow that.
>> 
>> I think we (those developping Qt and Creator etc.) are still the minority and
>> will always have special setups. The question is if we aim at getting the
>> experience right for ourselves or everyone else first.
> 
> +1 This discussion stemmed from user experience issues.

So, does everybody then always need to install Qt as administrator? Or do we then have some fallback path that does not write to / read from the global configuration after all? From a user point of view, I’m also very happy that I currently can just trash the Qt install directory, and do not need to clean up afterwards, to uninstall.


Actually the question if some global configuration should be written, and used or an “installation” specific configuration, is IMO pretty orthogonal to the actual original discussion, which was about having Qt Creator deselectable in the installer.

Currently we write a configuration file that is specific to the Qt Creator that comes with the Qt installer. That is *not* the reason why it’s currently not possible to deselect Qt Creator in the installer. The installer could write the configuration to <QtInstall>/Tools/qtcreator/share/qtcreator/QtProject/…. even if Qt Creator is not installed. The reason why this isn’t done, is because the tool that actually *writes* the configuration is currently part of the Qt Creator sources and binary package, because we wanted to avoid “freezing" the file format of the configuration file, and packaging it in a separate package was just not (yet?) done (that would be Kai’s suggestion (1) and (2)). If the configuration was written to a global configuration, we still would need to have the tool that does it separated from Qt Creator.

> Developer experience is still a very nice thing to have though.
> Perhaps we can make a little tool which lets us stash existing
> settings before installing a new build of Qt Creator?
> 
> 
>> From a user point of view, I'd happily have one current and great Qt Creator
>> installation which let's me easily switch between all the Qt versions I have
>> installed on my system. I don't see why this wouldn't be a good thing.
> 
> +1

That would also be achievable with an online installer that actually allows to install all these Qt versions.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin. Registergericht: Amtsgericht Charlottenburg, HRB 144331 B