Re: ABI and API for g_object_ref_sink() (Re: GTK_FLOATI



>1. a flags field
>2. the floating reference (stored in the flags field, incidentally)
>3. the destroy signal
>4. a user-data property (this one is far surpassed by GObject's
>arbitrary data keys, but is there to ease porting from 1.x)
>5. the compat layer for GtkArgs (which were replaced by GObject
>properties, but that's not so important and will probably be removed
>entirely in 3.x)

Is it worth pushing the floating flag to GObject, pushing the destroy signal 
into GObject, and eliminating the user-data and GtkArgs code all in 3.x? 

If the 32-bit flags field can not move into GObject, GtkObject would simply 
become a holder for this extra 32-bits and would not need any API other than to 
manipulate the bits.

I agree that destroy would be useful in GObject as well, and given the API/ABI 
problems of moving the floating flag into 2.x, should the above be considered as
 a viable option if it was to wait entirely for 3.x?

Andrew Paprocki
Bloomberg LP






[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]