拿 Pixel 举例子是不知道 Nexus ？

1. 一般改配置就可以直接修改高度
2. 你想要的是 panel 不要显示 Task Bar，还是要做成 Mac/Ubuntu 里面 Menu Bar 的效果（ Ubuntu 之前有和 Mac 差不多的 Menu Bar，但是后来好像没了，和 GNOME 统一了，应该是和 Unity 有关）？前者可以想办法把 Task Bar 这个组件删掉（配置里删掉，如果不行的话代码里删掉），这样就能做到“一个打开的应用同时显示在 dock 和 bar 里面”。
后者稍微麻烦一点，需要类似 #2 的东西，但是这个东西在 Linux 下并不完美（应该也是和 Unity 退潮有关）。

当然我会考虑你把 Task Bar 干掉之后用什么来填充这个空间（绝大多数情况下 Menu Bar 不能完全填满 1366 以上宽度的显示器，#2 那个 GNOME 截图到处都是反生产力的设计，还填不满 1920 屏幕的一半）。可以不填充就留着空白，但是对于我来说这是空间的浪费。如果是 /r/unixporn 的话，可能会考虑显示个网速，音乐播放控制之类的。
哦，我的选择是不用 Dock，因为 Dock 也是反生产力的（尤其在“同一应用的多个实例同时存在”的情况下）。把 Menu Bar，Task Bar 和 Status Bar 放到一起，最大限度节省空间。

3. Workspace Switcher 以文本方式显示，在 tiling 向的 panel 里面比较多见。原因可能是此类 panel 避免了一般客户端软件“把用户当傻逼”的设计思路（但是依然无法避免固有思维的影响，比如绝大多数此类 panel 也并没有啥图形能力）。而在主流偏向于“把用户当傻逼”的软件中做到可能比较难。我没用过 Cinnamon，楼主可能要做好改源码的准备（ https://old.reddit.com/r/gnome/comments/a6hjdp/display_workspace_names，对应到 Cinnamon 好像应该是 https://github.com/linuxmint/cinnamon/blob/8fbdd45740e09448f266a567f32037d2497f4752/files/usr/share/cinnamon/applets/workspace-switcher%40cinnamon.org/applet.js#L223 ）。

有趣的是，在非 tiling WM 的 panel 中更流行的好像是 graph 形式的显示，比如这个 fvwm 的截图（ http://www.xwinman.org/screenshots/fvwm2-taviso.png ，http://www.xwinman.org/screenshots/fvwm2-karl.jpg ），Cinnamon 和 xfce 也有类似功能。但是好像很少有把两者结合的（上面说了，tiling WM 用的 panel 基本没有图形能力），虽然我用 tiling WM，但是和 tiling WM 的典型目标用户不同，我目前没有给 workspace 设定特定的用途，因此 graph 对我更有用。

@KentY 这个其实不能叫“美化”，因为直接和交互逻辑相关，不是纯样式的东西。

说起来，今年又是 Linux 桌面元年呢

理论上，这些死宅用的东西在这时候应该是涨价的

你问对时候了，新鲜出炉的： http://www.yinwang.org/blog-cn/2020/02/05/how-to-read-code

Org 有个硬伤文章里面好像没提：只能 PC 用

当然这个并不是绝对的，比如 WebKit 这种项目分成 WTF、WebCore、JavaScriptCore、WebKit 等很多子项目，子项目之间依赖非常紧密（假设把这些项目单独分成几个 repo 的话，某开发者放假回来忘记 pull 其中一个项目，就可能 build 不过），一个 CMake 全都 add_subdirectory 进来就得了。

但是 WebKit 用了 sqlite，这个就用系统的就行。

没用过 Travis CI，但是 CMake 没见过 FetchContent 用得多的。一般 CMake 是假设你系统（或者你的配置里）已经有了现成的依赖，然后再去 find。CMake 是个 build system，不是 package manager。

感觉楼主需要做的是把依赖从 CMake 的 build 中剥离出来单独 build，这样就可以满足“在一个独立的目录中”的条件了。

我倾向于避免把依赖都放在一起 build，因为我用这类工具的经验是如果用得频繁，它们（大多数）都会日常抽风，抽风的最简单解法就是删掉所有 cache 重来，这样我就必须最小化每次 full build 的时间。

亲你好可以的，只是需要多用两年才能解锁哦

一般课程应该不会讲到 Monad Transformer 以后

老实用 Promise 不好么……

@lzwt806 你直接搜 gelf.h 呗，应该是 libelf 的

如果你主要是偏展示和交互而不是复杂 geometry 的编辑的话，游戏引擎应该会更适合

大多数 DCC 都是给你一个现成的应用，然后你想办法 integrate 进你的 workflow。游戏引擎灵活得多

@matafu 这不是一个算法么怎么画 …

该不会你要把软件 script 成你想要的样子吧

@lzwt806 你是 4.0.0 啊 … 那就不知道了，现在早就 CMake 一把梭了，除了 CMake 没别的依赖。
另外 LLVM 本身不直接依赖任何驱动。
“—enable-llvm is required when building r300”是说你编译 mesa 的时候要把 —enable-llvm 这个 flag 加进去。r300 和 r600 应该是不同的驱动

llvm-config 是 LLVM 的编译产物之一，属于 LLVM 库，不是单独下载的。单独的 llvm-config 没有意义

楼主到底要画啥？

@tomari 说的该不会是某莎吧 ...

我不记得 LLVM 有用到 Perl ...
另外 llvm-config 是要你自己编译的