Re: Bumpmap with negative Depth ??
lasm wrote: I was trying to look for an engraved effect, the opposite of emboss, i.e. to make the thing look caved in, instead of popped out. While I couldn't find any plugin that does this, I thought of an idea, if the bumpmap can be changed to accept negative depth, in addition to positive integers, would it then achieve the "engraved" effect ? I think the effect you are talking about is called 'Carve-It'. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: GIMP 1.2.0 source and binary RPM files
Greetings, all! Yesterday evening I uploaded the patches, source, and binary RPMs for gimp and gimp-data-extras to gimp.org for the 1.2.0 version of the GIMP. They should become available sometime in the near future once they get moved out of the 'incoming' area of the FTP server. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: anonymous CVS is broken :(
At 12:02 AM 01/04/2001 +, you wrote: Whoever is providing anonymous CVS, it's broken. , | loki:/usr/packages/gimp% echo $CVSROOT | :pserver:[EMAIL PROTECTED]:/cvs/gnome | loki:/usr/packages/gimp% cvs -z5 co -r gimp-1-2 gimp | cvs server: cannot open /root/.cvsignore: Permission denied | cvs [server aborted]: no such tag gimp-1-2 I have noticed this as well. Persistence and patience are the key. I find that trying a few times (with some brief waiting periods in between attempts) usually does the trick. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
GIMP 1.2.0 source and binary RPM files
Greetings, all! I now have source RPM files. I will be uploading the patches, source and binary RPMs to gimp.org later today. These files will become available for downloading once they have gone through whatever process contributed files go through. The RPMs I have are for both gimp-1.2.0 and gimp-data-extras. The binary RPM files were compiled on a machine running RedHat 6.2. If anyone is desparate to have RPMs and can't wait for the files to be available via gimp.org, let me know and I will arrange to make them available on a website. I won't send the spec and patch files through the mailing list to save peoples already overflowing mailboxes. You may now jump up and down, and cheer (or not). :-) Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: GIMP 1.2.0 DESTDIR patch
Marco Lamberto wrote: Please check the patch and _please_ merge those changes in order to build again easily and RPMmed GIMP. ;) I've taken a look at the patch, Marco. For some reason all your patches were rejected when I tried to apply them so I recreated the patches. However, I am only using four of the six patches you provided. --- gimp-1.2.0lm/plug-ins/perl/Makefile.PL.orig Fri Dec 29 14:03:30 2000 +++ gimp-1.2.0lm/plug-ins/perl/Makefile.PL Fri Dec 29 14:03:32 2000 I'm not sure why you commented out one of the lines in this file so I have left it out for now. --- gimp-1.2.0lm/plug-ins/Makefile.in.orig Fri Dec 29 11:27:02 2000 +++ gimp-1.2.0lm/plug-ins/Makefile.in Fri Dec 29 14:12:30 2000 I also did not use this patch. As far as I can tell this file does not need a DESTDIR patch. It is determining which argument to pass to the make in the sub-directories based on how this level make was invoked. Last night I compared the contents of the .rpm files created using my updated .spec file against the files installed in to the directory tree used for the CVS based version of GIMP. I feel I am picking up everything that my development version was installing so I am making a patch for the ChangeLog file. I will then do one more build to verify everything is ok and release the patches. After this, I will create a spec file for gimp-data-extras. I will also compare the source tree for the GIMP 1.2.0 which I downloaded as a tar ball and compare it against the CVS version I downloaded fresh last night. I know there are some patches that were made to the original 1.2.0 so I will try and incorporate them in to the .src.rpm if there is not already an updated file with the latest patches at gimp.org already available. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: GIMP 1.2.0 DESTDIR patch
Marc Lehmann wrote: scm2scm should go into gimp-devel, as it only requires perl, not gimp-perl, scm2perl should go into gimp-perl-devel, so you can choose on your own (I recommend gimp-perl). Thank, Marc. I was thinking that was probably how it would wind up. I'll move scm2perl in to gimp-perl (in the .spec file) along with the man file for it. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: GIMP 1.2.0 DESTDIR patch
Marco Lamberto wrote: Good, I've attached a revised patch of mine vs the gimp.spec.in that should fix some stuff. It was contributed by my friend Giandomenico Di Tullio. I hope this will help you. ;) Thanks, Marco. That patch shows most of the changes I have already made myself. There are a few other changes I made which aren't in the version from your friend. Is the result of the discussion re: Marco's DESTDIR patches that all 6 of them do need to be applied? There were two that seemed questionable at first. If so, I will add the other two which I am not using yet to the patch set which will be used to make RPM files. Other than this last issue, I feel I have everything ready to be released. You can thank my poor overworked Pentium II 266 for this Marco. It takes me about an hour to build the RPMs as well. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: GIMP 1.2.0 DESTDIR patch
Marco Lamberto wrote: This time I've fixed the main problem related to the "prefix" var used for installation, now changed into "DESTDIR", and I've attached a patch vs 1.2.0. I've added the DESTDIR support in the subdirs that still hold the old installation prefix. I tried building an RPM file using the four of your original 6 DESTDIR patches as I mentioned in a previous message. It turns out that the 'dir' variable already has the DESTDIR information in it. If you add DESTDIR it winds up in there twice. I know this having captured the full output of an RPM build. It seems the DESTDIR patches you indicated are not needed (other than the one in the spec file itself which I had already found). I am currently half way through what should be the final RPM build. I will upload the patches later tonight or tomorrow once I have packaged everything up. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: GIMP 1.2.0 DESTDIR patch
Marco Lamberto wrote: Some times ago me and other guys complained about a broken support for building GIMP's RPMs. This time I've fixed the main problem related to the "prefix" var used for installation, now changed into "DESTDIR", and I've attached a patch vs 1.2.0. I've added the DESTDIR support in the subdirs that still hold the old installation prefix. Great timing, Marco. Yesterday and today I have been working on the .spec file for GIMP 1.2.0. I have a working one now. I'm just reviewing it as I am not sure that the libgimp .html files are being installed and probably should be. I am also trying to decide where scm2scm and scm2perl belong. Should they be in gimp and gimp-perl respectively, or gimp-devel for both? Other than that, I will put a patch together for the spec files in a day or so. Happy new year everyone! Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Problem building an gimp-1.1.32 RPM
Henning Sauer wrote: Is their a way to correct this behaviour and build an RPM ? Certainly. I'd be happy to look at the RPM file and fix it. Its probably a minor thing. Everytime I look at .spec files I learn something. The problem is that with Christmas just about here, I may (but may not) have a chance to look at it later today or early tomorrow. If not, I won't be able to look at this until sometime in the afternoon on the 27th of this month at the earliest. I'm tempted to have my name put down as the maintainer of the .spec file as I like building RPMs when needed. I have rolled a few of my own already from source files. I do have a remote site I administer where I could store SRPM and RPM files. Consider my name written down in pencil for now. After Christmas I'll see if it will get written down in ink. Happy holidays to everyone! Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Problem building an gimp-1.1.32 RPM
Henning Sauer wrote: Is their a way to correct this behaviour and build an RPM ? I managed to take a quick look in to this. I believe the problem is not with the spec file but with the Makefile's. The 'make install' invoked by the spec file is installing gimp, gimp-tool, gimp-remote, and a sym link for gimp-config in to /usr/bin instead of into the directory specified by the prefix= and PREFIX= arguments passed on the command line to the make program. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: new plugin
david rohde wrote: I am currently writing a new plugin, which I hope if there is intrest in it could be included in to standard gimp distributions. I understand that the gimp is frozen at the moment, but if anyone could tell me the process required for a new plugin to be considered for the gimp. Should I have users before I ask you guys to look at it. Even if it is too late for it to be included in the next major release of the GIMP, you can always make your plug-in available via a web site and then get your plug-in listed in the plug-ins section of gimp.org. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: TODO for 1.2 release
[EMAIL PROTECTED] wrote:
On 26 Sep, Tim Mooney wrote:
Grepped through the source and couldn't find any C++ style
comments...
cc: Error: lighting_ui.c, line 387: Invalid statement. (badstmt)
// GtkWidget *spinbutton;
--^
There are a number of C++ style comments. I ran the following command
against the GIMP 1.1.26 source which I last updated from the CVS repository
as of sometime last night.
find . -name "*.[ch]" -print -find . -name "*.[ch]" -print -exec grep \/\/
{} \;
(NOTE: Lines starting with ./gimp indicate the name of a file containg C++
comments)
./gimp/app/channel_ops.c
// 64,64,128,128);
//
newgdisplay-disp_width,newgdisplay-disp_height,
//
newgdisplay-disp_width+newgdisplay-disp_xoffset,newgdisplay-disp_height+newgdisplay-disp_yoffset
./gimp/app/convert.c
// boxp-Rhalferror = (Rmin+Rmax)/2;
// boxp-Ghalferror = (Gmin+Gmax)/2;
// boxp-Bhalferror = (Bmin+Bmax)/2;
//R = ((b1-Rmax - b1-Rmin) R_SHIFT) * R_SCALE;
//G = ((b1-Gmax - b1-Gmin) G_SHIFT) * G_SCALE;
//B = ((b1-Bmax - b1-Bmin) B_SHIFT) * B_SCALE;
./gimp/app/tile_manager.c
// fprintf(stderr,"V%p ",tm-user_data);
./gimp/plug-ins/Lighting/lighting_ui.c
// GtkWidget *spinbutton;
./gimp/plug-ins/print/print-weave.c
//putchar('\n');
./gimp/plug-ins/sel2path/spline.c
/* //HB: the above is really nice, but is there any other compiler
./gimp/plug-ins/twain/tw_func.h
#endif // _TW_FUNC_H
./gimp/plug-ins/twain/tw_util.h
#endif // __TW_UTIL_H
./gimp/plug-ins/twain/twain.h
#ifdef __BORLANDC__ //(Mentor June 13, 1996) if using a Borland
compiler
#pragma option -a2 //(Mentor June 13, 1996) switch to word
alignment
#else //(Mentor June 13, 1996) if we're using some other compiler
#endif //(Mentor June 13, 1996)
// TW_MEMREF pData; /* Based on implementation specifics, a
*/
// TW_MEMREF pData; /* Based on implementation specifics, a
*/
//#define TWSS_B 8
#ifdef __BORLANDC__ //(Mentor June 13, 1996) if we're using a Borland
compiler
#pragma option -a. //(Mentor October 30, 1996) switch back to
original alignment
#else //(Mentor June 13, 1996) if NOT using a Borland compiler
#endif //(Mentor June 13, 1996)
./gimp/plug-ins/winsnap/resource.h
//{{NO_DEPENDENCIES}}
// Microsoft Developer Studio generated include file.
// Used by snappy.rc
//
// Next default values for new objects
//
./gimp/plug-ins/winsnap/winsnap.c
/* //HB: update data BEFORE size change */
Cheers!
Kevin. (http://www.interlog.com/~kcozens/)
Internet:kcozens at interlog.com |"What are we going to do today, Borg?"
or:ve3syb at rac.ca |"Same thing we always do, Pinkutus:
Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!"
#include disclaimer/favourite| -Pinkutus the Borg
Re: TODO for 1.2 release
"Moses P. Milazzo" wrote: Why not: grep "//" `find . -name "*.[ch]"` | grep -v 'p://' You should include -print as part of the find statement or else you will wind up getting a list of lines containing C++ style comments without knowing the name of the file that needs to be edited. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Expanding the Palette
At 02:55 PM 09/27/2000 -0500, you wrote: For printing I'm sending the high resolution files to a company that outputs them to photographic paper. I have no idea what they use to make the prints but the quality is fantastic. I have something I need to get printed which I designed using the GIMP. How did you deal with the issues of colour matching? What format do you use when sending the images to the printer (ie. jpg, png)? I know a lot of printers prefer files to use CMYK colour which the GIMP doesn't do (yet). Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: PCX import
At 10:08 PM 08/12/2000 +0200, Martin Weber wrote: ... For most formats GIMP has a very good solution, but for PCX ImageMagick and XV loads the pictures 50 % faster into memory than GIMP. Where could pcx.c be optimized? I have only taken a quick look at pcx.c but I can see where some minor(?) optimizations might be made in a few loops. I don't know what impact (if any) it would have on the load time. I don't have any PCX coded files let alone ones that test each of the load routines to be able to try the minor changes to the code and see what impact it would have on the load times. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Stupid Question : )
Anton Enright wrote: I've got a GIMP precompiled binary tarball that is supposed to be installed in /opt Because I do not have root access to my machine I've installed it in /space/opt. [snip] Is there anyway to modify post-install the prefix directory that gimp looks for scripts plugins etc... Check for paths in the 'gimprc' file under the directory where you installed GIMP plus in the users area under the .gimp-1.1 directory. In the main gimprc file there is a path called 'prefix' which is the main one you need to modify. Changing the path should help but I do not guarantee that this will make it fully operational but its worth a shot. Alternatively, you could grab the source and compile it yourself. This would allow you to specify any install path you liked.
Re: Gimptool in Gimp 1.0.4
Robert L Krawitz wrote: A number of our users who are using Red Hat (6.0 or 6.2) report that there is no gimptool present with Gimp 1.0.4 (they've done a find and come up with nothing; they've checked that they've installed [snip] Any suggestions? Is Red Hat broken, or is it our configure script? I just checked the GIMP 1.0.4 RPM files that I have on my RedHat 6.2 machine. The gimptool file is located in /usr/bin.
Re: CorelPhotopaint for Linux
Jeff Sheffield wrote: I thought this was interesting. in the "End User License Agreement" It states that you may not reverse engineer the product. YOU MAY NOT: ---snip 2. reverse engineer, This is not uncommon in agreements these days. I have installed the product under Redhat Linux but it hangs when trying to start on my machine. I thought I would take a look to see what it had that wasn't in the GIMP. There has to be something to explain the installation stating that you need 170Meg of disk space which is about twice the space needed for the GIMP.
Re: [Who are we again, again?]
Piers Cornwell wrote: Why is there *yet another* incomplete list of all Gimp contributors in the AUTHORS file? Hint: We already had enough such lists, and none of those are properly maintained either. I'm curious as to what is the criteria that determines whether someones name will appear in the authors list and/or in the About GIMP scrolling window. Is it only core developers, people who have made a certain level of contribution, or is it meant to encompass everyone who has made provided a patch (or patches) for the project? My name isn't on the list but I've only supplied a number of minor patches. I am in the ChangeLog for most of them once I remembered to include updates for the ChangeLog with the patch. As a result, I'm not too worried if I appear in a more visible list or not.
Re: Getting mouse coordinates from inside a gimp plug-in?
At 10:41 27/6/00 -0500, Frazer Williams [EMAIL PROTECTED] wrote: I'm trying to write an "unplot" plugin. The idea is to load a graph image into the gimp (probably using a scanner), and then, using the mouse to click on points on the graph, write the x and y values of mouse-selected points to a file. Thus, if I had a graph of, say, voltage vs. current, I could digitize it manually using the plug-in, obtaining a file with voltages and currents. I would suggest you look at the code for the ImageMap plugin. Thinking about what it how it works from the users point of view I suspect it has to have a way of getting the mouse coordinates.
Re: The undo stack does not record some changes in layer attributes
Greetings! On Wed, 07 Jun 2000, Sven Neumann [EMAIL PROTECTED] wrote: [quoting Austin Donnelly [EMAIL PROTECTED]] I would be very unhappy if changing the layer opacity from 100% to 50% would eat up a dozen or more undo-steps since each value_changed signal from the slider triggers an undo which causes another undo-step fall off the end of the undo queue. Oh, sure - that's clearly a bad idea. I was thinking of only pushing the undo when you release the slider. That doesn't help those using the keyboard to nudge the slider though. [...] I just had an idea re: the undo stack. It shouldn't matter whether changes are done via keyboard or via mouse. Not pushing an undo on to the stack until the mouse release would help (ie. when adjusting sliders or spin buttons) but only affects mouse operations. The more generic solution is to check the last entry of the undo stack before pushing something on to the undo stack. If someone is nudging a given slider, a check would show that the last operation on the undo stack is a change to that same slider. You would then throw out that stack entry and push the latest change to the stack. This assumes that the operation being done a bit at a time does not affect an image being worked on. If the user nudges different sliders each time, then you would save each nudge of a slider (for example). The tricky part might be to determine whether the last item on the undo stack caused a change to an image. Changes to image previews should probably be ignored. I'm not suggesting this be done for 1.2 as I suspect its too likely to wind up adding bugs to the GIMP. It would help to maximize the use of the undo stack, however.
Re: static and forward declaration
CodeWarrior is correct in its message. The variables are being defined the first time for use in the procedural_db_register() calls and then later they are defined again but this time with initial values. Does CodeWarrior issue the redefinition message as a warning or as an error? The output from 'gcc -v' on my machine is: Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Even though -Wall is specified, gcc accepts it without even a warning. I don't know offhand if this behaviour is allowed by the standard. My personal coding style would put the declaration with initial values before the first use which would eliminate the two lines at the top of the file.
Re: Photo Archive Pre-Announcement
Carey Bunks wrote: Dear GIMPsters, Creating digital collage and photo-montage with the GIMP requires good access to unfettered, raw photographic materials. Although there are many online stock-photo companies offering images for a fee, to promote and accelerate the use of the GIMP, it would be useful to have a readily available, copyright-free, photo archive. It looks good. It will be wonderful once it is fully indexed. Since you can ony use keywords and not a phrase, what keyword should be used to indicate an image that is black and white?
Re: Edit Fille behaviour change?
My usage pattern is Fill = Undo = Swap Colours = Fill = Swap Colours ^ + insert a "this damnit fill braindamage e3stD%$DFZG§ gimp thing" here. Apart form the API changes (breaking _some_ plug-ins), I highly welcome that change. But I'd also say it was not a bug. "but but" now is a good time to change that. So I am not the only one that has the usage pattern with fill listed above. I don't know if its from other graphics programs I have used or just what made sense to me but I expected fill to use the foreground colour. I mean after all, you don't expect the pencil tool to draw with the background colour. From some of the other comments on the mailing list here, perhaps its something that should be changed after 1.2 is out. Many scripts may have to be adjusted and some of us may have to adjust the way we use GIMP slightly but I think it makes more sense to fix something that is a little odd rather than live with it forevermore IMHO. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Translation inconsistency
If you need to tell USERS something important then it should not be in these strings, you should rather write a paragraph for the GUM. (B) don't mark the strings for translation, not in the core, neither in the plug-ins It depends on what is meant by having something important to tell the users. If the information is just letting the user know how to do something or what a particular feature does this should be in the manual. If its a message as a result of a run time situation (input needed from the user, status message, or an error message) this should be translated based on the users specified language. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: [gimp-devel] Re: End-user feedback: Perl logulator innerbevel
If re-reporting the bug is so painful that you can't do it It is so painful because I re-reported it at least three times (so many mails are in my saent-folder, but I know I sent more that got lost during a crash). They are not SO critical that I have been unable to use script-fu They are ciritcal enough that some plug-ins (like the logulator) never worked because of it. Could you provide the subject line of any one of the messages when you reported the problems with script-fu which you say have not been fixed and/or a date when one of the messages was posted to the list? I am searching the mailing list archives but there are so many messages I haven't found it yet. Using "script-fu" as a search criteria only 206 messages were found. I haven't found one yet which seems to mention script-fu problems in the subject line. I did find the following message from around May of 1999: 1. Gimp segfaults on the first PDB call to gimp_paintbrush. The reason is that the pointer "paintbrush_options" (app/paintbrush.c) is NULL as it isn't initialized automatically. I haven't checked but if other tools use a similar technique these also won't work. (I also haven't checked wether this depends on the global paint options setting). 2. Also, could somebody tell me how I can set the tool options? I seem unable to use gradients from my scripts. 3. How do I use the ink tool? There seems to be now way of using it from scripts. 4. --with-mp=yes slows down the paintbrush tool by approximately 5791%, if not more. (seriously, drawing a line takes 5 seconds instead of 0.2), this was tested with the Circle (01) brush. The same is true for the pencil tool but NOT for the ink tool, which is still fast. I don't the above is script-fu related as such. This is all I was able to find so far. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Fwd: mailing lists changes
Greetings, all! Here is the information Manish Singh sent out some time ago regarding the switch from majordomo to the ezmlm style of mailing list. Date: Tue, 31 Aug 1999 11:17:52 -0700 From: Manish Singh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: mailing lists changes Sorry for all the downtime people, the list should be operational again. We're using ezmlm now, so there's new instructions for subscription and unsubscription. To subscribe, send an empty email to [EMAIL PROTECTED] To unsubscribe, send an empty email to [EMAIL PROTECTED] -Yosh Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: get terrence brannon OFF these lists
When you join the list, you get directions on how to unsubscribe. A rational being, a thoughtful being, a being who belongs on a technical list, will save these instructions, and use them if needed. This is true. However, the list changed from being based on majordomo to ezmlm and the instructions changed. The new instructions were e-mailed out to all on the list and the new info should have been saved. Also, the information could have been sent directly to the individual and saved some of the discussions on this list. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: Help System
Why not allow the user to choose his/her browser of choice ? With Netscape, Mozilla, the Gnome Help Browser, kfm, or even Lynx in an xterm as possible choices, I don't see any problem with this... So Gimp help should be a set of HTML files and a small exec to launch the preferred browser (calling process already running if needed, a la moz remote). GSR You beat me to it. I was about to suggest that the simplest solution is to create simple HTML files for use as help and let the user use whatever browser they prefer to use in order to view the help files. This is essentially what is done in a Windows based HTML editor known as Dreamweaver (as if you really care what a Windows program does :-). Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
Re: bmp-plugin
Do you have example 16-bit and 32-bit BMP files, and also examples of non-working RLE images? I have been collecting images which broke Gimp for some time now to check for regression in new builds. I have a 16-bit BMP file I can send you. If you want it, tell me where to send it. I should tell you that it is a 1280x960 pixel BMP with 16-bit colour depth. It was created from a .jpg using Netscape to turn it into Windoze wallpaper. Its 2,401kb in size. I will update my copy of GIMP and the bmp plug-in and see if I can load the image. Cheers! Kevin. (http://www.interlog.com/~kcozens/) Internet:kcozens at interlog.com |"What are we going to do today, Borg?" or:ve3syb at rac.ca |"Same thing we always do, Pinkutus: Packet:ve3syb@va3bbs.#scon.on.ca.na| Try to assimilate the world!" #include disclaimer/favourite| -Pinkutus the Borg
