Re: [Gimp-developer] Icon for dynamics
Making good default icon is important. But please remember that it is more important to allow users define their own custom icons for each dynamics separately (like icons of the brush resourse in MyPaint.) Users make their own dynamics and distinguish them by its icons. 2011/02/04 7:24 Sven Neumann s...@gimp.org: ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On Thu, Jan 6, 2011 at 4:51 PM, Alexia Death alexiade...@gmail.com 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
On Wed, Jan 5, 2011 at 7:39 PM, peter sikking pe...@mmiworks.net 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
Re: [Gimp-developer] GUI enhancement patch from GIMP UI brainstorm blog
2011/1/5 peter sikking pe...@mmiworks.net: しげっち 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 pe...@mmiworks.net: 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: http://blog.mmiworks.net/2008/09/armpit-of-usability_20.html 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
