您使用了一款软件多年，很多操作界面已经习惯，软件推出了新版本但没有新功能，但把界面操作逻辑大幅度改动，需要重新花些时间去学习，您会觉得？
Anonymous Poll
26%
不能接受，怎么能随便大幅度改变用户操作界面和习惯呢，回退版本
74%
可以接受，喜欢接受新事物，即便开始很不习惯也会尝试花时间去学习
🎉45
还有个调研，您对自己 PC（Windows，若有） 电脑的桌面图标的情况选择
Anonymous Poll
30%
隐藏了桌面图标或者就留个回收站或者我的电脑，其他的出现了就不喜欢
38%
有几排常用软件的图标，以及一些但不多的文件摆在桌面上
22%
图标排列得非常整齐，或分区块整齐排列，甚至尝试给图标换上统一风格的新图标
10%
图标排列的很混乱，已经各种文件乱摆，几乎超过了半个屏幕，一般不会去管理它们
🎉45
Salt UI 发布 2.3.0-alpha02 版本
移除了对 compose-material 依赖，目前 Android 平台依旧依赖 material 和 material3，移植了 compose-material Icon
添加了对 System VersionCode 获取，Android 平台为 SDKINT，Windows 平台为内部版本号（提供了 Windows 10 1607 至 Windows 11 24H2 内部版本号），macOS/Linux/iOS 暂不支持
新增了 ItemSelect，预计后续取代 ItemPopup
新增 SaltPalette，包含一些默认配色
添加 Modifier.thenIf 拓展方法
SaltConfigs 现在需要显示指定 indication 参数，可以使用 Salt UI 包含的 AlphaIndication 或 material 的 ripple 或自实现
https://github.com/Moriafly/SaltUI/releases/tag/2.3.0-alpha02
移除了对 compose-material 依赖，目前 Android 平台依旧依赖 material 和 material3，移植了 compose-material Icon
添加了对 System VersionCode 获取，Android 平台为 SDKINT，Windows 平台为内部版本号（提供了 Windows 10 1607 至 Windows 11 24H2 内部版本号），macOS/Linux/iOS 暂不支持
新增了 ItemSelect，预计后续取代 ItemPopup
新增 SaltPalette，包含一些默认配色
添加 Modifier.thenIf 拓展方法
SaltConfigs 现在需要显示指定 indication 参数，可以使用 Salt UI 包含的 AlphaIndication 或 material 的 ripple 或自实现
https://github.com/Moriafly/SaltUI/releases/tag/2.3.0-alpha02
GitHub
Release 2.3.0-alpha02 · Moriafly/SaltUI
Full Changelog: 2.3.0-alpha01...2.3.0-alpha02
🎉47
吐槽下小米，可能每型号小米手机的 R 角都不一样，所以曲线也不一样，开发文档只能提供一个圆角值
但实际会发现小米多任务界面卡片圆角是比手机 R 角小好多的，比开发文档提供的获取到的圆角值也要小蛮多，甚至在小窗中这个值似乎更小（这地方居然好像和 R 角没什么关系）
我觉得这个地方要求小米致敬苹果，至少几年内都完成不了，甚至去适配以前那么多的机型更是天方夜谭。即便到时候视频，是否提供给第三方？第三方适配情况？都是问题
我觉得解决方法是在 Salt Player 中继续缩小圆角值，或者和播放界面再完全展开的时候去掉圆角
但实际会发现小米多任务界面卡片圆角是比手机 R 角小好多的，比开发文档提供的获取到的圆角值也要小蛮多，甚至在小窗中这个值似乎更小（这地方居然好像和 R 角没什么关系）
我觉得这个地方要求小米致敬苹果，至少几年内都完成不了，甚至去适配以前那么多的机型更是天方夜谭。即便到时候视频，是否提供给第三方？第三方适配情况？都是问题
我觉得解决方法是在 Salt Player 中继续缩小圆角值，或者和播放界面再完全展开的时候去掉圆角
🎉90
升级了开发软件，感觉笔记本 16 GB 内存比较吃力了，开两个项目后台挂点网页什么的已经有点卡_(:з」∠)_
SPW 现在随便跑下 400 MB，有点丢人啊（加油搞花里胡哨点，不然配不起这个内存占用 x），心里预期感觉 200 MB 还差不多 大家的电脑内存是？（16 GB + 的意思为大于等于 16 GB 小于下一个选项 32 GB）
SPW 现在随便跑下 400 MB，有点丢人啊（加油搞花里胡哨点，不然配不起这个内存占用 x），心里预期感觉 200 MB 还差不多 大家的电脑内存是？（16 GB + 的意思为大于等于 16 GB 小于下一个选项 32 GB）
Anonymous Poll
3%
< 4 GB
2%
4 GB +
11%
8 GB +
47%
16 GB +
26%
32 GB +
5%
64 GB +
5%
128 GB +
🎉63
近期开发计划
【Salt Player】今天会频道和 Github 发布 Salt Player 10.6 正式版，国内应用商店/Play 商店将在下周逐步推送，公众号文章这两天发布（可能延期）
【SPW】今天下午和朋友进行第二次开发测试
【Qinalt】在制作新的“歌词库”功能，工作量有点大预计下周（可能延期）
【Salt Player】今天会频道和 Github 发布 Salt Player 10.6 正式版，国内应用商店/Play 商店将在下周逐步推送，公众号文章这两天发布（可能延期）
【SPW】今天下午和朋友进行第二次开发测试
【Qinalt】在制作新的“歌词库”功能，工作量有点大预计下周（可能延期）
🎉41
10.6.0-2024111701-moriafly-arm64-v8a.apk
11.7 MB
10.6.0-release-2024111701
*对比 10.6.0-beta04 版本
优化自然排序
优化组件无障碍
*对比 10.6.0-beta04 版本
优化自然排序
优化组件无障碍
🎉46
https://github.com/Moriafly/SaltPlayerSource/releases/tag/10.6.0
已在 Github 发布最新版本，可查看完整更新日志以及下载 32 位版本
已在 Github 发布最新版本，可查看完整更新日志以及下载 32 位版本
GitHub
Release 10.6.0 Release · Moriafly/SaltPlayerSource
亮点
1. OPPO 流体云支持
自 11 月 11 日起逐步支持，感谢 OPPO 提供的帮助
2. 第三代歌词组件加强版
实验室，部分功能测试
全新开发的歌词组件，低功耗高准确度
兼容旧版本歌词组件模糊、3D、隐藏播放界面控制面板效果
优化兼容性卡拉 OK 歌词最后一行歌词动画
目前仅开放“兼容性卡拉 OK 歌词”动画效果
预计后期上线支持增强型 LRC 歌词
全新
使用开发工具包 ...
1. OPPO 流体云支持
自 11 月 11 日起逐步支持，感谢 OPPO 提供的帮助
2. 第三代歌词组件加强版
实验室，部分功能测试
全新开发的歌词组件，低功耗高准确度
兼容旧版本歌词组件模糊、3D、隐藏播放界面控制面板效果
优化兼容性卡拉 OK 歌词最后一行歌词动画
目前仅开放“兼容性卡拉 OK 歌词”动画效果
预计后期上线支持增强型 LRC 歌词
全新
使用开发工具包 ...
🎉39
Salt Player/SPW 后续更新策略，不进行第三方开源软件兼容合作或者第三方专用格式适配
如第三方歌词插件、Xposed 框架、第三方软件自己的标准歌词（如 TTML），都拒绝适配
如有必要，会推出自己的专用格式
如第三方歌词插件、Xposed 框架、第三方软件自己的标准歌词（如 TTML），都拒绝适配
如有必要，会推出自己的专用格式
🎉89
不要糖醋放椒盐
最近同步在开发自研的音频属性读取器，希望做的功能强大，但工程量巨大，预计这两个月做一个小安卓软件进行测试
其实还有点想法是想复活下 Hearusy Spectrum 和 Moriafly Audio Hub，合二为一
前者签名密码忘记了｡°(°¯᷄◠¯᷅°)°｡以前什么密码都不记的，现在都得拿小本本写下，可能是记忆力开始衰退了。。。
前者签名密码忘记了｡°(°¯᷄◠¯᷅°)°｡以前什么密码都不记的，现在都得拿小本本写下，可能是记忆力开始衰退了。。。
🎉101
不要糖醋放椒盐
遇到这个事情就提一下 其实我觉得大学可以注重此方面的教学，我上软件工程可对如开源协议、版权可能课本就一两页提一下，至于上课那几乎就不可能讲这些，像商标法这些就不会教 大家可能在 B 站看过一些被“商标刺客”一样的恶心公司专门来搞钱的，也可能热搜了解过“商标抢注”等等这样的，也有许多开发者因为商标的问题被发律师函的 我之前也不懂这些，看都不想看，但确实这个没法避免 建议相关开发爱好者、初从业人员注意这部分，也懂得保护自己
昨天晚上看到了”何同学使用 MIT 开源软件并删除原作者信息“，还是希望这个环境可以更好，及时改正错误
国内开源，做的体量大的开源可能是既没金钱，还被骂还被挂知乎上指指点点对吧，或者被抹去名字成为他人的代码而出现在各种计算机作业、毕设、淘宝等等地方，是否内心可以接受呢？
国内开源，做的体量大的开源可能是既没金钱，还被骂还被挂知乎上指指点点对吧，或者被抹去名字成为他人的代码而出现在各种计算机作业、毕设、淘宝等等地方，是否内心可以接受呢？
🎉93
我的话，内心还是有点不安，我虽然感觉自己不是很在意金钱但无法抛弃，我还幻想某天收购索尼呢。至于名声，我也在意。我想绝大多数人都在意这两点，多的不说了，下面两点：
1. 还是之前的承诺，哪天我收入到了网易云音乐研发的平均水平，我就把椒盐音乐 Salt Player GPL3 开源
2. 最近在想思考做一个自研音频编码识别、标签读取写入库，想着是闭源的，但今天决定开源的来写，开源协议用 LGPL 吧
1. 还是之前的承诺，哪天我收入到了网易云音乐研发的平均水平，我就把椒盐音乐 Salt Player GPL3 开源
2. 最近在想思考做一个自研音频编码识别、标签读取写入库，想着是闭源的，但今天决定开源的来写，开源协议用 LGPL 吧
🎉107
不要糖醋放椒盐
我的话，内心还是有点不安，我虽然感觉自己不是很在意金钱但无法抛弃，我还幻想某天收购索尼呢。至于名声，我也在意。我想绝大多数人都在意这两点，多的不说了，下面两点： 1. 还是之前的承诺，哪天我收入到了网易云音乐研发的平均水平，我就把椒盐音乐 Salt Player GPL3 开源 2. 最近在想思考做一个自研音频编码识别、标签读取写入库，想着是闭源的，但今天决定开源的来写，开源协议用 LGPL 吧
从头自研多媒体格式音频识别、标签读取写入库地址：https://github.com/xuncorp/openmrw
名字全称（Open Metadata Reader Writer）今天开始写吧，用 Kotlinx IO 写，适用于 Android/JVM
名字全称（Open Metadata Reader Writer）今天开始写吧，用 Kotlinx IO 写，适用于 Android/JVM
GitHub
GitHub - xuncorp/openmrw: Audio metadata reading and writing library for Android/JVM platforms.
Audio metadata reading and writing library for Android/JVM platforms. - xuncorp/openmrw
🎉76
不要糖醋放椒盐
从头自研多媒体格式音频识别、标签读取写入库地址：https://github.com/xuncorp/openmrw 名字全称（Open Metadata Reader Writer）今天开始写吧，用 Kotlinx IO 写，适用于 Android/JVM
今天完成了 FLAC 音频识别、流信息读取、标签读取
慢慢做，做的差不多就进行在 Salt Player/Qinalt 中接入测试，目前 Salt Player 标签读取是个混合解析的，MAH 是直接套 FFmpeg 封装加了点辅助处理
慢慢做，做的差不多就进行在 Salt Player/Qinalt 中接入测试，目前 Salt Player 标签读取是个混合解析的，MAH 是直接套 FFmpeg 封装加了点辅助处理
🎉101
不要糖醋放椒盐
从头自研多媒体格式音频识别、标签读取写入库地址：https://github.com/xuncorp/openmrw 名字全称（Open Metadata Reader Writer）今天开始写吧，用 Kotlinx IO 写，适用于 Android/JVM
今天完成了 APE V1/V2 头解析和 MP3 ID3v2 头解析
🎉66
Salt Player 对 DSD 的废弃标识将延期，SPW 将完全屏蔽 DSD 格式不提供支持，建议切换到其他主流格式
DSD 数字格式（.dsf/.dff）应该被丢进历史垃圾堆
推荐格式：
FLAC/APE
MP3/AAC
DSD 数字格式（.dsf/.dff）应该被丢进历史垃圾堆
推荐格式：
FLAC/APE
MP3/AAC
🎉109
不要糖醋放椒盐
从头自研多媒体格式音频识别、标签读取写入库地址：https://github.com/xuncorp/openmrw 名字全称（Open Metadata Reader Writer）今天开始写吧，用 Kotlinx IO 写，适用于 Android/JVM
今天完成了 ID3v2.3 标签文本帧的解析，以及晚上尝试添加对 ID3v2.4 的适配
但其实 ID3 标签做为 2000 年左右的标准（草案，非完全标准化），目前使用 ID3v2.3 的比较多（吐槽下草案写的有些地方有点模糊）
ID3v2.4 现存的许多音频格式还存在和文档不一致，我想在后续要进行更多的测试，疑似可能是用户使用的某些编辑器的问题
希望在今年能初步完成 FLAC、APE、MP3 等基本格式的流/标签读取，希望尽快投入生产环境提升软件品质
但其实 ID3 标签做为 2000 年左右的标准（草案，非完全标准化），目前使用 ID3v2.3 的比较多（吐槽下草案写的有些地方有点模糊）
ID3v2.4 现存的许多音频格式还存在和文档不一致，我想在后续要进行更多的测试，疑似可能是用户使用的某些编辑器的问题
希望在今年能初步完成 FLAC、APE、MP3 等基本格式的流/标签读取，希望尽快投入生产环境提升软件品质
🎉75