Hi,

Kevin Cozens writes:

In the file plug-ins/script-fu/script-fu-scripts.c is a typedef for SFScript. The third member is 'description'. The contents of the structure is filled in by the routine script_fu_add_script() further down the file. This routine is processing the arguments of the script-fu-register call located at the end of a Script-Fu based script. It uses the second argument of script-fu-register to set the value of 'description' in the SFScript structure.

I see this as misleading. It is not a description of the script but more of a menu path. The following item (referred to as 'help') contains more in the way of an actual description of a script.

I think it would make more sense to change 'description' to something like 'menupath'. It would be more indicative of its actual use.

Well, it is not only used as a menu-path but also as a (short) description. Basically, Script-Fu is a mess. Wouldn't you want to rewrite it? We keep looking for someone who wants to redo Script-Fu for quite a while already.

Sven

Hi,

Kevin Cozens writes:

On Tue, 2004-02-03 at 04:48, Sven Neumann wrote:

Well, it is not only used as a menu-path but also as a (short) description. Basically, Script-Fu is a mess. Wouldn't you want to rewrite it? We keep looking for someone who wants to redo Script-Fu for quite a while already.

Looking at that again, you are right (of course). The menu path shows up in the second line titled 'Blurb:' in DB Browser. This is good. I remember a long time ago when this wasn't there. I would find something in the browser I wanted to use but had trouble tracking down where it was in the menus.

I do seem to have painted a target (or at least a sign) on my back as Script-Fu maintainer over the last number of days. :-)

AFAIK, the Script-Fu stuff seems to be working. When you say you want someone to redo it, can you be more specific as to what you feel needs to be done to it?

Probably the worst thing with the current Script-Fu interpreter is that its error reporting sucks. This makes it very hard to debug scripts. Then, the interpreter doesn't provide a full implementation of SIOD. There are a few things missing that would be extremely useful. For example functions to deal with the file-system so that one could write scripts that operate on directories or files that match a regular expression.

All of this would probably be best solved by redoing Script-Fu using a full-featured and actively maintained Scheme implementation. Perhaps things would also already improve if the SIOD implementation in Script-Fu would be updated to the latest release which is, iirc, albeit being 8 years old, still two years newer than what we use currently.

Another thing that could be considered is to use a dedicated interpreter instance for each script. Currently you cannot run two or more scripts simultanously.

the moment I hit a call to write_channel and the GTK+ documentation I have often found lacking. I'll try and track down some good GTK+ tutorials since I want to be able to do more GUI related programming in Linux.

I suggest you also make yourself comfortable with GObject and would like to point you to this very nice tutorial:

http://le-hacker.org/papers/gobject/

Sven

Sven Neumann wrote:

All of this would probably be best solved by redoing Script-Fu using a full-featured and actively maintained Scheme implementation.

Might I suggest Guile?
http://www.gnu.org/software/guile/guile.html

It seems almost ready made to be stuck into the gimp.

-- Dan

In regard to: Re: [Gimp-developer] Misnamed structure element in SFScript...:

All of this would probably be best solved by redoing Script-Fu using a full-featured and actively maintained Scheme implementation.

Years ago, there was talk of switching to Guile, since that's what the GNU people were (are?) pushing as the language for scripting applications. I don't recall ever seeing why that was rejected, but talk of replacing SIOD with Guile just kind of died.

Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD?

Tim

On Tue, Feb 03, 2004 at 11:52:29PM +0100, Sven Neumann wrote:

Another thing that could be considered is to use a dedicated interpreter instance for each script. Currently you cannot run two or more scripts simultanously.

Another problem that could be solved with this measure is that script-fu no longer needs to be in memory all the time and would get rid of the delay caused on startup.

On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney wrote:

Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD?

As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own.

(These are not my arguments, I just repeat what I think was one of the bigger points back then).

Marc Lehmann (pcg@goof.com) wrote:

On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney wrote:

Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD?

As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own.

(These are not my arguments, I just repeat what I think was one of the bigger points back then).

It was a point that I indeed support very strongly :)

IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well).

I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him "drop this file in that directory and invoke it" and I don't have to care whats his platform and what interpreters are installed.

So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates.

Bye,
Simon

Simon Budig wrote:

Marc Lehmann (pcg@goof.com) wrote:

On Tue, Feb 03, 2004 at 05:30:19PM -0600, Tim Mooney wrote:

Does anyone know any good reasons why Guile would be an inappropriate choice for replacing SIOD?

As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own.

(These are not my arguments, I just repeat what I think was one of the bigger points back then).

It was a point that I indeed support very strongly :)

IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well).

I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him "drop this file in that directory and invoke it" and I don't have to care whats his platform and what interpreters are installed.

This is, I think, really shooting ourselves in the foot. By making this choice, we are choosing to use a broken, out-of-date, scheme interpreter when _much_ superior alternatives exist, because we don't want to force installers in have to install another library. Isn't that what installers do!? Guile is specifically designed to be an extension language for applications. It is a shared library. It is a perfect replacement for the gimp's soid bundle.

The problem I see with this argument is:

You are turning a packaging problem into a design choice. Suppose, for example, we choose to make siod a seperate dynamically linked library (included in the gimp sources, even). What is the difference between forcing you to install soid, and forcing you to install guile?

The "not-creating-another-depency" argument is an illusion. soid is already a dependency. It is just a dependency we choose to include in the sources. Why did we do this? Is jpeglib included in the gimp source tarball? What about libppm? libpng? These are all dependencies. Should we include those in the tarball as well?

It is true enough that you can argue that jpeglib is not as important as siod because you can disable the jpeg plugin on the configure command line. But this can be true for soid as well. While I don't immediatly see a ./configure option to disable script-fu, there is no technical reason why we can't have a configure option that disables script-fu. In fact, because you can disable script-fu, you cannot gaurentee that there exists a script system at all, let alone script-fu.

Basically, the only real way to ensure that every single instance of the gimp has a scripting language installed is to package the gimp for every platform ourself. Not moving to something besides siod is *crippling* to our supported, which should be the best, extension language.

So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates.

Guile is in all ways superior to siod, and is even self contained. We could even include a version of Guile in the tarball, which is what we do now with soid anyway.

--
Dan

Daniel Rogers writes:

As far as I remember, it was because it adds a rather big dependency, and people thought that gimp should come with at least one script interpreter on it's own.

(These are not my arguments, I just repeat what I think was one of the bigger points back then).

It was a point that I indeed support very strongly :) IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well).
I don't want to tell a newbie on Windows to install Python, because he
needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him "drop this file in that directory and invoke it" and I don't have to care whats his platform and what interpreters are installed.

This is, I think, really shooting ourselves in the foot. By making this choice, we are choosing to use a broken, out-of-date, scheme interpreter when _much_ superior alternatives exist, because we don't want to force installers in have to install another library. Isn't that what installers do!? Guile is specifically designed to be an extension language for applications. It is a shared library. It is a perfect replacement for the gimp's soid bundle.

(...)

I agree 100% with everything Daniel said. SIOD is unmaintained crap from the stone age. We should ditch it and use guile instead.

ciao, --mitch

Hi,

Michael Natterer writes:

I agree 100% with everything Daniel said. SIOD is unmaintained crap from the stone age. We should ditch it and use guile instead.

