Re: About dialog API / extensibility

["Gustavo J. A. M. Carneiro" <gjc inescporto pt>]

A Qui, 2003-05-08 às 19:33, Havoc Pennington escreveu:
> On Thu, May 08, 2003 at 05:51:03PM +0100, Gustavo J. A. M. Carneiro wrote: 
> >   What's the point on making the about dialog take a dozen arguments. 
> > Why not make it extensible instead? 
> 
> Keep in mind that the about dialog is convenience API. Convenience API
> is a hardcoded shortcut built on top of the generic/extensible API (in
> this case GtkDialog is the more generic API - but is itself partially
> convenience API on top of GtkWindow).
> 
> Generally you don't want to make a convenience API as generic as the
> underlying API, because the whole idea of a convenience API is to
> reduce typing by making hardcoded assumptions about what to do.

   Maybe I'm not seeing it as a convenience API.  I see it more as a new
widget, one which is restricted unnecessarily.

> 
> Concretely, there's really no reason you can't build a fully custom
> about dialog from GtkDialog; this widget is just a shortcut if you
> want a prebuilt dialog.
> 
> > Surely you realize how fundamentally flawed this hard-coded dialog
> > is.  You cannot guess every possible field an application author
> > might want to add in the future, and for every new field the library
> > wants to support there will be API incompatibility.
> 
> I don't understand that - the API does allow adding new fields, you 
> can add new properties.

  I'm sorry.  I saw an older message where that didn't seem to be true. 
See my reply to Owen.

> 
> >   One way to make it API/ABI compatible with future releases is to use
> > properties:
> > 	dialog = g_object_new (GTK_TYPE_DIALOG, "authors", authors, "license",
> > "GPL ....", NULL);
> 
> The latest version of the API does use properties, doesn't it?

  Sorry, again.

> 
> >   However, I think that's not enough.  We should make it extensible too,
> > making it accept user-defined information tabs.
> 
> The cost to that (other than just more API) is decreased opacity of
> the widget, which could limit what changes you can make in the future,
> and limit what you can do "automagically" as new properties are added.

  If you say so.  I'm not exactly seeing how adding custom information
tabs can have any impact on existing or future properties...

> 
> I don't think it's clearly wrong to have add_custom_tab() but I don't
> think it's clearly right either, and I don't think it's a disaster
> either way. We're just talking about a convenience API, not a
> fundamental restriction on what you can do.
> 
> Havoc

  Thanks.

-- 
Gustavo João Alves Marques Carneiro
<gjc inescporto pt> <gustavo users sourceforge net>