Re: [Gimp-developer] gimp gradients
sorry for the delayed reply, I had some deadlines to deal with. Aleksandar Kovac wrote: On 2013/03/12, at 0:45, peter sikking pe...@mmiworks.net 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: http://gui.gimp.org/index.php/Transformation_tool_specification even earlier sketches were blogged: http://blog.mmiworks.net/2009/03/working-on-gimp-transformation-tool.html 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. 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 agreement—I scratch your back and you scratch mine—has been broken with that. --ps founder + principal interaction architect man + machine interface works http://blog.mmiworks.net: on interaction architecture ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
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
Re: [Gimp-developer] gimp gradients
Date: Wed, 13 Mar 2013 09:18:10 -0300 From: gwid...@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_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Von: peter sikking pe...@mmiworks.net An: gimp-developer list gimp-developer-list@gnome.org 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
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 :) ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
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. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
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 vary—straightforward implementation; ‘I know better’; or the need for tinkering—the 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 ‘that’s 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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
Date: Sun, 10 Mar 2013 13:14:14 -0300 From: gespert...@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_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp gradients
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. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
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_ran...@hotmail.com Numbers may not lie, but neither do they tell the whole truth. ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
Re: [Gimp-developer] gimp gradients
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 ___ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
