On Thu, 18 Mar 2004 16:38:55 -0800, Daniel Rogers wrote:

More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer.

You are bringing very good news here. Congratulations!

The final thing I want to do here is to seek out what people think about putting a "sponsors" section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too).

Do you think that it should be on developers.gimp.org, or www.gimp.org? Maybe both? Anyway, I think that it would be nice to mention our sponsors somewhere. Maybe this should be discussed on the gimp-web list?

[...] The ones I really need to run past everyone are 3, 4, 5, and 6 as those involve core gimp and I need to make sure that I am not going to be working on anything that would be outright rejected by the gimp developers. 1 and 2 are gegl territory, and I know I'll accept that work :-)

Most of the milestones seem reasonable, but I have some questions about how the GIMP integration would take place, especially regarding the plug-ins. Many of the current plug-ins are making more or less the same assuptions as the core regarding the bit depth of the images, etc. There is a lot of code to be re-written in the plug-ins and I expect them to be broken as soon as the format of the tiles is changed. I also expect that it would be difficult to fix them before some parts of the core become more stable.

I suppose that you did not include the plug-ins in your activity planning because that would be too much work for a single programmer (but maybe I am underestimating you? ;-)) So I am wondering how we will be able to coordinate the work and update the plug-ins. Will there be a phase during which there would be a call for volunteers for updating all of the plug-ins once the new interfaces to the core become more mature? Or would it be possible to provide some kind of backwards compatibility so that the transition could be spread over a longer period, with some plug-ins using the new API while some others would still use the old one through a compatibility layer?

Anyway, I am glad to see that the offer for sponsoring is becoming more concrete.

-Raphaël

Hi,

On Fri, 2004-03-19 at 01:38, Daniel Rogers wrote:

More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer.

Congratulations to us! This is good news for the future of GIMP/GEGL. A big thank you to Mark for sponsoring us.

The final thing I want to do here is to seek out what people think about putting a "sponsors" section on the new webpage, and devoting some space to thank Mark Shuttleworth for this (and hell, our past sponsers too). Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them.

If you provide the contents I will be happy to help formatting the press release using LaTeX as I've done with the current press release.

First my milestone list, as I sent to Mark Shuttleworth. Please tell me if it is sane.

From a quick read through I think the milestones look sane when taking

into consideration that one developer will work on them full time.

The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread.

Sincerely, Brix

On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted]

The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread.

I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones.

Regards, Dov

Sincerely,
Brix

Hi Dan,

Daniel Rogers wrote:

More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration.

Congratulations! :)

Also, I want to prepare a press release about this, and would like some help with that. I can write the content, but those current press releases are so purty, and I'd like any new one to look like them.

Can I suggest that you talk to Mark? He has more PR experience than any of us, and I'm sure that he would have some ideas to offer for a press release.

3. begin gimp integration
() Time for completion: about a month -- a. replace tile manager with data compatible GeglBufferedImage. This involves modifying the existing gimp-compositing system to use GeglImage, as well as modifying GimpImage and GimpColor to use GeglImage and GeglColor.

>

4. start adding deep paint
() time for completion: about 4-6 months -- a. modify GimpImage and GimpLayer to use a set of GeglOps. -- a. design a new file format (this has already begun), and start converting all the plug ins, core, and paint to use high bit depth (16 bit or float).

If you started 3 after 2.2, that would have a 3.0 milestone somewhere around here. Can I check, then, what exactly will get done here? Do we keep a PDB compat layer around so that plug-ins that don't get changed still work, but only on 8 bits per channel? Do we declare teh milestone complete when the core has support internally for floating point, so that only tools get converted first, and we start working on plug-ins afterwards?

I think that you're probably underestimating 4 by a bit, particularly since we will want a stable release at this point, which will mean (probably) a 3 month pre-release cycle like the one we've just had. Completion in 6 months is possible (with all plug-ins, I'm not sure), but that would make the 3.0 release next Summer - does that sound reasonable?

We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it...

6. The big ones
() Goal: start adding some long wanted features. a and b probably need to take place at the same time. () time for completion: about 6 months -- a. build the CMYK painting system. This will involve figuring out all the equivalent CMYK and RGB operations, and modifying the GIMP to use CYMK equivalent operations in place of RGB operations. -- b. add color management to the gui. -- c. add layer effects
-- d. add layer groups.
-- e. add clone layers.

Cool - this sounds like a plan.

At what stage do we turn plug-ins into nodes and replace the PDB with a node handler? I know that corba's a bad word, but how will plug-ins work after that?

Cheers, Dave.

Dave Neary wrote:

We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it...

Unless the code has changed a lot and I haven't noticed it (and looking I see it hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from GeglImage.

I'm not sure whether having GimpImage inherit from GeglNode, or contain a member GeglNode, makes more sense.

Kelly

Dave Neary writes:

We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it...

GeglImage can't replace GimpLayer, it can only replace TileManager. GEGL's scope is not to provide a replacement for GIMP's highlevel object system (GimpImage, GimpDrawable etc) but only for the lowlevel pixel storage buffers and the operations on/between them.

ciao, --mitch

Daniel Rogers writes:

From: Daniel Rogers
Subject: Re: [Gimp-developer] The Mark Shuttleworth offer To: gimp-developer@lists.xcf.berkeley.edu Date: Fri, 19 Mar 2004 06:54:34 -0800

Kelly Martin wrote:

Dave Neary wrote:

We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it...

Unless the code has changed a lot and I haven't noticed it (and looking I see it hasn't), you should be redesigning GimpDrawable (not GimpLayer) to inherit from GeglImage.

Actually, yes. Though GimpDrawable, GimpLayer and GeglImage all need to be touched.

Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one.

I'm not sure whether having GimpImage inherit from GeglNode, or contain a member GeglNode, makes more sense.

I believe GimpImage is a set of GimpLayers. It might even be able to stay that way.

It should stat that way I'd say.

ciao, --mitch

Michael Natterer wrote:

Actually no. GimpDrawable is a GimpItem is a GimpObject. It should *have* a GeglImage, not be one.

Yes, this is probably correct. Tempbufs should probably also be replaced by GeglImages, and the entire paint core replaced by GeglOp-related operations.

As I see it, GimpImage would contain a GeglNode, rather than inherit from it. There would be a contained GeglNode that would represent the current projection; it would be created from the existing layer & channel lists.

Part of the problem is that GeglNode can represent combinations that the GIMP doesn't support, and adding the UI support for those combinations is (remarkably) nontrivial. Also, there is not a one-to-one correspondence between GeglNodes and GimpLayers (some layers will generate only one GeglNode, others several, especially when layer masks are in use). Relying on "decompiling" the GeglNode to generate the Layers & Channels dialog seems unwise.

Kelly

On Fri, Mar 19, 2004 at 10:50:23AM +0200, dov@imagic.weizmann.ac.il wrote:

On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted]

The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread.

I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones.

A PDB revamp is planned.

While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts?

-Yosh

Manish Singh (yosh@gimp.org) wrote:

On Fri, Mar 19, 2004 at 10:50:23AM +0200, dov@imagic.weizmann.ac.il wrote:

On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted]

The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread.

I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones.

A PDB revamp is planned.

While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts?

Hmm, isn't there a perl-way to do named parameters? I bet there is (but I don't know about it).
After a quick search on google the following seems to be "standard":

gimp_perl_foo_bar (-image => image, -drawable => drawable, -radius => 5.5, -size => 300);

For scheme we could do something like this:

(script-fu-foo-bar '("image" image) '("drawable" drawable) '("radius" 5.5) '("size" 300))

or (less clutter)

(script-fu-foo-bar "image" image "drawable" drawable "radius" 5.5
"size" 300)

that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters.

Bye,
Simon

On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote:

Manish Singh (yosh@gimp.org) wrote:

On Fri, Mar 19, 2004 at 10:50:23AM +0200, dov@imagic.weizmann.ac.il wrote:

On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted]

The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Rapha?l already pointed that out in another reply to this thread.

I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones.

A PDB revamp is planned.

