[cairo] GObject

[Owen Taylor]

On Wed, 2006-01-11 at 23:26 -0600, Mike Emmel wrote:
> On 1/11/06, Gustavo J. A. M. Carneiro <gjc at inescporto.pt> wrote:
> > Qua, 2006-01-11 às 08:41 -0800, Bill Spitzak escreveu:
> > > It seems that Cairo itself has successfully implemented a large thing
> > > (the cairo_t) without using GObject or any "base" library. I see no
> > > reason that the text layout cannot do the same thing.
> > >
> > > What exactly does GObject provide and why is it so hard to remove from
> > > Pango?
> >
> >   glib + gobject is about 850K + basic data structures.  Most of this is
> > shared between multiple applications.  To use pango you don't even have
> > to use the glib main loop.
> >
> >   Incorporating pango into cairo would mean two text layout
> > implementations -> bad for fixing bugs, bad for memory usage.  You
> > probably can't make pango use the cairo text layout api without breaking
> > pango api.  And pango api cannot be broken, period.  And you don't
> > honestly expect all the apps using pango to start using a new API for no
> > good reason, do you?  I mean, for cairo drawing you get lots of new
> > features relatively to the gdk/x11 drawing, but from pango to cairo text
> > you get nothing in return.  Also, we'd need new language bindings (!)
> > Without gobject reference counting and enums/flags introspection, things
> > become much harder for dynamic languages.
> >
> >   This whole thread is a really bad idea.  I am tired of linux
> > development platform always shifting APIs for mediocre reasons.
> > Stability counts much more than 850K of shared memory.
> >
> 
> Then I would be very surprised if pango fills the role of a companion
> text library for cairo. It will have to be something else  since there
> is a real need for one that can handle some simple cases but also
> complex text layout problems if desired.  Its a shame you feel this
> way I think there are a lot of good things about pango that would be
> useful outside of gtk but 850k of code is not needed to solve this
> problem.

Commenting briefly on this thread:

 - The chance that Pango will be rewritten not to depend on GLib
   and GObject is remote; they are part of the Pango API, so you'd
   have to write some sort of "Pano" and then wrap it with the
   current API.

   Sure, it would have been possible to do Pango C-only along 
   the lines of cairo or fontconfig, and I had some intention 
   of doing that originally... but I found myself constantly 
   reinventing the wheel and wanting this or that or the other from
   GLib. It didn't feel justified at that point to add another
   6 months to the project.

   In addition, by using GObject, Pango language binds much better
   and fits better into the GNOME stack.
   
 - The idea has been floating around this thread that you could
   some how hack off the low-level parts of Pango or maybe
   the fontconfig-backend of Pango, make that part GLib 
   independent and share it between Cairo and Pango.

    Splitting of the low-level parts of Pango: you might be
    able to write a PangoLayout-compatible object that support 
    95% of the Pango API that people actually use; but I doubt 
    you could fully maintain API and ABI compatibility. 
    Plus, using Pango at the low-level is painful. I wouldn't
    wish it on my enemies.

    Splitting off the fontconfig backend of Pango: possible - 
    we wrap Uniscribe on Windows and ATSUI on OS X, we could
    wrap some other library on fontconfig platforms. But
    presumably the desire is a *cross-platform* text rendering
    API to use with cairo.
   
 - If you think the GLib dependency brings in too much weight, then
   well, you should look at what a large fraction (half at least)
   of the GLib binary size is: it's the Unicode tables I added
   when writing Pango...

   My guess is that a mini-GLib with only the parts of GLib 
   and GObject that Pango uses wouldn't be mini at all; while there
   is stuff in GLib that Pango doesn't use (thread abstractions,
   the main loop, for example) it's not the bulk of the library.

In the end, what I wanted to do with Pango was to create an 
capable, easy-to-use, cross-platform text library that integrates
well with the GNOME stack, but can be used in other contexts.
We've achieved that with Pango; I think the vast majority of people 
who need a companion text  library for cairo would do well using 
Pango. Maybe it's not the text library for everyone, but it's 
better to fill some roles well, than all roles badly. 

Regards,
						Owen