It seems like it’s still unclear what the widget project actually is and what it means, so it’s really time to make things a bit more clear. Especially, to justify why this project is important for the Blender user interface.
Sidenote: Since I’m currently also working on normal widgets like buttons, scrollbars, panels etc, I actually prefer to call the widget project ‘custom manipulator project’. Just to avoid confusion.
– Julian
(Mockup)
Blender suffers from an old disease – the Button Panelitis… which is a contagious plague all the bigger 3d software suites suffer from. Attempts to menufy, tabify, iconify, and shortcuttify this, have only helped to keep the disease within (nearly) acceptable limits.
We have to rethink adding buttons and panels radically and bring back the UI to the working space – the regions in a UI where you actually do your work. This however, is an ambitious and challenging goal.
Here, the widgets come into play! Widgets allow to tweak a property or value with instant visual feedback. This of course, is similar to how ‘normal’ widgets like buttons or scrollbars work. The difference is, that they are accessible right from the working space of the editors (3D View, Image Editor, Movie Clip Editor, etc). It is simply more intuitive than having to tweak a value using a slider button that is in a totally different place, especially when the tweaked value has a direct visual representation in the working space (for instance, the dimensions of a box).
Being able to interact with properties, or in fact with your content, directly, without needing to search for a button through a big chunk of other buttons and panels, is like UI heaven. This is how users should be able to talk to the software and the content they create in it. Without any unnecessary interfaces in-between. Directly.
Blender already has a couple of widgets, like the transform manipulator, Bézier curve handles, tracking marker handles, etc. But we want to take this a step further: We want to have a generic system which allows developers to easily create new and user friendly widgets. And, we want the same to be accessible for Add-on developers and scripters.
It’s also known that Pixar’s Presto and DreamWorks’ Apollo in-house animation tools make heavy use of widgets.
In Blender, there are many buttons that can be widgyfied (as we like to call it): Spot-lamp spot size, camera depth of field distance, force field strengths, node editor/sequencer backdrop position and size, …
Also, a number of new features becomes possible with a generic widget system, like a more advanced transform manipulator, or face maps (groups of faces) with partially invisible widgets, similar to the ones from the Apollo demo.
Actually, all these are already implemented in the wiggly-widgets branch 
The new transform manipulator
The spot size widget (GIF – click to play)
Face map widgets (GIF- click to play)
Current state of the project:
The low-end core can be considered as quite stable and almost ready now. Quite a few widgets were already implemented and the basic BPY implementation is done.
The next steps would be to polish existing widgets, create more widgets and slowly move things towards master. It’s really not the time to wrap things up yet, but we’re getting closer.
Focus for the next days and weeks will likely be animation workflow oriented widgets, like face maps or some special bone widgets (stay tuned for more info).
A bit on the technical side:
Widgets are clickable and draggable items that appear in the various Blender editors and they are connected to an operator or property. Clicking and dragging on a widget will tweak the value of a property or fire an operator – and tweak one of its properties.
Widgets can be grouped into widgetgroups that are task specific. Blender developers and plugin authors alike, can register widgetgroups to a certain Blender editor, using a system very similar to how panels are registered for the regular interface. Registering a widgetgroup for an editor, will make any editor of that type display the widgets the widgetgroup creates. There are also similarities to how layouts and buttons function within panels. The widgetgroup is responsible for creating and placing widgets, just as a panel includes code that spawns and places the buttons. Widgetgroups also have a polling function that controls when their widgets should be displayed.
For instance, the transform manipulator is a widgetgroup, where individual axes are separate widgets firing a transform operator. Just as every 3D editor has a toolbar, registering a manipulator widgetgroup with the widgets used for object transform, will create those widgets for every 3D editor.
Needless to say, plugins can enable their own widgets this way and tweak their widgetgroups to appear under certain circumstances through the poll function, as well as populate the editors with widgets that control the plugin functionality.
(A more detailed and technical design doc will follow, this is more like a quick overview)
So! Hopefully this helped to illustrate what the custom manipulator/widget project is, and why it matters.
It is a really promising approach to reduce UI clutter in button areas and for bringing the user interface back to the viewports. Work with your content, not with your software. It’s about time.
– Julian and Antony