On 01/04/2011 08:25 AM, しげっち wrote:

Hi, all.
I'm recently implementing a GUI features that is inspired by the ideas of the GIMP UI brainstorming.
I hope these features to be included or merged into the master branch in some future.
So I inform you the patch here.
If you're interested in the patch, please discuss about it.

The patch is maintained by git, and published at following site. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=summary

This patch implement several features like: * horizontal toolbar with many tool options. (http://gimp-brainstorm.blogspot.com/2009/07/blog-post.html or http://gimp-brainstorm.blogspot.com/2009/07/gimpscape.html) * much sophisticated brush panel
(http://gimp-brainstorm.blogspot.com/2009/12/brush-panel.html) * dynamics editor with side tabs
(http://gimp-brainstorm.blogspot.com/2009/12/brush-dynamics-curves.html) * vertical dock and image tabs for single window mode. (http://gimp-brainstorm.blogspot.com/2010/10/vertical-menu.html) * dock folding features. I think this feature is necessary for single window mode.

This patch is based on the current master branch of the git://git.gnome.org/gimp.
It modified many source code of the existing codes, but it does not delete any features that is available in the master branch.

Thanks, --
sigetch.

Hi sigtech

That's some very interesting work and we should work on merging what makes sense to merge to GIMP git master. A word of warning though: not everything posted on the gimp-brainstorm blog is suitable to be actually implement in GIMP, so all your patches might not make sense to merge.

A couple of early comments on your code:

Add toolbar for tool-options to GimpImageWindow. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=13c321f2db36bae52b23d4264dee242827bb801c

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.

- G-Pen algorithm is ported into GIMP trunk. Now smoothing function works for Ink...
http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=070fc064271f0b359ccdc9ad06466eeb3c1bc3ed

Looks like something we might want, some paint tool hacker should look closer at it. Alexia? Mitch?

Initial import of color blending function for smudge tool. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=1b83ecae173641b0b08bccd0b207457bb549f9e6

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.

* Some parameters in the toolbar can be edited using popup editor. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=2d5edbfe2fbba08ab4cf456586d5344a3c3a49cc

If I understand your code correctly, you are replacing big widgets with smaller widgets that "expand" when you use them. Worth looking into further.

* GimpDock: GIMP dock column folding is implemented. http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=01c5590e9566d7f9f7fe2b8112e570a26cb3ac4c

Another interesting change, I'll look closer at it when I get back at hacking on single-window mode.

[various bug fixes and additions to earlier commits] For review purposes, it would be good if you squashed fixup-commits with commits they fix, so upstream reviewers just need to review one patch.

Best regards, Martin

On Tue, Jan 4, 2011 at 10:15 AM, Martin Nordholts wrote:

On 01/04/2011 08:25 AM, しげっち wrote:

- G-Pen algorithm is ported into GIMP trunk. Now smoothing function works for Ink...
http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=commitdiff;h=070fc064271f0b359ccdc9ad06466eeb3c1bc3ed

Looks like something we might want, some paint tool hacker should look closer at it. Alexia? Mitch?

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...

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.

hi しげっち,

I'm recently implementing a GUI features that is inspired by the ideas of the GIMP UI brainstorming.

you do realise that the brainstorm is a 'sandbox' for ideas?

the deal is that everything is OK within a brainstorm (so ideas keep flowing) but that is only _within_ the brainstorm.

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. sometimes these steps are necessarily heavyweight because of the complexities involved, sometimes as lightweight as 15 mins of thinking and an email or irc exchange. it depends...

for the patches you sent, only step 1 and 6 were done: 1 by the brainstorm participant and 6 by you. the steps in the middle are missing.
this is not criticism of you, most (99.9%) of the software world does not do and know any better than that.

but here at GIMP we do better. other folks here will be able to judge the quality of your code, but I can see your enthusiasm to work on UI issues that matter, and we have a backlog of that.

I am gathering resources at the moment to get more done for GIMP on the UI design side, we could use your enthusiasm to have more power on the development side.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

しげっち wrote:

I know that there was a discussion about the consumption of the vertical space of the toolbar once in the mailing list.

I also spent most of a talk at an lgm discussing this topic.

in the bigger scheme of things (space, how usable toolbars are) I do not see GIMP having a toolbar.

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.

==snip==

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.

nice try, but: no.

I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see:

so walking through steps 2–5 with me (or soon my team) is mandatory. yes, it is a 'UI maintainer' kind of thing.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

2011/1/5 peter sikking :

しげっち wrote:

I know that there was a discussion about the consumption of the vertical space of the toolbar once in the mailing list.

I also spent most of a talk at an lgm discussing this topic.

in the bigger scheme of things (space, how usable toolbars are) I do not see GIMP having a toolbar.

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.

==snip==

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.

nice try, but: no.

I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see:

Well, you don't permit the GIMP to have the toolbars even if it is OPTIONAL and it doesn't replace or overwrite any existing GUI policy ? I think it can be merged as an optional code, and safely ignore that feature in compile time of runtime switch.
(currently I don't implement any switches though.)

I think open source project can have several policy as a optional implementations,
and it can provide alternative way for users who has alternative demands. --
sigetch

sigetch (sigetch@gmail.com) wrote:

Well, you don't permit the GIMP to have the toolbars even if it is OPTIONAL and it doesn't replace or overwrite any existing GUI policy ?

Each and every optional thing is a burden. Even if disabled it clutters the preferences dialog, it makes inconsistent User-Interfaces across installations (think about "telephone support" where you first have to figure out how the user interface on the other side actually looks) and it has the potential of confusing users. So before adding a new option we need to make sure that it is really necessary.

I think it can be merged as an optional code, and safely ignore that feature in compile time of runtime switch.
(currently I don't implement any switches though.)

Compile-Time switches are a maintenance nightmare: If larger chunks of code are not compiled by default, the code quality tends to degrade with the time, since it does not automatically follow the rest of the code in the case of API changes etc.

So another burden, which - given our very limited development ressources - is not a good idea to have.

I think open source project can have several policy as a optional implementations, and it can provide alternative way for users who has alternative demands.

I don't get how "open source" maps to "several policys". Except maybe that one easily can fork an open source project, if the predominant policy feels wrong or unsuitable.

Which btw. you're free to do (although I'd consider this a bad idea).

I hope this helps, Simon

On 1/4/11, Simon Budig wrote:

I think it can be merged as an optional code, and safely ignore that feature
in compile time of runtime switch.
(currently I don't implement any switches though.)

Compile-Time switches are a maintenance nightmare: If larger chunks of code are not compiled by default, the code quality tends to degrade with the time, since it does not automatically follow the rest of the code in the case of API changes etc.

So another burden, which - given our very limited development ressources - is not a good idea to have.

Another problem is that every Linux distribution tends to make its own choice what features to compile and what not to compile. The thing is that if we go for compile-time switches, we *will* end up with different looking GIMPs all around which is something we could do without indeed :)

And there is also documentation burden which is rather self-explanatory.

In fact, I rather like Inkcape's horizontal tools options toolbar and I'd like to see both apps sharing UI solutions, but IMHO the new GIMP's text tool with its on-canvas options rendering beats the hor. toolbar hands down.

Alexandre Prokoudine http://libregraphicsworld.org

I know this has been beat to death before, but just wanted to say please never take away any of my precious real estate at the top and bottom of screens with a horizontal toolbar or anything else! The aspect ratio of screens have gotten so wide these days, I have plenty of extra room at the sides, but not at the top and bottom:)

Just my 2 cents.

Patrick

On 04.01.2011 17:00, peter sikking wrote:

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.

==snip==

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.

nice try, but: no.

I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see:

What is wrong about a high fidelity prototype? It is a central task of the usability engineering life cycle [Nielsen]. Adding it to master might be wrong but usertesting is not bad.

Improving Flexibility might help...

so walking through steps 2–5 with me (or soon my team) is mandatory. yes, it is a 'UI maintainer' kind of thing.

If you only do steps 2-6 you implement your mental model. Prototyping and user testing is not bad at all.

Just my two cents

regards Bernhard

Bernhard Guillon wrote:

I tried to show you why in my previous mail. I can only add that a developer plunking in a code change at users' request and then let users' feedback sort it out is the 'armpit of usability' (i.e. the worst possible). see:

What is wrong about a high fidelity prototype? It is a central task of the usability engineering life cycle [Nielsen]. Adding it to master might be wrong but usertesting is not bad.

well, see here for my take on proper integration of usability:

it is a very fitting post for our current thread: organisation, process, authority.

clarification: at the moment there is interaction design at GIMP but no usability as defined in the post (empirical testing). usability testing for GIMP is tricky, because it is a power tool that has to be mastered. Discussing this a while ago with Ellen Reitmayr (a fellow openUsabilty founder) it became clear that any UI innovation has to be prototyped, let a group of users train for a month with it, then perform tests focussing on ease (read: speed) of use.

Improving Flexibility might help...

I am not sure what you want to say with this.

so walking through steps 2–5 with me (or soon my team) is mandatory. yes, it is a 'UI maintainer' kind of thing.

If you only do steps 2-6 you implement your mental model. Prototyping and user testing is not bad at all.

so back to your argument:

1) there is no value in usability testing random ideas, as were implemented here. There are thousands of random ideas, with an infinite number of combinations. there is value in testing UI designs (step 2–5) to debug their concepts.

2) throwing out a prototype and getting some user feedback _is_ by definition the armpit of usability. proper testing is a whole other ball-game.

--ps

founder + principal interaction architect man + machine interface works

http://blog.mmiworks.net: on interaction architecture

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Can I add something?
You all may be right - discussing and checking UI changes are very very important and additional optional features are not the solution. And it makes sense to have one person (or a small group) that knows the way to go and keeps the overview. And on the other side, I can completely understand the TO - the current UI is definitely worth some polishing so he has invested some time and wants to get his stuff in. And on the first glance his fixes look very cool.

All fine to now, two controversial opinions that may be solved by some trade-off... But I still have to give some critique: I have experienced similar incidents quite a few times. Again, you may all be right and I understand your perspective. But if you want to get/keep contributors you want to consider *how* to stress your workflow. Please try some empathy: somebody invests a lot of time (and even more important does the step to actually start doing something) and is rejected with not too much thankfulness. Or at least it sounds like that. I know about some people that wanted to contribute but also gave up due to bad help and harsh conversation.
Sure, I understand that also you guys do it for free. My respect for this, truly. But it's only a small hint. Either you want GIMP going forwards then you should do everything to support it or you don't want it (what I don't think) then you also would not have to invest your precious time in the project.
You can have your opinion, your workflow, your casual how-to-deal-with-new-features. But before rejecting contributors one should thank and laud them. And emphasize that one likes the changes but before implementing them has to re-consider and double-check them. And maybe offer some help or time-limit for the check. Otherwise it sounds like "thanks, we keep it in some temp file and maybe we find it in some years again but at the moment, no chance". Lauding would be the way to go in order to keep people motivated and in a good mood spending more time on the project. Since years I read about complaints GIMP has only 2 or 3 full developers and releases delay and delay. This will definitely not change with sentences like "nice try, but: no."

You can ignore me if you think you should. I just had to try giving some explanations and in this way maybe helping the GIMP project. And again, I hold your work in high respect and am happy you do the stuff you do. That's no general criticism. It's only a little proposal how to do even better :)

Regards,
Mathias

On Wed, Jan 5, 2011 at 7:39 PM, peter sikking wrote:

so back to your argument:

1) there is no value in usability testing random ideas, as were implemented here. There are thousands of random ideas, with an infinite number of combinations. there is value in testing UI designs (step 2–5) to debug their concepts.

