Besides Script-Fu and its successor Tiny-Fu, there's Perl, Python and Lua for you to choose from. There also used to be Java bindings and probably others but I am not sure if these have been updated for GIMP 2.x yet. Generally, all the functionality is available in a well-defined API and it is not a big deal to write a binding that allows you to write scripts/plug-ins in your favorite programming language.
If you go the GIMP preferences dialog, select the "Window Management" page and enable the "Utility window" hint for the docks and/or the toolbox, your window manager is supposed to keep the docks and the toolbox above the image windows. So you basically get exactly that behaviour.
This is not the default because we got a couple of angry bug reports when it used to be the default in the 1.3.x series. Now what's missing is an equivalent setting that works on Win32. Perhaps one of the/. readers knows more about the Win32 window API and could help to implement this in the Win32 backend of GTK+?
A lot of people like to be able to select individual windows from the taskbar. If you don't, then you can configure your taskbar to group all GIMP windows together. GIMP sets the same WM_CLASS property on all it's windows (even on plug-in windows) and it has done so since GIMP 1.2. That allows the window manager and your taskbar to easily identify GIMP windows and treat them as a group. You can then minimize/maximize all GIMP windows in a single operation, move the window group to a different desktop or whatever else you want to do...
Now what would be nice if there was an equivalent window manager hint available for Win32. Perhaps there is, and all that's missing is support from the Win32 GTK+ backend?
Both features you ask for are on the TODO. The GIMP developers are fully aware of the need for higher color depths. Color management is scheduled to be added in the next development cycle. Whether this also means support for 16bit per color in GIMP 2.4 remains to be seen. At some point it will definitely be added.
Macro recording needs a major redesign of the PDB but there are plans to finally address this. Nothing promised because this is entirely a volunteers' project. New features are added if and only if someone's capable and willing to put some time and effort into it.
the thing they really want is a small fast easy to use animated GIF replacement
But that's exactly what MNG offers. It's a perfect replacement for GIF animations. Given the right tools your web developers will also start to make use of other features it offers like reuse of image objects in multiple frames and the ability to combine JPEG (JNG) and PNG compression.
The only weak point about MNG is that it is not supported in most browsers. A new format is unlikely to change that. Overall it will even decrease the probability that one day there will be a commonly available animation format.
Adding JNG support to the GIMP plug-in would be trivial. As soon as MNG is finally put back into the Mozilla trunk, I promise to add JNG support for the GIMP MNG plug-in.
I had forgotten that the MNG subset is even already defined in the MNG spec. This whole APNG thing looks very much like a reimplementation of MNG-VLC (Very Low Complexity):
MNG-VLC
A very-low-complexity subset of MNG that does not use stored objects, variable framing rates, location of images at positions other than (0,0), or other complex features.
MNG supports animations that include JNG (JPEG Network Graphics) datastreams. It can even be mixed with PNG compressed image data. Very useful if for example you want to animate text or a logo over a photographic background. There's really no need for new formats, MNG has everything you need.
Adding MNG support to your version of Firefox is actually pretty simple. Just go to http://stud4.tuwien.ac.at/~e0225227/ and download the extension for your platform.
I suggest that you also take a look at the filesize of this extension. It's really not as much bloat as people try to make you believe. We are talking about a 270KB library here (for the Linux version).
Yes indeed. The only argument against using MNG seems to be that it is too complex. I don't really understand this argument since MNG isn't actually that complex and there is code available that deals with the complexity. However if the point is complexity, then the obvious solution is to define a subset of MNG so that more applications can add support for that subset (and perhaps add full support later). This has been done for other formats (for example SVG) and is has shown to work pretty well.
The other argument for the new format seems to be backwards compatibility with the PNG format. Applications that don't support it will show the first frame of the animation. Well, this is IMHO a strong argument against this hack. There is no advantage at all in having applications show the first frame of an animation w/o giving any incidence that more frames are available. If the animation format is not supported, nothing should be shown at all.
Well, except that this new "format" is not at all better than MNG. In fact it is inferior in a lot of aspects despite of it being a crude hack that violates the PNG spec.
This is a very stupid idea. Just when MNG was finally getting the attention it deserves and MNG support for Mozilla is about to be integrated back into the main trunk, some morons come up with a new format which is inferiour to MNG and also clearly violates the PNG spec. Let's hope this thing is forgotten soon and let's focus on making all browsers support MNG.
Certainly the most annoying quirk is not the button order (I love it), it's the idea that dialogs should not have a "Cancel" button. While it is of course perfect to have settings from a dialog apply instantly, you still want to be able to back out your changes by using the "Cancel" button.
Imagine you accidentally change a setting, it applies instantly and now you have no way to go back to the old setting unless you remember exactly what it was. That is a serious usability problem and IMO the HIG authors have been on some rather bad crack when they suggested to remove "Cancel" buttons all over the place.
Perhaps you should read the bug report more carefully then. Of course adding the setting alone won't change any application but the setting is a pre-requisite for making the button order configurable. It's the first step that has to be taken and only if this setting is available in GTK+ will patches to application be accepted.
I can only speak for The GIMP project but we would accept a patch that makes the button order dependant on a GTK+ setting. We would definitely not accept a patch simply changes the button order back.
Changing the button order back by forking the GNOME project? That's about the stupiest thing I've ever heard about. Instead of writing patches for each and every app out there (patches which are certainly not going to be accepted), you should first of all submit a patch for
http://bugzilla.gnome.org/show_bug.cgi?id=74669
As soon as this is fixed and in a released GTK+ version, you can start to submit patches to application to make them respect this setting. Such patches would then have a good chance to be accepted.
It would also help a lot if you stopped speaking about *fixing* the button order. I understand that you disagree with the decision (I do myself love it) but there is clearly no correct button order so there is nothing that could be fixed here.
More types of data being supported in cut-and-paste in GNOME apps. This means being able to cut-and-paste from the GIMP or Inkscape to Open Office and back again.
You'd have to put that on the GIMP / Inkscape / Oo roadmaps. But fortunately it's already on the GIMP roadmap at least. Might even make it into GIMP 2.2.
The py-slice and perlotine plug-ins for The GIMP do a very nice job on slicing your image putting it back together in HTML.
The idea of the GIMP is to provide you with the tools to do the job. It is supposed to be extended by plug-ins. Plug-ins that do not necessarily need to be maintained by the few GIMP core developers. "Save for Web" can easily be implemented in a plug-in. Why has such a plug-in not been written yet? Think about it and tell me.
There has been a button to access the menu in gimp-1.2 already (upper left corner of the image window). In gimp-2.0 there's an optional menubar at the top of the image window and it is enabled in the default configuration. You obviously haven't looked at The GIMP user interface for quite some time.
Well, if you tried GIMP-2.0, you might find that stroking a path gets you very nice antialiased lines drawn with GIMP. And text rendering is definitely up to par with PS. The author of this article compared unhinted text rendering (PS) with hinted text rendering (GIMP). If he wanted to get similar output from GIMP, he should have unchecked the "Hinting" toggle in the text tool options.
GIMP has professional quality rendering, it's just a matter of learning how to use it correctly.
Points 1 to 3 are planned for future GIMP versions but aren't that simple to implement at it may perhaps appear to you.
Point 4 is dogshit to use your own words. As can be easily seen by a direct comparison, the quality of the font rendering has much improved with GIMP2. GIMP-1.x could not even do proper antialiasing. It used to render the text bitmap three times the requested size and scaled it down. GIMP2 uses the Freetype and Pango libraries to produce well-hinted, antialiased, internationalized text.
You could put some effort into it then and rebuild the GIMP binaries with more uptodate versions of FreeType and Pango. The problems that people see with GIMP 2.0 on the Windows platform have all been addressed. It's just a matter of building a new binary based on freetype 2.1.8 and Pango 1.4.
Sooner or later those binaries will become available but you could help to make that happen sooner.
Why exactly are you suggesting a fork? You could instead join the GIMP development team and help them (or rather us since I am one of them) to improve the user interface. We are constantly working on improving The GIMP and your help would be very much appreciated.
Any contribution is useful, you don't even need to be a hacker to contribute. We need people to improve the documentation, we need people to propose a better menu structure, we need people who contribute mockups for more intuitive dialogs. Lots and lots of ways to help to make a better GIMP.
Only after you have tried to work with the GIMP developers and found for whatever reasons that your idea of a better GIMP isn't accepted, you should consider a fork.
What exactly is your problem with the new text tool? I know that there's room for improvement and GIMP 2.2 is supposed to bring some but I would still be interested to hear why you think that the new text tool is deficient.
Try a more recent version then. Unsharp mask radius goes down to 0.1 in GIMP 2.0. The other issue you mentioned will certainly be addressed at some point as well. Support for other color spaces and more color depth is on the roadmap.
Uhm, did you ever try GIMP 2.0? It does allow you to group the controls (or call them palettes or docks) in container windows, thus avoiding the need for dozens of windows floating on your screen.
Claiming that the GIMP developers wouldn't listen only shows that you never tried to talk to them.
Slashdot Mirror
Besides Script-Fu and its successor Tiny-Fu, there's Perl, Python and Lua for you to choose from. There also used to be Java bindings and probably others but I am not sure if these have been updated for GIMP 2.x yet. Generally, all the functionality is available in a well-defined API and it is not a big deal to write a binding that allows you to write scripts/plug-ins in your favorite programming language.
If you go the GIMP preferences dialog, select the "Window Management" page and enable the "Utility window" hint for the docks and/or the toolbox, your window manager is supposed to keep the docks and the toolbox above the image windows. So you basically get exactly that behaviour.
/. readers knows more about the Win32 window API and could help to implement this in the Win32 backend of GTK+?
This is not the default because we got a couple of angry bug reports when it used to be the default in the 1.3.x series. Now what's missing is an equivalent setting that works on Win32. Perhaps one of the
A lot of people like to be able to select individual windows from the taskbar. If you don't, then you can configure your taskbar to group all GIMP windows together. GIMP sets the same WM_CLASS property on all it's windows (even on plug-in windows) and it has done so since GIMP 1.2. That allows the window manager and your taskbar to easily identify GIMP windows and treat them as a group. You can then minimize/maximize all GIMP windows in a single operation, move the window group to a different desktop or whatever else you want to do...
Now what would be nice if there was an equivalent window manager hint available for Win32. Perhaps there is, and all that's missing is support from the Win32 GTK+ backend?
Both features you ask for are on the TODO. The GIMP developers are fully aware of the need for higher color depths. Color management is scheduled to be added in the next development cycle. Whether this also means support for 16bit per color in GIMP 2.4 remains to be seen. At some point it will definitely be added.
Macro recording needs a major redesign of the PDB but there are plans to finally address this. Nothing promised because this is entirely a volunteers' project. New features are added if and only if someone's capable and willing to put some time and effort into it.
the thing they really want is a small fast easy to use animated GIF replacement
But that's exactly what MNG offers. It's a perfect replacement for GIF animations. Given the right tools your web developers will also start to make use of other features it offers like reuse of image objects in multiple frames and the ability to combine JPEG (JNG) and PNG compression.
The only weak point about MNG is that it is not supported in most browsers. A new format is unlikely to change that. Overall it will even decrease the probability that one day there will be a commonly available animation format.
Adding JNG support to the GIMP plug-in would be trivial. As soon as MNG is finally put back into the Mozilla trunk, I promise to add JNG support for the GIMP MNG plug-in.
"Mozilla won't show you the thing." is just plain wrong though. I've created animations using JNG chunks and the Mozilla firefox extension shows them just fine.
I had forgotten that the MNG subset is even already defined in the MNG spec. This whole APNG thing looks very much like a reimplementation of MNG-VLC (Very Low Complexity):
MNG-VLC
A very-low-complexity subset of MNG that does not use stored objects, variable framing rates, location of images at positions other than (0,0), or other complex features.
MNG supports animations that include JNG (JPEG Network Graphics) datastreams. It can even be mixed with PNG compressed image data. Very useful if for example you want to animate text or a logo over a photographic background. There's really no need for new formats, MNG has everything you need.
Adding MNG support to your version of Firefox is actually pretty simple. Just go to http://stud4.tuwien.ac.at/~e0225227/ and download the extension for your platform.
I suggest that you also take a look at the filesize of this extension. It's really not as much bloat as people try to make you believe. We are talking about a 270KB library here (for the Linux version).
Yes indeed. The only argument against using MNG seems to be that it is too complex. I don't really understand this argument since MNG isn't actually that complex and there is code available that deals with the complexity. However if the point is complexity, then the obvious solution is to define a subset of MNG so that more applications can add support for that subset (and perhaps add full support later). This has been done for other formats (for example SVG) and is has shown to work pretty well.
The other argument for the new format seems to be backwards compatibility with the PNG format. Applications that don't support it will show the first frame of the animation. Well, this is IMHO a strong argument against this hack. There is no advantage at all in having applications show the first frame of an animation w/o giving any incidence that more frames are available. If the animation format is not supported, nothing should be shown at all.
Well, except that this new "format" is not at all better than MNG. In fact it is inferior in a lot of aspects despite of it being a crude hack that violates the PNG spec.
This is a very stupid idea. Just when MNG was finally getting the attention it deserves and MNG support for Mozilla is about to be integrated back into the main trunk, some morons come up with a new format which is inferiour to MNG and also clearly violates the PNG spec. Let's hope this thing is forgotten soon and let's focus on making all browsers support MNG.
Certainly the most annoying quirk is not the button order (I love it), it's the idea that dialogs should not have a "Cancel" button. While it is of course perfect to have settings from a dialog apply instantly, you still want to be able to back out your changes by using the "Cancel" button.
Imagine you accidentally change a setting, it applies instantly and now you have no way to go back to the old setting unless you remember exactly what it was. That is a serious usability problem and IMO the HIG authors have been on some rather bad crack when they suggested to remove "Cancel" buttons all over the place.
Perhaps you should read the bug report more carefully then. Of course adding the setting alone won't change any application but the setting is a pre-requisite for making the button order configurable. It's the first step that has to be taken and only if this setting is available in GTK+ will patches to application be accepted.
I can only speak for The GIMP project but we would accept a patch that makes the button order dependant on a GTK+ setting. We would definitely not accept a patch simply changes the button order back.
Changing the button order back by forking the GNOME project? That's about the stupiest thing I've ever heard about. Instead of writing patches for each and every app out there (patches which are certainly not going to be accepted), you should first of all submit a patch for
http://bugzilla.gnome.org/show_bug.cgi?id=74669
As soon as this is fixed and in a released GTK+ version, you can start to submit patches to application to make them respect this setting. Such patches would then have a good chance to be accepted.
It would also help a lot if you stopped speaking about *fixing* the button order. I understand that you disagree with the decision (I do myself love it) but there is clearly no correct button order so there is nothing that could be fixed here.
More types of data being supported in cut-and-paste in GNOME apps. This means being able to cut-and-paste from the GIMP or Inkscape to Open Office and back again.
You'd have to put that on the GIMP / Inkscape / Oo roadmaps. But fortunately it's already on the GIMP roadmap at least. Might even make it into GIMP 2.2.
The py-slice and perlotine plug-ins for The GIMP do a very nice job on slicing your image putting it back together in HTML.
The idea of the GIMP is to provide you with the tools to do the job. It is supposed to be extended by plug-ins. Plug-ins that do not necessarily need to be maintained by the few GIMP core developers. "Save for Web" can easily be implemented in a plug-in. Why has such a plug-in not been written yet? Think about it and tell me.
There has been a button to access the menu in gimp-1.2 already (upper left corner of the image window). In gimp-2.0 there's an optional menubar at the top of the image window and it is enabled in the default configuration. You obviously haven't looked at The GIMP user interface for quite some time.
Well, if you tried GIMP-2.0, you might find that stroking a path gets you very nice antialiased lines drawn with GIMP. And text rendering is definitely up to par with PS. The author of this article compared unhinted text rendering (PS) with hinted text rendering (GIMP). If he wanted to get similar output from GIMP, he should have unchecked the "Hinting" toggle in the text tool options.
GIMP has professional quality rendering, it's just a matter of learning how to use it correctly.
Points 1 to 3 are planned for future GIMP versions but aren't that simple to implement at it may perhaps appear to you.
Point 4 is dogshit to use your own words. As can be easily seen by a direct comparison, the quality of the font rendering has much improved with GIMP2. GIMP-1.x could not even do proper antialiasing. It used to render the text bitmap three times the requested size and scaled it down. GIMP2 uses the Freetype and Pango libraries to produce well-hinted, antialiased, internationalized text.
You could put some effort into it then and rebuild the GIMP binaries with more uptodate versions of FreeType and Pango. The problems that people see with GIMP 2.0 on the Windows platform have all been addressed. It's just a matter of building a new binary based on freetype 2.1.8 and Pango 1.4.
Sooner or later those binaries will become available but you could help to make that happen sooner.
Why exactly are you suggesting a fork? You could instead join the GIMP development team and help them (or rather us since I am one of them) to improve the user interface. We are constantly working on improving The GIMP and your help would be very much appreciated.
Any contribution is useful, you don't even need to be a hacker to contribute. We need people to improve the documentation, we need people to propose a better menu structure, we need people who contribute mockups for more intuitive dialogs. Lots and lots of ways to help to make a better GIMP.
Only after you have tried to work with the GIMP developers and found for whatever reasons that your idea of a better GIMP isn't accepted, you should consider a fork.
What exactly is your problem with the new text tool? I know that there's room for improvement and GIMP 2.2 is supposed to bring some but I would still be interested to hear why you think that the new text tool is deficient.
Try a more recent version then. Unsharp mask radius goes down to 0.1 in GIMP 2.0. The other issue you mentioned will certainly be addressed at some point as well. Support for other color spaces and more color depth is on the roadmap.
Uhm, did you ever try GIMP 2.0? It does allow you to group the controls (or call them palettes or docks) in container windows, thus avoiding the need for dozens of windows floating on your screen.
Claiming that the GIMP developers wouldn't listen only shows that you never tried to talk to them.