GNOME Bugzilla – Bug 165612
0.1 px brush-scale-inscrease shortcuts and other brush shortcuts
Last modified: 2008-01-15 12:46:42 UTC
Right now from what I can see, there are shortcuts to increase the brush size for 1 pixel and for 10 pixels. But I often draw in Gimp, and for that I sometimes need bigger precision: in the .1 pixel range. So can there be possibilities for a .1 pixel increase/decrease shortcuts? I think ideally, there'd also be an increase/decrease scale shortcut that works logarithmically, but if that's too hard to implement, nevermind... While we're at it, is there a possibility of being able to assign a shortcut that when pressed, makes the outline of the brush appear, then you can drag your mouse right and left to increase or decrease the size of the brush, like you can with selections? Ideally this would also work logarithmically to make small brushes more easily. It might work as though by pressing the key, it's as though you're actually dragging the scale bar of the brush editor right and left (without having to access the brush editor). It might be nice if this virtual dragging of the bar could be applied to other criterias as well, by the way (opacity, hardness etc. Of course by default, these shortcuts would not be assigned, and if someone wants to use all of them, it would require a big number of shortcut keys, but it's up to us users to worry about that and assign the keys ourselves). I'd also like an option to see the exact size of the brush as you modify it with shortcuts: it'd appear either besides the outline or in the bar underneath the picture (only as an option though, one that's disabled by default). It'd be nice to have this for opacity, hardness and the likes as well. If these are implemented, I would not need the brush editor nor the brush tools options 90% of the time anymore, and that'd represent a significant saving of space in the particular case of drawing with a brush (I'd be able to close half the menus, really, which is particularly appealing for drawing).
I second this feature. One thing I have a gripe with is only being able to use the brushes given to me, instead of being able to select them down the the pixel. I know The GIMP isn't trying to be like Photoshop, but this feature works and would increase overall workflow performance. Instead of being forced to use a preset list of brushes, one could select a base and then define the pixel width and all other parameters.
"to select them down the pixel" = ?
Replying to comment #1: But you can do that in GIMP. Actually what this bug report is all about, is adding more fine-grained control to this feature.
I would recommend adding an option to scale by a fixed percentage rather than just adding a fixed ammount. Perhaps +10% and -10% (really +10%, and -9.09090909% so it is reversable).
Yup, I second this suggestion. It would greatly increase the output of an average artist if theres a hotkey to increase the brush size rather than selecting then on a window.
Yvan, there are such hotkeys already. This is not what this report is about.
Created attachment 73388 [details] [review] The patch. This patch adds context commands for 0.1px brush radius inc/dec and context commands for percentually radius changed as proposed by Jax Cox. Also fixes a tine indentation bug in docs/Makefile.am
Created attachment 73394 [details] [review] The refined patch. This is a new version of the above patch.
I now see I forgot a to add 'Partially fixes bug #165612' to the ChangeLog diff, so it would be good if the person who commits the patch adds that.
Let's consider this for inclusion in GIMP 2.4.
Created attachment 73435 [details] [review] The futher refined patch It is not smart to return if fail at the beginning of the function, because in some cases it makes sense to pass delta_percent as 0, so I fixed that in this version. Also added the 'Partially fixes bug' sentence.
Created attachment 73842 [details] [review] Even *futher* refined patch Made radius adjustments a more intuitive; the minimum allowed brush radius is 1.0 unless a high precision method is used, in which case the minimum radius allowed is 0.1 px is maintained (for 0.1px or percentual radius change steps). This eliminates the irritating situation that arose if you decreased 1.0 px step one step "too far" so you got a 0.1 px radius. If you then increased the radius you got 1.1, 1.2 radiuses etc, which was irritating. If the user does not set a keyboard shortcut for highprecision changes, the minimum radius (for keyboard shortcuts) will still remain 1.0. Please, let me know if there is any particular issue with this patch that makes you refrain from commiting it.
I really appreciate this, I had not even thought of such a thing but I'm sure I will get a lot of use out of it. Here's my overview of what might need changes: * Usually, diffs do not include changelog entries. One reason for this is: the changelog entry is credited to the person who committed the patch (with credit to the patch creator inside the entry) * "* app/actions/actions-types.h: Added four enum values." This is vague. Be specific. 'Added enum values for increasing/decreasing by percentage or by especially small units.' * "SMALL_PREVIOUS/SMALL_NEXT" sounds strange. MICRO_ might be a better prefix. * "delta_percent" is not a percentage (1.0 units of delta_percent equals 100 percent) * Layer opacity ends up mapping to the range 0..255, so there is no point in using an increment smaller than 1.0/255 ( 0.0039215686274509803 ) The same applies to drawing opacity. * docs/Makefile.am should probably not be included in the diff. * 'Further' is spelled 'further' ;)
MICRO is certainly not in any way better than using SMALL here. The patch looks fine to me execpt for the hackery that is needed for the minimum brush radius. If this is not avoidable, then there should at least be a comment explaining this weird code.
Created attachment 74126 [details] [review] Among the last refinements hopefully Based on your feedback, here's the latest version of the patch. I give you a ChangeLog proposal here instead. Added support 0.1 px brush radius inc/dec context commands as well as inc/dec commands for changing the brush radius size relatively to the current size. Adding corresponding functionality for other things involves tweaking the values passed to action_select_value for that particular action. Partially fixes bug #165612 * app/actions/actions-types.h: Added enum values for increasing/decreasing by percentage or by especially small units. * app/actions/actions.c: (action_select_value), (action_select_property): * app/actions/actions.h: * app/actions/context-actions.c: * app/actions/context-commands.c: * app/actions/layers-commands.c: (layers_opacity_cmd_callback), (layers_mode_cmd_callback): * app/actions/view-commands.c: (view_zoom_cmd_callback), (view_scroll_horizontal_cmd_callback), (view_scroll_vertical_cmd_callback):
Ok, that was really irritating, I had the unmodified ChangeLog change in the clipboard. Add 'Applied patch by Martin Nordholts which adds support for'... to the beginning to get what I was meant to submit.
What's the purpose of g_return_val_if_fail (delta_factor > 0.0, value) ? Also, why don't we change the minimum brush size to 0.1? Either it makes sense to have such small values, then we should just change the minimum, or it's pointless, then we don't need to special case this.
The g_return_val_if_fail was first testing for division with zero, but as it makes no sense anyway at having a negative value for delta_factor, it checks for > 0.0 instead of != -1.0, and it checks in both inc and dec to be consequential. The thing is, if we let minimum brush radius be 0.1 px, then it is very easy to accidentally get a 0.1 px radius with the 1.0 px radius steps, and once you get that, the radiuses will always end with .1 unless you manually fix it with the Brush Editor. Besides, the special case code to handle this is concentrated to one place, and is not complex, so it is very easy to remove/modify if this for any reason would be needed. I think the bare appearance of the comment makes the special case code look more complex, after all, it only uses local variables so I think it is quite easy to follow. The comment more or less paraphrase what you would think out loud when you read the code line by line, so I think the comment is redundantt, but it's not my decision to make, of course.
Fixed in CVS: 2006-10-15 Michael Natterer <mitch@gimp.org> Applied slightly modified patch from Martin Nordholts which implements more fine-grained steps for actions. Fixes bug #165612. * app/actions/actions-types.h: add additional values to enum GimpActionSelectType. * app/actions/actions.[ch] (action_select_value) (action_select_property): handle them here and added "small_inc" and "delta_factor" parameters. * app/actions/context-actions.c: added small and percent actions for the brush radius. * app/actions/context-commands.c * app/actions/layers-commands.c * app/actions/tools-commands.c * app/actions/view-commands.c: pass small and percent increase values to the action_select_foo() functions. * app/actions/context-commands.c (context_brush_radius_cmd_callback): make sure we don't end up with 1.1, 2.1 etc brush radius values.