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

[Kenneth Albanowski <kjahds kjahds com>]

On Thu, 20 Nov 1997, Tim Janik wrote:

> hi folks,
> 
> within the last few days i exchanged quite some ideas with marius vollmer
> about GUBIs gtk.defs format. within this process marius suggested to use
> this format as a general gtk+ interface description, which is why i'm
> drafting this proposal to which he has been a great help in creation.
> my main intention was driven by the fact that i figured i would need much
> deeper and precise information about the gtk+ interface then what is currently
> provided by GUBIs hardcoded widget knowledge or the guile-gtk gtk.defs file,
> if i ever want to have a chance to support multiple target languages close to
> their fullest extends.
> 
> the main stubs are:
> 
> -	function definitions now consist of the library-domain,
> 	the operation-symbol and a method name like
> 	gtk widget set-uposition
> 	instead of the old
> 	gtk-widget-set-uposition
> 	because this didn't provide enough information to build oo-stubs.

Yes, this would be much appreciate. I'll note that in the Perl binding,
I've tended to duplicate functions like gtk_signal_connect, you could say
(this isn't actually the case in the current implementation, but only
because I've not felt like doing the work) either:

   Gtk::Signal->connect($object, "event", sub { "handler" });

or:

   $object->signal_connect("event", sub { "handler" });

It's relatively easy to auto-generate this stuff if the "domain" is broken
out of the function definition.

> 	function arguments are grouped together now (through another
> 	perenthesis level) and are flagged to be of type `in', `out' or
> 	`inout'.

Good.

> -	object definitions can have a creator function assigned now, and the
> 	old `fields' part inside the object definitons (which used to be
> 	merely a hack anyway) will be replaced by a `slot' defintion.

We'll have to see how well this works.

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

> -	function grouping. functions can be put into groups which is usefull
> 	for locical separation along lines like `creation', `linkage',
> 	`configuration', `connection', `misc', etc...

Maybe something tree based would work as well. "general/specific/...", or
somesuch.

> -	library domain hints. library domains should be defined preceeding
> 	to the function deinitions and can contain informations like
> 	neccessary include files or linkage dependencies on other libraries.

I think that this should simple be considered part and parcel of having a
 .defs file. Such a file should give complete information on how to use
the described widgets, and that includes how to link to them and compile
with them.

> -	descriptions: these consist of the keyword `description' followed
> 	by strings which will be concatenated in the glue building process.
> 	descriptions are optional on every single item.

Yes, definitely! An excellent idea. I've no idea how I might support this
in Perl, but I'd love the opportunity to try. 

> concerning the slots i'd like to translate a simple example i gave to marius
> explaining the neccessity of expressing widget parameters besides the
> additional arguments that could be figured from their corresponding
> `configure' functions:
> 
> > das problem ist, das dieser per-widget-parameter die funktions argumente
> > pro widget unterscheiden soll, die fuer das gleiche widget gleich aussehen
> > koennten. beispiel, ich habe zwei C funktionen:
> the problem is, that this per-widget-parameter [slot] should distinct between
> those function arguments that could look similar (on a per widget basis).
> as an example, here are two C functions:
> 
> > void gtk_window_set_title (GtkWindow *window, gchar *title);
> > void gtk_window_set_icon_title (GtkWindow *window, gchar *title);
> 
> > wenn ich nun ein generische eingabe fuer widget specifische parameter
> > bastel, dann wuerde sie ungefaehr so aussehen:
> if i'm going to create a generic input dialog for widget specific parameters
> it would look like this:
> 
> > Widget Name:    | MyWindow      |
> > Title:          | MyWindowTitle |
> > Title:          | MyIconTitle   |
> 
> > und sonst koennte man diese namen halt gut unterscheiden:
> otherwise [having the seperation through slots] the parameters are easily
> to distinguish:
> 
> > 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. 

> i think in general you should have got the idea by now ;)
> so, the new format mainly features oo and GUI builders and as an aside
> it's predestinated to produce (reference) documantation with any grouping
> you might find appropriate.
> i'd like to see a function browser based on this (somewhen in the future)
> just like the DB Browser of the Gimp.
> 
> 
> 
> 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.

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