[cairo] GObject

[Mike Emmel]

On 1/12/06, Owen Taylor <otaylor at redhat.com> wrote:
> 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.
>

I think it does feel some roles well it just that when you leave the
gnome environment its tough to sell GObject. No big deal I think pango
is a good piece of software I hate that I'm finding myself in a
position where I can't use it but thats life.

Mike

> Regards,
>                                                 Owen
>
>
>