With the 2.30 launch, we present the first results of work on an improved user interface for Blender. Since most of Blender's code *is* UI, a huge task to accomplish, and something that will grow more mature over the upcoming releases.

 

Nevertheless, we can proudly present a series of improvements over the last 2.28 release, which will be briefly described and elaborated below.

 

Feedback

 

Of course we release to get feedback on our work as well. Please bear an open mind when testing the various new features. Not all is finished nor polished.

 

We'll schedule a review process in three stages;

 

1. getting all bugs solved involved with this release, things that don't work anymore, hotkeys or menus that give wrong events, and so on. For this release we had to do a major code reshuffle and cleanup, which enevitable will need some additional testing.

Based on that, we'll release an update (2.31) within a couple of weeks, to make sure there's a good working Blender available, also to be included in the new manual.

 

2. after that, with a couple of weeks time for everyone to get familiar with what's all new, we'll gather reports and suggestions for further improvements. This then still will be done within the context of the UI Redesign doc, which provides the big picture. Proposals are especially welcome to finalize:

• locations, context, contents and manipulation of Button Panels
• the new toolbox (which is really still in alpha)
• contents and structure of pull down menus
• design and styling for buttons (and themes)

 

 

3. what is still pending, and/or what we first need design proposals for is:

• icons and cursor styling
• naming conventions in menus and buttons
• bringing back, user configurable, icon buttons for tools in header and a new vertical floating 'toolbar'
• access from Python to the new UI system
• further experiments with radial toolboxes
• full review of usage of hotkeys
• drawing style & colors of wireframes
• selection modes (vertex, edge, face)
• better implementation of 'face select' and 'painting' modes
• having multiple Blender windows (Screens) open, also for dual monitor setup

More than enough to do still...

 

 

Pull down menus

 

The purpose of pulldown menus in Blender is to give a complete as possible overview of all tools and commands Blender offers. Each window type in Blender will get these, based on the functional context of the window itself. The main header (Info Window) provides the global available options, all other options can be found in the corresponding window headers.

 

New options:

• All headers allow to hide pulldowns (triangle icon).
• In user settings menu (pull down top header) you can tweak settings for automatic opening of menus.
• another click at a pulldown menu now doesn't close the menu anymore

 

 

Cleaning up headers

 

Apart from solving the intimidating looks - headers with loads of obscure icons - we also needed to create space for future expansion. For this version, only the most important options are displayed in headers; where possible the old icon buttons have been moved to a pulldown menu. We've also added a larger button to indicate the very important current 'mode', like 'EditMode' or 'Vertex Paint'.

The next stage will be to allow a user configurable icon-button setup. For both in header, or for in a small floating toolbar in the window.

 

Most obvious is the reorganization of icons in the ButtonsWindow header. This had to match a vertical layout (250 pixels wide) as well. Using middlemouse scroll, you can tweak display for a small header though.

 

We've done experiments with full transparent headers, but this didn't work at all... you can still hide/reveall them with a rightmouse click on a window border.

 

 

Buttons window reorganization

 

To enable flexibility an future expansion, the old and rigid structure for buttons in Blender has been rewritten from scratch. It now allows a flexible hierarchical structure, with three levels:

 

-> Main Context

 

In the header, the icon group on the left indicates 'main context' level. Divided now in six categories based on workflow:

1. Game logic buttons

2. Script buttons (for next releases, python scripts can completely fill this in)

3. Shading buttons (materials, lamps, world, radiosity, texture)

4. Object buttons (all related to doing things outside of editmode)

5. Editing buttons (related to editing modes, including paint and UV texture select)

6. Scene buttons (global context-free settings)

 

For convenience, we kept most of the previous hotkeys for it, but this is a candidate to change later on:

F4: logic

F5: material

F6: texture

F7: object

F8: world

F9: editing

F10: render

 

You can of course have multiple windows with buttons open, to have 'shading' and 'editing' context visible together.

 

-> Sub Context

 

Each 'main context' can have unlimited branches. Most obvious is the Shading group, which updates on selected (activated) Objects, including showing 'World' when a Camera is selected. Going to another 'context' and back will always restore what you had.

 

At this level actually a decision is made which button panels are visible.

 

(NB: the current tree is hardcoded still, but a candidate to become dynamically generated, allowing to construct different tree structures on the fly, including Python playing with it all)

 

-> Panels

 

This is the most obvious change, organizing all buttons in small groups that can be moved around, collapsed, or merged. After doing some experiments with sizes, we found that a fixed 320x210 size was optimal, both for horizontal and vertical layouts. With only a few exceptions we've used this standard.

 

For this release we've also deliberately choosen to match a layout as close as possible to previous versions. Expect in upcoming releases results of further 'information design' work on this as well.

 

Panel features are:

• press rightmouse button in buttonswindow for an 'align' menu. This enables automatically controlled horizontal and vertical layouts.
• click-drag a Panel header to move it around. In align mode Blender will animate the other Panels out of the way
• press 'Home Key' to have Panels properly scaled and aligned in a window
• use the mousewheel to scroll the buttons in the aligned direction. Use CTRL+mousewheel to zoom.
• PageUp / PageDown keys scrolls as well, PadPlus/PadMinus and CTRL+middlemouse still zooms.
• please note that these Panels are not real 'windows', and don't support clipping for an overlapping layout (yet). Only for that reason they're drawn transparent, to remind such layout is not really functional.
• click on the triangle icon to collapse/open a Panel. In horizontal align mode, only the first character of the Panel name is printed now, vertical text will be coded later.
• while dragging a Panel, you can release it on top of another Panel, to merge them. The Panel then will display 'tabs', and only the righthand part allows dragging.
• click-drag an active 'tab' to unmerge.
• note: the previously described 2 points have been patented by Adobe in the USA. It was the simplest and most straightforward method to implement it though... alternatives will be studied at.

Since Panels reside within the 'context' of the hierarchical tree of the buttons window, they can't be moved outside of the window. Yet...

 

Floating Panels

 

Several obscure buttons in Blender have been moved to a location where they actually belong. Most obvious were:

• the 3d Window 'background image' options
• the IpoWindow options in the former 'anim buttons' (F7) menu.

 

You can invoke this with the new pulldown menu in the headers. It then will display a Panel in the window, working fully non-blocking and live updating changes. The same method has been used for the former 'N-Key' (numerical input) menu, which is a nice Panel now as well. Features of floating Panels are:

• They are drawn transparent, but this can be adjusted using the 'themes'.
• Collapsing a Panel will move it aligned to the window bottom.
• Use ESC to get rid of them.
• Press PAD-plus or PAD-minus to change Panel size. Mouse-wheel doesn't do that.
• Studied still is whether to add a feature that these Panels close automatic on mouse-exit, as the former menus did... but the non-blocking parallel working is too nice to at least play with now.
• Note that Panels only catch events on buttons, and still allow rightmouse select on stuff that's behind.

 

 

Automatic coloring for buttons

 

In previous Blender versions, coloring of buttons was used to indicate its type. This was all hand-coded, and was not consistantly implemented.

For 2.30 it is replaced with an automatic system, all buttons are colored now based on type. It needs some further tweaking to get some exceptions corrected though, the colors don't always match what we want to communicate.

 

 

Toolbox

 

The new version of a toolbox is in fact mostly based on what the pulldown menus offer in the 3d Window. Again for this a lot of new code had been written, especially to devise a simple scripting style structure, to enable easy experiments with alternatives later on. It's about the latest addition coded, just finished a couple of days before the release, and one of the main issues that need further work.

 

The main purpose is to give as much context-sensitive information as possible. It's always a subset of the available total of options, and should please power users as much as new ones...

 

Some things to mention:

• both left- as rightmouse click'n'hold will invoke the toolbox. Currently the threshold is set at 0.5 seconds, which can be changed in the User Settings menu. Moving the threshold value up will efficiently disable this.
• not all categories have been implemented... toolbox will also only run in 3d window now.
• Spacebar and SHIFT+A still both invoke toolbox

 

 

Themes

 

Drag down the top header (mouse over window border) to see the options to tweak color and drawing style of the UI. A couple of features to mention:

• you can add up to 16 Themes now, but the first Theme is built in and cannot be altered. This allows to go back to 'normal' at any stage
• a newly added Theme is always a copy of the previously displayed theme
• Themes are only saved when you invoke CTRL+U, "save user settings". This then is written in your home directory, as a regular .blend file: ".B.blend".
• for upcoming releases, we'll add options to exchange (load) Themes and to disable loading a UI from Blender files.
• Each Theme can be given a name. This will be used later on, when we add the option to assign a Theme to individual windows. Useful to have sevareal backdrop colors for modeling, for example.
• Themes for button style are now easy to construct in C code. Expect a couple of (useful) choices in next releases.

 

 

Styling

 

 

• Obviously styling work has been done at:
• drawing method of pulldowns
• drawing method of standard buttons
• removal of the 'big fat' window edges, back to a single black line
• headers are displayed rounded, to indicate which window they belong to
• header colors (can) match the window color
• using anti-aliased fonts is much faster now, they also scale down automatic when buttons are smaller.

 

 

Speed...

 

Quite some work was done in cleaning up old code. Several old hacks were removed which caused substantial slowdown or CPU load. In general, the new UI should draw faster than ever.

There might be issues with certain Linux window managers though... like minimizing windows, and using desktop switching. Some removed hacks were undocumented, and need careful evaluation again.

 

 

 

Ton Roosendaal

 

Amsterdam, october 30, 2003.