On Jul 8, 2016, at 1:36 AM, Eike Ziller <[email protected]<mailto:[email protected]>> wrote:
On Jul 7, 2016, at 5:36 PM, Jake Petroules <[email protected]<mailto:[email protected]>> wrote: On Jul 6, 2016, at 11:10 PM, Eike Ziller <[email protected]<mailto:[email protected]>> wrote: On Jul 6, 2016, at 19:47, Jake Petroules <[email protected]<mailto:[email protected]>> wrote: I agree this is a -1. Is this something we're just doing for the beta and the final should be correctly shipped as a drag n drop dmg? On Jul 6, 2016, at 10:36 AM, Mike Jackson <[email protected]<mailto:[email protected]>> wrote: Out of curiosity why was there a switch from a "Drag-n-Drop" installation of QtCreator to an actual "installer" that I have to run? I would like to put a "-1" vote for the installer? Was there really a need for it? And where all is stuff being installed? I tend to use the nightlies which as a Drag-n-Drop install was easy to update on a daily basis and have multiple versions available at any one time. This is the result of consolidating how we build Qt Creator standalone and the diverse Qt packages. So far we had completely different setups for Qt Creator standalone and Qt packages, and it is far from optimal or even good. That was extremely optimal and good. Besides, they are separate and unrelated products, why on earth would their setup processes have anything to do with each other? Because one (Qt) includes the other (Qt Creator). And while it might be reasonable to keep packaging processes separate if these products are done by completely unrelated people, it doesn’t make sense at all if people and infrastructure are the same. It avoids duplication of efforts like license changes, changes in what exactly must be packaged, checking that the correct MSVC runtime is installed and install it if necessary, registering menus on Windows and Linux, registering as default application for file types, and even the decision which version of the installer framework is used. And it will make thinks like providing the CDB debugging extension for both 32bit and 64bit for both 32&64 bit packages easier, and enable us to get rid of the error-prone hack with the binary-artifacts repository (http://code.qt.io/cgit/qt-creator/binary-artifacts.git/tree/), without duplicating the effort of packaging cdbextension and jom as well. Yes, none of these is interesting for the opensource Qt Creator for macOS. Some of these _are_ interesting for the enterprise product even on macOS, which shipped with an installer already before. I have on my list to investigate if and how we can get the drag’n’drop dmg back on macOS. As long as that is *also* provided, there is no problem. Providing it as an option shouldn't affect your goals for the above. Considering that the Qt Creator application bundle is already built as part of the overall build process anyways and is itself completely self contained, the DMG packaging step is quite simple. Changes like this are not user friendly. People do not want an installer on macOS. They do not want bin and lib directories. They want drag n drop application bundles in a DMG. This is how virtually all applications are deployed on macOS. Whoever decided this: • Doesn't own a Mac • Is a KDE/Linux user/developer • Is a developer and not a product manager At least one of the three is true. Am I right? I think you can simplify that to “is not a product manager who owns a Mac”. It was done by the one who is responsible for releasing Qt Creator, who happens to work 95% on Macs. It's really frustrating to see constant accumulation of concepts and ideas that arise from 90% of our developers being long time KDE/Linux developers and having no interest in anything else. The other platforms of the world are not KDE. Things are done differently there. Please start acknowledging this. I don’t see any relation between KDE/Linux and GUI installers. Actually most Linux users would prefer having .deb/.rpm/<fill_your_preferred_package_format> packages. Yes, that's my point -- provide what the users of the target platform expect. deb/rpm packages would be nice, but of course that has other issues that DMGs do not (conflict w/ system packages). [snip from other mail] OTOH, there are a lot of Mac applications shipped with installer, though they are not the majority. When there's a necessity for it, like installing kernel extensions. Does Qt Creator require kexts or other system-wide state? No? Then it should not have an installer. I have seen many applications that have an installer on Mac, but do not install kernel extensions or anything else outside a single directory that is installed in some user defined directory. I do agree that it would be nicer for them, and for Qt Creator, to not come with an installer. In any case, for running the opensource content Qt Creator does not require an installer on any platform, and you can just go ahead and unpack the sevenzips located in the “installer_source” sub-directories for the platform, e.g. https://download.qt.io/development_releases/qtcreator/4.1/4.1.0-beta1/installer_source/mac_x64/ (on other than macOS, you should be aware that these do not contain any “qt-creator” subdirectory, and directly contain “bin/“, “lib/“, etc directories). Br, Eike -- Eike Ziller Principal Software Engineer The Qt Company GmbH Rudower Chaussee 13 D-12489 Berlin [email protected]<mailto:[email protected]> +123 45 6789012 http://qt.io<http://qt.io/> Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B -- Jake Petroules - [email protected]<mailto:[email protected]> Consulting Services Engineer - The Qt Company Qbs build tool evangelist - qbs.io<http://qbs.io>
_______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