While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts?

Hmm, isn't there a perl-way to do named parameters? I bet there is (but I don't know about it).
After a quick search on google the following seems to be "standard":

gimp_perl_foo_bar (-image => image, -drawable => drawable, -radius => 5.5, -size => 300);

Yeah, I thought of that, but I'm not sure how you'd differentiate between named usage and positional usage.

With both

gimp_perl_foo_bar($image, $drawable, 5.5, 300)

and

gimp_perl_foo_bar(-image => $image, -drawable => $drawable, -radius => 5.5, -size => 300)

all perl hands the function is a list of values. CGI.pm tries to guess about this, but it's easily fooled if the actual data string you give it starts with '-'.

One way to do it would be:

gimp_perl_foo_bar({image => $image, drawable => $drawable, radius => 5.5, size => 300})

And check if we get a hash reference as our first arg, but that seems a bit nonobvious.

For scheme we could do something like this:

(script-fu-foo-bar '("image" image) '("drawable" drawable) '("radius" 5.5) '("size" 300))

or (less clutter)

(script-fu-foo-bar "image" image "drawable" drawable "radius" 5.5
"size" 300)

that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters.

Again there is the problem of differeniating between positional and named usage.

-Yosh

Manish Singh (yosh@gimp.org) wrote:

On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote:

For scheme we could do something like this:

(script-fu-foo-bar '("image" image) '("drawable" drawable) '("radius" 5.5) '("size" 300))

or (less clutter)

(script-fu-foo-bar "image" image "drawable" drawable "radius" 5.5
"size" 300)

that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters.

Again there is the problem of differeniating between positional and named usage.

Ok, thinking some more about it: What about using symbols as parameter identifiers?

