On 7 July 2014 19:11, Frederik Gladhorn <[email protected]> wrote: > Mandag 7. juli 2014 10.02.55 skrev Ziller Eike: >> On Jul 7, 2014, at 11:17 AM, Frederik Gladhorn <[email protected]> > 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 _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
