Re: [gtk-list] Re: Perl comments

[Kenneth Albanowski <kjahds kjahds com>]

On 23 Oct 1997, Marius Vollmer wrote:

> I think return values are consistently handled.  The last element of
> the GtkArg array (which is not included in the argument count) carries
> a pointer to a location for the return value.  You can access this
> location with the GTK_RETLOC macros.  There is a GTK_RETLOC for every
> fundamental GTK_TYPE.  I think all marshalling works this way.  When
> there are exceptions, they need to be assimilated.  Resistance is
> futile.

Yes, the example given is internally consistent, it's just not consistent
with other argument values (which means two functions to store values in
GtkArgs, instead of one), and it's not consistent with parameters passed
by value. 

I see no reason why the return value should not be handled exactly as a
"GTK_ARG_OUT" parameter (as you describe below) would be in the set of
input parameters. This simplies everything, IMO.

> > The timeout_add_interp and idle_add_interp go some direction in unifying
> > everything, but more work is needed. Ideally, I would love to see a single
> > style of marshalling function (currently the signal marshaller has a
> > different signature from the idle/timeout marshaller),
> 
> Hmm, really?  They both are GtkCallbackMarshallers, no?

timeout_add_interp and idle_add_interp, yes. But gtk_signal_set_funcs
still uses a GtkSignalMarshaller instead of a GtkCallbackMarshaller. I
don't see any obvious reason why the signal system can't invoke a
GtkCallbackMarshaller. It looks like the last two parameters in
GtkCallbackMarshaller are redundant. 

Also, init callbacks aren't processed through the marshaller yet. Just
about everything else is, though.

> > You mean in your working .defs file? This actually doesn't help me as
> > much, because the marshalling functions must be dynamic.
> 
> Yes, you are right.  We need to enhance the GtkArg mechanism as well.
> Maybe a new GtkArg field would do it.
> 
>     enum GtkArgMode {
>        GTK_ARG_IN,
>        GTK_ARG_OUT,
>        GTK_ARG_INOUT
>     };
> 
>     struct GtkArg {
>       ...
>       GtkArgMode mode;
>       ...
>     };
> 
> And then change the GTK_RETLOC macros to GTK_VALLOC and rule that
> whenever the mode is out or inout the value must be accessed by
> 
>     *GTK_VALLOC_INT(arg)
> 
> etc.

This looks feasible. However, it would be a bit nasty to build up arg
lists, as you couldn't use a single TYPE value for a parameter.

Maybe two bits of the type field could be reserved, so that GTK_ARG_OUT or
GTK_ARG_INOUT can optionally added to the type value. GTK_ARG_IN would be
the default, of course.

Due to the problem of treating read/write variables as read-only, there
would need some adjustment to the various access macros, so that
GTK_FUNDAMENTAL_TYPE, for example, returns some placeholder type
(GTK_TYPE_WRITABLE?) when called on a GTK_ARG_OUT parameter, and a
different macro entirely to return the genuine underlying type. 

> Is this still easier than using ILU?

Definitely.:-)

> > However, I have noticed one general fault: to make use of a name like
> > GtkFooBar, in some cases it must be transformed to gtk_foo_bar, and
> > GTK_FOO_BAR, and perhaps a few other variants. Currently this seems safe
> > enough to do, but it strikes me that this is not a very reliable
> > mechanism, and that not all languages may be as adept as Perl in dealing
> > with these transformations.
> 
> Hmm, yes, the name business is quite a hack.  What do you propose?

I've no idea, to be honest. Most of the verbosity is Gtk itself, using
different case/separation, instead of the equally common suffixes or
prefixes, to distinguish macros from structures from functions. 

There's no simple solution (we certainly shouldn't need to state all three
in the .defs file), except perhaps to add some sort of official
guidelines on writing widgets so that the manipulation rules are always
strictly followed.

The rule I've been using is that GtkFooBar in the .defs file becomes
Gtk_Foo_Bar via s/([a-z])([A-Z])/$1_$2/g, and then the case shifted up for
a macro, or down for a function. The original is used only for the
structure name.

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