I think the best approach will be to develop a Script-Fu replacement based on Guile (or another interpreter) separately from Script-Fu. When this implementation is mature enough to provide a way to run the existing scripts, we can drop Script-Fu.

Sven

Daniel Rogers (daniel@phasevelocity.org) wrote:

Simon Budig wrote:

IMHO we should have at least one language where we can rely on the availability on *every* gimp installation. Basically this is impossible to guarantee for all languages that are packaged separately (like Perl, Python and Guile as well).

I don't want to tell a newbie on Windows to install Python, because he needs it to e.g. run a simple script that applies a curve that depends on the current foreground color... (just a silly example). It'd be better to tell him "drop this file in that directory and invoke it" and I don't have to care whats his platform and what interpreters are installed.

This is, I think, really shooting ourselves in the foot. By making this choice, we are choosing to use a broken, out-of-date, scheme interpreter when _much_ superior alternatives exist, because we don't want to force installers in have to install another library.

I think you missed my point. I am not advocating for script-fu over guile (or that is not my main point), I am advocating for a simple self-contained language, that is included with the GIMP sources. Lets call it Gimp-Basic.

Isn't that what
installers do!? Guile is specifically designed to be an extension language for applications. It is a shared library. It is a perfect replacement for the gimp's soid bundle.

The problem I see with this argument is:

You are turning a packaging problem into a design choice. Suppose, for example, we choose to make siod a seperate dynamically linked library (included in the gimp sources, even). What is the difference between forcing you to install soid, and forcing you to install guile?

The difference of course is, that Gimp is most likely the only application using SIOD and we would have full control over the version we deliver. I have no idea how GUILE usually is distributed, I was assuming that GUILE gets distributed similiar to Perl or Python. [Assuming this is true, I might be wrong here:] When we'd use GUILE (as the "Gimp-Basic") and the user uses Guile for different tasks he obviously would expect that GIMPs Guile is the same as his GUILE. Having our own Guile in the Installer would be a bad idea then, either because of e.g. Windows DLL hell or because of two different versions.

The "not-creating-another-depency" argument is an illusion. soid is already a dependency. It is just a dependency we choose to include in the sources. Why did we do this? Is jpeglib included in the gimp source tarball? What about libppm? libpng? These are all dependencies. Should we include those in the tarball as well?

Well, supposing SIOD were a library, it is perfectly natural to include SIOD, because it is not as universally available as the other libraries. Having libraries in the GIMPs tarball already has happened...

It is true enough that you can argue that jpeglib is not as important as siod because you can disable the jpeg plugin on the configure command line. But this can be true for soid as well. While I don't immediatly see a ./configure option to disable script-fu, there is no technical reason why we can't have a configure option that disables script-fu. In fact, because you can disable script-fu, you cannot gaurentee that there exists a script system at all, let alone script-fu.

[there used to be a dependency on the SIOD interpreter for parsing batch commandlines, but IIRC this is gone now]

All true and well, but my point is: I *want* to have a scripting system that is available almost universally. And this is the reason why siod is much more important than libjpeg right now. The scripting system not necessarily has to be Script-Fu, but it did the trick for at least six or seven years now...

Basically, the only real way to ensure that every single instance of the gimp has a scripting language installed is to package the gimp for every platform ourself. Not moving to something besides siod is *crippling* to our supported, which should be the best, extension language.

So we should have at least one self contained language that comes with the GIMP. I am not exactly tied to Script-Fu, but I don't see any other obvious candidates.

Guile is in all ways superior to siod, and is even self contained. We could even include a version of Guile in the tarball, which is what we do now with soid anyway.

I indeed would be very happy if I could write all my scripts in Python, but this is not an option, since I cannot assume that Python is available on all gimp installations. Thats why I write most of my scripting stuff in Script-Fu, and it works. Ok, sometimes it is a pain to debug (I think most of the debugging problems could be solved by evaluating errobj instead of displaying a silly "see errobj" message), but when the script is completed it is plug'n'play.

Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations.

Bye, Simon

Hi,

Simon Budig

Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations.

I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then.

Sven

Hi,

Sven Neumann wrote:

Simon Budig

Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations.

I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then.

I'm with Simon - at least one scripting language installation's a good idea. We might assume that perl or python are more or less universally available, but we can certainly not assume that guile is always installed. Given the fact that script-fu has historically been the reference language binding (and it continues to be), we should go out of our way to make sure it's available, IMHO.

Dave.

Hi,

Dave Neary writes:

I'm with Simon - at least one scripting language installation's a good idea. We might assume that perl or python are more or less universally available, but we can certainly not assume that guile is always installed. Given the fact that script-fu has historically been the reference language binding (and it continues to be), we should go out of our way to make sure it's available, IMHO.

It's just a packaging issue. As long as we make sure that everyone can install gimp-script-fu, we have script-fu support. Do you really want to continue to include it with GIMP with all the problems that arise from doing that? I don't think it's worth it.

In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do. The sooner it happens the better. Actually I was considering this for 2.2 (along with gimp-python). We are not doing ourselves a favor if we treat Script-Fu any better than other language bindings. Especially since it is technically the worst of them all.

Sven

Dave Neary (dneary@free.fr) wrote:

We might assume that perl or python are more or less universally available, [...]

Please note that this definitely is wrong. We have a Windows user base and they most probably don't have Perl or Python installed. Otherwise I wouldn't bring this topic up.

Bye, Simon

Hello,

Sven Neumann wrote:

It's just a packaging issue. As long as we make sure that everyone can install gimp-script-fu, we have script-fu support. Do you really want to continue to include it with GIMP with all the problems that arise from doing that? I don't think it's worth it.

Including guile doesn't mean supporting it. As it is, there are a bunch of things we include that don't get much support because the original authors have gone their own way. This time we're not even talking about *pretending* that this is a GIMP thing - we set up a configure script that checks if there's a local guile installed, if there is it uses it, otherwise it calls configure && make on its copy, and uses it in the GIMP. It is the same thing as we currently have, except that instead of George Carrette's SIOD, we'll be using GUILE. And this time, we will be using an official release of a scheme interpreter, not a GIMP modified copy. I don't see a downside.

In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do.

There is a certain point at which this is unreasonable. If we move all the C plug-ins out into another module, and all the brushes, patterns and other data to another module, and all the script-fu and python-fu to separate modules, we'd have a small, stripped down core, but a usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to download, and 6 or 7 packages to maintain.

The sooner it happens the better. Actually I was considering this for 2.2 (along with gimp-python). We are not doing ourselves a favor if we treat Script-Fu any better than other language bindings. Especially since it is technically the worst of them all.

I'm afraid that moving all of the langauge bindings out of the core would only result in the bindings not being maintained as well. As it is, the Python bindings are in need of a bit of a work-over before 2.0, if I remember correctly, and script-fu itself is only getting the minimum of maintenance for it not to be broken.

Anyway - working towards a minimalist GIMP is kind of going away from what I'd like to see. I'd be more interested in being pretty liberal about the patches and plug-ins we accept in the core, and get more plug-in authors involved in maintenance work and development. For that we need to define guidelines for getting a plug-in into the core, and get the word out that we're interested in more or less anything and everything to do with image processing. Hand in hand with that we would also need guidelines for when a plug-in would get dropped (temporarily?) from the distribution if it is unmaintained. If we have decent guidelines, this would add very little work for maintainers, who could just let plug-in authors take care of their own code.

