On Nov 26, 2013, at 1:19 PM, Thiago Macieira <[email protected]> wrote:
> On terça-feira, 26 de novembro de 2013 11:56:20, Jake Petroules wrote:
>> I agree with everything you say and as an OS X user I feel your pain. Qt SDK
>> absolutely should be a drag and drop installer just like Xcode.
>> Unfortunately there are some major blockers in the way before we could
>> begin to think about doing that - see
>> https://bugreports.qt-project.org/browse/QTBUG-14150 (and
>> https://bugreports.qt-project.org/browse/QTBUG-31814 as you said).
>
> One big advantage is that we maintain one single codebase for all platforms.
> Doing it the Mac way requires us to start doing Qt SDKs installations per
> platform.
Single codebase but a degraded user experience that makes Qt less appealing out
of the box than, say, Xcode. If anything I would guess "the Mac way" would even
be simpler than the other platforms.
There's a good reason VLC, for example, uses a native Cocoa UI on OS X and Qt
only for "the rest". Overall, Qt for OS X just isn't that great in a lot of
areas, specifically UI and system integration. Unfortunately these areas happen
to be the most noticeable ones, and taking only OS X into account, leads to the
native development tools being the best ones for the job in the majority of
cases... and even sometimes for cross-platform apps like VLC.
On Windows, Qt is quite often better than the native tools (Win32, MFC) - it
would be nice to see that eventually become the case for OS X as well.
>> I would argue there is value in an installer since there are multiple
>> versions of the SDK available. But then again... an online installer is an
>> easy way around this - put package management into Qt Creator preferences
>> and store SDKs in /Applications/Qt
>> Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ But what exactly do
>> you include in the offline installer? OS X, iOS and two or three Android
>> versions (and eventually BlackBerry?)? That would be massive. One solution
>> is that SDKs bundles in a DMG could be provided as separate downloads (and
>> the builtin package manager in QtC could automate downloading and
>> installing them). The .qtsdk extension could be registered with Creator -
>> double clicking it registers it with the Qt Creator version it's opened
>> with, and QtC pops up a dialog even offering to move the SDK folder within
>> its app bundle.
>
> I'd expect you to download one .dmg that contains Creator and the online
> installer / update tool. Then you *need* to run the update tool to download
> any Qt version. Before you do that, Qt Creator is useful for writing C++
> code,
> but there will be no Qt versions to link against.
>
> Also, the online update tool should be separate from Creator: don't install
> the toolchains inside the Qt Creator bundle. That way, if someone wants to
> use
> XCode and not Creator, they can simply remove the bundle by dragging to the
> Trash.
Yes, that makes sense. Qt Creator could install the SDK manager tool to
/Library/Qt/Qt SDK Manager.app - or /Applications to make it more accessible if
the user opts to trash Creator. (it would also have a nice icon - the Qt icon
with a opened box overlaid on the corner? :) ) The SDK manager app could
install Qt SDKs to /Library/Qt/SDKs, so for example the base path of a Qt 5 SDK
for OS X would be /Library/Qt/SDKs/Qt5.2.0-macx-clang.qtsdk. Or ~/Library/Qt if
we don't want to bother with elevated permissions. As I said before, *.qtsdk
could be registered as a bundle, so it could contain an Info.plist at the root
which would describe the properties of the SDK as necessary (mkspec, version
number, display name). The layout might look something like:
- Qt5.2.0-macx-clang.qtsdk/
-- Applications/
--- Assistant.app, Designer.app, Linguist.app, QMLViewer.app, pixeltool.app
(what is the point of this thing?)
-- bin/ (non-bundle binaries only!)
--- qmake, moc, rcc, uic, etc...
-- imports/
-- include/ (this could be omitted for framework builds, there's no point
duplicating the header locations... if we need this for backwards compat, at
least symlink them to the framework bundles, it wastes space otherwise)
-- lib/ (non-framework libraries only!)
-- libexec/
-- Library/Frameworks/
--- QtGui.framework/PlugIns
---- libqgif.dylib, libqico.dylib, ... (perhaps bundles)
-- mkspecs/
-- phrasebooks/
-- plugins/{category}/ (non-framework builds only)
-- qml
-- translations
The SDK manager tool could also add symlinks such as Qt5.2.qtsdk, Qt5.qtsdk,
pointing to the latest versions for convenience.
Adding plugins into the respective frameworks would simplify deployment
significantly. macdeployqt's task would be reduced to inspecting the frameworks
the app links against, and copying the framework folders into the bundle. Don't
need to think about plugins, don't need to mess with install names. It just
works.™
A rather fascinating aspect of having a fixed install path such as /Library/Qt
is that macdeployqt could have an option to copy Qt to the lesser known Shared
Frameworks subfolder in application bundles. Qt SDK Manager.app could keep
/Library/Qt*.framework symlinked to the newest version of the Qt frameworks
installed (i.e. /Library/QtCore.framework =>
/Library/Qt/SDKs/Qt5.2.0-macx-clang.qtsdk/Library/Frameworks/QtCore.framework).
Then, if the version of Qt installed on the system is newer than the version of
Qt in the application bundle's Shared Frameworks folder, it will use the system
version. Otherwise, it uses its own copy. Again, an optional but interesting
feature that would *really* allow us to take advantage of our strong commitment
to binary compatibility.
Having multiple copies of the apps in $SDK/Applications is kind of annoying.
Launch Services also doesn't really like having multiple copies of the same app
lying around. Perhaps Qt SDK Manager.app could simply install the latest
versions in /Applications, and the user would have the non-default option of
installing SDK-specific versions in the respective SDKs.
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
> _______________________________________________
> Development mailing list
> [email protected]
> http://lists.qt-project.org/mailman/listinfo/development
--
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: [email protected]_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
