El 10/03/13 11:10, rafał rush escribió:

Hi
Gradients in gimp are very very painful thing. I love gimp and i used it a lot but gradients are nightmare. I see that you are making new tools and other stuff but the most important thing and the thing that all graphic designers using all the time is gradient. To make simple gradient i must do hundred clicks. Gradient window is weird and difficult for new user. Are you planing make gradient tool more user friendly?

A nightmare, a pain? I can agree that editing the endpoints is not as straightforward as it should, but adding stops requires only to drag and drop colors on the gradient editor.

How exactly would you do it "more user friendly"? Probably in the future when a gradient is a GEGL node the tool could be extended to allow th edit the stops on canvas making the gradient editor almost unnecessary, but right now it's not possible since you have to define the gradient before applying it, and once you did it it becomes pixels.

The gradient editor could use some improvements, of course, but saying it's a painful thing, a nightmare and stating that you have to do "hundred clicks" is an unnecessary exaggeration. Why don't you try describing the parts you think are more problematic and propose how to do it better?

Gez

Date: Sun, 10 Mar 2013 13:14:14 -0300 From: gespertino@gmail.com
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] gimp gradients

El 10/03/13 11:10, rafał rush escribió:

Hi
Gradients in gimp are very very painful thing. I love gimp and i used it a lot but gradients are nightmare. I see that you are making new tools and other stuff but the most important thing and the thing that all graphic designers using all the time is gradient. To make simple gradient i must do hundred clicks. Gradient window is weird and difficult for new user. Are you planing make gradient tool more user friendly?

A nightmare, a pain? I can agree that editing the endpoints is not as straightforward as it should, but adding stops requires only to drag and drop colors on the gradient editor.

How exactly would you do it "more user friendly"? Probably in the future when a gradient is a GEGL node the tool could be extended to allow th edit the stops on canvas making the gradient editor almost unnecessary, but right now it's not possible since you have to define the gradient before applying it, and once you did it it becomes pixels.

The gradient editor could use some improvements, of course, but saying it's a painful thing, a nightmare and stating that you have to do "hundred clicks" is an unnecessary exaggeration. Why don't you try describing the parts you think are more problematic and propose how to do it better?

Gez _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

I have a mixed opinion about this. For starters, actually painting the gradient is a simple task - make a selection (when/as desired), switch to the Gradient tool, then click and drag, and the only flaw in this system is the inability to define gradient length for shaped gradients (you still have to click AND drag to initiate the painting, but the drag length has no effect on shaped gradients. It would be tons easier to, say, create a simple gradient border if you could define the length).

I also agree that editing a custom gradient can be both difficult and annoying.

1 - The gradient editor is segment-based, not node-based. While I agree that some functions (e.g. blending mode and handle) are inherently segment-oriented while others (endpoint type/color) are node-oriented, I find it generally counter-intuitive.

2 - Making node colors contiguous - the same color on both sides - is not the default behavior, when it should be. (Most gradients utilize contiguous node colors anyway.) Currently you have to manually click the neighboring segment and select "Load endpoint's color > from neighboring endpoint". This very quickly becomes tedious on the end user.