Cheers, Dave.

Ooops, that should have been gone to the ML as well...

Sven Neumann (sven@gimp.org) wrote:

Simon Budig

Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations.

I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately.

It is pretty easy to see why a default scripting language is important, and I guess it is your grumpiness against script-fu that prevents you from seeing it.

When somebody on IRC has a problem that is cumbersome in the UI, but can be solved with three or four PDB calls (e.g. "Flip Layer menu entry") I'd hate to tell him that he has to install a monster like Perl/Python or whatever, to be able to use my quickly hacked three line solution. And even if he has Perl installed, I could not provide a script for him, because I only know about Python and Script-Fu. I don't want to be a master in all bindings available for gimp, just to be able to provide such a thing. I want to focus on one or two languages.

This has happened in the past and Script Fu was a nice solution for stuff like that. And that is the reason why it is important to have a simple language available always.

Bye, Simon

On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann wrote:

I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then.

I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already.

(and the rest should easily be prepared to deal with installing things from source).

To me it's all a matter of the installer.

Simons agruments, however, smell a lot of "standard gimp extension language", because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts.

pcg@goof.com ( Marc) (A.) (Lehmann ) wrote:

On Thu, Feb 05, 2004 at 01:06:58PM +0100, Sven Neumann wrote:

I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately. If we can make sure that the language extensions work and can be easily installed that should be good enough then.

I think this is already reality, as most people will get gimp from a gnu/linux distribution and many if not most of them will ship these extensions as seperate packages already.

Actually, most GIMP users probably get their GIMP from Jernej - OK - the GNU/Linux side of things gives us a nice big install base on Linux, but proportionately very few Linux people actually *use* the GIMP. I'd guess that the majority of our power users are on Win32.

(and the rest should easily be prepared to deal with installing things from source).

This is the big developer fallacy... installing from source is not easy, particularly if you have a desktop set-up and not a developer's set-up. If you have to install a C compiler, you probably won't bother.

To me it's all a matter of the installer.

