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

[Sze Howe Koh]

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 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.


>> 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.

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


Regards,
Sze-Howe