2) throwing out a prototype and getting some user feedback _is_ by definition the armpit of usability. proper testing is a whole other ball-game.

I see your opinion and I find that everyone like talking about GUI things :)

Actually I'm not so interested in the GUI, but only interested in improving the brush behavior like line smoothing and color blending feature that is currently released and maintained as a separate patch by the another member in our project, which is called GIMP-painter.

And actually GUI patch is only an option. I think toolbar is a good option though.
I need some good stuff that can be implemented quickly to improve my own brush testing operation, because current GUI has many problems and I can't find any prospective concept or prototype implemented in the master branch...

So if you all don't want to accept the toolbar, let's ignore them and discuss about the brush features.
--
sigetch.

Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

On Wednesday, January 05, 2011 19:42:28 sigetch wrote:

So if you all don't want to accept the toolbar, let's ignore them and discuss about the brush features.

Brush features are my domain sort of and theres a lot to merge there. It would be cool to have you on IRC for more immediate chat:) Your work is awesome :) I think the first thing Id like to see incorporated is smoothing, smudge dynamics fixes and fixes in general.

Mixingbrush is sort of a sticking point. We dont really want to add another non-gegl based paint tool in this iteration and in gegl paint core render engines could be pluggable...

As a question,have you looked into the new tool presets system?

Best, Alexia