(script-fu-foo-bar 'image image 'drawable drawable 'radius 5.5
'size 300)

passing symbols to the PDB doesn't make sense, so this could be used to differentiate.

Bye,
Simon

On Sat, Mar 20, 2004 at 01:34:02AM +0100, Simon Budig wrote:

Manish Singh (yosh@gimp.org) wrote:

On Sat, Mar 20, 2004 at 12:58:25AM +0100, Simon Budig wrote:

For scheme we could do something like this:

(script-fu-foo-bar '("image" image) '("drawable" drawable) '("radius" 5.5) '("size" 300))

or (less clutter)

(script-fu-foo-bar "image" image "drawable" drawable "radius" 5.5
"size" 300)

that having said: I don't have much experience with scheme outside script fu, so there might be a convention out there on how to do named parameters.

Again there is the problem of differeniating between positional and named usage.

Ok, thinking some more about it: What about using symbols as parameter identifiers?

(script-fu-foo-bar 'image image 'drawable drawable 'radius 5.5
'size 300)

passing symbols to the PDB doesn't make sense, so this could be used to differentiate.

That's a good idea. Unless there's some other standard way of handling this in scheme (anyone?) this sounds good to me.

-Yosh

See below...

----- Original Message ---

Simon Budig wrote:

Ok, thinking some more about it: What about using symbols as parameter identifiers?

(script-fu-foo-bar 'image image 'drawable drawable 'radius 5.5
'size 300)

passing symbols to the PDB doesn't make sense, so this could be used to differentiate.

The more Scheme-like approach would be to add a read syntax which instantiates a "parameter name" type. So, something like "(script-fu-f00-bar ::image image)" (:: being an arbitrary syntactic marker that I just made for which an appropriate syntax macro has been defined; you can theoretically use anything not already assigned to something else), which is internally expanded to "(script-fu-f00-bar # image)" which is then magically converted to however the PDB handles parameter passing by the appropriate Scheme-C glue code.

Not only is this more in keeping with how Scheme is generally used, it's conceptually much cleaner because it avoids overloading quoted interned symbols.

Kelly

For various reasons that I don't know about or don't completely understand, several of the proposals that have already been made may be far superior to what I am about to suggest. In fact, there could easily be some reason why my suggestion is completely unworkable. Never the less, I have worked with other languages where using named items based on the following simple syntax seems to work well, and I'm wondering if it might be a better alternative than some of the other suggestions:

(script-fu-foo-bar image="myimage" size=300)

Some languages allow unquoted parameter strings when the type can be identified based on the parameter name or value and there are no embedded blanks or other delimiters withing the parameter value. Some languages use single quotes instead of double quotes, and some languages allow both. Most languages with syntax along these lines also allow quotes characters to be doubled up in order to represent the occurance of a quote character within the parameter value.

Most of you guys are probably already very well aware of syntax like this, so it may not be possible or advisable here for some reason. But I just thought that I'd throw this idea out in case it was being overlooked and might solve any of the other problems that have been discussed.

s/KAM

----- Original Message ---

Kevin Myers wrote:

(script-fu-foo-bar image="myimage" size=300)

Defining syntax macros for such a syntax in Scheme is less than straightforward, and is also very un-Scheme-like.

Kelly

You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other "special" characters?

I am especially concerned about this issue, because previously I have found it almost completely impossible to pass appropriate parameter values to some otherwise very desirable gimp scripts from the Windows command prompt...

Thanks, s/KAM

----- Original Message ---

Kevin Myers wrote:

You seem to know what you're talking about Kelly, so I'll have to accept your word that my suggestion is un-Scheme-like. However, please verify one thing regarding your suggestion: How do you handle parameter values with imbedded blanks or other "special" characters?

(True) Scheme has a quoting mechanism for this issue, which is relatively well defined. It might be tricky to quote those quotes when you're using an inferior command shell (such as Windows Explorer), but this should be considered a fault of those environments -- and is certainly no reason to abandon the R5RS standard.

Kelly

Hi Kelly,

I understand your basic points, but...

Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows.

For example, in one past case, I wanted to run a simple GIMP script from the Windows command shell, and there wasn't one single person (Sven and everyone else included), who was able to tell me how to arrange the quoting to get the script to run along with the required parameters. That level of disfunctionality is not acceptable, and should be eliminated, even if it means doing something like "abandoning" (or modifying) certain *nix based standards for the Windows version of the GIMP.

Obviously though, I do realize the strong need to minimize any such Windows-specific behavior, and that any such differences should receive a great deal of very careful consideration before implementation. In the past however, I feel that the scale may have been tipped slightly too far against Windows on such issues.

s/KAM

----- Original Message ---

Kevin Myers wrote:

Hi Kelly,

I understand your basic points, but...

Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows.

Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product.

Kelly

Kelly Martin (kmartin@pyrzqxgl.org) wrote:

Kevin Myers wrote:

Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems.

Windows inhibits its own usability in this respect. It is nearly impossible to get imbedded quotes from the Windows command line. This is a defect in the Windows shell. Getting around it would force us to use some weird character for string quoting, which would be confusing to everyone. In my opinion, the sacrifice is not worth the gain: we should not have to do something Weird and Bizarre to cope with Microsoft's inferior product.

Also please consider, that scripting from the commandline is not the thing the average Windows- (and even Linux-) user needs. If a windows user really needs scripting, I'd recommend to install e.g. a bash.

The other option always is to use "gimp-1.3 --batch -" and pass the commands to execute to stdin.

Bye, Simon

Hi Kelly,

Though I basically agree with your opinion of the inferior Windows command shell, IMHO that doesn't excuse important GIMP features from being completely inoperable under Windows. Inconvenient is one thing, impossible another. I can appreciate your strong desire to avoid a kludge workaround, but at this point I'm not at all certain that the only possible solutions are quite as bad as your comments would imply. Never the less, I think that we have both probably expressed our opinions adequately on these issues at this point, and may simply have to agree to disagree in some respects, and let other developers and users weigh in to help determine the best approach.

I just wanted to help make sure that some concerns from the Windows side of the equation were voiced. I'll back off now and let the discussion resume between yourself and the other gimp gurus.

Regards, s/KAM

----- Original Message ---

Hmmm, I wonder why using the --batch option wasn't suggested when I ran into the problems that I mentioned previously...

Unfortunately, it has been so long ago now that I don't remember the details. I gave up trying after a couple of days of trial and error plus a number of related emails. I can't think of any reason at this point why that wouldn't have been a reasonable solution.

s/KAM

----- Original Message ---

On Fri, Mar 19, 2004 at 09:26:23PM -0600, Kevin Myers wrote:

Admittedly, the Windows command prompt (not simply Explorer) is less capable than most *nix command shells. However, there are also a very large number of Windows based GIMP users, and one of the requirements of GIMP 2.x is that it should be as usable under Windows as it is on other operating systems. I'm not familiar with R5RS, and you could certainly be right in your opinion regarding that. However, as a Windows GIMP user (and much more rarely a GIMP bug, patch, fix, and enhancement contributor), I want to make sure that there isn't excessive *nix bias that inhibits or ignores usability needs under Windows.

TheGIMP only exists for Windows(TM) because at the time, linux and scanners were not working so well together. The GNU/Linux bias is a fact. It is the only reason it exists.

For example, in one past case, I wanted to run a simple GIMP script from the Windows command shell, and there wasn't one single person (Sven and everyone else included), who was able to tell me how to arrange the quoting to get the script to run along with the required parameters. That level of disfunctionality is not acceptable, and should be eliminated, even if it means doing something like "abandoning" (or modifying) certain *nix based standards for the Windows version of the GIMP.

To avoid problems like this, linux developers are fairly good at following standards and all sorts of acronyms like api's and rtfm's -- there are more, i cannot remember them.

Writing web pages for internet explorer is very limiting and not fun as they have not adhered to browser standards. Are you making TheGIMP suck like this?

Obviously though, I do realize the strong need to minimize any such Windows-specific behavior, and that any such differences should receive a great deal of very careful consideration before implementation. In the past however, I feel that the scale may have been tipped slightly too far against Windows on such issues.

GNU/Linux is supporting scanners really well now. Perhaps you might be more interested in helping the Image Magick project as they have been running better from the command linue than from the GUI for years. It is available on Windows(TM) also.

carol

On Fri, Mar 19, 2004 at 10:11:53PM -0600, Kevin Myers wrote:

Hmmm, I wonder why using the --batch option wasn't suggested when I ran into the problems that I mentioned previously...

i was part of this discussion. you were given honest answers from the linux people developing TheGIMP. we all use Image Magick to do batch processing. The manpages are some of the best written and the convert, mogrify and other image magick commands usually come with every linux distribution.

if i need more than Image Magick can do, i write python scripts. All of the gimp scripts have a browser which should avoid any problems that a GIMP User on Windows(TM) should have.

also, if you really like to use the command line, why ever are you using Windows?

Unfortunately, it has been so long ago now that I don't remember the details. I gave up trying after a couple of days of trial and error plus a number of related emails. I can't think of any reason at this point why that wouldn't have been a reasonable solution.

i have a complaint about the way emails are being formated on what should be a repectable mail list. i am sending it in a different email.

carol

Hi Carol,

I/we are already users and contributors to the ImageMagick and GraphicsMagick projects as well as the GIMP. Both of those programs and the GIMP have certain key strengths and weaknesses with respect to each other, such that they are certainly not direct substitutes in *many* respects. That was certainly the case with our previous need regarding command line execution of a Gimp script under Windows. For another example, the GIMP can handle the size of our larger image files under Windows, while IM and GM still cannot. (IM and GM pixel representation in memory is always at least 40 bit (8x5), while the GIMP allows 8 bit memory representation, allowing roughly 5 times more pixels to be manipulated under Windows).

It is utterly ridiculous that simply because I voiced concerns about and would like for the ability to have gimp scripts execute properly from the command line under Windows that you accuse me of "making the GIMP suck". The suggestions that I offered earlier this evening were only thrown out for consideration, and I didn't try to force those down anyone's throat. All that I asked was that GIMP developers try to give adequate consideration to the needs of Windows based gimp users rather than selecting an implementation that I was worried might have an adverse impact.

Some bias towards Linux and other Unix based systems is completely understandable and acceptable to everyone. We all appreciate the deficiencies of Windows and its poor record of adhering to standards (though there are *many* similar examples in the *nix world as well). We also appreciate that the Linux community is making the biggest share of contributions to the GIMP development effort.

What I don't appreciate, is your apparent lack of sympathy towards users who have *no* choice but to run under Windows (for any of numerous reasons) and who simply desire to use the gimp (just as you claim to), and to help enhance it to meet *their* needs, just as you enhance it to meet your own needs under Linux. The gimp is an open source product, and is also supported and developed by Windows users, not just *nix heads. So what gives you the right to presume that only *nix developers can own and control the GIMP (as your comments seem to imply), and to ignore the needs of Windows based users and the feedback and proposals of Windows based contributors?

Your statements seem to imply that any user or organization who doesn't like the lack of certain GIMP features under Windows can just switch right over to Linux at a moments notice, and that simply is NOT the case in many situations. For example, in our own situation, we use several extremely complex, industry specific technical applications that simply do not exist for Linux. Other programs that we use do have Linux counterparts, but would require numerous man years of retraining, redevelopment of supporting applications, and data conversion in order to switch over, and many are *very* expensive applications that are *not* public domain, even under Linux, which we cannot afford to replace. Also, we can't afford a bunch of duplicate hardware to run both operating systems in parallel, nor can our work flows stand the wasted time of constantly rebooting to switch between applications running under the different operating systems. From an ideological standpoint, we would *love* to switch to Linux, immediately!!!

From a practicality and expense standpoint, we just can't do it, and there

are many other folks in exactly the same boat. To presume otherwise is to assume that you know everyone else's business better than they do, and I guarantee that you do NOT.

Our view seems to be quite different from yours. We believe that Windows based GIMP users should be able to make contributions (which BTW include comments and suggestions) that allow the gimp to work as effectively for us under Windows as it does for other folks under Linux, and *of course* at the same time not to do anything that would adversely impact Linux users. Apparently there are lots of other gimp users and contributors who feel the same way as we do. What doesn't seem right is that *some* Linux based developers don't seem to have any problem implementing features in such a way that it precludes effective use under Windows when it doesn't need to, or reject proposed development efforts by others that would benefit Windows users simply because there is no perceived benefit to the *nix community.

I'm not saying at all that has happened in this specific instance regarding the issues that I raised earlier this evening and the subsequent discussion. What I am saying Carol, is that some of you appear to be having a rather knee jerk reaction against someone else who is merely trying to help the GIMP better support the operating system that they are using, no different than anyone else who might happen to be using some other OS. If the approach that I suggested won't work or will cause real problems under another OS, that's fine. But what isn't fine is to say in essence "we don't care about Windows users and contributors, and we're not going to listen to their input", which is basically what I got out of your reply.

s/KAM

----- Original Message ---

Simon Budig writes:
> If a windows user really needs scripting, I'd recommend to install > e.g. a bash.

True, but doesn't necessarily help. The Win32 process invokation API (CreateProcess()) doesn't use a argument vector like Unix does. It uses a "command line". The argv that a C or C+++ main() receives has to be constructed from the command line that the operating system passes to it. (In the Microsoft C library there are exec*()-like functions that take an argument vector, but that argument vector is then joined together into a command line that is actually passed to the CreateProcess() API.)

Thus, there are many levels of quoting/unquoting/splicing/whatever going on starting from the command line you type into bash on Cygwin on Windows, ending at the argv passed to main(). If you value your sanity, you shouldn't try to pass a Scheme expression potentially requiring quotes, embedded spaces in arguments, whatever, to a program...

> The other option always is to use "gimp-1.3 --batch -" and pass > the commands to execute to stdin.

Unfortunately, in GIMP 1.2.x, that is explicitly disabled on Win32 in the source. I don't remember the exact reason for this, presumably because some detail in the GLib main loop Win32 implementation that would have prevented it from working anyway. It isn't disabled in the GIMP HEAD (i.e. 2.0preX) sources (and there has been some changes to the GLib main loop now and then), so it might even work. I'll have to check.

--tml

Please see below...

----- Original Message ---

On Sat, 2004-03-20 at 02:33, Kevin Myers wrote:

I may be completely out in left field, so feel free to correct me if my comments are off the mark...

I am worried that Sven's proposal may case some problems. I am uncomfortable with using a syntax that depends on what many languages and operating environments would consider to be unbalanced single quotes. I am worried that these could end up causing great difficulties for example, when starting the gimp with a script-fu script and related parameters from the command line, on either *nix, or especially under Windows. Does anyone else agree this could be a serious problem, or can someone essentially guarantee that it isn't?

Unbalanced single quotes are used very often in Scheme. A single single quote is used to indicate literal data. It is an integrated part of the Scheme language.

./Brix

Hi,

"Kevin Myers" writes:

Hmmm, I wonder why using the --batch option wasn't suggested when I ran into the problems that I mentioned previously...

I guess that people assumed you knew about it. After all, googling for "gimp batch" leads you directly to Adrian's nice batch tutorial which is a bit outdated but still valid in the important parts:

http://adrian.gimp.org/batch/batch.html

Sven

As Tor reminded me later, --batch doesn't work in gimp 1.2 under Windows, so that was the reason I couldn't use it.

----- Original Message ---

hello kevin,
On Sat, Mar 20, 2004 at 12:39:23AM -0600, Kevin Myers wrote:

Hi Carol,

I/we are already users and contributors to the ImageMagick and GraphicsMagick projects as well as the GIMP. Both of those programs and the GIMP have certain key strengths and weaknesses with respect to each other, such that they are certainly not direct substitutes in *many* respects. That was certainly the case with our previous need regarding command line execution of a Gimp script under Windows. For another example, the GIMP can handle the size of our larger image files under Windows, while IM and GM still cannot. (IM and GM pixel representation in memory is always at least 40 bit (8x5), while the GIMP allows 8 bit memory representation, allowing roughly 5 times more pixels to be manipulated under Windows).

It is utterly ridiculous that simply because I voiced concerns about and would like for the ability to have gimp scripts execute properly from the command line under Windows that you accuse me of "making the GIMP suck". The suggestions that I offered earlier this evening were only thrown out for consideration, and I didn't try to force those down anyone's throat. All that I asked was that GIMP developers try to give adequate consideration to the needs of Windows based gimp users rather than selecting an implementation that I was worried might have an adverse impact.

Some bias towards Linux and other Unix based systems is completely understandable and acceptable to everyone. We all appreciate the deficiencies of Windows and its poor record of adhering to standards (though there are *many* similar examples in the *nix world as well). We also appreciate that the Linux community is making the biggest share of contributions to the GIMP development effort.

What I don't appreciate, is your apparent lack of sympathy towards users who have *no* choice but to run under Windows (for any of numerous reasons) and who simply desire to use the gimp (just as you claim to), and to help enhance it to meet *their* needs, just as you enhance it to meet your own needs under Linux. The gimp is an open source product, and is also supported and developed by Windows users, not just *nix heads. So what gives you the right to presume that only *nix developers can own and control the GIMP (as your comments seem to imply), and to ignore the needs of Windows based users and the feedback and proposals of Windows based contributors?

Your statements seem to imply that any user or organization who doesn't like the lack of certain GIMP features under Windows can just switch right over to Linux at a moments notice, and that simply is NOT the case in many situations. For example, in our own situation, we use several extremely complex, industry specific technical applications that simply do not exist for Linux. Other programs that we use do have Linux counterparts, but would require numerous man years of retraining, redevelopment of supporting applications, and data conversion in order to switch over, and many are *very* expensive applications that are *not* public domain, even under Linux, which we cannot afford to replace. Also, we can't afford a bunch of duplicate hardware to run both operating systems in parallel, nor can our work flows stand the wasted time of constantly rebooting to switch between applications running under the different operating systems. From an ideological standpoint, we would *love* to switch to Linux, immediately!!!

From a practicality and expense standpoint, we just can't do it, and there

are many other folks in exactly the same boat. To presume otherwise is to assume that you know everyone else's business better than they do, and I guarantee that you do NOT.

Our view seems to be quite different from yours. We believe that Windows based GIMP users should be able to make contributions (which BTW include comments and suggestions) that allow the gimp to work as effectively for us under Windows as it does for other folks under Linux, and *of course* at the same time not to do anything that would adversely impact Linux users. Apparently there are lots of other gimp users and contributors who feel the same way as we do. What doesn't seem right is that *some* Linux based developers don't seem to have any problem implementing features in such a way that it precludes effective use under Windows when it doesn't need to, or reject proposed development efforts by others that would benefit Windows users simply because there is no perceived benefit to the *nix community.

I'm not saying at all that has happened in this specific instance regarding the issues that I raised earlier this evening and the subsequent discussion. What I am saying Carol, is that some of you appear to be having a rather knee jerk reaction against someone else who is merely trying to help the GIMP better support the operating system that they are using, no different than anyone else who might happen to be using some other OS. If the approach that I suggested won't work or will cause real problems under another OS, that's fine. But what isn't fine is to say in essence "we don't care about Windows users and contributors, and we're not going to listen to their input", which is basically what I got out of your reply.

s/KAM

----- Original Message ---

On Fri, 19 Mar 2004 dov@imagic.weizmann.ac.il wrote:

On Fri, Mar 19, 2004 at 08:56:36AM +0100, Henrik Brix Andersen wrote: [stuff deleted]

The only thing that struck me as missing was the work involved with porting the plug-ins to the new API, but Raphaël already pointed that out in another reply to this thread.

I very much hope that at least this time around, since so much is anyhow changed, the PDB will finally get the face lift and use named parameters instead of positional ones.

FYI: the version of libpdb in CVS already uses named parameters instead of positional ones.

Rockwalrus

Great. Now, when you say it I remember Sven mentioning it in the past. But I guess that this new interface is not exported yet to any of the language bindings? Is that correct? Any plans when this API will become active?

Regards,
Dov

FYI: the version of libpdb in CVS already uses named parameters instead of positional ones.

Rockwalrus

One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of:

gimp_foo -bar 3 -baz yellow

Having such an interface to the PDB has several advantages:

1. It would take care of the quoting problems from the shell. E.g.

gimp -nodisplay -cmd "my_logo -text foo -bg_color yellow" \ -cmd "save_image -img 1 -filename foo.png"
2. We could easily do recording and save into this format.

3. The format could easily be translated into script-fu, python, guile, etc.

Possibly I misunderstood Sven though, in which I take all the blame. ;-)

Regards, Dov

On Sat, Mar 20, 2004 at 08:09:56AM -0600, Kevin Myers wrote:

As Tor reminded me later, --batch doesn't work in gimp 1.2 under Windows, so that was the reason I couldn't use it.

----- Original Message ---

On Sun, Mar 21, 2004 at 09:55:36PM +0200, dov@imagic.weizmann.ac.il wrote:

Great. Now, when you say it I remember Sven mentioning it in the past. But I guess that this new interface is not exported yet to any of the language bindings? Is that correct? Any plans when this API will become active?

It's not actually used in any GIMP code yet, and it's not been discussed how well it fits in with GIMP's needs going forward. So there aren't really any concrete plans yet.

-Yosh

Hi,

Manish Singh wrote:

A PDB revamp is planned.

How far along is the planning? I have heard of Rock's libpdb, which I believe he wants to finish for 2.2, but I hadn't heard any concrete plans for the often-mentioned forthcoming PDB re-write.

What requirements would the new PDB have?

Cheers, Dave.

On Sat, Mar 20, 2004 at 12:39:23AM -0600, Kevin Myers wrote:

It is utterly ridiculous that simply because I voiced concerns about and would like for the ability to have gimp scripts execute properly from the command line under Windows that you accuse me of "making the GIMP suck". The suggestions that I offered earlier this evening were only thrown out for consideration, and I didn't try to force those down anyone's throat. All that I asked was that GIMP developers try to give adequate consideration to the needs of Windows based gimp users rather than selecting an implementation that I was worried might have an adverse impact.

FWIW, the suggestion was ill-researched. (foo image=bar) is so very very un-Scheme like, which is surprising to hear from someone who has apparently written scripts from scratch. It pays to be versed in the language you're dealing with.

Some bias towards Linux and other Unix based systems is completely understandable and acceptable to everyone. We all appreciate the deficiencies of Windows and its poor record of adhering to standards (though there are *many* similar examples in the *nix world as well). We also appreciate that the Linux community is making the biggest share of contributions to the GIMP development effort.

What I don't appreciate, is your apparent lack of sympathy towards users who have *no* choice but to run under Windows (for any of numerous reasons) and who simply desire to use the gimp (just as you claim to), and to help enhance it to meet *their* needs, just as you enhance it to meet your own needs under Linux. The gimp is an open source product, and is also supported and developed by Windows users, not just *nix heads. So what gives you the right to presume that only *nix developers can own and control the GIMP (as your comments seem to imply), and to ignore the needs of Windows based users and the feedback and proposals of Windows based contributors?

Except there are a number of ways already to workaround the deficiencies of the windows shell. Even if --batch - is broken, you could always save a script out to a file, put it in the scripts dir, and call it from the command line.

I'm not saying at all that has happened in this specific instance regarding the issues that I raised earlier this evening and the subsequent discussion. What I am saying Carol, is that some of you appear to be having a rather knee jerk reaction against someone else who is merely trying to help the GIMP better support the operating system that they are using, no different than anyone else who might happen to be using some other OS. If the approach that I suggested won't work or will cause real problems under another OS, that's fine. But what isn't fine is to say in essence "we don't care about Windows users and contributors, and we're not going to listen to their input", which is basically what I got out of your reply.

It's also better to research your suggestions a little, so that they don't sound completely out there, thereby reinforcing the viewpoint that Windows users are clueless.

-Yosh

On Sun, Mar 21, 2004 at 10:01:26PM +0200, dov@imagic.weizmann.ac.il wrote:

One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of:

gimp_foo -bar 3 -baz yellow

Well, we ship a scheme engine already, so writing and including yet another syntax parser seems kind of silly.

Having such an interface to the PDB has several advantages:

1. It would take care of the quoting problems from the shell. E.g.

gimp -nodisplay -cmd "my_logo -text foo -bg_color yellow" \ -cmd "save_image -img 1 -filename foo.png"

There's still quoting problems for strings with spaces in them, parsing arbitrary colors, etc.

2. We could easily do recording and save into this format.

Recording into scheme syntax is pretty easy.

3. The format could easily be translated into script-fu, python, guile, etc.

No translation needed for script-fu (and probably not guile either), and python, perl, etc. already have many implementations of lispy type syntax parsers, which is nicer than writing a whole new one.

-Yosh

On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:

Hi,

Manish Singh wrote:

A PDB revamp is planned.

How far along is the planning? I have heard of Rock's libpdb, which I believe he wants to finish for 2.2, but I hadn't heard any concrete plans for the often-mentioned forthcoming PDB re-write.

There hasn't been any real planning, other than planning to do some planning after 2.0 is out. All I was saying is that we haven't forgot about it.

What requirements would the new PDB have?

Not clear yet. I don't think we should really touch the PDB for 2.2, if we want to do a short release cycle for that.

There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support.

-Yosh

----- Original Message ---

On Sun, Mar 21, 2004 at 03:32:08PM -0600, Kevin Myers wrote:

----- Original Message ---

On Sun, Mar 21, 2004 at 03:32:08PM -0600, Kevin Myers wrote:

----- Original Message ---

On Sun, Mar 21, 2004 at 03:32:08PM -0600, Kevin Myers wrote:

----- Original Message ---

If it's important to you, you'll do the 10 mins of research and critical thinking needed.

Apparantly you could research this a whole lot faster than I can, which isn't surprising since you work with gimp development almost every day. It would probably take me more than that amount of time just to track down a valid link to the docs for the version of Scheme that the gimp actually uses, much less try to interpret it.

You raised your issue about quoting problems, but then you had time to follow up with a completely out there suggestion. So the "too busy" argument doesn't really fly.

You have *no* idea. I've been putting in 18+ hour days for months on end, trying to keep my company above water. I posted these suggestions (and this note) in the down time while I am waiting for my computer to complete other tasks.

It's not like we're planning on making any changes related to this near term, so I don't see the urgency.

The only urgency is this: I try to respond to things when I see them, when the potential for an issue occurs to me and while the topic is fresh on my mind. If I try to wait until later, then two bad things happen: 1) a lot of issues would get dropped, and more importantly 2) if I bring it up later then folks would claim that it was too late to change things and say why didn't you bring up your concerns sooner when this issue was being discussed?

Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond

