Re: [Gimp-developer] Support for doing image preprocessing using Gimp library functions?
Hi, Miles Lane [EMAIL PROTECTED] writes: We'd like to add support for doing some color preprocessing for Gnome 2.0 GTK pixmap themes. We'd like to not reinvent the wheel and am hoping that we could use Gimp library functions to do the processing work. Is this currently supported? If not, would it be a lot of work to add support? that functionality is in the GIMP core, not in a library. So if you'd want to use it, you'd have to start a Gimp process to do the work. It wouldn't be hard to control the GIMP application from the theme capplet but I doubt that starting a GIMP session is what you want to do. Our plans for GIMP-2.0 aren't nailed down yet but we have a design change planned that would allow to do what you suggest. You probably don't want to wait for GIMP-2.0 though. How this would work, from a user's perspective, is that a new GTK theme capplet would include UI for specifying and previewing saturation/brightness/contrast and hue shifts for the images specified in the pixmap theme. Then, when a user's theme is loaded the images would get massaged and the resulting shifted images get cached and used for display. If adjusting saturation/brightness/contrast and hue is all you want, I'd suggest to just do it in place. You will end up writing more code to interface with another application or library then if you'd just insert the few lines needed to do localized color-correction. BTW, you can adjust saturation of GdkPixbufs using the function gdk_pixbuf_saturate_and_pixelate() which is part of GTK+-2.0. Other color corrections could be coded in a similar way. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] test this howto now
On Sun, 20 Jan 2002, Rebecca J. Walter wrote: Please everyone test this how to and see if it is lacking anything. It is intended to be a beginner tutorial for compiling gimp 1.2 from CVS. [...] http://carol.gimp.org/gimp/howtos/cvs/cvs.html Some parts of the tutorial are Linux-centric or bash-centric and should probably be changed to support more UNIX-like operating systems. Even if most developers will probably use Linux, we should not exclude the others in this howto. Otherwise it will be hard to get contributions for other platforms. Here are some examples: : The second step is to see if you have CVS packages installed. : Type whereis cvs. If a path to a bin directory (like /usr/bin/cvs) appears, : you are ready to go. If not, you will need to follow your distributions : instructions and install it. The command 'whereis cvs' is not available everywhere, or does not always give the expected results. For example, on my Solaris machine, typing whereis cvs prints cvs: and nothing else (which means that the command /usr/ucb/whereis cannot find cvs). On the other hand, if I type which cvs, then it shows me the full path. It would be better to replace this sentence by: Type whereis cvs, type -p cvs or which cvs depending on your shell. In the Compiling section, there is another example using whereis aclocal. This should also be changed. : * diff -pu : p adds the name of the changed function to the generated diff. This is a : matter of taste, as it helps mostly when reading diffs. u makes the patches : in unified diff format, which is widely considered both the most readable : and the most robust patch format, however it doesn't work with old versions : of cvs on HPUX and other old UNIX machines, diff -c should be used instead. If I am not mistaken, the diff option in cvs passes the parameters to the command-line diff program. The -p option is an extension of GNU diffutils that is not available in the standard diff found on many UNIX systems. So this is not only a problem for HP-UX or any old systems, but also for the latest versions of Solaris, IRIX, AIX and others. I would change the last part of this paragraph as follows: [...], however the options -p and -u are non-standard extensions of the diff command that are not supported by all versions of diff, especially on systems other than Linux. If your system does not understand -u, you should use diff -c instead. : Updating : : Later, when you want to refresh your versions, go into the cvs directory : and type cvs up. To refresh just one module, go into the subdirectory for : that module and enter cvs up. As simple as that. Although cvs up is easier to type, cvs update is probably easier to remember for first-time users. It would be better to mention the full name of the command at least once. For example: [...] and type cvs update (or the shorter version cvs up) In the Compiling section, there are several examples showing how to set environment variables with 'export VAR=value', followed by: : If you use another shell, you will have to find out the appropriate : syntax (or switch to bash). Those who use (and prefer) a different shell will probably think that this sentence is a bit arrogant. It would be much better to give some examples of the syntax supported by the other shells. As far as I know, all Bourne-based shells such as sh, bash, zsh and ash use the export syntax (but some of them require two commands, one for the = and one for export) so the only other syntax that needs to be explained is the setenv syntax used by all csh-based shells such as tcsh. The explanations can be repeated using setenv, or the last sentence could be replaced by something like the following: If you use another shell, you may have to use a different syntax than 'export VAR=value'. For csh and tcsh, you should use the syntax 'setenv VAR value' (note: there is no = sign between the variable and its value). The second step (2. Not it is time to compile. [...]) suggest to run ./autogen.sh without using any options. It would be good to explain at least the usage of the --prefix option. The 4th step mentions that the GIMP will be installed in /usr/local, but the user has not been told about that until then. It would be better to add some comments earlier, saying that: - autogen.sh will pass its arguments to configure - the --prefix option can be used to install the GIMP in a different directory than the default /usr/local/. This makes it possible to have several versions of the GIMP installed on the same system. - the --help option will give a full list of the available options Finally, step 4 tells the user to try make and make install. If the user has been running all commands from his (hopefully) non-root account, it is likely that make install will fail because the user is not allowed to write in /usr/local or whatever $PREFIX she has chosen. So the user should be told to type make, then su and then
Re: [Gimp-developer] test this howto now
Hi, Raphael Quinet [EMAIL PROTECTED] writes: The command 'whereis cvs' is not available everywhere, or does not always give the expected results. For example, on my Solaris machine, typing whereis cvs prints cvs: and nothing else (which means that the command /usr/ucb/whereis cannot find cvs). On the other hand, if I type which cvs, then it shows me the full path. It would be better to replace this sentence by: Type whereis cvs, type -p cvs or which cvs depending on your shell. I believe 'which' is more commonly available. However the easiest way to find out if cvs is properly installed is to type 'cvs'. You'll either get cvs: command not found or usage information from cvs. In the Compiling section, there is another example using whereis aclocal. This should also be changed. this could be changed in a similar way. Actually one should probably expect the user to have at least a little experience using command-line tools. Otherwise she'll be lost anyway. : Later, when you want to refresh your versions, go into the cvs directory : and type cvs up. To refresh just one module, go into the subdirectory for : that module and enter cvs up. As simple as that. Although cvs up is easier to type, cvs update is probably easier to remember for first-time users. It would be better to mention the full name of the command at least once. For example: [...] and type cvs update (or the shorter version cvs up) I'd suggest to stay with the full commands. The abbreviated forms are somewhat confusing. Think of 'cvs co'. No, it doesn't mean 'cvs commit'. Also, I think the tutorial should list all requirements such as glib-1.2, gtk+-1.2 and probably also libpng, libjpeg etc. in one nicely formatted list before it goes to the Compiling step. It would be wise to also mention that all these libraries need to be installed with headers. On most distributions only the libraries are installed by default and the respective developer packages need to be installed separately. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Raphael's edits, was Re: test this howto now
Hi Carol, Carol Spears [EMAIL PROTECTED] writes: but while all of these different shell commands are being added to the how-to, maybe we should make a how to compile the gimp tar-ball for people who are having problems with their distributions GIMP or supporting libraries. ack. The Compile The GIMP from CVS HOWTO should refer to the Compile The GIMP from source HOWTO and focus on the possible pitfalls that compiling from CVS adds (cvs, aclocal, autoconf, automake). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimpcon2
On Mon, 21 Jan 2002, Rebecca J. Walter wrote: On Mon, 2002-01-21 at 05:53, syngin wrote: Would it not be a better idea to figure out the country of origin for those attending and place the convention closest to the majority? No.. because then we'd be in Germany again. Yosh wants to go somewhere different. Well, another choice could be Belgium, which is not too far away from Germany (maybe too close for Yosh?). This could be done in Brussels before, after or during the FOSDEM - see http://www.fosdem.org/ -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: gimpcon2
On 2002-01-21 at 1913.49 +0100, Raphael Quinet typed this mail: Hmmm... I'd be on the side of simon and drc. From my point of view, I would like to have a good internet connection in a nice non-smoking room and make sure that the place has an equally nice non-smoking closet for those who insist on keeping bad habits... ;-) ducks i cannot be put in a closet with mitch, syngin and Sven. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Raphael's edits, was Re: test this howto now
On 2002-01-21 at 1033.24 -0800, syngin typed this mail: On 21 Jan 2002 19:20:13 +0100 Sven Neumann [EMAIL PROTECTED] sent: Hi Carol, Carol Spears [EMAIL PROTECTED] writes: but while all of these different shell commands are being added to the how-to, maybe we should make a how to compile the gimp tar-ball for people who are having problems with their distributions GIMP or supporting libraries. ack. The Compile The GIMP from CVS HOWTO should refer to the Compile The GIMP from source HOWTO and focus on the possible pitfalls that compiling from CVS adds (cvs, aclocal, autoconf, automake). Salut, Sven I'd be happy to write a HOWTO compile a package from source, specifically The GIMP if no-one else will do it. syngin, can we make a date and write this how to together? i just have a feeling that i can fake it like that first time again better than you. i have some ideas about what should go into it. we can write gimp-howto-build-stable-tarball together, assume it is being used by a person who has never compiled a package before. step through compiling one library as an example (i say png since some distro or another had trouble with this lately and also png is so pc). make them read the freakin first paragraph of man ldconfig. and talk about why you choose /usr or /usr/local as a destination for The GIMP and what the pitfalls of each decision might be. when is a good time for you? we can build it and write it together, maybe? carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Raphael's edits, was Re: test this howto now
On Mon, 21 Jan 2002 13:43:51 -0500 Carol Spears [EMAIL PROTECTED] sent: syngin, can we make a date and write this how to together? i just have a feeling that i can fake it like that first time again better than you. i have some ideas about what should go into it. we can write gimp-howto-build-stable-tarball together, assume it is being used by a person who has never compiled a package before. step through compiling one library as an example (i say png since some distro or another had trouble with this lately and also png is so pc). make them read the freakin first paragraph of man ldconfig. and talk about why you choose /usr or /usr/local as a destination for The GIMP and what the pitfalls of each decision might be. when is a good time for you? we can build it and write it together, maybe? carol Anytime (like now) is fine. -- http://syngin.homelinux.org mailto: syngin at gimp.org http://syngin.gimp.no mailto: syngin at gimp.no UNIX gives you enough rope to shoot yourself in the foot ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimpcon2
On Mon, Jan 21, 2002 at 07:57:01PM +0100, Sven Neumann wrote: Hi, Raphael Quinet [EMAIL PROTECTED] writes: On Mon, 21 Jan 2002, Rebecca J. Walter wrote: On Mon, 2002-01-21 at 05:53, syngin wrote: Would it not be a better idea to figure out the country of origin for those attending and place the convention closest to the majority? No.. because then we'd be in Germany again. Yosh wants to go somewhere different. Well, another choice could be Belgium, which is not too far away from Germany (maybe too close for Yosh?). This could be done in Brussels before, after or during the FOSDEM - see http://www.fosdem.org/ I wouldn't mind going to Brussels but February 16 17 sounds a bit too close. At least me would have trouble to make it there. Yeah, I agree.. Feb is a bit too close for enough planning and travel arrangements. I think a June timeframe would be more reasonable, so people may have trouble getting time off for GUADEC and gimpcon if the two are close together. Norway sounds pretty cool, but I'm not opposed to Brussels. -Yosh ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Raphael's edits, was Re: test this howto now
On 21 Jan 2002, at 13:32, Carol Spears wrote: On 2002-01-21 at 1920.13 +0100, Sven Neumann typed this mail: ack. The Compile The GIMP from CVS HOWTO should refer to the Compile The GIMP from source HOWTO and focus on the possible pitfalls that compiling from CVS adds (cvs, aclocal, autoconf, automake). hmm. gimp-howtos-build-stable-tarball gimp-howtos-build-stable-cvs gimp-howtos-build-unstable-tarball gimp-howtos-build-unstable-cvs do you ack at this? Aren't gimp-howtos-build-unstable-tarball and gimp-howtos-build- unstable-cvs just: Pester Sven or Mitch until you find out what they broke last night and how to route around that.? ;-) Anyhow, that brings me to one thing: perhaps the current CVS-howto should have links to other, more generic compilation-, shell- and CVS- howtos. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] test this howto now
Hi, Nathan C Summers [EMAIL PROTECTED] writes: We have to be a little careful here, as in the off chance that configure.in is written correctly and everything works right :) aclocal doesn't say anything. That could confuse beginners. (I type aclocal and it didn't do anything!) that would only happen if the user tried running aclocal in a directory that has a working configure.in. But you're right, probably using 'cvs --help' and 'aclocal --help' would be a better choice. While I do think that we should assume the reader is familiar with compiling the GIMP to some extent, we should also realize that they may never have dealt with auto* other than typing ./configure. this is the whole point of a compile-from-cvs howto as it will only in this regard defer from the compile-from-tarball howto. The autofoo tools are rather tricky and it is not obvious how to get everything right. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Raphael's edits, was Re: test this howto now
Hi, Branko Collin [EMAIL PROTECTED] writes: On 21 Jan 2002, at 13:32, Carol Spears wrote: On 2002-01-21 at 1920.13 +0100, Sven Neumann typed this mail: ack. The Compile The GIMP from CVS HOWTO should refer to the Compile The GIMP from source HOWTO and focus on the possible pitfalls that compiling from CVS adds (cvs, aclocal, autoconf, automake). hmm. gimp-howtos-build-stable-tarball gimp-howtos-build-stable-cvs gimp-howtos-build-unstable-tarball gimp-howtos-build-unstable-cvs do you ack at this? Aren't gimp-howtos-build-unstable-tarball and gimp-howtos-build- unstable-cvs just: Pester Sven or Mitch until you find out what they broke last night and how to route around that.? ;-) I guess you are joking but I want to state this nevertheless: The version from CVS should always build and indeed it does so almost all of the time. If someone has trouble to build we ask you to pester whoever might have broken the build (check the ChangeLog!). If there's an obvious fix and you have CVS write access, please go ahead and commit the change without waiting for approval. We can always do the right fix later if yours turned out to be wrong. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Raphael's edits, was Re: test this howto now
A good Compiling the GIMP from a Tarball HOW-TO seems like a really good idea. I think this outline covers the main points, but certainly could use some rearranging. I hereby offer it up for tweaks and adjustments. How to Compile GIMP from a Tarball: a tentative outline 1. Introduction 1.1 What's a Tarball? 1.2 Why do I want to compile GIMP? 2. Getting the Tarball 2.1 Where's the briar patch? (Where to put the gimp-x.y.tgz file) 2.2 Saving the source (source directory tree) 3. Do I have the right libraries? 3.1 List of required stuff here (with how to get it). This is starting to look recursive, no? 4. ./configure and what it means. 4.1 What's this --prefix= that they keep yammering about? 4.2 Differences between /usr and /usr/local, and why some stuff goes in one place and some stuff goes in the other. 5. Why a new GIMP won't play well with an old GIMP and what to do about it. 5.1 Library version conflicts 5.2 Include paths 5.3 Library paths 5.4 ldconfig, LD_LIBRARY_PATH, and other arcana 5.5 Removing an old version of GIMP - how do I do this? 6. Compiling on various systems: /* Maybe this should come much earlier */ 6.1 Linux and its flavors 6.1.1 Red Hat 6.1.2 Debian 6.1.3 Mandrake 6.1.4 Slackware 6.1.5 etc, etc, ad lib. 6.2 Solaris 6.3 HP-UX 6.4 Other Unices 6.5 Windows 6.6 Mac? 7. Problems and troubleshooting We need to collect at least the most common problems here and provide solutions. Comments welcome, -- --Jeff Jeff Trefftzs [EMAIL PROTECTED] http://www.tcsn.net/trefftzsHome Page http://gug.sunsite.dk/gallery.php?artist=68 Gimp Gallery http://trefftzs.topcities.com/home.html Photo galleries ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Raphael's edits, was Re: test this howtonow
I guess you are joking but I want to state this nevertheless: The version from CVS should always build and indeed it does so almost all of the time. If someone has trouble to build we ask you to pester whoever might have broken the build (check the ChangeLog!). If there's an obvious fix and you have CVS write access, please go ahead and commit the change without waiting for approval. We can always do the right fix later if yours turned out to be wrong. bex has been known to break CVS. just so everyone remembers that. just don't expect me to fix it if i break it. :-) but i actually compile now so that shouldn't be a problem. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Raphael's edits, was Re: test this howto now
On Mon, Jan 21, 2002 at 12:16:44PM -0800, Jeff Trefftzs wrote: A good Compiling the GIMP from a Tarball HOW-TO seems like a really good idea. I think this outline covers the main points, but certainly could use some rearranging. I hereby offer it up for tweaks and adjustments. This may be useful, but is meant as a followup to the posts about documenting building from CVS. In the gimp-print source, there is a file `doc/README.maintaining' that describes how to use the autotools to build from CVS. It covers how to set up a checked-out CVS (or tarball) tree, and use configure (but that's documented fully in README). It also goes into how all the autotools work together, and how to set up the build scripts manually, or with autogen.sh automatically. Additionally, it describes briefly how to hack configure.in and Makefile.am's. I lost the message about documenting building from CVS, but you might find parts of this useful (there's little point in writing the same thing twice). Some parts are specific to gimp-print, but you can eaily cut them out or modify them. I spotted a couple of typos just now, and I also have an updated copy for autoconf 2.52 and automake 1.5. See: http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gimp-print/print/doc/README.maintaining?rev=1.8content-type=text/vnd.viewcvs-markup or the source. Regards, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers msg01799/pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Raphael's edits, was Re: test this howto now
On Mon, Jan 21, 2002 at 10:12:55PM +0100, Sven Neumann wrote: Hi, Roger Leigh [EMAIL PROTECTED] writes: In the gimp-print source, there is a file `doc/README.maintaining' that describes how to use the autotools to build from CVS. It covers how to set up a checked-out CVS (or tarball) tree, and use configure (but that's documented fully in README). It also goes into how all the autotools work together, and how to set up the build scripts manually, or with autogen.sh automatically. Additionally, it describes briefly how to hack configure.in and Makefile.am's. this file is traditionally called HACKING. Is this documented anywhere? I can't see anything about this in the GNU Coding Standards. Thanks, Roger -- Roger Leigh ** Registration Number: 151826, http://counter.li.org ** Need Epson Stylus Utilities? http://gimp-print.sourceforge.net/ GPG Public Key: 0x25BFB848 available on public keyservers msg01803/pgp0.pgp Description: PGP signature
[Gimp-developer] Message reorganization in gimp HEAD complete?
Is the message reorganization in gimp HEAD completed? There are quite a few changes, and I'd like to know if it's more safe to start translating these without too many expected radical changes coming. Before anyone reminds me I'd like to state that I know, and am fully aware of the fact that HEAD is under heavy development, but I'd like to update the HEAD translation again, just like before the announced message reorganization, and thus want to know if the announced message reorganization is complete, so that I don't shoot myself too much in the foot by translating gimp HEAD. Christian ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
