sean.upton@uniontrib.com wrote: ...
I'm not sure if I understand what you mean by an application as a toolkit?
I don't say why you say this: Below, you prove that you do understand me.
That doesn't make sense to me: function libraries are toolkits; class libraries are toolkits. Running all this within an app sounds like the functional equivalent of running GW basic code under DOS on a 8086: you are forced to run apps inside an interpreter, there is no runtime, and this is not transparent to the user. Why force this kind of complication? To produce an IDE that won't create standalone applications, let alone ones that use simple, freely available toolkits?
FYI, Inprise EULAs forbid creating competing products; for example, during the days when Borland marketed Paradox, they explitly forbit Delphi developers from using the BDE to create general-purpose database app workalikes to Borland products.
This is what I meant: If it is forbidden to do this, than you can trash my proposal.
Anyway, this is making the problem more complex than it needs to be; the only value Kylix has is as a RAD tool; it has no value for creating toolkits for development without the closed RAD tool, so what's the point?
The point is that creating the RAD tool would be not so hard. But if it isn't allowed, there is no point. Well, but what is a competing product? Is a free tool a competition to a product which has to be bought? And I'm not going to write a competitor for Kylix, just a general GUI framework. The programming language is pure Python. Hee, hee. ciao - chris -- Christian Tismer :^) <mailto:tismer@tismer.com> Mission Impossible 5oftware : Have a break! Take a ride on Python's Kaunstr. 26 : *Starship* http://starship.python.net/ 14163 Berlin : PGP key -> http://wwwkeys.pgp.net/ PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF where do you want to jump today? http://www.stackless.com/