Table Of Contents
| 1. | Gimp Contexts Revisited | ||
| 2. | Script Editor? | ||
| 3. | Dodge, Burn, and Smudge Tools | ||
| 4. | Build Broken on m68k | ||
| 5. | Shakedown on Plugins | ||
| 6. | Color Display Framework |
Mailing List Stats For This Week
We looked at 58 posts in 213K.
There were 23 different contributors. 10 posted more than once. 8 posted last week too.
The top posters of the week were:
1. Gimp Contexts Revisited
Archive Link: "[gimp-devel] GimpContext summary."
People: Marc Lehmann, Simon Budig, , Michael Natterer, Simon Bundig
Last week in issue #2, article 1 (gd19990620_2.html#1) , Michael Natterer started putting in his new code to have brush, color, and other contextual information within the Gimp. This thread continued this week, one of the more interesting sub-threads was concerning the PDB API.
The PDB is the procedural data base. It is a database of functions that the Gimp exports to plugins and scripts. As Michael was firming up parts of the new context API he asked if the active image should be stored in the context. Simon Bundig said that yes it should because then they could drop the redundant first argument in most of the PDB calls.
Marc Lehmann disagreed saying that this would cause more work when manipulating multiple image/layers. And "there is no fundamental way to draw the line between arguments and context. The best you cna do is craft an interface where most frequently changed arguments are _arguments_ and less frequently changed arguments get converted into context."
Simon replied:
Hmm - it depends. If you write a plugin to create an effect you probably only manipulate the current layer. So you have to give the drawable-argument in *nearly every* PDB-call - and it is always the same. Thats what I call redundant ;-)
If you create a plugin to modify the image-structure (reordering, whatever) you have to juggle with different drawables. In this case you are probably right.
What about this: PDB-Functions which work *on* the drawables take it from the Context. PDB-Functions which work *with* the drawables (i.e. dont change the image- data on it) get the drawable as an argument.
Marc replied that if they take the drawable argument out they would need to replace it with a really good API. One much better than what Simon was proposing.
Jay proposed that they keep the drawable argument and the active drawable in the context but that the drawable in the context shouldn't be used over the drawable argument.
Also thought there should be a PDB drawable argument value which got the active drawable value from the current context.
The conversation continued as the team worked on hammering out more potential problems with the system.
2. Script Editor?
Archive Link: "[gimp-devel] script editor?"
People: pixel fairy, , Marc Lehmann
pixel fairy wrote:
just a thought for ease of use, in maya (and, i believe, photoshop 5) you can see a set of commands as they are used, hightlight them, and set them aside as a script, usually with a little tweaking. all this would take is a gimp window translating the users actions into script-fu statements, perhaps add this to the script fu console (turning it into a maya style script editor i guess.
of course theres still the questions of which language ( scheme? perl? cobol?)
Marc Lehmann replied that he thought there already was someone working on a PDB tracing facility to make something like this possible, but that it was difficult to do because the gui would need to use the PDB.
As far as language choice went Marc said it would be in the neutral PDB which could then be easily translated to the language of choice.
3. Dodge, Burn, and Smudge Tools
Archive Link: "[gimp-devel] dodge burn, and smudge"
People: , Jay Cox
Calvin Williamson wrote that he had written dodge, burn, and smudge tools for the gimp. Also, for approval, he posted the basic algorithm he used for creating the tools behaivior. He was also unsure how it would fit in with the new context system.
Jay Cox replied that he should commit it into the CVS right away, and not to worry about contexts yet.
4. Build Broken on m68k
Archive Link: "[gimp-devel] [Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de>] Bug#39863: gimp1.1_1.1.6-1(unstable): patch for m68k needed"
People: , Sven Neumann
Roman Hodek found a bug in the 1.1.6 release on the m68k that had to do with the mpeg plugin assuming the byte order incorrectly. Sven Neumann pointed out that it should just be using the byte order routines in glib and not do the fiddling itself. Shortly thereafter Yosh said he had it changed already.
5. Shakedown on Plugins
Archive Link: "[gimp-devel] Plugin Reorg"
People: Manish Singh,
Not horribly important news but Manish Singh wrote: "I'm going to be shuffling around the plugins in CVS (getting rid of that one dir per plugin hell) approximately one hour from the date this message was sent. I'm going to lock the cvs dir, so don't try to checkout or commit or anything, since it won't work."
And that was all that was said.
6. Color Display Framework
Archive Link: "[gimp-devel] Color Display Framework"
People: Manish Singh,
In a more interesting message Manish Singh wrote: "I've come up with a framework for doing display color correction using dynamically loaded modules. The idea is that just before we send the pixels to the display (most likely in image_render.c) we pass the color values and coordinates through a transformation function."
With a system like this different color correction plugins can be loaded and unloaded on demand. As of KC Gimp press time there has been no comment on Yosh's proposal, but it sounds neat so far.
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0. |