Re: Say goodbye to core X fonts

[Arnaud Charlet <charlet ACT-Europe FR>]

> I don't see why Xft2 is much worse than the other dependencies of
> GTK+. The minimum requirements of GTK+-2.2 on a legacy system are:

It *is* worse, before it makes it harder to e.g. relocate files (e.g.
configuration files), ...

> This just adds
> 
>  expat/FreeType/fontconfig/libXrender/Xft

which is a real pain. Plus the fact that on systems that do not have Gtk 2,
installing all of this and loading most of these shared libs in memory when
you are using only a single app is a real waste of memory.

> And in fact, even with 2.2, you'd be really advised to install
> expant/FreeType/fontconfig, since many GTK+-2.0 apps (like the
> GIMP) require the FT2 backend explicitely.

I am talking about distributing our own Gtk based applications, which we
control completely.

> I don't think a "standalone" binary of a GTK+ has been reasonable
> since 2.0 came out. While with --with-include-* it is *possible*

That's unfortunately close to be true. However, we managed to have a
configuration with an executable, plus the gtk dlls, and nothing else,
which is pretty good and relatively easy to handle.

> to make a totally statically linked copy of a GTK+, it takes
> an expert and is 200% harder than simply compiling GTK+ and
> all its dependencies.

That's not such an issue as long as there *some* way to make it work, since we
have our experts and they know how to handle these. Now adding Xft makes the
200% becomes 500%, and that's what worries me.

> Plus, a "standalone" GTK+ app binary is likely to violate the LGPL.

Not if you are still distributing shared libraries.

Anyway this is irrelevant to the discussion, since our applications
are full GPL apps, so linking statically is still an option for us.

> Maybe we need to come up with some standard way of installing
> the 4 GTK+ libraries and 10 dependency libraries in a "legacy" system
> in a self-contained way.
> 
> E.g., you run your program as:
> 
>  /opt/gtk2.2/bin/gtkwrap my-binary
> 
> And /opt/gtk2.2/bin/gtkwrap sets all the necessary environment variables
> to point 'my-binary' at /opt/gtk2.2.

That's be useful. We do have some scripts and a few local changees to pango/gtk
to make this easier. I was planning to submit these changes, but got stopped
because one of these changes concers the pango X back end which is no longer
maintained... Anyway, I'll submit my other changes (e.g. remove the requirement
of a gtk.immodules file) via bugzilla.

> A lot of linux systems aren't going to have Xft2, yes, if that's
> what you mean by "broken".

No, by broken I meant a non functioning (e.g. early Xft1) version.

Arno

> If we don't get around to these features, then we might as well keep
> pango-1.2 (and even pango-1.0) compatibility, since the pango-x specific
> rendering code in GTK+ is tiny, but if we do add features, then we have
> to require a new version of Pango.
> 
> Regards,
>                                             Owen
>