[cairo] UserFontFace vs FtFontFace management (cairomm)

[Jonathon Jongsma]

Ian Britten wrote:
> Jonathon Jongsma wrote:
> 
> Hmmm...  If that's the case, is the interface still open to
> discussion/change?  :)
> 
> As I've start trying to use it, I got wondering if it wouldn't
> make more sense (and be more C++-like) for UserFontFace to be
> an abstract class, with a pure-virtual 'render()' method, and
> virtual 'init()', etc, methods?
> I'm just working through setting up the function pointers, and
> trying to decide where to store my client-data (requiring a
> separate struct, etc), and got thinking that if I could simply
> derive from UserFontFace and carry my extra information in my
> own derived implementation, it would probably simply things.
> 
> Anyways, just some initial thoughts...
> Ian

Yes, the interface is technically still open to change.
Just for reference, my initial implementation was done as an abstract class with virtual 
methods (as you suggest), but I ran into some complications by going that route.  I can't 
remember all the details that caused me to abandon that approach, I believe it was that it 
didn't fit in well with the underlying implementation.  If you implement these callbacks 
as virtual functions, you need to install stubs in the C object that will call your 
virtual functions.  The idea is that you'd install a stub for each callback which would in 
turn call your (possibly no-op default) virtual function.  The problem is that the 
implementation relies on the assumption that some of your callbacks will be NULL.  If I 
recall correctly, there are at least two callbacks that are mutually exclusive, so the 
internal logic is something like:
if (foo_callback != NULL)
   foo_callback();
else if (bar_callback != NULL)
   bar_callback();

So as you can see, if you implement the callbacks as virtual functions and install 
callbacks in the underlying C object that will call your virtual function, you'll never be 
able to call bar_callback(), since foo_callback will always be non-null.  Did that 
explanation make any sense?  My memory is a little bit rusty regarding all of the details 
at the moment, but I know that the user-font implementation is quite C-specific and 
difficult to wrap in a natural way for object-oriented languages.  There may still be ways 
to improve the cairomm UserFont interface though, and I'd appreciate any ideas you may have.

-- 
jonner