3 - When using HSV segment blending, greys and whites are assumed to have a red hue, which can produce some weird results (because greys and whites technically don't have any hue whatsoever).

4 - I can't seem to find a way to make GIMP auto-generate a node's color based on its position between neighboring segments (and, where applicable, blending modes). For example, if one segment of my custom gradient starts at 30% grey, the next one ends with 80% grey, and a node in the middle is positioned 40% away from the left end, the node's default color (based on linear blending) would be (40% of the way from 30% to 80%, aka...) 50% grey, but I can't find a way to make GIMP calculate and set this color automatically.

5 - I think the context menus for setting the endpoint colors could use some tweaking. Currently they say: - Color Type >
- - Fixed
- - Foreground
- - Foreground (Transparent)
- - Background
- - Background (Transparent)
- Endpoint's Color.... (loads color selector)

Perhaps they could say instead: - Endpoint's Color >
- - Fixed color... (loads color selector) - - Use Foreground
- - Use Foreground (Transparent)
- - Use Background
- - Use Background (Transparent)

6 - And while we're on the subject, it would be nice if GIMP could define colors for each endpoint/node in RGBA terms (like Inkscape does) instead of just RGB. But that's probably a bit more intensive....

However, I have to disagree that painting a "simple" gradient is anywhere near painful - the two most common gradients I actually paint with are "FG to BG" and "FG to Transparent" because they don't use predefined colors. The only problem with these gradients is the inability to adjust their handles (which is not unique to gradients, all resource types - especially brush dynamics - have the same problem).

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

=

On 03/10/2013 05:14 PM, Guillermo Espertino (Gez) wrote:

El 10/03/13 11:10, rafał rush escribió:

Hi
Gradients in gimp are very very painful thing. I love gimp and i used it a lot but gradients are nightmare. I see that you are making new tools and other stuff but the most important thing and the thing that all graphic designers using all the time is gradient. To make simple gradient i must do hundred clicks. Gradient window is weird and difficult for new user. Are you planing make gradient tool more user friendly?

A nightmare, a pain? I can agree that editing the endpoints is not as straightforward as it should, but adding stops requires only to drag and drop colors on the gradient editor.

This must be part of Gimp's Great Oral Tradition... I can't find the word "drop" in http://docs.gimp.org/en/gimp-gradient-dialog.html :)

This said, after trying it, the gradient editor indeed looks better.

BTW, this is my personal usecase scenario where editing a gradient in GIMP was unexpectedly a painful thing:

I was trying to create a sepia-like gradient -- a gradient that fades from black to sepia (for simplicity, let's just say RGB #804000) to white. Y'know, something I can just Gradient Map onto a grayscale image later on.

This poses several challenges:

1 - Because the endpoints are black and white, any blend between those endpoints will only ever produce a greyscale gradient. This applies in both RGB and HSV space (black and white by definition have saturation=0). Therefore I require a node in the middle to specify the desired color.

2 - Because I will be tweaking or changing the color to suit my tastes (there's a specific image I'm trying to match), and this gradient is contiguous, I constantly have to tell GIMP to "Load endpoint's color from > neighboring endpoint" every time I make the slightest tweak to the node's color. This doubles the number of steps I have to perform just to set one color -- but as a small optimization, I can simply tell GIMP to use my foreground color in the meantime. The only problem with doing that, though, is once I'm finished tweaking the color I have to set the color type (and remember, on both sides) back to "fixed" before I save the gradient and quit GIMP.

3 - My chosen RGB tone doesn't exactly carry the same luminance as a 50% grey, does it? So I need to apply the equivalent of a midtones/gamma adjustment to it. I set each segment to Curved blending, drag this node to the left, brightening the overall appearance of the gradient....

4 - But I see another problem - the midpoints between nodes (white handles) don't move in proportion to the overall length of their segment. So I have to adjust them too. Now instead of just manually positioning one handle, I now have to manually position three.

5 - And because this gradient should approximate a curved blend, I can't just re-center the handles in their respective segment - if my middle node is 40% from the left, each segment's midpoint also has to be 40% from their left endpoint too.

6 - And did I mention that I'm alternating between tweaking both the color and position as I go along?

7 - Cue banging of head against the keyboard in frustration and having to undo whatever steps GIMP may have interpreted those keystrokes as. (Oh, wait, the Gradient Editor doesn't even have its own undo system -- cue banging of head against monitor....)

Now in some alternate universe where editing gradients is done solely on a conceptual level, I could have just:

a - Specified the starting color (RGB black) in HSL values of: hue = 30°, saturation = 100%, luminosity = 0%. b - Specified the ending color (RGB white) in HSL values of: hue = 30°, saturation = 100%, luminosity = 100%. c - Assigned HSL color mode to the segment. (midpoint of segment becomes: hue 30°, saturation = 100%, luminosity = 50%, a.k.a. RGB #804000) d - Specified Curved blending on the segment and adjust the midpoint until I get the desired result. e - Done!

Yeah, that would be nice....

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth. =

El 10/03/13 15:16, Ofnuts escribió:

This must be part of Gimp's Great Oral Tradition... I can't find the word "drop" in http://docs.gimp.org/en/gimp-gradient-dialog.html :)

This said, after trying it, the gradient editor indeed looks better.

Heh, I didn't check the documentation, but one of the great things in GIMP is being able to drag and drop colors from swatches (it's also a nice method for color fill without going to the bucket fill tool, so I use it a lot and it's the first thing I tried when I wanted to edit a gradient.

I guess this should be added to the documentation.

- To modify an existing stop: grag and drop a color on the black triangle. - To add a new stop, drag and drop a color on the gradient preview - To move stops and modify the transition curve between them, drag the black and white triangles respectively.

IMO it's very, very simple (of course, if you found how to do it or somebody told you, so point taken about the lack of documentation about this way to customize gradients).

Gez.

On Sun, Mar 10, 2013 at 6:10 PM, rafał rush wrote:

Hi
Gradients in gimp are very very painful thing. I love gimp and i used it a lot but gradients are nightmare. I see that you are making new tools and other stuff but the most important thing and the thing that all graphic designers using all the time is gradient. To make simple gradient i must do hundred clicks. Gradient window is weird and difficult for new user. Are you planing make gradient tool more user friendly?

Planning would be a too strong word, perhaps, but we do want to improve that in the future.

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre wrote:

Gradients in gimp are very very painful thing. Are you planing make gradient tool more user friendly?

Planning would be a too strong word, perhaps, but we do want to improve that in the future.

I must say I am thinking of picking either the gradient or align tool as the module for my students to design.

both are simply up for grabs.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Mon, Mar 11, 2013 at 3:20 PM, peter sikking wrote:

Gradients in gimp are very very painful thing. Are you planing make gradient tool more user friendly?

Planning would be a too strong word, perhaps, but we do want to improve that in the future.

I must say I am thinking of picking either the gradient or align tool as the module for my students to design.

both are simply up for grabs.

That would be great if a spec will come out of it.

*cough* selection tool *cough*

:)

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre wrote:

I wrote:

I must say I am thinking of picking either the gradient or align tool as the module for my students to design.

both are simply up for grabs.

That would be great if a spec will come out of it.

*cough* selection tool *cough*

spec writing seems to be a waste of time, competence and enthusiasm at the moment. developers simply throw away a third of it and do what they want. this pattern has been growing at GIMP over the last years.

so yes, the student exercises that I publish in my blog are not designs for implementations. that takes more, especially fully experienced interaction designer involvement.

so at the moment I am limiting my GIMP activities to parts where the contribution vs. return ratio is worth it. apart from the teaching using GIMP as real software, I have to figure out where else that is.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Von: "peter sikking"
An: "gimp-developer list"
Betreff: Re: [Gimp-developer] gimp gradients

Alexandre wrote:

I wrote:

I must say I am thinking of picking either the gradient or align tool as the module for my students to design.

both are simply up for grabs.

That would be great if a spec will come out of it.

*cough* selection tool *cough*

spec writing seems to be a waste of time, competence and enthusiasm at the moment. developers simply throw away a third of it and do what they want. this pattern has been growing at GIMP over the last years.

My feeling as only occasional contributor is that it is currently hard to determine if a spec is fully implemented or not, and if not, what parts are missing.

Some specs, like e.g., Save & Export, seem to be next to complete.

Others, like the Unified Transform Tool, are implemented up to a point where any further steps felt like removing existing functionality - and have thus are thus left the tool in an inconsistent state.

Would it help if the state of the implementation was tracked in the gui wiki itself, by marking paragraphs and sections as implemented or missing?

Regards,
Michael

Well, if I could say something about creating gradients in gimp (as a regular user), there are some issues that I think that can get the user confused or frustrated:

- using right mouse button to change colors and to split segments: Intuitivelly, I see the right mouse button as "more options" for anything. Having to access the main funcions of the editor with right mouse button is strange (and I just discovered it after reading a tutorial).
- not allowing the movement of the endpoints is a little frustrating. If you want to extend the endpoint color a little, you have to create a new segment.
- there's a color box in the gradient editor that is only for previewing colors. It would be great if it could be used to change the selected segment color. Have to use foreground/background color slows a little the proccess, i think.
- a numerical input for the position for the segment would be great too, just like Blender's ramp editor.

Well, maybe I am missing some functionality here because I never used too much the gradient editor, as I did not knew the drag and drop from palette as described here... My apologies if I addressed something that is wrong :)

On Mon, Mar 11, 2013 at 5:43 PM, free wrote:

Well, if I could say something about creating gradients in gimp (as a regular user), there are some issues that I think that can get the user confused or frustrated:

- using right mouse button to change colors and to split segments: Intuitivelly, I see the right mouse button as "more options" for anything. Having to access the main funcions of the editor with right mouse button is strange (and I just discovered it after reading a tutorial). - not allowing the movement of the endpoints is a little frustrating. If you want to extend the endpoint color a little, you have to create a new segment.
- there's a color box in the gradient editor that is only for previewing colors. It would be great if it could be used to change the selected segment color. Have to use foreground/background color slows a little the proccess, i think.
- a numerical input for the position for the segment would be great too, just like Blender's ramp editor.

Well, maybe I am missing some functionality here because I never used too much the gradient editor, as I did not knew the drag and drop from palette as described here... My apologies if I addressed something that is wrong :)

In a nutshell, and that's my personal view, the gradient editing should happen on canvas, much like in Inkscape (0.49 also places numerical input for colors stops position on the tools settings toolbar). And in GEGL-based GIMP a gradient fill should be re-editable.

Alexandre Prokoudine http://libregraphicsworld.org

El 11/03/13 11:20, Alexandre Prokoudine escribi:

In a nutshell, and that's my personal view, the gradient editing should happen on canvas, much like in Inkscape (0.49 also places numerical input for colors stops position on the tools settings toolbar). And in GEGL-based GIMP a gradient fill should be re-editable.

That was my point in my first reply. The tool itself could be extended in the future and the current limitations in gradient editor aren't that critical to justify an overhaul (at least not now).

This is also my personal view as a user, but I can live with the current tool waiting for a more flexible, non destructive on-canvas tool.

Gez.

Michael Schumacher wrote:

spec writing seems to be a waste of time, competence and enthusiasm at the moment. developers simply throw away a third of it and do what they want. this pattern has been growing at GIMP over the last years.

My feeling as only occasional contributor is that it is currently hard to determine if a spec is fully implemented or not, and if not, what parts are missing.

Some specs, like e.g., Save & Export, seem to be next to complete.

it is not about incomplete implementation. although that happens, is no fulfilling, but it at least gives a chance of can be taken further, also in the design, next time.

the problem is complete substitution of a third of the design by developer-made stuff. although the reasons for this may varystraightforward implementation; I know better; or the need for tinkeringthe result is always the same: a significant shift in the users-tech-project balance, in favour of tech and at the cost of users and the project.

Others, like the Unified Transform Tool, are implemented up to a point where any further steps felt like removing existing functionality - and have thus are thus left the tool in an inconsistent state.

it is not only the unified transform tool, although that is the one that broke my back, certainly after our Vienna BOF. it is the string of these things, and the thats the way it is cheerfulness that developers display with it, that is exhausting me.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

On Mon, Mar 11, 2013 at 6:32 PM, peter sikking wrote:

it is not only the unified transform tool, although that is the one that broke my back, certainly after our Vienna BOF. it is the string of these things, and the thats the way it is cheerfulness that developers display with it, that is exhausting me.

AFAIK, the latest issue here was a missing rationale for duplicating transformation tools (Unified Transform as "feel" tool + separate "precision" tools).

I hope we can work through these different points of view.

Alexandre Prokoudine http://libregraphicsworld.org

Alexandre wrote:

On Mon, Mar 11, 2013 at 6:32 PM, peter sikking wrote:

it is not only the unified transform tool, although that is the one that broke my back, certainly after our Vienna BOF. it is the string of these things, and the thats the way it is cheerfulness that developers display with it, that is exhausting me.

AFAIK, the latest issue here was a missing rationale for duplicating transformation tools (Unified Transform as "feel" tool + separate "precision" tools).

OK, in all craftsmanship, and GIMP is all about craftsmanship and getting there, there is a balance between doing the next task totally free (take a hand tool, start and it will come out 100%) and totally controlled (using jigs). every individual craftsman takes depending on the next task and her/his skills and experience a unique decision. as a tool supplier (GIMP) we we end up aiming for a 50/50 mix of free + controlled.

this is for instance a reason why in the paint system we need an equal balance between working with presets (controlled) or knocking up/adjusting setting on the spot (free).

it is elementary.

you can read much more about this in the nature and art of workmanship by David Pye. very thorough. you can read it online at google books.

and talking about duplication: we would end up with much less tools: unified transform, rotation and perspective tools. and then we take it from there (now is my time to say that).

what about having it all in one tool? not what 2 decades of experience in interaction design says. and having designed this tool and actually made the hundreds of decisions in it, I can tell you that not having precision and _useful_ number entry (read that again, not the #$%^&* 3x3 matrix) as requirements made important things possible, like combining all the geometry operations at random, and optimising the free part.

I hope we can work through these different points of view.

well, as long as I get shown the middle finger where it comes to implementing the control frame of the tool, I think the situation is completely out of whack here where it comes to interaction design and usability.

remember, it is open source: only successful contribution counts.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

yup, "painful" would be the right word. Over time, i have just resorted to simple tools. When in need of a gradient I draw it by hand using brushes, size it and blur it. in other words I paint it and deal with it just like any other layer. much simpler and far less painful. This approach might not be for everyone, but it works for me. Being in interaction design myself, I have always thought "why do we have those clunky dialog windows for such a hand-on thing?" in the first place.

--- Aleksandar Kovač
Kyoto Institute of Technology

On 2013/03/10, at 23:10, rafał rush wrote:

Hi
Gradients in gimp are very very painful thing. I love gimp and i used it a lot but gradients are nightmare. I see that you are making new tools and other stuff but the most important thing and the thing that all graphic designers using all the time is gradient. To make simple gradient i must do hundred clicks. Gradient window is weird and difficult for new user. Are you planing make gradient tool more user friendly? _______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

On 2013/03/12, at 0:45, peter sikking wrote:

well, as long as I get shown the middle finger where it comes to implementing the control frame of the tool, I think the situation is completely out of whack here where it comes to interaction design and usability.

remember, it is open source: only successful contribution counts.

Hi Peter,
please don't get me wrong on this one since I truly admire your work on GIMP and the fact that you are educating a generation of students for interaction design for open source. The written words can not communicate properly the sincerity and there is always a bit of cynism lurking, but I want to assure you that there is no cynism but only sincerity.

I would like to remind you that open source is not about "only successful contribution counts". We have seen a case or two where initially unsuccessful contribution made all the difference in the long run, when the time was right. That is fine in the open source. i.e. the fact that ideas evolve and flow and can wait for better times and purposes. We have the luxury of not having the strict economic constraints or market competition that commercial projects have, and I think that this is something to embrace.

But rather, the "open source" is about open access to any development and implementation information for a "final" product. With that in mind, professionally, I am very much interested in your approach to designing interactions. Your work (and that of your students) has been inspiring, but unfortunately has been a bit of a black hole, too. It would be great if you could open your team's "development and implementation information". At the moment, the input information for your process is open (gui brainstorm, GIMP itself, forums, this mailing list, etc.), and the solution they your team provides is open, too. But the main part, i.e. "development and implementation" is closed, as far as I can tell. What/how/why of the process that leads to solutions your team provides is not openly articulated. Excuse me for saying it, but it resembles the conventional closed design proces a little (which is fine, too). I understand that for some reasons unknown to me (student's work evaluatio n perhaps?) maybe you have to keep it closed?

Either way, that opaqueness of your team's design decision process puts your team undeservedly in a position where you have to announce/defend the solutions in front of the community everytime you "deliver" the solution. And no matter how smart and informed your solution is, there will always be some middle fingers raised. For various understandable reasons (some might not get it, some might hate it, some are cans, some have different ideas... etc.)...

From my experience, early and open access to design development and implementation helps immensely when it comes to articulating the solutions to community. We are all enthusiastic, curious and antsy about the new stuff, and we like to peek over the shoulders of developers and designers and give our 2cents any time. Even when not asked! That is an amazing asset for a designer, wouldn't you agree? And, who knows, informed by the insights into your process, maybe the specs would be written and even followed by someone else, openly and collaboratively. ;)

Do you think that you could perhaps open your design process a bit?

(I follow the GUI brainstorm, your blog and your contributions in GIMP. If I am missing a key part of the whole image here, please let me know... and if that's the case I apologize in advance)

Peter and everyone else, thank you, cheers, and keep up the great work

Alex

To all people complaining about how hard it is today to edit a gradient - The most usable way I have to edit gradients in GIMP is actually quite hidden: try drag and dropping colors from the color selector into the gradient editing window.

What would be a nightmare of segment splitting, selecting left-hand-color-type-of-segment , and so on, is suddenly past!

js ->

Date: Wed, 13 Mar 2013 09:18:10 -0300 From: gwidion@mpc.com.br
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] gimp gradients

To all people complaining about how hard it is today to edit a gradient - The most usable way I have to edit gradients in GIMP is actually quite hidden: try drag and dropping colors from the color selector into the gradient editing window.

What would be a nightmare of segment splitting, selecting left-hand-color-type-of-segment , and so on, is suddenly past!

js ->
_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

Dragging and dropping a color onto the gradient editor's preview area adds a node at that position with that color. It IS useful behavior when you are initially setting up a gradient, but not when you are tweaking the parameters later on.

On the other hand, dragging and dropping a color onto a gradient node handle paints both sides of that node that color. Which is definitely quite useful behavior - it does avoid the issue of GIMP not treating node colors as contiguous by default (it should, really!) .

-- Stratadrake strata_ranger@hotmail.com
--------------------
Numbers may not lie, but neither do they tell the whole truth.

=

sorry for the delayed reply, I had some deadlines to deal with.

Aleksandar Kovac wrote:

On 2013/03/12, at 0:45, peter sikking wrote:

well, as long as I get shown the middle finger where it comes to implementing the control frame of the tool, I think the situation is completely out of whack here where it comes to interaction design and usability.

remember, it is open source: only successful contribution counts.

please don't get me wrong on this one [...]

not at all, I appreciate posting on this thread, a lot.

I would like to remind you that open source is not about "only successful contribution counts". We have seen a case or two where initially unsuccessful contribution made all the difference in the long run, when the time was right. That is fine in the open source. i.e. the fact that ideas evolve and flow and can wait for better times and purposes. We have the luxury of not having the strict economic constraints or market competition that commercial projects have, and I think that this is something to embrace.

OK, let me explain better: I was trying to say that people who on this mailing list and irc obstinately imply that they also got the interaction design angle somehow covered, should maybe check their contributions, accomplishments and recognition by seasoned peers (all three in interaction design, of course, as should be the seasoned peers).

because this is how it works in code in open source and the devs are taking no prisoners in this regard.

meritocratic is how it is supposed to work.

But rather, the "open source" is about open access to any development and implementation information for a "final" product. With that in mind, professionally, I am very much interested in your approach to designing interactions. Your work (and that of your students) has been inspiring, but unfortunately has been a bit of a black hole, too. [...]

without any cynicism I say that I could use some evaluation and advice here from you Aleksandar, because all pointers say that you are indeed a peer, deep into open source and you are independent of me.

without trying to convince you, that design was developed in the open at its wiki page:

even earlier sketches were blogged:

there were quite few afternoons where I showed the design on irc and adapted it after critiqueespecially the handle designuntil it dealt with the criticism without throwing out the innovation with the bathwater.

also I linked to the design in progress on this list, of course looking for attention and feedback.

Either way, that opaqueness of your team's design decision process puts your team undeservedly in a position where you have to announce/defend the solutions in front of the community everytime you "deliver" the solution.

well, I would not like to see that this comes to that I have to be more catholic than the pope. developers, open the source for inspection and sharing. but they do not have to justify every micro decision of every line of code, certainly not to non-developers (heh, try...) the code has to work and get past the quality standards and technical architecture requirements of the maintainers.

the interaction design has to work and get past the quality standards and interaction architecture requirements of the lead designer.

it brings me to the actual point that is so galling for me at the moment. as a designer I have several long-term relationships with clients and partner companies. what I notice about them is the giant trust that comes with them:

clients and partners trust that when I lead the design the problems (and they are always big and complex) will be solved and the results will be great; just build it;

clients and partners can trust that I never let them down, I am always there for them when they need it.

I am now 6 years active at the GIMP project (long term, I call that) and the trust is not there. I really would like to see an explanation for this.

And no matter how smart and informed your solution is, there will always be some middle fingers raised. For various understandable reasons (some might not get it, some might hate it, some are cans, some have different ideas... etc.)...

the unworkable thing is that the middle finger comes from the people who are supposed to be partners in this: developers.

the implicit agreementI scratch your back and you scratch minehas been broken with that.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Peter, and everyone else, excuse me for taking so long to reply.

OK, let me explain better: I was trying to say that people who on this mailing list and irc obstinately imply that they also got the interaction design angle somehow covered, should maybe check their contributions, accomplishments and recognition by seasoned peers (all three in interaction design, of course, as should be the seasoned peers).

To be honest, I've seen this implication you mention both in coding and in design. A designer designs an interface and "implies that he/she also has the programming angle somehow covered". Just because there are open projects around with open code and similar functions, the designer presumes it won't take long to patch together a functioning code... Of course, this approach doesn't work at all. Either in programming or design. The only difference being that the comedy of failure is much easier to spot in the patchwork of code done by an overly enthusiastic designer then in the patchwork of GUI done by an overly enthusiastic programmer. :)

I think that with GIMP the delusive confidence in "having the interaction design angle somehow covered" is resting on a myth of a bitmap editor "as-it-ought-to-be" - the ineffable Photoshop. Often, while developing, there is a comfy crutch in the back of our heads, a mental model we gravitate to in a lack of a better vision, that "later, when we need to add the GUI, we should do what Photoshop did, or something similarilish…". I think that this is only normal. To notice the analogies between GIMP and Photoshop functions and transplant the existing user interface "solution" from Photoshop to GIMP. Honestly, this transplantation appears like a very efficient thing to do!

Unfortunately, since Photoshop and GIMP are not identical, these "transplantations" have paradoxical downsides. Internally, GIMP is definitely not chasing anyone's taillights thanks to brilliant work of many developers who created it as an advanced and unique piece of software. Externally, from the user interaction standpoint, GIMP appears as if it is chasing Photoshop's taillights. In other words, the unquestionable mastery in coding is paired with "not-really-mastery" in interaction/interface design.

As a result, the coded capabilities of GIMP often get buried in a patchwork of GUI approaches. Which is unfortunate considering the developer's work done on the inside. Admittedly, most of GIMP's functions can be accessed somehow, somewhere if you happen to know certain magic ritual of "unwritten wisdom". (e.g. see recent thread here on gradients, or follow many threads on GIMP user forums). That is not interaction design but "hide-and-seek".

With this paradox in mind, my understanding is that the best contribution to GIMP that interaction architects could/should/would do is designing the user interface and user interaction that complements the quality of GIMP code. To pull out GIMP's powerful functions into the light by shaping the interactions and controls for them. So that we can use them. Also, together with the developers and users, the designers can indicate the needs that would, once solved, round-up GIMP as a capable and enjoyable tool. (MyPaint and Blender3D got this part right, in my opinion)

This work is tough but well due. Inevitably, it will be perceived as "destructive" by many or "not sufficient" by many others. Like you said, it takes seasoned peers, i.e it takes mastery. The same level of mastery the code developers need to have when dealing with GIMP's insides. So far, you and your students did an admirable job in this field. Personally, I did not get your style always (as I have mentioned to you before here) but there is always a strong rationale behind your work. 100% rational decision making. Proper design work by all means.

Allow me get back to those taillights once more... Chasing taillights wouldn't be much of an issue if Photoshop's approach to workflow and GUI was a case in excellence. The issue is that Photoshop's approach has never been particularly smart. It did fit well into what was possible 20 years or so ago, and then it got stuck there. With every version, new layers of functions are being added but adobe is reluctant to introduce changes for various reasons (mostly profit). The same stance is shared by AutoCAD, 3ds max, Maya, Illustrator, MS Office (until recently), etc. I don't know if you would agree with me, but currently, from the user interaction standpoint, Photoshop suffers from a traditionalistic (atavistic?) approach. Some might argue that Photoshop's market share is an argument in favor of Photoshop's UX/UI, but I think we know better.

because this is how it works in code in open source and the devs are taking no prisoners in this regard.

meritocratic is how it is supposed to work.

I think I understand now what you were referring to. Thanks for the explanation.

without any cynicism I say that I could use some evaluation and advice here from you Aleksandar, because all pointers say that you are indeed a peer, deep into open source and you are independent of me.

without trying to convince you, that design was developed in the open at its wiki page:

even earlier sketches were blogged:

there were quite few afternoons where I showed the design on irc and adapted it after critique—especially the handle design—until it dealt with the criticism without throwing out the innovation with the bathwater.

also I linked to the design in progress on this list, of course looking for attention and feedback.

Thanks for the links. I am not sure if I am able to provide you with deep evaluation or advice. I can only try.

In my opinion, from the interaction design side the transformation tool proposal looks very well done. It would be an elegant solution for transformations (once deployed in parallel with its counterpart, i.e. the precise transformation tool that I yet have to see). The decision to split precise/by-feeling transformation controls seems sound and well grounded to me. For several reasons:

1. It allows us to bring from the real world to computer realm two very natural approaches of operating anything: by-feeling and precise (Peter, you called it differently before, I just forgot the terminology you used, sorry; e.g. freehand drawing vs. precise drawing using precision tools). This dichotomy for toolmaking is essential and it rarely (never?) mixes into one. e.g. Typesetting machines do not have pens and pencils, hammer and chisel don't have angle indicators, etc… That is not to say that using skillfully either of the two approaches cannot appear as if it is performed "intuitively". (think of sound engineers using studio mixing desks, for example, they are using precision tools very intuitively)

2. Giving dedicated sets of controls to by-feeling and precise transformation approaches will benefit both approaches. By-feeling approach retains the speed and hands-on experience, while precise approach (hopefully) will build on numerical/algebraic expressions. In other words, no stepping on each other's toes. (Provided that users will be able to switch between the free and precise transformation approaches smoothly...)

3. Seems to clean-up the GUI a bit. A cleaner interface that accomplishes the same (or better) functions is always good. "no matter how cool, no matter how beautiful your interface is, it would be better if there were less of it!" ;)

