Re: Say goodbye to core X fonts

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-04-15 at 18:56, Mark McLoughlin wrote:
> Hi Owen,
> 
> On Tue, 2003-04-15 at 17:59, Owen Taylor wrote:
> 
> > Problems that need to be dealt with, or at least thought
> > about:
> > 
> >  - Existing GTK+ programs have have a library dependency
> >    on libpangox-1.0.so. So, we'll have to provide a dummy
> >    libpangox-1.0.so so that these programs continue
> >    to run.
> > 
> >  - There may be some programs that use the PangoX
> >    backend *directly*. The only case I'm actually aware
> >    of this is the VTE terminal library. There's nothing
> >    much we can do here; once the backend is gone, it's
> >    gone. For VTE, it would actually help to stub out
> >    all the PangoX API functions; that would keep old
> >    versions of VTE starting up as long as they didn't
> >    try to use the PangoX functions. (And VTE won't
> >    use PangoX if Xft is available.)
> 
> 	Are you then effectively saying "although we said we were going to be
> fully ABI compatible we're breaking it now" ?
>
>	I'm not criticising, I'm honestly just curious as to whether or not 
> this breaks previous guarantees about ABI stability ...

It's a good question. My basic feeling is that what we really
are interested in:

 *) A guarantee that application programs that worked with
    older versions of GTK+ keep on working. (With some
    caveats about "non-buggy")

 *) The ability to offer a continually evolving platform
    that offers new features while not breaking compatibility
    with older versions.

To some extent, I'm willing to sacrifice technical ABI 
compatibility to achieve that second goal as long as we don't 
compromise the first goal.

If using PangoX functions directly was a remotely common thing
to do, then removing the PangoX code would be really hard, but
since:
 
 A) On a large percentage of GTK+ installations, using
    PangoX directly would not produce the expected results
    because GTK+ was using Xft

 B) This functionality was effectively abstracted away by
    GTK+.

I think it was pretty clear that using PangoX directly was
a fringe thing to do and people stayed away from it.

It's a fine line here ... I think the pain of the GTK+-2.0
transition indicates that a clean ABI break where we do
parallel installs and parallel compilation environments is
something that we need to avoid as long as possible.

But that's the only way we can provide 100% compatibility 
guarantees, because *any* change can break something that
somebody out there is doing. To keep forward motion, I think
we have to be satisfied with 99% compatibility guarantees.
(And as close to 100% compatibility guarantees as 
possible within stable branches.)

Regards,
                                            Owen