Eike Ziller 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.
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.
[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
So... are we going to get the .dmg back for Mac OS X? running the
installer every morning is a pain and needlessly takes time away from
other things that I should be doing. Also, why is the default install
put into /Users/$USER/Applications? shouldn't we be putting that into
/Applications like EVERY other Mac OS application including Xcode?
Thoughts.
Mike Jackson
BlueQuartz Software.
_______________________________________________
Qt-creator mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/qt-creator
