Open MewX opened 2 years ago
@MewX 支持,而且next分支正在往这个方向走。虽然我个人考虑更多的是站点关闭的情况。
另外:
看中分发的话,主要看压缩后大小;感觉现在已经很少有人在乎解压后的大小了吧,硬盘有点便宜了。压缩前差不多1.5M,其实不大。
至於统一宽高,可以有多个角度思考。
总体来说,感觉统一宽高不是很有必要,但是可能最开始的话有必要统一转码,去掉metadata(不确定,但是以防万一?)。
icon都有identity我个人觉得不太可能。next分支中,我对downloader的icon是统一到128x128的,这个数量不多也相对容易。
另外还有一个问题,就是在目前版本中,我们支持自定义站点(虽然这个口子(包括其他一些涉及自定义脚本的口子)我准备在next中封上)。那么对于这类用户自定义站点,icon势必不可能进pack中,这块后续怎么做合适些?
@Rhilip base64写到配置里?用户可以自己改
@Rhilip base64写到配置里?用户可以自己改
(不会有人这么做吧,一定过不了 Code Review 的)
icon都有identity我个人觉得不太可能。
确实,我也觉得不太可能,不过考虑到cabal能在邀请码交易网站蹲点,可能什么都是有可能的吧 LOL
next分支中,我对downloader的icon是统一到128x128的,这个数量不多也相对容易。
听起来不错,但是有个问题就是图片按照什么算法来扩大。参考
个人比较倾向于用 convert --filter point
。但是确实需要一个统一的规范。
在目前版本中,我们支持自定义站点(虽然这个口子(包括其他一些涉及自定义脚本的口子)我准备在next中封上)。那么对于这类用户自定义站点,icon势必不可能进pack中,这块后续怎么做合适些?
确实是个好问题,也就是说还要对自定义的设定做兼容,但是最终还是需要最终汇总到repo里面,这样才能添加icon。
@Rhilip 没看懂,我指的用户可以自己填base64,然后保存到个人配置中,类似passkey那样,原有的自定义界面咋样我不记得了,太久没用了
width
和height
来调整。
目前使用的大小为 我的数据列表 18, 时间轴 38, 站点新增 40👍 看起来还不错,另外3可能不需要局限于png文件,ico文件也可以接受应该,也是无损的。
@Rhilip 没看懂,我指的用户可以自己填base64,然后保存到个人配置中,类似passkey那样,原有的自定义界面咋样我不记得了,太久没用了
直接以base64的形式填入会扩大配置文件的体积。我个人是倾向能内置icon直接内置,不能内置的还是和原来一样。我们来请求文件。
我觉得独立文件更好,这样code review更方便,可以直接预览,而不用手动复制base64然后找个网站解析一下再看。
如果一个图标有30K,相当于有一个超长行在文件里,编辑文件比较痛苦。
@Rhilip 我指的自定义站点。因为之前看到有提到自定义站点
@ted423 自定义站点走老路子,直接写icon url在配置中。
👍 看起来还不错,另外3可能不需要局限于png文件,ico文件也可以接受应该,也是无损的。
从自动加载的角度来说,我个人觉得应该对其进行限制,要么 ico 要么 png。 除非我们每个都将icon写入配置文件,并约定如下:
{
icon: './site.ico'; // ./ 开头 从 `icons` 目录下加载,由webpack进行管理
// 如果是 png 必须声明,如果标准的 `./{site}.ico` 则不需要
// 这样也能实现icon的复用,例如某些nphp站点使用默认图标,直接 `./nexusphp.ico` 就行
}
{
icon: 'https://example.com/favicon.ico'; // http开头,远程加载并缓存base64
}
{
// no icon,如果有 `./{site}.ico` 文件,则使用,没有则走页面解析道路
}
另外,我简单测试了下:
public/assert
目录下,则 vue-cli(webpack) 不对其进行管理,那么我们怎么判定icon存在需要考虑,在之前next的写法中,我是用 brower.runtime.getUrl + axois
的方式。import.meta.webpackContext
的话,vue-cli 默认不对ico文件进行加载,需要进行 chainWebpack
改写。虽然可以前置判断,但是输出的文件都堆在了 dist/img
下,会不会过于杂乱(虽然也没人看)?
如果统一的话确实png更好些,空间也不会膨胀多少因为和ico都是无损的。
判断icon存在直接就用指明目录的方式呗?我觉得放在 PT-Plugin-Plus/resource/sites/*
文件夹里已经比较直观了,我个人倾向于
{
icon: './site.ico'; // ./ 开头 从 `icons` 目录下加载,由webpack进行管理
// 如果是 png 必须声明,如果标准的 `./{site}.ico` 则不需要
// 这样也能实现icon的复用,例如某些nphp站点使用默认图标,直接 `./nexusphp.ico` 就行
}
这样贡献者想添加站点的话不至于到处找目录,本来pt圈的程序员就不多,贡献开源的难度降低一些也好。
如果统一的话确实png更好些,空间也不会膨胀多少因为和ico都是无损的。
统一png的话,意味着多数站点的favicon不能直接使用,这些favicon的大小也多是32的。
而且从目前 config.json
的统计来说,ico更多。
其实转成png也就是一行指令的事 convert a.ico a.png
,但是好处是空间大概率减小 + 可以只保留最高分辨率的icon。
P.S. ico文件很多是内置多个分辨率的图片的,比如一个ico文件里面可能包含了:16x16, 32x32 ... 256x256的多个图片。看如下就是转码成了多个图片。
$ ls -alh
total 615K
-rwxrwxrwx 1 mewx mewx 1.5K Apr 3 11:09 1ptba.com.png
-rwxrwxrwx 1 mewx mewx 1.3K Apr 3 11:09 aidoru-online.me.png
-rwxrwxrwx 1 mewx mewx 884 Apr 3 11:09 alpharatio.cc.png
-rwxrwxrwx 1 mewx mewx 550 Apr 3 11:09 animebytes.tv-0.png
-rwxrwxrwx 1 mewx mewx 775 Apr 3 11:09 animebytes.tv-1.png (低分辨率可以删除)
-rwxrwxrwx 1 mewx mewx 960 Apr 3 11:09 animebytes.tv-2.png (低分辨率可以删除)
-rwxrwxrwx 1 mewx mewx 1.2K Apr 3 11:09 animebytes.tv-3.png
...
$ ls -lah
total 1.4M
-rwxrwxrwx 1 mewx mewx 4.2K May 24 2018 1ptba.com.ico
-rwxrwxrwx 1 mewx mewx 894 Jun 15 2016 aidoru-online.me.ico
-rwxrwxrwx 1 mewx mewx 1.2K Nov 8 2020 alpharatio.cc.ico
-rwxrwxrwx 1 mewx mewx 32K May 15 2021 animebytes.tv.ico
-rwxrwxrwx 1 mewx mewx 5.4K Apr 25 2017 animetorrents.me.ico
...
@MewX convert操作对非专业来说是不是过于困难,要么两个在未声明的情况下同时查找 .png 和 .ico,优先使用ico?
@MewX convert操作对非专业来说是不是过于困难,要么两个在未声明的情况下同时查找 .png 和 .ico,优先使用ico? 都查到了png为啥还要使用ico😂😂😂
前面不是说要统一嘛,所以我就觉得统一支持png比较好;如果支持两个格式的话就没问题了呀,先查询是否有png(因为各方面而言png都是比较高效的),再查询是否有ico如何?
另外我有点晕,这个icon文件目录不是指定在设置里面了嘛,不需要查询吧😅
(import.meta.webpackContext()).keys()
会生成一个 Array<./${string}.${"png" | "ico"}
> 对应 icon目录下的文件,是在这个array中查找
const packedIconContext = import.meta.webpackContext("../icons/", {
regExp: /\.(ico|png)$/,
mode: "eager"
});
const packedIconList: Array<`./${string}.${"png" | "ico"}`> = packedIconContext.keys();
oh,原来要用 import.meta.webpackContext。 输出的文件都堆在了 dist/img 下确实有点不简洁,更新版本的时候就会添加新的文件了。那感觉 public/asset 还是好些,因为可以自己管理。
那要不直接去掉icon这个field,然后标注一下图标请复制到 public/asset目录? 🤣 迷茫了,要不依然在site目录加icon,然后编译脚本自动把它们复制到 asset目录,自动改名,这样对贡献者友好些。
您的功能请求是否与问题有关? 请描述一下。
目前图标经常因为未知原因无法加载,刷新逻辑也是全部图标重新刷新,然后个别站点抽风导致刷新失败。
好处的话主要是用户体验,可以避免看不到图标(导致的原因可以是网络/网站/ptpp)。
描述你想要的解决方案
直接把ico打包进repo。
描述您考虑过的替代方案
release的时候包含图标。
其他附加信息
我做了些实验,目前已有的站点差不多所有图标加起来是350KB (zip默认参数),我测试了111个站的图标:
顺便也测试了一下imagemagick 默认参数转成png(无损),jpeg(有损)的结果。
差别不大其实,所以直接保持原有的ico应该是最优方案。