Sha256: e392fec5e7710de0357dc4a2c6fca1a490b80082ec6bbcdd7503aca3100e1c01
Contents?: true
Size: 1.5 KB
Versions: 3
Compression:
Stored size: 1.5 KB
Contents
= TODO == Use GIR to bootstrap the GIRepository namespace Currently, all the classes used to read the GIR are hand-coded. It should be possible to hand-code only part of it and use that to generate the rest. This would also integrate that properly with the rest of the GObject type system. Update: This has been tried, but the problem is that the GIRepository namespace is not object-oriented: The Info structs are not GObjects, and the methods that act upon them are just functions in the GIRepository namespace. Perhaps some custom method_missing can be implemented to handle this, though. == Handle passing of generic pointers Many GObject methods take a pointer to 'user data'. This means we should be able to pass any Ruby object. On the other hand, these cases cannot be distinguished, based on the GIR data, from methods that take a pointer to any GObject. I'm currently leaning towards passing the object id as the value of the 'gpointer'. Special overrided will have to be used for the cases where the 'gpointer' actually needs to be a GObject. I consider it an omission in GIRepository that these two cases are not distinguished. == Compatibility with all implementations. Currently, there are the following incompatibilities: * The MRI implementation does not allow invoking layout more than once. In particular, this means you cannot subclass a struct and change (augment) the layout. This *not* a problem in JRuby. * JRuby disables ObjectSpace by default, so using _id2ref is not ideal. == See Also rake notes
Version data entries
3 entries across 3 versions & 1 rubygems
Version | Path |
---|---|
gir_ffi-0.0.3 | TODO.rdoc |
gir_ffi-0.0.2 | TODO.rdoc |
gir_ffi-0.0.1 | TODO.rdoc |