Re: Plans for 2.8 - GNOME Managed Language Services?
- From: Murray Cumming <murrayc murrayc com>
- To: Mike Hearn <mike navi cx>
- Cc: "desktop-devel-list gnome org" <desktop-devel-list gnome org>, "language-bindings gnome org" <language-bindings gnome org>
- Subject: Re: Plans for 2.8 - GNOME Managed Language Services?
- Date: Sun, 28 Mar 2004 17:40:27 +0200
On Sat, 2004-03-27 at 01:23, Mike Hearn wrote:
[with gratuitous snipping]
> As Soeren said it needn't be GType/GObject specific, a lighter weight
> abstraction over basic C types could be useful as well, if only for
> quickly strapping it onto existing code (C_ARRAY, C_STRUCT, C_STRING etc)
There aren't many GTK+ functions that take only basic C types. It
wouldn't be a very useful if it just told us that function
do_something() took 4 void* parameters and returned a void*.
Note that there already is a gtype-based system like this for signals,
which gtkmm, python, and probably others use, though gtkmm doesn't use
it at runtime.
> * Ability to bind objects from other languages -> GObject.
> Loading and reflecting a Python object into C should be an interesting
> project for somebody that wouldn't be too hard - the Python object model,
> with the exception of signals (which afaik is not a part of any native
> language OM) is a superset of GObject so it should not be too painful as
> long as some basic rules are followed. You could then write a Python class
> and run the automatic generator program on it to spit out a
> libmegaobject.so.0 file which contains the GObject skeletons for the
> class, along with code that implements the reflection interfaces.
I think that pyorbit might do something similar already, using the ORBit
typelibrary thing.
> * Not required but would be cool, ability to do all that automatically for
> objects from dynamic languages.
>
> What I mean is there should be a generic:
>
> GObject *python_get_gobject_from_class(PyObject *pyobj)
>
> method, which:
>
> - reflects the python object and creates a new GType
> - construct assembly thunks for the methods, init the signals
> and so on, ie basically build the object at runtime
> - delegates the reflection interfaces to a generic implementation
>
> you can then do:
>
> g_object_get_method(gobj, "some_foo_method") to get the function pointer,
Oh, and dbus has similar things, though I don't think it has a full type
system yet.
--
Murray Cumming
www.murrayc.com
murrayc murrayc com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]