[Qt-interest] [OT] Politically Correct way to release an Open Source Qt Project

[Oliver.Knoll at comit.ch]

Martin Hofius wrote on Monday, August 02, 2010 1:20 PM:

>> ...
>> Should not be that difficult should it? Two clicks to download and
>> run, one drag to get rid of it.
> what does a MAC user if a program doesn't start anymore 
> ...

Okay okay, since I started this "Mac vs Windows vs Installer vs Whatever" I will end it hereby ;).

But my point was really that

a) Yes, each application coming with its own "homegrown installer", that is certainly a bad concept

b) But it is a fact that most applications leave "trails" behind them (config files, cached data, ...), and IMO they must be deleted when "uninstalling" the application

Think of Google Earth which might leave HUNDREDS of MB of cached data (oh and yes, here we go: http://www.macosxhints.com/article.php?story=20090424045847496 "Remove the updater application and files installed by Google Earth" ;) Do you really want to force the user to remember to first execute "Clean cache" from within the application before deleting the application binary from the "Applications" folder? Not to mention that this alone would only remove his/her OWN cached data, not the one from OTHER users (if you REALLY want to get rid of the application "system-wide")? Not very user-friendly ;)

I am not a Mac expert, but I don't think the caches under ~/Library/Caches/... are deleted on a regular basis by the OS, are they?


So in my opinion having an API on some OS level which would allow to "register data" which then becomes "unregistered" (read: deleted) when the application is "uninstalled" (via a common "Installed Software" dialog, like the one on Windows) and at the same time would provide a way to "update" existing applications (like the package management tools on Linux), that would be a good thing IMHO.

So basically an application would simply come with a "recipe of installation" (for example a simple text config file with "I want to have a config file in (possibly) all $HOME directories, I want the executables to be in /usr/bin, my cached files are here, my user documenation there, my update server is http://update.fooapp.com, the component FooBar is optional for installation, I depend on the following components: ..." etc.) and the "OS Installer" would then provide a common and well-known GUI which would allow the typical task of installing and updating the application - and completely removing it later on.

I think the "MSI based installation mechanism" on Windows fulfills some of these requirements, RPM/*.deb based package managers do the dependency and update job very well, as well as de-installation (uninstallation - what a word...).

But a "installer-framework" is still somewhat an utopy.

Then there is the task of "converting existing data", but I agree with Kustaa that this is *not* a job for an "Installer": that requires "application logic" (or "business logic") and should be part of the application itself, e.g. when it is first run it should detect "Hey, the data in the DB is old, I need to convert it first" and do the necessary steps, e.g. by automatically launching a "converter application" (or giving the user an option to do so).

And off course the installation could still be as simple as "dragging a binary into the app folder" if the "installation recipe" would not provide any options or would request "Simple Installation mode" or whatever, so the user would simply be presented with a big fat "Install Now" button :)

And if ALL THAT would be platform-independent (at least a common API for the "Installation recipe" config file...)... :)

Cheers, Oliver
-- 
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22