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

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

On 20 Nov 1997, Owen Taylor wrote:

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

hm, functions like gtk_widget_show()/gtk_widget_hide() are neither
accessors nor mutators. moreover they change specififc widget
states so i called them activator/deactivator.


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

hm, i don't understand what you mean by widget->grab_focus()?
you are correct in your assumption about the builder, but in what
way would you think generality is missing?

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

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

this would not work for all slots then. as shown below i created
a slot named focus-grab which has no corresponding c-structure item in
_GtkWidget, in fact it's just a reference by another toplevel widget...

hm, we might extend the SLOT-DEFINITION to hold an additional c-field
definition like:

; SLOT-DEFINITION:
; (TYPE SLOT-NAME [DEFAULT-VALUE] [DESCRIPTION] [ACTION-DEFINITION]
; [C-FIELD-DEFINITION])
;
; C-FIELD-DEFINITION:
; (c-field {accessible|mutatible} TYPE NAME)
(define-object GtkButton (GtkContainer)
  (slots
    (bool button_down
      (c-field accessible))))

this will identify the corresponding c-structure field for this slot,
if it has one...

> > (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  ^^

if you call gtk_widget_set_uposition (MyWidget, 5, -2);
only the x value will get changed...

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

if you call gtk_widget_set_uposition (MyWidget, -2, 7);
only the y value will get changed...
(you will figure this from the implementation
of gtk_widget_set_uposition()....)

> 
> > ; OBJECT-DEFINITION:
> > ; (define-object TYPE-NAME (PARENT-TYPE) [DESCRIPTION]
> > ; [SLOTS] [CREATOR] )
> 
> 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.

ok, this has been changed to
; OBJECT-DEFINITION:
; (define-object TYPE-NAME (PARENT-TYPE) [DESCRIPTION]
; [SLOTS] [CREATOR...] )

so you can do
(define-object GtkButton (GtkContainer)
  (creator gtk-button-new)
  (creator gtk-button-new-with-label))

if there are multiple creation possibilities, give them to the user...
            

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

i'm not sure how you would like to describe this...

> 
> Signal specifications seem to a missing ingredient here.

this could be a made by a function definition inside the widget
definition, haven't thought this out yet...

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

this is because there is a definite overlap in the gtk+ api (which is
not bad IMHO).
i'd prefer to have special action types on gtk-object-set and gtk-object-get
as these functions differ in calling conventions much from the rest of the
api.
so what about

; ACTION-TYPE:
; {accessor|mutator|activator|deactivator|generic-accesor|generic-mutator}
(define-object GtkButton (GtkContainer)
  (slots
    (string label
      (description
        "the label argument of a button is used to specify the"
        "string that will be displayed by a label which is"
        "automatically added to the button as it's sole child")
      (generic-mutator gtk-widget-set))))

this might seem to vague, but the gtk-widget-set and
gtk-object-set/gtk-object-setv functions need to be special cased
anyway because of their c-specififc calling conventions and because
they take strings (and values of different types) as arguments that
don't even refer to fields of the corresponding widgets c-structure.

i don't even think we should bother about that too much at the moment,
because this functionality isn't fully implemented yet (not even
half way).


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

hu? i'm having real problems understanding your statement here, do you mean
the function-definition part? as far as plain C goes, function parameters
can't be omitted (even the ellipsis only allowes additional parameter
specifications), but i know that you know this, so i don't understand you ;)

> 
> Regards,
>                                         Owen
> 

---
ciaoTJ