Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)
- From: Lauris Kaplinski <lauris ariman ee>
- To: Robert L Krawitz <rlk alum mit edu>
- cc: gimp-print-devel lists sourceforge net, gnome-print helixcode com
- Subject: Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print (fwd)
- Date: Sun, 21 May 2000 03:17:47 +0200 (CEST)
On Fri, 19 May 2000, Robert L Krawitz wrote:
> Date: Sat, 20 May 2000 03:06:56 +0200 (CEST)
> From: Lauris Kaplinski <lauris@ariman.ee>
>
> There is no such thing as GNOME dependency (aside packages :).
>
> Which you really shouldn't brush off like that. It's quite a lot of
> stuff. My /opt/gnome (October) is 80 MB, and what looks like about 50
> packages.
Mos of which are programs. gnome-libs package from Red Hat 6.1 is less
than megabyte. To /usr/lib it installs less than 1.8MB of files.
Aside standard stuff (X etc.) it requires esd, gnome-audio, xpm, jpeg and
png libraries. Not very much.
Also, for much users it is much easier to have one big dependency
(libgnome) than many small ones (From where can you find separate libart
SUSE package, for example?).
Not having GNOME is all about not having desktop components installed
(panel, filemanager etc.)
>
> There are
> dependencies to several different free libraries, which happen to be
> distributed as a part of GNOME. And some libraries has every program to
> use, if it does not want to reimplement all things under the sun...
>
> Fine, and what do THOSE libraries depend on? glib is actually
> reasonably self contained; most of the others depend on a lot of other
> stuff. Now we start to get into DLL hell.
>
> Once gnome-print stabilizes enough, it would be meaningful to
> separate it into GUI and backend parts. GUI part needs and will
> always be needing libgnomeui for print-preview canvas, dialogs etc.
> Non-gui base requirements are only Gtk+ (object system) and libart
> (drawing primitives). Not very much, I think...
>
> There's nothing wrong with the GUI stuff (and the printing API for
> GNOME programs) requiring the GNOME libraries. That's completely
> appropriate. It's the back end stuff that really needs to be done
> completely independently of any UI toolkit, desktop, etc.
>
> Still I think that in near future libgnomeui is installed in most
> computers, so this is no-issue.
>
> Sorry, I don't buy it. KDE users won't do it, nor will Motif users,
> nor will CDE users. Nor, for that matter, will servers. Servers
> won't even have X installed on them. If they need to be running X in
> order to handle printing, then we're just implementing Windows all
> over again, where the GUI permeates everything (and destabilizes and
> bloats it). The back end printing system *had better* be completely
> independent of any particular UI choices (or lack thereof).
Well - at moment, to do advanced C based OO programming, most people use
Gtk+, thus creating implicit dependency in X libraries installed. But this
does not mean, that X has to be RUNNING.
Hopefully Gtk+ type system will be moved to glib - and similarly probably
some parts of gnome libs will be done X agnostic. But until then I can see
nothing wrong writing server programs with Gtk+.
> It bothers me that a lot of the GNOME stuff seems to assume that GNOME
> will be universal, and that requiring a lot of the GNOME subsystems to
> be installed is perfectly OK. That isn't how it works in the real
> world. If you want to do a generic UNIX printing facility, you need
> to completely give up on the idea of GNOME being part of it.
No. We do not assume everyone running panel etc. But is is completely
reasonable to use the best free renderer - libart - for rasterizing, and
the best display engine - GnomeCanvas - for print previews. You can have
both, without other Gnome, but usually it is much simpler to have full
libgnomeui package installed, instead of figuring out, how to set these
libraries up separately.
> I'm going to suggest -- pro forma, at least -- that gnome-print
> concentrate on providing a seamless UI and a good printing API for all
> GNOME applications. The caanvas idea sounds great for that purpose --
> it provides an abstract imaging model that any GNOME-enabled
> application can use to render for any device. Where I think you're
> overreaching is in going after the back end.
The one goal of Gnome is to provide good set of support libraries for
programming. At moment sending PS commands to filedescriptor does not
help people creating neither cute print previews (no alpha) nor export to
bitmaps (same reason). Rendering job in client-side is reasonable for
bitmap applications (GIMP), but huge overkill for all vector/text based
apps. And until some free PS renderer is created, using libart or similar
techinque, the best possible solution for these is certainly hybrid
system, like gnome-print is now. It lets you use any spooling and
rasterizing engine, while preserving client-side consisteness and
extensibility, which is lost with plain PostScript.
Regards,
Lauris
>
> --
> Robert Krawitz <rlk@alum.mit.edu> http://www.tiac.net/users/rlk/
>
> Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
> Member of the League for Programming Freedom -- mail lpf@uunet.uu.net
> Project lead for The Gimp Print -- http://gimp-print.sourceforge.net
>
> "Linux doesn't dictate how I work, I dictate how Linux works."
> --Eric Crampton
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]