Robert L Krawitz <[EMAIL PROTECTED]> writes:

> Just to make it clear: the reason we don't use Glib in the core is
> that it isn't part of the standard load on a lot of platforms (in
> particular, OS X).  We've had enough issues on OS X with Ghostscript,
> which is *necessary* (there's no workaround whatsoever) in a lot of
> cases; OS X users want a single binary blob.  We've made a conscious
> choice that we're going to play as well as possible with the working
> methods of OS X users.  OS X users are already suspicious enough of
> the UNIX core (command line geeks) and don't want to be reminded of
> the fact.  They see their computers as appliances.

I really don't want to get into an argument with you but glib-2.0 (or
rather 2.2 and soon 2.4) works just fine on MacOS X, is easy to
install through fink or darwinports and it would help you to avoid a
good deal of code duplication.

> I tried a while back to install Gnumeric on my SuSE 8.1 (not even 18
> months old) systems, and it was a horrible mess indeed.  I had to
> install more or less the entire GNOME stack, and that caused other
> problems with older Gnome 2 stuff in SuSE.

gnumeric is a GNOME application. Of course it needs a full GNOME
stack. We are talking about glib here, which has no dependencies.

> If the problem's with the Print plugin or libgimpprintui, we can
> obviously afford to use Glib 1.2 (there are lots of GIMP 1.2 users
> out there, and I don't want to break them).

glib-1.2 doesn't have the functionality you need in order to handle
the problem this thread started about. Besides that, it is not any
longer maintained and it is missing support for Unicode and UTF-8 and
you can hardly get away without that nowadays.

Gimp-developer mailing list

Reply via email to