Re: [Gimp-developer] Brush dynamics input and output mapping.
On Thu, Sep 15, 2011 at 1:49 AM, Brian Vanderburg II brianvanderbu...@aim.com wrote: Velocity - I may consider 10 pix/sec slow (0) and 100 pix/sec fast (1) while someone else may consider 50 pix/sec slow and 500 pix/sec fast. This is slightly compilcated as velocity is purely a derivative value but velocity range may become configurable in the future. Pressure - While a tablet may support many levels of pressure, a user may not be accustomed to pressing a certain force to get a desired result, and may wish that pressure level 300 (instead of 511) be treated as the maximum pressure (1). Similarly a user may not be good at being very light on the tablet and may prefer a pressure level of 30 to be treated as the minimum pressure (0). Tilt - A user may prefer a certain tilt range to map from. One user may prefer only slight tilts to get the full range (0-1) while another user may be fine with larger tilts. All physical axis of the tablet have curves that you can configure in the settings in 2.7(dev version of 2.8) Inputs that mapping does not make sense: Direction (0-1 = 0-360 deg) Random Doesn't make sense how? Look at GPS. Random is made rather good use of in some presets and direction has its uses as well. Input mapping should probably be configured in user preferences. That does not make sense. Outputs are provided by the pain tool... Similarly it may be useful for each target's outputs. For instance specifying the 0/1 size of a brush as a percentage of the brush size or opacity as a percentage of the current brush opacity. I dont understand this... Have you looked at what you can do with 2.7 dynamics curves? dynamics always affect the output as a ratio. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush dynamics input and output mapping.
On 09/15/2011 03:15 AM, Alexia Death wrote: Inputs that mapping does not make sense: Direction (0-1 = 0-360 deg) Random Doesn't make sense how? Look at GPS. Random is made rather good use of in some presets and direction has its uses as well. What I mean is it doesn't make sense for the direction to have any other mapping than from 0 to 360 degrees of the stroke to become 0 to 1 of the direction dynamics input. All the input mapping idea is for is to map the physical input from the device or mouse to the dynamics input in a way that is natural for the user. It is not meant to do anything more exotic, all that can be done in the dynamics themselves. You've mentioned that something like this is already there for the tablet axis in the form of curves under settings. So a user can already use these to map how input from the device would become input for the dynamics, what pressure or tilt range is natural for them. (I don't own a tablet yet so I wasn't previously aware these are already there.) Since these settings are already there, then my idea is reduced simply to having velocity dynamic configured as well so two different users with different ideas of what is slow and fast could still have their idea of slow mapped as 0 and their idea of fast mapped as 1 for the velocity dynamic, even if just using a mouse. signature.asc Description: OpenPGP digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush dynamics input and output mapping.
As the brush dynamics editor only supports inputs from 0 to 1 and outputs from 0 to 1, it seems like it could be a good idea to support mapping inputs and outputs based on user preferences. Inputs that could use mapping: Velocity - I may consider 10 pix/sec slow (0) and 100 pix/sec fast (1) while someone else may consider 50 pix/sec slow and 500 pix/sec fast. Pressure - While a tablet may support many levels of pressure, a user may not be accustomed to pressing a certain force to get a desired result, and may wish that pressure level 300 (instead of 511) be treated as the maximum pressure (1). Similarly a user may not be good at being very light on the tablet and may prefer a pressure level of 30 to be treated as the minimum pressure (0). Tilt - A user may prefer a certain tilt range to map from. One user may prefer only slight tilts to get the full range (0-1) while another user may be fine with larger tilts. Inputs that mapping does not make sense: Direction (0-1 = 0-360 deg) Random Input mapping should probably be configured in user preferences. Similarly it may be useful for each target's outputs. For instance specifying the 0/1 size of a brush as a percentage of the brush size or opacity as a percentage of the current brush opacity. Brian Allen Vanderburg II signature.asc Description: OpenPGP digital signature ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush dynamics input and output mapping.
I would second this as a useful idea. -- Kind Regards, Vincent Ardern -Original Message- From: Brian Vanderburg II brianvanderbu...@aim.com Sender: gimp-developer-boun...@lists.xcf.berkeley.edu Date: Wed, 14 Sep 2011 18:49:34 To: GIMP Developers Listgimp-developer@lists.xcf.berkeley.edu Subject: [Gimp-developer] Brush dynamics input and output mapping. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush tool artefacts = slow brush tools
2010/10/10 Sven Neumann s...@gimp.org On Sun, 2010-10-10 at 17:24 +0200, Olivier wrote: There are no longer brush tool artefacts on the canvas, which is very good. Unfortunately, and maybe this is because of the repair, the brush tools are now very slow. Olivier, please, this is ongoing development. And yes, we are using the application that we are developing. And yes, we notice such problems. There is really no need to tell us about each and every problem you encounter with current git. In particular not if there's already a bug-report on it. Please forgive me for the bothering. I do know that GIMP is in development, and I'm following the process as close as I can, so that the book I'm preparing will be published as soon as possible after 2.8 delivery. I'm only trying to be helpfu to the developers, and some times I signaled a problem not yet discovered. This time, as soon as I saw that the bug about brush artefacts was fixed, I made a try and sav the slowness problem. I was not aware of the other bug report, and I did the mistake of not checking before. I don't really know what is the best way to signal problems without bothering the developers: the gimp-developer list, the IRC channel, or bugzilla ? -- Olivier Lecarme ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush tool artefacts = slow brush tools
On Mon, Oct 11, 2010 at 12:11 PM, Olivier oleca...@gmail.com wrote: I don't really know what is the best way to signal problems without bothering the developers: the gimp-developer list, the IRC channel, or bugzilla ? IF it's git and the issue just appeared, checking in at IRC is best and fastest way. If reporting against git, the situation can change in 10 minutes it takes to type up an email. If its something that is going to take a bit longer or the person working on that particular thing is way, you will probably be asked to open a bug report. Stable version issues can go directly to bugzilla. Mailing list is usually used for generic debates, recommendations and large scale problem solving. And flame wars over the name. It's not interactive enough for daily debugging work. -- --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush tool artefacts = slow brush tools
On Sun, 2010-10-10 at 17:24 +0200, Olivier wrote: There are no longer brush tool artefacts on the canvas, which is very good. Unfortunately, and maybe this is because of the repair, the brush tools are now very slow. Olivier, please, this is ongoing development. And yes, we are using the application that we are developing. And yes, we notice such problems. There is really no need to tell us about each and every problem you encounter with current git. In particular not if there's already a bug-report on it. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush dynamics are confusing at their current state
Hello, After a bug report like this https://bugzilla.gnome.org/show_bug.cgi?id=623980 and some more discussion on IRC, it was pointed out that brush dynamics are now confusing for users who don't know them. Some example problems are: - Brush resizing because the default dynamics maps the velocity to the brush size, will make regular users wonder why their brush resizes (like the bug report above) - Users that used the basic dynamics in 2.6 possibly won't find them in 2.8 and will complain about missing features - Finding where to choose brush dynamics is simply not intuitive Suggestions: 1. Change the default brush dynamics to mimic the default settings in 2.6 (Pressure mapped to Opacity, and disabling all the other inputs). Simply disabling all the dynamics by default (or more precisely, setting them to Dynamics Off) will cause bug reports about missing pressure support... 2. Adding a widget in the tool options window, to select the brush dynamics. This sounds logical if we already allow to select the brush and gradient from the tool options window. We need feedback for both suggestions - what should the default dynamics be (maybe we should enable things like tilt which don't affect users that use a mouse), and whether to add or not to add a widget to select the dynamics from the tool options window. ~LightningIsMyName ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush dynamics are confusing at their current state
On Friday, July 09, 2010 23:38:53 LightningIsMyName wrote: Suggestions: 1. Change the default brush dynamics to mimic the default settings in 2.6 (Pressure mapped to Opacity, and disabling all the other inputs). Simply disabling all the dynamics by default (or more precisely, setting them to Dynamics Off) will cause bug reports about missing pressure support... It's pretty much a decided thing that the default dynamics are not intuitive and they are going to change to 2.8. To what is open for discussion, but I'm also favoring mimicking 2.6 unless a better option is proposed. 2. Adding a widget in the tool options window, to select the brush dynamics. This sounds logical if we already allow to select the brush and gradient from the tool options window. This is also pretty much a decided thing. Not implemented yet tho. Wanna do it? --Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] brush precision
Hi, I posted this to the users' forum, but that was probably a mistake. I'm copying it to here in the hope that it might be useful. /Gary (from users' forum... some time ago there was a thread about changing the brush icon between showing the brush size and a precise crosshair. I can't seem to locate that thread, but if I remember rightly it was suggested that the change should happen at mouse-click, or when holding the mouse button down. Now I've just discovered, quite fortuitiously, that in photoshop (at least in Elements 2, so presumably also in PS7, on which the elements code was based) that you can toggle between these icons (i.e. brush outline vs. crosshair) using the caps-lock key. Maybe that might be a good idea for GIMP also? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush dynamics - wheel sensivity
-- EV -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush dynamics - wheel sensivity
On Thursday 12 February 2009 22:10:14 Egor Voznessenski wrote: -- EV -- This mail is supposed to mean what? What wheel? -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] brush rotation - abotu the chanegs on 10-feb-09
Hi, I am aware that it is a work in progress -- just to let you know (Alexia and others) - the changes in the two commits dated 10-feb-2009 got things a lot worse and less natural for me than it was before. I am nto complainign, I know a lot of tunning is getting in, and I am writing this just for feedback while you adjust it. Now, I f I paint slowly, the brush will suddenly reverse its angle - Also, if I mark the direction x angle dynamic, the painting angle does nto feel natural, and it felt before - at least when I use a brush that is oriented towards up like an up arrow, or the letter A - both behaviores were better previously. Regards, js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] brush rotation
For those of you who don'tt follow trunk closely or the irc channel, I can't resist the urge to tell that Alexia Death and Mich have been working on brush dynamics over the last few days - and have thus far added brush rotation. It now works both as a fixed factor and following painting direction. Yaii!! (as any brand new feature, it still buggy and error prone, but they are actvelyy fixing everything) js -- I've heard it in the IRC last week ;) Its really great - however i couldn't try it out yet. Nevertheless: Thanks very much, Alexia Death and Mitch, for this feature! It will also be great when using it together with the brush dynamics. -- Bernhard S. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] brush rotation
For those of you who don'tṫ follow trunk closely or the irc channel, I can't resist the urge to tell that Alexia Death and Mich have been working on brush dynamics over the last few days - and have thus far added brush rotation. It now works both as a fixed factor and following painting direction. Yaii!! (as any brand new feature, it still buggy and error prone, but they are actvelyy fixing everything) js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush dynamic ideas.
I've recently compiled GIMP 2.6 on Linux (Debian 4). It took some work
compiling some base libraries but overall was pretty simple. I may
start looking though the code some to get acquainted with it mainly for
writing custom plugins to do some things I want.
Anyhow I though about some more ideas for a brush dynamics system, these
are just some ideas I doubt I could do much with them myself though but
I may try to familiarize myself with the code anyhow.
In the brush dynamics system there are input controllers and output
attributes (just the words I'm using, may not be the official names).
The current system is a little limited because for any given input the
same adjustment value applies to any outputs. It's not possible for
'pressure' to affect 'opacity' by 0.5 and 'color' by just 0.2 for instance.
First, the brush dynamics could be a separate dialog, or at least a
button for each tool supporting the dynamics could open up the dialog or
make it active if it is already opened. Instead of having mappings
directly in the dialog, a list would exist supporting add, edit, delete,
move up, and move down (and maybe save and load)
Each item in this list corresponds to a single input-output pair
mapping. It can not modify the values of the input controller, but it
can modify the values of the brush attribute. It also contains an
offset and multiplier such that 'pre_output = inputs[selected_input] *
multiplier + offset'. It may also be desired to adjust the final
attribute in different ways. Two ways would be addition to the current
value or multiplication by the current value:
if modify_mode == ADDITION:
outputs[selected_output] += (inputs[selected_input] * multiplier +
offset)
elif modify_mode == MULTIPLICATION:
outputs[selected_output] *= (inputs[selected_input] * multiplier +
offset)
The available outputs would depend on the selected brush type. Common
values include:
opacity
hardness
color
size
jitter (if part of brush dynamics, it could be controlled by any of the
inputs)
rate
frame (for animated brushes, could be used to select output image from
the brush)
rotation (the rotation of the brush, could be used for weird calligraphy
effects of oddly shaped brushes, etc)
It has also been mentioned that curves would be nicer. This could be
done and would just replace the offset and multiplier:
if modify_mode == ADDITION:
outputs[selected_output] += curve[inputs[selected_input]]
elif modify_mode == MULTIPLICATION:
outputs[selected_output] *= curve[inputs[selected_input]]
Additional input types could also be provided. The only ones may be
tilt (for tablets that support them), angle (the angle between the
previous mouse position and the current mouse position)
The values of the inputs would have to be calculated before processing
the dynamics list, then the list processing is fairly straight forward:
// assume inputs is array of available input control values and
// outputs is the array of final brush attributes before applying the brush
for(node = first ; node ; node = node-next)
{
adjustment = inputs[node-selected_input] * node-multiplier +
node-constant;
// For curves
// adjustment = get_curve_value(node-curve,
inputs[node-selected_input]);
value = outputs[node-selected_output]
switch(node-method)
{
default:
case ADDITION:
value += adjustment;
break;
case MULTIPLICATION:
value *= adjustment;
break;
}
outputs[node-selected_output] = value;
}
// outputs now has the final brush attributes to use
Anyway those are the ideas. I doubt any of those are compatible with
the current code though.
Brian Vanderburg II
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush dynamic ideas.
Brian Allen Vanderburg II wrote: Anyhow I though about some more ideas for a brush dynamics system, these are just some ideas I doubt I could do much with them myself though but I may try to familiarize myself with the code anyhow. Hi and thanks for the suggestions! They are however not very original and along the lines of what most other people propose as far as an improved brush dynamics system goes. What is needed is less proposals and more people actually writing some code ;) It's great to hear you are curious about the code. The best place to hang around when getting acquainted to the code is #gimp @ irc.gnome.org as this is where the core developers also hang around. Feel free to drop by and ask any questions you have. You also probably will want to get in touch with Alexia_Death who has a few brush dynamics hacks up her sleeve. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush dynamic ideas.
On Saturday 25 October 2008 11:02:57 Brian Allen Vanderburg II wrote: Anyhow I though about some more ideas for a brush dynamics system, these are just some ideas I doubt I could do much with them myself though but I may try to familiarize myself with the code anyhow. Most of what you have suggested has already been detailed. There is a concept of curves driven dynamics GUI. But there is nobody to realize it. Thats where it is stuck now. I am capable of making the functionality, but not the GUI. Anyway those are the ideas. I doubt any of those are compatible with the current code though. Compatible in what sense? The dynamics calculation system is very simple and rather extensible. when a brush needs a value ie opacity it queries a function for it. The function returns the mixed value based on the coord set passed an the state of dynamics options. Extending it is very simple. Making the GUI for it and linking it to code is not(at least for me). If you would be interested of working on it, it would be great. -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush dynamic ideas.
[EMAIL PROTECTED] wrote:
On Saturday 25 October 2008 11:02:57 Brian Allen Vanderburg II wrote:
Anyhow I though about some more ideas for a brush dynamics system, these
are just some ideas I doubt I could do much with them myself though but
I may try to familiarize myself with the code anyhow.
Most of what you have suggested has already been detailed. There is a concept
of curves driven dynamics GUI. But there is nobody to realize it. Thats where
it is stuck now. I am capable of making the functionality, but not the GUI.
I'm more of a C++ person (esp when it comes to GUIs) or python and
usually use wxPython/wxWidgets so I don't really know much about how GTK
works that much.
Anyway those are the ideas. I doubt any of those are compatible with
the current code though.
Compatible in what sense? The dynamics calculation system is very simple and
rather extensible. when a brush needs a value ie opacity it queries a
function for it. The function returns the mixed value based on the coord set
passed an the state of dynamics options. Extending it is very simple. Making
the GUI for it and linking it to code is not(at least for me). If you would
be
interested of working on it, it would be great.
I've only done a little so far on GIMP 2.6.0 code. I've made a small
change that makes it where jitter is controlled also by brush dynamics
so that when jitter is enabled and a dynamic is also enabled, it will be
used. Tested with velocity, faster motion causes a smaller jitter.
Here is a diff showing whats done. I've no idea if the diff is the
correct format as I'm used to doing 'svn diff' and not just 'diff -r
oldpath newpath'.
I can't seem to figure what prescale does. No matter how I adjust it in
the interface the result always seems the same. If velocity is set to
color, slow motion yields the first color and faster motion yields the
second color, whether the slider is all the way to the right or the left.
Brian Vanderburg II
Only in gimp-2.6.0/app/gui: gimpdbusservice-glue.h
diff -r gimp-2.6.0/app/paint/gimpbrushcore.c
gimp-2.6.0-new/app/paint/gimpbrushcore.c
641a642
gdouble real_jitter;
645c646,650
jitter_dist = g_rand_double_range (core-rand, 0,
core-jitter);
---
real_jitter = core-jitter *
gimp_paint_options_get_dynamic_jitter (paint_options,
paint_core-cur_coords);
jitter_dist = g_rand_double_range (core-rand, 0,
real_jitter);
diff -r gimp-2.6.0/app/paint/gimppaintoptions.c
gimp-2.6.0-new/app/paint/gimppaintoptions.c
48a49
#define DEFAULT_PRESSURE_JITTER FALSE
56a58
#define DEFAULT_VELOCITY_JITTER FALSE
64a67
#define DEFAULT_RANDOM_JITTER FALSE
97a101
PROP_PRESSURE_JITTER,
105a110
PROP_VELOCITY_JITTER,
113a119
PROP_RANDOM_JITTER,
218a225,228
GIMP_CONFIG_INSTALL_PROP_BOOLEAN (object_class, PROP_PRESSURE_JITTER,
pressure-jitter, NULL,
DEFAULT_PRESSURE_JITTER,
GIMP_PARAM_STATIC_STRINGS);
247a258,261
GIMP_CONFIG_INSTALL_PROP_BOOLEAN (object_class, PROP_VELOCITY_JITTER,
velocity-jitter, NULL,
DEFAULT_VELOCITY_JITTER,
GIMP_PARAM_STATIC_STRINGS);
276a291,294
GIMP_CONFIG_INSTALL_PROP_BOOLEAN (object_class, PROP_RANDOM_JITTER,
random-jitter, NULL,
DEFAULT_RANDOM_JITTER,
GIMP_PARAM_STATIC_STRINGS);
457a476,479
case PROP_PRESSURE_JITTER:
pressure_options-jitter = g_value_get_boolean (value);
break;
485a508,511
case PROP_VELOCITY_JITTER:
velocity_options-jitter = g_value_get_boolean (value);
break;
513a540,543
case PROP_RANDOM_JITTER:
random_options-jitter = g_value_get_boolean (value);
break;
647a678,681
case PROP_PRESSURE_JITTER:
g_value_set_boolean (value, pressure_options-jitter);
break;
675a710,713
case PROP_VELOCITY_JITTER:
g_value_set_boolean (value, velocity_options-jitter);
break;
703a742,745
case PROP_RANDOM_JITTER:
g_value_set_boolean (value, random_options-jitter);
break;
1247a1290,1327
gdouble
gimp_paint_options_get_dynamic_jitter (GimpPaintOptions *paint_options,
const GimpCoords *coords)
{
gdouble jitter = 1.0;
g_return_val_if_fail (GIMP_IS_PAINT_OPTIONS (paint_options), 1.0);
g_return_val_if_fail (coords != NULL, 1.0);
if (paint_options-pressure_options-jitter ||
paint_options-velocity_options-jitter ||
paint_options-random_options-jitter)
{
gdouble pressure = -1.0;
gdouble velocity =
[Gimp-developer] brush manager
With these new cool options for the gimp 2.4, I can't seem to find information about whether or not there will be a brush manager. In gimp 2.2, it's getting rather messy in that folder when you have a number of brushes, it gets hard to organize, plus it seems to add to the time gimp takes to load. There is a python script around that provides a kind of brush management, so you can toggle sets on and off. Basically it works like this: you have an active brush folder, which is the directory you tell gimp to load the (extra) brushes from, and there is the folder where all the brushes, and sets are located. the script creates a small gui with a list and a checkbox. you check which brushes you want active, it then copies those to the active brush folder, and after a brush reload, you have your brushes at your disposal. Obviously if you uncheck them, the script removes them from the active brush folder. I've googled quite a bit, and can't find a thing about brush management, well, rather a brush manager for the gimp above version 2.2 (which includes 2.4) I'm rather curious, is a brush manager in the works? that would be a very nice addition. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush manager
On 8/19/07, M Tieleman wrote: I'm rather curious, is a brush manager in the works? AFAIK, no. Feel free to write it after 2.4 :) There is an open source (hosted by SourceForge) brush manager for The-Application-I-May-Not-Name-Here, so you have something to look at. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush manager
On Sat, 18 Aug 2007 22:36:14 +0200 M Tieleman [EMAIL PROTECTED] wrote: I've googled quite a bit, and can't find a thing about brush management, well, rather a brush manager for the gimp above version 2.2 (which includes 2.4) I'm rather curious, is a brush manager in the works? that would be a very nice addition. There was a 2006 Google Summer of Code project for this. If it had been completed, there would be a brush manager in GIMP 2.4, but it wasn't (the student is not to blame, he focused on something completely different instead). Maybe the same project can be proposed for the 2008 GSOC? Karine ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush Scaling
Accessing the size and rotate settings through the pdb would be great, here is a lot of ways that I would end up using it... I have a few scripts where I have needed to change rotation and size of a brush... What I've ended up doing is creating a new layer, paint one instance at x,y, and then resize it - rotate it - merge it down - It works but it's very, very time consuming when you have a script that does it several dozen times... Multiple strokes on the same path or selection for sure... You could make some nice border scripts just by using different rotate, scale, and spacing settings with the same brush layered on top of each other... anyway thanks again for everything so far, it is really appreciated... (I've been using it constantly) Joao S. O. Bueno Calligaris wrote: On Thursday 15 March 2007 07:22, jbaker wrote: Thanks for all the work on this one, it works great... I was just curious if there are any plans add the ability to scale and rotate the standard brushes with python ? I did a quick search in the procedure browser but didn't see anything except the functions for the generated brushes... thanks, no plans made - except for generated brushes (the ones you can create and edit from within the brush dialog). But this is an area I am thinking about. (actually, mostly the pdb for brush stroking) Please say a little more on what you are planning to do (the final effect). Regards, js -- jerry ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush sizing
Greetings, I'm glad to see that GIMP is incorporating a brush scaling mechanism. I've been waiting for a long time for something like this! Although, it would be nice if the brush can scale up and down, instead of simply scaling down. This is something that I use quite a lot when painting. The current workaround for this problem I use is to use dynamic brushes and increase and decrease the radius with key bindings. The only drawback is that this works only dynamic brushes. Sometimes a would like to do the same for a bitmap brush (which can now be done via scaling). So, in short. Could you guys have the brushes scale up as well? Thanks for the fabulous work so far! As a side note: How about a separate mailing list for feature requests or where would you prefer feature requests go? Regards, Van Aarde. -- Van Aarde Krynauw http://students.ee.sun.ac.za/~idx Man who falls in vat of molten optical glass makes spectacle of self. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush sizing
On Fri, 2007-03-16 at 15:16 +0200, Van Aarde Krynauw wrote: Greetings, I'm glad to see that GIMP is incorporating a brush scaling mechanism. I've been waiting for a long time for something like this! Although, it would be nice if the brush can scale up and down, instead of simply scaling down. This is something that I use quite a lot when painting. The current workaround for this problem I use is to use dynamic brushes and increase and decrease the radius with key bindings. The only drawback is that this works only dynamic brushes. Sometimes a would like to do the same for a bitmap brush (which can now be done via scaling). So, in short. Could you guys have the brushes scale up as well? It's already done and will be in the next development release. Thanks for the fabulous work so far! :-) As a side note: How about a separate mailing list for feature requests or where would you prefer feature requests go? Feature request go into bugzilla and are preferrably discussed on this mailing list first, to avoid cluttering bugzilla with weird requests and to avoid hiding the discussion there. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush Scaling
On Thursday 15 March 2007 07:22, jbaker wrote: Thanks for all the work on this one, it works great... I was just curious if there are any plans add the ability to scale and rotate the standard brushes with python ? I did a quick search in the procedure browser but didn't see anything except the functions for the generated brushes... thanks, no plans made - except for generated brushes (the ones you can create and edit from within the brush dialog). But this is an area I am thinking about. (actually, mostly the pdb for brush stroking) Please say a little more on what you are planning to do (the final effect). Regards, js -- jerry ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush organization
Too bad. My C skills are probably not quite up to doing anything about it myself, unfortunately. In terms of looking up the bug in bugzilla: My bad, but at the same time developers probably do need some way of figuring out which bugs/requests for enhancements are most needed by users, and if you see a lot of people independently asking for the same thing that is information that could probably be of use to you in terms of setting priorities. -Original Message- From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: gimp-developer@lists.XCF.Berkeley.EDU Sent: Mon, 22 Jan 2007 1:32 AM Subject: Re: [Gimp-developer] Brush organization Hi, On Sat, 2007-01-20 at 15:28 -0500, [EMAIL PROTECTED] wrote: I asked this on the Gimp-Win mailing list and no one there knew a way of doing it so: Is there any way to put Gimp brushes into subcategories (like subdirectories) so that if I add a bunch of brushes I don't have to scroll through an inordinate number of them in order to get the one I want? If not, is that something worth considering for some future release--2.6 or 3.0? A search in our bug-tracker would have showed you that this has indeed been considered a long time ago and that it would be a welcomed addition. Since no one is actively working on it, it is not likely going to be in 2.6 though. Sven Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Brush organization
I asked this on the Gimp-Win mailing list and no one there knew a way of doing it so: Is there any way to put Gimp brushes into subcategories (like subdirectories) so that if I add a bunch of brushes I don't have to scroll through an inordinate number of them in order to get the one I want? If not, is that something worth considering for some future release--2.6 or 3.0? BTW: Looking forward to 2.4. Thanks Dale Cozort Check out the new AOL. Most comprehensive set of free safety and security tools, free access to millions of high-quality videos from across the web, free AOL Mail and more. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Brush organization
Hi, On Sat, 2007-01-20 at 15:28 -0500, [EMAIL PROTECTED] wrote: I asked this on the Gimp-Win mailing list and no one there knew a way of doing it so: Is there any way to put Gimp brushes into subcategories (like subdirectories) so that if I add a bunch of brushes I don't have to scroll through an inordinate number of them in order to get the one I want? If not, is that something worth considering for some future release--2.6 or 3.0? A search in our bug-tracker would have showed you that this has indeed been considered a long time ago and that it would be a welcomed addition. Since no one is actively working on it, it is not likely going to be in 2.6 though. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush plugins
Hi, Laxminarayan Ammembal Kamath [EMAIL PROTECTED] writes: another idea Not a new one though. This has been suggested before. There is just no infrastructure for these kind of plug-ins/extensions. We plan to have it at some point in time but so far no work is being done to make this happen. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] brush
Hi. I'm not sure if it's too late to suggest this change to the coming stable version of The Gimp or not, but I've been thinking that it would be nice if, when drawing or painting (or moving or anything for that matter), there would only be a small dot or something that doesn't take a lot of space when trying to edit a small image or part of it. I've noticed that forexample when I try to move some small image downwards, I can't properly see the down-right side of the small image. Just a suggestion, let me know how this idea sounds. -Nasim -- ××× Nasim Shamlou A. +358-45-676 2746 http://www.students.tut.fi/~shamlou ××× ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] brush
Hi, Nasim Shamlou A. [EMAIL PROTECTED] writes: I'm not sure if it's too late to suggest this change to the coming stable version of The Gimp or not, but I've been thinking that it would be nice if, when drawing or painting (or moving or anything for that matter), there would only be a small dot or something that doesn't take a lot of space when trying to edit a small image or part of it. I've noticed that forexample when I try to move some small image downwards, I can't properly see the down-right side of the small image. have you tried the Crosshair cursor modes? They can be selected in the Preferences dialog in the Image Window section. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