4. The transformation frame approach concept seems reusable. Meaning, I could imagine the same workflow implemented in other graphic software projects.

5. It is uncompromisingly designed to provide as good as currently possible control for transformations by-feeling, and to achieve that, it did not chase any taillights! I think that this is a new value for GIMP. This might be a good step towards getting out of the St. Photoshop's geriatric shadow. Of course, there is other good stuff peppered around GIMP, but "transformation tool" is symbolically fundamental.

One question… I understand that it might not be in the spirit of the transformation tool proposal, but I think that there is a need for something like an "augmented" intuitive approach. I am referring to various snaps (grids, angles, points) that would allow us to work by-feeling while being reasonably precise. For example, a layout grid of guidelines might be laid out; from then on a user could use only a combination of snapping and transformation tool you proposed to achieve precision and speed. Perhaps this ability is considered as understood in your proposal?

Some said that transformation modes (rotation/scale/shear/..) should be kept as separate tools. I don't think that would be the best approach. Imagine you want to accomplish a ride from A to B in a car. Naturally, first you will get in the car. This ride will demand from you to control acceleration, braking and steering either simultaneously or in rapid sequences. This is easy because, once you are sitting at the driver's seat, you will find a set of controls that are all within your reach, dedicated for efficient driving. Convenient. Now, back to transformation tool... Imagine you want to transform a selection. Equivalent of having the transformation "modes" as separate tools would be like having 3 driver seats in one car. One seat for controlling acceleration, one seat for braking and one for steering. Driving from A to B would have to be accomplished by doing a little acceleration on the acceleration seat, then switching to steering seat, then a little braking seat, then... Plus, each time you would have to get out of the car to switch the seat. Not convenient.