Mathias Lindner (monoceros84@googlemail.com) wrote:

Can I add something?

Sure. :)

All fine to now, two controversial opinions that may be solved by some trade-off... But I still have to give some critique: I have experienced similar incidents quite a few times. Again, you may all be right and I understand your perspective. But if you want to get/keep contributors you want to consider *how* to stress your workflow. Please try some empathy: somebody invests a lot of time (and even more important does the step to actually start doing something) and is rejected with not too much thankfulness. Or at least it sounds like that. I know about some people that wanted to contribute but also gave up due to bad help and harsh conversation.

I understand your concerns and I do share them - at least partially. So with all clearness:

I do appreciate the effort from しげっち (I hope that comes out correctly... :) and I love the fact that he actually dived into the code and made this work. We get a lot of "why don't you? It is easy!" requests, and having some existing code is nice for a change.

Unfortunately we have a tendency to be a bit blunt in our wording and rejecting stuff - even for hopefully good reasons - is hard. It does have the advantage of being very clear, but yeah - it can put people off, which is something I hate.

Especially with regards to the UI we currently are in a tricky situation: On one hand the collaboration with Peter is very fruitful and we got some enthusiastic responses to the stuff that has been developed with his help. Since it is clear that a consistent UI does not happen with people developing on random bits in the UI we - in my opinion - need a person that coordinates the efforts in the UI, and that person is Peter. On the other hand, yes, this unfortunately creates a bottleneck (which scares me), but I don't see a good way around this.

