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

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

为此当时还研究了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就显得简单。 用户可以允许等待,因为移动鼠标也需要时间。

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