On Sat, Jan 4, 2014 at 2:14 AM, Jeffery Small wrote:
> My simple solution is to provide a workflow switch in the preferences
> that flips back and forth between the two workflow paradigms.
Which has already been evaluated and denied.
> In his blog post on "GIMP 2.8: understanding UI changes," Alexandre Prokoudine
> addresses the suggestion above:
Not a blog post, but that's just a minor remark.
> "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."
> "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.
This is an absolutely meaningless statement. The cook in the
kindergarden I went to when I was a kid couldn't cook a meal worth a
damn, and she had been at this job for decades. This is really not the
kind of argument one would use to prove credibility.
> Is this a realistic statement or hyperbole?
It is a realistic statement.
> 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?
In the two or more years that we've been having this discussion noone
has demonstrated the ability to
1) implement such a switch;
2) maintain a project containing such a switch;
3) ensure that noone is confused by the fact that different tutorials
refer to different workflows of the same app.
In fact, people who patched GIMP to revert the change are still
incapable of even maintaining their respective forks and keeping them
up to date with all the bugfixes we've had since releasing 2.8.0. Case
in point: https://github.com/mskala/noxcf-gimp.
To me this clearly indicates that nobody really wants to do introduce
this kind of a switch. (Not that the team would accept it in the
upstream project, mind you.) The amount of hot air regarding a
possibility of such a switch, however, is truly incredible.
> "3. Behavior options make documentation convoluted and lacking
> 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.
And that's coming from someone who's been developing software for 40
years? Sorry, but in my eyes you've just lost all your credibility.
To sum it up, every change in UI opens the floodgate. In real life,
people can stare at the slightly rephrased UI message and never
realize it's what they need, then go to a forum and pester other
people about "removed feature". This is the reality that people who
actually communicate to users have to deal with.
> "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
> So far as I know, no one accused anyone of "hating"
Exactly: so far as _you_ know.
> But refocusing doesn't mean you have to totally
> ignore the existing user base.
Nobody's being ignored, let alone totally ignored. For someone who
claims to have attempted being respectful that was one hell of a nasty
gimp-user-list mailing list
List address: email@example.com
List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list
List archives: https://mail.gnome.org/archives/gimp-user-list