Juha Manninen wrote: > > I am sorry to tell you but your project is doomed to failure with the > requirements you listed.
With that attitude, ALL developers would be out of business and we wouldn't have things like Linux, OpenOffice or any open source projects for that matter. :-) I gather your thought process is as follows: We only need ONE accounting packages. We only need ONE operating system. We only need ONE programming language. We only need ONE office suite. Yet with all these examples and millions more like it, we have thousands of similar applications. Our company develops software to fulfil our needs - that's our first priority because we are writing the software. As a courtesy to others we will in all likelihood release the software as a Open Source project. I simply thought that while writing the software, I might as well incorporate some "wish-list" ideas from other developers we haven't thought of. If you don't want to use the software, then don't - nobody is forcing you! > Your idea is not new. Other people have banged their heads to wall as well. > The variation of distros' package formats and directory structures is a bad > thing of course, but not as bad as it first looks... We are following some guidelines as proposed by Microsoft, Linux Standards Base, FreeDesktop.org etc. So we do use "desktop standards" and use known locations, file formats etc. This especially applies to Linux. To give you a Linux example: * we use xdg scripts when available * we use recommended *.desktop and *.directory files for menu items * we use accepted install locations: /opt, /usr/local/, ~/.local/ etc. > You wouldn't need to build thousands of packages though. The same RPM package > works for most RPM based distros (but not all), a DEP package works for > Debian > based distros. Package managers have sophisticated dependency checks, Does RPM support dependency checks? Last time I used RedHat (years ago) it did not. This is also why we say we support "Free Pascal based" applications more than others. Such applications (in our case, with fpGUI, this is true) have a much smaller dependency. We are definitely *not* trying to compete or replace RPM, DEB, TGZ, TXZ etc... We are targeting the new "desktop users" that know how to use a mouse and click things. > With only few packages you would have a long list of supported distros and > then not support some exotic ones. We don't want to spend three weeks building and packages releases. So we want one installation build process that works for all our supported platforms. > About Adobe Reader and Java installers: they can't count on any dependencies > but must include everything. Yup, we do the same. That's why we use fpGUI and why we use FPC. Both have cross platform support in mind and implement those directly in the resulting executables. Built-in archive support, built-in xml handling ability, built-in database support, built-in file handling, built-in Unicode support, built-in (custom written) help file support and the list goes on... Hence the reason it is easier to deploy our software than C/C++ (thinking *nix here) or .NET or Mono or Java applications. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
