Re: is gtk_file_chooser_set_extra_widget redundant?

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

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

On 1/23/2006 10:48 AM, Claudio Fontana wrote:
> Hello,
>
> --- Matthias Clasen <matthias clasen gmail com> ha
> scritto: 
>
> > On 1/22/06, Claudio Fontana <sick_soul yahoo it>
> > wrote:
> > > Hello,
> > >
> > > while extending a GtkFileChooserDialog with some
> > > custom widgets using the same hook as with any
> > other
> > > Dialog (->vbox), I noticed that GtkFileChooser
> > offers
> > > a dedicated method
> > > gtk_file_chooser_set_extra_widget().
> > >
> > > I tried using it and shows exactly the same as
> > using
> > > ->vbox.
> > >
> > > Isn't it redundant? What are the differences
> > between
> > > the two ways, and which is preferable?
> > >
> > > Thanks
> > >
> > > Claudio
> > gtk_file_chooser_set_extra_widget() is guaranteed
> > not to break
> > in future gtk releases.
>
> thank you for your answer,
> could you explain a little more why?
>
> vbox is documented as the general way to extend
> dialogs, and the examples use it:
> http://developer.gnome.org/doc/API/2.0/gtk/GtkDialog.html

Correct, but by accessing the vbox member of a file chooser dialog, you
are relying on a specific container hierarchy and placement of widgets
that may change from release to release.

> Why is gtk_file_chooser_set_extra_widget() function
> more guaranteed not to break in the future,

Quite simply because it *is* guaranteed by the API not to break.

> compared to struct GtkDialog?

The struct will not change, of course, as that would break API/ABI
compatibility.  However, as I said above, you cannot rely on the
specific placement and hierarchy of widgets that are inside the vbox.
Say you wanted to add a label above the folder/file list.  You'd have to
read the gtk source to figure out how the widgets are arranged, and use
the gtk_container_* and gtk_bin_* functions to access the child widgets
in a specific way in order to pack your label in the correct place.
This isn't guaranteed to work across gtk versions, as this specific way
may change.

> Is there any plan to make a replacement of GtkDialog,
> and mark current GtkDialog as deprecated?

I would think not.  There's nothing wrong with it.  In the *general*
sense, you can access the ->vbox and ->action_area members of a
GtkDialog.  However, subclasses (such as GtkFileChooserDialog) may
impose further constraints on how you should and shouldn't mess with the
member variables, as is this case.

        -brian

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

iD8DBQFD1Y246XyW6VEeAnsRAlgoAKC4CDe+BB7DonkuHQ4JBKECz8YaMQCg4ay3
8nFtWnZzcl0hLZ80PlhMFU4=
=mAW9
-----END PGP SIGNATURE-----