You have a lot of valid points here. I just hope you realize how pointless it is to post such user interface criticism on slashdot. It would be a lot more helpful to file bug reports for them or bring them up on the gimp mailing-list or in the GIMP forum at openusability.org.
It's a miracle to me why noone has sat down and spent some days implementing a "Save for Web" plug-in for GIMP. There is definitely lots of interest in such a feature. The reason it doesn't exist is not that GIMP was not meant to be used for web production. It's simply because noone has coded it yet.
We have realized this a long time ago and have discussed it several times. But a mailing-list is a public place. You don't throw someone out of a public place just because you don't like him/her. Especially not if he/she is also often being helpful and he/she is one of the few people who are actually contributing to the project. It is a difficult situation but at some point it needs to be dealt with. That's why I was asking for evidence so that we can bring it up again if needed.
Actually no. The main reasoon GIMP is lacking lots of things is lack of active developers. There's really nothing that keeps us from adding support for high color depths and/or other color spaces like CMYK except that GIMP is being developed by a small group of volunteers with limited free time. If you want to help out, there are plenty of tasks in our bug tracker over at bugzilla.gnome.org that are waiting to be implemented. The GIMP developers will be happy to hold your hand and answer your questions.
Carol is not representative for the GIMP developers. The last time we heard about her sending such mails off-list, we asked her to stop it and were told that it wouldn't happen again. If it did indeed happen again (as you said), I would like you to report this incident and show evidence for it (but please not here on slashdot). If your claims are true, then it is probably about time that Carol gets her gimp.org mail address and web space revoked. We have been hesitant to do that until now because she is often very helpful and the content of carol.gimp.org is a very good resource for GIMP users. But her attitude towards some people on the mailing-list is indeed inacceptable and I am afraid that she is doing more harm than good.
GIMP doesn't rely on X Windows. It doesn't make any XLib calls but uses a highly portable abstraction layer called the GIMP toolkit (GTK+). GTK+ is currently being ported to Quartz and as soon as that port is finished it won't any longer require an X server to run on Mac OS X.
We are looking forward to your contributions that will help to integrate GIMP better with the Mac OS X desktop environment. Such patches are very much welcome.
The tutorials will be published, we just need some more time to prepare them for the website. Carol is already working on it and you should see the results online soon.
That is exactly what GIMP is doing. Plugins are not loaded on startup unless the executable changed since GIMP was last started. Instead the information is taken from the pluginrc file. For even further reduced startup time, try GIMP 2.3 and see my blog entry about GIMP startup time.
Actually, it wasn't quite like you put it. The FilmGimp developers told the GIMP developers that they don't think their code should be merged into the main trunk. It wasn't ready for it and would have broken things all over the place. FilmGimp was after all a very reduced version of GIMP. Noone has ever been locked out of GIMP development. I wonder where you picked that up.
And no, neither FilmGimp nor CinePaint have CMYK support. That has never been the intention behind this project. Instead it was about adding support for 16bit color depth. That is of course an important feature and at some point it is going to be added to GIMP as well. I can't tell you when because it simply depends on when someone will finish the remaining bits that are needed to bring GEGL into shape so that GIMP can start to use it.
If you think that GIMP is looking old, perhaps you should really consider to replace that old copy of GIMP 1.2 you are using.
Now why is that the fault of GIMP? GIMP does set the appropriate window hint that is telling the window manager that this is a splash screen. It appears that Apple is to be blamed here for delivering a lousy X server.
No problem. Menus, keybindings, icons and the like are all themable. I actually don't understand why the author (*sigh*) of this GIMP ripoff claims that he edited hundreds of files. The menu hierarchies are defined in a handful of XML files; all strings are translatable and can be changed by adding a new language ("en_PS" ?!). Unfortunately the "author" doesn't provide a diff of the changes. I am afraid that he did actually change the strings in the code. This will make it very difficult to keep up with upstream changes and it renders all translations invalid (GIMPs UI is translated into more than 40 languages). Anyway, this guy refused to even try to work with the GIMP development team. I asked him to join the GIMP menu reorganization effort but got no response whatsoever.
GIMP does have SOMETHING for quite a while already. There's a display filter (available under View->Display Filter) that allows you to do soft-proofing using ICC color profiles. There's also the separate plug-in that converts to CMYK based on profiles.
This is something that will improve with GIMP 2.4. There is already some code in CVS to improve integration of color management into the workflow.
GIMP 2.2 does copy-and-paste of PNG image data through the system clipboard. It does also accept SVG via drag-and-drop. This is going to be improved further with GIMP 2.4.
Well, do it then. I said it before whenever this came up here or anywhere else and I can say it again:
It shouldn't actually be hard to abstract window handling in the GIMP core to a point where we can offer users the choice to have the current UI or a WiW interface. If you or anyone else can come up with a clean patch to implement this. Or, even better, a detailed proposal and a set of small steps towards it, we, the GIMP developers, would certainly consider it.
We would also love to add tabbed images and whatever else you can think of to reduce the number of top-level windows or to make them interact better. We are constantly working on improving the user interface. Any help is appreciated.
Slashdot posters complaining about the UI are trolling, nothing else. I've even stated here on slashdot that we would accept a patch that abstracts window handling in a way that allows to implement different backends. The default backend would be the current behaviour, another backend could implement a windows-in-windows UI. Everyone who keeps claiming that the GIMP developers wouldn't care or would refuse to accept any changes is either badly misinformed or a troll. Anyone who really cares should shut and start coding.
Uhm, GIMP does exactly that since version 2.0. It's called startup notification and has been specified by the FreeDesktop project. How exactly the startup is being visualized depends on if and how your desktop implements the startup notification spec. The splash screen is just an extra eyecandy that can be easily turned off.
No GIMP plug-ins are loaded ever, except on very first startup where they are queried to register themselves. GIMP plug-ins also run as a seperate process. The moment you select one from the Filter menu, it is started and when it has done it's job, it quits.
Why not make yourself familiar with the basic concepts of an application before starting to make suggestions? Did you even check how long it takes for GIMP to start up? We are talking about a couple of seconds here (perhaps five seconds on a 1GHz machine). There is some small room for improvements in the startup phase but you would have to do some serious profiling to get a significant speedup. In case you are really interested, I posted a proposal on how to improve startup time to the gimp-developer mailing-list lately. You should be able to look it up in the archives.
You obviously didn't even take the time to look at GIMP since that's exactly what it's doing. Plug-ins are only queried on first start. On subsequent starts, the information is read from ~/.gimp-2.2/pluginrc.
Slashdot Mirror
You have a lot of valid points here. I just hope you realize how pointless it is to post such user interface criticism on slashdot. It would be a lot more helpful to file bug reports for them or bring them up on the gimp mailing-list or in the GIMP forum at openusability.org.
You mean something like this, don't you: http://gimp-sharp.sourceforge.net/screenshot-6.jpg
It's a miracle to me why noone has sat down and spent some days implementing a "Save for Web" plug-in for GIMP. There is definitely lots of interest in such a feature. The reason it doesn't exist is not that GIMP was not meant to be used for web production. It's simply because noone has coded it yet.
No, I can't see this. You are an anonymous coward and obviously trolling.
We have realized this a long time ago and have discussed it several times. But a mailing-list is a public place. You don't throw someone out of a public place just because you don't like him/her. Especially not if he/she is also often being helpful and he/she is one of the few people who are actually contributing to the project. It is a difficult situation but at some point it needs to be dealt with. That's why I was asking for evidence so that we can bring it up again if needed.
Actually no. The main reasoon GIMP is lacking lots of things is lack of active developers. There's really nothing that keeps us from adding support for high color depths and/or other color spaces like CMYK except that GIMP is being developed by a small group of volunteers with limited free time. If you want to help out, there are plenty of tasks in our bug tracker over at bugzilla.gnome.org that are waiting to be implemented. The GIMP developers will be happy to hold your hand and answer your questions.
Carol is not representative for the GIMP developers. The last time we heard about her sending such mails off-list, we asked her to stop it and were told that it wouldn't happen again. If it did indeed happen again (as you said), I would like you to report this incident and show evidence for it (but please not here on slashdot). If your claims are true, then it is probably about time that Carol gets her gimp.org mail address and web space revoked. We have been hesitant to do that until now because she is often very helpful and the content of carol.gimp.org is a very good resource for GIMP users. But her attitude towards some people on the mailing-list is indeed inacceptable and I am afraid that she is doing more harm than good.
GIMP doesn't rely on X Windows. It doesn't make any XLib calls but uses a highly portable abstraction layer called the GIMP toolkit (GTK+). GTK+ is currently being ported to Quartz and as soon as that port is finished it won't any longer require an X server to run on Mac OS X.
We are looking forward to your contributions that will help to integrate GIMP better with the Mac OS X desktop environment. Such patches are very much welcome.
Have you read the gimp man-page, in particular the part about splash images? http://gimp.org/man/gimp.html#SPLASH
The tutorials will be published, we just need some more time to prepare them for the website. Carol is already working on it and you should see the results online soon.
The name is GNU Image Manipulation Program, what's offensive about that? You could simply stop using the acronym if it bothers you.
That is exactly what GIMP is doing. Plugins are not loaded on startup unless the executable changed since GIMP was last started. Instead the information is taken from the pluginrc file. For even further reduced startup time, try GIMP 2.3 and see my blog entry about GIMP startup time.
Actually, it wasn't quite like you put it. The FilmGimp developers told the GIMP developers that they don't think their code should be merged into the main trunk. It wasn't ready for it and would have broken things all over the place. FilmGimp was after all a very reduced version of GIMP. Noone has ever been locked out of GIMP development. I wonder where you picked that up.
And no, neither FilmGimp nor CinePaint have CMYK support. That has never been the intention behind this project. Instead it was about adding support for 16bit color depth. That is of course an important feature and at some point it is going to be added to GIMP as well. I can't tell you when because it simply depends on when someone will finish the remaining bits that are needed to bring GEGL into shape so that GIMP can start to use it.
If you think that GIMP is looking old, perhaps you should really consider to replace that old copy of GIMP 1.2 you are using.
One step is too depressing? Yes, there's a script that does it all in one step and it has been part of the GIMP distribution for like 8 years.
Now why is that the fault of GIMP? GIMP does set the appropriate window hint that is telling the window manager that this is a splash screen. It appears that Apple is to be blamed here for delivering a lousy X server.
i mp-startup-time/
On a related note, GIMP startup takes about 3 to 5 seconds here. See also http://svenfoo.geekheim.de/index.php/2005-11-05/g
The 770 uses Opera as its web browser but I guess the plan is to replace it with a GtkWebCore based browser as soon as it is ready.
No problem. Menus, keybindings, icons and the like are all themable. I actually don't understand why the author (*sigh*) of this GIMP ripoff claims that he edited hundreds of files. The menu hierarchies are defined in a handful of XML files; all strings are translatable and can be changed by adding a new language ("en_PS" ?!). Unfortunately the "author" doesn't provide a diff of the changes. I am afraid that he did actually change the strings in the code. This will make it very difficult to keep up with upstream changes and it renders all translations invalid (GIMPs UI is translated into more than 40 languages). Anyway, this guy refused to even try to work with the GIMP development team. I asked him to join the GIMP menu reorganization effort but got no response whatsoever.
GIMP does have SOMETHING for quite a while already. There's a display filter (available under View->Display Filter) that allows you to do soft-proofing using ICC color profiles. There's also the separate plug-in that converts to CMYK based on profiles.
This is something that will improve with GIMP 2.4. There is already some code in CVS to improve integration of color management into the workflow.
The CVS version of GIMP has Altivec support. That makes it two applications already ;)
GIMP 2.2 does copy-and-paste of PNG image data through the system clipboard. It does also accept SVG via drag-and-drop. This is going to be improved further with GIMP 2.4.
Well, do it then. I said it before whenever this came up here or anywhere else and I can say it again:
It shouldn't actually be hard to abstract window handling in the GIMP core to a point where we can offer users the choice to have the current UI or a WiW interface. If you or anyone else can come up with a clean patch to implement this. Or, even better, a detailed proposal and a set of small steps towards it, we, the GIMP developers, would certainly consider it.
We would also love to add tabbed images and whatever else you can think of to reduce the number of top-level windows or to make them interact better. We are constantly working on improving the user interface. Any help is appreciated.
Slashdot posters complaining about the UI are trolling, nothing else. I've even stated here on slashdot that we would accept a patch that abstracts window handling in a way that allows to implement different backends. The default backend would be the current behaviour, another backend could implement a windows-in-windows UI. Everyone who keeps claiming that the GIMP developers wouldn't care or would refuse to accept any changes is either badly misinformed or a troll. Anyone who really cares should shut and start coding.
Uhm, GIMP does exactly that since version 2.0. It's called startup notification and has been specified by the FreeDesktop project. How exactly the startup is being visualized depends on if and how your desktop implements the startup notification spec. The splash screen is just an extra eyecandy that can be easily turned off.
No GIMP plug-ins are loaded ever, except on very first startup where they are queried to register themselves. GIMP plug-ins also run as a seperate process. The moment you select one from the Filter menu, it is started and when it has done it's job, it quits.
Why not make yourself familiar with the basic concepts of an application before starting to make suggestions? Did you even check how long it takes for GIMP to start up? We are talking about a couple of seconds here (perhaps five seconds on a 1GHz machine). There is some small room for improvements in the startup phase but you would have to do some serious profiling to get a significant speedup. In case you are really interested, I posted a proposal on how to improve startup time to the gimp-developer mailing-list lately. You should be able to look it up in the archives.
You obviously didn't even take the time to look at GIMP since that's exactly what it's doing. Plug-ins are only queried on first start. On subsequent starts, the information is read from ~/.gimp-2.2/pluginrc.