Agreed. The installer should, IMHO, install almost everything (within reason). It makes more sense to have separate packages for stuff on Linux (that's the Linux way) but on Windows, people expect to be able to install 1 thing.

Simons agruments, however, smell a lot of "standard gimp extension language", because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts.

Agreed. So - who's been thinking about the macro recorder? :)

Cheers, Dave.

Hi,

Dave Neary writes:

Including guile doesn't mean supporting it. As it is, there are a bunch of things we include that don't get much support because the original authors have gone their own way. This time we're not even talking about *pretending* that this is a GIMP thing - we set up a configure script that checks if there's a local guile installed, if there is it uses it, otherwise it calls configure && make on its copy, and uses it in the GIMP. It is the same thing as we currently have, except that instead of George Carrette's SIOD, we'll be using GUILE. And this time, we will be using an official release of a scheme interpreter, not a GIMP modified copy. I don't see a downside.

We don't include libpng or libjpeg or glib or gtk+. Why should we include guile? If we need guile for script-fu and you argue that script-fu needs to be part of the standard gimp tarball, then gimp needs to depend on guile. Where's the downside?

In the long run we should move as much as possible out of the GIMP package. This will assure that we provide a stable and powerful API and will enable more extensions and plug-ins to be written. IMO moving script-fu out of the tree and putting it on the same level as gimp-perl and other language bindings is a very important thing to do.

There is a certain point at which this is unreasonable. If we move all the C plug-ins out into another module, and all the brushes, patterns and other data to another module, and all the script-fu and python-fu to separate modules, we'd have a small, stripped down core, but a usable GIMP would be made up of 6 or 7 CVS modules, 6 or 7 packages to download, and 6 or 7 packages to maintain.

This sounds like the right thing to do. I'd go even further and move the GIMP libraries into a seperate package as well. The casual user will not even notice the difference. Users can install a meta package, all packaging systems I am aware of support such a thing. But if we had all these separate modules and would even distribute libgimp separately, we would finally allow other apps to use our widgets and the image processing libary we are developing. Other apps like for example a video manipulation program could be developed around the gimp core.

I'm afraid that moving all of the langauge bindings out of the core would only result in the bindings not being maintained as well. As it is, the Python bindings are in need of a bit of a work-over before 2.0, if I remember correctly, and script-fu itself is only getting the minimum of maintenance for it not to be broken.

If it turns out the languages are not maintained outside the GIMP it is probably about time to get rid of them. Actually I believe that it is a lot easier for people to maintain and contribute to a smaller package like gimp-script-fu as it is for the GIMP maintainers to keep Script-Fu alive and decide what to do about contributions from others.

Anyway - working towards a minimalist GIMP is kind of going away from what I'd like to see.

This would a major shift in our goals and policies and it definitely needs more discussion.

I'd be more interested in being pretty liberal about the patches and plug-ins we accept in the core, and get more plug-in authors involved in maintenance work and development. For that we need to define guidelines for getting a plug-in into the core, and get the word out that we're interested in more or less anything and everything to do with image processing. Hand in hand with that we would also need guidelines for when a plug-in would get dropped (temporarily?) from the distribution if it is unmaintained. If we have decent guidelines, this would add very little work for maintainers, who could just let plug-in authors take care of their own code.

This is IMHO not a reasonable goal. At the moment we are doing it like this because we are afraid of finally cleaning up our codebase to a point where it becomes maintainable again. At the moment the GIMP tree is way too large. Not only from a maintainance point of view. I also believe that the casual user is struggling with the shear amount of plug-ins and modules we ship by default.

Sven

On Thu, 2004-02-05 at 16:14, pcg@goof.com wrote:

Simons agruments, however, smell a lot of "standard gimp extension language", because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts.

I agree that we should have a "standard gimp scripting language" but nothing prevents us from having it in a separate package on which The GIMP depends on being installed - just as we depend on GTK+ being installed (and just as we will depend on GEGL being installed in a not too distant future).

I believe the project would benefit from splitting stuff like script-fu, python-fu etc. out from the main source module into their own. Why? To make the GIMP source code more modular. IMO, modularity means easier to maintain, easier to grok for new developers - and the beauty of it all: a much better separation between the different modules.

./Brix

Hi,

Dave Neary writes:

Actually, most GIMP users probably get their GIMP from Jernej - OK - the GNU/Linux side of things gives us a nice big install base on Linux, but proportionately very few Linux people actually *use* the GIMP. I'd guess that the majority of our power users are on Win32.

Are there any numbers you can base this statement on? I don't think this assumption is correct. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. I'd also like to get an idea of the number of MacOS X GIMP users.

Sven

Hi,

Sven Neumann wrote:

Dave Neary writes:

I'd guess that the majority of our power users are on Win32.

Are there any numbers you can base this statement on?

No, it's a guess.

Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users.

It's possible.

I'd also like
to get an idea of the number of MacOS X GIMP users.

I'd say not many.

Cheers,
Dave.

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 5, 2004, at 5:20 pm, Sven Neumann wrote:

Are there any numbers you can base this statement on? I don't think this assumption is correct. Not that it would matter much but I doubt there are more Win32 GIMP users than Linux GIMP users. I'd also like to get an idea of the number of MacOS X GIMP users.

FWIW I'm using GIMP 1.2 under OS X and suspect that there might be a few freaks who do so, too simply because it's easily to install if there's fink on the machine. On the other hand there're probably not to many professionals doing this because fink is too much Unixish for UI attracted persons and Photoshop is still the standard; and no, Mac professionals normally don't care much about prices as far as maximum productivity and creativity is concerned. I do realize that things are shifting a bit now that Macs start providing better bang for the buck. :)

BTW: In OSX gtk 2 has really sucky rendering performance compared to gtk 1. I haven't tried GIMP v2 as of yet but other applications' UIs like gnumeric and evolution are simply slow on my new PowerBook which is certainly not a weak performer. FWIW one can feel the performance difference between my old PowerBook under Linux and the new PowerBook under OS X with the same applications. This is quite a showstopper for GIMP v2.

Unfortunately I've no idea how to profile the X communication to possibly find the bottleneck. Any ideas?

- -- Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCJ5EDBkNMiD99JrAQLMWggAwplnURivogW16c4EeeXs/c6kRnd6h72u ym5jEIERhdW8nnHjvBrcgaJXBpJV2S/A5ykny9OX7dGiz44TZ6xrX9riJsPIj74P +MTN4cmcyHjrzUybHX4h3wbv/cbc59LoZY1freDWo1HMdt5+kbJdPMSD6hvgUjs0 1pii3ZMy6iPM/C+936H9EDjlJLm5vG2FCPD4vwaSKHDEs3tEeXstlnXsQClvi1eO IB9HSY2/0qVNFnCZZl+xZpaBnAxsqg+r8Z168WeltNNC8zThPyQQYooxL2u9xrhW pXe983du5k2EsET5Z4iKZL3lUd+Cq0CS4wH4AJfp/OwzZL7R5vxs9A== =EGy7
-----END PGP SIGNATURE-----

Hi,

Daniel Egger writes:

FWIW I'm using GIMP 1.2 under OS X and suspect that there might be a few freaks who do so, too simply because it's easily to install if there's fink on the machine.

Installing gimp2 should be about as easy nowadays.

BTW: In OSX gtk 2 has really sucky rendering performance compared to gtk 1. I haven't tried GIMP v2 as of yet but other applications' UIs like gnumeric and evolution are simply slow on my new PowerBook which is certainly not a weak performer. FWIW one can feel the performance difference between my old PowerBook under Linux and the new PowerBook under OS X with the same applications. This is quite a showstopper for GIMP v2.

Do you use XFree or the X-Server that Apple provides?

Sven

hiya,
On Thu, Feb 05, 2004 at 03:42:24PM +0100, Simon Budig wrote:

Ooops, that should have been gone to the ML as well...

Sven Neumann (sven@gimp.org) wrote:

Simon Budig

Include a GUILE in the Gimp sourcecode, make sure that it doesn't conflict with other GUILEs on the target system and use it as the GIMPs default language. Perfectly fine with me as long as I have a language that is guaranteed to be available for 99% of the GIMP installations.

I don't think we should do that simply because I don't see what is so important about having a self-contained scripting language. I'd rather like to see three or four well-maintained and working scripting languages that can be installed separately.

It is pretty easy to see why a default scripting language is important, and I guess it is your grumpiness against script-fu that prevents you from seeing it.

When somebody on IRC has a problem that is cumbersome in the UI, but can be solved with three or four PDB calls (e.g. "Flip Layer menu entry") I'd hate to tell him that he has to install a monster like Perl/Python or whatever, to be able to use my quickly hacked three line solution. And even if he has Perl installed, I could not provide a script for him, because I only know about Python and Script-Fu. I don't want to be a master in all bindings available for gimp, just to be able to provide such a thing. I want to focus on one or two languages.

This has happened in the past and Script Fu was a nice solution for stuff like that. And that is the reason why it is important to have a simple language available always.

okay, i dont really like script-fu. i cant read it and it has this way of not telling gimp when it has made an image.

yet, even if there is one user of gimp on windows, these users are used to one button making of images and some of the functions that the scripts give to gimp. i think there would be a lot more griping and tutorial pointing if you do anything to make it so it is difficult to install the script thing.

about guile, do we even know those people?

carol

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 5, 2004, at 7:39 pm, Sven Neumann wrote:

FWIW I'm using GIMP 1.2 under OS X and suspect that there might be a few freaks who do so, too simply because it's easily to install if there's fink on the machine.

Installing gimp2 should be about as easy nowadays.

Nothing beats:
fink install gimp
simplicitywise. There's still no package for gimp2. Sure, one can do it like in the old days and compile some requirements and The GIMP manually but this is an intermediate to advanced topic especially under Darwin which hasn't received that amount of adaption and cleanup yet; especially dynamic libraries are still a real mess. And for some reason some GNOME applications really aren't stable although they normally run fine, I suspect the compiler but that could be almost anything.

BTW: In OSX gtk 2 has really sucky rendering performance compared to gtk 1. I haven't tried GIMP v2 as of yet but other applications' UIs like gnumeric and evolution are simply slow on my new PowerBook which is certainly not a weak performer. FWIW one can feel the performance difference between my old PowerBook under Linux and the new PowerBook under OS X with the same applications. This is quite a showstopper for GIMP v2.

Do you use XFree or the X-Server that Apple provides?

The "official" Apple X11 that comes with 10.3. This one is still best integrated and the best performer, so there is no real choice.

- -- Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCKdfTBkNMiD99JrAQLrSwgAxb8N+HcHQdd9fX2T2XRkZ56wGHldjP5S PW3R9ixQasFaBh89cK4uwHaKn73x2KGeZuYqLe9uwzXTU3PjuY29hvrUWfz9TwFW imbfegx0wwEGvBkfmy0KRjTLgtCsl64CsSMIImIJKO94nasQTu0w2n5w2BRKr42A EoiyygrgWxTM/dpPRcScA++Y4ToPAc877OeH277Qi6iMwGEO/DWBcfzehokYfDvi gSbLNeVbvtQD+ohgWO3B03RsMRItszUDula2Q3G41UPUBQsXla5R+x/v2oEu5MCv /hKrMo6OGbcq++af7LRo9etxaEztRR3ATwv2BOmKjp7CYC+O2C/gJg== =EZGv
-----END PGP SIGNATURE-----

Hi,

Daniel Egger writes:

On Feb 5, 2004, at 7:39 pm, Sven Neumann wrote:

Installing gimp2 should be about as easy nowadays.

Nothing beats:
fink install gimp

Well, this beats it:

port install gimp2

You will need Darwinports (http://darwinports.opendarwin.org/) but IMO darwinports is an improvement over fink. Of course your mileage may vary.

simplicitywise. There's still no package for gimp2.

There is one but last I checked it wasn't in the official fink tree yet:

http://www.breakmyfink.net/finkfiles.php?&pkgorder=up

The "official" Apple X11 that comes with 10.3. This one is still best integrated and the best performer, so there is no real choice.

This is the first time then that I hear complaints about performance of GTK2 applications on the Apple X11 server. Are you sure this is a general problem?

Sven

On Thu, Feb 05, 2004 at 06:10:35PM +0100, Daniel Egger wrote:

BTW: In OSX gtk 2 has really sucky rendering performance compared to gtk 1.

The same is true for gtk+ on other X11 platforms (but it's usually bearable, but very noticable). The biggest offender is font drawing: Xft is a rather slow design already and the (very good!) i18n features of gtk+2 seem to cost even further cycles.

It helps to a) avoid antialiasing (small effect) b) use x fonts (big effect).

Also, if you use a theme of some kind, try wether not using one will improve your rendering. In my experience, even a simple theme engine can make rendering much slower.

There might be other slowdowns, but I think fonts and themes are the predominant offenders that make gtk+2 so slow.

Hi,

writes:

BTW: In OSX gtk 2 has really sucky rendering performance compared to gtk 1.

The same is true for gtk+ on other X11 platforms (but it's usually bearable, but very noticable). The biggest offender is font drawing: Xft is a rather slow design already and the (very good!) i18n features of gtk+2 seem to cost even further cycles.

It helps to a) avoid antialiasing (small effect) b) use x fonts (big effect).

