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

[Frederik Gladhorn]

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:
> >>> -----Original Message-----
> >>> From: development-bounces+kai.koehne=digia.com at qt-project.org
> >>> [...]
> >>> 1) Developers who face regressions (not just testers) are now in an
> >>> awkward
> >>> position, and need to install an extra copy of Qt Creator (see
> >>> below)
> >> 
> >> Right, that's the main drawback. We could maybe have a 'Show all' section
> >> in the settings dialog or so that would show/hide such patch level
> >> releases though ... will bring this up with the Release Team.
> >> 
> >>> 2) In Qt Creator, the Qt version and kit are still listed as "Qt 5.3.0",
> >>> even though it has been upgraded to Qt 5.3.1. Since it is an
> >>> auto-detected entry, the user cannot change the name.
> >> 
> >> Yeah, that's something we should fix in the next Qt Creator release.
> >> 
> >>>> Is it possible to use the offline installer to install 5.3.0 into the
> >>>> existing installation and not install a new Qt Creator?
> >>> 
> >>> 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.
 
> 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.
 
> 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.

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

Greetings,
Frederik

> 
> Br, Eike
> 
> >> I think both 1. and 2. are be feasible ... 3. might end up in more bug
> >> reports / annoyed users than the current 'forced' installation, so I'm
> >> personally not keen to implement this.
> >> 
> >> 
> >> Regards
> >> 
> >> Kai
> >> _______________________________________________
> >> Development mailing list
> >> Development at qt-project.org
> >> http://lists.qt-project.org/mailman/listinfo/development
> > 
> > _______________________________________________
> > Development mailing list
> > Development at qt-project.org
> > http://lists.qt-project.org/mailman/listinfo/development