[Development] New Qt 5.2 snapshot build #172

Adam Strzelecki ono at java.pl
Wed Nov 27 12:06:35 CET 2013


Jake Petroules wrote:
> But what exactly do you include in the offline installer?

Thanks for detailed insight. I think I am all way with /Applications/Qt Creator.app/Contents/SDKs/{mkspec}-{version}.qtsdk/ because of simple reason that on OSX you don’t need elevated permissions to put anything into /Applications (comparing to /Library).

1st of all I wouldn’t call it installer, but it would be DMG bundle with nice background & layout:

1. Drag to Application to install
  [Qt Creator.app] ==> [/Applications]

2. Then double click to install SDK:
  {mkspec}-{version}.qtsdk

Where online bundle would have just (1) Qt Creator bare app + Qt Creator Mac plugin that downloads offline .dmg-s for iOS, Android or whatever, mounts dmg and copies .qtsdk.

We can easily have helper (i.e. written in Apple Script) embedded in Qt Creator.app that is bound to .qtsdk extension, that simply launches Finder copy into /Applications/Qt Creator.app/Contents/SDKs or wherever it is placed, then ejects the .dmg.

What’s more cool, we can figure out the case user have not dragged yet .app into /Application but clicks on the .qtsdk and show „please drag Qt Creator into your Applications first”.

As for Xcode compatibility sake, we can make in Qt Creator a button [Install Command Line Tools] which will:
(1) install symlink to qmake into /usr or /usr/local
(2) install symlinks to all .frameworks into /Library/Frameworks

Again we can make it as Qt Creator plugin, rather putting it into base code.

Since these are symlinks, even if we trash Qt Creator.app (and all SDKs within) these will be dangling, but not occupying any space on the disk.

Finally regarding maintenance burden: actually there would be less, because we will get the .qtsdk helper and Qt Creator plugin just once. Then making OSX Qt bundles will be less work, since it would be what it done right now minus creating Qt installer framework based installer app.

> 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.™

Yeah.

Thiago Macieira wrote:
> So, as much as this would look desirable, it will not leave the paper unless 
> someone volunteers to start experimenting with it. Let's see some volunteers 
> trying it during the 5.2.x timeframe. If it works fine, we can release it 
> officially for 5.3.0.

I am hereby submitting my candidature. I am registered Mac&iOS developer. I am personally interested to improve Qt experience on Mac, since I am using it for several projects. I may either submit patches or fork Git master.

Of course if Qt maintainers are open for dropping idea of Qt installer framework based installer for OSX platform if they are convinced that these ideas work better for Mac users.

I may then also fix other issues, such as @rpath support and OSX Retina issues in Qt Creator.

WDYT?

Cheers,
-- 
Adam


More information about the Development mailing list