Re: [Gimp-developer] GNU/Linux vs. Linux
Simon Budig [EMAIL PROTECTED] writes: We should change it - to Unix. registered trademark :-( -- Still untested beyond 'it compiles' (davej) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] erase-rows.scm patch
Hi, (My apologies if this is the wrong forum for this message.) I've edited the Erase every other row script-fu so that the size of the rows can be changed. I can't find a contact address for the original author, so I've attached a patch. Thanks for your time, -- Rory Hunter Yes, but most people don't attack their boxes with the same cavalier abandon you do. -- Said when modding my box [fenriz.org] --- erase-rows.scm Mon Apr 8 15:10:31 2002 +++ erase-n-rows.scmMon Apr 8 15:09:41 2002 @@ -1,19 +1,33 @@ -(define (script-fu-erase-rows img drawable orientation which type) +;; [EMAIL PROTECTED] Mon Apr 8 14:35:49 BST 2002 +;; Added size parameter to control size of rows / colums +(define (script-fu-erase-rows img drawable orientation which type size_raw) (let* ((width (car (gimp-drawable-width drawable))) -(height (car (gimp-drawable-height drawable +(height (car (gimp-drawable-height drawable))) +(size (if (= orientation 0) + (if ( size_raw height) height size_raw) + (if ( size_raw width) width size_raw (gimp-undo-push-group-start img) (letrec ((loop (lambda (i max) (if ( i max) (begin (if (= orientation 0) - (gimp-rect-select img 0 i width 1 REPLACE FALSE 0) - (gimp-rect-select img i 0 1 height REPLACE FALSE 0)) + ;; [EMAIL PROTECTED] Mon Apr 8 14:33:47 BST 2002 + ;; Changed the code here to use a variable size + ;; for row / column width / height. + (gimp-rect-select img 0 i width size REPLACE FALSE 0) + (gimp-rect-select img i 0 size height REPLACE FALSE 0)) + ;; [EMAIL PROTECTED] Mon Apr 8 14:55:24 BST 2002 + ;; Handle extra operation (if (= type 0) (gimp-edit-clear drawable) - (gimp-edit-fill drawable BG-IMAGE-FILL)) - (loop (+ i 2) max)) + (if (= type 1) + (gimp-edit-fill drawable FG-IMAGE-FILL) + (gimp-edit-fill drawable BG-IMAGE-FILL))) + ;; [EMAIL PROTECTED] Mon Apr 8 14:35:24 BST 2002 + ;; Changed loop increment to variable + (loop (+ i (* 2 size)) max)) (loop (if (= which 0) 0 1) (if (= orientation 0) height @@ -21,17 +35,21 @@ (gimp-selection-none img) (gimp-undo-push-group-end img) (gimp-displays-flush))) (script-fu-register script-fu-erase-rows - _Image/Script-Fu/Alchemy/Erase every other Row... - Erase every other row/column with the background color - Federico Mena Quintero - Federico Mena Quintero - June 1997 + _Image/Script-Fu/Alchemy/Erase Rows... + Erase every n rows/columns with the background color + Federico Mena Quintero / Rory Hunter + Federico Mena Quintero / Rory Hunter + June 1997 / April 2002 RGB* GRAY* INDEXED* SF-IMAGE Image 0 SF-DRAWABLE Drawable 0 SF-OPTION _Rows/Cols '(_Rows _Columns) SF-OPTION _Even/Odd '(_Even _Odd) - SF-OPTION _Erase/Fill '(_Erase _Fill with BG)) + ;; [EMAIL PROTECTED] Mon Apr 8 14:55:54 BST 2002 + ;; Extra opertion - fill with FG colour. + SF-OPTION _Erase/Fill '(_Erase _Fill with FG _Fill with +BG) + ;; Added option for size. + SF-ADJUSTMENT _Row Size '(1 1 100 1 1 0 1))
Re: [Gimp-developer] GNU/Linux vs. Linux
On Fri, 5 Apr 2002, Kelly Martin wrote: The G in GIMP stood, once upon a time, for General. It was changed to GNU at Richard Stallman's insistence (but with the consent of SP, so it's not like it was completely hijacked). See the SP interview at http://www.xach.com/gg/1997/1/profile/1/. Yet another case where Stallman's zealous efforts to push his brand name on people was successful. How long before we have GNUburgers and GNUfries with our GNUlunch? :-) IMHO, we should say something in the first page of the manual and on the front page of the web site like: When we talk about Linux, we are talking about a combination of the Linux kernel and a large collection of tools contributed by a large number of individuals and some significant groups such as GNU, Xfree and BSD. Since we cannot credit everyone in every sentence, and for the sake of brevity, we call this system Linux. ...that should be enough to keep it clear. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
On Sat, 6 Apr 2002, Tomas Ogren wrote: On 06 April, 2002 - Simon Budig sent me these 0,7K bytes: Branko Collin ([EMAIL PROTECTED]) wrote: Should we change these instances to GNU/Linux? We should change it - to Unix. I guess that at most places Linux is simply wrong, because there is not really anything Linux specific in the GIMP. So the whole discussion is kind of pointless. .. and gimp runs on Windows too.. ;) Sure - when you are not referring to Linux *specifically*, you should use whatever more-generic term is applicable. That's not the issue though. The question is when you *are* talking specifically about Linux, what do you say? UNIX is a registered trademark though - you can't legally use it to refer to Linux. You can talk about UNIX-like operating systems - although that's rather a fuzzy term. Microsoft used to claim that WinNT was UNIX-like. Steve Baker (817)619-2657 (Vox/Vox-Mail) L3Com/Link Simulation Training (817)619-2466 (Fax) Work: [EMAIL PROTECTED] http://www.link.com Home: [EMAIL PROTECTED] http://www.sjbaker.org ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Preview widget for plugins
Hi, Maurits Rijk [EMAIL PROTECTED] writes: Ok, this has been discussed numerous times and seems to be quite high on the wishlist but it still doesn't really exist: a preview widget that can be used in all (or probably most) plug-ins. So I've taken up this challenge and started coding, heavily based on some work that has already been done in this area. However my approach is slightly different: instead of coding a perfect preview widget from the start I opted for the evolutionary approach: Step 1) first create a quick and dirty preview widget that really consists of code factored out from several plugins. This code relies on the deprecated GtkPreview widget. Main advantage of having this step is that it doesn't involve a lot of rewriting of the existing plugin code. This step has been succesful: I have changed the code from the max_rgb and the plasma plugin so they now both use my new preview widget. it's fine to temporarily use GtkPreview if you don't expose this fact thru the API. Step 2) update all plugins that already have a preview. Some of them will be easy, others might involve more rewriting or adding functionality to the preview widget. Step 3) once all plugins use the same preview widget it's time to replace the deprecated GtkPreview by another widget (GtkImage or GtkDrawingArea). In this step the API should be well established and be able to handle all preview needs. Step 4) update plugins that don't have a preview yet. So what's the current status? Well, I've finished step 1 and it seems to work :) Step 2 will take quite a bit more time, but will greatly clean up and reduce the current plugin code for all those plugins that use a preview. I expect this to take about 2 or 3 months. Step 3 will be relatively easy. Few evenings of hacking should be enough to do this. And finally, step 4, will be comparable with step 2: about 2 or 3 months. actually, I expect Step 3 to take less than 20 minutes. Just go ahead and introduce a preview widget based on GtkPreview and we'll port it to GtkDrawingArea for you. To sum up: before the end of the year all plugins for which this is appropriate will have a preview, using a common preview widget. I just hope Gimp 1.4 isn't already released before that time :) We definitely aim for a GIMP-1.4 release before the end of this year but I believe we can finish the plug-in preview task in this time schedule. What about sending a mail with the proposed API to the list so people are able to comment on it? Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
Hi, Kelly Martin [EMAIL PROTECTED] writes: The G in GIMP stood, once upon a time, for General. It was changed to GNU at Richard Stallman's insistence (but with the consent of SP, so it's not like it was completely hijacked). See the SP interview at http://www.xach.com/gg/1997/1/profile/1/. Yet another case where Stallman's zealous efforts to push his brand name on people was successful. How long before we have GNUburgers and GNUfries with our GNUlunch? and, would it hurt? As long as the FSF actually supports the ideals of Free Software and sometimes even pays for some GIMP hacker's burgers (or travel costs, whatever...), I don't care if there's a GNU brand name stamped on them. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Libgimpwidgets, libgimptool etc and ELF features
Hi, Tor Lillqvist [EMAIL PROTECTED] writes: There is a slight problem with the code in HEAD GIMP, that manifests itself at least on Windows, but probably also on other non-ELF platforms (AIX, others?). [...] Before this goes out of hand, could we please agree to stop assuming ELF features? Maybe even use -no-undefined on all platforms? To handle the dynamic linking either to libgimp or the gimp exe, why not use the features that GModule provides? g_module_symbol() on the result from g_module_open (NULL, G_MODULE_BIND_LAZY) searches the currently loaded shared libraries, *and* the application. Works also on Windows. sounds like a reasonable solution to me. Will you come up with a patch? Probably wait until we decided on the issue of pluggable tools so you don't complicate the task of backing out the plug-in tool code (in case we want to do that). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] amp photoshop curves
Hi, Nathan C Summers [EMAIL PROTECTED] writes: [...] as soon as I finish up with the tool plug-in work. actually Mitch and me are not overly happy with your recent commit. It appears that your code was based on an outdated version of the tools code so your commit seems to remove some of the fixes Mitch applied lately. You also removed some stuff like cursor changing etc. that was finally working. Our plan was to finally approach 1.4, not to steer the ship away from it evenb further. You catched us on the road to Guadec, so we haven't been able to react earlier and we haven't had much chance to look at the changes in detail. Hopefully we'll find some time to evaluate the changes in more depth tomorrow after our talk. At the moment, I'm favoring to back the tool plug-in changes out of the HEAD branch and to apply it to a separate branch so we have a chance to finish cleaning up and stabilizing the tools while you can continue to develop the tool plug-in infrastructure at the same time. More thoughts on this tomorrow... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
Hi, Branko Collin [EMAIL PROTECTED] writes: What is our stand on using the name Linux or the name GNU/Linux. I don't have any strong feelings about this, but the FSF has supported us gently in the past, so we should probably use GNU/Linux. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Curves files
Hi, regis rampnoux [EMAIL PROTECTED] writes: On 04-Apr-2002 Guillermo S. Romero / Familia Romero wrote: from 0 to 16, that's seventeen values! Can I delete this day? :] Days are deleted when deprecated ;-) But why 17? ( why not? ) My question was why 17 points in curves.c and gimp_curves_spline accept an array of 32 points ? What are the diff between the curves in curves.c and color_cmds.c ? well, gimp_curves_spline actually accepts an array of 32 integers, not points. Our spline curves are limited to 17 points (for no good reason except simplicity), so the maximal number of points should probably be 34. IMO this is simply a bug. I don't think we should fix it in gimp-1.2 since it would mean that newer plug-ins/scripts that depend on this feature won't work correctly on older 1.2 versions, but it should be definitely be fixed in 1.3. Would you mind filing a bug-report so we don't forget? A patch would be nice to have too (you need to change the .pdb file, not color_cmds.c). Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