If fonts are rendered using XRender, font rendering shouldn't be a major problem. But I don't have any numbers to base this on.

There might be other slowdowns, but I think fonts and themes are the predominant offenders that make gtk+2 so slow.

I think what's slowing gtk+2 down is the back-buffering on the client side. Every expose event causes a pixmap to be allocated. Drawing operations are then redirected to that pixmap and finally the pixmap is blitted to the screen. This makes the display flicker-free but can bring down performance quite badly.

Another slowness is the treeview. There's a major speedup possible by fixing the row heights and Wwe could do this for The GIMP but it will need GTK+-2.4.

There's also some possible optimizations in our preview code. At the moment we sometimes convert a GdkPixbuf to a TempBuf when we could render the pixbuf directly. Perhaps we can improve this for GIMP-2.2 but I doubt that it will make a noticeable difference.

Sven

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 5, 2004, at 9:26 pm, Sven Neumann wrote:

You will need Darwinports (http://darwinports.opendarwin.org/) but IMO darwinports is an improvement over fink. Of course your mileage may vary.

Too complicated to install, at least I did and since I already had fink I didn't care enough to try twice.

What I really like about fink is apt-get in the back. No cluttering of the system, no stray files, just packages which can be easily installed and removed (and FWIW I even provide them for friends).

simplicitywise. There's still no package for gimp2.

There is one but last I checked it wasn't in the official fink tree yet:
http://www.breakmyfink.net/finkfiles.php?&pkgorder=up

breakmyfink doesn't sound that comfortable to me... :)

The "official" Apple X11 that comes with 10.3. This one is still best integrated and the best performer, so there is no real choice.

This is the first time then that I hear complaints about performance of GTK2 applications on the Apple X11 server. Are you sure this is a general problem?

I'm convinced this is a problem with GTK2, since GTK1 and Motif applications run fast as hell... Probably too much invalidations or other notifications which need to go through the additional layer... GTK2 is also slower than GTK1 under Linux/X11 but it's not as noticeable....

- --
Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCN8bjBkNMiD99JrAQLyJgf9HtcZgsIU4kKqEVMFGnHYCuLcOWpRBrWL NmTqsYGlfcOoxn1eMXICHti6UwDevs2zRuSJ17xHNQUJgXwlZk9fhQL79BJcIFmr inSfIV+mlx3CgWjhVr002pgAKYaiSfw0kK2EIUcQ+Rn51XvjwUHWx+i3PObbVYpq TxRkEn+O5B3WLcYyrKxXEj9ZwSehOt9ZlBdO5emdALVy4W+vckMgJ2o3dv2t1F2H bopEETYzUgiG9f7bW565uEZ1rMeYCCcnYE0aHW1JecWxvZGhavNtsopestk4/tJ7 JOVb0KDf56QgEDutduy9kGxcWKTm2lC8o51bbhHSXuHHRCWaOhBf/A== =/7w5
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 5, 2004, at 10:35 pm, wrote:

It helps to a) avoid antialiasing (small effect) b) use x fonts (big effect).

Thanks for this tip. I'll try installing some high quality X fonts (which is sort of an Oxymoron but anyway). The interesting thing is, my Linux notebook is running exactly the same truetype fonts which I extracted from Mac OS X 10.2 some time ago.

a) is not an option for me. I put many hours in the try to get rid of that crappy OS X antialiasing and instead have the nice X RENDER subpixel antialiasing. Now that I finally have a gnome-terminal with subpixel antialising and a working vim with UTF-8 I will certainly never go back.

Also, if you use a theme of some kind, try wether not using one will improve your rendering. In my experience, even a simple theme engine can
make rendering much slower.

Indeed, it makes some difference. However even with the built-in theme it is still slower than on Linux, even if the latter has a very complex theme.

BTW: The easiest way to test this is firing up gnumeric and scrolling up and down with the scrollwheel on the mouse. Linux (remeber, this is a much slower machine and runs with a complex GTK2 theme!) jumps instantly to the destination row. OS X lags behind fractions of a second to several seconds, depending on the distance.

The net result is not only that gnumeric is hardly fast enough to be usable but also that many GTK2 applications really feel slow and the perceived speed is especially important for daily use.

On the other hand there's another issue with GTK1 that bugs me: It tends to swallow button down events which is quite annyoing when one wants to switch tools or start drawing in the image.

- -- Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCOD+DBkNMiD99JrAQIqNwf/eZFGzyEe+AWwIU/DQWJGMpdRMwLHIdux sh9X3ZcpdzY2eZDrzTjIJwJPvitlA641xGszuZka7BlPGH5l/3rBvjgM3gPODXAT iSuwIqv1hYW3lgkF8iQL2jCvS015/j7Eh1Cx3WO/wE26cUo0uXddqdKtyzsWPsnP /MxckT8LtrNXTF9PY/tETTDJit9jfQ/YGc6Nhfr2/QkmC7OJyKMribvWTVLGQeoF 7weYvvJAyzQEnbc5mJhdCMzUTN8KAOJO28HgJPZM4HpJ5GuS7e6txL8h/2sbOllh ZpUrBxgDUV92xzlpkFA7mTLBeEA2017v0unahgtwly5NUy8lO0tTqQ== =Tvo9
-----END PGP SIGNATURE-----

Hi,

Daniel Egger writes:

You will need Darwinports (http://darwinports.opendarwin.org/) but IMO darwinports is an improvement over fink. Of course your mileage may vary.

Too complicated to install, at least I did and since I already had fink I didn't care enough to try twice.

Checking out a cvs repository and typing "configure; make; make install" doesn't sound too complicated to me.

Just adding this comment so that people don't get a wrong impression...

Sven

In regard to: Re: [Gimp-developer] Gimp on OS X, Daniel Egger said (at...:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 5, 2004, at 10:35 pm, wrote:

It helps to a) avoid antialiasing (small effect) b) use x fonts (big effect).

Thanks for this tip. I'll try installing some high quality X fonts (which is sort of an Oxymoron but anyway). The interesting thing is, my Linux notebook is running exactly the same truetype fonts which I extracted from Mac OS X 10.2 some time ago.

I haven't played with OS X enough to know, but does its X server support the Render extension? If not, that's probably why GTK+ 2 is slower.

Also, support for X fonts in pango has been dropped, so in the not-too-distant future Marc's suggestion isn't going to be an option.

Owen explained it very well here

http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00176.html

