peony的扩展实际上是满足peony扩展接口的插件，它以so库的形式在peony执行过程中加载进peony。peony的扩展只关心peony提供的接口，并不关心peony的内部是怎么样的。
与peony扩展不同，peony的扩展框架不在意每个扩展具体干了什么。peony的扩展框架需要考虑与peony的协同——怎么定义一组接口？在什么时候加载扩展？什么时候显示扩展？什么时候触发扩展？也许在使用时没有一个扩展，但是框架依然存在，一些步骤依然会被执行，只是我们看不到而已。
一个人的力量是有限的，一个项目也不可能包揽所有的工作，把所有的功能整合进同一个项目并且管理起来是一个十分复杂的工作，而且从程序设计的角度来看是十分不合理的。
peony（caja、nautilus）也考虑到了这一点，它们把一些复杂且不太属于文件管理器本职的工作使用扩展的形式来实现，在peony中，我沿用了这样的设计思路。
我之前也撰写过一篇文章简单的分析了旧版peony的扩展机制，本质上是对glib接口/插件机制的一层封装；旧版peony的扩展机制当然不适用于新版peony-，我们需要使用qt的插件机制对其进行重构，并且最终整合到我们的ui中去。
如果你对qt的插件机制比较了解，相信你应该能够很容易了解新版peony的扩展框架，在这里简单介绍一下新版peony扩展框架的实现思路：新版peony的扩展一般被设计成一个工厂，在程序初始化时就被加载并且持续到程序结束，通过统一的接口进行扩展管理，在程序运行时，通过特定的ui交互进行触发。
一个扩展的复杂度不是由扩展框架决定的，实现一个扩展可能会比实现一个项目本身还要难，这也是我之前说整合项目不合理的一个重要因素。
在新版peony的设计里，右键菜单、工具栏、导航栏、属性窗口甚至文件视图都是可扩展的，为了达到这样的设计，可能会增加编写代码和阅读代码的难度，但是考虑到今后长远的发展，这些工作都是值得去做的。
一个好的插件能够使新版peony添彩很多，正如我所说，我一个人很难在维护新版peony的同时去编写各种复杂的插件，那么我希望这些工作最好能由贡献者来完成。目前，我希望有人为新版peony编写压缩、共享、预览等实用的插件。