Hi,
seems I wrote my previous message too quick. Forgive me (but I still
don't feel familiar with UNO)...
If I'm right (this time), the idea I proposed to rewrite the main
pyuno part exporting explicitely UNO services from their idl is
nonsense, since UNO objs could come from other scripting frameworks,
be added by the user, etc.
Seems to me that there is no really other way of doing the bridge than
more or less the way it is actually done. For now, I'm still thinking
that transforming UNO objects ("pyuno" instances) to make them more
Pythonic would be really much easier at Python level (with an injector
metaclass for example, as long as I can find a way of doing so even on
instances that do not have a __class__...).
I'm investigating on this.
David
2005/12/9, David Douard <[EMAIL PROTECTED]>:
> Hi,
>
> 2005/11/29, Joerg Budischewski <[EMAIL PROTECTED]>:
> >
> > Hi,
> >
> > >> thinking to a quite elegant solution using metaclasses).
> > >> it should be done at the C level, and I think, it shouldn't be too
> > >> difficult once one knows, which properties to support to achieve this.
> > > OK, I'll have a look at this ASAP, if you wis ;-)
> > sure, go ahead.
> >
> > > I have
> > > > solved my issues with pythonscript.py .
> > > I already have a fix for this issue, just wanted to let you know
> ...
> > > Is it available on the CVS repository or somewhere else (I have not
> > > checked yet) ?
> > well, yes there is an cws cws_src680_pyunofixes2, which is currently
> > based on a quite SRC680_m106, where several fixes for pyuno went into.
> >
> > The relevant patch is the last difference in
> >
> >
> >
> http://udk.openoffice.org/source/browse/udk/pyuno/source/module/pyuno.cxx?r1=1.6&r2=1.6.12.1
> >
> > , basically a get() must be replaced by a getAcquired() because of this
> > strange semantics, that PyList_SetItem steals a reference.
>
>
> This seems to work OK. Now the __members__ is working.
> But, in fact this is more/less useless, I think (more, __members__ and so
> are deprecated methods since Python 2.2).
> IMHO, the way the "pyuno" is exported to python (basically, just by
> reimplementing the __getattr__ & __setattr__ methods) is a hack.
> It has the (big) advantage that there is only one C object for every UNO
> service and class, but it is almost impossible to export UNO objects the
> Python way with this hack.
> I mean, the usual way of exporting methods and properties is to define the
> PyTypeObject's tp_methods, tp_members and tp_getset (and more) struct
> items.
> This cannot be done with one kind of "C metaclass" like it is done now.
> The only way (AFAIK) would be to have a tool that create C files from IDL
> files for every UNO service & interface, accroding the several namespaces
> (wich would be Python modules then).
> It seems that Boost is actually included in OOo, thus it could be used to
> create Boost.Python wrappers for every C++ class & struct that need to be
> exported in Python. This should not be very hard.
> The main drawback is the pyuno dll would the be notably bigger...But the
> whole pyuno would then be much more pythonic and maybe notably quicker (not
> sure of that, btw).
>
> The other way of doing so it, as I suggested, to add the standard class
> methods & properties in pure Python.
>
> > One remark. I am not sure the use of "smart-pyref" is really a helpful
> > > tool. I think this brings more confusion than help in the code. I have
> > > no time to develop this now, but I can do it later if you think I am
> > wrong.
> > I agree that this is not the common way how python C code is developed.
> > However in a world with c++ exceptions it becomes really very tedious to
> > do the refcounting by hand because want would have to introduce a lot
> > of additional try{} catch{} clauses to do the recounting right.
> >
> > You need to concentrate on doing the smart-pyref right, when it is
> > constructed, but when you achieve this, it is very easy to add more
> > exits to a function without going through all the refcounting again.
> >
> > Bye,
> >
> > Joerg
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> I have succeeded (at least) in making pythonscript.py able to
> create/edit/rename/delete python scripts.
> The editor is still the very poor OOo TextEditor. It can use a
> Tkinter.Textwith syntax colorization, but this worls only if the
> tcl/tk & tkinter stuff
> is correctly built, which is not the case with the OOo official binary
> (under Linux at least).
> On my laptop, I have the Suse version of OOo 2.0 in which everything
> related
> with Tkinter works fine out of the box (since the python bundled with OOo
> is
> the main distrib's python 2.4).
> Should I send my file on this list?
>
> Thanks,
> David
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
