On Mon, 2006-01-23 at 22:35 -0500, Matthias Clasen wrote: > 2006-01-23 Matthias Clasen <mclasen redhat com> > > Add GtkLinkButton, a port of GnomeHRef. (#314808, Emmanuele Bassi) > > * gtk/gtklinkbutton.h: > * gtk/gtklinkbutton.c: New files. > > * gtk/gtk.h: > * gtk/gtk.symbols: > * gtk/Makefile.am: Glue. > > * gtk/gtkaboutdialog.c: Use GtkLinkButton. Hi Matthias, I really like the fact that we now have GtkLinkButton. It's a neat little widget. I don't like the fact that every instance of every clicked button has to handle the 'clicked' signal itself. We can add a call like gtk_about_dialog_set_url_hook() to the link button to set it globally for all link buttons, but I'd like to do better than that. The user's browser preferences exist in GConf; lets try to get it out of there. We'd traditionally try to do this with gnome_program_init in libgnome. However, we're trying to deprecate those libs precisely because people didn't like adding an additional library just to get desktop support. Here are a couple other approaches we could take here: 1. Make GTK+ depend on GConf PROS: Makes this (and a lot of other similar problems) very easy CONS: Doesn't work with OSX/Windows; likely to be very controversial 2. Push it out to XSettings PROS: Solves this specific problem in the short run. Has the potential to be cross-desktop. CONS: Doesn't really scale in the long run. Also, XSettings is intended for cross-desktop settings, not everything. 3. Add a loadable module to the environment PROS: Lets us push a lot of other configuration in there. We already do it for the file chooser. CONS: Possibly break applications that weren't expecting it. All of these solutions also have the problem that a well-written application will also have to add their own hooks as fallbacks in the case they don't run on a desktop. Any one else have any thoughts here? Thanks, -Jonathan Thanks, -Jonathan
Attachment:
signature.asc
Description: This is a digitally signed message part