Difference between pages "LGM layer trees or layer groups" and "LGM painting tools"

From GIMP GUI Redesign
(Difference between pages)
Jump to: navigation, search
 
 
Line 2: Line 2:
  
 
==our point==
 
==our point==
−
* introduce layer groups
 
−
* introduce layer sets
 
−
* introduce version control
 
  
 
==argumentation chain==
 
==argumentation chain==
  
−
* in the user observation we saw the need for layer grouping, on a physical and logical level, and we saw that in PS layer groups are used to manage versions of a file
+
 
−
* in the evaluation we found the system for controlling layers (visibility, locking, selecting to work on) to be not complete and not straightforward enough when used in anger; too much thinking involved
 
−
* there is a requirement to introduce layer groups
 
−
* there is a requirement to introduce layer sets
 
−
* complete and simplify the layer controlling functionality (locking)
 
−
* from the scenario original art: compare different approaches
 
−
* there is a requirement to introduce version control (GEGL helps) warning: this should be very simple, no developers power functions
 
  
 
====Raw notes that concern the issue more or less.====
 
====Raw notes that concern the issue more or less.====
  
−
===Layers===
+
===Adding noise ===
−
# User doesn’t have to do the bookkeeping of layer dimensions, a layer can grow and shrink as needed.
+
There could be possibility to use brush for noise adjustments.  
−
# Layer name should be a default name (layer 12). Double clicking on a layer is fine to rename it , no dialog needed.
+
=== IWarp===
−
# There should be a default transparent filling of a layer (we should enforce the concept of a layer as a transparent slide, plastic)
+
should be done with a tool.
−
# This all leads to the higher goal: get rid of the new layer dialog.
 
  
−
===Comparing different approaches===
+
===Brushes===
−
#to support this (trying two or more artistic strategies), we need to introduce a very simple versioning system, with branching.
+
#users want to adjust their brushes on the fly, just by pressing keys, user should be able to change the parameters.
−
#‘tree of versions’ -each of them would have a stack of layers, which has a stack of treatments.
+
#Brushes need shortcut for: color picker, opacity (not sure about the steps, that should be applied- it should be measured with usability methods), radius/size of brush.
−
#Saving a point in time would mean labelling it. Labelling the versions, changing the names 1.0,1.1,1.2…
+
#User could also ‘cycle’ through all 4 main paint 'modes' (airbrush, ink, pencil, brush). But opacity and scale of the brush has the absolute priority.
−
#Branches – the structure should support moving the layers between versions.
+
#It is important that for these 2 comments that the user would keep his hand on the keyboard in the same position.
−
#Side by side comparison by choosing different versions.
+
#When changing paint modes we need to think whether to take care about the continuity of the size/opacity, or not, because the second tool might be a complementary tool.
−
#Merging two versions: to be discussed later.
 
  
−
===Active/inactive layer===
+
==Fragments of Analysis==
−
We are concerned by the fact that there are often mistakes caused by independence of what you see, and what is an active layer. Is painting on invisible layer a good idea? It would be useful if after clicking on invisible layer in the stack, it would become visible.
+
===the brush tools===
  
−
===Virtual layer folders===
+
* make the four main brush modes (airbrush, nib, pencil, paintbrush) sub-modes of every type of brush tool, not just of color painting;
−
#Idea:There could be virtual folders, that would group physical layers, in aim to allow easier comparing, or switching on/off visibility. But that has to be done in a very easy way.
+
* create the opportunity to move  the four main brush modes to be more algorithm based for further refinement. Bitmaps for brush shapes will play a more secondary role (for special jobs) in the future;
−
#Physical folders can be arranged in a vertical way, going top to bottom. But to the right there would be stack of text boxes and stack of SVG on a single layer.
+
* complete the palette of type of adjustments that can be made with a brush:
−
#The virtual folders could be at the top and would be arranged from top to right. And you could just drag in and out the layers for creating virtual folders. Or instead of dragging user could just click OK to create virtual layer folder from visible layer. Two options might be available-new layer group, or new group from visible layer.
+
** saturation
 +
** distortion
 +
* merge cloning and healing;
 +
* take a less generic approach for what options are available for a certain brush type;
 +
* discuss the historic significance of the modes parameter, and its future;
 +
* introduce a way of painting with the effects of plugins. Probably via the blobs-of-paint concept;
 +
* review of the shortcut actions to change brush parameters.
  
−
==Fragments of Analysis==
+
====other points====
−
===layers===
+
* it should be possible to apply unsharp mask with 4 basic brushes (sharpen tool)
−
* the overriding design principle here is that the whole concept of layers can be explained with one sentence: ‘layers are just transparent sheets, stacked to form the image’;
 
−
* adjustment layers are a hijack of the layers concept that was needed in the 1990s to get things done and to be re-adjustable later on; with GEGl there is no need for it anymore, and GIMP can miss like a toothache: the complication, the unnatural way of working and the fact that the guiding principle above goes to hell;
 
−
* layer modes: we understand the power, but there is also something horribly wrong with it; the best a user can do is scroll through the list of modes and see what happens, and that is not being in control of your tool; any workflow that includes a layer mode for rather straightforward goals indicates an interaction problem we have to solve;
 
−
* grouping of consecutive layers: we support it; we see for groups of groups an interface display problem, the indenting for a level should not eat too much horizontal space;
 

Revision as of 08:59, 25 April 2007

go back to LGM issues

our point

argumentation chain

Raw notes that concern the issue more or less.

Adding noise

There could be possibility to use brush for noise adjustments.

IWarp

should be done with a tool.

Brushes

  1. users want to adjust their brushes on the fly, just by pressing keys, user should be able to change the parameters.
  2. Brushes need shortcut for: color picker, opacity (not sure about the steps, that should be applied- it should be measured with usability methods), radius/size of brush.
  3. User could also ‘cycle’ through all 4 main paint 'modes' (airbrush, ink, pencil, brush). But opacity and scale of the brush has the absolute priority.
  4. It is important that for these 2 comments that the user would keep his hand on the keyboard in the same position.
  5. When changing paint modes we need to think whether to take care about the continuity of the size/opacity, or not, because the second tool might be a complementary tool.

Fragments of Analysis

the brush tools

  • make the four main brush modes (airbrush, nib, pencil, paintbrush) sub-modes of every type of brush tool, not just of color painting;
  • create the opportunity to move the four main brush modes to be more algorithm based for further refinement. Bitmaps for brush shapes will play a more secondary role (for special jobs) in the future;
  • complete the palette of type of adjustments that can be made with a brush:
    • saturation
    • distortion
  • merge cloning and healing;
  • take a less generic approach for what options are available for a certain brush type;
  • discuss the historic significance of the modes parameter, and its future;
  • introduce a way of painting with the effects of plugins. Probably via the blobs-of-paint concept;
  • review of the shortcut actions to change brush parameters.

other points

  • it should be possible to apply unsharp mask with 4 basic brushes (sharpen tool)
Retrieved from "https://gui.gimp.org/index.php?title=LGM_layer_trees_or_layer_groups&oldid=292"