BlenderDev/ScreensAreasWindows

Wikipedia，自由的百科全书

原文:http://mediawiki.blender.org/index.php/BlenderDev/ScreensAreasWindows

Blender 窗口管理器(typeErr翻译)

屏幕/区域/窗口（screens/areas/windows）

Blender有它自己的多功能窗口管理器。Blender正是基于这样系统的所需求而开发的。窗口管理器的最高级别是“屏幕”，场景正是操作系统环境里面的“窗口”。场景再被分为“区域”,区域是子窗口。（我大部分地选择了场景和区域来避免使用容易混淆的“窗口”）。

在很早的blender1.0中，对区域的绘制留给了Irix窗口管理器提供的“子窗口”特性。过了一段时间我决定放弃它，把部分的原因是速度太慢，速度在一个需要开10-20个窗口的程序中是一个重要的考虑的因素，不能过多地增加系统的负担，比如刷新一次屏幕要用上几秒钟（在有些软件中）。

我发现了一种方法：用openGL特性完全最小化子窗口。同时使用glScissor（）和glViewPort()方法可以高效地完成。对应得代码在src/myWindow.c文件中。注意你仍然可以在以前的子窗口中找到wrappers，引进“bwindow”层。

所以在这里，把“区域”特性和“BWindow”的混淆已经介绍了。。，为了使整个系统更有吸引力，对Gltu的端口被加到系统之上，然后才是 Ghost。从“BWindow”到GhostWindow的封装在“ghostwinlay.c”内。所以现在我们感兴趣的是这一系列的封装：

System Window(操作系统指定)<->GHOST window（GhostLib）<->Window（ghostwinlay。c）<->bWindow（mywindow。 c）<->ScrArea（editscreen。c）

如何渲染系统的窗口至今还是一个噩梦，重建工作从未完成过。

比较明显的封装是像这样的一个东西：

System window<->Ghost window<->Screen

区域和空间（Areas and Spaces）

在blender内“活动窗口”就是一个活动区域，这一在屏幕内的区域是输入和输出的地方。Editscreen.c管理这些东西，定义了哪些区域是当前输入窗口，哪些区域应该被重绘，还有在哪些情况下应该完成全部或部分的交换缓冲。

由于这些原因，区域必须有它自己的事件队列，和（方程指针）返回去控制和描绘队列。屏幕系统去读取主队列，再分配到区域，执行队列，对于恰当的交换缓冲仍可以执行重绘。

这所有一切很平衡，缓冲队列重载可以防止执行100个程序用100个重绘命令。

Blender的“空间”（spaces）是另外一个新的定义以区别“窗口”（window）。决定是：完全从屏幕/区域系统中分离在区域内运行的应用程序。这一点允许了每一个区域明显地运行任何一个程序，这一点在blender中很重要，（可以改变window的类型），一个空间被简单地定义成一下几项：

-一个spacexxx结构（在DNA_xxx_type.h内）持有永久变量，为了拷贝和存储，这些数据与保存进文件有关。

-分配，撤销，拷贝Spacexxx的方程。

-一个winhandle（）调用去处理区域事件

-一个windraw（）调用去（重）绘

-一个winchange（）调用去重新初始化窗口大小或者是其他改动。

每一个区域对于每一个space 类型存储一个Spacexxx结构（在列表内），当应用程序在区域内改动的时候就会进行存储。据一个例子：当你调用某一个SpaceFile，它可以安全地返回到原先的SpaceView3d 类型而不去做任何改动。

另外重要的一点是任何一个空间（space）都是在本地内部运行，它不会（也不应该）意识到其他编辑器的打开与否，也不会从它上面读取文件，也不会进入他们去改变他们的数据。空间（space）被当作一个独立的应用程序，在它的结构内部去存储数据，只在blender所提供的数据库工作，或者是屏幕指定的活动内容（就象活动的场景，物体）。

（读blender architecture获得更多这方面的知识）

现在仍然没有一个好的协定和文档去写出如何加一个新的space 类型，但是通过这种方式在理论上它可以与任意一个应用程序挂钩。使用调用结构可以使应用程序插入到space内。。。设想一个例子：加一个 internet浏览器或者是文字编辑器或者是中端会发生什么情况。你自己的桌面环境！！??

Blender远没有完美，所有你可以看到有许多的古老的对系统得滥用，尤其是全局变量。。编辑模式和面选择就是这样。在按键面板中的一些工具的执行是另外一个例外，工具本应在3d窗口下工作，但是另外一些的space类型进入了这些工具。消除这些问题是2.3版本工程的一部分，试图保持使用的内容尽量易懂。

丑陋的全局结构

任何一个好的结构的程序是去限制使用全局变量而得到绝对最小化。一个惩罚就是重新编译，还会有一些意外发生。

现在因为是只有使用一个屏幕或者一次只用一个屏幕，blender的屏幕管理在G结构中有许多“有用的”全局变量。

纵观代码你可以看见“G.vd”和”G.sipo”等的使用。有一些指向*活动*Space结构的指针，他们由屏幕管理器在鼠标移动和区域处理队列或重绘的时候设置。用这一些变量的任何代码100%的属于它自己的space类型。没有一个G.vd（View3D）在按键，文件选取，脚本space 等的地方被允许进入，因为没有被定义（或者可以甚至为0）。这是一个在blender的代码中普遍的错误而且经常导致bug和crash的发生。 Python窗口模块也使用了它，它应该被移出掉。

如何继续

在以下的一些地方还需要有工作要做：

-移除荒谬的5层窗口封装的概念

-对space设计一个新的方法去处理队列（用动态事件处理器）

-设计一个新的方法让Python能连接到每一个space上面（可以变为事件处理器）

（译者：有些可能在新版本中已经得到解决）。