Beta发布声明

一、新功能和特性

$$Nurtureinsightswithoutboundaries.$$

1.1 功能描述

榕树模式

榕树的生成

榕树模式是文档内的一种编辑模式，在这种模式下，文档会被展示成一棵结构化的榕树。

树的非叶子节点包括：

• 各级标题
• 列表虚拟节点（这是因为在 markdown 中没有像 latex 一样的 itemize 一样的总体结构）

树的叶子节点包括：

• 文本段
• 数学块
• 代码块
• 引用
• 列表
• 表格

需要注意的是，以下 md 实体并不是叶子节点：

• 加粗
• 斜体
• 下划线
• 链接
• 图片

对于如下 md 源码

# 一级标题 1

## 二级标题 1

`int main(){return 0;}`

$$
1 = 1 + 1
$$

### 三级标题 1

一段文字

> 一段引用

## 二级标题 2
- item1
- item2
- item3
# 一级标题 2

生成如下 Ficus 树：

需要注意这是一颗有序树，也就是兄弟节点之间是有顺序的。

榕树的展示

榕树模式大大增强了文档的架构展示，让原本线性的文本变成了更加有逻辑的树形结构。

为了方便用户更加直观和全面的了解文章的架构，我们增设了许多功能来帮助用户。

节点折叠展开：

当节点折叠时，它的孩子节点会被隐藏；当节点展开时，它的孩子节点会被显示。

我们有两种方式进行节点的折叠和展开：

第一种是直接在图上点击节点右侧的 ‘+’ 或者 ‘-’ 进行展开或者折叠

第二种是在左侧的工具栏处对于整体榕树进行统一的折叠和展开操作：

榕树样式选择：

我们为榕树的展现形式提供了多种样式，您可以在工具栏中从 5 种样式中进行选择：

榕树的编辑

这棵树不仅有展示功能，您还可以通过拖拽对其进行编辑操作，所有的操作都会被同步到文档中：

• 平级交换：通过拖动节点，您可以互为兄弟的节点交换顺序
  

• 层次改变：您可以将标题类节点拖动到其他标题类节点上，此时这个节点会转变成目标节点的孩子，相应的
  

• 内容修改：您可以点击节点，并修改他们的内容
  

此外，用户还可以通过右键菜单进行更加准确的操作，右键菜单如图所示：

榕林模式

榕林的初衷

受制于一些客观条件，我们可能会写很多个细碎的文档，或者写一个很冗长的文档，这些“畸形”的文档如果一个个的整理，并不是一件容易的事情。

榕树提供将多个文档展现在一个“工作平台”，这样就可以同时对多个文档进行编辑操作。我们对于每一个文档都以“榕树”的形式展示，多棵榕树组成了“榕林”。

当我们在榕林上完成操作后，确定没有问题后，可以将榕林的结果导出到指定文件夹，目前是 .\out 文件夹。

榕林的选择

如何选择进入榕林的榕树们呢？我们提供了两种模式：

• 榕根选择：用户可以根据榕根（后文会有介绍）逻辑对进入榕林的文件进行选择
• 榕柱选择：用户可以根据榕柱逻辑对于进入榕林的文件进行选择

用户可以在侧边栏处选择对应的模式和具体进入的文件，如下图所示：

榕林的操作

榕林内的操作基本上和榕树相似，只有以下几点不同：

• 榕林不允许直接添加与 Forest 相连的子节点，这些子节点代表文件本身。被称为“基底”。
• 增加基底需要通过侧边栏按键。
• 如果不满意当前的榕树们，可以用“清除”按钮将榕林清空。

当编辑完成后，即可点击侧边栏的“导出”按钮进行导出。在榕林上进行的编辑操作，并不会修改原本的文档。

榕林的局限性

按照最开始的设计，榕林并不应该是直接导出的形式，但是考虑到如同图片、引用这类的非文本本地资源，如果直接在文档本身进行操作，会导致“资源引用”发生错误。后来才采取了“导出”的形式，希望将资源和文档一起导出，避免了资源的引用错误。

