Dev:Source/UI/Window Management

IN PROGRESS. NOT FINISHED

Window Management

this page and the event refactoring one are closely related and aim to provide a base for defining the specs of the long due rewrite of this part of blender. The actual code is convoluted and use too much layers of wrapper while not allowing enough flexibility for modern software request like customization.

the Current Situation

Blender use a single window to do all its work with multiple non overlapping sub windows (named Areas). In each area run a separate editor (named Space). the Areas can be resized and changed to another kind of space at will. Each space handle its own datas and can access the global data structs. This part of the UI works very well, but the state of the underlying code is very worying.

From the system provided window to Areas, we have 5 ! levels of wrappers. Add to this that we dont properly support multi-screens setups, and that the render window is badly hacked in.

from Ton's notes in CMS (http://blender.org/cms/Window_Manager.497.0.html):

System Window <-> GHOST_Window <-> Window <-> bWindow <-> ScrArea
(OS specific) (Ghost lib) (ghostwinlay.c) (mywindow.c) (editscreen.c)

Especially the way how the renderwindow is hacked into this system is a total nightmare, with even code comments like "Do not ever release this after 2.23!"). This was part of a restructuring process never even finished...

The obvious wrapper series should be something like this:

System Window <-> GHOST_Window <-> Screen

Making the "render output window" just an Area in a Screen, or as a new (system) Window with a Screen, and thus allowing multiple Screens to be opened in separate windows (dual monitor purpose for example).

Refer to CMS for more in depth explanation of system.

Each space then handle its own event queue (via callbacks) and is supposed to run fully local, communicating with other spaces only via the global eventqueue. The most notable exception to this is the button windows which act on the active 3Dview.

the MVC model

the MVC model is a well known software engeneering method that i feel well suited for blender and for this rewrite, as the concepts involved are not too far from current. While it is generally viewed as an OOP concept, it can be perfectly be done in C, and insure nicely the spaces independance we need, while providing ways of communication perfectly defined.

• Model is what we act on, the input of action. In blender terms, the datalibs.
• View is the result, the actual space that display a kind of datalib.
• Controller handle user actions and all communications between different objects.

The key point in this model is how and when things are changed, especially view updates. Even if the view can (and do in blender) modify directly the model datas, it is the controller who notify other controllers which need to know values were updated, and those in turn will update their view. this means that the flow of info is perfectly controlled without having to rely on global redraw events.

Another keypoint is that controllers are stacked, if one controller cannot handle a request (an event), it pass it to a higher level controller. As controllers are directly linked to a view object, iow a rect on the screen, you can always find the view and as such the controller completly encircling the requestor.

In case of mode change, the view can change on the fly of controller, permitting maximum flexibility.

controllers use an Observer & notification mecanism to pass data and request between them.

This system allow to solve the problem of having a space A acting on another B, simply by allowing A to install a controller for B (name BforA), and then passing messages to it. B running in its own context, there is no problem of space state. the controller BforA is only active when space A is active, even if physically in space B.

each space keep its event queue and the stack of controller receive each in order.

the rewriting

Now this is a complex task, as it will impact on many areas of blender (basically many things in src + ghost) but this would provide a nice framework for further expansion.

We have several problems there.

As ghost is severly impacted (see its own page for lowlevel specifics) we need a X11 internals coder. We have no problem for finding Windows and Os X coders.

it goes hand in hand with event system refactoring wich is another huge task.

The notification and observer mechanism is relatively straightforward and there is plenty of example of how doing that.

but the messages passed in those notifications must be well thinked first as the system will allow easy expansion, but changes afterward will be harder.

Lukep 21:55, 18 April 2006 (CEST)