> So that would always contain the Qt sources, documentation and examples too?
Yes, Kai wrote he sees no point to be able to not install docs & examples together with SDK as suggested in QTBUG-34870. So once Qt Creator isn’t there, bundled frameworks use @rpath, is there any point to have an installer that just copies files if Finder serves this purpose just fine? > 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. Great to hear! > “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. Correct me if I am wrong but there’s single ~/.config/…/QtCreator file, so even we have several QtCreators all of them gonna see some SDK registered by the other. Of course triggering registration and copy Qt5.x.y-spec.qtsdk with Qt Creator requires Qt Creator to be there. It may be explicitly written on .dmg background image. We can even put link to Qt Creator download too for convenience. I have ready bash scripts that do all the layout and dmg build. Still Qt5.x.y-spec.qtsdk would be just a normal folder containing whole SDK for given target. So you can always drag & copy it anywhere you want and use it from command line if you don’t like Qt Creator. What’s more since dmg is mounted RO HFS filesystem, so you can even try the toolchain without copying it anywhere, which isn’t possible right now. > 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). If Qt Creator is installed you will not see .qtsdk extension and instead of folder icon you will see some custom icon that will intuitively make you click on it. If it is not installed it will look as regular folder and Finder will let you step into it when you double click it. This is how it works for many other apps and it works well. > 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. Aside „everything is in the bundle” and simple install & updates, it is also easier to manage multiple SDK or Xcode Betas, being just separate .app, you drag around trash or overwrite. It is far more simple that previous .pkg based installer that requires launching command line uninstall-devtools to get rid of stuff. Also now switching between command line toolchain versions is as simple as selecting it from combo in Xcode Prefs or launching some fancy extra manager apps, but there is also xcode-select. > 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. I don’t claim that installers are alien, but just custom installers. Also .pkgs serve special purpose, they modify your system, i.e. installing drivers, quick time components, etc. etc. Also before Xcode 4, Interface Builder and many other tools were separate from Xcode itself. > 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. In fact in 10.9 there’s no more Install Command Line Tools, since there’re shims that pick up installed Xcode toolchain, or when there’s none pops a dialog to install one. Again it is just convenience, not necessity. It provides UNIX compatible command line toolchain that works, compiles X11, autotools, OpenGL/GLUT stuff just fine. That’s why a having QtCreator Install Command Line tools would be similar, it would just make something that you may do manually anyway. Many other apps such as TextMate, Keleidoscope do that, and users like it. > 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. Well, I do agree that forcing system-wide install may be a bad idea and I am against to mess around with /Library, which needs elevated privileges. That’s why Qt5.x.y-spec.qtsdk should be just a folder, and all registering and auto-copying stuff should be convenience not necessity. You can always put Qt5.x.y-spec.qtsdk/bin in your PATH, symlink to /usr/local/bin or do whatever you want, and copying stuff into Qt Creator.app/Contents/SDKs would be just another convenience not necessity to let user remove SDK directly from Qt Creator or remove everything putting Qt Creator into trash. > 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. > I can’t follow that calculation. If I read it correct, it was about creating and maintaining SDK install packages per platform. What I am saying it would be less burden because instead building+packaging_installer+packaging_dmg it would be replaced with building+packaging_dmg. > We’d still need the online installer functionality *somewhere*. That’s why I think Qt Creator is best place for that. If someone want to use command line, it won’t use anyway some extra GUI manager. More apps, more clutter. I opt for really simple solution that leads you do .dmg for given platform, as simple as a lists with Download button that opens a URL to .dmg. I don’t think we even need to use any Qt installer functionality, unless it has some download dmg, mount and copy functionality out of the box. But I really think packaging stuff twice, 1st time into dmg, 2nd time into installer.dat is bad idea. > 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. Great. If you need any support, testing anything let me know. Regards, -- Adam _______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
