Dev:2.5/Source/Development/WinterCamp/EditorReviews

In Blender 2.5 hotkey/mouse definitions are grouped in 'key maps' together. For each editor in Blender there are multiple key maps, also for all modes or modal tools like transform. Customizing keys will be done per key map, by making a local copy of the default map and then editing all options you'd like to have. The default key maps will always be unaltered and available to use.

To allow consistency among editors or to follow user preferences, keys can get names using macros, for example "SelectMouse" or "RotateKey".

Creating and changing key maps will be fully accessible via Python.

International Keyboard mapping

The low level Ghost library should handle proper keycodes, to ensure that the actual "name of the key" (rawkey) can be used for hotkeys in the Keymap editor, and not the ascii value. This to prevent that a key assigned on one keyboard gets mapped to a modifier+key on another keyboard. Example: assign a key to "[" on an English keyboard will show as "Å" on a Swedish keyboard, and vice versa.

Suggestion for future documentation:

Avoid denoting tools via hotkey names! The operator specification provides a unique name for every tool, which will be visible in the interface all over (even via search). Using those names with some special style or bracketing might make documentation work well.
Needs further design, but could look like: [Mesh Extrude] or [Marker Move].

Drag'n'drop

In theory you should be able to drag any tool (button, icon) into another location to invoke an event. This will be defined by special "key maps" as well, defining for all relevant input types (the drag part) an operator to execute (the drop).

Examples:

- Drag Material out of outliner into a buttons window to make it show values, and depending on window context it also assigns.
- Drag editor-type icon into an area to change type

This topic will require further experimenting still; like what dragging a button on another button means, for example.

File conventions

- We should enable to save user preferences separately from screen/window layouts.
- Explore: save window layouts separately from screens too (as part of start-up preference).
- Communicate much better the existence and usage of temp files and restoration files (on quit or crash).

Icons and Color Language

- Proposal is to stick in the default theme to the currently used icons style, designed by Jendzrych
- These icons use color to make a distinction between tools and settings
- Larger icons (like 35x35 pixels) should be possible too, this is pending further design tests with toolbars.

Screen layouts

- Region dividers should become draggable as well, similar to Area dividers
- Merging and duplicating areas via the "corner widgets" works very well; visualization of this hotspot has to be improved.
- More functionality in "corner widgets" can be added, like flipping the editors of 2 adjacent areas.
- More flexibility to change layouts needed in general, like 'rotate an edge'. (Visual proposal following!)
- In case an area or region is too small to be useful it should "collapse", indicating such clearly and showing a visual clue (icon) how to bring it back.

- Using a region with vertical 'tabs' on the area edge to visualize and access previously used editors didn't get consensis. Downside is that it occupies not much used UI space. The topic can come back later though.

3D View

- No "max draw type" anymore, if you set an object draw type it will just use this disregarding 3D window setting.
- Draw types should be each customizable, especially for texture/light/glsl options.
- Wire Colors will be implemented using a 'rules' system, which can provide similar functionality to now, and extended with more complex rules like "if object has parent AND is Mesh". And the rule "if has custom color" of course. Colors preferably come from an indexed Theme palette.
- Layers should allow to be named. Preference is to keep layers 'flat' and quick to access, although a hierarchical version proposal will be reviewed later. UI for this is open design topic.

2D Views

- Scroll bars should dissapear if everything is visible
- Test: make timeline + markers an own region in bottom, preventing confusing mixed selection of markers and other items, prevent keymap conflicts for markers, and allow to map LMB frame-dragging in a window to select or other tools.

Graph Editor

- Usage of colors needs further review
- Default start with 'show active object curves'

Image/UV-Image Editor

Too much functionality is combined here:
- UV editor
- Viewing images
- View render result, layers, passes
- Show Composite viewers
- Texture painting

Proposal: separate in UV Editor and Image Editor/Viewer
Proposal: drop the per-face-image pointer, and use regular Materials instead. This will solve a lot of confusement for editing.

Sequencer

No real issues; we'll stick to internal 'view modes' for a while to either draw sequencer output, sequencer strips or color graphs.

Audio Window

Delete or hide, until proven it has useful functionality.

Text Editor

- Should get normal scroll bars

Info Window

- User Preferences don't belong here

New: Screen bar

- Screens will get a fixed top/bottom bar for the menus and for browsing screens/scenes.
- This Screen bar will also communicate 'active context' as explicit as possible.
- Screen bar gets operator/hotkey search box, optionally activated via hot key too
- Test: add (customizable) toolbar options here for global tools

New: User Preferences

- User preferences get own space type (open topic: what's in the header?)
- Option: hotkey or menu to show preferences will open a (smaller) window with the user prefs.

New: Console

- Console header will be used for stats/reports/errors or 'last issued command'.
- Console window shows entire logs (as py lines) and allows to input commands.
- Default configured screens will get console header in bottom.

Design note: python commands executed in console that require strict local editor context will just fail. Either just drag/drop the python line then in the editor, or on a toolbar (creating icon or button) or assign hotkey to it for reuse.

Outliner

- Allow to view assets from externl library
- Get rid of OOPS view (sob!)

Buttons Window

- Uses layout engine to view contextual properties
- No tools here, apart from operations on data
- Either shows screen context (active/selected) or local browser context.

For more info: UI Design Rules

Scripts Window

Delete! Either you make a custom space, or just extend existing UIs via Python

File Browser

- Get rid of file manager options?

- Get rid of . and .. items in the file list, replace with explicit operator buttons
- Create new directory needs button
- List of recent directories
- Importers should be able to put settings in the filebrowser
- Choose exporter type in filebrowser like image type
- Collapsed view for image sequences
- Hide backup file/ hide .dot files
- Filter string regex?
- File browser settings (sort by) as user preference
- Make Append/Link actual action buttons
- Image views could be a little smaller, and/or zoom in/out
- show file hierarchy in left
- tab completion