trime
trime copied to clipboard
osfans
同步时自动备份及还原软件选项xml配置文件
Pull request
Issue tracker
Fixes will automatically close the related issue
Fixes #
Feature
- 同步时自动备份及还原软件选项xml配置文件
a. 备份 /data/data/APPLICATION_ID/shared_prefs/APPLICATION_ID_preferences.xml 到同步目录
b. 从同步目录恢复 revocer.xml 到data目录，并且重命名recover.xml为recovered.xml
- 目前没有自动刷新同文的设置，需要手动结束进程才能生效
- 修复了部分App横竖屏切换时键盘宽度错误（termux 、debian）
Code of conduct
- [x] CONTRIBUTING
Gradle task
Tasks passed on every commit
- [x]
./gradlew spotlessCheck - [x]
./gradlew assembleDebug
Manual test
- [x] Done
Code Review
- No wildcards import
- Manual build and test pass
- GitHub action ci pass
- At least one contributor reviews and votes
- Can be merged clean without conflicts
- PR will be merged by rebase upstream base
Daily build
Login to fetch artifact
https://github.com/osfans/trime/actions
Additional Info
这部分的配置应该存到 trime.yaml 里
我觉得给 trime 增加特性应该先经过讨论设计, 不然会给以后增加兼容性成本
比如我正准备给 trime 写有一个图形化编辑器来编辑 yaml, 现在这个问题也就一并解决了
这部分的配置应该存到 trime.yaml 里
trime.yaml目前是在存储皮肤参数，并且trime.yaml需要进过build过程，用户修改的过程也是单向的：修改trime.yaml -> build -> rime从build目录读取参数。 如果用户在图形界面修改参数，再把值反馈回到yaml文件，似乎...有点怪，需要仔细捋一捋。 可能需要写在另外一个yaml文件中，修改配置后保存的过程为yaml文件和xml配置进行同步。如果要通过图形化编辑器的方式一并解决，那要把目前调用了preferences的全部代码都重构一遍了。
感觉有点头大
trime.yaml目前是在存储皮肤参数
现在设置里的大部分也是样式相关的配置项, 感觉问题不大
或者再加一个配置文件
其他 rime 前端是如何做的?
并且trime.yaml需要进过build过程
只 build 单个文件速度是很快的, 可以做到无感知
实际现在切换 theme 也是在 build
如果用户在图形界面修改参数，再把值反馈回到yaml文件，似乎...有点怪
通过图形界面修改配置文件是很常见的
按照 rime 的规则, 程序修改的是 .custom.yaml, 难点是序列化这部分没有实现, 其他都很好解决
只 build 单个文件速度是很快的, 可以做到无感知
实际现在切换 theme 也是在 build
我说build的是在说这个流程原先的是单向的。要说效率，显然不是问题。
其他 rime 前端是如何做的?
众所周知，小狼毫通过图形界面只能选择配色和方案，而且还是一个单独的程序😂
我说build的是在说这个流程原先的是单向的。要说效率，显然不是问题。
rime 本身就有 generator 来生成配置文件, 流程没有问题的
众所周知，小狼毫通过图形界面只能选择配色和方案，而且还是一个单独的程序😂
但是小狼毫的其他配置项, 也都是存在 UIStyleSettings 生成的这个 .custom.yaml 文件内的, 只是它的图形界面只实现了部分配置项的编辑
这和现在 trime 的情况一样, 可以先只把现有的带界面的配置项的编辑和保存实现 (比如配色和方案)
单独存一个 xml 体验还是太割裂
但是小狼毫的其他配置项, 也都是存在 UIStyleSettings 生成的这个 .custom.yaml 文件内的, 只是它的图形界面只实现了部分配置项的编辑
这和现在 trime 的情况一样, 可以先只把现有的带界面的配置项的编辑和保存实现 (比如配色和方案)
单独存一个 xml 体验还是太割裂
现有的preferences xml已经有齐全的编辑界面，用户完全不需要直接修改xml文件的内容。在这个前提下xml和yaml又有什么区别呢？
现有的preferences xml已经有齐全的编辑界面，用户完全不需要直接修改xml文件的内容。在这个前提下xml和yaml又有什么区别呢？
trime 要同时支持图形和文本修改配置, 对于图形这部分没区别, 但是文本修改就有区别了
有一部分配置只能图形修改, 或者反之, 都是割裂的