Re: About dialog API

[Owen Taylor <otaylor redhat com>]

On Thu, 2003-04-10 at 03:01, Matthias Clasen wrote:
> < My main other
> > API comment is that I don't think using 
> > g_param_spec_value_array() for the "array" properties
> > is a good idea. It doesn't work for GUI builders, since
> > a GUI builder has no idea what type the array elements
> > need to be. And it isn't convenient in C either.
> 
> 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.

> > What I might suggest is simply using a newline separated
> > string:
> > 
> >  "author", 
> >  "Anders Carlsson <andersca gnu org>\n"
> >  "Matthias Clasen <maclas gmx de>\n"
> > 
> > Works well from C, works well from language bindings, works well 
> > >from a GUI builder.
> > 
> > What it doesn't allow is a lot of flexibility for adding
> > extra fields of contributor information, but I think string
> > heuristic string parsing should be OK for that.
> 
> I have looked around a bit for other about dialogs, and the KDE api for that
> associates an optional URL (homepage or something), email address and a
> comment
> (area of work or something) with contributors mentioned in the about dialog.
> I guess 
> thats about anything one would ever want to add. So if we can come up with a
> string format
> which allows to 
> 
> a) get this information in
> b) is easily parseable
> c) lets us conveniently ignore some parts (e.g. the URL, since we can't
> depend on gnome_url_show)
> 
> I have nothing against it.
> 
> One proposal would be to say URLs are not needed and  use something like
> 
> "name1 <email1>\n\tcomment1\n"
> "name2 <email2>\n\tcomment2\n"
> "name3 <email3>\n"
> "name4\n\tcomment4\n"
> 
> which has the advantage that it can be directly dumped into the label and
> yield reasonable results.

Sounds basically fine for me: 
 
 - It might be cleaner if the name and comment were separated by a single
   \t rather than a \n\t? Or perhaps tabs aren't a good idea considering
   that you might have a text field in a GUI builder. A ':' might be better.

   "name1 <email>: stuff that name1 did"

 - For URL's, I think it would be perfectly fine to simply auto-linkify
   URLs in the comment in the future if we add some sort of link
   feature. 

   The GNOME Project: http://www.gnome.org

> > I had various minor implementation comments, but I think I'll hold
> > off on those until we get the API basically settled.
> 
> Good. The main API questions I still see are:
> 
> a) do we want to allow "custom tabs", e.g. "Artwork" ? I have made some
> comments about that in the bug.

Hmm. This widget has the potential to grow unbounded in complexity.
gchar *other_contributors_tab_title, gchar **other_contributors
approach does feel awkward to me.

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)

> b) the setters/getters question 

I think I'm tentatively OK omitting the setters/getters. 

> c) do we need to have more app information beyond the generic comment ?
> Examples which have been
> mentioned are bug reporting address, web site.  Of course, this partially
> depends on the implementation question whether we can do something intelligent
> with email addresses and urls (show them as links) without gnome_url_show().

My experience is that auto-linkification works pretty well. You
don't typically need to use @ outside of email addresses, you
don't typically need to use http:// ftp:// out of URLs. The more
we can keep things free-form, the less likely we are to end
up with an unending list of properties to meet different people's
needs.

I might add 

 d) Do we need a language-binding friendly way of accessing the 
    unique per-toplevel dialog? gnome_about_show() isn't going
    to be usable from a language binding, and even the general
    approach doesn't make a lot of sense for a language like
    C++ where you don't have varargs lists.

Regards,
                                                  Owen