Re: [gtk-list] Re: Perl comments

[Kenneth Albanowski <kjahds kjahds com>]

On 20 Oct 1997, Owen Taylor wrote:

> I would suggest instead adopting the IDL convention that parameters
> can be "in" (default), "inout", or "out". Almost all such parameters
> in functions and signal handlers are "out" not "inout" and this can
> be used to advantage by language bindings. 
> 
> (e.g. ($x,$y) = $window->get_pointer() )

Yes, my big hope is to automate a number of the calls that return more
then one argument. With full "directional" information, this might be
possible, although there are still some functions that are quite difficult
to describe -- like the _color functions that take or return an array of
floats with unspecified size, or functions that take or return GList's
containing an unspecified type.

> > > I've got a slight bone to pick about GdkWindow: I'm of the opinion that
> > > it's inappropriate to treat GdkPixmap as "a type of" GdkWindow (with the
> > > result that GdkWindow is mentioned in gtk.defs). Since the various drawing
> > > functions work on both GdkPixmap's and GdkWindow's, but the window
> > > functions only work on GdkWindow, it seems to make much more sense to
> > > treat GdkPixmap as the "base", with GdkWindow and GdkBitmap as inheriting
> > > from GdkPixmap. (Yes, I realize this doesn't actually affect any code,
> > > it's just a semantic change.)
> 
> Why not follow the way things set up in the C code typedef's and
> consider all three subclasses of GdkDrawable? There's no reason to
> assume the operations on either GdkPixmap or GdkWindow will always be
> proper subset of the other, though it may work that way now.

I honestly hadn't noticed Drawable. If the types _can_ be described with a
decent relationship diagram, I'll be glad to honor it. Unfortunately the
typedefs provide no clue, implementing all of the types with a _GdkWindow.

-- 
Kenneth Albanowski (kjahds@kjahds.com, CIS: 70705,126)