GNOME Bugzilla – Bug 163057
allow simple editing/transforming of pixmap/bitmap brushes in brush[editor] dialog
Last modified: 2009-07-22 12:33:09 UTC
Currently, with bitmap/pixmap brushes, there is essentially no tweaking of the brushes available (just spacing). It would be handy to allow brushes to be scaled and rotated from the editor dialog. It would also be handy to be able to do some simple color adjustments (changing the overall hue/sat/value would be nice) for pixmap brushes, since there is currently no way to change the color of a pixmap brush other than opening the brush file, editing it, saving it, and refreshing the brushes. For painting/drawing, having quick and easy access to these types of modifications to the brushes would help artists produce more relastic images.
These modifications probably shouldn't modify the brush pixmap, just the "view".
I don't think we should overload the brush editor and let it duplicate the functionality of the main app. GIMP is a pixmap editor already, people should use it to edit brushes. We might have to make it easier to do that but the actual editing functionality doesn't belong into the brush editor.
*** This bug has been marked as a duplicate of 163059 ***
This is not a duplicate of 163059. The two are different RFE's. Forcing a user to open a brush as an image, tweak it, save it (and in the process, permantely changing the brush), refresh the dialog, and reselect the brush so that they can make a brush a little bit smaller is pretty horrible ui. Having some simple brush editor capabilities easily accessable is the point of this RFE. See Painter or PS7 for an example. Changing the size of brush should not be a multi step proccess.
In the long run we want to get rid of pixmap brushes anway. IMO any work put into this is wasted time and effort.
Sven, this is quite an unreflected statement and I don't remember a discussion that would justify the usage of "we". We'll always have to deal with pixmap brushes, simply because users want to use snippets from photos etc. as brushes. And being able to do simple transformations like scale/rotate on this kind of brushes without loading/saving the brushes as images is IMHO absolutely reasonable. /me waits for the "nobody suggested that..." :-)
I thought that it was commonly agreed that all brushes should be transformable. Most brushes should be vector brushes for that purpose and we have started to add more brush shapes for that reason. We might of course have to support pixmaps just as SVG also deals with pixmap data. But for the user a brush would just be a transformable vectors object. If this report is about being able to transform pixmap brushes, than it should probably be renamed since "editing a pixmap" sound more like drawing to it.
you say transform, I say edit. How about "munge" Basically, there is a small set of transforms and munging to a brush that would be very useful to have quickly available to the user. Scale and rotate being obvious ones. But some simple color manipuation also (changing hue/sat for example). PSP and Painter seem to store brushes in a very large format, and scale down for the "default" size. Since gimp already supports brush scaling, doing this as part of the ui seems logical. The ui for editing vbr brushes already allows scaling. How this is implemented doesn't matter much to me. I understand that in the perfect future the distinction between brush data and image data will disappear and brushes could be manipulated with the same code as images. But regardless of the internal representation of the brushes, this feature would be nice.
OK, so this is mainly a duplicate of bug #65030 then, isn't it? One way of addressing this would be to change the internal representation of brushes (and patterns while we are at it) from TempBuf to GdkPixbuf. We could then use the GdkPixbuf scaling routines and in the future there's also supposed to be a transform API that allows rotations.
I'd say it's closer to a dup of #126591 than #65030 ( I wouldn't of closed #126591 as a dup of #65030 myself, since #65030 doesn't touch on rotation at all and seem to be seperate, but related, work items). The primary idea here is that this should be in the ui somewhere, and the brush editor seems the logical place. I don't really understand the policy and lifecycle for gimp bugs, so I can't say if this is considerred a duplicate or not. Thats your call.
Adrian, could you please try to learn the proper syntax to refer to bugs, which is _not_ "#126591" but "bug #126591". That would make things a lot easier.
*** Bug 172433 has been marked as a duplicate of this bug. ***
Created attachment 75903 [details] suggested UI Here's an annotated mockup of a possible UI to such a feature. It could be simplified, but eventually this seems like the right way for it to end up when all of those features are available in the backend. Design based on Pixia (simple easy brush scaling adjustment) and somewhat apropos to the ink tool -- clicking inside the blue box sets the cursor position, which determines scale and (later) rotation. of the edge handles: 1 2 3 4 5 6 7 8 4 and 5 would adjust vertical skew (drag up or down) 2 and 7 would adjust horizontal skew (drag left or right) 1, 3, 6, 8 would adjust perspective the advanced transform UI is based on Inkscape's UI. The dashed box is the original size of the brush. I think this will be important even with vector brushes. The blue box would be drawn differently (more/less squashed or rotated) according to the position of the cursor; It happens to be square due to having exactly 100% scale in both dimensions and 0 angle. There would be another box which shows the current scale and rotation.
part of this bugs solution is IMHO to make brush editor work for all, not just vbr brushes.
With the new brush dynamics stuff incoming and scaling and rotation in place, we essentially have what the original reported requested. Let's close this as OBSOLETE and deal with other issues in dedicated bug reports.