但是实际上我们的导出功能也没有办法追踪资源位置，导致采用相对路径的资源依然会出现错误。但是“导出”的形式为后续的开发提供了一种实现的可能性。

榕图模式

您可以通过榕图查看和编辑文档间联系，文档间联系有三种类型：

• 榕根 (ficus root)：表示文档在文件系统中的组织关系
• 榕柱 (ficus prop)：文档与标签（tag）间的联系
• 榕须 (ficus aerial)：文档间的引用关系和被引用关系

当您打开一个文件夹，并且在侧边栏中选择榕图侧边栏，即可以进入以当前文件夹为榕图中心点的榕图。您可以通过点击图中的节点进行聚焦，榕图上会高亮聚焦节点和与之相关的节点。

在榕图侧边栏的会显示当前节点的信息和他的邻居组，您可以通过可视按钮控制榕图上节点的显示控制文档节点的显示。并且选择一些对应的关系转换操作。

榕根

榕根的定义

榕根的本质是文件系统的关系，如果一个子文件或者子文件夹属于一个父文件夹，那么在父子之间就会存在一条榕根。

榕根是一种 MECE 的体现，榕根是完全的树形结构，符合“不遗不漏”的原则。榕根的建立其实是归档的过程，将笔记按照唯一的原则进行归档，方便笔记体系的结构化。

榕根的展示

对于如下目录结构：

fgraph-demo
├── dir1
│   ├── doc2.md
│   └── doc3.md
├── dir2
│   ├── doc4.md
│   ├── doc5.md
│   └── doc6.md
└── doc1.md

应形成如下结构

其中图上的“箭头静态实线”表示榕根。fgraph-demo的榕根已经被加粗紫色高亮。

榕根转榕柱

对于文件夹节点，我们可以对其执行“转变为tag”操作，则当前节点的榕根都会转变为榕柱，我们对于 dir1 节点执行这个操作，效果如图：

转变前：

转变后：

这种操作可以改变笔记的归档结构，结合“榕柱转榕根”的操作，可以方便地进行归档文档的整理和变更工作。

榕柱

榕柱的定义

由单层 tag 组织起来的 Ficus 关系，一个 md 文档可以具有多个 tag。一个 tag 对应一个节点，所有具有该 tag 的文档与这个 tag 节点间都有一条边。可以被看做一种以 tag 为中心的星形图。

榕柱是一套标签系统，这套系统相对于榕柱，体系感会减弱，但是会更加适合知识的检索。

可以在侧边栏中用标签管理器创建 tag，而且创建好的 tag 会显示在文档头部。当然也可以直接在文档头部添加 tag，语法如图所示

// doc4.md
---
tags:
  - tag3
  - tag1
---

榕柱的展示

在上文中的目录结构，tag 情况如下：

• doc4.md: tag1, tag2
• doc5.md: tag2 , tag3
• doc6.md: tag1, tag3

此时的 Ficus 柱如图所示：

其中图上的“圆点动态实线”为榕柱，tag2的榕柱已经被黄色加粗。

榕柱转榕根

对于当前 tag 节点，我们可以对其执行“转变为文件夹”，效果如图：

转变前：

转变后：

可以转变的的榕根的节点需要在同一路径下，我们将在不同路径下的节点分在了不同的组中。

榕根体系相对于榕柱体系要更加的灵活自由，但是同样的缺少了逻辑性和体系化。利用这个功能可以将原来成熟的榕须转变成榕根，是笔记变得更加体系化。

榕须

榕须的定义

由拓展 md 语法 -[ref_name](file_path) 构建出的关系。这种关系是一种有向的关系，关系的两个端点分别是引用文档和被引用文档。

