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

[wmperry aventail com (William M. Perry)]

Bryan Patrick Coleman <bpcolema@uncg.edu> writes:

> On Tue, 27 Jun 2000, Dean Jones wrote:
> >how this overlaps with the GNOME toolkits (like the GnomeCanvas issue),
> 
> I like gtk+ better than the gnome stuff which does not seem to add that
> much to me.

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

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.

The GNOME stuff is particularly awful in this respect, but even the core
GTK widgets could be much better.  If this gets done, the .defs file could
get much simpler.

Right now in the XEmacs lisp bindings you can just do:

(setq container-widget (gtk-hbutton-box-new)
      child-widget (gtk-label-new "Testing"))
(put container-widget 'child child-widget)

instead of calling gtk-container-add directly.  Maybe not the best example,
but it works. :) Readability would actually be much more useful.  Instead
of having to create functions to get at the hscrollbar or vscrollbar in a
GtkScrolledWindow, you could just do:

(get scrolled-window 'hscrollbar)
or
(get clist-object 'rows) ; access 'gint rows' of struct GtkCList
(get paned-object 'child1) ; access `child1' of struct GtkPaned.  Basically
any `public' entry in the GtkFoo struct should have a corresponding
argument exposed.

This would actually be safer as well, since the argument system in Gtk
allows the widget to specify whether something is read-only or not.

Depending on how far out Gtk 2.0 is, I would love to see this get into
there.

-Bill P.