Re: [Gnome-print] Re: GnomeFont state of affairs

[Lauris Kaplinski <lauris kaplinski com>]

On 16 Jun 2000, Havoc Pennington wrote:

> 
> Lauris Kaplinski <lauris@kaplinski.com> writes: 
> > Now my own reasoning for separate Gnome font API is following:
> > Gnome has some specific needs, which are not covered by low-level
> > API -
> > such as font installing, font sharing in workgroups, font matching between
> > different output devices & so on.
> 
> Can you please try to have only a glib/pango dependency? I see no
> reason you need a GNOME dependency here.

There is no such thing as GNOME dependency ;) The closest thing to that is
dependency on libgnomeui.
At moment, I think the base depends on:
  libttf, libart, libunicode, Gtk+ and cousins
Font installing and font browsing can be well separated into their own
library. As can be done with font server.
On the other hand - the thing, as I see it, is modelled for the current
Gnome display engine. There can well be people, finding both libart and
libunicode to be too Gnome-specific. FreeType2 is itself capable of
filling most general needs - all above that is inherently adjusted to some
special platform IMHO.

> If it has a GNOME dependency, people will have to reimplement a
> generally-useful solution. Most Linux distributions won't be able to
> adopt a GNOME-specific solution for installing fonts, for example.

Font-installing, in my imagination, is done via general font server,
exporting solid font API through CORBA. So even, if Gnome would adopt
specially tailored solution client-side, there is no need for server to be
Gnome specific.
Still, I have kept network tranparency in mind, so I hope non GUI sepcific
part of library can well be used for such server.

> It's OK to have a library on top that actually requires GNOME, for
> stuff like dialogs, but installing fonts etc. should be below the GTK
> layer.
> 
> Probably shouldn't call it GnomeFont either, perhaps GFont with a
> gfont_ prefix for functions, similar to GConf.

Good point. I would like GFont also, because it saves typing :)
But g_ namespace is quite filled already, so I am reluctant to move
anything there before I am absolutely sure, it is done The Right Way and
can really be universal partner of other g_ projects. Just like Gtk object
system is moved to g_ only now, when it is already proven to be excellent.

Regards,
Lauris