in

the extremely arrogant and insulting manner of Carol's replies to the newsgroup?

Well, you brought up windows vs. *nix, when the issue is how Scheme works.

As mentioned, my concern was the command line syntax issue. I don't know all of the Scheme syntax rules. While I was writing my script with Scheme, I found it to be a very arcane language, with very little documentation available, *especially* for the apparantly outdated or non-standard version that the gimp seems to use. So, I thought that I should leave it up to the experts to decide whether my concerns or suggestions were valid, rather than trying to reach those conclusions on my own based on using either the wrong documentation, or misinterpreting the documentation due to being a neophyte with the language, especially considering the limited time that I had available.

Finally, *far* too much time and bandwidth has already been wasted on this discussion for all concerned. If folks could have simply explained that my suggestion wouldn't work, rather than making inflammatory statements, then all of this excessive discussion could have been avoided. I've already decided not to respond to Carol's further emails (even though I would like to defend my position) in order to keep from dragging this out further. I now have some idea of your gripes against my input, and hopefully you now have some idea of why my input was provided in the manner that it was. I doubt that anything further can be accomplished. So, how about if we just drop this now, and give all of the other folks on the list a break?

s/KAM

On Sun, Mar 21, 2004 at 05:57:04PM -0600, Kevin Myers wrote:

If it's important to you, you'll do the 10 mins of research and critical thinking needed.

Apparantly you could research this a whole lot faster than I can, which isn't surprising since you work with gimp development almost every day. It would probably take me more than that amount of time just to track down a valid link to the docs for the version of Scheme that the gimp actually uses, much less try to interpret it.

There isn't anything gimp specific. It's straight Scheme. The issue is that you didn't even bother to *try*. Show some respect by doing attempting a little research. Even if you don't get it, that's ok, but you should try.

You raised your issue about quoting problems, but then you had time to follow up with a completely out there suggestion. So the "too busy" argument doesn't really fly.

You have *no* idea. I've been putting in 18+ hour days for months on end, trying to keep my company above water. I posted these suggestions (and this note) in the down time while I am waiting for my computer to complete other tasks.

Same downtime could've been used for some research.

It's not like we're planning on making any changes related to this near term, so I don't see the urgency.

The only urgency is this: I try to respond to things when I see them, when the potential for an issue occurs to me and while the topic is fresh on my mind. If I try to wait until later, then two bad things happen: 1) a lot of issues would get dropped, and more importantly 2) if I bring it up later then folks would claim that it was too late to change things and say why didn't you bring up your concerns sooner when this issue was being discussed?

You said it was an important issue. If it's really important, you wouldn't forget it.

Also, it's clear that we're getting ready to put out a new stable release, after which there will be plenty of architecture dicussions when it'll be more relevant.

Finally, wouldn't you also agree that it is better to be polite when rejecting someone else's well intentioned suggestions, than to respond

in

the extremely arrogant and insulting manner of Carol's replies to the newsgroup?

Well, you brought up windows vs. *nix, when the issue is how Scheme works.

As mentioned, my concern was the command line syntax issue. I don't know all of the Scheme syntax rules. While I was writing my script with Scheme, I found it to be a very arcane language, with very little documentation available, *especially* for the apparantly outdated or non-standard version that the gimp seems to use. So, I thought that I should leave it up to the experts to decide whether my concerns or suggestions were valid, rather than trying to reach those conclusions on my own based on using either the wrong documentation, or misinterpreting the documentation due to being a neophyte with the language, especially considering the limited time that I had available.

