Re: About dialog API

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-04-10 at 14:58, Matthias Clasen wrote:
> On Thu, 2003-04-10 at 04:51, Owen Taylor wrote:
> > > 
> > > Maybe we should add typed arrays, so that we can make it a string array.
> > > Isn't there already a bug about adding typed arrays ?
> > 
> > I'm not that crazy about GTK+ API blocking on GObject additions at
> > the moment, I must admit :-)
> > 
> > I would like to see typed arrays in GObject, but there are various
> > implementation details and questions about C marshaling that
> > would most likely make it take quite a while to sort out.
> > 
> 
> Hmm, Owen, it turns out we both know too little about GObject. I looked
> closer and while GValueArray is in fact just an untyped array of
> GValues, GParamSpecValueArray does offer 
> 
> a) typed arrays (by setting element_spec to a ParamSpec describing the
> expected type)
> b) fixed-length arrays (by setting fixed_n_elements to a nonzero value)
> 
> In fact, the code I copied from GnomeAbout already uses a) to inform GUI
> builders about the fact that "authors" is a string array:
> 
> 
> g_object_class_install_property (
>     object_class,
>     PROP_AUTHORS,
>     g_param_spec_value_array (
>         "authors",
>         _("Authors"),
>         _("List of authors of the programs"),
>         g_param_spec_string (
>             "author-entry",
>             _("Author entry"),
>             _("A single author entry"),
>             NULL,
>             G_PARAM_READWRITE),
>         G_PARAM_READWRITE));
> 
> 
> The "author-entry" describes the expected type of the array elements.

This perhaps solves the GUI builder problem, but it doesn't solve
the problem of use from C at all. Creating a GValueArray of strings
looks to be quite painful, in fact.

> [...]
> 
> > One possibility would be to extend the parsing of the contributers list
> > to allow division into sections with section names.
> > 
> > "* Coders\n"
> > "Matthias Clasen\n"
> > "* Artwork\n"
> > "Garrett Lesage\n"
> > 
> > Which you could display in various ways, including notebook tabs.
> > This type of thing could *clearly* get out of hand, but done
> > moderately with caution, I think may be cleaner than extensive
> > amounts of API. (Especially if everything is property based)
> 
> This seriously goes in the direction of an XML api (which I'm sure
> someone is going to propose shortly), and I have to admit that I find
> these abominable and wouldn't want to be responsible for introducing
> them to GTK...

Too late, didn't post soon enough to forestall Jody. :-)

But I think there are shades of gray here. The suggestion above is
certainly heading in the direction of API design that would damn my
programming soul to eternal hellfire. But that doesn't necessarily mean
that it isn't the simplest, easiest and most convenient design in this
particular case.

Regards,
                                            Owen