So I really recommend to discuss stuff (on this list, in irc etc.) before investing lots of time into code, that might get rejected for the reasons mentioned above. This not only applies to GUI stuff, but to other functionality as well.

In my opinion the current Gimp source code is in a very good state and I tend to attribute this to strong maintainership and a reluctance to accept random patches. Yes, this is sometimes hard on new contributors (which we urgently need), but I don't think just opening the floodgates would be a good strategy here.

What currently is needed is some more work on the single-window mode. AFAIK there are some bugs in there and Martin (Enselic) can no longer dedicate as much of his time to it as he used to. It would be awesome if this work could be picked up and continued, I think a lot of the GUI issues have been worked out already and there is a spec for it at http://gui.gimp.org/index.php/Single-window_mode_specification .

Thanks, Simon

On 01/05/2011 07:19 PM, Simon Budig wrote:

What currently is needed is some more work on the single-window mode. AFAIK there are some bugs in there and Martin (Enselic) can no longer dedicate as much of his time to it as he used to. It would be awesome if this work could be picked up and continued,

That is not necessary, the reason I haven't hacked on GIMP the last two months is that I am working on a website which will allow people to easily track progress of GIMP development (or any project for that matter).

I expect to be back working on single-window mode in 1-3 months.

/ Martin

2011/1/5 Martin Nordholts

