图像快速预览功能的实现，以及一些想法。

当时在完成自定义文件之后，给后缀添加了统一的图标，之后我是计划实现图片和视频的预览 缩略图的效果。

为此当时还研究了com接口和shell的uuid是如何关联在一起的，不过因为这块非常复杂，还需要继承com的接口实现，再加上后续的一些不可抗力的因素就搁置了。

最近跳过了这个部分，实现了自定义文件的预览，本质上很简单，就是在main 函数中直接处理图像到图像的显示窗口中，因为不需要在加载一些配置以及乱七八糟的初始化操作，这个过程就变得非常丝滑。

一个看图的模块，只需要能够提供缩放和位移，标注，导出，后处理，截图，打印，这些基本的逻辑就足够了。

虽然所有的逻辑都可以预处理，但是预处理的代价是很难权衡的，也是一般人注意不到的。这就涉及到功能的使用次数，如果不常用，那么即使等待10s 也不是什么难以忍受的事情。如果是必须看到的，那么就需要在完成基本功能之后，在后台预先处理后面的逻辑。



很久之前的浏览图片，我通常都是安装ACDsee,而且必定是破解的，不过便随着更新，ACDsee，预览图片越来越卡了，我也不知道他都执行了什么乱七八糟的东西，所以后面我放弃了这个软件改用了honeyview。功能比ACDsee简单的多，也不调色，不过对于我来说足够了，毕竟我也不想要去看什么直方图，我只是想要简简单单的看个图片。

现在软件都越来越大了。有些东西越来越大我感觉还蛮好的，像是Matlab，具有不可取代性，越大代表功能越多，虽然我不用，但我开心。

但是像是QQ，微信这些东西越来越臃肿，什么都在里面，我就用的不是很开心。











集合式软件的发展真的有前景吗？

如果非他不可，那就有必要，但如果存在同位替换，我一定会选择路径最短的那个。

就像是我打开抖音，希望第一时间看到视频，所以视频放在首页，如果更改，我就不喜欢用。

就像是我打开微信，第一时间一定是看到的消息，看看有没有未读消息，如果要是朋友圈乱七八糟的我就不喜欢用。

就像是我为什么淘汰了迅雷，而选择了115，虽然他们都是 基于 Chromium开发的，但是 115具有不可替代性，我可以忍。迅雷我忍不了，选择了更简单了 bitcomet。为什么没有选择同位替换的其他下载器是因为，浏览器自带的下载已经可以处理大部分的需求，剩下的特定就是种子。



设计的理念从来不是花里胡哨，而是尽可能降低用户的心智负担，方便用户操作和使用。

我很久不曾打开过支付宝了，我感觉就像是里面百科全书，什么都有，我不喜欢用。那些视频功能也很冤枉，没有支付宝引流，这些就真的成了垃圾。但他就是垃圾，这些垃圾让支付宝也成为了残次品。

就像是我能看出来，抖音很想要做商品，但他要是敢把我的界面首页改成商城，那我也没什么办法，也就是就是找找破解，安装一个无广告的版本。

知乎想要推视频，结果视频这块死的不能再死了。知乎也想要做AI，这块处理的就挺好，默不作声的放进去，眼不见心为静。



就像是如果我需要序列化一段json，最短的途径是什么，在浏览器的输入窗口输入 js 按照自动联想历史记录到json.cn  然后回车，然后ctrl + V ，问题就解决了。

中间的途径已经缩短到不可能更简单了，浏览器工作的时候是要一直开着的，不可能关闭，如果还要用快捷键打开一个聚合引擎，我就感觉有些繁琐了。

同理，所有可以在线实现的转换功能都是，比如 什么 jpg 转 ico 等等逻辑。

除了ping 之类的，可以纯命令行的 .因为ping 的逻辑更简单， win +R 输入 cmd 然后回车 然后输入ping XXX 无需鼠标操作，看完直接alt +F4关闭即可。

像是git 的操作，在github 看到想要下载的，只需要 选择地址栏，然后ctrl+ c 然后  命令行打开 cmd 然后 cd des 然后tab 补全到 桌面，然后输入 proxy  设置命令行代理,  git clone  Ctrl+v   就瞎子啊好了。



但是像是ffmpeg 相关的操作，我就很难用命令行打出来，因为文件地址不好输入，还有那些乱七八糟的命令不好记，我就更喜欢使用自己写的一个 gui , 生成命令，然后自动打开命令行执行。



当功能复杂到一定程序，命令行界面就显得复杂，而GUI就显得简单。 用户可以允许等待，因为移动鼠标也需要时间。



这个其实又能牵扯到 思维途径和使用的代价