We do have to do this eventually to make it easy to write a complete 
app with only gtk. Should not be a lot of work.

Created attachment 15368 [details]
gtkaboutdialog.h

Created attachment 15369 [details]
gtkaboutdialog.c

Another libgnomeui widget coming home...
I decided to name it GtkAboutDialog to stay in sync with the other 
complex dialogs. Open questions:

* do we need setters and getters for all properties ?
* do we want a default image ? If so, which ? gtk-logo-rgb ?

Created attachment 15370 [details] [review]
necessary glue and gtk-demo example

It makes sense to me if the default image is taken from 
gtk_window_set_default_icon_list() perhaps, then perhaps 
fall back to no image at all (does the dialog look OK with no image?
surely we could make it look fine in that case).

Might also consider using g_get_application_name() instead of having to 
pass that in?

Would a "support URL or email" and "bug report URL or email" 
be a good idea? Not that the new() function needs more arguments. ;-)

I guess for GNOME we might want something like "Report bugs 
to your operating system vendor or to the kind volunteers
at http://bugzilla.gnome.org/" I dunno.

I don't think setters/getters are needed, the properties are good
enough IMHO.

I'm somewhat uncomfortable that the _new() function becomes broken if
we add/remove properties, but not sure there's a hugely better way.
everything I can think of has other problems.

Implementation looks pretty sane to me, I was afraid it'd be ancient
gnome-libs 1.0 cruft.

Falling back to g_get_application_name() and
gtk_window_get_default_icon_list () is a good idea. Do you think we
should drop the name argument from _new() completely or just fall back
if it is NULL ?

Adding bug reporting address / website would perhaps be nice, but the
immediate question is how to implement these as links without dragging
in too much gnome infrastructure.

I have looked at how gnumeric does it: they use 
gnome_href_new() for the link and simply add it to 
GTK_DIALOG (about)->vbox.

Another question that occurred to me: Are we comfortable with this
kind of one-shot, self-destructing dialog, or do we leave management
of the dialog lifecycle to the app ?

I have been looking around for complaints which people had about the
GnomeAbout in libgnomeui, and here is what I found:

bug 59632: website/email address for contributors and app
bug 73429: padding for the contributor lists
bug 80468: support custom credit tabs (e.g. "Artwork")
bug 84790: a bugfix for modal about dialogs

Owen suggests having the new() function take no arguments
and the resulting dialog doesn't destroy itself on response signal, 
but then have a convenience function:

 void gtk_about_show (GtkWindow *parent, ... all those args ...)

that would manage an about dialog associated with the given parent 
window (one about dialog per window, rather than a global dialog 
for the whole app).

Here is a new version with the gtk_about_dialog_new () /
gtk_about_dialog_show () split and the fix for bug 84790. I'm
currently contemplating about the other bugs listed above. 

Regarding the custom credit tabs, I think that the approach taken in
the patch attached to bug 80468 is overkill and it would be good
enough to add gchar *other_contributors_tab_title, gchar
**other_contributors
to the argument list of gtk_about_dialog_show(). That would allow to
add one custom tab with content similar to the other tabs.

Regarding email addresses of authors, I'm not sure if the introduction
of a boxed type

struct GtkAboutContributor 
{
  gchar *name;
  gchar *email;
  gchar *website;
  gchar *comment;
}

would be too heavy. With the current approach, we would have to do
something like
author = "Owen Taylor <otaylor@redhat.com>\n  wrote everything"
and rely on string parsing to recover the email address if we later
want to introduce mailto: links.

Created attachment 15582 [details]
new gtkaboutdialog.h

Created attachment 15583 [details]
new gtkaboutdialog.c

Forgot to mention: the latest version also has the fallbacks:


name --> g_get_application_name()


logo --> gtk_window_get_default_icon_list() --> no logo

re. self-destructing dialogs - this is is very difficult for language 
bindings. Whenever GTK+ or libgnomeui dialogs self-destruct we have 
to do very difficult hacky stuff in gtkmm to prevent it. Please don't 
confuse window hiding with underlying destruction of the GTK+ 
instance.

With the current plan, gtk_about_dialog_show() will be
a convenience function not usable from C++ anyways.
So, you'll have to make your own one-per-toplevel convenience
function, that can do whatever it wants for memory
management.

Plus, the planned gtk_about_dialog_show() doesn't return
a widget, so memory management from the language
binding point of view is irrelevant.

(The only self-destruction I can think of in GTK+ 
currently is the default handler for ::delete-event;
so this certainly isn't a general problem... (even
if as always, I think the gtkmm memory management
scheme is highly misguided.))