That is not necessary, the reason I haven't hacked on GIMP the last two months is that I am working on a website which will allow people to easily track progress of GIMP development (or any project for that matter).

I expect to be back working on single-window mode in 1-3 months.

What could be the implications on the date of the future release of version

2.8?

On Wednesday, January 05, 2011 19:42:28 sigetch wrote:

So if you all don't want to accept the toolbar, let's ignore them and discuss about the brush features.

I tried merging the smooth on top of the master yesterday. It works nicely, has a little bit of room for improvement(like makining the line catch up when you stop or finish the stroke) but when I started cleaning up the code... well, there are things in it that do not fit with gimp code standards at all. Like the circular queue thingy and the fact that it's a miniobject stuck into paint options object and its existence in general. The way it would need to be rewritten is adding a stroke array and its management functions into the paint core and then smoth from that. The smooth function also belongs in the paint core. And why does ink have its own circular buffer? whats wrong with using the paintcores one?

And to discuss all of this, Id like to see you in IRC :)

--Alexia

On 01/06/2011 08:32 AM, Olivier wrote:

2011/1/5 Martin Nordholts >

That is not necessary, the reason I haven't hacked on GIMP the last two months is that I am working on a website which will allow people to easily track progress of GIMP development (or any project for that matter).

I expect to be back working on single-window mode in 1-3 months.

What could be the implications on the date of the future release of version 2.8?

We want GIMP 2.8 out as soon as possible. Achieving that goal with be easier with a tool which will allow us to track progress of development, since problems can be spotted early, making them easier to resolve or mitigate. The effect on GIMP 2.8 development as well as future GIMP versions will be positive.

It will also be easier for external parties, for example book authors that tries to align book publishing with releases of new GIMP versions, to see if development is progressing as expected.

/ Martin

On 01/05/2011 07:09 AM, Mathias Lindner wrote:

... much good stuff elided by patrick ...

Thank you Mathias. I was also bothered by the tone and thought that it could drive away an obviously talented developer that is motivated to help.

Patrick

On Thu, Jan 6, 2011 at 4:51 PM, Alexia Death wrote:

On Wednesday, January 05, 2011 19:42:28 sigetch wrote: I tried merging the smooth on top of the master yesterday. It works nicely,

I'm very happy to hear that.

has a little bit of room for improvement(like makining the line catch up when you stop or finish the stroke)

I agree that improve of the stroke finishing process is very important.

the circular queue thingy and the fact that it's a miniobject stuck into paint options object and its existence in general. The way it would need to be
rewritten is adding a stroke array and its management functions into the paint core and then smoth from that. The smooth function also belongs in the paint core.

I simply imitate the gimp_paint_options_get_gradient_color(...), but paint core is better choice to implement that function.

And why does ink have its own circular buffer? whats wrong with using the paintcores one?

Well, simply by the historical reason. I implemented the smoothing of the ink tool first,
and then extend it to the brush core, while keeping the first one unchanged...

And to discuss all of this, Id like to see you in IRC :)

