Thorsten wrote: >> <http://www.mmiworks.net/eng/publications/2007/05/lgm-top-gimp-user- >> requests_25.html> > > On 4. better painting tools: > > So you propose to have brush models in tools like dodge/burn. > Why would this be preferable to having modes like dodge/burn inside > brush tools? because dodge/burn matches users' goal as a primary selector, and because within that certain task (brighten/darken) the image content dictates which brush model work best in a certain part. So main mode = dodge/burn, sub-mode = switch through the brush models fits that best. > Maybe brush model and mode should be handled separately? > > A: The region/scope to work on > - whole image > - a layer/group/set > - a selection > - brush strokes as they happen > B: Options for above > - mainly brush model with parameters comes to mind > C: The action or drawing mode to apply > - transformations > - filters > - paint the whole puzzle is about decomposing ortogonal modes, and then flattening these multidimensional tool spaces again. Our only guide can be here the graphics concepts our product vision users think in. > On power modes > > Sounds like a rather vague distinction, makes me wonder if > is such a good idea to split the modes based on it. > Shouldn't layer and paint modes be kept the same? Not necessary to keep both the same. With the brush tools you have this opportunity to take out the modes with natural descriptions (vs. mathematical) and make unhide it out of these modes and integrate into an existing or new brush tool, that matches a user goal directly. no such chance for layer modes. > dipping and smearing > > Considering GIMP is not and shall not be painter ... but this would > be very nice especially for drawing from scratch ;) fine with me. but you can see how this solution came about, straight from the product vision, via the user scenarios. > Regarding adjustment layers and GEGL > > GEGL is graph based, somewhat comparable to the nodes in Blender, > right? If so, the concept of a layer stack does not match GEGL. > I would propose to go all nodes and have no layers, if the layer > stack wouldn't match the common case so nicely. I was very happy when I reached a consensus with pippin and mitch on hat the GEGL graph is an internal technical representation that is not exposed in the UI. Maybe, only, to the developing users who use GIMP as stated in the third point of the product vision: "GIMP is a platform for programming cutting-edge image processing algorithms, by scientists and artists;" So yes, the graph is more flexible than a image->layers->operation history structure. But I am convinced that the latter will help users more in getting the job done. > On window management > > I have been thinking: What if GIMP was represented by a window with > just the main menu. Image windows could be dockable palettes. Requires > docking side-by-side. For SDI style, one would dock one image window > and the inspectors all to the main window. Several images could docked > together to have tabs. Although I will have to push the boundaries of the look + feel guidelines every once and a while, I do prefer to stay 90% within the law. It does not hurt to go far out for an hour, but after applying some sane laws like "the menu bar sits at the top of the main window, on linux and windows," I am mostly back where I am in the last blog entry. --ps principal user interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