well, I would not like to see that this comes to that I have to be more catholic than the pope. developers, open the source for inspection and sharing. but they do not have to justify every micro decision of every line of code, certainly not to non-developers (heh, try...) the code has to work and get past the quality standards and technical architecture requirements of the maintainers.

I agree, there is no need to explain every tiny decision made that ultimately led to your solution proposal. Also, it is true, as you said, that the code has to work and get past the quality standards and technical architecture requirements of the maintainers.

Maybe this is a good place to try to say what I had in mind when I mentioned "opening" your design process. I truly hope this topic will not be too cryptic or patronizing.

Getting past the quality standards and technical architecture requirements of the maintainers is not the exclusive pathway leading to solution implementation. Open source does not impose legal confinements for ideas and solutions so ideas can be forked and cloned by others, too. Which in turn brings more ideas and more feedback, more interest and more drive to make it. This ensures that a good idea will "live"… So, it will happen that someone, somewhere (maybe not even connected to GIMP community) will be able to develop and implement solutions that were based on your work.

So, I am thinking… Are solutions "delivered" to the community in an "open" format? Could your design proposals be presented in a way that would improve the chances for the ideas behind them to be implemented, forked or cloned?

That said, I think that the specs are very terse and condensed, maybe even intimidating? I read your specs like a recipe. They are excellently executed, no question about it, but readers have no option but to accept them. I am aware that this is exactly what specs are supposed to be. The specs are lacking the verifiability and fallibility (to introduce a little bit of ol' Karl Popper). Probably only because I have been dealing with specs I am able to "decode" them and visualize the final design in my head or on a piece of paper. Even so, there are some points where I have to invest some faith, and trust your expertise that it will be OK in the end. To use developer language: you are giving us a packaged/compiled solution (which is great!) but not so much the raw source.

Also, GIMP is code-developer initiated and maintained project. It will remain code biased, I think. Or, as you said, leaning towards "tech" in "user-tech-project" balance. Perhaps your design specs introduce a bit of culture shock, too. This transformation tool proposal is quite different from the existing models. It might not be a trivial thing to understand for any design non-expert. I hope I am not insulting anyone's intelligence by saying so. Especially if one has to "decompile" it's true value solely from the specs. One way, I imagine, would be to provide more articulation and rationale (as señor Prokoudine mentioned) of the final proposal. A clear narrative that will articulate these interactions in a simple, but real context. It would be very helpful to see a visualization of the basic interactions using the proposed transformation tool frame. Ideally, a video mock-up or a sketch, but even a static storyboard with basic interactions depicted could do, I think. Without this narrative, we have to read the specs carefully and reconstruct the interaction in our heads based only on the static descriptions of the elements that constitute your solution. Consequently, the acceptance of your solution proposal will depend on reader's (developer's?) imagination and willingness for leaps of faith. This kind of imaginative process demands a lot of experience in interaction design. Same as imagining some program structure demands a lot of experience and skill in programming. It is a little bit like facing orchestral notation. It takes a lot of note-reading experience to "hear" it just by reading. Live or recorded performance, on the other hand, will captivate ears of even those not experienced among us. I imagine that there is no "fun, contribution and accomplishment" in coding according to the dry specs without getting hooked to the ideas that are behind those specs first ;).

