Re: GTK+ Future timelines and features, help needed ???

[wmperry aventail com (William M. Perry)]

Derek Simkowiak <dereks@kd-dev.com> writes:

> -> One thing that I would LOVE to see is a general review of all the widgets,
> -> and make them expose most of their functionality through arguments.
> 
> This sounds like JavaBeans.  If we used the GtkArg system and had a
> JavaBeans-like spec, we could even make the object's functionality show
> up at runtime.

Yup, when I was reading havoc's book and got to the chapter about object
arguments I was very excited, but the widgets don't quite live up to the
potential of the object system.

> -> way language bindings could have a generic interface to things using
> -> gtk_object_setv / gtk_object_getv instead of having to access things inside
> -> the structure directly.
> 
> Besides language bindings, IDEs (and people :) would be able to realize a
> widget's functionality without any prior knowledge of the widget (I'm
> thinking of the beanbox here).

It would be great for glade as well... I thought that glade just used the
object system after parsing the XML, but after perusing a glade project it
didn't seem to be using any of the argument names, so it must be doing
something different.

In XEmacs, it knows as little as possible about the widgets, and you import
the functions entirely in lisp.  I was able to import most of GtkExtra
without recompiling XEmacs at all.  It would be great if Guile and Glade
could do the same.

> Only thing is, to use 3rd-party widgets in this manner (which is what
> beans are really good for) we would need some kind of plug-in or shared
> object standard to compare to Java's ability to load an arbitrary .class
> or .jar file.  Hmm, I haven't really thought this through...

This would be up to the application that wants to use the new widgets.  In
XEmacs I just exposed a dll-load function that loads the DLL stores the
reference in a hashtable, and the gtk-import-function walks the list of
DLLs that have been opened if it can't find it using the main executables
set of libraries.

So to load GNOME into a XEmacs that wasn't compiled into it:

(defvar gnome-init-called nil)

(defun gnome-init (app-id app-version argv)
  (mapc 'dll-load
	'("libgnomesupport.so"
	  "libgnome.so"
	  "libgnomeui.so"
	  "libesd.so"
	  "libaudiofile.so"
	  "libart_lgpl.so"))
  (if (and (not (noninteractive)) (not gnome-init-called)
	   (= (gtk-type-from-name "GnomeApp") 0))      
      (prog1
	  (gtk-call-function (gtk-import-function-internal
			      'gint "gnome_init" '(GtkString GtkString gint GtkArrayOfString))
			     (list app-id app-version (length argv) argv))
	(setq gnome-init-called t))))

And then loading gnome-widgets.el will expose the guts of (most of) the
GNOME widgets, all without any C level changes.

> -> I'd be willing to help on this, but I'm not sure when I'm going to have
> -> time.  I'm looking at taking another few months off from work in late
> -> february, so I might be able to find time then.
> 
> Hey Bill, how are things at Aventail :)?  (We met briefly at Spry)

Better than SPRY. :)

-Bill P.