But you twisted it into a windows vs. *nix issue, which is what Carol responded to. You really didn't have to do that. A more constructive line of thought is to perhaps enable other language bindings on the command line. Both perl and python work on windows too.

Finally, *far* too much time and bandwidth has already been wasted on this discussion for all concerned. If folks could have simply explained that my suggestion wouldn't work, rather than making inflammatory statements, then all of this excessive discussion could have been avoided. I've already decided not to respond to Carol's further emails (even though I would like to defend my position) in order to keep from dragging this out further. I now have some idea of your gripes against my input, and hopefully you now have some idea of why my input was provided in the manner that it was. I doubt that anything further can be accomplished. So, how about if we just drop this now, and give all of the other folks on the list a break?

Shouldn't have started with the whole unix bias thing to begin with...

But yes, let's drop it. We can discuss language bindings and batch mode in the content of 2.2 and beyond.

-Yosh

On 03/21/04 15:01, dov@imagic.weizmann.ac.il wrote:

One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of:

gimp_foo -bar 3 -baz yellow

Perhaps I'm being extremely dense, but couldn't there be an interface:

gimp -cmdfile

Surely notepad can handle funny characters and the name of the file is completely up to you so you can make it as shell-friendly as you'd like. GIMP could have some extra code to handle "text mode" files, but that's about all that would be needed ...

Chris

Perhaps I'm being extremely dense, but couldn't there be an interface:

gimp -cmdfile

I think that the existing --batch option is equivalent to what you are suggesting. Unfortunately that option doesn't work using Gimp 1.2.x under Windows. I haven't heard from anyone else and haven't yet tested myself to see whether this option works in gimp 2.0, but some of the developers seem to think there is a good chance that it might. I hope to get a chance to try it out again in the near future.

s/KAM

On 03/22/04 00:45, Kevin Myers wrote:

Perhaps I'm being extremely dense, but couldn't there be an interface: gimp -cmdfile

I think that the existing --batch option is equivalent

Ah, hmm. For some reason I had gathered that this option took the script on the commandline, which is where the metacharacter problem lie. I'll go back to my hovel and keep quiet, obviously never have used it.

Chris

From: "Christopher W. Curtis"
Sent: Monday, March 22, 2004 12:06 AM

On 03/22/04 00:45, Kevin Myers wrote:

Perhaps I'm being extremely dense, but couldn't there be an interface: gimp -cmdfile

I think that the existing --batch option is equivalent

Ah, hmm. For some reason I had gathered that this option took the script on the commandline, which is where the metacharacter problem lie. I'll go back to my hovel and keep quiet, obviously never have used it.

Then again, maybe I am the one who is missing something (again?). Since the --batch option hasn't previously worked under Windows, I haven't yet had the opportunity to try it (successfully) either. Guess I'll just have to install 2.0, and find out...

FWIW, it has been difficult for me to work up to this change so far, because other than the command line arguments issue, 1.2.4 has been generally working well for us, and my copy has some initial display scale customizations that I implemented and am somewhat loathe to give up. However, I know that Sven and company implemented some kind of alternate initial scaling that was intended to address essentially the same issues that I was trying to solve, so hopefully that will be adequate for our needs.

s/KAM

On Sun, Mar 21, 2004 at 12:56:32PM -0800, Manish Singh wrote:

On Sun, Mar 21, 2004 at 10:01:26PM +0200, dov@imagic.weizmann.ac.il wrote:

One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of:

gimp_foo -bar 3 -baz yellow

Well, we ship a scheme engine already, so writing and including yet another syntax parser seems kind of silly.

I actually forgot one advantage. A meta-character void syntax has the advantage of being friendly for command line interactive use. After all, who many people do you know who are using either perl or scheme for their default shell. ;-)

Dov

Christopher W. Curtis (ccurtis@aet-usa.com) wrote:

On 03/21/04 15:01, dov@imagic.weizmann.ac.il wrote:

One of the ideas that I believe Sven raised on irc, was that there should be a minimal and trivial interface to the PDB that is not based on any particular language but just consists of:

gimp_foo -bar 3 -baz yellow

Perhaps I'm being extremely dense, but couldn't there be an interface:

gimp -cmdfile

Surely notepad can handle funny characters and the name of the file is completely up to you so you can make it as shell-friendly as you'd like. GIMP could have some extra code to handle "text mode" files, but that's about all that would be needed ...

While gimp --batch indeed accepts a script fu command (the "-" argument is a special case to read the command from stdin) it is not that hard to work around the missing filename argument.

Simply write a script fu script (e.g. called "script-fu-my-script"), place it in the script directory (~/.gimp-2.0/scripts/) and invoke it via

gimp-2.0 --batch "(script-fu-my-script)"

thats it.

Bye, Simon

Hi,

"Kevin Myers" writes:

Perhaps I'm being extremely dense, but couldn't there be an interface:

gimp -cmdfile

I think that the existing --batch option is equivalent to what you are suggesting.

It is not equivalent but similar. To execute commands from a file you use

cat | gimp --batch -

and I really don't see why this should not work on Windows.

Sven

Sven Neumann writes:
> It is not equivalent but similar. To execute commands from a file you use >
> cat | gimp --batch -
>
> and I really don't see why this should not work on Windows.

Sorry, this is probably a very silly question, but could someone post a minimal example of the kind of Scheme code that file could contain?

The tutorial by Adrian that Sven referred to earlier in this thread didn't really help much, there was way too much "i don't know why this works but it does" in it... Like the business of using underscores instead of hyphens in one place.

Is there any way to get a verbose trace from the script-fu interpreter, or from the PDB mechanism?

--tml

On Mon, 2004-03-22 at 13:42, Tor Lillqvist wrote:

Is there any way to get a verbose trace from the script-fu interpreter, or from the PDB mechanism?

The Scheme interpreter in SIOD normally runs with its verbosity level set to 2. To change it, use '(verbose n)', where n is the verbosity level you wish to set. In the current code, there is no point in using a value of n greater than 5.

On Sun, 21 Mar 2004, Manish Singh wrote:

On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:

How far along is the planning? I have heard of Rock's libpdb, which I believe he wants to finish for 2.2, but I hadn't heard any concrete plans for the often-mentioned forthcoming PDB re-write.

There hasn't been any real planning, other than planning to do some planning after 2.0 is out. All I was saying is that we haven't forgot about it.

2.0 is out now. :)

What requirements would the new PDB have?

There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support.

Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object.

Distributed processing will soon be supported by libpdb using the WireSocket backend; this will be done by early May. Implementing WireSocket is one of the group projects chosen by some of the students in a class I am taking, so it will be done if they want a good grade. :)

UI generation is mostly out of the scope of libpdb. I would have to know more what is specifically meant by "UI generation" before I could comment on it.

Efficiency has yet to be addressed by libpdb, although some easy optimizations have been put in place. Serious optimization should probably wait until the feature requirements are more in place and reasonable profiling can be done.

GEGL node support opens a big can of worms, and there probably is no best solution. The first big decision to make is whether plug-ins should be written as GEGL nodes objects directly, or whether there should be a shim GEGL node that translates the operations into procedural calls not unlike those in the traditional GIMP api.

If we do use a translating shim, Libpdb seems like a good fit for this as well.

It seems like a real shame to lose GIMP's ability to run plug-ins out of process, so my vote is we rule out dynamically loading gegl nodes using GPlugIn as the only method, although we may want to be able to do it as an additional extra-fast method.

CORBA seems like a flexible choice here if we decide to make plug-ins implemented directly as gegl nodes. Although my guess is it would add somewhat more overhead than a hand-rolled gimp-specific method, it has the advantage of being more flexible than anything we could do, and also it would be something maintained by an outside group instead of another burden for us.

If we do decide to have plug-ins be native GeglNodes, I recommend that we still have a PDB for scripting purposes.

Rockwalrus

On Tue, Mar 23, 2004 at 01:22:23PM +0100, Marc Lehmann wrote:

