关于第一次使用 echo-live 1.5.0 版本后的一系列提议
- 我已确认 Echo-Live 近期没有类似更新。
- 我已确认近期没有其他人提出类似提议。
- ~~我并不确认这些功能是不是已经做进去了,它们可能藏在 doc 的某个角落。~~
- 反正有想法先提吧,有没有做不做另外一回事 ~~wont fix 预定~~
提议描述
以下提议全部基于“方法一:通过 OBS 内置浏览器广播传递消息(推荐)”的使用方式。
- [x] 在“闲置时自动隐去”为开的情况下,隐去后再现只是将原先的内容呈现出来了,提议使用退格动画(即“迅速”删去原先的内容)
- [x] 不过这看上去会带来一个新的问题,如果连续的两条消息还切了 username,username 似乎不应该用退格动画,淡入淡出吗?
- [x] 对于单一 username 下的重复消息:
- [x] (仅提议)我认为的确有这么一个需求,就是复读同一个消息,像是刷新一样的感觉,但目前状态并不会出现任何反应(在自动隐去状态下也不会再出现),我不知道是否需要做这么一个东西刷新一下;
- [x] 历史记录-消息-去除连续的重复消息似乎是为多 username 考虑的,但对于单一 username 的重复历史记录似乎没有一个选项可以处理。
- [x] (仅提议)我个人需要多行渲染/手动换行,但似乎没有一个选项可以启用(看了下 Echo,从设计的角度上看似乎并没有设计?)
- [x] ~~不过把 LF 先转成 \n 再渲染成 <br> 也太欢乐了~~,CR 渲染不出来。
- [x] ~~闲的蛋疼~~发送奇怪的文本,例如“ (&Tab)”会直接导致消息无法发送,提示信息为:
[ERRO] 发送的消息格式存在错误。详见帮助文档:https://sheep-realms.github.io/Echo-Live-Doc/message/
- [x] 在 OBS 加载后,通过设置初始化的 username 仅仅显示在编辑器中,editor 配置的说话人和 start.js 的配置不能统一(或者说要手动统一)的设计我感觉很割裂...不知道会不会处理这个问题/怎么搞。
- [x] ~~我觉得对话框高度应该可以改吧怎么找了半天没找到,现在的高度对我而言我感觉有点高了。~~
- [ ] ~~闲的蛋疼~~对于过长的文本,溢流文本会直接撑开对话框下面。在上一条的基础上,我想要把它高度改小一点的话,可能会产生更多的溢流文本,直接手动配置/分很多次发单条我感觉会很麻烦,会考虑加一个自动化设置(如发送多长的文本之后配置一个自动顿几秒切下一条)吗?
- [ ] “多行文本分割为消息队列”这个试验性功能看上去也是为多 username 准备的,在上一条的基础上,能配置类似于自动顿几秒发下一行文本的机制吗?
实现方法
- 对于多行的问题我在想要不要放一个快速格式化,还是说直接做兼容?~~还是 wont fix~~
- ~~剩下的我还在看,所以上面全部是用的 toggle。~~
一条条来,关于第一点,这是刻意为之。由于动画时间是可调的,不可假定显现动画不会干扰观看文本打印过程,因此打印需要等待动画结束才会开始。此外 Echo 内核的退格功能是残废的,无法使用。
关于第二点,由于早期版本发生过逆天的用户操作导致逆天的故障,再加上防抖考虑,对话框会忽略重复的消息,但这技术上是可以调整的,可以作为一项高级设置更改。而历史记录忽略重复消息是考虑到可能存在多个对话框同时接收消息,历史记录实际上并不接收来自编辑器的消息,而是接收来自对话框响应时的转发消息,这会导致历史记录出现重复消息。
关于第三点,不小心改爆了,这是个 BUG。
关于第四点,start.js 仅作为示例用途,设计上是方便随时刷新调整布局,不是用于开场白的。
关于第五点,对话框所有主题都可以自适应高度(部分主题不允许把高度拉得太逆天),请自行调整对话框容器高度。文本溢出的问题目前暂时没想到优雅的解决方案,不过可以考虑设计一款全屏幕覆盖的主题,文本贴靠屏幕下端,可以根据内容自动抬高。
关于 2.1 的提议我已经在最新提交中新增了一项配置来关闭防抖。
不过我有个问题,你在 3.2 中提到了发送特定文本会报错,但无论我是发送 (&Tab) 还是 \t 都无法复现这个问题,你具体是发送了什么内容?
关于 2.1 的提议我已经在最新提交中新增了一项配置来关闭防抖。
不过我有个问题,你在 3.2 中提到了发送特定文本会报错,但无论我是发送
(&Tab)还是 \t 都无法复现这个问题,你具体是发送了什么内容?
~~复现不出来了当时该截个图的。~~
另辟蹊径复现出来了,产生的是相似但不一样的问题,虽然用的是1.5.0,~~尽管我看到了最新是1.5.2~~,刚更新到1.5.1还会犯,按下述操作: 在“输出内容”不要使用\t或者\n,而是直接输入LF或Tab,那么会产生报错,例如:
我推测之前我发现这个问题是由于&Tab因为一些不知名的原因没有被对应地解析为\t,但是我刚刚又测试的时候发现实际上1.5.0可以正常解析。
这么操作肯定会出问题啊,这已经不能被解析为 JSON 了,换行符需要转义
我的意思是之前可能没有被正常转义导致出现了这样的问题,但是具体问题出在哪里我不知道因为我一时半会复现不出来了。
如果又复现出来了我下面再补
希望编辑器发送信息时可以显示目前发送的信息
Marked as Closed.
如果有需要补充的建议新开issue。