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

[Tim Janik <Tim Janik Hamburg Netsurf DE>]

hi Kenneth,

first i'd like to thank for your positive response ;)

On Thu, 20 Nov 1997, Kenneth Albanowski wrote:

> On Thu, 20 Nov 1997, Tim Janik wrote:
> 
> > -	slots consist of a type/name pair that can have optional default
> > 	values (main use: interface builders) followed by an optional
> > 	action description.
> > -	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.
> 
> I hope this works well enough. Remember, the optimal goal is something
> like Visual Basic or Delphi, where the entire object state can be
> controlled through a property inspectory -- and that it should be possible
> to invoke the functions within dynamically loaded code. 

i'm not sure what you mean by dynamically loaded code, are we talking only
C here?
for GUBI i'm thinking about generating one sole function as a multi caller,
that takes the gtk-function description and it's parameters as argument and
then calls it.

> > > Widget Name:    | MyWindow      |
> > > Title:          | MyWindowTitle |
> > > Icon Title:     | MyIconTitle   |
> > 
> > > im prinzip soll es nur moeglich sein saemtlichen widget-specifischen
> > > parametern einen eindeutigen (sinnvollen) namen zu zuordnen.
> > basically, it should just be possible to assign each widget specific parameter
> > an own, unique and suggestive name.
> 
> I'm not sure this is needed. You could have a "simple" name for each slot,
> and automatically prepend the class name if there is a collision. 

please look at my other mail to owen, we can do much more with slots like
defining "virtual" widget parameters (e.g. can-focus), defining c-structure
components for each struct _Gtk*, and we can have a slot describing the
gtk_widget_set() interface...

> > please note that nothing of this is stone graved at the moment and your
> > comments, suggestions and criticism is more than apprechiated.
> > 
> > 
> > now, here comes a sample portion of what i'd like GUBIs new gtk.defs file
> > to look like:
> [...]
> 
> Looks good. It'll be work to parse it from Perl, but it will be worth it,
> I think.

i'm currently implementing a parsing back end (in C ;) that reads in the
*.defs file and builds an internal tree of it. this can have different front
ends then (e.g. one  that dumps the function names and their descriptions to
a text file).
you could easily implement a front end that suits your needs for this then...

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

---
ciaoTJ