[Bf-funboard] Modes & modes

[Ton Roosendaal]

Hi,

(long text, conclusion in the end if you like to skip!)

OK! For clear communication on Blender UI stuff we should have the  
right definitions.

1)
First, googling for the term 'modal' and 'nonmodal' it mostly seems to  
be used in conjunction with dialogs (button panels, popups) which are  
either:
- blocking, waiting for input (=modal dialog)
- non-blocking, accepting input when done (=nonmodal dialog)

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'.

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.

In Blender the word 'mode' now is used to describe a state where UI  
elements are in. A different visualization or state then enables  
different editing methods, which changes meaning of gestures (keys,  
clicks, mouse-movement). That's the 'mode' you referred to as well. So  
we have:
- editmode
- posemode
- vertexpaint mode
- radiosity tool mode (after 'collect meshes' the UI is limited)
- (and so on)

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).

Whether it's good or bad - or should change - is not the topic now.  
We're stuck to this approach, and try to make the best of it by making  
it as clear and consistant as possible. Nevertheless, for new  
development or improvements, we can look at limiting these modes as  
much as possible.

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.

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.

The Gkey in Blender, even when it is a little affected by state-modes,  
is still 'nonmodal' in the sense that it always works in a consistant  
way. It would become 'modal' only when we decide to adopt a global  
option which turns by default left-mouse dragging into 'grabbing'.

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.

Matt Ebb once mentioned the "nonmodal mode"; which I think is a funny  
one, but a bit confusing... we can also define it as "temporal tool  
mode".

Also difficult is to classify tools like 'Subdivide' or 'EdgeLoop  
Select', because they are available only within the context of a mode.  
However, when the tool is consistantly available it still makes it a  
non-modal tool.
For UI design we then only have to decide whether the availability is  
controlled with a:
- blocking dialog (popup "Extrude?" or pull-down menu)
- a button in a non-blocking toolbar
- directly with a single keypress


--------- conclusion ----------
The definitions then could be:

- blocking dialog
a menu or button panel waiting for user input, and blocking all other  
UI elements
(example: "quit blender")

- non-blocking dialog
a persistant menu or button panel, non-blocking
(example: material buttons)

- 'mode' or 'state mode'
A persistant change in visualization or state that enables different  
editing methods and which changes meaning of gestures (keys, clicks,  
mouse-movement).
(example: vertex edit-mode)

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

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

- modal tool
A tool which is available by a persistant change of meaning of gestures
(example: you hardly find them in Blender... but it could be assigning  
the grabber into leftmouse-hold-drag)

---------------

-Ton-

(*) I have to admit the extensive usage in Blender of sub-looping  
(reading events outside of the main event loop) also caused this  
approach. Changing this code into a real event-based one (with  
handlers) is possible though, and doesn't have to change the way it  
works for users.


On Thursday, Sep 11, 2003, at 21:21 Europe/Amsterdam, Thorsten Wilms  
wrote:

> Ton Roosendaal wrote:
>
>> Hi,
>>> Hello!
>>>
>>> Do you mean:
>>>
>>> tool -> hotkey
>>> mode -> menu
>>>
>>> ?
>>>
>>> (It should be clear, that tool or mode is a question of feel.  
>>> Because  a Tool (like rectangular selection) establishes a mode.)
>> Not really... a mode is sticky, permanent. After one border-select in  
>>  Blender the situation is back to normal. This is what 'non-modality'  
>>  defines. I think. :)
>> In photoshop all tools in the main toolbar are real modes. In Blender  
>>  almost all tools are not, but temporal loops that return to normal.   
>> This is a very important distinction, influencing workflow a lot.
>> ...
>
> A mode is when gestures (keys, clicks, mouse-movement ...) have  
> special/changed meaning.
>
> With border-select the mode ends with the actual selection-action,  
> whereas with classical tools like in Photoshop, you switch tools.
>
> So things like border-select are modal, but feel very natural because  
> with the completion of action the mode is left.
>
>
> Talking about modes vs tools could be misleading. Could we use a  
> distinction between persistent modes (must be explicitly terminated)  
> and auto-termination (must have nicer name!) modes? Examples:  
> proportional-vertex-editing and border-select.
>
> Hope to not confuse people ...
>
>
> And now I think loop-select should behave like border-select (for  
> consistency). Press key (or an icon), make your one seletion and exit.  
> Multiple selection? No problem: just repeat, as the selection is kept  
> anyway. Don't know how it is currently implemented.
>
>
> Has anybody thought about face-loop selection?
>
>
> ---
> Thorsten Wilms
>
> _______________________________________________
> Bf-funboard mailing list
> Bf-funboard@blender.org
> http://www.blender.org/mailman/listinfo/bf-funboard
>
>
------------------------------------------------------------------------ 
--
Ton Roosendaal  Blender Foundation ton@blender.org  
http://www.blender.org