Re: [gtk-list] Proposal: GUBIs gtk.def

Tim Janik <Tim.Janik@Hamburg.Netsurf.DE> writes:

> -	actions are of a specified type (type currently consists of one out of
> 	{accessor|mutator|activator|deactivator}), a function portion and
> 	its calling parameter descriptions. hereby parameter can be a
> 	constant value (e.g. -1) a reference to the object the slot referes to,
> 	named `this' or a reference to the slot itself indicated by the
> 	slots name.

Maybe you could expand on this a bit more. Accessor and mutator make
sense, but I'm not really quite sure about activator/deactivator.
What are some other examples? Why wouldn't a function
widget->grab_focus() work just as well? (I suppose in this instance
you might want to have a check button for initial focus grab
in a GUI builder - but I'm not sure of the generality of this.)

Can a single slot have several actions ? (something that can 
both be accessed and mutated?)

Maybe there should be a way to indicate that a slot is a variable in
the corresponding C structure and should be accessed directly? (To
avoid having to have to add a bunch of accessors/mutators to the C

> (define-object GtkWidget (GtkObject)
>   (slots
>     (GtkWidget	widget)
>     (bool	focus-grab	0
>       (activator	gtk-widget-grab-focus this))
>     (gint	x	-2
>       (mutator	gtk-widget-set-uposition this  x -2))
                                      what does this do  ^^

>     (gint	y	-2
>       (mutator	gtk-widget-set-uposition this -2 y))))
                       why is this in the other order ^^


Hmmm, what about things with more than one creator?
(For instance, a Font can be created with either gdk_font_load
or gdk_fontset_load.

Some other considerations:

I'd still like to see a way to specify structures passed by
value. Despite what people may think, a rectangle is _not_
an object with accessors/mutators for x,y, width and height.

Signal specifications seem to a missing ingredient here.

You should give some thought as to how your slots interact
with the gtk_object_set() mechanism. I like the slots better
because they can work with static languages, but there is
definitely an overlap here.

Function arguments should be able to be specified as optional.
I think this is already in the current gtk.defs spec - if
so it should definitely be retained.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]