[Development] New Qt 5.2 snapshot build #172

[Ziller Eike]

On Nov 27, 2013, at 12:06 PM, Adam Strzelecki <ono at java.pl> wrote:

> 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

So that would always contain the Qt sources, documentation and examples too?
I just want to mention here that there *is* the plan to get rid of the requirement to install Qt Creator from the installers. There are several possible ways to solve that and I think the discussion of what is the preferred way to do it is not over yet, but I think there is overall consensus that it should be done.

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

“double-click .qtsdk to register" only works if you have exactly one Qt Creator install on your machine. Of course there still would be “drag qtsdk thing into Qt Creator” etc, but I don’t really see the advantages.

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

I’d guess that the more common case would be that people double-click Qt Creator without double-clicking the .qtsdk (which they have no idea what it’s supposed to be).

> As for Xcode compatibility sake,

I’m convinced that the AppStore is the only reason why Xcode is having “everything in the bundle” nowadays. Not because it would make sense usability-wise. I don’t think the normal user of Xcode cares if the SDK was installed within the Xcode.app or not. It’s not that Xcode didn’t come as a installer for years, and it’s not that installers are completely alien on OS X. And actually Apple now needs to provide and maintain two “installers”: Xcode.app with its package management, and the separate CommandLineTools package, which is still available (for a reason).

> we can make in Qt Creator a button [Install Command Line Tools] which will:

The “Install Command Line Tools” thing in Xcode is one of the things that are really *bad* usability-wise now. Apple doesn’t care, because for Apple this is the “if you are not using Xcode we don’t care much” path, but I don’t think we want to follow that.

> (1) install symlink to qmake into /usr or /usr/local
> (2) install symlinks to all .frameworks into /Library/Frameworks

I’m actually glad that we got rid of system wide installs (that we did for Qt4), so I don’t think system wide installs would be a good direction to go. It’s also not very common to do that on OS X.

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

That would be highly unintuitive (after all it is supposed to be *installed*), and counter productive to the “I don’t want Qt Creator” case (you can’t “install the tools” and trash Qt Creator). Again, Apple doesn’t care with Xcode, I think we should.

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

I can’t follow that calculation.
We’d still need the online installer functionality *somewhere*. Which would functionality-wise be mostly what the current installer framework does, so we’d still need to maintain installer framework for Mac, or the exact same functionality in a Qt Creator plugin: Component management (what is available on the remote repository, what is installed, what should be installed + deinstalled), downloading and installing components (even if the last is just unpackaging some package somewhere), uninstalling components.

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

I’m all for self-contained, relocatable Qt (@rpath, plugins in bundles, etc), and afair the corresponding Qt Project maintainers too. It’s a bit independent from the question of how to distribute Qt packages for developers though.

Br, Eike

> 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
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B