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



La plume légère, à Fri, Jun 16, 2000 at 04:11:00PM -0400, heure d'inpiration,
Sean Thomas Middleditch écrivait en ces mots:

> > Miguel de Icaza <miguel@helixcode.com> writes: >
> > > I think we need parity of goals here.  My goal is to make GNOME
> > > succeed, to make it ubiquitous, and to make it the best desktop
> > > environment in the world.  So I am doing everything I can to make that
> > > happen.
> > >
> >
> > That's a stupid goal. The goal should be to make free software
> > succeed. GNOME is a means to an end. Don't lose sight of that.

Both goals could be achieved together. When GNOME will be totally integrated
in the GNU system (which would be a way of separate GNU from UNIX, for the
better), the GNOME libraries could become as important as the C library.		

Therefore, my question is, why don't you just reduce the amount of libraries
and merge a couple together.
Every library which was released to due the GNOME project should not especially
be part of a big libgnome; every library could probably be merged in
common libraries depending on its "nature".
Obviously, this "nature" has to be defined.

But for example, libgnome and bonobo could be merged together since they are
non-graphical (GNOME) system libraries. GTK should be kept independent since
it could be used as just an X toolkit, but libgnomeui could include other
things.
Why don't we merge the ORBit libraries together... Is it required to have
libgnorba, liboaf, etc independent of it? Wasn't ORBit designed just for
GNOME..

A good reason for all this is:
[wolfgang:~] ldd /opt/gnome/bin/gnome-terminal 
	libgnorba.so.27 => /opt/gnome/lib/libgnorba.so.27 (0x4001f000)
	libORBitCosNaming.so.0 => /opt/gnome/lib/libORBitCosNaming.so.0 (0x4002b000)
	libORBit.so.0 => /opt/gnome/lib/libORBit.so.0 (0x40034000)
	libIIOP.so.0 => /opt/gnome/lib/libIIOP.so.0 (0x40079000)
	libORBitutil.so.0 => /opt/gnome/lib/libORBitutil.so.0 (0x40088000)
	libpopt.so.0 => /usr/lib/libpopt.so.0 (0x4008b000)
	libgnomeui.so.32 => /opt/gnome/lib/libgnomeui.so.32 (0x40091000)
	libart_lgpl.so.2 => /opt/gnome/lib/libart_lgpl.so.2 (0x40179000)
	libgdk_imlib.so.1 => /opt/gnome/lib/libgdk_imlib.so.1 (0x40189000)
	libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x401b0000)
	libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x401b9000)
	libgtk-1.2.so.0 => /usr/X11R6/lib/libgtk-1.2.so.0 (0x401cf000)
	libgdk-1.2.so.0 => /usr/X11R6/lib/libgdk-1.2.so.0 (0x40310000)
	libgmodule-1.2.so.0 => /usr/X11R6/lib/libgmodule-1.2.so.0 (0x40348000)
	libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4034b000)
	libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40353000)
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4035e000)
	libgnome.so.32 => /opt/gnome/lib/libgnome.so.32 (0x403fb000)
	libgnomesupport.so.0 => /opt/gnome/lib/libgnomesupport.so.0 (0x40413000)
	libesd.so.0 => /usr/lib/libesd.so.0 (0x40419000)
	libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x40422000)
	libm.so.6 => /lib/libm.so.6 (0x40434000)
	libdb.so.3 => /lib/libdb.so.3 (0x40452000)
	libglib-1.2.so.0 => /usr/X11R6/lib/libglib-1.2.so.0 (0x40491000)
	libdl.so.2 => /lib/libdl.so.2 (0x404b6000)
	libzvt.so.2 => /opt/gnome/lib/libzvt.so.2 (0x404ba000)
	libutil.so.1 => /lib/libutil.so.1 (0x404d1000)
	libc.so.6 => /lib/libc.so.6 (0x404d4000)
	libz.so.1 => /usr/lib/libz.so.1 (0x405ba000)
	libasound.so.1 => /usr/lib/libasound.so.1 (0x405ca000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
	
... compared to :
[wolfgang:~] ldd /bin/ls
	libc.so.6 => /lib/libc.so.6 (0x4001f000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
(btw, no, this is not a spam)
	
Main advantage would be clearness (sometimes needed with programmers).

OTOH, the GLIBC itself contains a lot of functions which just have nothing
to do together. For example: strdup and bind, why would it be different
for GNOME?

If GNOME becomes an important part of the system, as I think and hope it will
be, any program could link to its libraries, even for just a the few functions
it needs.

Not to mention that GNOME is about to become platform dependent. So we might
be able, at some point, to get rid of X dependencies and make GNOME a
standalone framework build on top of glibc (and GTK and libjpeg/tiff/any).

The ideal would be to have GTK and GTK only to depend on the implementation
chosen, whether it is X, Berlin, or Y.

Following what I could perceived from some discussions I had with Richard
Stallman, GNOME is definitely the way to go. (The GNU Projects need to be
integrated as much as possible...)		


Wolfgang
-- 
A chicken is an egg's way of producing more eggs.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]