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

[Derek Simkowiak <dereks kd-dev com>]

-> > This sounds like JavaBeans.
[...]
-> > Besides language bindings, IDEs (and people :) would be able to realize a
-> > widget's functionality without any prior knowledge of the widget 

-> 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.

	I don't know anything about Glade, but I do know that one of the
ChangeLog entries (from a loooong time ago) was "Now supports
GnomeCanvas".  To me, that implies that widgets need to have support
explicitly compiled in--which is no good in a world full of
special-purpose third-party widgets.


-> 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.

	If people are interested in this kind of a system (I know I am), I
think Glib should have a function to do this.  That'd be new code, meaning
the 2-week deadline :)

	It would be good if all the of the widgets with read/write members
had corresponding *_set_<member-var> and *_get_<member-var> methods,
instead of needing to access any members directly.  Besides being good
coding, it would allow for a system like this.  More gruntwork...

	(Also, in case the debate over whether or not to have signals in
the GObject system is still open, I think this would be an argument for)


--Derek