[Development] New Qt 5.2 snapshot build #172

Tue Nov 26 20:46:06 CET 2013

On Nov 26, 2013, at 1:19 PM, Thiago Macieira <thiago.macieira at intel.com> 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Jake Petroules
Chief Technology Officer
Petroules Corporation · www.petroules.com
Email: jake.petroules at petroules.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20131126/9903ff04/attachment.html>