Date: Tue, 25 Jan 2000 19:17:31 -0500 From: Federico Mena Quintero <federico@xxxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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@xxxxxxxxxxxx "Linux doesn't dictate how I work, I dictate how Linux works." --Eric Crampton
