Re: [discuss] OO.o Macros with Python interpreter?
Mathias Bauer wrote: You can write a Python macro that doesn't use the OOo API, you can even write OOo Basic macros that don't use the API, only the Basic Runtime functions. Of course these macros don't do anything with the document. Okay, the point of a macro is to do something with some document or with the application. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote:
> Eh eh... This is the same simplification as OpenDocument = OO.o.
> It would be more exact to say that the *interpreter* of a macro
> must be written for the application that calls it (OO.o or whatever)
> and today the only macros found in pre-OpenDocument files (.sxw, .sxc)
> are written in a language that was designed only for *StarOffice*,
> not for its file *format*. See my other reply.
No, an interpreter will never be created for a format or even a
particular API, theoretically it can work with any API you provide to it.
I'm not sure if you understand the nature of a programming language for
an application. The interpreter is only a very small part of it, you
also need an inspection component and a language agnostic component
technology that mediates between objects. Additionally you need an API
that the inspection component can "read", but this API basically is
exchangeable.
In OOo the basic interpreter takes a given object that is based on the
UNO component technology, uses the so called "introspection" service to
find the methods and properties it has and dynamically "learns" them. In
the same way VBA takes objects based on the COM component technology and
inspects them.
All the found methods and properties can be used as object members in
your macro and make them look as if they are part of the language. This
way the macro "language" evolves automatically by adding new objects to
your application or extending the function or property set of existing
ones *without writing any line of code in your interpreter*.
As an example, you have only one VBA interpreter, but it is able to
execute macros for Calc as well as for Word, but you can also
instantiate other COM objects (even OOo on Windows!) and directly use
their COM based API in your VBA macro. The OOo Basic interpreter offers
the same flexibility with all UNO based objects. As an example, adding
the "Base" component in OOo2.0 gave you many grub for writing macros,
but not a single line in OOo Basic had to be changed for this.
In an extrem manifestation of this flexibility you can replace the
current OOo API by something completely different and you can work with
this new API without any change in your interpreter as long as you don't
replace the introspection component and its API and you use the same
component technology ("Middleware").
Of course an extreme API exchange like this is neither likely (because
it's too much work) nor possible (because it's forbidden by our
self-constraints concerning API compatibility), but as a thought
experiment it can show you how things work.
So creating a "compatible" interpreter for lets say KOffice will be only
the very first step to macro interoperability. By using Python (as you
correctly stated) you could even save this first step if you provided a
binding from Python to your component technology (like OOo has in
PyUNO). And this component technology is the key to everything.
If you want to be future-proof and keep it open for additional macro
languages in the future, your component technology should be language
agnostic by supporting the "language binding" concept (as COM and UNO
do), but at least it must be usable from your API implementation
language (like C++ in KOffice or OOo) and your scripting language.
A quick look to KDE.org it looks as KOffice has something like that, but
somebody in the know should confirm. Of course this is only for KDE,
Gnome has another component technology. I'm not an expert for this.
If this was all in place, *then* you could start defining and
standardizing an API and then implement it using the component
technology. This implementation can "wrap" the current objects of the
applications or in future times even replace them or at least make up
the new parts.
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]
Re: [discuss] OO.o Macros with Python interpreter?
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]
Re: [discuss] OO.o Macros with Python interpreter?
Daniel Carrera wrote: > I very much doubt that this is possible. A macro always uses the OOo > API, and this API has no connection with OpenDocument. You can write a Python macro that doesn't use the OOo API, you can even write OOo Basic macros that don't use the API, only the Basic Runtime functions. Of course these macros don't do anything with the document. 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]
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: > Back to my training class example: a portable macro embedded into > an .odt file is what you could use to distribute tutorials or any > other interactive educational material where there is scarce bandwidth > and/or PCs not powerful enough to run OO.o. Ditto for CDs attached > to magazines or books. Yes, that's an interesting approach. Unfortunately the Open Document standard doesn't say anything about macros (or any other "external" content). So what you could achieve now (at best) is an OOo extension of the OD standard, but because we don't want to be Microsoftish, we should call this an OOo feature, not an Open Document feature. To realize your idea (what definitely is possible) *and* make it future-proof we miss the standardization. But OK, this is only a general remark because you emphasized the Open Document relation by yourself. Let's put this aside for the moment. [Personal estimation: In general our way to store macros inside packages is very open and easily portable so that it might have a good chance to enter the OD standard with only minor changes once people want to extend the standard for document macros. At least the conversion effort for you OOo documents should be limited.] Embedding arbitrary content into the packaged OO.o(!) file format is possible, using it needs a component that is able to handle this content. Our Scripting Framework uses this feature of the package file format to allow for embedding macros written in Java, BeanShell or JavaScript by storing "script parcels" inside the package and providing runtime components for them. There is also an integratation of Python/PyUNO into the Scripting Framework. Quoting Jörg Budischewski from dev@udk.openoffice.org: > Subject: [udk-dev] FYI: Integration of python-scripts in Tools/Macro dialog > available since OOo 1.9.m79 > Date: Sat, 19 Feb 2005 21:56:57 +0100 > From: Joerg Budischewski <[EMAIL PROTECTED]> > > Hi, > > since the above mentioned version, pyuno supports the office scripting > framework in the upcoming OOo-2.0 release. > > The support is limited to the 'core' framework, meaning that execution > and assigning of macros works fine, but editing and debugging macros is > not integrated in OpenOffice.org's UI (simply because of the lack of > development resources). Thus, this feature is targeted at more advanced > script developers. Details about the integration can be found at > > http://udk.openoffice.org/python/scriptingframework/index.html > > In case you don't know pyuno, have a look at > > http://udk.openoffice.org/python/python-bridge.html > > Bye, > > Joerg Budischewski I can't say how good this integration works, but I have a lot of confidence in Jörg. :-) Lets's take that for granted, so all you have to do is placing your macro into the right place inside the package where the Scripting Component can find it. I think the links in the quote should show you the ropes. Now you can run your Python macros from the "Run macro" dialog or bind them to document events or buttons, put them into toolbars etc. like you can do with Basic Macros. Your Python macro can be "plain Python" code only and/or it can use the PyUNO bridge to access the OOo API (but I assume the latter is not what you want because it is not "portable" to other OD based applications as long as they don't support the particular API). Of course ATM there is no other application that can work with your macros, even if you don't make use of our API in them. Wether this solution fits to your needs is something you can only judge by sourself. 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]
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: As for macros, the issue is more tricky because a macro is a program >>that tells the application to do something. Well, not exactly, if I have understood it correctly. A macro is a small program written in some _language_. Uhhhm... what does that have to do with anything? Any program is written in a language. It is NOT the code _and_ its interpreter. The latter, yes, is definitely not portable. A macro is a set of instructions to do something. Those use the application's API. The application is the interpreter. 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 What you are thinking is a new API. OpenDocument is not an API. Look, a macro is not like a stand-alone program. It needs to interact with another program (the application) and must do so through the application's interfaces (API). It is conceivable that one could make a standard API for macros, but OpenDocument is not it. 3) Then, you and I write a macro in "Python calling the library defined in 1) above" on whatever platform and once... An example of why this is difficult: Now you'd be requiring every implementation of OpenDocument to include both a copy of Python and a compliant copy of said library. That's quite a bit to ask. 5) we can then send the .odt file to anybody with: any .odt program (OO.o, KOffice...) + Python + his own specific implementation of 1) above... I'm pretty sure that OpenDocument does not include an API for macros, much less one that includes Python bindings. I couldn't imagine that such a thing would be required for OpenDocument compliance. I have written Python above because it is already useable *today*, or so I understand, both in OO.o *and* KOffice, Not through the same APIs and not as part of the OpenDocument standard. Look, what you want is great, but OpenDocument isn't it. Any feedback on the flow above, from suggestions on how to implement it to (polite, please! ) strong criticism is welcome. Defining a common API between OOo and KOffice would be a challenge. Getting OASIS to adopt it as part of the file format would be a greater one. What you want is fantastic, but very very difficult. 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? I doubt this could be done in a summer. I doubt that even the spec for this new API could be agreed on in a summer. But I'm no expert. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Daniel Carrera wrote: > Come to think of it, I don't know how OpenDocument deals with > macros. OpenDocument itself shouldn't deal with macros, but this is something that _should_ be standardized, or at least well known. This is the hole I'm trying to fill. > I very much doubt that this is possible. A macro always uses > the OOo API, and this API has no connection with OpenDocument. Eh eh... This is the same simplification as OpenDocument = OO.o. It would be more exact to say that the *interpreter* of a macro must be written for the application that calls it (OO.o or whatever) and today the only macros found in pre-OpenDocument files (.sxw, .sxc) are written in a language that was designed only for *StarOffice*, not for its file *format*. See my other reply. Ciao, Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Daniel Carrera wrote: > Marco Fioretti wrote: > > >[snip: OpenDocument and freedom] This loses > >a *lot* of relevance if there is no defined path to standardize > >macros and spreadsheet formulas, and the will to follow > it. > > Well, there is a defined path for spreadsheet formulas. As for > macros, > the issue is more tricky because a macro is a program that tells > the application to do something. Well, not exactly, if I have understood it correctly. 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. 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 2) different *implementations* of those functions for KOffice, OO.o, anything else. Just like there is *one* Python language, but different binary interpreters for it on Linux, Windows etc... 3) Then, you and I write a macro in "Python calling the library defined in 1) above" on whatever platform and once... 4) that Python _code_ is zipped with everything else in the .odt file, just like StarBasic code in .sxw files today... 5) we can then send the .odt file to anybody with: any .odt program (OO.o, KOffice...) + Python + his own specific implementation of 1) above... 6) and he will be able to run the macro, happily ignoring with which combination of .odt-program and operating system it was created. I have written Python above because it is already useable *today*, or so I understand, both in OO.o *and* KOffice, or in any case much more common in computing than StarBasic, so I'm seriously starting to think that it is a much better choice to solve this problem. Any feedback on the flow above, from suggestions on how to implement it to (polite, please! ) strong criticism is welcome. 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? Ciao, Marco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: [snip: OpenDocument and freedom] This loses a *lot* of relevance if there is no defined path to standardize macros and spreadsheet formulas, and the will to follow it. Well, there is a defined path for spreadsheet formulas. As for macros, the issue is more tricky because a macro is a program that tells the application to do something. I don't see how you can make that application independent. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Alexandro Colorado wrote: Ok this is a learning opportunity, I thought odt is exactly the same as sxw just a with a different syntaxis. Not quite, but close ;-) OpenDocument can do a few things that sxw can't do; it's more general and powerful. But they are very close. If I have a macro with a window form and I save that document. Does that mean that the code will be in the file or would it be on my computer? Does that means that they are no-longer portable to another OOo? The macro would be in the file, and would definitely be portable to another OOo2.x. But I'm pretty sure it won't be readily portable to KOffice. I don't think that macros are part of the OpenDocument specification. I guess it's similar to how OpenDocument allows you to embed an OLE object, but the recipient might not necessarily know what to do with it. Could you do me a favour? Prepare a .odt file with a macro in it (e.g. "hello world") and send it to me. I'd be interested in seeing what it looks like inside. I can't do this myself, I haven't been able to install OOo1.9 on Ubuntu. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Marco Fioretti wrote: But this addon would not be embedded in an .odt paragraph (at least, not in the current and near-future OOo releases). Why not, if I may ask? Uhhm... because no such functionality is implemented yet. May I ask... is there a reason why a .odt file is needed but an addon won't work for you? (provided that the add-on works whenever OOo is installed). Fair question, but you partly answered it yourself. I did? wow! ;-) OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... Ah. I am not aware of Python macros being part of the OpenDocument spec. Come to think of it, I don't know how OpenDocument deals with macros. Back to my training class example: a portable macro embedded into an .odt file is what you could use to distribute tutorials or any other interactive educational material where there is scarce bandwidth and/or PCs not powerful enough to run OO.o. Ditto for CDs attached to magazines or books. I very much doubt that this is possible. A macro always uses the OOo API, and this API has no connection with OpenDocument. Teacher writes on OO.o, students learn on KOffice. Or vice-versa. That's why I said "embedded into the .odt file". Of course, if (in the conditions above) there is any other solution which has the same end result for the student/user is OK, but is there? I don't think there is. But ask Gary, he's the OpenDocument guru. Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Laurent Godard wrote. > IMHO, macros (developepd in StarBasic, python, beanshell, > whateverlanguage) do not deal with openDocument at all > It only deals with the layer the software (OOo) that render an > OpenDocument gives the script through its API. It is implementation > specific > > OpenDocment is /only/ the description of the xml files (eg > content.xml), and not a specification of the api of the > implementation The only answer I have to this is the same I gave to the KOffice developers when they made the very same remark a few days ago: 1) technically, you are 100% right, and I even agree, but 2) after years of advertising what is now OpenDocument as THE one, application-independent, truly open, durable solution etc... that frees your data from lock-in to any single SW provider (including "free as in freedom" ones)... ...end users are going to be mightily pissed when they start exchanging .odt files from/to OO.o and KOffice or whatever else and they don't always work in the same way. See the example I made of training material, possibly distributed via CD-Rom. Oh, and remember that "end users" include all those governments which, with great effort, are being carried to the notion of "perpetually available data, regardless of the application: this is what OpenDocument gives you". This loses a *lot* of relevance if there is no defined path to standardize macros and spreadsheet formulas, and the will to follow it. 3) Therefore, the way I see it, OO.o, KOffice and whoever else will go OpenDocument publicly (which *is* a wonderful thing) have *already* committed to standardize those things too. They just haven't realized it yet, but the sooner the better. For PR, at least. Ciao, Marco F. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Hi, Ok this is a learning opportunity, I thought odt is exactly the same as sxw just a with a different syntaxis. If I have a macro with a window form and I save that document. Does that mean that the code will be in the file or would it be on my computer? Does that means that they are no-longer portable to another OOo? if written as a starbasic macro, it will remain in the file Nevertheless, OpenDocument Oasis standard do not deal with macros so IMHO .odt files handles more information (embedded images, macros ...) than the OpenDocument standard states. OpenDocument for me is /only/ the xml description of an office document but i may be false ... Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Quoting Laurent Godard <[EMAIL PROTECTED]>: Hi Marco, Fair question, but you partly answered it yourself. OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... IMHO, macros (developepd in StarBasic, python, beanshell, whateverlanguage) do not deal with openDocument at all It only deals with the layer the software (OOo) that render an OpenDocument gives the script through its API. It is implementation specific OpenDocment is /only/ the description of the xml files (eg content.xml), and not a specification of the api of the implementation Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 Ok this is a learning opportunity, I thought odt is exactly the same as sxw just a with a different syntaxis. If I have a macro with a window form and I save that document. Does that mean that the code will be in the file or would it be on my computer? Does that means that they are no-longer portable to another OOo? -- Alexandro Colorado Co-Leader of OpenOffice.org Spanish http://es.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Quoting Marco Fioretti <[EMAIL PROTECTED]>: D. Carrera wrote: But this addon would not be embedded in an .odt paragraph (at least, not in the current and near-future OOo releases). Why not, if I may ask? May I ask... is there a reason why a .odt file is needed but an addon won't work for you? (provided that the add-on works whenever OOo is installed). Fair question, but you partly answered it yourself. OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... Before answering "gee, that's so far in the future, why bother?", keep in mind that OpenDocument is being advertised as *the* long term solution for governments, multinationals and so on. All organizations that have a huge inertia to switch, and before "buying" the whole FOSS thing still need to see or be told that there *is* a coherent, long term strategy behind. Back to my training class example: a portable macro embedded into an .odt file is what you could use to distribute tutorials or any other interactive educational material where there is scarce bandwidth and/or PCs not powerful enough to run OO.o. Ditto for CDs attached to magazines or books. Teacher writes on OO.o, students learn on KOffice. Or vice-versa. That's why I said "embedded into the .odt file". Of course, if (in the conditions above) there is any other solution which has the same end result for the student/user is OK, but is there? Ciao, Marco F. AFAIK add-ons are not part of the file (odt) but you can still insert code in the file by adding macros documents. The macros are libraries, scripts and even forms that are carry within the document. At least this is the way ooomacros.org have them and so does other files like Py-Xray and Dokuwiki. -- Alexandro Colorado Co-Leader of OpenOffice.org Spanish http://es.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Hi Marco, Fair question, but you partly answered it yourself. OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... IMHO, macros (developepd in StarBasic, python, beanshell, whateverlanguage) do not deal with openDocument at all It only deals with the layer the software (OOo) that render an OpenDocument gives the script through its API. It is implementation specific OpenDocment is /only/ the description of the xml files (eg content.xml), and not a specification of the api of the implementation Laurent -- Laurent Godard <[EMAIL PROTECTED]> - Ingénierie OpenOffice.org Indesko >> http://www.indesko.com Nuxeo CPS >> http://www.nuxeo.com - http://www.cps-project.org Livre "Programmation OpenOffice.org", Eyrolles 2004 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
D. Carrera wrote: > But this addon would not be embedded in an .odt paragraph (at > least, not in the current and near-future OOo releases). Why not, if I may ask? > May I ask... is there a reason why a .odt file is needed but > an addon won't work for you? (provided that the add-on works > whenever OOo is installed). Fair question, but you partly answered it yourself. OpenDocument is one thing, OO.o another. Who can assume that the latter *will* be installed wherever the former is used? Especially in 2/4 years, if OpenDocument is to become the truly universal that we keep saying etc etc... Before answering "gee, that's so far in the future, why bother?", keep in mind that OpenDocument is being advertised as *the* long term solution for governments, multinationals and so on. All organizations that have a huge inertia to switch, and before "buying" the whole FOSS thing still need to see or be told that there *is* a coherent, long term strategy behind. Back to my training class example: a portable macro embedded into an .odt file is what you could use to distribute tutorials or any other interactive educational material where there is scarce bandwidth and/or PCs not powerful enough to run OO.o. Ditto for CDs attached to magazines or books. Teacher writes on OO.o, students learn on KOffice. Or vice-versa. That's why I said "embedded into the .odt file". Of course, if (in the conditions above) there is any other solution which has the same end result for the student/user is OK, but is there? Ciao, Marco F. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Quoting "M. Fioretti" <[EMAIL PROTECTED]>: Greetings, What if I wanted to implement some OO.o macros with Python? What should I study, do, code, patch, download...? I suggest you to read Robert Vojta's blog and also subscribe to the dev@udk.openoffice.org list where the PyUNO guru -- Joerg is always helping. http://blog.vojta.name/archives/2005-06-02T11_51_04.html Rationale: poor end user (me), without any realistic possibility or skills to hack OO.o core code, not really eager to dig into StarBasic, has some complex Python text processing routines *already* written from other projects, by him and other guys. Hence, poor guy would love to use *those* Python scripts from within OO.o directly on the content of OO.o files. Instead of learning StarBasic and rewrite the same routines with it. So, is there a way for a normal end user, which has only the pre-built OO.o binaries, to add a Python interpreter to it and attach scripts to buttons, menus etc? TIA, Marco PS: Ditto with Perl, in case using it in OO.o is different than Python -- Marco Fiorettimfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ It's always socially unacceptable to be right too soon. -- RAH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Alexandro Colorado Co-Leader of OpenOffice.org Spanish http://es.openoffice.org/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
M. Fioretti wrote: Thanks for the prompt answer, I'll look at the links you provided. One thing to mention, maybe, is that I said "Macro", not "Add on". I thought you might have been thinking about .odt files, but wasn't sure. In any event, Python probably still comes closer to what you want than anything else I can think of. I was thinking to something I can embed into an .odt file and distribute (say a quiz system for training classes, or whatever strikes your fancy). In other words, assume I study what you told me, and manage to make the Python macro work on my (Linux) PC. Can I embed it in an OO.o file, and how many chances there are that if I send it by email to another (Windows) user he will be able to run it just as it did on my computer? (Never mind security for now, I need to understand the basic flow first). I can answer the second part of your paragrah: OOo itself comes with Python included. It is in the 'programs' directory. If you made an add-on with Python, it would install just fine on any computer. The addon would be a zip archive containing (1) one or more .py files for the actual code and (2) an XML file that tells OOo to add a menu entry and call your program when the user clicks on it. But this addon would not be embedded in an .odt paragraph (at least, not in the current and near-future OOo releases). If what you want *must* be in a .odt file I think you're stuck with StarBasic for now. May I ask... is there a reason why a .odt file is needed but an addon won't work for you? (provided that the add-on works whenever OOo is installed). Cheers, Daniel. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
On Tue, Jun 07, 2005 01:47:19 AM -0400, Daniel Carrera ([EMAIL PROTECTED]) wrote: > Hi Marco, > > Your best bet is Python, not Perl. I have good news and bad news. The > good news is that you can program OOo with Python and create > add-ons. Thanks for the prompt answer, I'll look at the links you provided. One thing to mention, maybe, is that I said "Macro", not "Add on". Sorry if this wasn't clear in the original message. I was thinking to something I can embed into an .odt file and distribute (say a quiz system for training classes, or whatever strikes your fancy). In other words, assume I study what you told me, and manage to make the Python macro work on my (Linux) PC. Can I embed it in an OO.o file, and how many chances there are that if I send it by email to another (Windows) user he will be able to run it just as it did on my computer? (Never mind security for now, I need to understand the basic flow first). TIA, Marco -- Marco Fiorettimfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ Cyberspace makes every place the same. But we're planning to put five billion people in it. [That] will freeze the entire species. Everything will stop dead in its tracks. Everyone will think the same thing at the same time.-- Michael Crichton, "The Lost World" - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [discuss] OO.o Macros with Python interpreter?
Hi Marco, Your best bet is Python, not Perl. I have good news and bad news. The good news is that you can program OOo with Python and create add-ons. The bad news is that Python doesn't eliminate the complexity of the OOo API. But at least you'll be using a better language than StarBasic or C++. Okay, places to learn how to do this: 1) Start here: http://udk.openoffice.org/python/python-bridge.html 2) Then go here: http://ext.openoffice.org.nz/doku.php?id=cookbook:python_uno_component And ask questions at dev@api.openoffice.org or [EMAIL PROTECTED] Once you figure out how to do what you want, please add what you learn to ext.openoffice.org.nz (it's a Wiki) so that the next person has an easier time figuring it out. With luck, one day we'll have a solid set of instructions for people wanting to program OOo in Python. Cheers, Daniel. M. Fioretti wrote: Greetings, What if I wanted to implement some OO.o macros with Python? What should I study, do, code, patch, download...? Rationale: poor end user (me), without any realistic possibility or skills to hack OO.o core code, not really eager to dig into StarBasic, has some complex Python text processing routines *already* written from other projects, by him and other guys. Hence, poor guy would love to use *those* Python scripts from within OO.o directly on the content of OO.o files. Instead of learning StarBasic and rewrite the same routines with it. So, is there a way for a normal end user, which has only the pre-built OO.o binaries, to add a Python interpreter to it and attach scripts to buttons, menus etc? TIA, Marco PS: Ditto with Perl, in case using it in OO.o is different than Python - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[discuss] OO.o Macros with Python interpreter?
Greetings, What if I wanted to implement some OO.o macros with Python? What should I study, do, code, patch, download...? Rationale: poor end user (me), without any realistic possibility or skills to hack OO.o core code, not really eager to dig into StarBasic, has some complex Python text processing routines *already* written from other projects, by him and other guys. Hence, poor guy would love to use *those* Python scripts from within OO.o directly on the content of OO.o files. Instead of learning StarBasic and rewrite the same routines with it. So, is there a way for a normal end user, which has only the pre-built OO.o binaries, to add a Python interpreter to it and attach scripts to buttons, menus etc? TIA, Marco PS: Ditto with Perl, in case using it in OO.o is different than Python -- Marco Fiorettimfioretti, at the server mclink.it Fedora Core 3 for low memory http://www.rule-project.org/ It's always socially unacceptable to be right too soon. -- RAH - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