The net result is not only that gnumeric is hardly fast enough to be usable but also that many GTK2 applications really feel slow and the perceived speed is especially important for daily use.

I've noticed this too, using an X server on a commercial UNIX platform. Owen has talked about performance improvements for non-Render platforms, and I'm certainly hoping they become a reality in the next year.

Tim

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 6, 2004, at 4:32 pm, Sven Neumann wrote:

Checking out a cvs repository and typing "configure; make; make install" doesn't sound too complicated to me.

It is, especially when it doesn't work out-of-the-box. Also this is equivalently complicated to compiling a simple application manually.

Just adding this comment so that people don't get a wrong impression...

No problem. This is a free world... :) I still prefer a decent packagemanagement like the one that comes with Debian....

- --
Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCPBmzBkNMiD99JrAQIJIAf/fXxLrZbamRasRnJ34+pJk7VzWIRt4R6K 23pDDJcX5UYfcwhsmtbV/A171b0aE4fimcYkSWXUG9f3bD58FV/rv6Kb9J6YerOy 5wCtmqSL0xDvBsqnIN1yLThlYNFRaydJ4qBoEitS2O5v6Jya/TBBIFzO4aKHFbsH AerO1oczyFdt9O2N3uBWLGCXhYwIWQ1THn0Z/l+ekL+dfY6CVrDqBa0/YbiGkGyn M8ctJyOormK2RWO2F4voMpXVWsjbJFzt5ek+8Asp/6Vdch3d/ydGS7eTsuEMtrFX xqUcYkDE4PieylWyqmLZGZcs9ySsXFkjEKMmtUmirwq+w2HBVNZVvw== =EyR+
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 6, 2004, at 5:12 pm, Tim Mooney wrote:

I haven't played with OS X enough to know, but does its X server support
the Render extension? If not, that's probably why GTK+ 2 is slower.

number of extensions: 28
Apple-DRI
Apple-WM
BIG-REQUESTS
DEC-XTRAP
DOUBLE-BUFFER
DPMS
Extended-Visual-Information
FontCache
GLX
LBX
MIT-SCREEN-SAVER
MIT-SHM
MIT-SUNDRY-NONSTANDARD
RECORD
RENDER
SECURITY
SGI-GLX
SHAPE
SYNC
TOG-CUP
X-Resource
XC-APPGROUP
XC-MISC
XFree86-Bigfont
XINERAMA
XKEYBOARD
XTEST
XVideo

It seems so. Hard to tell for me whether this is just the API extension or a hardware accelerated implementation. Do you have any idea how to gather this data?

I've noticed this too, using an X server on a commercial UNIX platform. Owen has talked about performance improvements for non-Render platforms,
and I'm certainly hoping they become a reality in the next year.

Meanwhile I've profiled gnumeric while waiting for the scrollwheel action to catch up and indeed it seems that the scrolling causes a lot of activity both in GTK and the X server with the activity in the X server being mostly blit operations resulting in memcpys. So it seems that updates are a really costly operation which should be better avoided
and actions to cause them reduced by coalescing and/or grouped...

- -- Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCPEFDBkNMiD99JrAQKeHwf8DzFYIS0sXxefIAf/UUX5SGizEK9WFPUK nK3DHHUir30tlTi/2yMQpSlNGkRx6gfI0f/AF1IwsVAmyP8tCbmsl13YP/rfhu46 QDuBoVspPUUPTSdUWKvYewtEnLz8Mmu1wYPfaYvOHeNKgogQlr3QlIhtOY/YDQhY evxxHmPI2jiAFgtKN23PYmA76b/wCNoFRIR9c4qVxkB5r49e71ZAbBZLEcV8LEjg NOu1sfjIAEiCuLeHorx4km0lbdx7DYIDrBZxFipzx0JzvrzMmI1NIMtE+3or5U1Z nBtidyQ3NVaWk2ckQy9PtjQJxn4daqzdeSpy2TJUnUkNb/6frt0QjA== =Yvep
-----END PGP SIGNATURE-----

Hi,

Daniel Egger writes:

I still prefer a decent packagemanagement like the one that comes with Debian....

Well, darwinports is a decent package management system just like BSD ports. And from my experience it works better than fink. This is also what everyone else who tried both system has told me so far. But yeah, it's a free world and it's probably good that there are alternatives.

Sven

On Fri, Feb 06, 2004 at 01:48:13PM -0500, Kevin Cozens wrote:

At 02:13 PM 02/05/2004, Carol Spears wrote:

okay, i dont really like script-fu. i cant read it and it has this way of not telling gimp when it has made an image.

I am starting to notice a lot of people saying they don't like Script-Fu. As for not being able to read it, that is not helped by the fact that the sample scripts are what I would call obfuscated. By treating the scripts like any other computer program, the proper use of white space and bracket placement greatly improves ones ability to read a script and see the syntax of the language of the script. One of the tutorials I saw for Guile makes a mention of this and shows the Scheme code formatted much better than anything in any of the existing Script-Fu scripts.

when i first started to look at the scripts, script-fu and gimp-perl madeno sense to me equally, however i could easily recognize the gimp parts. iworked with gimp-perl first for the simple reason that there weretutorials, not only for gimp-perl but also for the perl parts alone.also books with examples.

in the ultra-truth, due to a search error on my part, my first "gimpscript" was a gtk-perl stand alone that tried to answer some of the newwindow gimp users issues with the linux .somethinguseful/here dot files.i didnt recognize a gimp on windows user at that time so the wholeproject was just silly. i wrote "Hello World" and "Totally Remove"(that would clean the xvpics out at the same time).

that was back in 2000 i think. lately, i still cannot read the perl or the script-fu around the gimp commands and i find it just easier to skip to the monthly (or so blog) located at http://www.paulgraham.com than it is to remember what "cab" means.

even more recently, i discover that script-fu/LISP is an old fashioned thing that many people dont even think about any more.

Is the Script-Fu interpreter supposed to specifically tell GIMP when it has made an image? What function call do other plug-ins use to tell GIMP when they have made an image?

i might not be describing the problem i had with it properly. i wrote a script (in python) where a script-fu made an image that was used by gimp. my script did not know the image that the script-fu had made. there were two solutions to the problem, eventually. instead there was the equivelent of a fist fight on the irc between me and one of the script-fu writers that left me and his/her friends laughing.

yet, even if there is one user of gimp on windows, these users are used to one button making of images and some of the functions that the scripts give to gimp. i think there would be a lot more griping and tutorial pointing if you do anything to make it so it is difficult to install the script thing.

If Script-Fu gets dropped in favour of something else at some point, a Windows installer for the GIMP could be updated to include the extra library or dll needed to use the Script-Fu replacement to keep the installation easy for Windows users. In a Linux (*nix) environment, the GIMP package would only need users to have an additional package installed in order to use the replacement. I don't see installation as being a big issue. It can be handled in the best way once a replacement is available.

while i have seen a lot of things written in python that i could not read; i can make some sense out of the gimp-python scripts and it seems to be easier to learn with it and get help with it. at least as far as gimp is concerned. python cannot be included in gimp source.

what was nice about moving the old scripts and the old server along with this new gimp was that one button functionality the new users might need and want more than the older (ie pre-gimp on windows users) prefer. i knew if i ever got it to work on my moms computer, those scripts would be there ....

