[Bf-funboard] Toolbox design

Ton Roosendaal bf-funboard@blender.org
Fri, 3 Oct 2003 14:00:05 +0200


Hi,

Thanks for the proposal.
I'd prefer you to look the 'context' description as used in the UI  
paper. For me, the 'context' is including modes.

For the buttons panels, I am working at making a 'uiContext' struct (or  
so), which is a nice locally transferred pointer to calls (and  
commands) which then can find out themselves if the context itself is  
appropriate. This same system can be used for the toolbox, to check on  
'uiContext' before assembling the toolbox itself. I still have to code  
this, I might find out the UI paper proposal in insufficient, but sofar  
I know Blender I think it'll do.

Since we have a LOAD of commands in Blender, especially in the 3d  
window, I think its better not to include the top level context in the  
toolbox; these are already displayed in the main menu bar:

> - Application (Prefs and Quit, can all belong to the next one)
> - File
> - Scene
> - Screen

The remaining context levels:

- current window type
- current active object or indicated datablock (e.g. in ipowindow)
- mode
- current active item (vertex, face, bone, handle, strip, etc)

Also check on what 3DS did for their 'toolbox'.

http://www.discreet.com/images/products/3dsmax/3dsmax5_beta/hi-res/ 
PolyModeling-Frog.jpg
http://www.discreet.com/images/products/3dsmax/3dsmax5_beta/hi-res/ 
PoseAnimation-Abix.jpg

The simplicity of this system works very well. In the 2nd screenshot  
you can see how it entirely goes into a modal context (the selected  
axis for pose). I don't think we should take it that far, but it works.

As I mailed in my previous mail, we can use Matts work on the pulldown  
system to design the structure for the new toolbox. Some consistancy  
here would be more than welcome! Reviewing/changing Matts structure is  
ofcourse an option too.

I *do* like the 'autocomplete' mode, it should indeed search through  
the database of available commands. Coding this might be just one step  
beyond for what we can do in 2.3 however... unless it only searches  
inside the active toolbox itself. That's possible.

-Ton-


On Thursday, Oct 2, 2003, at 17:21 Europe/Amsterdam, Thorsten Wilms  
wrote:

> Hi!
>
> I would like to present the current state of my work for the toolbox
> (work on the icons hasn't been so fruitful up to now).
>
> http://wrstud.urz.uni-wuppertal.de/~ka0394/en/blender_ui/
>
> -----
>
> About organization:
>
> I can think of three different ways to categorize everything that
> could go into any menu.
>
> 1. Context-Layers or maybe Levels
> - Application (Prefs and Quit, can all belong to the next one)
> - File
> - Scene
> - Screen
> - Active window
> - Active Object
> - Selection
> - 3D Cursor (belongs here mainly for ADDing things)
>
> There can be no selection and no (truly) active object, but at any
> time your in an active window in a screen and in a scene in a file
> in the application blender. Therefore you have selections on all
> these levels allowing to operate on them.
>
>
> 2. Basic Operations
> - Add
> - Remove (Delete, Clear)
> - Change (Transform, Edit)
>
> to expand a little bit:
> - Select
> - Copy
>
> In a hierarchy starting with these, the Snap-Menu should be
> top-level, because it' entries belong together, but don't fit
> well under one of the other top-levels.
>
>
> 3. Modality / Mode of Operation (short: MoO! ;-)
> - Commands
>   Single gesture (click or keypress), therefore nonmodal.
>   Example: "Select All".
>   Mode of Operation: straight execution.
> - Tools
>   Temporary modal things like Border-Select.
>   Mode of operation in the sende of a menu: Start.
> - Modes
>   Explicit modes like Proportional Vertex Editing.
>   Mode of Operation: Toggle!
>   Boolean Options belong here as well
> - Mode-Selections
>   different to the above in that it's not a boolean thing, but
>   a selection from a list of possibilities.
>   Mode of Operation: Selection.
>
>
>
> All of these categorizations can be used to sort items inside a
> hierarchy starting from another one. For example entries that refer
> to addition, deletion or editing could go in the same order everywhere.
> For providing extra consistency.
>
>
> -----
>
> Autocomplete semi-commandline
>
>
> Like mentioned before in some post of mine, there could be a textfield
> somewhere on the toolbox menu. Starting with the first key entered,
> possible completions would be shown in a list next to the field.
> Like "Add" "Append" "Apply Size/Rot" for "A".
>
> Now what about making _all_ blender functionality accessible through
> this way?
>
> Example: Setting OSA to 16:
> - Hit spacebar
> - Enter "osa"
> - Below the textfiled a line reading "OSA" and the current value  
> appears.
> - Complete entry "osa 16" and hit enter.
>
> Example: Adjusting the red value of the material applied to the active
> object.
> - Hit spacebar
> - Enter "red"
> - All red-values that could be meant appear in form of sliders (just  
> like
> in the buttons-window)
> ...
> This would fit well with button-panels, because those could be called  
> by
> name.
>
>
>
> ---
> Thorsten
> _______________________________________________
> 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