Re: Introspection use cases
- From: Christian M <christian gm gmail com>
- To: gtk-devel-list gnome org
- Subject: Re: Introspection use cases
- Date: Fri, 25 Feb 2005 23:21:18 +0100
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
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]