Re: [gtk-list] GUBIs interface (was: Re: ANNOUNCE: python-gtk version 0.1)

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On Mon, 3 Nov 1997, Francois Pennaneach wrote:

> I agree that we must keep the names consistent for every foreign binbings, but I think that using *exactly* the same names is a bad idea. That's the case for OO languages, for example, where you don't have to give the type of your gtk object in the meth

od names.
> 
> I think it's much better to write (Eiffel case) :
> 
> my_button.show
> than
> my_button.gtk_widget_show
> 
> And with the use of accessors :
> window.border_width, to read the border width
> and
> window.set_border_width, to set it.
> 
> Names are not exactly the same as in gtk.defs, but the code is easier to read and is perfectly understandable if you only know the C function names.
> 
> Those changes are minor and always work the same way, so that it's possible to create stubs using gtk.defs (I hope so, I'm actually trying to make it work ;-)
> 

ok, but *please* stick to this naming scheme, i'm currently figuring out a
general function/types description for Gubi to support all languages that have
Gtk+ bindings (which is not as easy as it might seem on the first look).
therefore (and for consitency in usage!) we need some simple rules to
do name/case conversions.

BTW:	at least for Gubi it is absolutly neccessary to specify function
	arguments to be of type in/out/inout. also Gubi needs some else
	flags like "type-creator" or such on functions like
	gtk_label_new(). the question is what has to go into gtk-gubi.defs
	and what can go into gtk.defs.
	
> Francois
> 

---
ciaoTJ