Re: Introspection use cases

[Christian M <christian gm gmail com>]

What about creating instances or querying without explicit library references?
example:
* window= gobject.createInstance("org.gtk.GtkWindow")

* list= gobject.allClassesImplementing("org.gstreamer.ICodec")

* list= gobject.allClassesImplementing("org.gnome.nautilus.IExtension")
etc etc

In this context would namespace support also be nice. This might be
out of scope for
GObject/GTK and perhaps more relevant for gnome in general. Such a system
could for example be used to implement plug-in/extension functionality instead
of having application specific solutions to the common problem.

Regards Christian


On Fri, 25 Feb 2005 16:39:12 -0500, Owen Taylor <otaylor redhat com> wrote:
> Some random thoughts of things we might want to do with the
> introspection information when we have it.
> 
> Regards,
>                                         Owen
> 
> * GUI builder
> 
>   - It should be possible to load up an arbitrary .so file
>     into a GUI builder, find the widget (and other object)
>     types in it, create them and manipulate them.
> 
> * "Libglade"
> 
>   - Should be possible to create a "libglade" equivalent that
>     uses introspection information to locate _get_type()
>     functions.
> 
> * Dynamic language binding
> 
> - It should be possible to create a "good" language binding
>    that works purely from introspection information.
> 
>    import gobject
>    gobject.load_library("libgtk-x11-2.0.so.0")
> 
>    window = gtk.Window(gtk.WINDOW_TOPLEVEL)
> 
>    [...]
> 
>   Obviously, matching an existing API or writing language
>   specific convenience functions would require custom glue.
> 
> - It should be possible to implement interfaces in dynamic
>   language bindings.
> 
> * Static language bindings.
> 
> - It should be possible to create a "good" language binding
>   that creates a wrapper library in a compiled language completely
>   from introspection information.
> 
>    $ gtkc++-compile libgtk-x11-2.0.so.0 -o libgtkc++-2.0.so.0.8.0
>      --include-output-dir=gtkc++
> 
>    #include <gtkc++/Window>
> 
>    [...]
>     gtk.Window *w = new gtk.Window(gtk.WINDOW_TOPLEVEL);
> 
>   Obviously, matching an existing API or writing language
>   specific convenience functions would require custom glue.
> 
> * Cross language interchange of objects
> 
>   It should be possible to create an object in language A, and use it
>   from language B. (Activation is outside the scope of GObject, so
>   say that the object already exists.)
> 
>   E.g., to write a FSpot (C# app) plugin in C, you'd first generate
>   a wrapper library, then compile against that.
> 
>    $ gobject-wrapper fspot.xml -o libfspot.so.0
>     --include-output-dir=fspot
> 
>    #include <fspot/App.h>
> 
>    [...]
> 
>    FSpotApp *app = fspot_app_get(); // static method
>    FSpotAlbum *album= fspot_app_get_album (app, 0); // method
> 
>   Obviously using arbitrary language features in the exported
>   interfaces won't work, just as using arbitrary C won't work. But
>   I think a limited subset is pretty easy to support.
> 
>   Also, arbitrary cross-language derivation is impractical, so
>   interfaces that require subclassing must be avoided.
> 
> * Debug tools:
> 
>   - Having introspection information used by a debugger could
>     be incredibly cool. Imagine being able to do:
> 
>     (gdb) call gtk_window_list_toplevels()
> 
>     And getting a list of GtkWindow *. If gdb was only more
>     extensible...
> 
> - Could introspection information be combined with "sparse"
>   to do static checking of code for memory leaks, etc?
> 
>   (More ambitious, use introspection information in a compiler
>   frontend or preprocessor to optimize out runtime cast
>   checks)
> 
> - Could you do interesting things with introspection information
>   from a valgrind skin?
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
>