carol

On Thu, Feb 05, 2004 at 04:14:10PM +0100, Marc A. Lehmann wrote:

Simons agruments, however, smell a lot of "standard gimp extension language", because his goal is to have one language that is always pat of gimp, which would effectively be a standard. I don't think that's a bad idea at all, especially when we later think of macro recording and other tasks, where we _will_ need some standardized macro language that should be easy to translate into real scripts.

Exactly. And scheme is pretty good for that, since it's easy to parse, which makes writing a macro->real program script easy.

Running a macro shouldn't need any extra dependencies either. So SIOD is fine for this, unless there is a smaller scheme implementation out there. Use of it for anything beyond simple macro logic should be discouraged.

So there is room for a Guile binding which could run stuff that is .scm currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API.

-Yosh

On Fri, Feb 06, 2004 at 05:43:00PM +0100, Daniel Egger wrote:

Meanwhile I've profiled gnumeric while waiting for the scrollwheel action to catch up and indeed it seems that the scrolling causes a lot of activity both in GTK and the X server with the activity in the X server being mostly blit operations resulting in memcpys. So it seems that updates are a really costly operation which should be better avoided
and actions to cause them reduced by coalescing and/or grouped...

Interestingly enough, when it comes to scrolling, running a GTK+ app on OS X remote displayed to a Linux machine over 802.11b is *faster* than running it on the local OS X display. I'm guessing context switches on OS X are rather slow, so the chatter between the app and the X server is slowing things down.

Certainly some of this can be improved upon in GTK+, like doing scroll event compression.

-Yosh

On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh wrote:

currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API.

Hmm, at least during the 1.2 era, perl did have access to the full API (i.e. low-level pixel access, full UI transparency etc.), and right now I don't think something important has been added that is not accessible (as opposed to parts that haven't been converted to the new API).

I mean, in the sense of "you can write plug-ins indistinguishable from plug-ins wirtten in C", this was possible in perl for a long time already.

However, very few authors have used these features, and only two perl plug-ins, both written by me, use their own Gtk-UI instead of relying on Gimp::Fu, so I guess the demand for the latter power in perl is pretty low.

(I might err and there are lots out there, perl developers have this tendency of doing stuff for themselves without polishing & publishing them...)

On Mon, Feb 09, 2004 at 08:35:04AM +0100, Marc A. Lehmann wrote:

On Sun, Feb 08, 2004 at 07:35:08PM -0800, Manish Singh wrote:

currently, and go beyond that with a full gtk and gimp binding. The same should be done for python (I have plans to do this) and perl, the idea being having languages besides C that can use the entire gimp API.

Hmm, at least during the 1.2 era, perl did have access to the full API (i.e. low-level pixel access, full UI transparency etc.), and right now I don't think something important has been added that is not accessible (as opposed to parts that haven't been converted to the new API).

I mean, in the sense of "you can write plug-ins indistinguishable from plug-ins wirtten in C", this was possible in perl for a long time already.

However, very few authors have used these features, and only two perl plug-ins, both written by me, use their own Gtk-UI instead of relying on Gimp::Fu, so I guess the demand for the latter power in perl is pretty low.

(I might err and there are lots out there, perl developers have this tendency of doing stuff for themselves without polishing & publishing them...)

Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb.

I'd like to see more bindings that let you do everything a C plugin does, so people have language choice when it comes to writing things, which could mean a larger pool of plugin coders. It's also nice to have a quick way of trying out new algorithms.

-Yosh

Hi,

Manish Singh writes:

Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb.

We will have to make the libgimp APIs more language binding friendly then. If we made more use of GObject properties, that would probably help.

Sven

On Mon, Feb 09, 2004 at 11:58:15AM +0100, Sven Neumann wrote:

Hi,

Manish Singh writes:

Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb.

We will have to make the libgimp APIs more language binding friendly then. If we made more use of GObject properties, that would probably help.

Yeah, there's a bit of work to be done on the libgimp* side too. Not a whole lot though, and certainly doable for 2.2.

-Yosh

On Mon, Feb 09, 2004 at 12:53:40AM -0800, Manish Singh wrote:

Oh sure, out of all the bindings, perl comes closest by far to full coverage. But iirc it doesn't wrap libgimpcolor, libgimpmath, some of libgimpwidgets, and libgimpthumb.

Ah yes, I haven't looked into the new stuff...

[hints for implementors, after looking into a slightly older 2.0 snapshot that I have on my disk:]

Most of libgimpcolor and libgimpmath is available in other perl modules (using them directly would be rather slow in perl, using pdl is faster, although the results might be subtly dfferent, of course. Wrapping these into PDL interfaces would be best).

The way to wrap the remaining libgimpwidgets is to make them into real gtk2 widgets with properties and signals. The way it is now, every language interface has to reimplement the api, if they were written in the same way as other libgtk2 widgets it would be as simple as calling the register function and have everything available without extra C code. (as I understand, at least the python gtk2 interface is working very similar and would benefit automatically from this).

libgimpthumb would probably just need a few init calls to be called on module init, although the design of combining an initialisation function with setting parameters (gimp_thumb_init) might not have been the wisest choice, but this could be handled in perl using "use Gimp:Thumb (MyApp /basedir)", athough it's not clear how to handle multiple users of Gimp::Thumb. Everything else is nicely wrapped into gtk enums and properties there.

(Gimp::Thumb might become an extra module on CPAN, even, I see possible uses in non-gimp-apps. Same is true for the other libgimp interfaces that are not tied into the gimp protocol themselves).

Hi,

Daniel recently posted a list of X extensions supported by the Apple X11 server. The MIT-SHM extension was part of this list but today I found that at least in darwinports gtk2 is compiled with the --disable-shm configure option. Does anyone know if fink does this as well? Is there a particular reason to disable the use of the XShm extension on OS X? This would explain at least some of the slowness that people reported here lately.

Sven

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On Feb 11, 2004, at 4:06 pm, Sven Neumann wrote:

Daniel recently posted a list of X extensions supported by the Apple X11 server. The MIT-SHM extension was part of this list but today I found that at least in darwinports gtk2 is compiled with the --disable-shm configure option. Does anyone know if fink does this as well?

I can confirm it does.

Is there a particular reason to disable the use of the XShm extension on OS X? This would explain at least some of the slowness that people reported here lately.

No idea, I can try compiling it with SHM and see what happens if that would help...

- --
Servus,
Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (Darwin)

iQEVAwUBQCqOvjBkNMiD99JrAQLplAf/UUvfJjPrewVorUZCo7V+D7jnlrxWW4yP biaHfUFYwSXSlP7RCPETohw2MwJk1zfu9yV9r/Pg0y3Q/CSIRyN+6juhKEn4emes pZE+olXq+2Pcz1ueFSieYT93eZRlsnu1vPBUsu4YE1idT0YLcqh314q9GfrgAJ1C wNfhb3JM9Kenm0svugkq3OWuYsNiehknxmaC4HyrN0dAtpTP8pZSP3xnszQDSCvX qfIoyU0rAWoLI8smuhLOXHRKqzOGrcDrLKRxkuB34LXQBF3BEFVkcVHpbtpx4FtI oQLLHc7i5Wwrx8HYtszVvuGrzgQGRHmojrhnRCEgVAk/PlZJQEAkiA== =TfT+
-----END PGP SIGNATURE-----

