![]() Although the subdivision lay-out has proven its use - and being used now in other programs - there's occasions when it becomes too rigid, limiting users or certain useful multi-window setups.A local "Area manager" should take care of its own region subdivision, allowing it to be like a fully independent editor within Blender's Window Manager. The definition and handling of Areas and Spaces (editors) should become clean, allowing custom or plugin-able editors.Such regions also can contain buttons (to solve abuse of floating panels) or provide multiple views (a 4-split 3d window) with a single context. Now, each Area should be able to split itself again in many "AreaRegions". This gave context problems (where do we show related button options), space problems (headers were too rigid and small), but it also created problems when the need arose for further area subdivisions, such as channel lists for animation curves. The subdivision system only provided support on Area level, one per editor, with fixed header size.An optional render-output window should be handled like any regular "Screen" in Blender. Opening a 2nd window (render window) was horrible and tedious code, with no uniform handling.For 2.5 we will tackle a couple of weak points in the original design: The latter, Notifiers, are merely suggestions, and are only targeted at the UI ("View") to function properly.īlender was designed as a single-window system, providing non-overlapping subdivided layouts ("Screens, Areas") to manage the various editors and options. The first means user input - or timers, external events - which have to be handled each, and in order of occurrence. Events are strictly separated from "Notifiers".Separating these two is important for re-use of Operators, like for macros, history, redo, or python. There's a "View" related component (the Event Handler) and a Data related component (the Operator). The "Controller" has been split in two parts.The "View" now is the only place where event handling happens, this is the new WindowManager in Blender.This diagram shows a more elaborate description of how Blender 2.5 will handle events and tools. This is one of the main limitations that should be solved for the 2.5 project. It also meant that there was no central registration or handling of events, each view or tool could get own sub-queues with event handling. The main exception was that the "UI" (in this case buttons) was on each level, to allow data selecting, view selecting, tool selecting. Editing is always on the data, not the visualization of it! Although that could seem slower in cases, it makes the tools much more flexible, predictable, and uniform.The user selects the view method flexibly. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |