Re: GnomeFont state of affairs
- From: Havoc Pennington <hp redhat com>
- To: Elliot Lee <sopwith redhat com>
- Cc: gnome-devel-list gnome org
- Subject: Re: GnomeFont state of affairs
- Date: 16 Jun 2000 15:25:02 -0400
Elliot Lee <sopwith@redhat.com> writes:
> Given that GNOME provides a lot of the infrastructure that would be useful
> in building this system (for example, it would want to tie in with
> gnome-print,
Which has no real gnome dependency, it may have gratuitous ones such
as dialogs randomly tossed into the same lib with rendering code.
> leverage gnome-vfs for font sharing,
There's no reason to use gnome-vfs that I can think of. You're
stretching. (Plus, gnome-vfs does not depend on libgnome/libgnomeui
in any really meaningful way.)
> and utilize gnome-libs
> miscellanea)
libgnomeui for fonts? libgnome has nothing particularly relevant,
g_alloca() and g_file_exists() are not reasons to add it as a
dependency. popt is available separately if you want that.
If GnomeFont has actual good reasons to use gnome-libs then fine. All
I'm saying is, let's not have gratuitous dependencies, because all
that does is limit your userbase (and thus developer base).
It sounds to me like the only real dependencies are GObject and Pango.
> it's really stupid to reimplement these solutions in the font
> library or do other massive shuffling just to avoid a GNOME dependency.
>
There's no massive shuffling, the thing isn't written yet.
> "Most Linux distributions" will have no problems using a tool that
> installs fonts, whether or not it happens to use GNOME. It's not like a
> KDE program will suddenly be unable to render Type1 fonts just because
> they were installed by a utility that uses (horrors!) gnome-libs.
>
If the library that does all the font stuff links to gnome-libs, no
one but GNOME apps can link to it.
> You may be on an anti-GNOME crusade or whatever, but it seems that
> building on what already exists is the fastest way to a good solution.
> This is, after all, the GNOME project.
>
The fastest way to a good solution is to be useful to a maximum number
of users.
There are a huge number of users (and potential developers) that do
not use gnome-libs for one reason or another. Common reasons include:
ease of installation on non-Linux, portability to Windows, embedded
or kiosk systems with limited disk, ease of training/education, ease
of deployment.
We can sit in our own little corner and say "we don't care about
them," but they are not going to become converted because we have
artificial dependencies.
I am not anti-GNOME, but I do recognize some facts.
Fact #1: you can't force people to install GNOME by introducing
pointless dependencies. We've tried to promote GNOME by e.g. sticking
the canvas in libgnomeui, and it hasn't worked and won't work, because
it was a Dumb Ass Idea. If people can't or would prefer not to install
gnome-libs, they have reasons for that. If we can't offer a solution
they can use, they will just use another toolkit, or they will be
unhappy with their G* solution.
Fact #2: The reason free software succeeds is by maximizing the number
of users. Users == developers and testing. The more users we have the
better. And there are tons of people that would be interested in a
general solution that won't be interested in a solution containing a
gnome-libs dependency.
You can say those people are wrong, but you aren't going to convince
or convert them of that. And so standing on principle here gets you
nowhere, except maybe the same place the FSF finds itself today.
Fact #3: I know many people are worried about KDE stealing technology
if it's gnome-libs-independent. This is a dumb worry to begin with,
but I'm sure they won't link to glib/Pango anyway, so don't worry
about it.
Anyway; UNIX in general needs a good font solution. Personally I'm in
this to help the maximum number of users. I'm against anything that
artificially limits the number of users that can benefit from our
technology.
Let's end the thread here, Lauris is implementing it, he can do what
he wants. This is my .02 though.
Havoc
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]