On Wed, 11 Feb 2004, Daniel Egger wrote:

On Feb 11, 2004, at 4:06 pm, Sven Neumann wrote:

Daniel recently posted a list of X extensions supported by the Apple X11 server. The MIT-SHM extension was part of this list but today I found that at least in darwinports gtk2 is compiled with the --disable-shm configure option. Does anyone know if fink does this as well?

I can confirm it does.

Is there a particular reason to disable the use of the XShm extension on OS X? This would explain at least some of the slowness that people reported here lately.

IIRC, didn't early versions of OS X have truly pitiful amounts of shared memory available? Perhaps that is the reason.

Rockwalrus

On Feb 11, 2004, at 10:51 pm, Nathan Carl Summers wrote:

IIRC, didn't early versions of OS X have truly pitiful amounts of shared
memory available? Perhaps that is the reason.

So now I recompiled GTK 2.2.4 with SHM and I cannot sense any difference in behaviour. However scrolling in gnumeric is still as slow[1] as before.

I must say that GTK 1.2 runs like a charm here, even without SHM. GIMP 1.2 starts in a couple of seconds with all plugins on a cache cold system and is snappy all over...

I really need to try 2.0 soon....

[1] Perceived feeling, as long as it's possible to occupy 100% of the CPU power by scrolling a bit with the mouse wheel and then watching it move for minutes it's still *much* *too* slow and this hasn't changed.

Servus, Daniel

Hi,

Daniel Egger writes:

On Feb 11, 2004, at 10:51 pm, Nathan Carl Summers wrote:

IIRC, didn't early versions of OS X have truly pitiful amounts of shared memory available? Perhaps that is the reason.

So now I recompiled GTK 2.2.4 with SHM and I cannot sense any difference in behaviour. However scrolling in gnumeric is still as slow[1] as before.

Did you increase the shared memory limit? I am not sure what happens if it the X server hits the limit but I guess it just silently stops allocating more shared memory. So unless you changed that limit, it's not surprising that there's no difference to be sensed.

I must say that GTK 1.2 runs like a charm here, even without SHM. GIMP 1.2 starts in a couple of seconds with all plugins on a cache cold system and is snappy all over...

I really need to try 2.0 soon....

From my experience GIMP-2.0 runs very nicely on MacOS X. I even had PS

users claim that the GIMP-2.0 user interface would feel more responsive than PS on the same machine.

Sven

On Feb 25, 2004, at 10:11 am, Sven Neumann wrote:

Did you increase the shared memory limit? I am not sure what happens if it the X server hits the limit but I guess it just silently stops allocating more shared memory.

Err, I know somewhat how to mess with POSIX SHM in applications but how can I change the shared memory limits?

From my experience GIMP-2.0 runs very nicely on MacOS X. I even had PS users claim that the GIMP-2.0 user interface would feel more responsive than PS on the same machine.

Hm...

Servus,
Daniel

On Feb 25, 2004, at 2:12 PM, Daniel Egger wrote:

On Feb 25, 2004, at 10:11 am, Sven Neumann wrote:

Did you increase the shared memory limit? I am not sure what happens if it the X server hits the limit but I guess it just silently stops allocating more shared memory.

Err, I know somewhat how to mess with POSIX SHM in applications but how can I change the shared memory limits?

On mac os 10.3, in /etc/rc
Look at the lines:
sysctl -w kern.sysv.shmmax=41943040
sysctl -w kern.sysv.shmmin=1
sysctl -w kern.sysv.shmmni=320
sysctl -w kern.sysv.shmseg=80
sysctl -w kern.sysv.shmall=10240
This is already adjusted by a factor of 10, which will probably help things, but feel free to adjust it higher. keep shmmin=1 the same though. Then reboot. On mac os x client, these adjustements only work the first time you set them, so comment out of old lines or replace them entirely.

In mac os 10.2 and eariler, there is a similar thing done in the startup script SystemTuning or somesuch, but I don't have a 10.2 system to investigae.
--
Dan

On Feb 25, 2004, at 11:27 pm, Daniel Rogers wrote:

sysctl -w kern.sysv.shmmax=41943040 sysctl -w kern.sysv.shmmin=1
sysctl -w kern.sysv.shmmni=320
sysctl -w kern.sysv.shmseg=80
sysctl -w kern.sysv.shmall=10240

DUH! How could I possibly forget about sysctl. That doesn't seem to work though:

lucy:~ root# sysctl -w kern.sysv.shmmax=41943040 kern.sysv.shmmax: 4194304 -> 4194304 lucy:~ root# sysctl -w kern.sysv.shmmin=1 kern.sysv.shmmin: 1 -> 1
lucy:~ root# sysctl -w kern.sysv.shmmni=320 kern.sysv.shmmni: 32 -> 32
lucy:~ root# sysctl -w kern.sysv.shmseg=80 kern.sysv.shmseg: 8 -> 8
lucy:~ root# sysctl -w kern.sysv.shmall=10240 kern.sysv.shmall: 1024 -> 1024

Servus, Daniel

Daniel Egger wrote:

On Feb 25, 2004, at 11:27 pm, Daniel Rogers wrote:

sysctl -w kern.sysv.shmmax=41943040 sysctl -w kern.sysv.shmmin=1
sysctl -w kern.sysv.shmmni=320
sysctl -w kern.sysv.shmseg=80
sysctl -w kern.sysv.shmall=10240

DUH! How could I possibly forget about sysctl. That doesn't seem to work though:

lucy:~ root# sysctl -w kern.sysv.shmmax=41943040 kern.sysv.shmmax: 4194304 -> 4194304 lucy:~ root# sysctl -w kern.sysv.shmmin=1 kern.sysv.shmmin: 1 -> 1
lucy:~ root# sysctl -w kern.sysv.shmmni=320 kern.sysv.shmmni: 32 -> 32
lucy:~ root# sysctl -w kern.sysv.shmseg=80 kern.sysv.shmseg: 8 -> 8
lucy:~ root# sysctl -w kern.sysv.shmall=10240 kern.sysv.shmall: 1024 -> 1024

Yes, in fact it doesn't. I played around with this quite a bit. The explanation requires understanding how the startup sequence works and mach "security modes."

The first process run by Mac OS X in the normal boot-up sequence is init, which begins in mach security mode 0, and very shortly moves to mac security mode 1 (I belive man init explains this). In security mode 1, thos sysctl values can only ever be set _once_. Since they are set in /etc/rc, which is the first thing that init runs, you cannot change them after that. This is why you need to edit the rc file and reboot.

If you are in single user mode, which explictly is in security mode 0, then you can set these values as many times as you wish. Judging from the way the rc scripts are set up, I am guessing that these values are not so restricted in the server version, though I haven't tested it.

This goes back to the question as to why apple would restrict you from changing the values after boot, and why they would set the defaults to low.

Who knows? Who cares? but you do need to edit /etc/rc to see any effect.

Servus,
Daniel

--
Daniel

On Feb 26, 2004, at 5:38 pm, Daniel Rogers wrote:

Who knows? Who cares? but you do need to edit /etc/rc to see any effect.

Thanks for the explanation. I did just what you told me and retested, but it doesn't have any positive impact on the slowness.

Servus,
Daniel