Re: cmon guys, no patch from 1.1.32 to 1.2??
On Tue, 26 Dec 2000 [EMAIL PROTECTED] wrote: Huh? Don't get it. My bandwidth (64K) and time are also limited and still CVS is much faster than ftping and patching. And in addition you get the benefit not having to care about patches and well, your patches to the GIMP are also much easier to create with a CVS tree. You know since you take time to answer my posts, I might as well too. Compared to your "limited" 64k how does 9600 that disconnects every 5 minutes sound to you? And the fact that downloading something like a full gimp 1.2.0 would take close to 2 or 3 hours? And the fact that those 2-3 hours would cost me somewhere in the neighborhood of $5 PLUS telephone charges? Now go think again. I connect a few times a day for a few minutes to check email and get patches to latest stuff, and even downloading a 300k patch is bad enough not to bother with anything over 1mb. Thank you for taking your time to read this. And if you still insist on using CVS that would require me to go to www.gimp.org, find out the CVS server info (that would take as much time as downloading the 1.1.32 to 1.2 patch), and hope that whatever state my gimp tarball is in going to be acceptable for CVS, which is unlikely, so I am probably going to end up spending a couple hours trying to get all the little pieces and redialing in between. Try it sometime. And don't tell me about having to care about my patches. I haven't downloaded full source code to anything in the last 6 months. So I should know what to do with them. And yes, there is a possibility that total size of all patches exceeds the size of the current version patched up from the last one. But, it's spread over a long period of time and is not as noticeable. Having to download full ~8mb of gimp every new version would certainly kill my interest. And even linux kernel people provided a patch from 2.3.99 to 2.4.0-test. This is the only reason I am still able to test 2.4.0 because last time I got a full 2.3.xx tree was long time ago. And my gimp tarball IS out of sync with whatever is out there, because somewhere along the way some people decided to or not to include things like gimp_splash.ppm, there are some brushes I think missing from the gimpressionist plugin, and latest 1.1.31 patch was missing a number of .png images from the help dir, etc. But as long as the code patches clean, I really don't care. I don't read help anyway. So someone who has the time to do so just make a patch and stick it in gimp/unstable or whatever. If someone needs it, they will get it. That would include me, also. tc -- ・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・ timecop at japan.co.jp | ＯＡ通信サビース株式会社 | NTT DoCoMo I thought everything that Linus Torvalds is involved with was divine perfection? Must be a problem with NEC and Sony -about Crusoe recall ・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・
gimp patch 1.1.32-1.2.0
I got off my lazy arse and made a patch. I have no idea whether I did things correctly, I just downloaded the gimp- 1.1.32.tar.bz2 and gimp-1.2.0.tar.bz2 files, unpacked them, did diff -u -r gimp-1.1.32 gimp-1.2.0 gimp-patch, then bzip2'd that. It's 534kb, and you can download it from http://nova.student.utwente.nl/tc/gimp-patch-1.1.32- 1.2.0.bz2 Merry Christmas, Lourens
Re: cmon guys, no patch from 1.1.32 to 1.2??
On 27 Dec, [EMAIL PROTECTED] wrote: You know since you take time to answer my posts, I might as well too. Compared to your "limited" 64k how does 9600 that disconnects every 5 minutes sound to you? And the fact that downloading something like a full gimp 1.2.0 would take close to 2 or 3 hours? And the fact that those 2-3 hours would cost me somewhere in the neighborhood of $5 PLUS telephone charges? Now go think again. You are such a whining moron. Why should I solve YOUR homemade problems? Now go think again -- Servus, Daniel
Re: Pupus pipeline: what Adam has been doing, etc. etc.
Hi Gary, On Sat, Dec 23, 2000 at 02:45:42PM -0500, Garry R. Osgood wrote: How would the "pupus" functionality be directly exposed to users? The answer is that it most assuredly WOULD NOT. I do not advocate, in fact I ABHOR the idea that the user should end up drawing a little tree of boxes connected with wires. That's your view as a programmer I want it! Hey, this is interactive Script-Fu! I agree with Adam. It so happens that the directed graph abstraction which is serving his thinking about scheduling visually coincides with a user interface presentation where upstream branches of layers composite into common result sets. This happens to be two places where the abstract tree data type has taken root in the fecund (if imaginary) soil of Gimp 2.0. Trees happen to furnish a nice framework to think about the shape of a great many tasks, so this coincidence is common (and an ongoing source of confusion). I thought about that tree thing a bit more. We should not opt for trees but for directed graphs only. We are only a very small step away from a visual programming language. For example, a "choice box" would be almost trivial to implement. It lets you chose/route your image(?) data another path "down" the graph. So one could try several variants and subvariants. Such graphs could even be constructed on-tye-fly while working with the GUI (though they would get mazy very fast). If we dedicate the Gimp 2.0 core to nothing other than staging (various kinds of) compositing of result sets from different kinds sources (ideally, not all bit maps), then the user interface simply falls away from view. I agree with that. 2. Some (cache-boxes) are capable of persisting "upstream" image presentation for "downstream" black boxes. Some other component of the application might choose to associate with such cache-boxes the notion of "layer", but that is the business of that more or less external (and, me thinks, user-interface housed) component. To the step manager, it is a step that persists (parts of) images. The caching issue is very important. A seprerate bunch of code with a default caching strategy would probably be useful. 3. Some black boxes (it seems to me) house genetically engineered goats (large ones) that pixel process. As an aside, These GEGL boxes are (hopefully) the only interior places where some sort of physical implementation of pixels matter -- how many bits they have, how those bits relate to color and transparency components, what sort of pixel and pixel area operations are capable of mapping a region in one cache-box to a region in another. To pupus (the step manager) it is just a surface -- it is neither capable of, no interested in, the manipulation of the surface 'fabric.' Ideally, the step manager is a stand-alone library which can be used by other applications as well (think: a synthesizer like app using independent sound processing boxes for sequencer, 303, filters etc.). So what is Gimp 2.0 -- the application -- do? Refreshingly (I think) not much. It configures a step manager of a particular arrangement that makes sense for the profile of requirements that some sort of user interface presents, authenticates that the version of user interface is capable of talking with the version of step manager present, (mumble, mumble, other kinds of sanity/compatibility checks) then steps back and lets the ensemble articulate. [...] It is this view that makes Gimp 2.0 largely a collection of shared object code, each shared object being a thing that a (likely) small group of individuals can dedicate themselves to and get to know particularly well, and there will be less of a need for someone to be knowledgeable about the Whole Massive Thing (as in Gimp 1.x) (the shared object may even be general enough to export to some other application, unchanged). Let's talk about distributed objects! Using this framework, it would be easy to implement a transport mechanism via some high-speed network and interconnect several computers to do heavy scientific/industrial image processing. The "pipelines" connecting the black boxes should be pluggable. What concerns me is this style of thinking places a great deal of importance on coordinating interfaces and internal protocols; this is not a topic upon which UI, scheduling, image-processing, and specialty black-box architects (a kind of Gimp 2.0 third party contributor) should drift too far apart, reinventing wheels that are rolling in other parts. The Monolithic Gimp of 1.x fame, being monolithic, permitted some laxity in the design of internal interfaces; distributing the application over autonomous processes require a little more formality in coordination. I think we should set great store by software engineering in GIMP 2.0! Such a complex system of several almost independent modules needs a great deal of design considerations. I recommend
Re: gimp patch 1.1.32-1.2.0 [Also: Re: cmon guys, no patch from 1.1.32 to 1.2??]
[EMAIL PROTECTED] wrote: I got off my lazy arse and made a patch. I have no idea whether I did things correctly, I just downloaded the gimp- 1.1.32.tar.bz2 and gimp-1.2.0.tar.bz2 files, unpacked them, did diff -u -r gimp-1.1.32 gimp-1.2.0 gimp-patch, then bzip2'd that. It's 534kb, and you can download it from http://nova.student.utwente.nl/tc/gimp-patch-1.1.32- 1.2.0.bz2 Merry Christmas, Lourens Commendable, and in keeping with the spirit of the season. Thank you. Personally, I would strongly urge anyone desiring to support a Gnome or GNU/Linux project to learn about CVS. See http://cvsbook.redbean.com. The tarballs and patch-sets are really meant for end-users who prefer to compile from source, but don't otherwise desire to get involved in maintenance and so don't have a strong motivation to keep a bleeding-edge source tree around. Patch sets are published with this laid-back attitude in mind, They lack the CVS administrative files which is a pity (but then, CVS admin directories don't always transplant themselves effortlessly. They depend on the context of particular users on particular clients using particular CVS servers) After the initial working directory download (which can be painful on a slow, intermittent connection, but not prohibitive -- see below) keeping a working CVS directory current is painless, *especially* if one has a slow or intermittent connection. With CVS update, the server sends patches, not whole files, and per-patch compression somewhat lowers the absolute amount of bits to transfer (Steinar notes this could be better - agreed, but while the compressor could optimize across the entire patch set, it would not be as graceful in recovering if the connection dropped) Should a connection drop, the CVS client and server pickup can pick up where they left off -- check- pointing is an adjunct process to synchronizing a working tree with the repository. In contrast, not all ftp servers support restarting in an analogous way. And as for time, one can set up a cron job to do nightly syncs when one is asleep or otherwise occupied with something else, so it just happens that the tree is updated when you awake or come back to work. (with a little extra cleverness, the job can be written to restart dropped connections). Across the three or four projects I'm interested in, a weekly CVS hookup is generally complete in about fifteen to twenty minutes. (36K modem). Clearly, I could reduce the connect time if I synced nightly (fewer deltas). Apart from that, you have the CVS utilities available to access file update logs, find out who committed what, when and where, and other whatnot (Such information is also avalable from http://cvs.gnome.org/bonsai as well for many gnome projects). Most of all, you are liberated from wondering if a patch set matches a code base, since your CVS working directory and the repository it is associated with have per-file version granularity. See http://www.gimp.org/devel_cvs.html My two U. S. cents Garry
Re: Pupus pipeline: what Adam has been doing, etc. etc.
Tino Schwarze wrote: I recommend looking into David Hodson's Gimpeon at http://www.ozemail.com.au/~hodsond/gimpeon.html he's already figured out how to abstract such a system and I guess we could get at least some nice ideas from his work. Just remember that Gimpeon is intended for automatically processing sequences of images, rather than working on a single image. (It's also very much a work in progress, nowhere near a finished product!) It uses some of the ideas suggested for 2.0, but they're in a slightly different context. (And it's written in C++, which I know some of you won't like - but when I drop back to straight C to work on the Gimp, it's sooo frustrating!) Just to expand a little - Gimpeon is based on film effects work, where the workflow (using the tools I'm most familiar with) is something like this: * get the source image sequences, and make reduced resolution versions of them. (You generally can't work efficiently at full resolution.) * set up the basic processing sequence. This is usually done at low resolution, looking at one frame, but also involves stepping through the sequence (to check animated efects) and switching to full resolution (to check fine detail). * once everything is set, automatically generate the full sequence at low resolution. If this looks OK, generate the full sequence at high resolution. * wait for the effects director to tell you to do it again. (Hah!) Gimpeon appears to use "boxes and lines" as its main UI component, but I'm actually planning to provide a better interface on top of that. The user will always be able to directly edit the processing graph, but they will generate it in the first place by applying filters to images - the graph gets built behind the scenes, much like it would be (perhaps) in the Gimp. Just as an aside - one of the main annoyances I have with GTK is that manually setting a widget value triggers it. This makes doing a clean Model/View/Controller design very messy! -- David Hodson -- [EMAIL PROTECTED] -- this night wounds time
GIMP 1.2.0 and IRIX
On IRIX 6.2 and 6.5 with GIMP 1.2.0: $ gimp /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih" /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih" /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-16.gih" /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-16.gih" /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-32.gih" /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-32.gih" $ ls -ld /opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih -rw-r--r--1 root sys20818 Dec 26 22:32 /opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih The fix is to revert to data/brushes/SketchBrush* from 1.1.32. Any reason the version of these three files in 1.2.0 is different than from 1.1.32? -- albert chin ([EMAIL PROTECTED])
Re: GIMP 1.2.0 and IRIX
On Wed, Dec 27, 2000 at 01:16:26AM -0600, Albert Chin-A-Young wrote: On IRIX 6.2 and 6.5 with GIMP 1.2.0: $ gimp /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih" /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih" /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-16.gih" /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-16.gih" /opt/TWWfsw/gimp12/bin/gimp: Failed to load one of the brushes in the brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-32.gih" /opt/TWWfsw/gimp12/bin/gimp: Warning: Failed to load brush pipe "/opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-32.gih" $ ls -ld /opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih -rw-r--r--1 root sys20818 Dec 26 22:32 /opt/TWWfsw/gimp12/share/gimp/1.2/brushes/SketchBrush-64.gih The fix is to revert to data/brushes/SketchBrush* from 1.1.32. Any reason the version of these three files in 1.2.0 is different than from 1.1.32? Oops, I mean 1.1.30. 1.1.32 has the same SketchBrush* files as in 1.2.0. -- albert chin ([EMAIL PROTECTED])
