Re: [Gimp-developer] GIMP Roadmap - wiki page
> >> ... elision by patrick... > > How about having (hideable of course :)) on-canvas infos? IMHO that > > would be even fancier. Infos could be aligned with control that > > modifies them. Numerical input could be done similarly on-canvas. I > > think hovering pointer above e.g. rotation control and clicking > > middle button (?) could activate input (displayed on the place). > > That way we'd save considerable ammount of mouse movement between > > canvas and dock. To make things even more unobtrusive input could > > “slide” after activation to some place on the screen (bottom of the > > screen) util value would be entered and whole control could be > > hidden. Well… there's the thing about this being fast, but I think > > that's what new, fancy compositioning infrastructures are for ;>. > > It seems to me like a reasonable application of new capabilities. > I would prefer the dock-able thing. Working with my tablet, touching > on the side instead of on the drawing is a negligible movement. I > also prefer things not be mapped to middle mouse buttons because most > mice don't have them (and tablets neither) and though a simultaneous > click of right and left are often mapped to a middle mouse click, it > isn't always reliable. You certainly wouldn't want (IMHO) to make > this something that someone would have to do to use the tool. Yup… That's why I said “hideable” and used “(?)” after middle button (used also quite often for panning) :). As for the first: I prefer the idea of on-canvas because it means the least ammount of movement (hence fastest work)–be it stylus or mouse. Of course I'm not trying to force you into my way of working :), but I'd like to avoid “hunting” with pointer for appropriate control as much as possible. If the control is right under pointer… you don't need to seek it on the screen *at all*. As for the second: middle button is here just as an “e.g.” :). Equally good it could be some set of modifier keys or sumthin' ;). Anyway, I think it would be best to choose something sane for default but leave final decision about it to the user choice in the end. Best regards! thebodzio PS. I believe that most mice have the middle button nowadays, but that's just a little digression… signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/01/2011 03:54 PM, Bogdan Szczurek wrote: >> ... elision by patrick... > How about having (hideable of course :)) on-canvas infos? IMHO that > would be even fancier. Infos could be aligned with control that > modifies them. Numerical input could be done similarly on-canvas. I > think hovering pointer above e.g. rotation control and clicking middle > button (?) could activate input (displayed on the place). That way we'd > save considerable ammount of mouse movement between canvas and dock. To > make things even more unobtrusive input could “slide” after activation > to some place on the screen (bottom of the screen) util value would be > entered and whole control could be hidden. Well… there's the thing > about this being fast, but I think that's what new, fancy compositioning > infrastructures are for ;>. It seems to me like a reasonable > application of new capabilities. I would prefer the dock-able thing. Working with my tablet, touching on the side instead of on the drawing is a negligible movement. I also prefer things not be mapped to middle mouse buttons because most mice don't have them (and tablets neither) and though a simultaneous click of right and left are often mapped to a middle mouse click, it isn't always reliable. You certainly wouldn't want (IMHO) to make this something that someone would have to do to use the tool. Patrick ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/03/2011 02:17 AM, Chris Mohler wrote: > > I *think* that would cover all of the transformations of the proposed > tool. And I assume all or most of those values are going to be in > play (and in the undo stack) during use of the transform tool. But > yeah, just having the one-off dialogs for transforms would work as > well. I have no real preference either way, but the dockable (or > placing those items in tool options) seems cleaner to me for some > reason. Since each transform slightly blurs the image, using the individual transforms one by one would not give results as good as applying one single transform that combines everything, would it? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Wed, Mar 2, 2011 at 1:14 AM, Michael Grosberg wrote: >> > I'm a little uneasy at the moment about the "ban working with numbers for >> > transformations" comment. >> >> It would be nice (IMO) to have a dockable that displays the "numbers" >> of the transform tool's current selection and transform, and also >> applies numerical input to the transform tool. > > I have a somewhat different solution for this. > > When you start messing around with perspective transform and you drag corner > points every which way, scale and rotate numbers become meaningless. So, > Precise numbers are not that useful for a free transform tool anyway. > GIMP could simply keep the existing separate transform tools, but instead of > displaying them as icons in the toolbox, keep them in their own sub-menu under > edit-->transform or something. That would cover the uses I was worried about. The dockable I was imagining had the following items: Origin X,Y in pixels Width in pixels Height in pixels Rotation in degrees X shear in pixels or degrees Y shear in pixels or degrees And then some items that would become active only after performing a perspective transform or clicking on them directly: Top-Left X,Y in pixels Top-Right X,Y in pixels Bottom-Left X,Y in pixels Bottom-Right X,Y in pixels I *think* that would cover all of the transformations of the proposed tool. And I assume all or most of those values are going to be in play (and in the undo stack) during use of the transform tool. But yeah, just having the one-off dialogs for transforms would work as well. I have no real preference either way, but the dockable (or placing those items in tool options) seems cleaner to me for some reason. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Wed, 2011-03-02 at 07:14 +, Michael Grosberg wrote: > Chris Mohler gmail.com> writes: > When you start messing around with perspective transform and you drag corner > points every which way, scale and rotate numbers become meaningless. So, > Precise numbers are not that useful for a free transform tool anyway. For painting and general creative work you're probably right, but gimp is also used for other things. For example, I often rotate a scanned image, carefully writing down the exact number, and then if it was too little or too much, repeat with a slightly different number. It might work if the transform tools have an option (sorry) to remember the last value, or a list like curves and levels do today. > You've got a similar solution in Inkscape, Where the select tool also does > Transformations by default with no numerical input, but there is also a dock > for transforming objects numerically (there are tabs for separate actions, > so each transform command is separate). Or displaying the numbers in tool options in gimp might work. (I worked on a patch to change the numbers shown in Perspective to spin boxes just as in the other transform tools, but (1) lost it in a battle with git recently, and (2) never submitted it as it obviously didn't fit in with The Grand Vision. I wish I could drag guides around while the perspective grid was active!) Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
The term "layer effects" should be used carefully. PhotoShop uses it for a set of modifications that can be applied nondestructively to a layer, including blurring, color adjustments, and a limited number of other specific things. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Martin Nordholts wrote: > I've changed "Adjustment layers" to 'Layer filters' for now, and added > "Layer effects". Ideas for better names are welcomed. Most of the "effect" plug-ins are under a Filters menu so using "Layer filters" makes a certain amount of sense. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 3/2/11, Michael Grosberg wrote: > Adjustment layers = per-pixel value change (hue, levels, etc - stuff from > the "colors" menu) Such layers have a mask and adjustment properties but > no actual color content. > > Filter layers = real-time application of filters (sharpen, blur, distort) > that changes whenever the layers *beneath* it are changed. These are not > per-pixel but rely on the entire image. Such layers have a mask and filter > properties but no actual color content. These are updated whenever the > content odf any of the layers below it is changed. Don't you find this separation between adj layers and filter layers a bit over the top? :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Martin Nordholts gmail.com> writes: > > On 03/02/2011 04:33 AM, GSR - FR wrote: > > Hi, > > enselic gmail.com (2011-03-01 at 2214.48 +0100): > >> Thanks, I've added your items as well as mapped features into GIMP > >> releases up to GIMP 3.8. (I implicitly include both 'color adjustment > >> layers' and 'filter layers' under "Adjustment layers".): > >> http://gimp-wiki.who.ee/index.php/GIMP_Roadmap > > > > Please pick a different name that trully combines both things then, > > assuming they are combinable. Adjustment layers is already a standard > > term (de facto from another app, yeah, impossible to change that now) > > for a layer that only has a mask and applies per pixels changes like > > hue or level changes. Not only confusing, but hard to see the relation > > between "adjusment" and "render grid", for example, which is probably > > what you mean with filter. Thanks. > > I've changed "Adjustment layers" to 'Layer filters' for now, and added > "Layer effects". Ideas for better names are welcomed. That is also an already-used term. Adjustment layers = per-pixel value change (hue, levels, etc - stuff from the "colors" menu) Such layers have a mask and adjustment properties but no actual color content. Filter layers = real-time application of filters (sharpen, blur, distort) that changes whenever the layers *beneath* it are changed. These are not per-pixel but rely on the entire image. Such layers have a mask and filter properties but no actual color content. These are updated whenever the content odf any of the layers below it is changed. Layer effects - effects that operate on raster layers and affect the content of that layer only, usually around the perimeter of the actual pixel content. Examples - drop shadow, glow, bevel, stroke. These should be updated in real time as the user is drawing on that layer. While all of these are desired, I would say adjustment layers are the easiest to implement and the most important. Layer effects are important for web designers mostly, but less so for casual users, and they seem to be difficult to implement properly (just a guess from seeing adobe's successful implementation and other's less succesful attempts). Filter layers have a low importance. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Tue, Mar 01, 2011 at 04:24:18PM -0600, Chris Mohler wrote: > On Tue, Mar 1, 2011 at 3:46 PM, Kevin Cozens wrote: > It would be nice (IMO) to have a dockable that displays the "numbers" > of the transform tool's current selection and transform, and also > applies numerical input to the transform tool. > i asked them to do this for the move tool in gimp-1.2. i don't think that this is such a difficult task as to pay a person to work on it for the summer. GIMP got those stupid expanding tabs with their names for free because (i guess) icons aren't so good for using gui applications after all or was a reason provided for this? carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Chris Mohler gmail.com> writes: > > On Tue, Mar 1, 2011 at 3:46 PM, Kevin Cozens ve3syb.ca> wrote: > > I'm a little uneasy at the moment about the "ban working with numbers for > > transformations" comment. > > It would be nice (IMO) to have a dockable that displays the "numbers" > of the transform tool's current selection and transform, and also > applies numerical input to the transform tool. I have a somewhat different solution for this. When you start messing around with perspective transform and you drag corner points every which way, scale and rotate numbers become meaningless. So, Precise numbers are not that useful for a free transform tool anyway. GIMP could simply keep the existing separate transform tools, but instead of displaying them as icons in the toolbox, keep them in their own sub-menu under edit-->transform or something. The only difference would be to make them behave like one-off dialogs, so once you're done with transforming whatever it is, the UI reverts to the last selected toolbox tool. That way you could still have access to precise transformations for those who need them while not encumbering the more casual users with the numerical info. You've got a similar solution in Inkscape, Where the select tool also does Transformations by default with no numerical input, but there is also a dock for transforming objects numerically (there are tabs for separate actions, so each transform command is separate). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/02/2011 04:33 AM, GSR - FR wrote: > Hi, > ense...@gmail.com (2011-03-01 at 2214.48 +0100): >> Thanks, I've added your items as well as mapped features into GIMP >> releases up to GIMP 3.8. (I implicitly include both 'color adjustment >> layers' and 'filter layers' under "Adjustment layers".): >> http://gimp-wiki.who.ee/index.php/GIMP_Roadmap > > Please pick a different name that trully combines both things then, > assuming they are combinable. Adjustment layers is already a standard > term (de facto from another app, yeah, impossible to change that now) > for a layer that only has a mask and applies per pixels changes like > hue or level changes. Not only confusing, but hard to see the relation > between "adjusment" and "render grid", for example, which is probably > what you mean with filter. Thanks. I've changed "Adjustment layers" to 'Layer filters' for now, and added "Layer effects". Ideas for better names are welcomed. / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Hi, ense...@gmail.com (2011-03-01 at 2214.48 +0100): > Thanks, I've added your items as well as mapped features into GIMP > releases up to GIMP 3.8. (I implicitly include both 'color adjustment > layers' and 'filter layers' under "Adjustment layers".): > http://gimp-wiki.who.ee/index.php/GIMP_Roadmap Please pick a different name that trully combines both things then, assuming they are combinable. Adjustment layers is already a standard term (de facto from another app, yeah, impossible to change that now) for a layer that only has a mask and applies per pixels changes like hue or level changes. Not only confusing, but hard to see the relation between "adjusment" and "render grid", for example, which is probably what you mean with filter. Thanks. GSR ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
> > I'm a little uneasy at the moment about the "ban working with > > numbers for transformations" comment. > > It would be nice (IMO) to have a dockable that displays the "numbers" > of the transform tool's current selection and transform, and also > applies numerical input to the transform tool. > > Photographers could ignore/hide the dockable entirely and still use > the transform tool by "feeling", and designers would have a method for > performing precise transforms (for example a radial design needing > several exact rotations). How about having (hideable of course :)) on-canvas infos? IMHO that would be even fancier. Infos could be aligned with control that modifies them. Numerical input could be done similarly on-canvas. I think hovering pointer above e.g. rotation control and clicking middle button (?) could activate input (displayed on the place). That way we'd save considerable ammount of mouse movement between canvas and dock. To make things even more unobtrusive input could “slide” after activation to some place on the screen (bottom of the screen) util value would be entered and whole control could be hidden. Well… there's the thing about this being fast, but I think that's what new, fancy compositioning infrastructures are for ;>. It seems to me like a reasonable application of new capabilities. Best regards! thebodzio signature.asc Description: PGP signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Tue, Mar 1, 2011 at 3:46 PM, Kevin Cozens wrote: > I'm a little uneasy at the moment about the "ban working with numbers for > transformations" comment. It would be nice (IMO) to have a dockable that displays the "numbers" of the transform tool's current selection and transform, and also applies numerical input to the transform tool. Photographers could ignore/hide the dockable entirely and still use the transform tool by "feeling", and designers would have a method for performing precise transforms (for example a radial design needing several exact rotations). The spec for the tool looks pretty amazing though ;) Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
>>> * unified transform tool (I remember seeing plans for that last item on >>> Peter sikking's Blog) >> http://gui.gimp.org/index.php/Transformation_tool_specification >> >> You will probably be nicely surprised :) Definitely surprised. It looks interesting. A different icon than the small circle for the rotation thing could help clarify its purpose (eg. a circle made out of two curved, opposite pointing, arrows?). I will have to read over the rest of the page more thouroughly. I'm a little uneasy at the moment about the "ban working with numbers for transformations" comment. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 03/01/2011 03:23 PM, Michael Grosberg wrote: > Congrats! this is a much-needed step. > > Can I ask what "non-destructive editing" is? According to Adobe, this > includes: > * Color adjustment layers (such as levels, hue/saturation, threshold, etc) > * filter layers (such as blur, sharpen, emboss, etc) > * smart objects (i.e., ability to scale / rotate a layer as a single object, >without changing its pixel data) > > Maybe this could be expanded upon and prioritized. > > I also have a couple of suggestions for things to put on the roadmap: > > * change the floating selection behavior so that float and un-float can >be automatic and not need user's explicit input. > * Automate layer boundary management so that the user can draw on any point >at any time and not worry about increasing the boundary > * unified transform tool (I remember seeing plans for that last item on >Peter sikking's Blog) > > So, what do people here think? I believe all three are essential in making > GIMP a faster and more hassle free tool. I can expand on these subjects if > needed. Thanks, I've added your items as well as mapped features into GIMP releases up to GIMP 3.8. (I implicitly include both 'color adjustment layers' and 'filter layers' under "Adjustment layers".): http://gimp-wiki.who.ee/index.php/GIMP_Roadmap / Martin -- My GIMP Blog: http://www.chromecode.com/ "Why GIMP 2.8 is not released yet" ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On Tue, Mar 1, 2011 at 16:16, Alexandre Prokoudine < alexandre.prokoud...@gmail.com> wrote: > On 3/1/11, Michael Grosberg wrote: > > > I also have a couple of suggestions for things to put on the roadmap: > > > > * change the floating selection behavior so that float and un-float can > > be automatic and not need user's explicit input. > > Wasn't it supposed to be done in 2.8 actually? Floating selections got > some attention last year -- that's for sure. > > > * unified transform tool (I remember seeing plans for that last item on > > Peter sikking's Blog) > > http://gui.gimp.org/index.php/Transformation_tool_specification > > You will probably be nicely surprised :) > Wow! That's a great idea of one tool for many actions! +1 for me :) Łukasz Czerwiński ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
On 3/1/11, Michael Grosberg wrote: > I also have a couple of suggestions for things to put on the roadmap: > > * change the floating selection behavior so that float and un-float can > be automatic and not need user's explicit input. Wasn't it supposed to be done in 2.8 actually? Floating selections got some attention last year -- that's for sure. > * unified transform tool (I remember seeing plans for that last item on > Peter sikking's Blog) http://gui.gimp.org/index.php/Transformation_tool_specification You will probably be nicely surprised :) Alexandre Prokoudine http://libregraphicsworld.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP Roadmap - wiki page
Martin Nordholts gmail.com> writes: > > On the developer meeting I got an action to create a draft of a roadmap. > It can be found here: > > http://gimp-wiki.who.ee/index.php/GIMP_Roadmap > > It has has a list of features we prioritize, as well as a list of at > what GIMP release we expect features to be available. > > It is quite influenced by my personal opinions of what we should > prioritize, please take a look and add things you miss. If you disagree > on priorities, please bring it up here so we can discuss it and reach > consensus. > > / Martin > Congrats! this is a much-needed step. Can I ask what "non-destructive editing" is? According to Adobe, this includes: * Color adjustment layers (such as levels, hue/saturation, threshold, etc) * filter layers (such as blur, sharpen, emboss, etc) * smart objects (i.e., ability to scale / rotate a layer as a single object, without changing its pixel data) Maybe this could be expanded upon and prioritized. I also have a couple of suggestions for things to put on the roadmap: * change the floating selection behavior so that float and un-float can be automatic and not need user's explicit input. * Automate layer boundary management so that the user can draw on any point at any time and not worry about increasing the boundary * unified transform tool (I remember seeing plans for that last item on Peter sikking's Blog) So, what do people here think? I believe all three are essential in making GIMP a faster and more hassle free tool. I can expand on these subjects if needed. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
