Difference between revisions of "Work in progress"

From GIMP GUI Redesign
Jump to: navigation, search
(Vision)
(4 intermediate revisions by 3 users not shown)
Line 1: Line 1:
==Text in GIMP==
+
== Tool options widgets ==
  
=== towards solution models ===
+
All UI elements are built from a few basic UI building blocks called widgets. A list with images of all current available GTK+ 2 widgets can be found at [http://developer.gnome.org/gtk/2.24/ch02.html] and their respective GTK+ 3 counterparts at [http://developer.gnome.org/gtk3/3.4/ch03.html]. Since GIMP has special needs it also has quite a few widgets of it's own, a number of them (the external accessible ones) can be found at [http://developer.gimp.org/api/2.0/libgimpwidgets/libgimpwidgets-gallery.html].
 +
GIMP also has a number of additional internally used widgets, quite a few just extend basic GTK+ widget for specific needs, without altering the visual look and feel. However, there are also completely new widgets for specific needs like those used for pressure curves or the gimpspinscale a mix of a spin and scale button that can be found in a lot of tool options. A third category are ''meta'' widgets that mix together a few basic widgets in a certain fashion for a particular purpose, an example is the gimpscaleentry which consists of a label, scale slider and spinbutton (look at Tools->Color Tools->Brightness-Contrast menu).
 +
An exhaustive list is unneeded as most tooloptions only use a rather basic subset of aforementioned widgets, the following table is a list of those common widgets used in tool options and their GIMP counterparts.
  
overview of text in GIMP:
 
[[Image:Text_packs.jpg]]
 
  
==== Grouping of task packages ====
+
{| class="wikitable"
 
+
|+ List of widgets
'''IN'''
+
|-  
 
+
! GTK+
* typography aka in-text-layouting
+
! GIMP
** character and paragraph level
 
** preset functionality and behavior
 
** ''OpenType implementation may need to be postponed''
 
** ''lots of functions -> much screen space''
 
** ''toolbox space?''
 
 
 
* editing modes
 
** editor, on canvas, HUD
 
** level of abstraction
 
** availability and placement of functions
 
** switching between modes
 
 
 
* basic shape
 
** non-shape, rectangle
 
** creation
 
** modification
 
 
 
* text in 2D-space
 
** needs logical specification
 
** needs ui implementation, how to make the two tools work together
 
** ''dependencies: vector tool, GEGL (for non-destructiveness)''
 
** ''minor number of functions inside text tool. most adjustment is done in vector tool''
 
 
 
 
 
'''OUT'''
 
 
 
*annotations
 
** differ in many dimensions to usual text:
 
*** need to be turned on and off quickly
 
*** have no need for most of the formatting options
 
*** searchable?
 
** = are better managed by its own system
 
 
 
*complex shape/vector management
 
** creation and modification of complex shapes and paths is exactly what the new vector tool is made for
 
** doubling it in the text-tool…
 
*** …overloads the text tool
 
*** …uses space and control used for text-specific work
 
** with GEGL a "link" between text-object and the shape should do the job
 
** = should be done in vector tool: unified approach
 
 
 
*text effects
 
** drop shadow etc. are not unique to text
 
** useful for different sorts of objects (vectors)
 
** workflow is "select object" - "apply effect", no matter if it is special to text or a global effect
 
** = unified approach suits it better
 
 
 
==== starting points ====
 
 
 
{| border="1" cellpadding="5" cellspacing="0"
 
!
 
!text (no container)
 
!fixed basic (rectangular) shape
 
!fixed (any) vector shape
 
|-
 
|'''aims/scenarios'''
 
|click'n'type
 
 
 
workflow
 
 
 
text centered
 
 
 
small amounts of text
 
 
 
non-strict layouting
 
 
 
area/shape is not an object as itself
 
|layout centered = placement control
 
 
 
prevent/control intereference with other objects on canvas (boundaries)
 
 
 
use box as a shape (the box itself is s.th.)
 
 
 
justification
 
 
 
 
 
|generally broad variety of aims
 
 
 
free art vs. exact layouting
 
 
 
interaction with rest of canvas
 
 
 
|-
 
|'''definition'''
 
| one corner  is defined (e.g. its coordinates)
 
| all four sides are defined.
 
 
 
when reaching the right side, text is wrapped
 
 
 
when reaching the lower side, text runs out of the box and is visually clipped
 
| same as in fixed basic shape
 
 
|-
 
|-
|'''creating'''
+
| GtkLabel
|click + enter text,
 
sets start point of baseline
 
 
 
resulting "shape" is always rectangular
 
| click + drag
 
 
 
? convert rectangular vector shape + enter text?
 
 
|
 
|
* create text shape vector specifically for it
 
* use existing vector
 
** copy it -> text shape vector
 
** clone it -> text shape vector that reflects changes on vector of origin
 
 
 
|-
 
|-
|'''modifying'''
+
| GtkComboBox
|resize -> becomes fixed shape
+
| Gimp{Int,Unit,Sttring,ColorProfile,Enum}ComboBox
 
 
in-text layouting might modify shape
 
 
 
''rotate''
 
*text only (changes box anyways)
 
 
 
move
 
 
 
stroke/fill
 
 
 
convert to fixed shape
 
 
 
convert to vector shape
 
 
 
| resize shape (alters line breaks)
 
 
 
''rotate''
 
*text only
 
*shape only (changes to vector shape mode)
 
*text + shape (changes to vector shape mode)
 
move
 
 
 
stroke/fill
 
 
 
convert to dynamic shape
 
 
 
convert to vector shape
 
 
 
| resize shape (alters line breaks)
 
 
 
node manipulation (alters line breaks)
 
 
 
''rotate''
 
*text only
 
*shape only
 
*text + shape
 
 
 
move
 
 
 
any other transformation applicable to vectors
 
 
 
stroke/fill
 
 
 
conversion to dynamic shape (e.g. unbind from vector)
 
 
 
not possible to make basic shape
 
 
 
|}
 
 
 
 
 
two subcases of the dynamic and fixed basic shape are missing from this analysis.
 
 
 
* a fixed basic shape, that does not clip: lines over the bottom of the box are not clipped. Rather, the box is extended.
 
** workaround: this can easily be achieved by vertically resizing the box
 
* a fixed basic shape, that does not wrap: text runs out of the right side of the box, but is invisible outside the box. only manual line breaks cause new lines. However it is clipped at the bottom of the box
 
** workaround: if wrapping is a property of text on a paragraph level (by default set to positive), this can be turned off. In combination with a fixed shape it allows for a replication of above case.
 
 
 
conclusion: these special cases can be replicated with existing means. A native implementation would complicate the system too much and is much less appealing than the simplicity of the current implementation.
 
 
 
==== misc ====
 
 
 
==Path tool==
 
 
 
table 1
 
 
 
{| border="1" cellpadding="5" cellspacing="0"
 
!object/ operation
 
!end node
 
!multiple nodes
 
!in-between node
 
!segment
 
!component (sub-path)
 
!path
 
|-
 
|add
 
|create single end node or extend new segment 
 
|
 
|divide a segment (create 2 new segments instead of the old segment)
 
|
 
|
 
| √
 
 
|-
 
|-
|move
+
| GtkButton
|
+
| Gimp{,Chain,Pick,Color}Button
| √
 
| √
 
|
 
| √
 
| √ (multiple paths by linking)
 
 
|-
 
|-
|delete
+
| GtkSpinButton
|delete segment
+
| GimpSpinScale
|delete segments (component is not broken)
 
|delete 2 segments, create new segment (non polygonal)
 
|√
 
|
 
|  
 
 
|-
 
|-
|adjust
+
| GtkExpander
|
 
|
 
|
 
| √ (symmetrical handles possible)
 
|
 
 
|
 
|
 
|-
 
|-
|join
+
| GtkEntry
|close component/path or join components --> create new segment
 
|
 
|
 
|
 
|
 
 
|
 
|
 
|-
 
|-
|merge
+
| GtkToggleButton
 
|
 
|
|
 
|
 
|
 
|
 
|merge visible paths - no segments added
 
|}
 
 
 
table 2
 
{| border="1" cellpadding="5" cellspacing="0"
 
!object/ operation
 
!end node
 
!multiple nodes
 
!in-between node
 
!segment
 
!component (sub-path)
 
!path
 
 
|-
 
|-
|stroke
+
| GtkScale
|
 
|
 
|
 
|
 
|
 
|√
 
 
|-
 
|-
|create from Selection
+
| GtkRadioButton
|
 
|
 
|
 
|
 
|
 
|√
 
|-
 
|convert into Selection
 
|
 
|
 
|
 
|
 
 
|
 
|
|replace, Add to, Subtract, or Intersect with current Selection -->close path
 
 
|}
 
|}
  
  
===Shortcuts ===
+
=== Vision ===
*add end node + adjust segment (polygonal/non-polygonal control)
 
*add in-between node + adjust 2 segments
 
 
 
==present UI solutions==
 
 
 
====end node====
 
* '''add end node (extend a component)'''- activate end node of the component +click
 
It has to be more clear for the user to know if the new end node will expand the component, or start a new component?
 
* '''add end node (start new component)''' – Shift +click
 
Could it be done in a different way? For ex. deselecting active end node + click
 
 
 
*There should be just one handle visible when adjusting the end node.
 
 
 
* '''move node''' – select point and drag (triggers visible handles)
 
Handles should not bother user when moving, but should stay visible when finished, for adjusting a segment.
 
*Handles are difficult to access when the end of the handle is next to the node (so when the segments are almost polygonal). Length of the handles for polygonal shapes can be minimum, not zero. Size of the handles should be discussed, too.
 
 
 
* '''delete node''' - Shift+ CTRL + click
 
*''' join end nodes''' – select 1st end node, Ctrl + 2nd end node
 
Could it be done without Ctrl key? You could say GIMP what the segment should it be (polygonal or non polygonal)
 
 
 
 
 
====multiple nodes====
 
*'''move multiple nodes''' 
 
Is there a need to make it possible to move multiple nodes?
 
*'''delete multiple nodes''' – Shift select + Delete
 
This could be done by rectangular selection (drag from right -deletes nodes in selection area; drag from left– deletes all nodes of the path, that is fully in the selection area) + maybe hotkeys to chose – break component or not.
 
 
 
====in-between node====
 
*'''add in-between node–''' Ctrl + click on segment
 
Could it be possible to just click, and keep click+drag for adjusting the segment?
 
 
 
====segment====
 
*'''delete segment''' – Ctrl+ Shift click
 
*'''adjust segment''' – drag segment or adjust handles (activating node triggers visible handles)
 
 
 
====component====
 
*'''move component''' – Shift select multiple nodes + Alt
 
 
 
====path====
 
*'''add path'''- by path dialog
 
*'''move path'''-  Ctrl+Alt move canvas (not the component)
 
*'''merge paths'''- by path dialog- merge visible paths
 
*convert to selection, create from selection, duplicate– by path dialog
 
*'''stroke''' – by path dialog + stroke path dialog window
 
 
 
====general issues====
 
*handles - going out from the canvas-  are not accessible
 
Maybe we could change the scaling, etc.
 
  
====other enhancements====
+
Tools in GIMP enable hands-on manipulation of the compostion, direct on the canvas.
*no possibility to set a 2nd node in a position to make the segment horizontal or vertical
 
*selecting multiple nodes/components for deleting, moving etc.
 
*it’s important to deliver easy zoom in/out
 
  
 +
The tool options enable the fine and precise configurations that make the tool fit the job.
  
==sketches ==
+
Configuring tool parameters can happen anywhere from; almost continuously during a work session - to once in a user's lifetime.
  
[[Image:path01.jpg]],
+
Changing tool set-ups will never break user’s workflows.
  
 
==previously…==
 
==previously…==
 
* [[work in progress on text]]
 
* [[work in progress on text]]
 
* [[work in progress on paths]]
 
* [[work in progress on paths]]

Revision as of 15:12, 15 May 2012

Tool options widgets

All UI elements are built from a few basic UI building blocks called widgets. A list with images of all current available GTK+ 2 widgets can be found at [1] and their respective GTK+ 3 counterparts at [2]. Since GIMP has special needs it also has quite a few widgets of it's own, a number of them (the external accessible ones) can be found at [3]. GIMP also has a number of additional internally used widgets, quite a few just extend basic GTK+ widget for specific needs, without altering the visual look and feel. However, there are also completely new widgets for specific needs like those used for pressure curves or the gimpspinscale a mix of a spin and scale button that can be found in a lot of tool options. A third category are meta widgets that mix together a few basic widgets in a certain fashion for a particular purpose, an example is the gimpscaleentry which consists of a label, scale slider and spinbutton (look at Tools->Color Tools->Brightness-Contrast menu). An exhaustive list is unneeded as most tooloptions only use a rather basic subset of aforementioned widgets, the following table is a list of those common widgets used in tool options and their GIMP counterparts.


List of widgets
GTK+ GIMP
GtkLabel
GtkComboBox Gimp{Int,Unit,Sttring,ColorProfile,Enum}ComboBox
GtkButton Gimp{,Chain,Pick,Color}Button
GtkSpinButton GimpSpinScale
GtkExpander
GtkEntry
GtkToggleButton
GtkScale
GtkRadioButton


Vision

Tools in GIMP enable hands-on manipulation of the compostion, direct on the canvas.

The tool options enable the fine and precise configurations that make the tool fit the job.

Configuring tool parameters can happen anywhere from; almost continuously during a work session - to once in a user's lifetime.

Changing tool set-ups will never break user’s workflows.

previously…