Dev:Source/Architecture/Events Tool API Notes

Tool Lists

• Default/customisable lists of tools
• For use in (generating?):
  • toolbox
  • header menus
  • radial menus
  • popup menus
  • floating/dockable toolbars
• hierarchical?

UI Buttons connected to tool info

• Linked to tool data rather than DNA variable pointer
• To allow context menus on buttons with RMB menu/hotkey:
  • Insert/delete keyframe, per slider
  • Colour tinted visualisation of any keyframes set for that value on current frame
  • 'Help' web link
  • Change hotkey
  • Copy to selected objects (Copy Attributes menu is way past its practical limits)

Datablock operations as modular APIed tools

• example: texture workflow fixes
  • Currently adding a texture takes too many steps and is rather annoying:
    • For procedurals: Add New -> F6 -> Change none to desired texture type -> F5 -> 'Auto' button
    • For image textures: Add New -> F6 -> Change none to image texture -> click file select button -> file selector: find file -> F5 -> 'Auto' button
  • This could easily be streamlined by changing the Add New texture button to contain a list of texture types that get added automatically by selecting them from the list, rather than just a single action adding an empty texture
    • For procedurals: Add New -> Select texture type (name updated automatically)
    • For image textures: Add New -> Select image texture type -> file selector: find file (name updated automatically)
  • For this sort of thing to be possible, we need a nice API for datablock operations such as adding textures, instead of it all taking place within a giant construct in std_libbuttons()
• Other examples of usefulness:
• Drag and drop in outliner/oops
• Can drag and drop library data (materials, objects) to 3d view

Event System

• Should allow easy implementation of non-blocking tools
• No more tight loops (eg. knife tool) where manual redraws/event handling must be coded
• Should be able to use tools such as knife tool non-modally, while keeping access to other window spaces - i.e. buttons window controls
• Allow drag and drop (example, implementation details may not be the best, but hey)
  • Drags could be detected in ghostwinlay.c, checking mouse-held movement against a threshold
  • If a drag is detected, put a 'drag started' event on the queue
  • Tools code can check for the 'drag started' event, and do what they need to do (examining clicked location, displaying the dragged item with the mouse)
  • Ditto for drag end
  • Drag and drop should be possible across window spaces, i.e. dragging buttons window panels to the 3D View, or dragging a material from a library to an object, or dragging an object name from the outliner to an object name input button (IDPOIN).

Customisable hotkeys

• Keys belong to the tool, not tools belonging to keys?
• Gimp/Wings style edit-in-place is absolutely necessary (shouldn't be totally reliant on horrible 'hotkey manager' UIs)
  • RMB click or hotkey (Insert key) on a menu item to edit its hotkey: http://wiki.blender.org/uploads/a/a4/Hotkeys01.png
  • Modal dialog to enter a key: http://wiki.blender.org/uploads/d/d8/Hotkeys02.png
  • Check for conflicts: http://wiki.blender.org/uploads/b/b9/Hotkeys03.png
  • Updated hotkey in menu: http://wiki.blender.org/uploads/5/50/Hotkeys04.png

Customisable 3D navigation

• View manipulation tasks should be fixed, with the ability to assign various keys and modifiers to them, eg:
  • Orbit view: [ Alt •] [ MMB •]
• Mouse buttons
• Modifier (+ other?) keys
• Button combinations - LMB + MMB for scale = excellent for tablets
• Should be able to emulate other systems, for easier migration
• First-use startup screen (can be done in python), with preset navigation/preference configs for transition from other apps (Max, Maya, XSI, blah blah)