Re: About dialog API
- From: Owen Taylor <otaylor redhat com>
- To: Matthias Clasen <maclas gmx de>
- Cc: gtk-devel-list gnome org
- Subject: Re: About dialog API
- Date: 09 Apr 2003 22:51:08 -0400
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
> (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"
> 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
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.
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
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.
] [Thread Prev