[Xfce4-commits] r17207 - libxfcegui4/trunk/libxfcegui4

Jeff Franks jcfranks at tpg.com.au
Wed Aug 31 11:31:40 CEST 2005

Benedikt Meurer wrote:

>Brian J. Tarricone wrote:
>>>>This looks pretty strange: add() and remove() will act on the internal
>>>>HBox, while all other GtkContainer methods will work on the frame
>>>>itself. Either XfceFramebox should be deprecated completely or we need
>>>>to override all of GtkContainer methods and forward the calls to the
>>>>internal HBox.
>>I wouldn't mind deprecating it in favor of a non-class helper/utility
>>function to create the framebox as we have it now.
>>Otherwise we can just leave it as-is.  The common use case is just to
>>add() something to it and be done with it.  I got rid of the remove()
>>implementation because it was causing weird problems that I don't have
>>the patience to try to debug.
>The implementation as it stands now is just broken. It claims to be a
>GtkContainer, but it isn't. I'd vote to revert that change to the 4.2
>implementation, which wasn't good, but atleast consistent. There's no
>need for XFC to wrap that widget at all, as Gtk::Frame and
>Gtk::Alignment will do just fine there, and thereby saving a few
>unneccesary PLT entries for XFC. ;-)
With all the talk of deprecation what about considering Xfce 5.0 rather 
than 4.4. It would give us the opportuniy to clean out the Xfce4 source 
tree by removing unnecessary widgets and code, without Xfce4 ABI/API 
breakage. We could reduce the number of SVN modules and hence 
distributable packages as well. These are things that have all been 
mentioned before over the past few months but not seriously considered. 
With such a long Xfce release cycle... maybe there's no time like the 


More information about the Xfce4-dev mailing list