将 Scapple 嵌入 Scrivener

这个想法乍听起来非常诱人，但其背后存在两个根本性的难题：

1. 将一个程序嵌入另一个程序会极大增加复杂性。更不用说 Scrivener 本身已经是一个功能非常丰富的程序。想想 Scapple 中所有的菜单命令和键盘快捷键——它们在 Scrivener 的用户界面中该放在哪里？要么会大大膨胀菜单项的数量，要么 Scapple 组件本身必须被精简到几乎去掉所有高级功能，那它就会失去几乎所有使其独特的特质，变成某种类似于 Scrivener 中已有功能的东西——即自由形式的索引卡模式。
2. 更重要的是，这两个程序使用的信息模型存在根本性的差异。Scrivener 基于严格的大纲模型，活页夹中的每个项目都必须有且仅有一个父级项目，并且这些项目按线性顺序排列。而 Scapple 则完全没有线性顺序或嵌套层级的概念。将一个笔记向左上方拖动，在 Scrivener 的大纲中应该对应到什么位置？这正是 Scapple 与更常见的"思维导图"软件的区别所在——思维导图确实使用了可以表达为大纲的层级结构，而 Scapple 不要求笔记之间必须有连接关系，还允许创建不产生逻辑序列的连接，比如一圈首尾相连的笔记，偶尔还有从环外切入的链接。这种结构在 Scapple 中创建轻而易举，但对于基于大纲的程序来说，它是一种完全无法理解的"形状"。

简而言之，将 Scapple 嵌入 Scrivener 要么需要一方或双方程序在其设计目标上做出妥协，要么只能提供一种非常松散的"集成"诠释，以至于它们不如继续保持独立——这样每个程序都能拥有完整的菜单和快捷键服务。因此，这个请求几乎可以确定不会实现。