榕须所代表的引用关系，则不再具有榕根和榕柱明显的层次关系，变成了“文档与文档间”的一种关系，这种关系描述的是“知识与知识”的平级联系，而非“知识与知识标签”、“知识与知识类别”这种不平等的联系。这也是一种较为自然的联系方式，就如同我们在写论文的时候使用的“参考文献”。

用户同样可以在侧边栏中查看文档的引用和被引用关系。

榕须的展示

对于上文的示例，存在引用关系：

• doc2.md 引用 doc3.md
• doc3.md 引用 doc2.md

那么对应的 Ficus 须的结构如下所示：

其中图上的“动态虚线”为榕须，doc3 -> doc2的榕须已经被橙色加粗。

榕须转榕柱

对于当前文档节点，我们可对其执行“转变为tag”的操作，与当前文档通过榕须相关（我们提供了三种相关模式）的所有文档会被统一加上一个 tag。

转变前：

转变后：

榕须会让多个文档以“面对面”的方式组织起来，但是这样并不容易提取这个“文档群”的关键特征，“须转柱”的操作使得用户可以提取这些彼此引用的文档群的共同特征，并用一个 tag 进行标识。

1.2 应用场景

笔记内容过于零散

场景描述

阿榕平时很喜欢记笔记，每天都会将上课的收获记下来，有的时候中午追剧突然想到一个好的典故也会记录一下，但是笑笑却很不爱回看笔记，因为他的笔记都是这样的

// monday.md
“唧唧复唧唧”原来有两种解释，一种是织布机，一种是木兰的叹息声。
1 + 2 = 3

// tuesday.md
“自挂东南枝”这个典故似乎被《探清水河》化用了诶。
3 * 10 = 30

// wedsday.md
“谢公屐”是谢灵运穿的。
2^10 = 1024

分析

每一天的笔记都是很细碎的，因为人们的感官系统决定了大部分人读入信息只能以“流水账”的方式进行，但是这种线性而且杂乱的笔记，显然是不方便让人回看的。

解决方法

利用 ficus 林功能，进行文档的合并

可以看到原本每天的“流水账”变成了数学和语文两个有逻辑的 md 文档。

笔记内容过于冗杂

场景描述

阿榕平时很喜欢记笔记，但是他习惯把所有的东西都寄到一个文档中，时间长了一个 md 文档有 1 万多字，用滚轮滑都要滑很长时间，他根本不想回看。他的笔记长这样（我们挑了一个结构很清晰的，实际上阿榕的笔记没有这么有条例）

// note.md

# 网路实验入门实验内容
...
# 网路实验入门实验环境及设备简介
...
# 网路实验入门网线的制作
...
# 数据链路层实验内容
...
# 数据链路层实验以太网链路层帧格式分析
...
# 数据链路层实验 VLAN 的配置与分析
...
# 网络层实验 ARP 分析
...
# 网络层实验 ICMP 分析
...
# 网络层实验 VLAN 间通信
...

分析

人们在写笔记的时候是很难想清楚再动笔的，以一种模块化的方式去记笔记，就好像很多程序员喜欢 “一 main 到底”的程序设计思路一样，但是非结构化的笔记并不利于人们的反复观看和知识体系的构建。

解决方法

利用 ficus 林功能，进行文档的拆分。

可以看到原来 1 个文档被拆分成了 3 个有序的文档。

思路被体系限制

场景描述

阿榕是一个笔记狂人，有强迫症的他将自己的笔记管理得井井有条，但是有一天他面对罗素犯起了难。因为罗素既是一个数学家，也是一个哲学家，还是一个英国人！阿榕不知道要将罗素归到 /理科/数学 中，还是应当归到 /文科/哲学 中。

分析

“罗素问题”并不是一个个例，人们处理知识的时候，必然给这个知识建立多种的联系，这样才方便从多角度，多维度的去记忆和检索它，显然分类学的树形结构就不适合此时知识的放置。

解决方法

