> 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
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.
principal user interaction architect
man + machine interface works
http://mmiworks.net/blog : on interaction architecture
Gimp-developer mailing list