Re: [Gimp-developer] GAP
Sven Neumann wrote: > I have fixed that in gimp-gap, both in trunk and gap-2-2. Would be cool > if someone could do some more testing in the gap-2-2 branch before I do > the release... So far I have not encountered any problems with the changes. I did notice that the file 'gap/sel-to-anim-img.scm' does not run under the TinyScheme-based Script-fu (it uses some variables without defining them). I have created a patch file for this which is available at http://flashingtwelve.brickfilms.com/GIMP/Temp/selanim.patch The contents of that file are: Index: gap/sel-to-anim-img.scm === --- gap/sel-to-anim-img.scm (revision 681) +++ gap/sel-to-anim-img.scm (working copy) @@ -37,7 +37,17 @@ (idx 0) (draw-type (car (gimp-drawable-type-with-alpha drawable))) (image-type (car (gimp-image-base-type image))) -(old-bg (car (gimp-context-get-background +(old-bg (car (gimp-context-get-background))) + (selection-bounds) + (select-offset-x) + (select-offset-y) + (selection-width) + (selection-height) + (from-selection) + (active-selection) + (brush-draw) + (draw-name) + (brush-image)) (set! selection-bounds (gimp-selection-bounds image)) (set! select-offset-x (cadr selection-bounds)) @@ -94,7 +104,7 @@ (gimp-image-set-active-layer image drawable) (gimp-image-clean-all brush-image) (gimp-display-new brush-image) -(gimp-displays-flush)) +(gimp-displays-flush) (if (= filter-all TRUE) ; INTERACTIVE animated call of any other plugin ; (drawable and plugin name are dummy parameters @@ -103,6 +113,7 @@ (plug-in-gap-layers-run-animfilter 0 brush-image brush-draw "plug-in-bend" 1) ) ) +) (script-fu-register "script-fu-selection-to-anim-image" _"/Script-Fu/Animators/Selection to AnimImage..." ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
Hi, On Sat, 2007-08-04 at 03:44 -0400, [EMAIL PROTECTED] wrote: > I did notice that the file 'gap/sel-to-anim-img.scm' does not run under > the TinyScheme-based Script-fu (it uses some variables without defining > them). I have created a patch file for this which is available at > http://flashingtwelve.brickfilms.com/GIMP/Temp/selanim.patch Applied to both branches. Thanks a lot. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP UI redesign should be an open process
Hi, On Fri, 2007-08-03 at 22:44 -0600, Esteban Barahona wrote: > A rational and respectful exchange of ideas about the GIMP UI should > be started. Personally, I think that this is a crucial time in the > development of this widely used software. A total redesign without > informing users may lead to an unnecessary fork. The process is completely open and you have obviously misunderstood quite a few things about it. But now is indeed a crucial time for GIMP development as we are working hard on preparing the GIMP 2.4 release. Can we please not distract ourselves right now with a discussion that is based on nothing but fear, doubt and misunderstandings? Thanks. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
Hi, On Fri, 2007-08-03 at 23:50 +0200, Popolon wrote: > Here is an updated version for french. > Could have 1 or 2 mistakes, but mostly well updated. Please do not send translation updates to the mailing-list nor to me in personal. This is handled by the GNOME translation project and you should have contacted the coordinator of your language team instead. In this particular case I will make an exception and commit your changes. Thanks. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
On Friday 03 August 2007 17:18, Sven Neumann wrote: > Hi, > > On Fri, 2007-08-03 at 23:54 +0400, Alexandre Prokoudine wrote: > > > Are you absolutely sure that you removed the "fuzzy" marker > > > after updating the translation? > > > > Yes, I am. > > OK, please try again after updating from SVN. I added some missing > calls to gimp_plugin_domain_register(). That should fix it, but > there might be more places affected that need a similar fix. > > > Sven I am getting an error linking gimp-gap svn in a 64bit enviromment, in both trunk and gap-2-2 branch: /usr/bin/ld: bitstream.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC bitstream.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[4]: *** [libavcodec.so] Error 1 when doing: gcc -shared -o libavcodec.so bitstream.o utils.o mem.o allcodecs.o mpegvideo.o jrevdct.o jfdctfst.o jfdctint.o mpegaudio.o ac3enc.o mjpeg.o resample.o resample2.o dsputil.o motion_est.o imgconvert.o imgresample.o mpeg12.o mpegaudiodec.o pcm.o simple_idct.o ratecontrol.o adpcm.o eval.o dv.o error_resilience.o fft.o mdct.o mace.o huffyuv.o cyuv.o raw.o h264.o golomb.o vp3.o asv1.o 4xm.o cabac.o ffv1.o ra144.o ra288.o vcr1.o cljr.o roqvideo.o dpcm.o interplayvideo.o xan.o rpza.o cinepak.o msrle.o msvideo1.o vqavideo.o idcinvideo.o adx.o rational.o faandct.o 8bps.o smc.o parser.o flicvideo.o truemotion1.o vmdav.o lcl.o qtrle.o g726.o flac.o vp3dsp.o integer.o snow.o tscc.o sonic.o ulti.o h264idct.o qdrw.o xl.o rangecoder.o png.o pnm.o qpeg.o vc9.o h263.o h261.o msmpeg4.o h263dec.o svq1.o rv10.o wmadec.o indeo3.o shorten.o loco.o alac.o wnv1.o ws-snd1.o aasc.o a52dec.o liba52/bit_allocate.o liba52/bitstream.o liba52/downmix.o liba52/imdct.o liba52/parse.o liba52/crc.o liba52/resample.o -lm -lz -ldl -Wl,--warn-common -rdynamic (trying the suggested "fPIC" makes build halt early on.) > > > ___ > Gimp-developer mailing list > Gimp-developer@lists.XCF.Berkeley.EDU > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
Hi, On Sat, 2007-08-04 at 01:58 -0300, Joao S. O. Bueno Calligaris wrote: > I am getting an error linking gimp-gap svn in a 64bit enviromment, in > both trunk and gap-2-2 branch: That's a problem with the copy of libavcodec that is included with GAP. You better disable support for libavcodec when configuring gap. For GAP 2.4 we should include a recent version of libavcodec. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GAP
Hi, On Sat, 2007-08-04 at 03:44 -0400, > I did notice that the file 'gap/sel-to-anim-img.scm' does not run under > the TinyScheme-based Script-fu Did you also check the other Script-Fu script in the gap subdirectory? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ACO and CSS palette importing (patch attached)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi All,
Attached is a patch, against svn, which adds ACO importing, and CSS
color extraction, for the palette system.
The ACO code only reads the version 1 section at the moment, I plan on
finishing the version 2 support to extract color names a little later.
Color spaces supported are RGB, CMYK, HSV and greyscale, but not Lab.
The CSS import extracts colors defined in a .css file.
If this patch meets the standards, perhaps someone would like to
incorporate it into the repository.
This patch would, I believe, enable the closing of Bug #316618
Thanks
Nicola.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFGtMldG4yOusCUvb8RAvSVAJoD6KK24CPhq5AXsSzekqXUY3RF4wCfWDpw
5mUdq2GWEYX970J0gHzUWGE=
=ZgvZ
-END PGP SIGNATURE-
Index: app/core/gimppalette-import.c
===
--- app/core/gimppalette-import.c (revision 23113)
+++ app/core/gimppalette-import.c (working copy)
@@ -511,6 +511,14 @@
palette_list = gimp_palette_load_psp (filename, error);
break;
+case GIMP_PALETTE_FILE_FORMAT_ACO:
+ palette_list = gimp_palette_load_aco (filename, error);
+ break;
+
+case GIMP_PALETTE_FILE_FORMAT_CSS:
+ palette_list = gimp_palette_load_css (filename, error);
+ break;
+
default:
g_set_error (error,
GIMP_DATA_ERROR, GIMP_DATA_ERROR_READ,
Index: app/core/gimppalette-load.c
===
--- app/core/gimppalette-load.c (revision 23113)
+++ app/core/gimppalette-load.c (working copy)
@@ -430,6 +430,224 @@
return g_list_prepend (NULL, palette);
}
+GList *
+gimp_palette_load_aco (const gchar *filename,
+ GError **error)
+{
+ GimpPalette *palette;
+ gchar *palette_name;
+ gint fd;
+ guchar color_bytes[4];
+ gint format_version;
+ gint number_of_colors;
+ gint i;
+ gcharheader[4];
+ gcharcolor_info[10];
+ gcharformat2_preamble[4];
+ gint status;
+
+ g_return_val_if_fail (filename != NULL, NULL);
+ g_return_val_if_fail (g_path_is_absolute (filename), NULL);
+ g_return_val_if_fail (error == NULL || *error == NULL, NULL);
+
+ fd = g_open (filename, O_RDONLY | _O_BINARY, 0);
+ if (! fd)
+{
+ g_set_error (error,
+ G_FILE_ERROR, g_file_error_from_errno (errno),
+ _("Could not open '%s' for reading: %s"),
+ gimp_filename_to_utf8 (filename), g_strerror (errno));
+ return NULL;
+}
+
+ palette_name = g_filename_display_basename (filename);
+ palette = GIMP_PALETTE (gimp_palette_new (palette_name));
+ g_free (palette_name);
+
+ status = read(fd, header, sizeof (header));
+
+ if (status < 0)
+{
+ close(fd);
+
+ return g_list_prepend (NULL, palette);
+}
+
+ format_version = header[1] + (header[0] << 8);
+ number_of_colors = header[3] + (header[2] << 8);
+
+ for (i = 0; i < number_of_colors; i++)
+ {
+ gint color_space;
+ gint w, x, y, z;
+ gboolean color_ok = FALSE;
+ GimpRGB color;
+
+ read(fd, color_info, sizeof(color_info));
+ color_space = color_info[1] + (color_info[0] << 8);
+
+ w = (guchar)color_info[3] + ((guchar)color_info[2] << 8);
+ x = (guchar)color_info[5] + ((guchar)color_info[4] << 8);
+ y = (guchar)color_info[7] + ((guchar)color_info[6] << 8);
+ z = (guchar)color_info[9] + ((guchar)color_info[8] << 8);
+
+ if (color_space == 0) /* RGB */
+ {
+ gdouble R = ((gdouble) w) / 65536.0;
+ gdouble G = ((gdouble) x) / 65536.0;
+ gdouble B = ((gdouble) y) / 65536.0;
+
+ gimp_rgba_set( &color, R, G, B, 1.0);
+
+ color_ok = TRUE;
+ }
+ else if (color_space == 1) /* HSV */
+ {
+ GimpHSV hsv;
+
+ gdouble H = ((gdouble) w) / 65536.0;
+ gdouble S = ((gdouble) x) / 65536.0;
+ gdouble V = ((gdouble) y) / 65536.0;
+
+ gimp_hsva_set ( &hsv, H, S, V, 1.0 );
+ gimp_hsv_to_rgb( &hsv, &color);
+
+ color_ok = TRUE;
+ }
+ else if (color_space == 2) /* CMYK */
+ {
+ GimpCMYK cmyk;
+
+ gdouble C = 1.0 - (((gdouble) w) / 65536.0);
+ gdouble M = 1.0 - (((gdouble) x) / 65536.0);
+ gdouble Y = 1.0 - (((gdouble) y) / 65536.0);
+ gdouble K = 1.0 - (((gdouble) z) / 65536.0);
+
+ gimp_cmyka_set (&cmyk, C, M, Y, K, 1.0 );
+ gimp_cmyk_to_rgb( &cmyk, &color);
+
+ color_ok = TRUE;
+ }
+ else if (color_space == 8) /* Grayscale */
+ {
+ gdouble K = 1.0 - (((gdouble) w) / 1.0);
+
+ gimp_rgba_set( &color, K, K, K, 1.0 );
+
+ color_ok = TRUE;
+ }
+ else if (color_space == 9) /* Wide? CMYK */
[Gimp-developer] 4 annoying things in Gimp
1. When designing complicated project for example cd cover I often have to chain and unchain layers. Would be nice if gimp would have option - unchain all. 2. I can't make gradients bigger the current image area. Couldn't it work like other tools. 3. Every time I want to move layer using move tool I have to click on this layer first to be able to use arrows keys on keyboard 4. I have to click on the top of image window to go to fulscreen mode (pressing TAB) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 4 annoying things in Gimp
On 8/5/07, damianzalewski <[EMAIL PROTECTED]> wrote: > > 1. When designing complicated project for example cd cover I often > have to chain and unchain layers. > > Would be nice if gimp would have option - unchain all. Maybe, but you can already do this in two clicks 1. shift-click on the layer chain to make a layer the only one chained 2. click on the layer chain to unchain that one too. > > 2. I can't make gradients bigger the current image area. > Couldn't it work like other tools. ? Works for me. Are you running GIMP on the dreaded Windows OS? ;) > > 3. Every time I want to move layer using move tool I have to > click on this layer first to be able to use arrows keys on keyboard At all, or on that layer? if at all, then see below about your WM. otherwise, you probably don't have that layer selected (== the active layer). If you can think of a way to improve this behaviour, then please say so. > > 4. I have to click on the top of image window to go to > fulscreen mode (pressing TAB) That sounds like it's related to your window manager not giving the image window focus. Personally I find it best to set the focus to follow the mouse, then i needn't do any clicking. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Using Parallel Make
Hi, I recently acquired a new PC with a dual core chip running Kubuntu Feisty Fawn. So when I last tried to build Gimp, version 2.3.18, I used "make -j" and the build terminated with an error in just a few seconds. If I just use the command "make", the build completes successfully in about 10 minutes. Reading up on parallel make, I conclude that the Gimp makefile is not up to snuff for doing a parallel make. Naively perhaps, I think that is a shame because I bet a lot of people would save a lot of time if they could do parallel makes. Has anyone looked at doing parallel builds of Gimp? Regards, Don ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Using Parallel Make
"make -j" without a numeric argument will overwhelm most machines fairly quickly in complex makes. Since you're running a dual-core machine, try "make -j3" or "make -j4". This will limit the number of concurrent processes to something reasonable and provide decent load balancing between processing and i/o. (I haven't looked at the gimp Makefiles recently, but running gcc with the -pipe option might help performance, at least on Linux systems--I haven't a clue about Windows systems.) Don Rozenberg wrote: Hi, I recently acquired a new PC with a dual core chip running Kubuntu Feisty Fawn. So when I last tried to build Gimp, version 2.3.18, I used "make -j" and the build terminated with an error in just a few seconds. If I just use the command "make", the build completes successfully in about 10 minutes. Reading up on parallel make, I conclude that the Gimp makefile is not up to snuff for doing a parallel make. Naively perhaps, I think that is a shame because I bet a lot of people would save a lot of time if they could do parallel makes. Has anyone looked at doing parallel builds of Gimp? Regards, Don ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Christian H. L. Moller President Moller Software Development Services, LLC [EMAIL PROTECTED] 919.367.8689 (Voice) www.mollerware.com 919.367.9097 (Fax) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Using Parallel Make
Looking more closely at what is happening, I notice that when I do a "make -j 3" the make stops with the following error message: make[2]: *** No rule to make target `../libgimpthumb/libgimpthumb-2.0.la', needed by `gimp-thumbnail-list'. Stop. If I then do a "make", followed by a Control-c in say 5 seconds, followed by a "make -j 3" the build will complete successfully yielding a working program. This seems to be repeatable. The total build time is approximately halved and both cpu's are pegged most of the time. Thanks for the suggestion to use "-j 3". ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