On Fri, Mar 19, 2004 at 02:19:09PM -0800, Manish Singh wrote:

While on that subject, I'm wondering what a good way of representing named parameters in scheme and perl would be. Any thoughts?

This is natural, and common:

$obj->method (arg1 => value1, arg2 => value2, ...)

this, too:

$obj->method (-arg1 => value1, -arg2 => value2, ...)

as well as this:

$obj->method (Arg1 => value1, Arg2 => value2, ...)

All of these can be supported at the same time, and the difference between them is often seen as a style difference only.

However, there is no way of using the same method both with named parameters or not (unless your resort to other syntaxes like $obj->method (ARG1, value1, ARG2, value2), making ARG1 etc. global or worse).

Yeah, that is unfortunate, since the interface should support both named and positional interfaces (and combining the two in one call).

Especially with methods with just a single argument, forcing named parameters might not be the best thing (OTOH, you can make a difference between methods with single argument and more, but...).

Right now, a few things get autodetected because gimp-perl uses strong typing for the gimp objects (as opposed to e.g. C or scheme). All in all there would be no problem at all supporting named parameters (There is even a certain amount of support for that already in gimp-perl), but it will break existing scripts and make writing scripts slightly more tedious.

Well, this would go hand in hand with a plugin api redo, so scripts are gonna break anyway.

Personally though, I really want named parameters. Not at all because of me being able to remember arguments better (I think it's actually worse to have to remember the parameter names), but because it allows me to easily leave off arguments that can be defaulted.

Most of these arguments, however, are at the end, so even more important than named parameters would IMHO be default values for unspecified ones.

I once reworked the PDB code to allow variable number of arguments but left the check in for compatibility with existing plug-ins who expect all or nothing (ignoring the number of arguments actually passed; the API did provide this already).

So what would be a good way for perl to support both named and positional stuff? The only way I can think of still is to use a hashref for named parameters.

-Yosh

On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote:

On Sun, 21 Mar 2004, Manish Singh wrote:

On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:

What requirements would the new PDB have?

There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support.

Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object.

Have you given any thought on how to macroize interactive paint functions?

Distributed processing will soon be supported by libpdb using the WireSocket backend; this will be done by early May. Implementing WireSocket is one of the group projects chosen by some of the students in a class I am taking, so it will be done if they want a good grade. :)

Heh.

Maybe local UNIX sockets are faster than pipes. Would be good to benchmark.

UI generation is mostly out of the scope of libpdb. I would have to know more what is specifically meant by "UI generation" before I could comment on it.

Generate a UI from a PDB entry. Like a generalized -fu that the scripting languages currently have. This makes an easy way of generating property panes for nodes in a graph say, made out of PDB nodes.

Efficiency has yet to be addressed by libpdb, although some easy optimizations have been put in place. Serious optimization should probably wait until the feature requirements are more in place and reasonable profiling can be done.

Yeah. For macro recording things should to go through the PDB in the app itself, so the within process boundary case things should be lightweight and fast.

GEGL node support opens a big can of worms, and there probably is no best solution. The first big decision to make is whether plug-ins should be written as GEGL nodes objects directly, or whether there should be a shim GEGL node that translates the operations into procedural calls not unlike those in the traditional GIMP api.

If we do use a translating shim, Libpdb seems like a good fit for this as well.

Yes, that's undetermined.

It seems like a real shame to lose GIMP's ability to run plug-ins out of process, so my vote is we rule out dynamically loading gegl nodes using GPlugIn as the only method, although we may want to be able to do it as an additional extra-fast method.

CORBA seems like a flexible choice here if we decide to make plug-ins implemented directly as gegl nodes. Although my guess is it would add somewhat more overhead than a hand-rolled gimp-specific method, it has the advantage of being more flexible than anything we could do, and also it would be something maintained by an outside group instead of another burden for us.

I dunno. CORBA is pretty heavyweight, there isn't an ORB out there that does things efficiently.

If we do decide to have plug-ins be native GeglNodes, I recommend that we still have a PDB for scripting purposes.

A node has inputs and outputs, and so do PDB functions, so there isn't much difference there.

I've thought about doing a proxy GObject framework, which would allow IPC of arbitrary objects, but I haven't fleshed it out in my mind yet.

One thing I've thought about would be to use the object and type system features, like every PDB function is an object, with properties for parameters. A paramspec has everything we need: type, name, descriptions, defaults, possible bounds.

Maybe something like a PDB function is an object, you set properties on it, then run the execute method. Also have a print method for a textual representation. Then just instantiate and string together these objects, and run through then. Sort of like CellRenderers in GtkTreeView.

This might be a complete and total abuse of the object system tho, and not scale at all. I might do a quicky implementation and see.

Using paramspecs somehow is tempting though.

-Yosh

Manish Singh writes:

On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote:

On Sun, 21 Mar 2004, Manish Singh wrote:

On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:

What requirements would the new PDB have?

There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support.

Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object.

Have you given any thought on how to macroize interactive paint functions?

By simply passing an array of GimpCoords to the yet-to-be-generated core PDB wrappers, just as all core functions will have to be invoked via these wrappers to make marco recording possible.

ciao, --mitch

On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote:

Manish Singh writes:

On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote:

On Sun, 21 Mar 2004, Manish Singh wrote:

On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:

What requirements would the new PDB have?

There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support.

Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object.

Have you given any thought on how to macroize interactive paint functions?

By simply passing an array of GimpCoords to the yet-to-be-generated core PDB wrappers, just as all core functions will have to be invoked via these wrappers to make marco recording possible.

Well, something has to generate those coords, and something has to update the UI before painting is finished.

I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release".

-Yosh

Manish Singh writes:

On Fri, Mar 26, 2004 at 12:06:33PM +0100, Michael Natterer wrote:

Manish Singh writes:

On Wed, Mar 24, 2004 at 08:58:39AM -0800, Nathan Carl Summers wrote:

On Sun, 21 Mar 2004, Manish Singh wrote:

On Sun, Mar 21, 2004 at 09:44:25PM +0100, David Neary wrote:

What requirements would the new PDB have?

There's a number of issues to be addressed, like GEGL node support, efficiency, UI generation, distributed processing, and macro recording support.

Macro recording is already trivial with libpdb: you just connect to the appropriate signal of the Pdb object.

Have you given any thought on how to macroize interactive paint functions?

By simply passing an array of GimpCoords to the yet-to-be-generated core PDB wrappers, just as all core functions will have to be invoked via these wrappers to make marco recording possible.

Well, something has to generate those coords, and something has to update the UI before painting is finished.

I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release".

IMHO this is not a big issue, since even today PDB painting uses almost the same functions as interactive painting does. The only difference is that PDB painting flushes the stuff at the end while interactive painting flushes while painting.

So everything that would have to be changed is replacing the call to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo() and flush the display in between. Not a big deal i'd say.

(What I want to say is that painting has been abstracted well enough to enable stroke recording without changing too much).

But then you are right, maybe we need a new API because it's perhaps cleaner to just draw the stuff as we do now and to create the recorded entry on button_release()

ciao, --mitch

On Fri, Mar 26, 2004 at 06:53:28PM +0100, Michael Natterer wrote:

Manish Singh writes:

Well, something has to generate those coords, and something has to update the UI before painting is finished.

I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release".

IMHO this is not a big issue, since even today PDB painting uses almost the same functions as interactive painting does. The only difference is that PDB painting flushes the stuff at the end while interactive painting flushes while painting.

So everything that would have to be changed is replacing the call to gimp_paint_core_interpolate() by some_generated_pdb_paint_foo() and flush the display in between. Not a big deal i'd say.

(What I want to say is that painting has been abstracted well enough to enable stroke recording without changing too much).

But then you are right, maybe we need a new API because it's perhaps cleaner to just draw the stuff as we do now and to create the recorded entry on button_release()

Right, it wouldn't be hard to adapt the code to do this. But we should nail down a sane API...

We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno.

-Yosh

Manish Singh wrote:

I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release".