I have added a dependency on a gobject bug which adds a boxed type for
string arrays. With that, we can avoid the inconvenient GValueArray
for the string list properties and move to a more natural varargs
interface.

After having read the discussion about a too complicated API in
gtk-devel's archive, it seems to me that the things we want to pass to
the dialog can be divided in two: the things which we want to show in
the About itself (name, image, URL, etc) and the credits (authors,
translators, etc).
It has also been raised the point that commercial apps often don't
have credits so detailed.

What I was thinking is that maybe it makes sense to split the API in
the same way:

gtk_about_dialog_new()
gtk_about_dialog_show(name, image, etc) [without the credits button]
gtk_about_dialog_show_with_credits(name, image, etc and a credits
dialog widget)

where the credits dialog can be set up with another utility function as

gtk_about_dialog_credits_dialog_new(authors, translators, etc)

or, if the application writer prefer, can be a custom dialog.

I know I should probably shut up and let the experts work it out, but
since I filed the bug report I couldn't resist... hope it makes some
sense, after all it's saturday morning here ;)

I think the latest plan is to go with a varargs style interface:

gtk_about_dialog_show (GtkWidget *parent, 
                       const gchar *first_property_name,
                       ...)

We could then make the credits secondary dialog optional and simply
omit it if no credits are specified:

gtk_about_dialog_show (myapp, 
                       "name", "MyApp", 
                       "logo", my_logo, 
                       NULL);

vs.

gtk_about_dialog_show (myapp, 
                       "name", "MyApp", 
                       "logo", my_logo, 
                       "authors", authors,
                       NULL);

Created attachment 16032 [details]
gtkaboutdialog.h

Created attachment 16033 [details]
gtkaboutdialog.c

The latest version implements the varargs api. It also adds an
optional credits page for artists, autolinkification for email
addresses and urls , signals "send_email" and "show_url" which are
emitted when the links are activated, and additional "website" and
"website_label" properties, which can be used to put a link on the
about dialog itself. "website_label" defaults to "website". email
addresses and urls are shown as plain text when the corresponding
signals have no handlers connected to them.

Should we use the approach as with 
 gtk_color_selection_set_change_palette_hook() 
rather than signals on the dialog for show_url? don't you 
want the same handler for all dialogs?

Wow, I just saw 
"GtkColorSelectionChangePaletteWithScreenFunc" - that wins some kind 
of length award ;-)

Yes, that is much better. I also renamed the _show() function to
gtk_show_about_dialog(), since it doesn't take an about dialog as
first parameter, as the old name suggested.

Created attachment 16051 [details]
final (?) gtkaboutdialog.h

Created attachment 16052 [details]
final (?) gtkaboutdialog.c

The next version adds a "license" property which is displayed in
another dialog, opened from a "License" button next to the "Credits"
button.
I also enabled Pango markup in the comments property, since it may be
useful to add something in "small print", e.g. a serial number.

Created attachment 16084 [details]
gtkaboutdialog.c

Created attachment 16416 [details]
minimal about dialog, using only defaults

Created attachment 16417 [details]
full about dialog, specifying all optional parameters

Will this land in GTK+ 2.4 soon, in time for the GTK+ feature freeze?

I have not tried to push it. In fact, I've already moved it to the


nascent 2.6 feature set. But feel free to try and get it in 2.4.

I don't want to whine :) but is there a strong reason to delay until 2.6?
Code has been here for a while and the api has been dicussed on
gtk-devel and it looked like everyone agreed that it was ok, beside
it's an utility widget, so it does not look like a big source of bugs
and instabilties...

Don't get me wrong, I respect your decisions whichever they are, it's
only that since the code is ready and nobody seemed to have concerns I
would like to start using it as soon as possible. 

Created attachment 18883 [details]
new version

The latest version implements the links in the credits pages more
properly using tags (code inspired by similar code in gucharmap).

Won't go into 2.4

I've been following the discussion about the proposed schedule for gtk+2.6 which
seems to suggest that it will be used for gnome 2.10: I was wondering if it
would make sense to move this about dialog implementation in libegg and
encourage it's use for gnome 2.8 in order to have wider testing/feedback...

Great work! please take a look at #135684 about if G{gnome,tk}AboutDialog should
set the window icon. 

Created attachment 29327 [details]
new version of the header

A new version of the patch, this time including setters and getters.

Created attachment 29328 [details]
new version of the source

Here is the implementation again, now including docs. I have updated it to the
2.4 api (using G_DEFINE_TYPE, private struct support, g_markup_printf_escape,
etc),
fixed a couple of bugs and added a style property for the link color.

Committed this now.