I'd like to do so, but unfortunately, I have very little spare time in this month, neither
in the next month... X(
--
sigetch.

hello every one!

The original Vision and the "what if"?---------------------------------------------------- I have seen the new changes based on UI brainstorm, and i have to say that is very good for testing to have the ability of test new UI changes like MrSigtech. has done. But i agree with main developers. Because UIbrainstorm is just like that. and i see that it will be a madness to test all ideas.It will be bad for coherence in UI terms to have infinite versions of Gimp with different UI design. I agree with the "phone support" idea.That is important for development and for teaching, tutorials, books and more things to come.

We can´t forget that gimp has a vision, a "good" or a "bad" vision ,it depends who is talking about it. But is an "Own" vision. all the painter stuff is against this original vision, But could this change for a new open vision? i thing that is possible. and good for both audiences, photographers and illustrators,.I know we are very very different fields but this could be very good to improve our knowledge of gimp.

Nowadays we have things like David Revoy´s (sintel Art director) DVD "Chaos and evolutions"
that shows gimp paint potential using gimp painter and a personal brushkit that is completely free to download. Also we have GimpPaintStudio with lot of presets and people that is start to using it regularly due his features. and Gimp Painter is still in progress adding new features like mixbrush, g-pen, smoothing,minscale,power...

All this means that there is a good audience, and lot of interest on have a good painting features in gimp,althoug there is no painting purposes on the original vision.althoug we have mypaint and krita, we want, we would like to have this painting power on our loved gimp.

Colaboration between the actual resources.---------------------------------------------- So i have to thank a lot all the people working hard in provide GIMP. coders,web-designers,and original creators.Gimp is now really good ,but will be impressive if we open our mind and see what happens. GimpPaint Studio supports gimppainter use and even more in the 1.5 release where we are using more the "texture" feature of the mixbrush.something that is not possible on the original Gimp by now.
My personal thought is that it will be better to work all together, in the same direction like a team.Sigtech and his Gimppainter team coding working in combination with Alexia and the gimp team, all supervised by guiguru.Sigtech and his team is an amazing resource, and we have to use it properly, giving him help and encouragement. he alreaday have done a good job with gimp painter, but imagine what he could do with more time a bit of support,and more coders.
if Enselic is not available for a time, well, let´s him relax :D .meanwhile, Gimpaintstudio will be still developing new ways to use tools, spreading the gimp use all over the world by videotutorials, wiki, etc.

Young Blood and future.------------------------------------------------------------------- But i want to say something that maybe it will not sound so good.Roughness is not good, and it is absurd be rude when we all are in the same team,trying to help.And we have to think that we work by internet and "irc" can be cold missing the "tone" of the words.and also english is not always our language so it is more difficult to explain some things or even our thoughts.
And if we want to get some new coders or people interested on invert his spare time on gimp development, we have to make the idea more atractive, by kindness, communication, and maybe more social network pressence. To make some videos showing the good capabilities of gimp.. .in other words, marketing to sell the Idea "gimp is good ,powerful and fun." wich is true but unfortunately not so well known.

this is mi honest opninion

2011/1/4 しげっち

Hi, all.
I'm recently implementing a GUI features that is inspired by the ideas of the GIMP UI brainstorming.
I hope these features to be included or merged into the master branch in some future.
So I inform you the patch here.
If you're interested in the patch, please discuss about it.

The patch is maintained by git, and published at following site.

http://git.sourceforge.jp/view?p=gimp-painter/gimp-painter-2.7.git;a=summary

This patch implement several features like: * horizontal toolbar with many tool options. (http://gimp-brainstorm.blogspot.com/2009/07/blog-post.html or http://gimp-brainstorm.blogspot.com/2009/07/gimpscape.html) * much sophisticated brush panel
(http://gimp-brainstorm.blogspot.com/2009/12/brush-panel.html) * dynamics editor with side tabs
(http://gimp-brainstorm.blogspot.com/2009/12/brush-dynamics-curves.html) * vertical dock and image tabs for single window mode. (http://gimp-brainstorm.blogspot.com/2010/10/vertical-menu.html) * dock folding features. I think this feature is necessary for single window mode.

and some of the brush enhancement options which idea is imported from GIMP-painter- patch:
* line smoothing (currently called G-Pen patch.) * color blending features and brush dynamics transformations for smudge tools (very resembles for Mixbrush patch.)

You can see the screenshot at following site. http://picasaweb.google.com/sigetch/GIMPScreenshots#5558220202681944994

This patch is based on the current master branch of the git://git.gnome.org/gimp.
It modified many source code of the existing codes, but it does not delete any features that is available in the master branch.

Thanks, --
sigetch.
_______________________________________________ Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer