Hi, On 2005-03-15 20:31:17 +0000 Quentin Mathé <[EMAIL PROTECTED]> wrote:
> Le 14 mars 05, à 17:56, Frederico Muñoz a écrit : > >> There was some feedback on -discuss when I posted my Installer message. >> There were many ideas, the most original of which was the ..pkg/.app hybrid >> (cehck the mailing list). >> >> I'm open to suggestions in how to extend and improve things, but I think >> it's important at this point for me to have a clear and above all doable >> goal before trying to extend it to far. This means that I would really like >> to finish "basic" .pkg support, meaning the ability to create packages, to >> install them, and, since it it's easy after the previous goals are reached, >> to convert them between OSX and GNUstep. This will at least provide >> something usable, and from there adding features will be easier. > > I think it's better to have a first Installer.app version not so much > different than the current one (I'm not talking about UI here). And then we > will probably refactor it in a framework and reduce Installer.app to a > "wrapper" launched by the system or the user when needed. > Any comments ? Yes, that sounds good to me. The code, even if messy, already maintains a total degree of separation between the UI and the installer class (MVC and all that, took some time to get used to, but I think that I got it more or less). The Installer app will be in the end simply the UI that makes use of the installer object. According to needs the installer class can be extended with methods to aid unatended installation (e.g. installPackageAtPath:ToPath: ) and other installation methods as those described in previous mails. My concern, and I'm sure you understood it, is that while targeting advanced features and experimental solutions the code stays always 10% far from being finished. I prefer knowing that it works for a well-defined and already used paradigm that is immediatly usable and from there, with the added confidence given by something that works, adjust the code structure to allow alternative methods, especialy since it wil be easier to create new methods for them if the existing ones are known to work. Best regards, fsmunoz
