【备份】计划开发一个窗口管理器——某些大佬的回答

这个不是我写的，以下仅为备份，以后有时间弄窗口管理器再复习。
原地址：http://tieba.baidu.com/p/1454823621 #21楼

难得现在还能碰到想写窗口管理器的朋友

基于XServer天生的网络透明性，窗口管理器不用和其它XClient运行在同一台主机上，它们只是共享同一个XServer而已，同时最基本的窗口管理器仅仅负责绘制窗口边框，包括标题条，按钮等。因此 X 架构的灵活性决定了编写窗口管理器并不是一件非常复杂的事情。窗口管理器就是一个普通的XClient。

窗口管理器 XClient 和普通的 XClient 最大的区别就是在调用 XCreateWindow() 时，需要将最后一个参数 XSetWindowAttributes *attributes 中的 Bool override_redirect 设置为真，这样以后XServer 执行其它 XClient 调用的 XCreateWindow() 请求时就会将请求重定向到设置了 override_redirect 的 XClient, 也就是窗口管理器进程，窗口管理器进程则为这个窗口创建一个父窗口，也就是边框窗口，至于你想怎么玩，那就由得你发挥想象力了，比方说你可以参照科幻电影中的风格，将窗口边框设计的“科幻”无比（我自己的窗口管理器就是按照美剧《星际之门–亚特蓝蒂斯》中外星城市中的操作界面设计的），也可以将朴素的看不到任何边框，全部靠热键驱动，满足键盘狂人的需要。甚至根据运行 XClient 所在的主机（IP地址），或者执行XClient的用户帐户（用户ID）画出不同颜色不同风格的窗口边框，让人一看就知道这个XClient来自何处，主要是做什么的，是由谁在用。还有布局控制，将界面上显示的XClient 窗口按某种布局方案控制，如平铺、摘要窗口显示等等，至于实现成TAB风格自然就更不在话下。甚至还可以将自己需要的东西集成在其中，比方说Javascript引擎，Sqlite 数据库实现在其中，完成用Javascript脚本来动态配置窗口管理器，实现特定的布局方案等。或者将输入法集成其中以支持特定的输入法，甚至将 HTTP 客户端或其它协议的客户端集成在其中等等。总之正是这种机制使得窗口管理器可以“任意宰割”普通XClient创建的窗口，控制普通XClient的输入输出。也因此每个XServer任何时刻只能存在一个窗口管理器进程，因此窗口管理器在运行时需要首先检查一下XServer上是否有其它窗口管理器在运行，具体的方法是检查一下XServer中DefaultRootWindow()窗口属性是否中 override_redirect 是否被设置为真。如果已有窗口管理器在运行，那要么显示出错信息退出，要么干脆发送 kill 信号宰了它（有权限的话）。

虽然最简单的窗口管理器并不难写，但要写出一个比较可靠的窗口管理器也并不是那么简单的。因为 X 架构设计年代较早，它缺少现代图形界面普遍存在的一些特性，比方说实现类似于 Windows 下普遍使用的 MDI 窗口风格时，由于 MDI 的子窗口需要直接由 MDI 父窗口控制，造成和 X 架构创建边框窗口的机制相冲突，实现起来就比较麻烦。同时X架构在设计之初并没有考虑当前图形界面普遍支持的桌面概念，因此相比当前的其它图形界面如Windows, MacOS 等来说，X 在XClient进程间数据通讯方面缺乏统一的标准，在X环境下不同的桌面环境如KDE，GNOME之间的相互通信是比较麻烦的。也就是说我们习惯的类似拖拽操作在 X 下实现起来是比较罗嗦。类似的麻烦还包括输入法实现等等。

为了解决这一系列的问题，freedesktop 已经为此创建了一系列规范，在设计时应尽量参考之，具体的内容可以参考 freedesktop 官方网站的具体内容，尤其需要注意窗口管理器处理 MDI 风格的规范，否则会导致使用 MDI 风格的 XClient 工作异常。

因为窗口管理器并不一定需要涉及需要QT，GTK之类的桌面环境提供的现成窗口组件，所以直接用XLib 完全可以。当然需要的话也可以使用QT，GTK之类，这并没有什么本质区别，只是创建窗口管理器本身需要使用的对话框之类时更加便利一点而已。在这里本人建议LZ尽量用XLib开发，这样可以不依赖于QT，GTK库，毕竟不是任何主机都一定会安装这些图形库的。

