Difference between pages "LGM single window interface" and "LGM layer trees or layer groups"
From GIMP GUI Redesign
(Difference between pages)
| Line 1: | Line 1: | ||
go back to [[Lgm| LGM issues]] | go back to [[Lgm| LGM issues]] | ||
| − | + | ==our point== | |
| + | * introduce layer groups | ||
| + | * introduce layer sets | ||
| + | * introduce version control | ||
| − | == | + | ==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 | |
| − | + | * there is need to introduce layer groups | |
| + | * there is need to introduce layer sets | ||
| + | * there is need to introduce version control (GEGL helps) | ||
| − | == | + | ====Raw notes that concern the issue more or less.==== |
| − | |||
| − | == | + | ===Layers=== |
| − | # | + | # User doesn’t have to do the bookkeeping of layer dimensions, a layer can grow and shrink as needed. |
| − | # | + | # Layer name should be a default name (layer 12). Double clicking on a layer is fine to rename it , no dialog needed. |
| − | + | # There should be a default transparent filling of a layer (we should enforce the concept of a layer as a transparent slide, plastic) | |
| − | + | # This all leads to the higher goal: get rid of the new layer dialog. | |
| − | # | ||
| − | # | ||
| − | == | + | ===Comparing different approaches=== |
| − | + | #to support this (trying two or more artistic strategies), we need to introduce a very simple versioning system, with branching. | |
| + | #‘tree of versions’ -each of them would have a stack of layers, which has a stack of treatments. | ||
| + | #Saving a point in time would mean labelling it. Labelling the versions, changing the names 1.0,1.1,1.2… | ||
| + | #Branches – the structure should support moving the layers between versions. | ||
| + | #Side by side comparison by choosing different versions. | ||
| + | #Merging two versions: to be discussed later. | ||
| − | == | + | ===Active/inactive layer=== |
| − | + | 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. | |
| − | # | + | |
| − | # | + | ===Virtual layer folders=== |
| − | # | + | #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. |
| + | #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. | ||
| + | #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. | ||
| + | |||
| + | ==Fragments of Analysis== | ||
| + | ===layers=== | ||
| + | * 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 09:15, 25 April 2007
go back to LGM issues
Contents
our point
- introduce layer groups
- introduce layer sets
- introduce version control
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
- there is need to introduce layer groups
- there is need to introduce layer sets
- there is need to introduce version control (GEGL helps)
Raw notes that concern the issue more or less.
Layers
- User doesn’t have to do the bookkeeping of layer dimensions, a layer can grow and shrink as needed.
- Layer name should be a default name (layer 12). Double clicking on a layer is fine to rename it , no dialog needed.
- There should be a default transparent filling of a layer (we should enforce the concept of a layer as a transparent slide, plastic)
- This all leads to the higher goal: get rid of the new layer dialog.
Comparing different approaches
- to support this (trying two or more artistic strategies), we need to introduce a very simple versioning system, with branching.
- ‘tree of versions’ -each of them would have a stack of layers, which has a stack of treatments.
- Saving a point in time would mean labelling it. Labelling the versions, changing the names 1.0,1.1,1.2…
- Branches – the structure should support moving the layers between versions.
- Side by side comparison by choosing different versions.
- Merging two versions: to be discussed later.
Active/inactive layer
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.
Virtual layer folders
- 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.
- 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.
- 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.
Fragments of Analysis
layers
- 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;
