Dev:2.5/Source/Development/Proposals/UI/2.50 UI design/Brokenのソースを表示

==Overview==

One of the main reasons for starting the 2.5 project in the first place is that Blender's process of working with tools is well out of date. The available methods for interacting with Blender on a fundamental level have remained the same since the 1990s and haven't grown to keep up with the vast increase in complexity required for Blender, not only in the number of tools that must be accessed, but also in the standard of richness, feedback and interaction demanded by modern artists.

During the last several years, Blender has grown considerably, in size, scope, and also from a tightly controlled in-house project to a open source community spanning the globe. This has resulted in the greatest advancements Blender has seen but unfortunately it has also resulted in extra chaos and hacks as coders reach and push up against internal systems' limitations. In designing a new system, we need to look back at Blender's paradigms and analyse which are relevant, neglected, or outdated for the needs of Blender and its users today.

==View, Select, Edit==

An original design paradigm of Blender is the view->select->edit workflow. This means that data (content) is visualised, the user then decides what aspect of it will be changed, then how it will be changed, then starts the cycle again, seeing the results. As a general rule this has worked quite well. One advantage of this approach, is that it keeps a non-modal, non-blocking workflow, at each step of the way you can change your mind, or try something different, or look at something else, without being constrained into several levels of sub-modes for each tool. A modal workflow is essentially constraining, but with a non-blocking workflow, an artist isn't forced into a certain step-by-step process, but has the freedom to change and create different possibilities.

The idea of working using fine-grained, independent parts fits very well with one of the goals of Blender 2.5, the ability for an artist to 'create his own tools' by fitting existing tools together via macros or other such mechanisms. The more isolated and modal tools become, the harder it is to isolate and repeat their actions.

Due to limitations in Blender however, in recent years this idea of isolated steps in a view->select->edit workflow has been diluted somewhat, due to users demands for richer means of interaction. Most of the time this has had good reasons, and benefited users considerably via richer interaction, however the implementation has been sub-optimal, a compromise due to the limitations of Blender at the time.

The most easy option for coders at the time was to layer on further sub-modal tools, that gave better feedback, but locked the user into pre-set modes and while improving visualisation, at the same time limits other means of interaction considerably.

===Modal Tools===

Examples of blocking, sub-modal tools are found mostly in mesh edit mode, and include tools like knife subdivide, loop subdivide, edge slide. While, for example, the loop cut tool is great to use in terms of visualisation, it is severely limiting in other respects.

While within the loop cut sub-loop, all other interaction is blocked. You can't rotate the view to get a better look at the model, you can't change between wireframe and solid, you can't change other settings that may affect the outcome of the tool such as enabling/disabling modifiers, editing other settings, etc. Everything is blocked apart from the few options that the tool provides. Not only that, but the options that are available, are only accessible via one primitive method, keyboard entry. This is extremely limiting and prevents using any of the myriad other UI elements that are at our disposal such as toggle buttons, number fields (which of course support all sorts of things like python expressions), colour pickers, 3D manipulators, tree views, the list goes on.

Not only this but the feedback for this kind of UI interaction is terrible, limited to a single line of text, that's easily ignored or hidden, far away from the actual area of interest that you're working on, and without visual representation of anything  - witness the dreadful '(S)mooth: on/off' line in loop cut. And of course there's not enough space to represent the extent of the options available in one line of text, for example the mouse wheel or number key options within loop cut are completely hidden and not mentioned anywhere in the UI.

<i>(I can't believe I just wasted a few sentences arguing the usability merits of UI controls that have been standard since 1985, over a single line of text. That's very worrying.)</i>

While the visualisation aspects of these tools are useful, the actual interaction is a big step backwards. Not only is this a usability problem, but the code used to implement such things currently is horrid too (creating new, localised event loops, handling all redraws manually, not interacting properly with other parts of Blender - for example the modifier stack).

It's clear that these modal tools have to go, and that we have to find a way of keeping the positive aspects of feedback and visualisation, without the implementation baggage mentioned above.

===Non-blocking===
Until i write more, this IRC log may give an example of the problems and possible solutions for this:
http://wiki.blender.org/index.php/User:Broken/NonBlockingToolsChat

===Tools vs Settings===

settings/properties/attributes/variables/values

settings = data
i.e:
 - vertices/edges/faces in a mesh
 - vertex groups
 - object groups
 - lamp settings
 - material values
 - Particle system values

Settings are currently found in buttons window.

A lot of the interaction with Blender currently takes place via settings, not tools.

i.e:
 - creating and designing materials and textures
 - physics, soft bodies, particles, hair
 - constraints, modifiers (to some extent)




tools act upon data


[[Category:Interface]]