M. Fioretti wrote: > I should have been more specific. As I see it, macros today are used > (or misused) in OO.o in two fundamental ways: they either extend the > functionality of the *program* or that of the *document*. > > Most of the first kind are just unneeded in other (*nix) word > processors, as there are more integrated and efficient ways to do the > same thing, or it would be easier to just rewrite them in some other > way. This category includes dictionaries and spelling checkers (see > other thread here today), the oh-so-desired word count, find text in > multiple files, etc...
While I agree with this from the developers point of view (it's always more efficient to write program extensions in the language and environment that fits best to the program), I don't think that this helps a lot because *in practice* I don't see this differentiation between the two kinds of macros (see below). > The other kind of macros are those who add buttons inside documents > to check user input, etc... End users expect this kind of stuff to > travel with the document, and be there whatever you open it with. (snip) > So it is the second kind of macros whose portability should be > guaranteed across all OpenDocument compliant processors. "Unfortunately" these macros use the same API as the first ones, there is no real fundamental difference between them. Both kinds of macros can do and will do the same things, maybe with different probabilities. Nobody forbids you to count words or check spelling etc. on a button click! I'm sure you can define some kinds of actions that definitely aren't necessary for "the other kind of macros" and you also can define a lot of actions you really need for them, but the "grey area" between those different kinds is huge. It's tempting to believe that there are "two kind of macros" just because you can name clear and understandable examples for both kinds. But one should see that in practice you can't put all macros in either categorie what finally renders them useless. So a reliable port for the "document" macros means reimplementing more or less the whole API. From the investigations we did on the integration of VBA macros into OOo I'd say doing the same for OOo macros into other office programs is nothing I'd recommend. Your comparison with the browser case is IMHO not correct, because what you have described as "macros in documents" fits better to Javascript than to a Java Applet. Applets are more like embedded applications, and the "documents" of browsers (the web pages) usually are manipulated by JavaScripts. I don't want to stress that any further, but I don't see a clear boundary between "application" and "document" here also, especially in the case of the Mozilla based browsers where the whole GUI is based on Javascript. I think what you want is a portable, standardized function set for a well defined scope (like JavaScript, but referred to Office documents). Something like this isn't available anywhere, though it would be interesting. 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]
