以下的内容仅代表个人的观点，大家可以略过。
文件管理器有很多，远不止peony一个，也不是所有文件管理器都和peony承担的工作一样的，比如nautilus，它就不需要承担拉起桌面的工作。文件管理器的本职工作就是提供一个与文件的ui交互界面而已，我认为只要做好这一点，就是一个好项目了，其它的只是可选项，对于可选项，我们可以分解成独立的问题再考虑。
之前向nautilus提交issue的时候，我了解到了他们的设计理念，文件管理器永远不会处理gvfs/gio做不到的事情。如果抛开后台服务，还有session等等，它本身就只是一个图形代理而已，所有对文件的操作还是回到了gio上。我们不应该在文件管理器中去做文件系统架构层面的工作，所以我们首要考虑的问题就能够简化成怎么提供一个稳定可靠的gio图形操作端。哪怕我们抛弃了gio，选择了kio或者自己研发一个vfs和io库，我们也应该遵循这个理念。
只要研究过文件管理器代码就可以发现，nautilus的图标视图完完全全是自己从头绘制的，因为gtk的控件大部分都只能算半成品，不能满足实际使用；然而这种自己实现的view和和控制机制是要花很长的时间才能稳定下来。我认为没有必要深入研究本该属于图形库的工作，事实上现在gtk的icon view也能够与文件目录相结合，只不过效果没有nautilus的好罢了，如果要我在nautilus自己实现的icon view和qt 提供的icon view里选择，我会毫不犹豫的选择后者。
这种设计模式相信大家都有所了解了，我在之前基于qt编写桌面分类应用
的时候，对这种模式有了一个比较深刻的认知，它主要的理念可以概括为：
- 使用model控制要显示的数据
- 使用view控制显示数据的方式并且提供UI交互的接口
- 使用controller/delegate对某一数据进行修改
虽然gtk3也开始支持mvc的设计模式了，但是我们没有办法大刀阔斧的对现有框架进行改造，nautilus一样不会这么做，而如果是重写，当然也不会优先考虑gtk。
我们不想仅仅因为视图的转变而对数据或数据的载体进行修改，这样代价太大了，像nautilus的iconview和listview，虽然数据相同，但是不是以model/view的形式进行的开发，所以对每一个view都要做不同的处理，而将数据封装在model内部，就不会有这个麻烦。
在model的基础上，view能够给我们提供不同的显示模式，多样的selection机制，自定义的右键菜单，我们想要的一切ui交互都不必直接与数据打交道了。如果要对数据进行修改，让controller或者delegate先将修改缓存，然后以代理者的形式进行修改，可以增强稳定性和代码可读性。通常我们的代理框架都会提供一个友好的编辑框让我们修改起来更加的方便。当然delegate的作用也并不仅仅局限于此。
- 模块化与前后端分离
如果我们的文件管理器能够做到前后端分离，维护和开发难度就降低很多了。在MVC设计模式的支持上，我可以断言qt比gtk要好的多，qt4开始就已经推广了model/view的理念了，qt基于mvc设计模式的框架就比较完备，事实上qfilesystemmodel就是一个非常强悍的官方model，和qlistview或者qtreeview结合使用能够解决绝大部分文件管理器的要求了，gtk虽然也开始向mvc设计模式转变，正如上文所说，目前阶段来看，想要投入开发还不太乐观。
然而目前qfilesystemmodel的作用域只限于本地文件，我们如果对这个model进行定制，使其能够支持gvfs，在文件视图的绘制和同步这一块基本上就能够拿下了。目前我还没有研究过model的定制方法，我认为这一块的工作是比较麻烦的。
当然qt也是支持非model/view的设计方法的，对特殊路径采用非model/view的形式来实现也是一种选择，不过这样对整个架构来说并不友好。
- 文件操作
由于考虑到要支持回收站以及samba、sftp等远程目录的操作，qt提供的io库可能不适用了，我们需要把文件操作相关的代码迁移过来。
这一块的代码量也不小，不过主要可以分为直接操作和操作栈管理两块。有目标的迁移从时间上也是可以控制的。
- dnd
qt对dnd的支持还是不错的，如果使用qt提供的view，我们可以覆写一部分原有的方法来达到理想的效果。
- 关于session和dbus服务
可以参考dde和lxqt是如何做的，而且因为qdbus已经在4.9之后获得支持，实现起来应该不会太难。（其实我有点好奇nautilus不常驻后台的话dbus服务是在哪里提供的，难道是等调用才拉起吗？）
- tool bar和side pane
这一块基本上和文件视图一样需要回炉重造，不过就目前UKUI3.0的设计来说，可能使用qt进行二次开发会比基于原来架构修改的难度要小。
- 关于polkit
我对这一块的东西并不熟悉，代码中接触的机会也不多，但是这确实需要注意，可能下一步需要研究一下这个东西。
- 关于桌面和文件管理器
我更倾向于将桌面和文件管理器分离开来，这样能够使得代码的逻辑更加清晰，理论上桌面拉起的速度会更快，减少了黑屏的时间。