Re: breaking libgnomeui API

["Carlos Garnacho" <garnacho tuxerver net>]

Hi anders,

On Wed, 28 Jan 2004 10:12:54 +0100, Anders Carlsson wrote
> On ons, 2004-01-28 at 01:17 +0100, Carlos Garnacho wrote:
> > Hi,
> > 
> > Seeing that the gnome-file-entry, gnome-icon-entry and
> > gnome-pixmap-entry from libgnomeui HEAD still use the GtkFileSelection
> > API, I wrote a patch that replaces it with GtkFileChooser, as seen in
> > the bug #132043, where's the problem? that it "slightly" breaks the API,
> > currently in the public API there is a GtkWidget *fsw that's a reference
> > of the GtkFileSelection, in the patch I've replaced it by a GtkWidget
> > *fcw (the name is the less important issue here, and could be replaced
> > again with *fsw IMHO) that's a reference to the GtkFileChooserDialog.
> > 
> > So the problem is here, the file selection dialog is exposed in the
> > public API, and changing it will break all the programs that access it
> > directly (which is indeed evil), but keeping the old file selector for
> > gnome 2.6 is a little ugly. Should we break in some way the API or leave
> > it as is for 2.6? What do people think about this?
> >
> 
> Hello,
> 
> we can't do this at all. I bet there's lots of code out there that
> expects fsw to be a GtkFileSelector, which means they'll be poking
> around inside that widget; connecting signals, setting sensitivity etc.
> 
> What really should be done is that we should:
> 
> * See what entry widgets that are actually usable
> 
> * Port them over to gtk+ and put them there (IIRC Jim Cape started
> hacking on a really cool icon chooser that supported icon themes)

which will be the estimated gtk+ version which will include these widgets? 
2.6?

> 
> * Deprecate the old libgnomeui widgets and eventually get rid of them
> 
> * Profit!
> 
> So sorry, but changing widgets that I know people rely on being of a
> certain type is a no-no.

Anders, I know the importance of the API compatibility, and if the port to 
gtk+ is going to happen in a short/med term, and if there are replacements 
for these widgets that are being developed, then it's ok for me, but if it 
happens in a longer term then maybe we should create a GnomeFileChooserEntry 
widget that deprecates the otherwise good (IMHO) GnomeFileEntry only because 
of this widget or things like this, which is insane

The other option is to create both GtkFileSelection and GtkFileChooser, but 
we'll be changing anyways the behaviour of the programs that access *fsw 
directly

So this mail was only to collect ideas, I know that the API compat break is 
the wrong way

> 
> Anders


-- 
Carlos Garnacho <garnacho tuxerver net>
                <carlosg gnome org>