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
_______________________________________________
Development mailing list
[email protected]
http://lists.qt-project.org/mailman/listinfo/development
