Fso Python binding

[Guillaume Chereau]

On Mon, 2009-02-16 at 07:51 +0100, Michele Renda wrote:
> On 16/02/2009 03:44, Guillaume Chereau wrote:
> > Hi Michele,
> >    
> Hello Guillaume
> > I share your feeling that directly using dbus in python is a little bit
> > tedious.
> > I didn't try your your code, just had a look at it, I like how the dbus
> > methods are directly added into the object instead of using the
> > __getattr__ method, it means we can use automatic completion from the
> > python interpreter, something that is missing with DBus proxy objects.
> >    
> I don't think the code completation will never work, at least in a 
> editor, because the methods available will be known only
> during the execution of the code, not before :(
Yes but I was thinking of cli-framework where you interactively create
and manipulate the proxies objects. There the auto-completion would work
and be very helpful.

By the way, why do you change the name convention for the dbus methods,
and make them all lowercase ? I know python convention is to use
lowercase, but in that case I would prefer having the same name as the
original DBus method (just a suggestion.)

> The good part it that this library will not need to be updated if 
> fso-frameworkd will change.
> The weak part is that fso-frameworkd deamon will change, all the 
> applications that use it will continue to need to be updated.
> > What I like less is that you are using GObject, which mean I won't be
> > able use your library for paroli.
> >    
> Ops... my fault. I use PyGtk, so I thought that GObject is all the 
> world. And I forgot that exist a world done by other toolkits.
> I think it needed to be called PyGtkFso or PyGObjectFso, and if the 
> ideas is nice, it will not be difficult to create a version of the same 
> library to
> run with Qt and with Efl. I need only to study a bit PyQt and PyEfl.
Yes I know the pain of trying to write generic code for gobject, qt or
efl. The python Dbus library allow you to specify the underlying
mainloop you are using when you create the bus object, in your case that
would be more tricky I guess cause you use GObject as a base class for
all you proxies. May be possible though.

> > Also I though all the signals in GObject class had to be declared at the
> > class level, how does it work with your introspection mechanism ?
> >    
> This is the part I like more (but I don't know how much clean it is).... 
> I redefine the method "connect" and if a signal si a signal for dbus 
> (that I read on runtime), I connect it direct to dbus, else I contine to 
> connect to the object.
Ah I see, nice !

> Still I have to test well the part with signals, I tested well only methods.
> To be runned, it need the mdbus script copied as mdbus.py in the same 
> forlder of pyfso.py (I steal a class from Michael).
> > Anyway, I think it is a good initiative, maybe Mickey will consider
> > adding this or something similar to the framework git.
> >
> >    
> For now I will try to use on some programs I created. But I son't think 
> it is so good code to enter in framework. For now it is only an experiment.
I'll keep an eye on this project. If you could somehow embed it into an
interactive python interpreter (see cli-framework), then I would give a
try for sure. 
> 
> Thank you
> Michele Renda
> 
Regards,
Guillaume Chereau
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.openmoko.org/pipermail/community/attachments/20090216/7b3a9457/attachment.pgp