Sometime before 2010 when GIMP introduced single-window mode, GIMP was “weird.” There was a plugin called GIMP deweirdifier and a fork called GIMPshop that used the plugin and made other changes. The permanent solution was to add single-window mode to GIMP and take some additional steps. There were several discussions online such as on the GIMP forum about how GIMP was weird. The responses from developers were something like:
- To make everything in one window would require drastic structural changes to GIMP. Even if we did make the change, people wouldn’t have as much space in the drawing area [Some people other than developers probably concurred with that part].
- You must propose actionable incremental steps or there isn’t a clear solution, and the discussion isn’t productive.
I took the advice and started to understand how to talk to developers better. That is when I first began to put myself in the shoes of a software developer. I can’t say I’m the only one with the idea nor that I was solely responsible for the GIMP becoming less weird, nor even the only one who noticed these specific problems. However, I can say that I was (from what I could find at the time) the only person making suggestions that were specific and incremental enough to provide a path forward. I can also say that shortly after I provided the suggestions, they were implemented. I can’t find the post anymore since the GIMP forum software changed and don’t know exactly what URL to search on the wayback machine. Since the post is not available (to my knowledge), I’ll summarize it below (The wording is close to exact in certain parts, but parts in brackets and after “Aftermath” weren’t in the initial post).
Title: Incremental Steps to Normalize GIMP
There are several people posting about how GIMP is weird, but there doesn’t seem to be a clear way to solve the issue. I suggest making this issue a priority since GNOME’s flagship product doesn’t follow the GNOME interface guidelines. The main issue with the overall structure is that it is in multiple windows. In fact, whenever I show a new person GIMP, they look around the screen confused and start closing all of them…Then when they exit, the Windows are gone permanently (since the layout saves on exit)! I have done some development on Windows, so I have some specific suggestions to help normalize GIMP.
1. Make saving the window positions optional, and off by default. I mention this first since even if no other changes are made, people could close the program and re-open it to get anything back that they “messed up” (by permanently closing child forms). Users should be able to learn by trial and error without having to have advanced knowledge to fix the issue (such as knowledge of the exact names of the child forms, which ones they actually need, and how to re-enable them).
2. Make child forms look different than the parent Window.
Many Windows programs, even Photoshop, have child forms. Windows has a specific window style that gives users a visual cue as to which one is the main form and which are child forms. You can set WindowStyle to ToolWindow in all child forms to solve this issue. Even just changing the window style will greatly reduce confusion.
Eventually you could make the child windows dockable. If having a single window mode is considered less useful since it encroaches on the size of the painting area, perhaps make an optional single-window mode that is on by default.
3. Make sub-windows not create taskbar buttons.
You can set the ShowInTaskbar boolean to false on each child form to solve this issue.
[The exact API documentation may have differed circa 2009]
4. Make all menu items available even if an image isn’t open.
There has been some discussion about this, but there hasn’t been any solution. Users say it is weird to have some of the main menu bar headings on the toolbox window and others on the image. The stated problem from developers has been that if they were all on the toolbox then the toolbox would be too wide, and if they were all on the image, then they would disappear when all images were closed.
To solve this, I suggest having a special image called “the empty image” (conceptually it could be called that, but it could be some sort of object that is a subclass of the image form class). The empty image would have the following behaviors:
- All menu items from the toolbox and the images would be combined into it so that there is only one menu bar. When combining the two menu bars, duplicate Alt+keys should be changed (other hotkeys shouldn’t be a problem since they are already global). If necessary, all images would still have a copy of the toolbar. However in a single-window mode the images could be in tabs inside of it–In that case only one copy of the menu bar would be necessary.
- Whenever there are no images open, the empty image would appear.
- The background of the image would be some sort of blank window background color instead of containing an image.
- When the first image is selected via “File,” “Open” in the menu bar or by other means such as a command-line argument to GIMP, the empty image would disappear and the first real image window would appear (or the empty image would be transformed into a regular image window).
Aftermath
Replies: I don’t remember what replies were made to my post, but I think there may have been one or more positive responses before the forum shut down and GIMP changed to the new forum software.
Barring the suggested defaults, 100% of my suggestions were implemented shortly after my post!
Here are some web pages that describe how and when the changes were implemented:
- Hands-on: new single-window mode makes GIMP less gimpy Feb 3, 2010
- Single Window mode in GIMP Dec 26, 2012 (This post mentions “Gimp Shop” which was actually called GIMPshop)
This was the story about how GIMP changed, and how you can help developers by being patient, respectful and specific when you critique their software and provide bug reports or feature requests. You should also take the time to find out where is the appropriate place to start a discussion, since some projects say to use their forum not their issue tracker for feature requests. Even with that approach, I was able to emphasize the importance of the issue in the following ways: 1. I cited sources (specific GNOME interface guidelines and specific Microsoft Windows API documentation). 2. I cited community consensus (I may have cited specific forum threads and issues). 3. I offered ways to compromise and ways to make incremental changes instead of demanding everything which often leads to nothing.
[If I remember anything else, or if I find the original post, I’ll update this article. If you can find the original post or can even suggest a way (such as specific URLs on the wayback machine) to find it, please comment.]