面对多分类问题，可以使用 fic tag 而不是文件系统，fic tag 并不是严格的树形结构，一个文档可以具有多个 tag，可以根据 tag 方便的检索出对应的知识。

单篇文档架构感弱

场景描述

阿榕是一个英语老师，她要给学生们讲授“虚拟语气”，她整理出了第一版的讲义，其架构如下

但是按照这个讲义去讲课，同学们普遍反应讲授的知识点过于细碎和零散，没有办法很好的理解。

分析

从上面的讲义的架构图就可以看出，所有的知识点都是平铺直叙的，7 个如流水账一般的知识点组成了讲义的全部，对于学生的理解难度是很大的，而且这些知识点彼此之间是有联系的，可以被组织成更加有体系感的讲义，这样会更加方便用户的理解。

解决方法

不可否认人们在输出的时候确实很喜欢平铺直叙，但是这种东西是不利于记忆和展示的，所以可以使用我们的榕树功能对文档进行重构，可以轻松将文档调整为如下架构：

自然的 md 书写体验

场景描述

阿榕是一个学过一些 markdown 语法的人，她平时很喜欢用 vscode 记 markdown 笔记，但是 vscode 会展示 md 的源码，这些符号很干扰阿榕的思路，许多图片和表格在源码模式下也很丑陋，她书写的时候没有喜悦和满足之感。

分析

源码虽然对于编程人员来说很熟悉，很有一种掌控感，但是对于更关注内容的普通用户来说，在书写的时候过多思考源码，和在书写的时候过多思考排版是同样不好的行为，这会分散用户的注意力。

解决办法

Ficus 采用的“所见即所得”是一种很好的方式，它可以尽可能像用户掩盖源码，避免写作思路的打断，渲染好的文本也可以提高用户对于文档的掌握度，增加写作的满足感。

在文档间建立联系

场景描述

阿榕在写一篇 A 文档的时候，突然想到 B 文档可以作为 A 文档的参考，但是怎么在书写中展示这件事情呢？

分析

这种情况其实描述了一种文档间联系，这是一个很正常的需求，因为知识之间是有联系的。

解决办法

Ficus 中提供了“榕须”机制来模拟这个行为，你可以在文档内使用 -[ref_name](file_path) 来引用其他文档，同时我们提供了榕须管理器，可以在其上查看文档的引用和被引用关系。在榕图上，榕须也会显示出来。

不知道如何构建体系

可以利用 fic prop 转换成 fic root 的功能进行体系化的构建，同时可以用 root 转 prop 进行撤销。

构建唯一的体系是必要的！

无法发现知识间的联系

可以用 fic aerail 转 prop 的功能，aerail 提供双链功能构建 tag。

---

二、缺陷修复

2.1 之前存在的缺陷

• 榕树和榕图模式渲染速度慢，性能差，内存占有率高
• 公式渲染器无法渲染部分公式
• 导出 PDF 存在一定的溢出问题
• XSS 攻击
• MAC 安装问题

2.2 修复方式

• 榕树和榕图模式渲染速度慢，性能差，内存占有率高：更换了新的插件，解决了性能问题
• 公式渲染器无法渲染部分公式：提供了多种公式渲染器
• 导出 PDF 存在一定的溢出问题：解决了导出问题
• XSS 攻击：将 bug 反馈给了 lute 和 vditor（导致 bug 的插件项目）
• MAC 安装问题：在官网中加入了解决补丁

---

三、运行环境

系统平台要求

Window

• 提供 NSIS 安装包，自动安装到用户 AppData 目录下。

• 支持 Windows 10/11 (x64 / arm64)，不支持 32 位系统运行。

Linux

• 提供 AppImage 发行包，可以免安装运行。

• 支持 x64 的 Linux 发行版，需要 FUSE version 2 (libfuse2) 支持。

• 在 Debian 系下的 Ubuntu 20.04.02 LTS, Ubuntu 22.04.06 LTS 上测试正常运行。

• 在 Red Hat 系下的 CentOS7 上测试正常运行。

• 在 Arch 系下的 Arch Linux, Manjaro 上测试正常运行。

Mac

• 提供 dmg 安装包，支持 Mac Silicon 以及 x64 两种体系结构。

• 支持 MacOS 10.11 (El Capitan) 以及更高版本。

• 软件未进行签名，需要进行强制安装。

硬件要求

Ficus 安装文件占用磁盘空间约 100M，安装后占用 < 300M。

推荐软件安装环境有 1G 以上的剩余磁盘空间，且有互联网连接以支持软件进行热更新（可选）。

软件使用 Chromium 内核，推荐运行时保证 1GB 以上的空闲 RAM 使用。

四、安装与使用方法

4.1 下载安装

您可以通过这个页面进行下载安装。

如果您使用的 windows，你需要选择 Ficus 的安装路径，如下所示：

我们会在桌面为您创建快捷方式，点击即可运行 Ficus。

4.2 使用

运行后原始界面如下所示，您可以选择一个工作区文件夹：

然后在侧边栏选择要编辑的界面，即可进行 markdown 的编辑：

在左上角的 ficus 图标可以点击，并展开菜单，可以完成全部工作：

在顶栏的面包屑、模式转换器，侧边栏的诸多类型，可以辅助您更快速地完成操作，请大胆尝试。

更加详细的方法可以参看我们的官网。

---

五、已知问题和限制

5.1 不在本计划内修复的问题

即时渲染模式

目前 ficus 只支持所见即所得模式，不支持即时渲染模式（这种模式更加贴合 typora）。

之所以没有做这个，是因为 Thysrael 的决策失误，他把这两个模式弄混了，但是实际上即时渲染模式更加“优雅”。

光标

vditor 对于光标的支持并不好，导致很多时候光标的表现并不自然。

完美 tab 化

如果榕图是一个 tab，那么就可以通过“双击”之类的操作实现打开某个节点对应的文档了。

目前有两种方式，一种将一些页面设置成 tab（称之为“tab 化”），一种是将整个页面都显示某些信息（称之为“非 tab 化”）。

“非 tab 化”需要做到不显示 tab 栏，因为显然 tab 栏对于这种模式是一种交互上的干扰。

我支持对于榕林、榕树、偏好设置进行非 tab 化处理，对于使用手册进行 tab 化处理（这个东西说白了就是一个普通 md 文档），对于欢迎界面，这个东西应该属于 tab 的底版（见 vscode 的处理）。

之所以这样安排，是因为一个 tab 是和 sidebar 分离的，比如说一个文档，可以用大纲 sidebar，也可以用引用 sidebar。但是榕图是没有办法和榕图 sidebar 分离的，榕图不能搭配一个大纲 sidebar。所以 tab 化榕图，榕林，偏好设置（除非偏好设置是一个文件，而我们的编号设置是一个 GUI 界面）是不对的。

5.2 限制条件

安装路径

Windows安装路径在/User/[用户名]/AppData/Local/Programs/Ficus下，Mac安装在Application/ficus.app下，linux通过appimage安装。

缓存文件在语句 app.getPath('userData') 对应路径下，改路径因系统而异。

系统支持

目前软件可在Windows/MacOS/Linux上运行。

macOS启动时由于暂时没有申请证书，会弹出未知开发者警告。若信任本软件并正常启动，请在“设置-隐私与安全性”处选择“仍要打开”来运行软件。

应用运行

应用目前内置的资源管理器除文件夹外，只会显示Markdown类型文件（md|markdown），图像类型文件（jpg|png）。因为性能原因，仅可打开不超过100KB的Markdown类型文件。

如果对性能有一定要求，打开较多文件的文件夹的时，请尽量将不需要的文件配置ignored

---

六、发布方式和发布地址

软件可以在官网进行下载。

具体的发布方式后续会更新。