再多说几句：数年前因为工作需要本人必须解决十数种不同的unix系统或类unix系统上的中文输入法的统一解决方案，但现成的中文输入法解决方案无法通用到所有的unix版本上。因此在经过一段时间的构思后，最终将解决方案定位在窗口管理器上，设计了自己的窗口管理器版本–mwt，替换了机房所有unix版本中的窗口管理器，将输入法实现在窗口管理器中，词库和字体库以及窗口管理器的配置脚本则由专用服务器–mws统一管理。最终使得所有unix图形界面下都支持中文输入，并能自由切换窗口风格和布局控制，虽然只能工作在 mws + mwt 体系下，不具备泛用性，但感谢X架构的无比优秀，终究解决了那些让人头疼无比的一大堆unix版本中的统一架构的中文输入法支持问题，同时也给自己做了一个“科幻”到让同事们眼红的窗口管理器。

祝LZ早日实现自己的目标。

一般来说，试图自行开发一个新的窗口管理器不外乎以下几个原因：

1、希望拥有一款与众不同的窗口管理器

这种想法是受图形界面丰富的表现形式所影响，希望把自己对图形界面的理解外化出来，以彰显自己独特的品位。但这种想法恰恰反应了使用者对图形界面较为肤浅的认识。他们只注意图形界面在彰显个性上的作用，反而忽略了图形界面出现的本质：提高易用性。其结果就是把个图形界面弄的花里胡哨，甚至影响到了实际使用效果。

对于这种情况，我认为要做的事情不是开发新的窗口管理器，而是先抑制住自己浮躁的心理，认认真真地去用上几款现成的窗口管理器。随着对窗口管理器理解的深入，自然拥有了所谓的与众不同的能力。

2、希望使用某种窗口管理器，但又不想花费精力去熟悉和自己的使用习惯不符的特性

这种想法骨子里是对开发窗口管理器的投入缺乏清醒的认识，认为自行开发一个窗口管理器来满足自己需求在开销上小于学习一个现成的窗口管理器。实际上，受惠于 X 的优秀架构，开发一个简单的窗口管理器是很容易的，但 X 架构的古老和现代图形环境的复杂性使得发展一个窗口管理器却需要很大的投入。这种投入远远高于学习一个自己不习惯的窗口管理器。

对于这种情况，我认为要做的事情也不是开发新的窗口管理器，而是放弃先入为主的观念，将这款窗口管理器的所有特性摸熟，这不光能提高自己对窗口管理器的认识，还能提高自己的工作效率。

3、对现有的窗口管理器的某些特性不满

每一款流行的窗口管理器都有着明确的设计目的，因此它们也有着明确的适用范围，所以当用户的工作需要与设计者的工作需要无法100%重合时，即会产生这种情况。

我认为这个时候不应该急着去设计一款新的窗口管理器，而是应该仔细考虑考虑，对这些个特性不满到底是因为这些特性与自己的需求相矛盾，还是自己对这些特性的理解不够深入。如果是前者，那可以考虑和窗口管理器的作者沟通，看是否能得出一些双方都认可的结果。如果无法得到需要的结果再考虑自行开发不迟。如果是后者，那需要做的是深入学习该款窗口管理器，也许随着深入理解后会真正接受这些特性。

4、对图形界面有着自己的理解，而现成的窗口管理器又无法满足自己的需要

经验丰富的专业用户，他们对图形界面环境的设计和使用往往有着自己的理解和实际需求，他们通常掌握了对图形界面环境的架构和设计上比较完善的理论，对图形环境实际使用的环境有着非常深入的认识。同时他们对现存的图形界面环境也有着比较深入的理解。这使得他们有足够的把握去判断是否需要开发一款新的窗口管理器来满足自己的需求。

对于这种情况，开发一个满足需求的窗口管理器几乎是势在必行的，同时对于这一类用户来说，良好的专业素养也使得他们开发一个窗口管理器的难度比较低。

再多说几句：我本人之所以开发 mwt 这个可以兼做窗口管理器使用的多用途终端，最大的原因还是因为相对复杂的使用环境。在工作上为了管理在地理位置上分布非常广的数千台主机，我需要同时使用包括安装了 FreeBSD, Linux, Windows, MacOS，Android 的主机、笔记本、平板机、手机、以及家里用于工作的主机和总数多达14台，这还不包括提供后台服务的通用服务器和定制服务器。为了提高工作效率，我必须为这14台计算机上创建一个统一的操作界面以提供一致的操作体验。到目前为止，没有任何一种单一的解决方案能满足这种横跨多种不同系统的需求，所以才诞生了 mwt 这么一个集成了数十种功能的“怪物”。

因此，我强烈建议想自行开发窗口管理器的用户先仔细评估一下，自己是否真的需要一款独特的窗口管理器，是否拥有足够的实力去开发一款新的窗口管理起，是否愿意为维护一个窗口管理器投入多年的精力。最重要的是：将宝贵人生中本来就很有限的精力花在这个窗口管理器上，是否值得！！！