[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gimp-print-devel
Subject:    [Gimp-print-devel] Oh yeah, Federico's message...
From:       Robert L Krawitz <rlk () alum ! mit ! edu>
Date:       2000-01-27 4:06:49
[Download RAW message or body]

Date: Tue, 25 Jan 2000 19:17:31 -0500
From: Federico Mena Quintero <federico@helixcode.com>
To: gimp-developer@scam.xcf.berkeley.edu
In-reply-to: <20000125210045.R728@cerebro.laendle> (message from Marc Lehmann
	on Tue, 25 Jan 2000 21:00:45 +0100)
Subject: Re: Speaking of additional plug-ins

>  > For the record, I think a plug-in CVS tree independent of Gimp is a good idea.
>  
>  "Let's focus, people!"
[snip]
>  > The issue is: who has the time? Without people, good ideas remain abstract.
>  
>  I have no time, but I would nevertheless devote part of on merges between
>  the two cvs trees. I could also set up a cvs server, but I firmly believe
>  that it should be related to the gimp.org domain, and I would first have
>  to ask my "boss" wether abusing a machine at the university would be ok
>  (this is a space issue).

<delurk>

People should feel free to ask for a CVS account on the cvs.gnome.org
box.  If they have something cool they are working on for the GIMP, we
can certainly give them access, provided they are willing to follow
the standard GNOME CVS etiquette.

As far as the GIMP is concerned, people could maintain their own
experimental plug-ins in little CVS modules and later, when the
plug-in is Done(tm), they could ask a CVS maintainer to physically
move it to the main GIMP module.  Or it could be linked as a virtual
module, which also is a nice solution.  This way you can have branches
for particular plug-ins.

In particular, I would love to see the fantastic Print plug-in on the
GNOME CVS :-)  Of course, that is up to Robert to decide.  If there is
anything the CVS maintainers can do to make Robert's life easier, I'd
love to hear about it.

</delurk>

  Federico

...and my response...

Date: Tue, 25 Jan 2000 20:51:06 -0500
From: Robert L Krawitz <rlk@alum.mit.edu>
To: federico@helixcode.com
CC: gimp-developer@scam.xcf.berkeley.edu
In-reply-to: <200001260017.TAA06941@localhost.localdomain>
	(federico@helixcode.com)
Subject: Re: Speaking of additional plug-ins

   Date: Tue, 25 Jan 2000 19:17:31 -0500
   From: Federico Mena Quintero <federico@helixcode.com>

   In particular, I would love to see the fantastic Print plug-in on the
   GNOME CVS :-)  Of course, that is up to Robert to decide.  If there is
   anything the CVS maintainers can do to make Robert's life easier, I'd
   love to hear about it.

Thank you :-)  Actually, this gives me an opening for a couple of
other thoughts I have kicking around and a bit of soapboxing.  (and
BTW my wife says hi to all my net buddies, and politely inquires when
she can have her husband back :-) )

Actually, Olof put 3.0.3 in the Gimp CVS repository, and I've sent him
3.0.5 (the latest stable version).  At this point, 3.0 belongs with
the Gimp.  3.1 (which is what we're working on over at SourceForge --
we have 5 people signed up, and there are a couple more I'm waiting
for them to create accounts) doesn't.

A quick aside as to why I chose Sourceforge for this: Sourceforge
provides a complete hosting solution.  In addition to a CVS repository
(not just a CVS directory, it's an entire repository for each
project), they provide message forums, mailing lists, shell accounts,
backups, web hosting, a complete secure web-based administration
interface, basically soup to nuts.  I can decide who to accept as a
developer (or project administrator) and not need to worry if that
person's acceptable to the GNOME folks.  I'm still learning about it
(it's a really capable system, and VA is putting serious resources
behind it including what amounts to a help desk!), but we're
attracting a lot of attention in a hurry and I'm recruiting good
developers.  I don't want to split the effort with 3.1.

Basically, 3.0.5 is the last release I'm planning to make on the 3.0
(stable) branch, unless we have serious bugs or VERY low-risk features
from 3.1.  This is the version I'd like to see go into the 1.2 feature
freeze.  It's capable enough so that it will be useful to a lot of
people, while it's also received a decent amount of testing and we at
least know what the problems are with it, by and large.  So I have no
problem putting 3.0.5 in there.

<soapbox>
There are a number of very important changes that we're looking at for
3.2 (i. e. that will be on the 3.1 development line) that will have
important ramifications for its continued existence as a Gimp plugin.
The most important one is that we actually want to rip out the guts
altogether, put them into various Ghostscript and/or CUPS drivers (no
reason we can't do both, maybe with some kind of libprint, although
Ghostscript seems to be very hostile to anything remotely resembling a
decent architecture), and make the Print plugin merely be a glue layer
between the Gimp and the Linux printing system.

We actually have a prototype of the first half of this already --
Henryk Richter converted the Epson piece of the plugin (plus the
rendering engines) into a Ghostscript driver.  It has some residual
problems, mostly related to various static variables, but he reports
that it works just fine otherwise.  This is actually very exciting
news.  Henryk has been entirely too modest about it :-)

We'll release a Ghostscript driver based on 3.0.5 when we have the
static variable issues ironed out, and if that goes well we'll do
another release based on 3.2 (or some other stable intermediate point
if we find that the new Epson printers go well, since that will
probably be a big requirement for a lot of folks, and it's important
to be able to compete with Windows and the Mac on print quality).
</soapbox>

<wayfaroffinthefuture>
So what's basically going to happen is that we'll eventually (I'd like
to say 3.2, but that's not realistic for reasons I'll discuss below)
remove everything but the Postscript driver and the front end (GUI)
from the print plugin, and then that will stabilize.

The limitation here is that Ghostscript/lpd doesn't provide a way to
pass information about a printer's capabilities back to a front end.
Without this, we really don't have a way for the plugin (or for ANY
application print dialog, which is the real point here) to give the
user any reasonable way to set options.  For anything where output
quality matters (and I can't think of too many things where it's more
important than for the Gimp), this is not acceptable.  The Epson
Stylus Photo EX is a very fine printer (and the newer ones are even
better), but there are still some important choices to be made.
1440x720 highest quality output is great, but if you want a quick
proof it's too slow.  If you're using Luminos archival inks, you need
to tune the colors, and so forth.

So unfortunately, I think that the best we'll be able to do in 3.2 is
to have a couple of drivers using the same source base, with different
front ends.  But I want to be careful about tying the whole thing too
tightly to the Gimp, because that won't solve the real problem.  I
suppose if people see really high quality output from the Gimp and
then wonder why they can't get their other applications to do the same
thing they'll start to complain, but I want to be well at work on the
solution by the time this starts.  I suspect that that's going to mean
GNOME and KDE, although I'd like to see something even below that
level.
</wayfaroffinthefuture>

There is a script around to build a Gimp plugin, but it seems to be
targeted at simple single-source-file plugins.  I don't really want to
go through the whole hassle of doing a full fledged configure script
for it, though, because that seems a bit much for something that's
"just" a plugin.  I agree very much with the idea of a separate plugin
tree, though.  The best way to determine if a plugin architecture is
good is if it's really possible to keep the plugins separate from the
source (at least at the source level, if not at the end user level)
and to be able to build new plugins easily, on demand.

Actually, on further thought something that might be useful would be a
way to move useful development snapshots from Sourceforge to the
plugin tree, whether that's on gimp.org or gnome.org (in other words,
do 3.1.x releases to the tree, to allow people to experiment with
different versions).

-- 
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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[prev in list] [next in list] [prev in thread] [next in thread]