I believe that a visual narrative for your transformation tool proposal would give plenty of reasons to get hooked and ultimately inspired to clone/fork it or contribute the coding component to this solution. Because it is a good solution!

We all come here from different backgrounds and I cannot expect a person who diligently dedicated time to master programming to the level to be a GIMP developer will intuitively understand the thinking that went behind your design spec. By all means, I hope no developer ever makes that mistake and expects from me to understand the thinking that went behind some (even the simplest) piece of code! In that regard we are different cultures altogether. On the other hand, we both take on challenges, grasp concepts, focus on purposes and pursue functional "beauty" of our work. We (declaratively) tend to make rational decisions, too. This constitutes a good "common ground" for us to exchange ideas and communicate successfully.

the interaction design has to work and get past the quality standards and interaction architecture requirements of the lead designer.

it brings me to the actual point that is so galling for me at the moment. as a designer I have several long-term relationships with clients and partner companies. what I notice about them is the giant trust that comes with them:

clients and partners trust that when I lead the design the problems (and they are always big and complex) will be solved and the results will be great; just build it;

clients and partners can trust that I never let them down, I am always there for them when they need it.

I am now 6 years active at the GIMP project (long term, I call that) and the trust is not there. I really would like to see an explanation for this.

In the open source, conventional organizational structures necessary to support the designer role do not exist and without them the conventional design methodologies fail, too.

