> BTW, the division between apps and frameworks, libraries, etc in what > regards a need for an installer isn't so clearcut. Many apps need to > install files to different places, i.e. they are not self contained. > They are apps, just not appbundles
I think this is really where the confusion is. We have three GUI-based methods for geting an application onto our system: - Appbundle (drag and drop) - App (Installer-based) - Package (Installer-based) Appbundle is straightforward. Drag it, drop it, double click to launch. That's all the installation that's required, and it can be moved around in the file system at whim. Package is also straightforward. This would be used for CLI-based apps, I would assume. Here the app (or apps) are bundled as a pkg or whatever, double-clicked which launched Installer.app, then we track down where the files were put and we run them. Easy enough. The App is what Nicolas and myself are referring to. Here, you have an application that relies on some external library. Perhaps it's part of a suite, like Office or Adobe's Creative Suite, and there are a bunch of apps with similar functionality, and the developer wants to move that functionalty to a shared library. Here is where we see use of an Installer framework. The app is exactly like an appbundle, except it also has a package contained within it called, I don't know, libs.pkg for example. Now in order for OurApp.app to run, the contents of libs.pkg should be located outside the Applications folder, in an Application Support folder or in Libraries or somewhere similar. When you first double click on OurApp.app, it checks to see if libs.pkg's contents are in that folder. If not, it uses the Installer framework and starts up something that looks just like Installer.app, but just starts installing the contents of libs.pkg where they need to go. When it's done, OurApp.app starts up (because we double clicked on it), and could, theoretically, remove libs.pkg from its own bundle. Now, say we also have OurOtherApp.app, which uses the same libs.pkg. When we launch it, it sees that the contents of libs.pkg are in the file system, so it removes libs.pkg from it's own bundle, pulls in the shared libs, and off it goes. That way, an appbundle and an app behave exactly the same: drag and drop. One just happens to run an installer on first launch, the other doesn't doesn't. You get all the benefits of using a package installer, using shared libs, and the only place you have bulk and extra disk space, is in the initial, unlaunched app. Afterwards, the extra pkg is removed so you don't have wasted disk space. Is that any more clear? J. _______________________________________________ Discuss-gnustep mailing list Discuss-gnustep@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnustep
