docs: add RFC documentation for 3.x version

docs/rfcs/0000-template.zh-cn.md

@@ -0,0 +1,58 @@
+# 标题
+
+- 开始日期：（填写今天的日期，YYYY-MM-DD）
+- 目标主要版本：(2.x / 3.x)
+- 参考问题：（填写现有的相关问题，如果有的话）
+- 实现 PR：（留空）
+
+## 概括
+
+功能的简要说明。
+
+## 基本示例
+
+如果提案涉及新的或更改的 API，请包括一个基本代码示例。
+如果不适用，请忽略此部分。
+
+## 动机
+
+我们为什么要这样做呢？ 它支持哪些用例？ 什么是预期
+结果？
+
+请重点解释动机，以便如果不接受此 RFC，
+这种动机可用于制定替代解决方案。 换句话说，
+枚举你试图解决的约束而不耦合它们
+与您想到的解决方案密切相关。
+
+## 详细设计
+
+这是 RFC 的大部分内容。 为某人详细解释设计
+熟悉 LCUI 才能理解，对于熟悉的人来说
+实施实施。 这应该进入细节和极端情况，
+并包括如何使用该功能的示例。 任何新术语都应该
+在这里定义。
+
+## 缺点
+
+我们为什么*不*这样做？ 请考虑：
+
+- 实施成本，包括代码大小和复杂性
+- 提议的特性是否可以在用户空间实现
+- 对教人 LCUI 的影响
+- 将此功能与其他现有和计划中的功能集成
+- 迁移现有 LCUI 应用程序的成本（这是一个重大变化吗？）
+
+选择任何路径都需要权衡。 尝试在此处识别它们。
+
+## 备选方案
+
+还考虑了哪些其他设计？ 不这样做有什么影响？
+
+## 采用策略
+
+如果我们实施这个提案，现有的 LCUI 开发人员将如何采用它？ 是...
+这是一个破坏性的改动？ 我们可以写一个 codemod 吗？ 我们能否为它所取代的原始 API 提供一个运行时适配库？ 这将如何影响 LCUI 生态系统中的其他项目？
+
+## 未解决的问题
+
+可选，但建议用于初稿。 设计的哪些部分仍然存在

docs/rfcs/README.md

@@ -0,0 +1,3 @@
+# LCUI RFCs
+
+[中文](README.zh-cn.md)/**English**

docs/rfcs/README.zh-cn.md

@@ -0,0 +1,96 @@
+# LCUI 意见征集
+
+**中文**/[English](README.md)
+
+许多改动，包括错误修复和文档改进，都可以通过正常的 GitHub/Gitee 拉取请求工作流程实施和审查。
+
+虽然有些改动是“实质性的”，但我们要求这些改动经过一些设计过程，并在 LCUI 核心团队中达成共识。
+
+“RFC”（意见征集）流程旨在为新功能进入项目提供一致且受控的路径。
+
+## RFC 生命周期
+
+- 待处理：当 RFC 作为 PR 提交时。
+- 已生效：当 RFC PR 已合并、且正在实施时。
+- 已落地：当 RFC 提议的更改在实际版本中发布时。
+- 已拒绝：当一个 RFC PR 在没有被合并的情况下被关闭。
+
+[活跃的意见征集稿列表](https://gitee.com/lc-soft/LCUI/pulls?search=%E5%BE%81%E6%B1%82%E6%84%8F%E8%A7%81)
+
+## 贡献者协议 (CLA)
+
+为了接受你的拉取请求，我们需要你提交贡献者协议。如果你是第一次提交拉取请求，请告诉我们你已完成 贡献者协议签署。
+
+[点击此处签署你的贡献者协议](https://gitee.com/organizations/lc-ui/cla/lcui-cla)
+
+## 何时遵循此流程
+
+如果你打算对 LCUI 或其文档进行“实质性”改动，则应考虑使用此过程。
+
+构成“实质性”变化的内容是根据社区规范不断演变的，但可能包括以下内容：
+
+- 基于新 API 接口实现的新功能
+- 删除已作为发布渠道的一部分提供的功能
+- 引入新的惯用用法或约定，即使它们不包括对 LCUI 本身的代码更改
+
+一些更改不需要意见征集：
+
+- 改写、重组或重构
+- 添加或删除警告
+- 添加的内容只会被其他 LCUI 实现者注意到，而对 LCUI 用户是不可见的
+
+## 为什么你需要这样做
+
+为了提升稳定性，更多地考虑我们所做的每一项更改对最终用户可能造成的影响，另一方面，也需要防止新 API 变得更复杂。
+
+在 LCUI 的 2.x 版本之前，所有改动都没有文档，其中有些改动并没有经过认真思考和设计，在后期维护时，它们会阻碍我们理解相关需求和设计意图。对于用户而言，我们希望公开 LCUI 已实施的和待实施的改动，以征求更好的改进意见，让新增的改动内容更稳定可靠，而不是像以前那样随便增加了一些没有文档的功能，然后又随便删掉，又或是推倒重写。
+
+此外，在对 LCUI 进行更改时，RFC 流程可以引导你完成我们的思考过程，这样我们就可以在讨论为什么或为什么不应该进行这些更改时达成共识。
+
+## 在提交前收集反馈
+
+在深入研究 RFC 所需的 API 设计细节级别之前，获得对你的概念的反馈通常很有帮助。你可以在此仓库上提出问题以展开讨论，目标是最终制定具有特定实现设计的 RFC 拉取请求。
+
+## 流程是什么
+
+简而言之，要将主要功能添加到 LCUI，首先必须将 RFC 作为 markdown 文件合并到此代码库中。届时 RFC 的状态是“已确认”并且可能以最终包含到 LCUI 中为目标来实现。
+
+1. 基于此代码库中的模板 (`0000-template.zh-cn.md`) ，在新的 Markdown 文件中撰写你的提案。
+    - 注意细节：RFC 没有提供令人信服的动机，没有展示对设计影响的理解，或者对缺点或替代方案不诚实，往往不会被接受。
+1. 在[讨论板块](https://github.com/lc-soft/LCUI/discussions)中打开一个新主题帖，并确保将类别设置为“RFC Discussions”。
+    - 在讨论主题帖中建立共识并整合反馈。 获得广泛支持的 RFC 比那些没有收到任何评论的 RFC 更有可能取得进展。
+1. 如果提案收到社区成员的极大兴趣和普遍积极的反馈，你可以准备一个 拉取请求：
+    - Fork 此仓库。
+    - 创建你的提案并命名为 `active-rfcs/0000-my-feature.md` (其中的 "my-feature" 对提案的描述，而编号无需指定)。
+    - 提交拉取请求。确保它链接到讨论帖。
+1. 最终，核心团队将确定是否纳入 LCUI 中的候选 RFC。
+    - RFC 可根据核心团队和社区的反馈进行修改。重大修改可能会触发新的最终评论期。
+    - RFC 在公众讨论已经解决并且评论总结了拒绝的理由之后可能会被拒绝。然后，核心团队的一名成员应该关闭 RFC 的相关拉取请求。
+    - RFC 可能会在其最终评论期结束时被接受。 核心团队成员将合并 RFC 的相关拉取请求，此时 RFC 将变为“已生效”状态。
+
+## 有关活动 RFC 的详细信息
+
+一旦 RFC 生效，作者就可以实现它并将该功能作为拉取请求提交到 LCUI 存储库。 变为“生效”意味着核心团队已经原则上同意并愿意合并它，并不意味着该功能最终会被合并。
+
+此外，给定的 RFC 已被接受并处于“生效”状态这一事实并不意味着分配给其实现的优先级是什么，也不意味着当前是否有人正在处理它。
+
+后续的 PR 可对生效的 RFC 进行修改。我们努力以反映功能最终设计的方式编写每个 RFC；但是这个过程的性质意味着我们不能期望每个合并的 RFC 都能实际反映下一个主要版本发布时的最终结果；因此，我们尝试按计划使每个 RFC 文档与语言功能保持同步，并通过对文档的后续拉取请求来跟踪此类更改。
+
+## 实现 RFC
+
+RFC 的作者没有义务实施它。 当然，欢迎 RFC 作者（像任何其他开发人员一样）在 RFC 被接受后发布实现以供审查。
+
+一个生效的 RFC 应该有指向实现 PR 的链接（如果有的话）。 对实际实现的反馈应该在实现 PR 而不是原来的 RFC PR 中进行。
+
+如果你对“活跃”RFC 的实现感兴趣，但无法确定其他人是否已经在处理它，请随时提问（例如，通过对相关问题发表评论）。
+
+## 审查 RFC
+
+核心团队的成员将尝试定期审查一些已打开的 RFC 拉取请求。 如果核心团队成员认为 RFC PR 已准备好接受进入生效状态，他们可以使用 GitHub/Gitee 的审查功能批准 PR，以表示他们批准了 RFC。
+
+## 参考
+
+LCUI 的 RFC 流程及文档内容参考自：
+
+- https://github.com/reactjs/rfcs
+- https://github.com/vuejs/rfcs

docs/rfcs/active-refs-cn/0001-style-guide.md

@@ -0,0 +1,115 @@
+# 编码规范
+
+- 开始日期：2023-03-26
+- 目标主要版本：3.x
+- 参考问题：无
+- 实现 PR：无
+
+## 概要
+
+参考其它 C 开源项目，重新制定统一的编码规范。
+
+## 基本示例
+
+```c
+typedef enum parser_state_t {
+        PARSER_STATE_START,
+        PARSER_STATE_DATA_BEGIN,
+        PARSER_STATE_DATA_END,
+        PARSER_STATE_ERROR
+} parser_state_t;
+
+typedef struct parser_t {
+        /** 解析器状态 */
+        parser_state_t state;
+
+        /** 当前字符 */
+        char *cur;
+} parser_t;
+
+parser_t *parser_create(void)
+{
+        parser_t *parser;
+
+        parser = malloc(sizeof(parser_t));
+        parser->state = PARSER_STATE_START;
+        parser->cur = NULL;
+        return parser;
+}
+```
+
+## 动机
+
+2.x 版本的代码风格不一致，包含了驼峰、小写下划线风格以及各种命名规则，导致源码阅读体验和接口使用体验较差。
+
+## 详细设计
+
+使用 clang-format 工具对源码进行格式化，其配置文件 `.clang-format` 存放于源码根目录中。
+
+由于预设的格式化规则已经满足此编码规范的大部分要求，以下仅对需要在编码时注意的规范进行简单说明，不再详细说明规范的全部内容。
+
+### 命名
+
+常见的 C 语言开源库的编码风格大都是蛇形命名法(`snake_case`)，例如：[libgit2](https://github.com/libgit2/libgit2)、[cairo](https://www.cairographics.org/)、[leveldb](https://github.com/google/leveldb/blob/main/include/leveldb/c.h)，因此，LCUI 项目也采用该编码风格。
+
+由于 LCUI 已被拆分为多个子库，这些库内的标识符不再需要添加 `LCUI_` 前缀。
+
+类型名以 `_t` 结尾，例如：
+
+```c
+typedef struct foo_t {
+        int bar;
+} foo_t;
+```
+
+宏定义和枚举采用大写下划线命名法，例如：
+
+```c
+typedef enum pd_color_type_t {
+	    PD_COLOR_TYPE_INDEX8,
+	    PD_COLOR_TYPE_GRAY8,
+	    PD_COLOR_TYPE_RGB323,
+	    PD_COLOR_TYPE_ARGB2222,
+	    PD_COLOR_TYPE_RGB555,
+	    PD_COLOR_TYPE_RGB565,
+	    PD_COLOR_TYPE_RGB888,
+	    PD_COLOR_TYPE_ARGB8888
+} pd_color_type_t;
+
+#define PANDAGL_VERSION "0.1.0"
+```
+
+### 注释
+
+推荐写在代码行上面：
+
+```ts
+struct foo {
+        /** comment */
+        int bar;
+
+        /** string */
+        char *str;
+}
+```
+
+不推荐写在右侧：
+
+```ts
+struct foo {
+        int bar;    /**< comment */
+        char *str;  /**< string */
+}
+```
+
+### 缩进
+
+为确保代码在网页端和编辑器内的显示效果一致，以八个空格为一个缩进层级，不使用制表符缩进。
+
+## 缺点
+
+改动很大，涉及几乎所有代码，从 2.x 版本迁移到 3.x 版本需要参照头文件内容对旧的标识符进行全局替换。
+
+## 备选方案
+
+全部采用驼峰命名。

docs/rfcs/active-refs-cn/0002-architecture.md

@@ -0,0 +1,102 @@
+# 架构
+
+- 开始日期：2023-03-26
+- 目标主要版本：3.x
+- 参考问题：无
+- 实现 PR：无
+
+## 概要
+
+重新设计源码目录结构，将 LCUI 拆分为多个子库，重构部分模块以减少不必要的耦合。
+
+## 基本示例
+
+新的目录结构：
+
+```text
+docs/
+examples/
+include/
+lib/
+    css/
+    pandagl/
+    platform/
+    thread/
+    timer/
+    ui/
+    ui-cursor/
+    ui-server/
+    ui-widgets/
+    ui-xml/
+    worker/
+    yutil/
+src/
+tests/
+```
+
+更精简的头文件路径：
+
+```c
+// 之前
+#include <LCUI/util.h>
+#include <LCUI/display.h>
+#include <LCUI/graph.h>
+#include <LCUI/widget.h>
+#include <LCUI/css.h>
+
+// 之后
+#include <yutil.h>
+#include <platform.h>
+#include <pandagl.h>
+#include <ui.h>
+#include <css.h>
+```
+
+## 动机
+
+图形处理、系统窗口管理、输入输出管理等功能已经有更好的开源实现，继续维护和改进它们只是在浪费时间，而且 LCUI 项目维护人员的兴趣并不在底层功能模块上面。因此，LCUI 应该被拆分成多个较为独立、通用的子库，以便于他人根据自身的需要，对 LCUI 进行定制、裁剪，又或是只使用部分子库。典型的适用场景包括：
+
+- 单独构建 PandaGL 图形库，在应用程序中调用它的接口实现简单的图像编辑和文字渲染。
+- 基于 SDL 实现一系列与平台库 libplatform 相同的接口，使 LCUI 应用程序能够将 SDL 作为后端来为图形界面的各项能力提供更好的支持。
+- 在其它 UI 库中使用 LCUI 的自绘组件。
+
+简而言之，这是为了扩大 LCUI 的受众范围，使其从面向单一 UI 开发需求的 UI 库项目，转变为面向多种需求的项目集。
+
+## 详细设计
+
+新增 lib 目录用于存放子库，子库的目录命名和结构如下：
+
+```
+[libname]/
+    include/
+        [libname]/
+            config.h
+            foo.h
+            bar.h
+        [libname].h
+    src/
+        config.h.in
+        foo.c
+        foo.h
+        bar.c
+        bar.h
+    xmake.lua
+```
+
+源文件的私有接口声明在同目录同名头文件中，而公开接口则声明在 `include/[libname]` 目录中的同名头文件内。
+
+`src` 目录中存放这些子库共同运作所需的代码，包括初始化应用程序资源、字体、主循环、窗口管理等。
+
+为明确依赖关系，子库的依赖库都由它的 xmake.lua 配置引入。
+
+## 缺点
+
+无。
+
+## 备选方案
+
+无。
+
+## 采用策略
+
+这是个破坏性改动，从 2.x 版本迁移到 3.x 版本需要更新头文件包含代码。