This is a documentation of all features completed by me for my Blender GSoC 2012 project.
r47149, r47445, r47488, r47490, 47762
The user may close an area by dragging the area separator to the edge of an area. Holding control will prevent this from happening, allowing the user to minimize an area to header size without closing it entirely. Areas may also be closed immediately after they're dragged open.
A new area is created by dragging the handle on the top right and bottom left of each area. Accordingly, users should expect to be able to close an area in a similar fashion, i.e. by dragging it closed.
From my own experience and the experience of a number of users I've talked to and observed, this is often an initial frustration for a new user.
Blender's current signal that an area is about to be collapsed is to shade the collapsing area and overlay an arrow. This signal was insufficient user feedback to reuse for the drag-closing since an area dragged closed is rather small just before it closes, and thus a signal overlaid in the area would be missed. Instead, to signal that the area is about to close, this patch uses a "snapover" indicator similar to that used in region panels such as the tools panel. To achieve the snapover effect, offset information was added to ScrVert. When the user drags the separator over all the way, an offset is added to the vertices just before rendering. This rendering offset may normally interfere with UI interaction, but that's okay since the offset only renders while the mouse is tied up in dragging.
Blender's area system has some limitations in what areas may be closed. For example, any areas at a T-junction may not be closed. The T-junction must first be eliminated. This limitation isn't addressed by this drag-closing patch.
It's generally desirable that Blender's Info area remain open at all times, and the user be able to drag it open to view debugging messages and then close it again to header size. This patch would interfere with that behavior, so the feature is disabled for the Info area.
Non-modal Menus and Popups
r47251, r47301, r47346, r47446, r47772, r48216
If a menu or other similar popup region is open, the user may still take actions outside of the region, for example clicking interface buttons.
The initial prompt for this fix was the quirk that if a menu was open then it took two clicks to open a different menu. For example, if the "File" menu was open and the user clicked "Add" the "File" menu would close but the "Add" menu would not open. By making popups non-modal, the user is allowed to interact with controls outside the popup region, which will typically also close the popup. Thus, if the "File" menu is open, clicking the "Add" menu will close "File" and open "Add" as well.
Conceptually this patch is simple. The default return value for ui_handler_region_menu is changed to WM_UI_HANDLER_CONTINUE, and some code is added to activate a button (ie turn on mouseover highlighting, a prerequisite for running events in the button) which has been clicked but not activated because the popup was open.
This patch also includes a fix for an obsolete mousewheel-related hack that had started misbehaving. The hack was no longer necessary and was removed.
This is a simple change but it can have unseen consequences. I did it early in the development cycle, reviewed the affected code thoroughly and solicited feedback from other Bratwurst students to let me know if they experienced any odd behavior. A number of bugs were fixed, and no issues have appeared for the last month or so of this GSoC, leading me to believe that this patch is stable.
User Preferences Saved Separate From Default Startup Project
This patch allows preferences to be saved independently from the default startup project. "Save to defaults" in the preferences screen saves to the preferences blend instead of the default blend. Saving the homefile was renamed from "Save User Settings" to "Save Start-Up Project" for clarity.
"Save User Settings" and "Save to defaults" indicate that it will save things in the User Preferences panel, but instead it saves the entire project out as the "Default Blend" which is loaded when Blender opens. Often the user will want to change the default settings in the middle of some other work, and the result would be the in-progress work is saved and opened every time Blender starts up.
This patch introduces a "preferences.blend" file which sits alongside "startup.blend". The preferences file omits most other data blocks and contains only user preferences. It's loaded before the startup blend is loaded, and any preferences information in the startup blend isn't loaded. If there is no preferences.blend then the preferences information from the startup blend gets loaded instead. This is so that previously saved blend files are compatible with the new system.
There's still much usability work related to that could be done. For example, a "Save User Preferences" button which saves only user preferences in the file menu, a feature for re-loading the user-saved or default preferences while a project is still open, and an update to the User Preferences screen to make the functionality of the "Save As Default" button more clear.
X Delete Buttons In List Boxes
r47814, r47859, r47861, r47863, r48097, r48781, r48825, r48849
Added X button to delete single entries in a listbox. Implemented for material slots, keyring sets, render layers, and vertex groups.
This button comes from one of Bill Reynish's proposals. The X is visually more closely associated with what it will delete, and allows the user to delete an object without selecting it first.
Support for deleting in each listbox type must be added individually. In retrospect I should have detected if the delete operator had an "index" property and if so automatically added the "X". I recommend removing the "-" button for supported list boxes as well.
Dropdown List X Buttons
The two dropdown list boxes in the Info area, the Layout chooser and the Scene chooser, now have X button to delete single elements from them while the box is open.
This is from a proposal by Bill Reynish.
An X will be automatically added for any list box which has an "unlink" operator with and "index" property.
This list box was implemented without using controls, just by drawing text and then reading the mouse position to determine where the box's highlight will be. Thus I implemented the X's in a similar fashion, by using Blender's icon drawing function and reading the mouse input to determine if the X should be highlighted.
I don't recommend this feature be merged to trunk. I loved it when I saw it in Reynish's proposal, but now that I actually use it, I think it doesn't work well. I think the instance of a user accidentally deleting a layout of scene (very important items) will be significant, and not worth the workflow improvement.
r48184, r48185, r48211, r48295, r48620, r48660
This palindromic revision adds support for dragging the cursor over multiple buttons to select or deselect them all. This works much like the Photoshop layers work. Ctrl-click selects a single button and turns off the others.
This feature was highly requested in my BA thread.
A series of global variables were added to G to retain state while dragging. A button is toggled if its function (button->func) or RNA property (button->rnaprop) and state match that of the original button.
This patch actually changes the default behavior when a render layer is pressed. It no longer toggles the other render layers off unless ctrl-click is used. The tooltips have been updated to reflect this. I think this is justified since the feature was so highly demanded and I've not heard any complaints about the functionality change so far in my BA thread.
r48387, r48874, r49092, r49315
Adds a few features to the manipulator, such as mouseover highlighting and the ability to translate or scale in two dimensions at once.
Mouseover highlighting improves feedback and usability of the manipulator. 2-dimension translation and scaling improves its functionality.
This improved design was arrived at after many experiments and iterations, incorporating feedback from my BA thread. It works well even when multiple manipulators are enabled at the same time, and is not much more visually cluttered than the current design.
r48573, r48616, r48901, r48990, r49010, r49011, r49047, r49052, r49091, r49162, r49163, r49165, r49268
Controls overlaid on the 3D view, for purposes of usability and un-cluttering the design in other places.
The purpose of these changes is to support a redesign such as that proposed by Bill Reynish and others, including myself. It is primarily geared towards improving the new user experience by allowing a designer to place more commonly used controls in a more prominent place, separating them from other less-commonly used elements in the 3D view header.
An invisible 2D region with no controls is added to the 3D view. It's identical to other 2D regions, except that it carries a special flag ("dont_clear") which prevents it from having a background. Thus, the 3D viewport shows anywhere controls aren't drawn. A new panel type has been created (VIEW3D_PT_floating_controls) and it loads from Python.
New Python interfaces were added to allow layouts that designers of floating controls panels way want:
- Support for rows and columns to center or bottom-align objects
- A "clearfield" parameter for "prop" that clears all other bits in the prop's bitfield, for toggle buttons that should pop other related buttons when pressed
- RNA properties for vertex edge and face selection modes
- Operators for switching from object mode to vertex edge or face mode
- An operator for switching directly to object mode
- A function for querying the last redoable operator
- A "primary" marker for operator properties which can be used to indicate which properties are important and should be shown in a compressed view of the operator
The position of the floating controls can be changed or turned off in user preferences. To reduce the number of configurations that Blender must maintain I recommend that Blender find two or three positions that are best overall (ie "Top left" and "Bottom center") and support only these.
Since the 3D view floating control layouts depend so highly on Blender's sometimes-quirky Python layout engine, they carry some limitations. Some design ideas such as this one may be difficult or impossible to implement without further extensions of the layout engine.
There are some remaining issues with the interaction model of the buttons. For example, there's no prevention from the user turning off all edit modes without switching back to object mode. There's no prevention from the user turning off all manipulator handles. Should the Blender team's interface designer decide that these properties are undesirable, a way to prevent them will need to be implemented.
The text for the prototype "Last operator" button is black, it should be a brighter color such as white, and it should have some sort of mouseover effect and tooltip to show that it can be clicked.
Bug Fixes/Minor Features
Color wheel does not close
This bug was caused by a previous patch overlooking an overwrite of the UI_BLOCK_MOVEMOUSE_QUIT flag for the color picker.
r47248, r48290, r49722
Two buttons were added to the color picker which choose pure black and pure white.
3D view panel animations
This small patch fixes the lack of opening and closing animations in the 3D view panels.
Don't wait to open the next tooltip if the previous one has been closed very recently. This one took a few tries to avoid storing the information required to implement the feature in RNA, which would be serialized to disk.
Object selection in the Outliner
In the outliner, clicking an object in an unselected scene would select the scene the object is in but the object would remain unselected. This patch fixes that.
Prevent search popup auto-fill for some operators
Sometimes you don't want a search popup to automatically fill in the previous search, as it removes all auto-complete entries from the popup.