將 Scapple 嵌入 Scrivener

這個想法乍聽起來非常誘人，但其背後存在兩個根本性的難題：

1. 將一個程序嵌入另一個程序會極大增加複雜性。更不用說 Scrivener 本身已經是一個功能非常豐富的程序。想想 Scapple 中所有的菜單命令和鍵盤快捷鍵——它們在 Scrivener 的用戶界面中該放在哪裏？要麼會大大膨脹菜單項的數量，要麼 Scapple 組件本身必須被精簡到幾乎去掉所有高級功能，那它就會失去幾乎所有使其獨特的特質，變成某種類似於 Scrivener 中已有功能的東西——即自由形式的索引卡模式。
2. 更重要的是，這兩個程序使用嘅資訊模型存在根本性的差異。Scrivener 基於嚴格的大綱模型，活頁夾中的每個項目都必須有且僅有一個父級項目，並且這些項目按線性順序排列。而 Scapple 則完全沒有線性順序或嵌套層級的概念。將一個筆記向左上方拖動，在 Scrivener 的大綱中應該對應到什麼位置？這正是 Scapple 與更常見的"思維導圖"軟件嘅區別所在——思維導圖確實使用了可以表達為大綱的層級結構，而 Scapple 不要求筆記之間必須有連接關係，還允許創建不產生邏輯序列的連接，比如一圈首尾相連的筆記，偶爾還有從環外切入的鏈接。這種結構在 Scapple 中創建輕而易舉，但對於基於大綱的程序來說，它是一種完全無法理解的"形狀"。

簡而言之，將 Scapple 嵌入 Scrivener 要麼需要一方或雙方程序在其設計目標上做出妥協，要麼只能提供一種非常鬆散的"集成"詮釋，以至於它們不如繼續保持獨立——這樣每個程序都能擁有完整的菜單和快捷鍵服務。因此，這個請求幾乎可以確定不會實現。