In the conventional profit-driven organizations, members communicate directly, they plan and schedule efforts, assign responsibilities, resources and expertise, and so on. Conventional organizations plan and manage design early. For them, production (and very often - profit) depends on a well structured environment where defined methods, roles, needs, goals, schedules, and so on play very important roles.

In contrast, an online communal social environment of the open source software development is fundamentally different from work organization the designers are commonly prepared for. Organizationally, the open source has been described as action-driven, network distributed, asynchronous, concurrent and unmanaged system of mostly individual actions. In other words, A mess. :) But, it is a beautifully creative mess. To make design work, we have to stop relying on the old organizational crutches. I consider this to be a liberating condition, albeit a stressful one. So, let's find better design methodologies that free from the dependency on conventional organizational structures. I am *always* open to discuss/try those!

the unworkable thing is that the middle finger comes from the people who are supposed to be partners in this: developers.

the implicit agreement—I scratch your back and you scratch mine—has been broken with that.

This will bring no consolation. Unfortunately, I am not sure if such an agreement could be carried-out in the open source since it implies the code of duty (of respective back-scratching) and we are rarely driven by duty here. But, as you have mentioned yourself before, challenge, fun and accomplishment are a different story!

It is obvious to me that your work in interaction design is preceded by deep understanding of human perception and cognition, creative and work processes, workplace design, etc. Also, you put a lot of care to keep the tools you design simple yet open-ended, i.e. you are not creating dumb, narrowly specialized tools. I know that such open-ended yet simple tools are the most rewarding for users, but at the same time immensely demanding to design and I admire that you don't wiggle out! I can only learn from you!

That's why I believe that the middle fingers came from those who merely didn't get it yet. Certainly not on the level we would like them to get it. But this is something that, I believe, can be improved with some articulation.

Please excuse me for taking so long to reply. I tried to make up for it by an overly lengthy post, it seems. :) Or, did I just make it worse? Probably.

Cheers, award yourself with some meze. If you read all of this you are probably very hungry by now.
:)

admiring the magic,
Alex

On Apr 3, 2013, at 22:49, Aleksandar Kovač wrote:

Peter, and everyone else, excuse me for taking so long to reply.

excuse me too, I was travelling the last week and a half (and no, it wasn’t the lgm) which always takes me ‘out of office’, including email.

Aleksandar, thank you for actually keeping the discussion alive, because as we all might have noticed:

anyone who has ever done development on GIMP user interface seems to be sitting out this thread, probably waiting for this to blow over.

well, that will be a whole lot of sitting, because I am sitting too, in strike.

if GIMP as a project likes to have interaction design and usability work done for it, then we need to recover the implicit understanding of a couple of years ago, when Sven reached out and recruited me to heal the patient (== GIMP) and endowed his maintainer authority to get it executed in code; when I had working ‘I help you, you help me’ relationships with developers.

