Re: GNOME CVS: gtk+ matthiasc
- From: Emmanuele Bassi <ebassi gmail com>
- To: gtk-devel-list gnome org
- Subject: Re: GNOME CVS: gtk+ matthiasc
- Date: Wed, 25 Jan 2006 18:21:30 +0100
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/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.
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.
Ciao,
Emmanuele.
--
Emmanuele Bassi - <ebassi gmail com>
Log: http://log.emmanuelebassi.net
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]