给「图阅」简单做个logo
目录
1这图片阅读器长啥样？
2为啥要整这活？
3怎么开发的？
4rust用起来感觉怎样啊？
5软件在哪里下载？(showmethecode)
//它长这样
兴趣使然，做了一个电脑上用的图片阅读器，它长这样：
图库列表
看看漫画
看看照片
//缘由
其实去年差不多时候也做过一个类似的东西，那时候起名为ComicLibrary，私心里想要一个用户友好的漫画阅读器。
漫画有各种排版方式：单页、从左到右、从右到左、长条滚动。
在线阅读要等待加载、本地阅读则windows自带的图片浏览器使用上不太方便。
那便自己做一个。
去年的那个软件是用electron做的。electron内置了chromium内核，对于小型软件来说未免过于庞大，颇有杀鸡用牛刀的意味。
恰巧最近对rust语言颇感兴趣，早就听闻了这门编程语言以其极其陡峭的学习曲线而著名，并且据说学了之后思维都会有所改变。
于是一拍即合：用tauri来写一个图片浏览器吧。
//开发
#框架
tauri也是一个帮助开发者开发跨（桌面）平台软件的工具包，跟electron一样。前端也是web，而它的后端是rust。
#UI
不擅长美术的我要写有界面的软件，是离不开前端UI库的。这次用的库是NaiveUI，当初一看到名字就觉得，嗯很对我口味。
#前端
使用Vue3，颇为亲切。
#后端
rust是从头学起的。
先是阅读rust文档（的一部分），领会它的精神；
接着上leetcode用rust刷了十几道题，熟悉基本语法；
好嘞，开始写吧。
//rust体验后感，与对其精神的领会
以目前接触到的rust的内容，个人理解其精髓在于变量“所有权”这一理念：每一块内存都只能有一位（变量）拥有它的所有权，掌握所有权的那位需要对这块内存负责到底，变量在内存在。
又，所有权是可以转让的。
这特性便造就了move（移动）代替copy（拷贝）成为默认操作——在其他很多语言里，拷贝才是默认的行为，可以理解为“A将一份信息给到B，B拥有了这份信息的复制，但A也仍然持有这份信息”。这很符合直觉。
但人们终究要为这种“符合直觉”的行为付出代价，即当信息的复制代价太高（信息量太大，复制很耗时间和内存）的时候，人们创造了浅复制——信息仍然只有一份，让它静静呆在那里，咱们俩都拿着它的地址就好，这样咱们俩都能去查阅它更改它。
但人们终究又要为这节省代价的“浅复制”付出另外的代价，即竞争。A和B都想去篡改同一份信息的时候，咋整？更甚，其中一人想要删除这份信息，但另一个人不知道这份信息已经被删，这时仍去查阅……铺天盖地的bug就来了。
rust做了一个改变。在最初最初的地方做了一个简单的改变。
rust说，不妨把信息看成是像实物一样的东西，A要把这东西给到B，那A手头就没有这个东西了。
只要将信息看作实物，上述的问题就都不存在了。
永远只有一个人能拥有一份信息的所有权，竞争消失了；
所有权只能转让，拷贝消失了（当然，如果必要，可以显示定义拷贝行为，将一个信息多复制出一份来）；
当然，所有权除了转让之外，还可以借用。
rust定义了“可变”和“不可变”，也就是更改一份信息的权限。它还保证了在所有借用了同一份信息的人之中，同时最多只能有一位具备更改权限。（只读和可写借用之间也有约束，甚至保障到了只读那位的安全性。宛如读写锁。）
如此设计，让rust安全得一逼。绝大多数安全隐患在编译阶段就能被揪出来（当然这也导致了它的编译器非常严格，但严格归严格，提示却很友好）。
而这一切，都源于在最初做的一个理念的转变。
美妙。
初时写起来确实颇为卡顿，脑里需要时时记得这份信息是所有权在谁那里，要记得这份信息的类型（不像c/c++那样允许隐式类型转换）。
不记得也行，编译器会友善地告诉你你在哪里sb了，甚至会教你怎么改才对。
写多了之后便也写得流畅了（也不是很多）。编程终究是个练习的过程。
//货在哪
源码和windows可执行文件放在github：