Incorrect xfce_framebox_add() implementation

Brian J. Tarricone bjt23 at
Wed Aug 31 06:27:26 CEST 2005

Hash: SHA1

Jeff Franks wrote:
> Brain,


> xfce_framebox_add() is implementated wrongly, especially for language 
> bindings. For consistency, xfce_framebox_add() should be a static 
> function in xfce_framebox.c that is assigned likewise inside the 
> class_init function:
> container_class->add = xfce_framebox_add;
> As it stands, for language bindings, it creates a naming conflict 
> between the Gtk::Container base class and the Xfce::Framebox class. Can 
> we deprecate it and add a static function to xfce_framebox.c, something 
> like xfce_real_framebox_add(), and add a comment above the deprecation 
> that says use gtk_container_add().
> I can provide a patch if you want.

Yes, I'm well aware of this problem, and I'm not sure why it's a public
function and we just don't all use gtk_container_add().  It's just
Always Been That Way.

Actually, that widget is just constructed weirdly.  It's derived from
GtkFrame, which is a GtkBin, and yet it uses gtk_box_pack_start() to add
something to it, when it's not a GtkBox.  Well, there's a GtkHBox in the
GtkFrame for some reason.  Not sure why we don't just add stuff directly
to the GtkFrame.  I guess maybe for the padding.  I dunno.

Ok, xfce_framebox_add() is marked as deprecated, and gtk_container_add()
and gtk_container_remove() are hooked up properly.

Benny, can you verify that changing instances of GtkType to GType won't
break ABI or anything?  They should just be typedefs to guint32 or
gulong or somesuch, IIRC...

Danny: not sure, but you make have to 'fix' pyxfce.


Version: GnuPG v1.4.2 (GNU/Linux)


More information about the Xfce4-dev mailing list