the outreach, endowment, the relationships, they need to be recovered and this time explicitly, in writing, here on this list, not in gone-tomorrow talk on irc.

I will go into Aleksandar’s long analysis and argument another day (busy now), but if we want to recover, then GIMP user interface developers, past and precent, better get involved in this thread.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Hi Peter.

Let me state as the first thing that I at first did not really try and later had troubles following the dispute since I did not follow the development of the UTT, had not read the spec and just knew your mails from the mailinglist, basically pushing away the undertones because I failed to understand what you were angry about.

(For me I think that I now have some grasp on what was going on there and will try to describe it in detail later, because it is not at all clear from the mailinglist alone...)

peter sikking (peter@mmiworks.net) wrote:

the outreach, endowment, the relationships, they need to be recovered and this time explicitly, in writing, here on this list, not in gone-tomorrow talk on irc.

At the libre graphics meeting we had the usual gimp meeting and also discussed the problems that currently seems to make it impossible for you to continue working on GIMP.

In the meeting there was the general consensus that the collaboration with you was very successful and we'd like it to continue. I really hope that the differences between you and - I think - mostly Mitch can be resolved and everybody can return to the fun parts of GIMP development.

Anyway, before this can happen we need to rehash what happened, try to understand the issues and try to come up with a plan to resolve this.

Now - I understand that this problem is not just about UTT but the general expectations on how we collaborate on the interaction design. However, since the UTT seems to be the elephant in the room I'll focus on that one for now, we should try to resolve this first.

Here is my short summary of what I believe has happened regarding the UTT.

On Feb. 22 there was some discussion about the goals and designs for the UTT and the other transform tools. Later in the (european) evening you and mitch started discussing the current state in IRC. Mitch was enthusiastic on how good the interaction on the UTT works and starts talking about problems in the spec he and mikatchu faced when implementing it. There are some parts of the discussion I still don't really understand (the precision vs. feel stuff).

Then you apparently saw one or two screenshots and suddenly the tone of the discussion went downhill - you apparently were quite pissed and I am not sure if you actually read what mitch and mikatchu tried to explain before you left the channel. Later you rejoined, giving some statements on how you think the collaboration has to work and left.

Subsequently there were mails on the mailinglist where among other things you expressed your frustrations, I am not going to rehash these in detail.

I at that time peripherally followed the IRC discussion (I recall not understanding what went wrong there) and the mails left me more and more confused.

At LGM I compared the current state of the UTT with your spec and it suddenly became apparent to me how it is possible that you take that as a slap into your face and a stab in your back: The visual appearance of the tool has nothing to do with what you specified, the handles have been substituted with basically lots of line noise.

I imagine this must feel like the tailor delivering a quality business suit tailored for the client and then witnessing the client taking the scissors, randomly cutting holes for better ventilation.

Yes, I'd probably get pissed too.

In the defense of Mikatchu and Mitch however I don't believe this is what happened.

They had troubles with the spec, found holes in it and focussed on the parts they understood and left the rest for clarification together with you. They implemented stubs for the visual part, implementing just enough stuff with the stock-handle-code in GIMP to test-drive the mouse handling, getting the link to the transform core correct etc. pp.

By no means the current visual appearance is supposed to be a "better" replacement for your design, nobody claims that this is an improvement over your design and noone intended to show you any middle fingers.

It is just that the uncertainties in the spec (e.g. how do the handles behave while shearing/perspective changes) don't encourage the implementation, since without an overall understanding - including the corner cases - it is likely to have to be rewritten multiple times.

Then there is finally the chance of catching up with you, mitch wants to clarify stuff, is in a hurry, you are apparently feverish, and a simple screenshot makes things go sour, communication breakdown in about 20 minutes. Grgh.

