Re: GNOME CVS: gtk+ matthiasc

["Brian J. Tarricone" <bjt23 cornell edu>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 1/25/2006 8:01 AM, Jonathan Blandford wrote:
> 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

Please don't consider this approach.  There are many users of GTK who do
not need a large configuration backend, or who use different
configuration mechanisms (like us over at Xfce, for example).

I generally dislike the term "bloat", but this is a fine example of it,
plain and simple.

Most (maybe even all) of the GTK team probably also works on GNOME, but
please recognise that many non-GNOME developers have invested a lot of
time into using GTK for their projects, and don't need or want a GUI
toolkit that tries to cater to the needs of a desktop environment above
all else.

The simpler, flexible -- though less integrated -- solution is to
provide API hooks in GTK for setting external sources for
desktop-related settings, similar to gtk_about_dialog_set_url_hook(),
but more GTK-global.  The core GNOME libraries can set these up on app
initialisation.

So we could have something like:

typedef (*GtkUrlHandlerFunc)(const gchar *url, gpointer user_data);
gtk_set_default_url_handler(const gchar *scheme,
                            GtkUrlHandlerFunc handler,
                            gpointer user_data);

That's incredibly flexible: you can set different handlers for http,
mailto, even something like aim, or a fallback by passing NULL as
scheme.  If GNOME wants to store these settings in gconf, that's fine,
but let GNOME bridge gconf and GTK.  Maybe there are some issues with
this approach, but I'm sure they can be fleshed out and solved given
some thought and some people genuinely interested in doing the right
thing for *all* of GTK's users, and not just the GNOME crowd.

If it's notably better that GTK itself stores these settings, then why
not use a simple keyfile in the user's home directory?  It seems to work
fine for ~/.gtk-bookmarks.  Someone else in the thread mentioned this
would be "very 1991", but what's wrong with that?  Complexity != better.

	-brian


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iD8DBQFD19dM6XyW6VEeAnsRArwXAJ0f9b40H6jVJNSYh0B4gTtgthu10ACfb+SZ
BP4eEPFM6nqUUpeOOoLWqs4=
=ojst
-----END PGP SIGNATURE-----