On Mon, 2004-12-13 at 18:06 -0100, Tiago Cogumbreiro wrote: > Mon, 2004-12-13 �s 18:47 +0000, Gustavo J. A. M. Carneiro escreveu: > > Seg, 2004-12-13 �s 16:29 -0100, Tiago Cogumbreiro escreveu: > > > Mon, 2004-12-13 �s 10:49 +0000, Gustavo J. A. M. Carneiro escreveu: > > > > Seg, 2004-12-13 �s 08:37 -0100, Tiago Cogumbreiro escreveu: > > > > > Fri, 2004-12-10 �s 09:56 +0100, Xavier Ordoquy escreveu: > > > > > > On Fri, 2004-12-10 at 01:13 -0100, Tiago Cogumbreiro wrote: > > > > > > > The problem I was having was that the headers I was using mixed > > > > > > > with > > > > > > > h2defs.py weren't declaring the object itself, making the module > > > > > > > kind of > > > > > > > useless. > > > > > > > > I've noticed this too. But declaring the missing objects/boxed types > > > > is just 1% of the total defs file, very easy to add manually. Just > > > > copy-paste from somewhere else and change the names ;) > > > > Also keep in mind that, despite popular belief, h2def is just a helper > > > > tool to avoid generating the defs entirely by hand. The defs need some > > > > manual tuning after the initial generation, so don't expect to re-run > > > > h2def later and replace the original defs. Basically, h2def != codegen. > > > > > > > Indeed. That was my initial thought. Maintaining a .def is way easier > > > then maintaining the full source ;) > > > > > > > > > > > > > > > > > > > h2defs expects the header to be somewhat similar to the gnome de > > > > > > facto > > > > > > standard headers. the script isn't really perfect, but there are so > > > > > > many > > > > > > possibilities that one has to put some restrictions. > > > > > I'm wrapping libnautilus-burn. At a first glance the headers seemed > > > > > quite standard. > > > > > > > > Hm.. this almost sounds like a good candidate for gnome-python- > > > > extras... >;-) > > > Good to hear that :D > > > > > > > > > > > > > > > > > > > > > > > > > The problem I'm facing now, due to not yet reading [2] is wrapping > > > > > > > simple structures into objects. Tried with swig but it has way too > > > > > > > vodoo, so I think I'll just look at python.org resources and try > > > > > > > to > > > > > > > learn how to do it The Right Way (TM). It would be nice for the > > > > > > > defs > > > > > > > parser to parse structures tough ;) > > > > > > > > > > > > What would the structures be translated to in python ?? > > > > > > If it becomes objects, you could made them gobject in C then ;) > > > > > I think it's easier creating a C python object directly :D (which I've > > > > > already did) > > > > > > > > If you're wrapping GObject's, _please_ use pygtk (PyGObject), > > > > otherwise you'll get in trouble sooner or later. For instance, it is > > > > not trivial to implement GObject.connect. > > > All GObject are going to be wrapped using pygtk, since it's The Right To > > > Do It (TM). However, since there is no support for structs in codegen > > > > Actually, codegen almost supports structs. If these structs are > > registered with glib as boxed types, they are supported. Registering a > > structure as boxed type basically means to register a function for > > copying the structure and another for freeing its memory. Then, codegen > > can generate code to create a new Python object type with attributes and > > methods, just like GObject. > Is that the advised way of doing it? What are the advantages in regards > with other pygtk based objects?
Well, you have to think carefully, because copying structures means different semantics than just keeping references. So it doesn't work out too well in some cases when, for example, you want to modify a structure returned by some method. With boxed types, you usually end up modifying a temporary copy instead. However, I see many times structures wrapped with copy/free functions that just implement simple reference counting, i.e. copy=ref and free=unref. > > > > > > (ie defs) I am going to bind the remaining simple structs as simple > > > Python objects (using libpython, not swig). This is somewhat the same > > > thing done in pygtk, isn't it? > > > > > (for example the gobject.MainContext) > > > > Actually gobject module is currently 100% hand crafted. Bad > > example :) > > > Isn't it because of the same "difficulties" I am passing? The glib part > (which is structs based) cannot be generated. That's why I gave it, > there are no defs for one set of classes in the wrapped module and they > must be hand crafted as well. I don't know. I guess glib module is rather small. > > This is not a problem at all, since wrapping simple structure is not > difficult and works out ok. Cool. Just trying to help :) > > -- Gustavo J. A. M. Carneiro <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> The universe is always one step beyond logic
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ pygtk mailing list [EMAIL PROTECTED] http://www.daa.com.au/mailman/listinfo/pygtk Read the PyGTK FAQ: http://www.async.com.br/faq/pygtk/
