Updates zheng-wen-zhi-hou.md

Auto commit by GitBook Editor

zheng-wen-zhi-hou.md

@@ -6,7 +6,7 @@
 
 文件管理器有很多，远不止peony一个，也不是所有文件管理器都和peony承担的工作一样的，比如nautilus，它就不需要承担拉起桌面的工作。文件管理器的本职工作就是提供一个与文件的ui交互界面而已，我认为只要做好这一点，就是一个好项目了，其它的只是可选项，对于可选项，我们可以分解成独立的问题再考虑。
 
-之前向nautilus提交issue的时候，我了解到了他们的设计理念，文件管理器永远不会处理gvfs/gio做不到的事情。如果抛开后台服务，还有session等等，它本身就只是一个图形代理而已，所有对文件的操作还是回到了gio上。我们不应该在文件管理器中去做文件系统架构层面的工作，所以我们首要考虑的问题就能够简化成怎么提供一个稳定可靠的gio图形操作端。哪怕我们抛弃了gio，选择了kio或者自己研发一个vfs系统，我们也应该遵循这个理念。
+之前向nautilus提交issue的时候，我了解到了他们的设计理念，文件管理器永远不会处理gvfs/gio做不到的事情。如果抛开后台服务，还有session等等，它本身就只是一个图形代理而已，所有对文件的操作还是回到了gio上。我们不应该在文件管理器中去做文件系统架构层面的工作，所以我们首要考虑的问题就能够简化成怎么提供一个稳定可靠的gio图形操作端。哪怕我们抛弃了gio，选择了kio或者自己研发一个vfs和io库，我们也应该遵循这个理念。
 
 ### 拒绝自己从头画控件
 
@@ -16,17 +16,17 @@
 
 这种设计模式相信大家都有所了解了，我在之前基于qt编写桌面分类应用
 
-* https://github.com/Yue-Lan/desktop-file-memos
+* [https://github.com/Yue-Lan/desktop-file-memos](https://github.com/Yue-Lan/desktop-file-memos)
 
 的时候，对这种模式有了一个比较深刻的认知，它主要的理念可以概括为：
 
-*  使用model控制要显示的数据
+* 使用model控制要显示的数据
 * 使用view控制显示数据的方式并且提供UI交互的接口
-*  使用controller/delegate对某一数据进行修改
+* 使用controller/delegate对某一数据进行修改
 
 我们不想仅仅因为视图的转变而对数据或数据的载体进行修改，这样代价太大了，像nautilus的iconview和listview，虽然数据相同，但是不是以model/view的形式进行的开发，所以对每一个view都要做不同的处理，而将数据封装在model内部，就不会有这个麻烦。
 
- 在model的基础上，view能够给我们提供不同的显示模式，多样的selection机制，自定义的右键菜单，我们想要的一切ui交互都不必直接与数据打交道了。如果要对数据进行修改，让controller或者delegate先将修改缓存，然后以代理者的形式进行修改，可以增强稳定性和代码可读性。通常我们的代理框架都会提供一个友好的编辑框让我们修改起来更加的方便。当然delegate的作用也并不仅仅局限于此。
+在model的基础上，view能够给我们提供不同的显示模式，多样的selection机制，自定义的右键菜单，我们想要的一切ui交互都不必直接与数据打交道了。如果要对数据进行修改，让controller或者delegate先将修改缓存，然后以代理者的形式进行修改，可以增强稳定性和代码可读性。通常我们的代理框架都会提供一个友好的编辑框让我们修改起来更加的方便。当然delegate的作用也并不仅仅局限于此。
 
 ### 如果基于qt重写，一些值得关注的点
 
@@ -60,5 +60,7 @@ qt对dnd的支持还是不错的，如果使用qt提供的view，我们可以覆
 
 我对这一块的东西并不熟悉，代码中接触的机会也不多，但是这确实需要注意，可能下一步需要研究一下这个东西。
 
+* 关于桌面和文件管理器
 
+我更倾向于将桌面和文件管理器分离开来，这样能够使得代码的逻辑更加清晰，理论上桌面拉起的速度会更快，减少了黑屏的时间。