Thanks for many comments.

2011/1/4 Martin Nordholts <>:
> Add toolbar for tool-options to GimpImageWindow.
> Rather than adding a widgets at the top of the GimpImageWindow taking up
> precious horizontal image space, we should work on moving tool options
> to on-canvas in an elegant way. Adding another tool-options area gives
> less space for image content and more space is taken by widgets, which
> is not the best trend.

I know that there was a discussion about the consumption of the
vertical space of the toolbar once in the mailing list.
And I agree that the toolbar should not replace the existing tool options.
But I also know that there are many requests for horizontal toolbar options.
As a heavy GIMP user, I've wanted the horizontal toolbars and a popup
brush editor for many years.
So I'm developing a toolbar which code base is almost shared with tool
options and
It doesn't replace existing tool options at all. I think optional
toolbar is a good idea unless
it hurts the existing GUI navigation.

> - G-Pen algorithm is ported into GIMP trunk. Now smoothing function
> works for Ink...
> Looks like something we might want, some paint tool hacker should look
> closer at it. Alexia? Mitch?
2011年1月4日17:33 Alexia Death <>:
> I took a quick look. Its an interesting piece of code. Just wondering
> why it is implemented just for the inkpen, when it could just as well
> be implemented in the paint core for any paint tool...

This patch implements smoothing functions both for brush core and ink tools.
Smoothing function works with paint brush, air brush, ink tool, smudge tool,
and maybe with other paint tools such as clone tools.

> BTW, I cant find the dynamics editor implementation commits as a
> patch. Is it in the huge gui merge? Could you lik me to it. I find it
> interesting, but guiguru might object.

Dynamics editor is only an additional features, and it doesn't replace
any existing GUI.
It works only with the horizontal toolbar for now. So you can simply ignore the
additional dynamics editor implementation.
I feel it's much simpler to choose the dynamics and then tweak it in
the same panel,
like many other graphics editors.

> Initial import of color blending function for smudge tool.
> It doesn't look like you change shade_pixels() and shade_region() in a
> backwards compatible way. Don't you break other things with that change?
> Otherwise it looks like a change we would want to merge. It would be a
> good idea to split this commit up so that there is one commit per
> bullet-point in your commit message.

AFAIK, no one calls shade_pixels() and shade_regions(), and it seems
these functions
aren't updated for many years. So I reuse those functions, and update it.
If you don't want to change existing code, we can simply create new
functions instead.

To import blending functions, we should also import the following patches.

*Bugfix:app: GimpFgBgEditor: fix bug which caused a crash when
palette->n_colors == 0.
*Bugfix:app: GimpSmudge: set proper value for GimpBrushCore->scale parameter.;a=blobdiff;f=app/paint/gimpsmudge.c;h=a12863618323aaa01f2079cbbea7aae3dfa41917;hp=6941eed8384ce2afd684ae56394cf9daf10da649;hb=2290ffd0d17138eba31ab8e19d904044705ec2fc;hpb=eb95189dc7493b5364ee8dc462aa46b0419ded87

*Bugfix:app:GimpSmudge: properly handles size dynamics to work.;a=commit;h=66f1b48d582d4bb23a05901d34b14add46b38837

> * Some parameters in the toolbar can be edited using popup editor.
> If I understand your code correctly, you are replacing big widgets with
> smaller widgets that "expand" when you use them. Worth looking into further.

I copied GimpContainerPopup source code and create a new classes named
GimpPopup and GimpPopupButton.
Its functions is simply to popup one time window, to grab the pointer,
and to delete itself when another area is clicked.
And then rewrite many tool options code to use those popup functions
if it is used as a "horizontal toolbar" generator.
I think GimpPopup is very useful classes to make simple popup GUI parts.

2011年1月4日20:46 peter sikking <>:
> when making UI, one has to:
> 1) identify the issue
> 2) find the cause
> 3) evaluate everything (including brainstorm ideas)
> 4) make a solutions model
> 5) design the UI
> 6) develop it
> and although things go a bit jumbled every once in a while,
> this is what happens here at GIMP.
> steps 2-5 are what I bring to any project and customer I work with.

I agree that these features must be reviewed by many people in
official and commercial process,
but we also want to have a prototype to get positive feed back.

It's very good and superior point of the open source software to
implement GUI freely by anyone
and have review it by many other people.

It's just a patch of the my private work for now, so we can review it
and simply ignore many
of them. Let's try step 2-5 based on the feedback from existing prototype.
Gimp-developer mailing list

Reply via email to