Marco Fioretti wrote: > A macro is a small program written in some _language_. It is NOT > the code _and_ its interpreter. The latter, yes, is definitely not > portable.
But a large part of the language is also not portable, the "API" based part. Of course you can write macros without using this, but then these macros can't do anything on the document, only "external" work like copying/deleting/moving file, starting tools etc. > This is what I'm thinking about: > > 1) Python interface for opendocument, ie set of function definitions > that read/write odt files and their elements That sounds easier than it is. The best way to achieve that would be using XML based APIs of the document (like the SAX API) because they make use of the standardized format. Unfortunately they are much too complicated for the average end user. So another API needs to be provided, but this means: it has to be standardized and implemented. And there is still no guarantee that macros created in OOo will use only this "standardized" API because we still will have our current API (because we guarantee that macros written today also will run in the future), so users can (and will) use it. > Before I forget: if this does make sense, why not add it to the > list of "google summer of code" OO.o projects? Just in case > somebody felt like doing it? That wouldn't fit. The Google projects last for 3 months, a new API more fits to 3 years. ;-) Best regards, Mathias -- Mathias Bauer - OpenOffice.org Application Framework Project Lead Please reply to the list only, [EMAIL PROTECTED] is a spam sink. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
