Liam R E Quin <l...@holoweb.net> writes: >Constructive suggestions about how to make a more coherent workflow in >GIMP are welcomed. Whining about change is not so welcome.
Liam: I will take you up on your offer to make a constructive GUI suggestion. I fully understand the arguments for the workflow change that was made to GIMP 2.8. What I think was lost in the process was a recognition that there are two different primary workflows for two different groups of users. The new Save/Export distinction makes great sense for professionals working primarily in the xcf format. I do this a great deal myself and can embrace this workflow strategy. What seems to be unjustifyably dismissed by the development team is that there is a very large segment of the user base that operates by a different workflow altogether. These people use/save in the xcf format rarely or never, but use GIMP to do wholesale editing of png/jpg photos with a completely different purpose in mind from the "pros". I myself also engage in this type of activity from time to time. The arguments about lossey jpg saves or unsaved worksteps in the editing process are typically understood by this group, but of little to no concern. And if switching from Ctrl-S to to Ctrl-E was the only change in behavior required, then I believe that there would be very few serious complaints. The real problem occurs in the exiting from the workflow after an export. The forced "save" query really slows down this particular workflow process. For this group of people, it is a repetitive bludgeoning by something that is absolutely unwanted. When attempting to work in this mode, I can attest that it is very annoying. There is no right/wrong or better/worse workflow process -- only a preferred one for the type of work currently at hand. Why can't the development team recognize and acknowledge this instead of berating those who do not find the "pro" solution the best one for their needs? My simple solution is to provide a workflow switch in the preferences that flips back and forth between the two workflow paradigms. Let GIMP default out of the box to the new "pro" mode, but allow users to select the alternate workflow model if they choose. I would include some sort of icon somewhere (status area?) that indicated visually that you were operating using the alternate workflow method. A shortcut key could allow users to quickly toggle back and forth between the two modes. Whether Ctrl-S/Ctrl-E were swapped in the process is a matter for discussion (I wouldn't care if they stayed as they currently are in 2.8) but suppressing the subsequent "save to xcf" check would be the really important improvement. In this alternate mode, the old behavior of recognizing the file extension should be preserved, allowing users to save to xcf format anytime they desired. However, if Save is reserved for xcf and Export is still required to "save" the current png/jpg file, then this extension parsing might not be required. In other words, I believe there is some variability in how this could be implemented that would still go a long way in addressing most users' concerns. Getting input from other users would be helpful here. If something along these lines were done, the "pros" would never see any change to their use of GIMP, while countless users would recognize that the development team was actually listening and responding to their concerns instead of rejecting them out of hand. In his blog post on "GIMP 2.8: understanding UI changes," Alexandre Prokoudine addresses the suggestion above: ---------- "Why Couldn't They Just Add A Checkbox?" "Isn't it possible to just add a checkbox in the configuration dialog somewhere? It is." OK, good. "Would it be a good idea? No, it would be horrible. Let's have some reasoning again." "1. In general, options complicate code and make it less manageable. Every option virtually increases amount of cases where application can fail. A snowball can soon become an avalanche." Seriously? This is an argument against implementing a feature that is extremely useful to many users? Especially one a trivial as this? One that already has existed for years in the product? I think this snowball is just a snowball. "2. Certain planned changes such as better native CMYK support presume that color separation is done a special mode for exporting. Maintaining a related behavior switch, when you have such a feature, would be hell." Hell? Really? I've been developing software for 40 years. Is this a realistic statement or hyperbole? Again, we're talking about saving/exporting standard png/jpg files while bypassing the xcf save. Regardless of what is happening with CMYK, it is either saved/exported to these formats or it's not. How could this workflow introduce a massively complicating factor? "3. Behavior options make documentation convoluted and lacking consistence." We're not talking about opening the flood gate of change here. This is one simple workflow change that requires one simple update to the documentation. "People still take offense at this change, and there is probably no cure for that other than repeating again and again: the team doesn't hate you, they just refocused on a group of users for whom this makes a lot of sense." So far as I know, no one accused anyone of "hating" so that seems to me like just another straw-man argument. Yes, you are refocusing on a different type of user. But refocusing doesn't mean you have to totally ignore the existing user base. This is a very simple issue with a very simple resolution. There has been a huge amount of blowback over this. Honestly, I am at a loss to understand why there has been such a level of resistance for acquiescing, in some small way, on this point which is clearly so important to so many. So there you have it, as calmly and as respectfully as I can frame it. All the best, -- C. Jeffery Small _______________________________________________ gimp-user-list mailing list List address: firstname.lastname@example.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list