(I'll send the relevant parts of the irc log to you off list, please read it and try to look at it from an outsiders point of view...)

We're now in the weird situation that you're pissed towards - at least - M&M, because they supposedly fail to respect your work and Mitch is likewise pissed because you supposedly are unwilling to respect the work from Mikatchu and him that has gone into the invisible part of the tool.

Frankly, I believe this aspect is something only a real-world-meeting between mitch and you can resolve, I'll gladly donate the beer.

I sincerely hope that we can get this specific issue worked out and then broaden the discussion to the "overall" collaboration. I won't do this now, because this mail already is too long, and loading more potentially loaded issues won't help.

I really want to stress, that - contrary to your perception - there is a lot of trust in you and your work, I think the defense of the save vs. export design has proven that. In fact it is not only trust but also interest, which on the other hand means that sometimes your designs get challenged. Please don't take that as questioning your competence.

Thanks, Simon

simon@budig.de              http://simon.budig.de/

hi Simon,

I appreciate very much you writing a long post on this thread. it has halted, for the moment, my slide out of the GIMP project that was being propelled by no (GUI) developer responding whatsoever.

since I received your post I have been thinking a lot about about what to reply, how to say and structure it.

here is a try:

peter sikking (peter@mmiworks.net) wrote:

the outreach, endowment, the relationships, they need to be recovered and this time explicitly, in writing, here on this list, not in gone-tomorrow talk on irc.

At the libre graphics meeting we had the usual gimp meeting and also discussed the problems that currently seems to make it impossible for you to continue working on GIMP.

In the meeting there was the general consensus that the collaboration with you was very successful and we'd like it to continue.

this sounds encouraging, however, the public meeting minutes do not contain a word on this topic. that is again discouraging.

I really hope
that the differences between you and - I think - mostly Mitch can be resolved and everybody can return to the fun parts of GIMP development.

of course what is happening now is simply a continuation of our meeting at last years lgm in Vienna. a lot of outspoken things were said there, but at the end both Mitch and I avoided to confront each other. that is how both our characters are: outspoken but avoiding real confrontation.

it did leave real issues unresolved.

Anyway, before this can happen we need to rehash what happened, try to understand the issues and try to come up with a plan to resolve this.

Now - I understand that this problem is not just about UTT but the general expectations on how we collaborate on the interaction design. However, since the UTT seems to be the elephant in the room I'll focus on that one for now, we should try to resolve this first.

basically the issues came back to haunt us for the UTT.

it has become clear to me in recent times that the whole thing can be summarised as: over the last couple of years GIMP has been sliding back from a project where making good UI meant something, to an engineering project where any inconvenience for developers that follows from interaction design and usability work is either loudly protested against or circumvented by simply doing something else in code.

and now GIMP as a project, and especially Mitch as maintainer, must make a choice whether making good UI means anything anymore, at GIMP.

every time I think of going into one or more points of the UTT story, I have to conclude half an hour later that it is better not to. I think we better first figure out these general expectations on how we collaborate. the UTT can follow from there.

[long snip]

We're now in the weird situation that you're pissed towards - at least - M&M, because they supposedly fail to respect your work and Mitch is likewise pissed because you supposedly are unwilling to respect the work from Mikatchu and him that has gone into the invisible part of the tool.

Frankly, I believe this aspect is something only a real-world-meeting between mitch and you can resolve, I'll gladly donate the beer.

we need to find a way.

irc has shown for years not to work for discussing user interaction. it may work for engineering but UI is too complex for a low bandwidth medium like irc.

after trying for a week to write this email, I conclude that the mailing list is also not the forum to do this.

I do think we need some kind of meeting.

I sincerely hope that we can get this specific issue worked out and then broaden the discussion to the "overall" collaboration. I won't do this now, because this mail already is too long, and loading more potentially loaded issues won't help.

I really want to stress, that - contrary to your perception - there is a lot of trust in you and your work, I think the defense of the save vs. export design has proven that.

yes, I thanked the developers for that in Vienna, many a software company would not have the nerve to not buckle under such vocal protest. but, as Kate pointed out to me at that time, save + export is completely uncontroversial and logical from a technology point of view, so it is not leap-of-faith support that really counts: when developers cannot see the point, but trust the designer and implement anyway.

In fact it is not only trust but also interest, which on the other hand means that sometimes your designs get challenged. Please don't take that as questioning your competence.

encouraging words, but the last years show that developers trust themselves more on the topic of user interaction when it is time to take action. this is not only on module level, more and more when it is about the big sweeping interaction topics and implications of wild ideas, I am asked not to contribute big picture analysis. it seems to take the fun out of aiming at your foot with a gun.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Hi Peter,

I think it's best to not reply the the thread, because I have troubles following it myself already, and I better describe how I have experienced the UTT situation, and the unfortunate conversation with you on IRC several weeks back.

During last year's GSoC, Mikachu has repeatedly approached me with problems about how to implement the specified GUI, and it was clear to both of us that there is some under-specification going on and that we simply didn't have had enough spec iterations to make it fully implementable.

There was no hurry at the time, and I had really little time to attend to it, so I told him to postpone that part and instead get the internal appraratus really sound, and deal with the UI when we (Mikachu, Peter, Mitch) have had the chance to discuss the issues and get the spec updated for corner cases where is simply was not implementable as-is.

The unimplementable part was that the spec didn't say what's happening for angles where your drawing wouldn't work, and it was clear that the drawing code would explode in our faces, so I decided to tell Mikachu not to do any evil hacks that couldn't be right, and leave the GUI simple until you came back.

Also, there is the issue with the dialog with an infinite amount of buttons. That's simply because it was somewhat unclear how to integrate that into general image undo, and kill the dialog for good, which will clearly happen before 2.10, but we didn't see it as immediate problem because the undo/redo stuff was there, and the dialog can just be moved away as long as it exists in 2.9, and it won't be an issue in 2.10 anyway. In fact, one can simply pretend the dialog was not there and not worry about it.

When you came to IRC in Feb/March I think it was, I was really excited to finally discuss this and some other open issues with you, and we had a really nice talk for like an hour or so, until I brought up the UTT. I don't know what exactly triggered the miscommunication, but what I meant to say was this:

- The interaction is *completely* implemented as specified - So are the handles (not visually)
- So are the constraints
- So is undo/redo
- We even took care of handle-specific mouse cursors that rotate along with the transform frame

What is NOT implemented:

- The handles are completely not as specified, because we had no clue how to implement them for extreme angles, and we were hoping for your input
- The dialog is still there, which is temporary

And I also had a change request for the spec:

- The tool is so insanely useful, also for corrective transform and really precise working, that it would be a shame to remove the grid options. In fact, it's IMO the only usable tool now, so minus number entry for rotate/scale, there is actually not any need to have other tools.

Which I meant as a compliment, because the spec, the interaction, and the constraints are totally the shit. I even used the words "I love it", that's hardly disrespect in my opinion.

Now for general issues:

I have thought hard about last years meeting in Vienna, and all I remember was trying to mitigate a confrontation between you and pippin, and not engaging in confrontation. You can't expect me to completely side with you when in my opinion none of you guys was completely right or wrong.

Also, about GIMP sliding back from a project where good UI matters to an engineering project where we don't give a shit about interaction design... You know, that really hurts. How did that perception happen?

It actually happens *all* the time that we hit a problem with the GUI, and when you are not around I miss you every time, because what are we supposed to do? Not make a change that is technically needed (remember we are in the process of completely changing the inner core of GIMP to GEGL)? Of course not. Instead, we do it as good as we can, and hope for your input when you are around next time.

You might also have noticed that we're trying hard to fix issues in the specs that were implemented in the past, in particular Save/Export and single-window-mode. We take bugs serious and try to get it right, sometimes to our best knowledge in case the spec missed some corner case. And we defend the specs we have all agreed about to an insane amount of bitching, doesn't that prove our respect for your work?

Also, what am I supposed to do when somebody comes with a new feature, but we have no spec for its GUI yet? I can't tell everybody to wait until there is a spec (and we do that often enough). Instead, we do our best to make it as good as possible anyway. We can't have each and every GUI change block on the actions of one single entity.

tl;dr

So please, can't we just put all that weird disagreement and misunderstanding behind us and work together again? I try the same, because I can tell you, I am not exactly amused about the current situation either, in particular not about the outcome of our last discussion on IRC. That has let me standing in the rain, despite my best efforts to explain the UTT situation. The abrupt end of that conversation was not what I had hoped for, and I'm most certain the same is true for you.

You know how much I hate writing mail, and I'm on the 3rd page already in my editor, that should be evidence enough that I mean it ;)

Regards, --Mitch

Von: "peter sikking"

hi Simon,

At the libre graphics meeting we had the usual gimp meeting and also discussed the problems that currently seems to make it impossible for you to continue working on GIMP.

In the meeting there was the general consensus that the collaboration with you was very successful and we'd like it to continue.

this sounds encouraging, however, the public meeting minutes do not contain a word on this topic. that is again discouraging.

I'm going to take the blame for this - when writing the minutes, I decided to split this part of the discussion into a separate document, because the list of subtopics I write down bears too much room for misunderstanding, in my opinion.

I wonder if it is best to go over them in a meeting with more bandwidth than IRC or email, maybe a (Google) hangout?

Regards, Michael

Am 03.05.2013 09:57, schrieb Michael Schumacher:

I wonder if it is best to go over them in a meeting with more bandwidth than IRC or email, maybe a (Google) hangout?

+1 for spending GIMP money on scheduled bi-monthly real-world meetings

yahvuu