[cairo] UserFontFace vs FtFontFace management (cairomm)

[Murray Cumming]

On Mon, 2008-12-08 at 09:11 -0600, Jonathon Jongsma wrote:
> Murray Cumming wrote:
> > I'd like to see that patch, though I hope it's not necessary.
> > 
> > I guess that you are using a separate refcount and a single cairo
> > reference, much like this attempt to make Glib::RefPtr more generically
> > useful:
> > http://bugzilla.gnome.org/show_bug.cgi?id=104332
> > 
> 
> Actually, the concept is much simpler -- RefPtr no longer has any reference count. 
> There's basically two parts to the change.
> 
> RefPtr:
> RefPtr<T> would no longer have any direct role in deleting the C++ wrapper object. It only 
> calls T::reference() on copying (which should result in cairo_*_reference() being called), 
> and T::unreference() on destruction (which should result in a call to cairo_*_destroy()).
> 
> Wrapped Objects:
> In order for the previous RefPtr changes to work, the wrapper classes must be changed 
> slightly.  When a wrapper object is constructed, it must install itself in the user_data 
> of the underlying object.  Then when the C object's reference count reaches zero, the 
> registered user_data destroy function will be called, which will result in the wrapper 
> object being deleted.  This allows the wrapper function to live on after our last RefPtr 
> has died if there is an internal reference held on the object somewhere.

That sounds useful now that we are using sigc callback slots, which
would otherwise be disconnected when the instance is deleted. For now we
should probably document that those slots will only be valid as long as
the C++ instance is alive.

I'm a little scared by all the cleverness that we might need to add to
allow various things to be destroyed in various sequences in various
ways, but this should at least be simpler than it was for gtkmm. This
should be in bugzilla at least.

We'd need some way to make the new code work with old versions of the
RefPtr that are compiled into already-built applications.

Alternatively, we could wait for the gtkmm ABI break that will be forced
upon us by GTK+ 3.0, if that actually happens as they plan.



-- 
murrayc at murrayc.com
www.murrayc.com
www.openismus.com