[Bf-funboard] Modes & modes

[Thorsten Wilms]

On Fri, Sep 12, 2003 at 03:04:45PM +0200, Ton Roosendaal wrote:
>
> ...
>
> We can copy this definition... but for clear communication about our UI  
> project I prefer to use the word 'blocking' in this context, to avoid  
> confusement with all other modes below.
> A dialog like 'Nkey' (numerical input) then is 'blocking', the  
> MaterialButtons are 'non-blocking'.

Blocking: very clear language!
 
> 2)
> Also we should agree that the UI (or GUI) in Blender is not limited to  
> menus, buttons or dialogs. Even a 3d wireframe Object is a UI element.

An important thing to keep in mind!

> ...
> 
> If you prefer, we can also refer to these modes as 'state modes'. Then  
> we know absolutely sure what is mentioned here.
> A discussion about new 'selection modes' then is an evaluation whether  
> to keep it "nonmodal" (ALT+CTRL+click) or add a 'state mode' (set  
> option to change by default clicks).

A mode is a user-interface state (or part of a state). So state mode is doubled. 
But when a mode or state must be explicitly turned off / left, then we could call 
it persistent or sticky. In contrast to temporary or maybe closed modes.

>... 
> 3)
> For tools we get a bit into trouble for a simple definition. Tools  
> itself are not really 'UI' elements, but are made available through it.

Tools are UI modes. One could talk about the _scope_ of a mode, what part of 
the interface is affected, which gestures change meaning. You could say that gestures not 
handled by the actual mode are bypassed to the parent mode or general mode (Or at least 
they should be).
 

> Also, technically there's not much difference between:
> 
> - mousebutton press & hold -> move mouse -> release mousebutton
> or
> - press Gkey -> move mouse -> press SpaceBar
> 
> Both methods (can) have an internal 'while' loop with a clear beginning  
> and ending. However, my decision to prefer the latter method in Blender  
> is mostly (*) out of practical experience, defining the optimal  
> least-strained & quickest method. I really prefer to limit  
> click-hold-dragging, for it's one of the main causes of mouse fatigue.

Thank you very much for thinking about mouse-fatigue and avoiding click-hold-dragging!
Blender seems to be rather easy on my hands (have some problems and already change 
between left and right handed mouse-usage).

> ...
> 
> However, internally the GKey tool again is a temporal mode in itself,  
> changing gesture behaviour for input. This in contrary to - for example  
> - middlemouse view transformations in Blender.

Jeff Raskin uses the term quasimode for modes that work while a key is depressed. So in 
a way middle-click-hold establishes a mode for mouse-movement.

> ...
> 
> Also difficult is to classify tools like 'Subdivide' or 'EdgeLoop  
> Select', because they are available only within the context of a mode.  

Submode!? One can also talk about preconditions for a mode.


> However, when the tool is consistantly available it still makes it a  
> non-modal tool.

You mean the availability is non-modal!?

> - nonmodal tool
> A tool consitantly available
> (example: middle mouse view rotate, screen-edge dragging, Y-key split)

A true nonmodal tool has to be single command so you don't change interface state (have 
0 interaction runtime with respect to the one command). The other thing is nonmodal 
availability.

But if you consider pressing B and click-dragging to be _one_ gesture, than 
border-select is nonmodal. (Personaly I think about it beeing a 2 part action: enter a 
tool-mode and use it!)

> - 'nonmodal tool-mode' or 'temporal tool-mode'
> A tool which temporally changes gesture meaning, but intuitively  
> returns to normal
> (example: grabber)
>...

Raskin uses _temporary_ mode. A nonmodal (tool-) mode sounds like hot, black snow or 
something like that.


So we now have:

- modality of availabilty (preconditions and parent-modes)
- modality in usage

- persistent / sticky or temporary / closed modes
- connected to the above: the way a mode is entered and left / turned on and off

- the scope of a mode (which parts of the interface / gestures are affected)

- mode hierarchy: general mode, submodes, gesture/event passing


Hope to not have taken this to far and you find it helpfull!

---
Thorsten