Re: [Gnome-print] Gnome-print colors, gradients proposal

[Lauris Kaplinski <lauris ximian com>]

Hello Chema!

On 01 Jun 2001 23:53:56 -0500, Chema Celorio wrote:
> > I will extend gnome-print painter model a bit, and would like to
> > hear your opinion about the following infrastructure:
> 
> I don't think that what gnome-print needs at this point is extending
> the painter model. I feel like we are trying to change too many aspects
> of gnome-print at the same time, too many parts of gnome-print are beeing
> rewriten at the same time. I would suggest that first we finish
> the admin module, make the drivers get their the print job information
> from the GPASettings, allow the postscript backend to set job options
> by importing PPD files and enabling the "Properties" button on the print
> dialog. The gnome-print-admin code was very close to be complete.

Well, I would consider PPD imports much more lower priority than
colorspaces or gradients. 99% of your users do not have PS printer,
but instead some raster-only device, driven through ghostscript.

Why I am rewriting all and every part of gnome-print? Because current
gnome-print is load of crap, put together with duct-tape and debugged 
into existence. The only stylish code was original Raph's one, but it is
completely outdated for out current needs. I have lost countless hours
braincells trying to debug and synchronize different parts of 
gnome-print, that are neither debuggable nor synchronizable.

Well, to be more constructive.
I started by integrating gpa fully with gnome-print. I absolutely refuse
maintaining yet another loosely tided module, that builds into separate
library, because gnome-print is too heterogenous even without that.
Take a look into OpenOffice drawing code, and think, do we want such
future for any gnome library?
Now, lately I started to doubt about some ideas.
It seems to me, that the whole Vendor -> Printer part of equation has to
be removed from gnome-print. Gnome-print should not deal with adding
printers etc. You may want to put that part into XST, as it has to deal
with whatever backends etc. - gnome should not add its own printers,
but USE sytem provided printers - being these printcap entries or
something else. If you add printer, having plain lpr as spooler, you
certainly want to create printcap entry, some more informative xml
file is only extra sugar.
Now it would be useful, to have settings part of equation inside
gnome-print, to have tighter integration and slicker code. But the
thing needed here, is really a 4-fold interface
- loading defaults from printer
- read/write actual to some other place
- read/write individual settings for GUI
- read for actual job/spooler/whatever driver
It is the interface. Not necessarily the real thing, which may
lay inside extrnal library (or many exteranl libraries).
I am loosing point...
Well there a 2 possibilities:
1. gpa as standalone library, external to gnome-print. Gnome-print
may use its interfaces, how exactly internally, is implementation
detail.
Pros - easier to integrate with system, separate maintainership
Cons - there is no such...
2. gpa is fully integrated into gnome-print. What we need here,
are modular drivers for almost everything, as we have to keep in sync
with the real system configuration
Pros - easier to implement
Cons - looser integration with system. There is no such...
OK. Enough of ranting, what to do?
Printers have to be set up by module, that does system abstraction.
So XST?
Bang!
What if user prefers to hand-edit printcap, use QtCUPS or something?
Should we make using XST requirement for using gnome-print?
Or implement system-abstraction layer for gnome-print?
Or force gnome-print users to use CUPS or something similar?
Now, having abstraction layer (or xml printer definitions,
  configuration is realtively straigthforward).
So we can go on, implementing temporary quick-hack for creating
  xml printer definitions
Which happens in gpa
But I am very much concerned about extensibility. This is, why
  I am working on very-very high abstraction for gnome-print side.
So we can actually switch underlying system, without affecting
  gnome-print drivers and application interface.
This is all about tightly integrated gpa/gnome-print (into single
  library + loadable driver etc. modules).
If you think, we can go faster, by picking up your existing gpa
  code, make first move - release it, as separate library. It may
  be possible to pick it up and drop great deal of abstraction, if
  final interface is good enough. I have several concerns about the
  interface, what I am currently working with:
- arbitrary depth option tree
- get rid of GUI hints in options
- module hooks for driver and transport
- way to specify custom gui modules
- ...
uh, oh, I am getting tired. I very much prefer working on imaging
  part.

> Why not use the gnome_print name space as the rest of the library ?

Because gnome_print is too long. I tend to shorten it to gp_ to
a) preserve typing, b) preserve horizontal space, c) have more
readable code d) have readable file names

Best wishes,
Lauris Kaplinski