08.07.2016, 12:48, "Jake Petroules" <[email protected]>: >> On Jul 8, 2016, at 1:36 AM, Eike Ziller <[email protected]> wrote: >> >>> On Jul 7, 2016, at 5:36 PM, Jake Petroules <[email protected]> wrote: >>> >>>> On Jul 6, 2016, at 11:10 PM, Eike Ziller <[email protected]> wrote: >>>> >>>>> On Jul 6, 2016, at 19:47, Jake Petroules <[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]> 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).
It's possible to have deb/rpm packages that install the same bundle of official binaries to /opt and don't conflict with 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] >> +123 45 6789012 >> 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] > Consulting Services Engineer - The Qt Company > Qbs build tool evangelist - qbs.io > , > > _______________________________________________ > Qt-creator mailing list > [email protected] > http://lists.qt-project.org/mailman/listinfo/qt-creator -- Regards, Konstantin _______________________________________________ Qt-creator mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/qt-creator