Especially when you consider the airbrush, which has time sensitivity as well as motion sensitivity. The general paint UI (used for paint/pencil/erase, clone, smudge/dodge/burn, and airbrush, IIRC) has to generate an drawing event for each drag. The airbrush also has to generate one for each timer tick while the mouse is down, whether or not a drag occurred. The other tools generate only one drawing event, at mouse release. The lasso can probably only generate one drawing event, at mouse release, but its event structure is considerably more complex than the rest. I'm not sure about the various vector-related tools.

This is nonsimple to begin with, and making it efficient is even more complex. You don't want substantial redraw delays while painting. I am not sanguine on getting this implemented in the desired three month window.

Kelly

Manish Singh wrote:

We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno.

You'd at least have to serialize all the events for the paintbrush and airbrush if you want the macro to be brush- and color- independent (that is, you are interested in capturing the motions used, rather than the result). You could save the serialization in a buffer and then spew it forth at the end, but I don't see any way around collecting the actual paint events.

This was a requirement when I was asked to this by my former employer back in 2000, and also a requirement for the guy who was trying to contract Wilberworks to do it back in 1998. I think a macro recorder that doesn't capture motion events will be of limited utility to users.

Kelly

* Kelly Martin [040326 21:12]:

Manish Singh wrote:

We could simply bypass the pdb for painting, and just emit "record this" on button release. But maybe it'd be better to have the pdb more involved, I dunno.

You'd at least have to serialize all the events for the paintbrush and airbrush if you want the macro to be brush- and color- independent (that is, you are interested in capturing the motions used, rather than the result). You could save the serialization in a buffer and then spew it forth at the end, but I don't see any way around collecting the actual paint events.

Ideally you want to implement this code in an resolution independent manner as well. Thus all motion events should be interpolated in some manner,. when zoomed out drawing freehand shapes are guaranteed to create coordinate quantification in the shape, unless the coordinates are interpolated, and ideally translated to a curve.

If a procedual GEGL operation is lying below,. you could just pass the controlpoints of the curve to the function,. at some level the bezier/spline curve could perhaps also be smoothed within a threshold, when using tools freehand, before passing it to the drawing op itself,. doing it in this manner allows parametric data to be cached for a more advanced and memory efficient undo op stack as well.

This was a requirement when I was asked to this by my former employer back in 2000, and also a requirement for the guy who was trying to contract Wilberworks to do it back in 1998. I think a macro recorder that doesn't capture motion events will be of limited utility to users.

Hi,

Kelly Martin wrote:

Manish Singh wrote:

I was asking more in terms of an API should look like. Interactive paint is more involved than say, a bucket fill, which is easily translated into to "call PDB bucket fill function on button release".

Especially when you consider the airbrush, which has time sensitivity as well as motion sensitivity.

This is nonsimple to begin with, and making it efficient is even more complex. You don't want substantial redraw delays while painting. I am not sanguine on getting this implemented in the desired three month window.

Perhaps I'm being over-simplistic, but couldn't we go for the partial solution of just recording plug-in events, via the existing PDB interface, and get ourselves most of the functionality that people need for very little effort?

Cheers, Dave.

On Sat, Mar 27, 2004 at 03:27:04AM +0100, Marc Lehmann wrote:

On Thu, Mar 25, 2004 at 07:48:59PM -0800, Manish Singh wrote:

So what would be a good way for perl to support both named and positional stuff?

It simply shouldn't. It should either do positional where it is useful and named where it is useful. Or always named. Everything else (like a hashref) is just madness and should be handled by a different interface (call_procedure_hashref...).

Please note that it doesn't make _any_ sense to have 100% named parameters for the majority of functions (e.g. all fucntions having an image, or layer etc. as leading arguments, as these should be handled using method syntax).

No, but it's nice to be flexible and have the option of doing things with method syntax or procedural syntax. Isn't an important Perl motto TMTOWTDI? :)

Perhaps the OO syntax should always expect named parameters, but non-OO syntax should offer both in some fashion, like a hashref, or some sort of marker to say "named parameters start here".

Most languages share this problem, so it would be interetsing how this would be solved in C for example (probably using a different interface).

Python supports positional and named arguments natively, and we've talked about workable solutions in Scheme.

In C it's a pain in the ass to call PDB functions at all, so no big deal to have two interfaces. But I'd like to do better in more dynamic languages.

-Yosh

David Neary wrote:

Perhaps I'm being over-simplistic, but couldn't we go for the partial solution of just recording plug-in events, via the existing PDB interface, and get ourselves most of the functionality that people need for very little effort?

It's really not all that useful if we don't have paint event recording.

Kelly

* Daniel Rogers [040320 14:10]:

Michael Natterer wrote:

Dave Neary writes:

We could even consider having a quickish stable release after 2.2 with just GeglImage replacing GimpLayer, which would give us a chance to work out any wrinkles in that milestone before we start really relying on it...

GeglImage can't replace GimpLayer, it can only replace TileManager. GEGL's scope is not to provide a replacement for GIMP's highlevel object system (GimpImage, GimpDrawable etc) but only for the lowlevel pixel storage buffers and the operations on/between them.

What I mean is that everywhere it makes sense to _delegate_ to gegl structures things should be made to do so. I did misspeak about GimpImage, I know it is not similar to a GeglImage (more like a graph or somesuch). GimpImage and GimpLayer just need to be modified to do their image processing work with GeglNodes.

---- start of mind dump ----

I don't know if I'm starting to hate XML, but I am at the moment editing a music video in vim, doing compositing in xml, and it is no fun. So I'll be lax on the syntax of xml transformation of my mind.

What would be exported is a model api,. the GimpImage model,. which is constructed using gegl.

The data stored in the GimpImage models data store is as follows:

make a mental %s/GimpGroup/GimpLayer/g or gimplist or whatever is pleasing,. this is a mental draft trying to translate some other internal datastructues.

_(GimpImage file='test.xcf.tar.bz' |
|___(GimpGroup
|
|___ GimplGroup label 'background' | |
| |___ GeglProvider type 'drawable', | | width '320', | | height '240' | | _gegl_node='0x??' | | _gegl_node is private | | and serialized to a | | png, tif, .geglswap or what | | ever file format, that | | we have a loder for | |
| |___ GeglFilter type 'colorcorrect', | | brightness '0.0', | | contrast '1.2', | | white_cb '0.0', | | white_cr '1.2', | | black_cb '0.1', | | black_cr '0.0' | |
| |___ GeglFilter type 'blur', | | radius '5px' | |
| |___ GeglFilter type 'stroke', | svgpath '? movto ?? ? lineto ??', | color 'rgb(0,0,0)', | opacity '(could be stored according to | parametric cruve', | brush '' |
|___ GimpGroup label 'svg layer', | | x '0.5', (which is also th | | y '0.5' e default values) | |
| |___ GeglProvider type 'svg', | resource 'svg_layer_0.svg' |
|___ GimpGroup label 'text layer'. | x '0.5'. (default) | y '1', | local_x '0.5', | local_y '1' (non default origin) |
|___ GimpGroup label 'noise group' |
|___ GeglProvider type 'blank', | color 'rgb(0,0,0,0)' | width '320' | height '240' |
|___ GeglFilter type 'noise' | scale '2.0' | xoff '0.0' | yoff '0.0' |
|___ GeglFilter type 'apply mask' |
|___ GimpGroup label 'layer mask' |
|
|___ GeglProvider type 'pango' | content 'pangomarkup' | font 'sans' | size '10.2' |
|___ GeglFilter type 'blur' radius '0.3'

At least I have some of my thoughts shared now,. hopefully in an attackable manner.

/Øyvind K.

On 18 Mar 2004, at 16:38, Daniel Rogers wrote:

So,

More details have come forward about the Mark Shuttleworth offer. Mark Shuttleworth made up his mind and decided to fund myself and Calvin to work on GEGL and GIMP/GEGL integration. Until today, I didn't have any specific details on the offer.

[etc.]

Any news since last month? Your announcement was followed by a flurry of excited comments, but not much since. ESA putting a Dutch 'tourist' into space this week suddenly reminded me of Here Be Bounties.