Re: GNOME CVS: gtk+ matthiasc

Hi Jonathan,

On Wed, 2006-01-25 at 11:01 -0500, 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/ 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.  

Originally, the GtkLinkButton had a _set_uri_hook() similar to the
GtkAboutDialog URL hook; I plan to re-add it to the link button's API.

> 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

AFAIK, GConf pretty much works on win32; but it's the dependencies that
it brings along that are very controversial.  Making GTK depend on ORBit
and libxml2 would also be a killer for embedded environments.

Adding Yet Another Option to XSettings and then create a bridge between
XSettings and GConf like we do for the FileChooser backend and the icon
theme could be a short term solution as you noted, but it really sucks.

> 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?

Short of implementing a small(-ish) configuration source for GTK, I
don't see much more options available.  Jody Goldberg proposed, during a
meeting some weeks ago, a keyfile-based configuration storage for the
printing stuff; it would be very 1991 and reminds me of Windows' INI
files, but could be doable.  Also, GConf could add a backend for this
database and be notified for changes - thus making all GNOME
applications happy too.


Emmanuele Bassi - <ebassi gmail com>

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]