Martin Weber wrote: Here a list of buggy plugins in GIMP-1.1.16: snipped... Did you make bug reports of these? (http://www.xach.com/gimp/news/bugreport.html) 1. With 55 days (count'em) to a supposed release date, and lots of issues outstanding, Gimp needs all the resources it can possibly garner from the community. 2. Those of us on the periphery of support have time to lend - but perhaps only single-digit hours per week. 3, Expecting those of us on the periphery of support to go hunting through the mailing list wastes precious time that should go to the Gimp. 4. Mailing list "bug reports" are notorious for being incomplete. The form on the bug report page solicits pertinent information in an orderly manner, enhancing the possibility of a successful diagnosis. If you made bug reports that were not yet posted at http://bugs.gnome.org/db/pa/lgimp.html because of various latencies, then please accept my sincere thanks. Be good, be well Garry Osgood
On 5 Feb, Nick Lamb wrote: Please do not step forward and say "I'll do it", the time for that was in November or at the latest December, and there was conspicuous silence during my last Triage thread from those named to defend their code. You are right, it's time to cleanup. Unfortunately I don't know which code is in a better state to stay and which one has to go. Now is a good time to check-in fixes to code that you left in an untidy state (expect some File plug-in code in that vein) and to file bug reports for mysterious occurences that you've been putting up with during the development cycle. Me or Sven? And what "mysterious occurences"? Tell me, I'd like to fix them all... :) -- Servus, Daniel
On 5 Feb, Marc Lehmann wrote: Thats not the point. The point is effective user feedback. Now, where are the users? :) Here is one. If you are not a user you should not decide whats best for them. Especially not if you limit your horizon to a single person (yourself). I'm running tests with more or less experienced people to get some feedback. One of the common thoughts: The icons are very bad. Tigert? hint, hint -- Servus, Daniel
Just a proposal of how to deal with the plug-ins' CVS issue: 1 - Wait until 1.2 has been released. 2 - Remove _ALL_ the plug-ins from GIMP's main CVS. 3 - Create a separate CVS containing _ALL_ existing plug-ins. 3 - Create a set of packages containing groups of plug-ins. My idea is creating a place where everyone who creates a plug-in can place his work. And not only his code, but also web pages, demos, tutorials, ... It should be open to any kind of plug-in, not only those found interesting for the mainstream. Somebody should also prepare packages of those plug-ins, so users can easily choose which ones they need; one of such packages will contain the basic plug-ins, and will be shipped with GIMP's main package.
I'd really like to see the setting for default brush reappear. So much so that I'd do it myself. Hows this fit with the freeze? I hate to violate the freeze, esp since its been getting better. But I'm SO SICK OF THAT CALIGRAPHIC BRUSH (10x10)! Comments? I always use "Save device settings on exit", but I think having a default-brush in the gimprc which is not used is a bug. Go, fix it! Salut, Sven
On Sat, 05 Feb 2000 23:50:56 -0800, "Martin Weber" [EMAIL PROTECTED] said: Here a list of buggy plugins in GIMP-1.1.16: tileable blur plugin: the status bar is appearing in an extra window -- color exchange / color mapping plugins: color selection: you can choose a color but black is taken instead -- sample colorize plugin: when starting this plugin you get: Gtk-CRITICAL: file gtkwidget.c: line 3313 (gtk_widget_set_sensitive): assertion 'widget!=NULL' failed. -- max rgb / value invert plugins: the effect is only applied to a small rectangle -- curve bend plugin: no undo possible -- pnm plugin: When I save pbm in GIMP it is not saved as pbm but as pnm. Here's a novel idea: file bug reports, eh? Kelly
On Sun, Feb 06, 2000 at 02:18:24PM +0100, Eduardo Perez [EMAIL PROTECTED] wrote: How about: 1 - Wait until an installation manager of some kind is available My idea is creating a place where everyone who creates a plug-in can All there: gimp-plug-ins.sourceforge.net -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
On Sat, Feb 05, 2000 at 05:26:57PM +0100, [EMAIL PROTECTED] wrote: You are right, it's time to cleanup. Unfortunately I don't know which code is in a better state to stay and which one has to go. This has been mentioned at least three times on this list: one of them works, the other doesn't. Even a gimp-beginner can find this out in a minute or so. Serious question: are you reading this list, or are you ignoring what others write? I am not so sure anymore... -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
On Sun, Feb 06, 2000 at 11:41:50AM +0200, Tuomas Kuosmanen [EMAIL PROTECTED] wrote: If I remember correctly the progress window also happens on lot of the save plugins. In theory those all could be in the statusbar if the window has The api for that, however, is quite a hack. If you call the pdb function you get a seperate window (because there is no way to guess the display for you image). If you call the libgimp function gimp second-guesses on you. Since this plug-in is a script-fu (am I right?) a fix requires changes to the script-fu interpreter itself. After 1.2 I will happily introduce another of my break-everything patches that corrects this ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Tuomas Kuosmanen wrote: Martin Weber wrote: -- sample colorize plugin: when starting this plugin you get: Gtk-CRITICAL: file gtkwidget.c: line 3313 (gtk_widget_set_sensitive): assertion 'widget!=NULL' failed. I have no idea what this plugin is supposed to do? It doesnt seem to work like I expect (to colorize a image based on colors of another, right?) I was wondering too and looked at it, finding it broken in a few trivial ways (details coming soon to a ChangeLog Near You!) Input: 1. a desaturated RGB image 2a. a gradient OR 2b. an image with some saturated colors; it derives a gradient from such an image. What it does: Lets say the gradient (2a|b. however derived) ranges from red to cyan with grey in the middle range. The plugin colorizes the desaturated image in accordance with the gradient, so: 1. The shadows of the desaturated image colorize red 2. The midtones of the desaturated image colorize gray (which is not much at all ;) 3. The highlights of the desaturated image colorize cyan There are Image/Color/Level controls so mapping is not exactly linear and a few other toys that noisify the mapping that one can play with; these will be functioning when I commit the fixes (tomorrow, I think). Personally, I think similiar tricks may be pulled fully in the confines of the Curve tool, but as Marc pointed out, not everyone is a copy of me (or is it 'a copy of Daniel Egger'? I forget ... ;), so some people may find this plug-in to be lots and lots of fun. Be good, be well Garry Osgood
On Sun, 06 Feb 2000 19:04:12 -0500, "Garry R. Osgood" [EMAIL PROTECTED] said: Personally, I think similiar tricks may be pulled fully in the confines of the Curve tool, but as Marc pointed out, not everyone is a copy of me (or is it 'a copy of Daniel Egger'? I forget ... ;), so some people may find this plug-in to be lots and lots of fun. I've found Sample Colorize to be occasionally interesting, and certainly harmless. It should be an optional plugin post-1.2, but I see no reason not to include it in 1.2 if rendered relatively bug-free. Kelly
On Sat, Feb 05, 2000 at 09:00:19PM -0700, Michael J. Hammel wrote: The last comment I saw under this story said that a $2K award was given to "Wilbur the Gimp". Since Gimp has no non-profit (or for profit) organization, Not Wilbur. Wilber! Wilber! Wilber! :) Tuomas -- .---( t i g e r t @ g i m p . o r g )---. | some stuff at http://tigert.gimp.org/ | `---'
On 5 Feb, Tuomas Kuosmanen wrote: Argh.. I am used to toggle between paintbrush and pencil. Like I pointed out in my previous mail on this thread, I use the paintbrush as a "fine tuning" tool together with the "real" tool I am drawing with. And if it is the paintbrush, then there is no way to toggle fast between those.. clicking a checkbox every time instead of pressing a shortcut key sounds clumsy. We could add a plugin with toggles this per shortcut. Would that be sufficient? -- Servus, Daniel
4. Merging of some duplicate code pointed out by Martin Webber. There is no unnecessarily duplicated code. At least not a the places Martin pointed us to; he should have a closer look. Salut, Sven