 |
kuanatV2EX 第 634702 号会员，加入于 2023-06-19 11:38:40 +08:00今日活跃度排名 2589 |
| Go 语言的错误处理语法，不改了！ Go 编程语言 • kuanat • 151 天前 • 最后回复来自 bunny189 | 68 |
| Jetbrains 发布了 Kotlin 官方 LSP Visual Studio Code • kuanat • 168 天前 • 最后回复来自 ExplodingFKL | 1 |
| 全闪 NAS 的一些心得体会 NAS • kuanat • 179 天前 • 最后回复来自 idontunderstand | 25 |
| 我转发了一张图到前端群，大周末的群里已经爆炸了 程序员 • kuanat • 302 天前 • 最后回复来自 zbowen66 | 108 |
| 基于 Go 语言谈软件开发效率 Go 编程语言 • kuanat • 308 天前 • 最后回复来自 phoulx | 15 |
| Zed Linux vim 模式输入法切换 Zed • kuanat • 46 天前 • 最后回复来自 kuanat | 2 |
| 一个好用的、纯软件的扩展屏方案 分享发现 • kuanat • 2024-06-04 22:45:38 PM • 最后回复来自 kuanat | 2 |
| V2EX 是否会考虑增加专栏功能？ V2EX • kuanat • 2024-04-29 12:49:46 PM • 最后回复来自 kuanat | 5 |
| 分享一些 Go 在全栈开发中的经验
13 Go 编程语言 • kuanat • 2024-07-23 15:46:51 PM • 最后回复来自 GeekGao
|
43 |
kuanat 最近回复了
1 天前 回复了 YUX 创建的主题 › 分享创造 › 我用 Zig 重写（并重新设计）了 frp 和 rathole |
楼上说米氏对比法太逗了……
能具体说一下二进制文件体积的比较标准吗？因为我看这个项目里 build 设定里面是动态+strip 。
再就是原始 run_benchmarks 的结果有吗？从测试脚本看，这个更多是加密协议之间的对比。
能具体说一下二进制文件体积的比较标准吗？因为我看这个项目里 build 设定里面是动态+strip 。
再就是原始 run_benchmarks 的结果有吗？从测试脚本看，这个更多是加密协议之间的对比。
1 天前 回复了 renchong 创建的主题 › 程序员 › 有在用 flutter 的朋友吗，官方为何连这样基础的功能都不支持？ |
以我个人的体验来说，Flutter 的质量、社区生态算是比较好的了……问就是 bug 太多修不过来。
跨平台 UI 本来就是妥协方案，只能说强依赖这样的方案不是很理智，类比到现实就是一个便宜的替代方案不能期待它提供 100% 的体验。
跨平台 UI 本来就是妥协方案，只能说强依赖这样的方案不是很理智，类比到现实就是一个便宜的替代方案不能期待它提供 100% 的体验。
1 天前 回复了 bczhc 创建的主题 › Android › MIUI 13 如何关闭系统的 compose key |
@bczhc #2
看你这个回复基本上就是系统的 bug 了。小米的软件 bug 多到离谱，而且大多数时候管杀不管埋……
关键是从这个表现来看，在进入到 InputMethodService 之前就被拦截了，连拯救一下的机会都没有。
看你这个回复基本上就是系统的 bug 了。小米的软件 bug 多到离谱，而且大多数时候管杀不管埋……
关键是从这个表现来看，在进入到 InputMethodService 之前就被拦截了，连拯救一下的机会都没有。
2 天前 回复了 pbk 创建的主题 › 中州韻 › 自用 Squirrel [鼠鬚管] Rime MacOS 全局记录 ascii 模式的版本，有需要的自取 |
我来解释一下 Rime 作者为什么不接受这个实现方式，以及作者期望的可能的实现方式。
按照作者的术语习惯，librime 核心部分称为后端，也叫算法引擎，weasel/squirrel/ibus-rime 这些官方应用称为前端。这里忽略掉操作系统的输入法框架细节，搞清楚两个事情即可，一个是前端和后端之间是通过 ipc 通信的，另一个是像获取并维护输入焦点信息、输入法状态本身的管理是在前端完成的。
实际上只有 librime 后端才是输入法状态的真实来源，squirrel 这个前端只有逻辑上的 get/set 接口。由于 macOS/Linux 的输入法框架都是基于 ipc 的，所以 librime 后端实现了 Session 机制，用于区分不同的输入焦点目标。
现在 squirrel 前端的实现非常 naive ，对于每个输入目标焦点，都通过 createSession 来创建一个新的 session 。你现在的实现思路是，通过 squirrel 暴露的 set 接口，控制 librime 后端每个 session 的实际状态。
作者认为更好的方法是，在 squirrel 层面实现一个 session 复用机制，而不是每个输入焦点都用 createSession 来创建新的 ipc 连接。
这种实现方式也非常直接，我这里拿 fcitx5-rime 这个基于 fcitx5 框架的 rime 前端做例子。
fcitx5-rime 逻辑上不区分具体的 ascii 还是简繁或者其他什么状态，只关心是不是要在不同的输入焦点目标之间“共享状态”，有全局共享/应用内共享/不共享三个逻辑层次。
具体实现层面上，fcitx5-rime 维护了一个与 librime 后端之间的 ipc 连接池，对接到了 librime session 相关 api 。根据用户设定的共享状态，选择性创建或者复用 session 。
我不用 macOS 很久了，只是大致看了一下 issue 和代码，有可能说错，但我感觉这个大致的思路是没问题的。
按照作者的术语习惯，librime 核心部分称为后端，也叫算法引擎，weasel/squirrel/ibus-rime 这些官方应用称为前端。这里忽略掉操作系统的输入法框架细节，搞清楚两个事情即可，一个是前端和后端之间是通过 ipc 通信的，另一个是像获取并维护输入焦点信息、输入法状态本身的管理是在前端完成的。
实际上只有 librime 后端才是输入法状态的真实来源，squirrel 这个前端只有逻辑上的 get/set 接口。由于 macOS/Linux 的输入法框架都是基于 ipc 的，所以 librime 后端实现了 Session 机制，用于区分不同的输入焦点目标。
现在 squirrel 前端的实现非常 naive ，对于每个输入目标焦点，都通过 createSession 来创建一个新的 session 。你现在的实现思路是，通过 squirrel 暴露的 set 接口，控制 librime 后端每个 session 的实际状态。
作者认为更好的方法是，在 squirrel 层面实现一个 session 复用机制，而不是每个输入焦点都用 createSession 来创建新的 ipc 连接。
这种实现方式也非常直接，我这里拿 fcitx5-rime 这个基于 fcitx5 框架的 rime 前端做例子。
fcitx5-rime 逻辑上不区分具体的 ascii 还是简繁或者其他什么状态，只关心是不是要在不同的输入焦点目标之间“共享状态”，有全局共享/应用内共享/不共享三个逻辑层次。
具体实现层面上，fcitx5-rime 维护了一个与 librime 后端之间的 ipc 连接池，对接到了 librime session 相关 api 。根据用户设定的共享状态，选择性创建或者复用 session 。
我不用 macOS 很久了，只是大致看了一下 issue 和代码，有可能说错，但我感觉这个大致的思路是没问题的。
2 天前 回复了 ervqq 创建的主题 › 奇思妙想 › Linux 下有没有类似 Time Machine 的软件或者解决方案 |
我用 btrfs subvolumes 方案很久很久了。
准确来说 TM 的功能是两部分，一部分是类似 subvolumes 的本地快照，另一部分是备份快照到非本地设备上。
Snapper 只是自动化创建快照这个工作，备份快照本身可以用 btrfs send/receive 功能。
准确来说 TM 的功能是两部分，一部分是类似 subvolumes 的本地快照，另一部分是备份快照到非本地设备上。
Snapper 只是自动化创建快照这个工作，备份快照本身可以用 btrfs send/receive 功能。
3 天前 回复了 bczhc 创建的主题 › Android › MIUI 13 如何关闭系统的 compose key |
Android 系统在语言和输入法相关设置里有个物理键盘的设定，可以点进去看看是否有切换键盘布局的选项，如果有的话切换到不使用 AltGr/Compose 的布局。印象 aosp 中有过，但我不是很确定。
这个问题说起来比较复杂。Android 系统的输入栈在内核部分和 Linux 是没有区别的，但之后就完全不一样了。因为是针对移动平台设计的，关于键盘布局的设定是和输入法、语言强绑定的。从底层修改这个按键和功能的映射是可行的，可以参考一下 https://github.com/keymapperorg/KeyMapper 这个应用。
简单说 Android 输入栈有两层，最底层和 Linux 处理输入设备一样，在内核态完成 scan code 到名义按键的映射，比如 scan code 1 代表 esc 按键。上面一层是按键和具体功能的映射，比如 A 按键的效果是 a 字符，有 shift 修饰的时候产生 A 字符。
如果你的系统可以获得 root 的话，可以看一下 /system/usr/keylayout/ 和 /system/usr/keychars/ 两个路径的文件。前者包含不同设备的 .kl 定义，代表 scan code 到名义按键的映射，后者包含 .kcm 定义，即名义按键到实际功能的映射，也就是一般所说的布局。可以检查一下是否正常。
如果你可以用 onKeyDown 获得 COMPOSE 事件的话，可以在编写的代码里强行当作 alt 来处理。
这个问题说起来比较复杂。Android 系统的输入栈在内核部分和 Linux 是没有区别的，但之后就完全不一样了。因为是针对移动平台设计的，关于键盘布局的设定是和输入法、语言强绑定的。从底层修改这个按键和功能的映射是可行的，可以参考一下 https://github.com/keymapperorg/KeyMapper 这个应用。
简单说 Android 输入栈有两层，最底层和 Linux 处理输入设备一样，在内核态完成 scan code 到名义按键的映射，比如 scan code 1 代表 esc 按键。上面一层是按键和具体功能的映射，比如 A 按键的效果是 a 字符，有 shift 修饰的时候产生 A 字符。
如果你的系统可以获得 root 的话，可以看一下 /system/usr/keylayout/ 和 /system/usr/keychars/ 两个路径的文件。前者包含不同设备的 .kl 定义，代表 scan code 到名义按键的映射，后者包含 .kcm 定义，即名义按键到实际功能的映射，也就是一般所说的布局。可以检查一下是否正常。
如果你可以用 onKeyDown 获得 COMPOSE 事件的话，可以在编写的代码里强行当作 alt 来处理。
11 天前 回复了 funnypc 创建的主题 › Windows › 有没有一键切换摄像头[禁用/使能]的方案？ |
这里有两个可以独立实现的需求。
提供用户界面的状态指示，状态本身可以依赖 win 环境的 ipc 机制，也可以使用轮询，只要能达到目的即可。
至于控制设备本身的状态切换，主要看摄像头设备连接在什么总线上。如果是 usb 总线上，控制方法就非常多，基本上断电上电就可以，而且很彻底。如果是连接在 ipu 等总线上，通常需要走 acpi 。
提供用户界面的状态指示，状态本身可以依赖 win 环境的 ipc 机制，也可以使用轮询，只要能达到目的即可。
至于控制设备本身的状态切换，主要看摄像头设备连接在什么总线上。如果是 usb 总线上，控制方法就非常多，基本上断电上电就可以，而且很彻底。如果是连接在 ipu 等总线上，通常需要走 acpi 。
17 天前 回复了 BeautifulSoap 创建的主题 › Node.js › 2025 年 node 项目，乱成一锅粥的 typescript ESM import 写法该怎么选？ |
说点跑题的事情，C++20 才引入 Modules ，等生态成熟还早。ESM 应该会成为主流，就是时间可能会很长……
另外我个人认为，任何现代语言都应该有 opinionated 官方统一 fmt/lint ，当然老语言没办法。
另外我个人认为，任何现代语言都应该有 opinionated 官方统一 fmt/lint ，当然老语言没办法。
17 天前 回复了 PeterTerpe 创建的主题 › Android › 红米 K50 刷入 LineageOS 22.1 后 |
LineageOS 现在是很多 custom rom 的上游，涉及型号众多，main tree 基本上是不包含特定厂家的 binary blob/firmware ，同时也不带有 play integrity fix 之类的补丁，也一般不带厂家的相机应用什么的。所以如果要日常使用的话，可以使用基于 LineageOS 的下游改版。
一般来说，常规 integrity fix 能通过 device 等级的检测，要过 strong 等级就要特定的 keybox （因为需要 TEE 参与），这个主要影响的是支付功能。不过以目前主流的 ksu 等内核 root 方案以及改版来说，可以应对大部分应用的 root 检测。针对一些特定应用用到的检测机制，也有一些注入类的解决方案。
如果有一定开发能力，基于 LineageOS 做个修改，是个不错的选择。我有台测试机就是自己集成了一些厂家 binary 和各种 fix ，用着还是挺舒服的。除了第一次做的时候花了不少时间，后面随着上游更新自动构建不是特别麻烦的事情。不过当主力还是要注意备份，这种折腾的设备刷机还是有风险。
一般来说，常规 integrity fix 能通过 device 等级的检测，要过 strong 等级就要特定的 keybox （因为需要 TEE 参与），这个主要影响的是支付功能。不过以目前主流的 ksu 等内核 root 方案以及改版来说，可以应对大部分应用的 root 检测。针对一些特定应用用到的检测机制，也有一些注入类的解决方案。
如果有一定开发能力，基于 LineageOS 做个修改，是个不错的选择。我有台测试机就是自己集成了一些厂家 binary 和各种 fix ，用着还是挺舒服的。除了第一次做的时候花了不少时间，后面随着上游更新自动构建不是特别麻烦的事情。不过当主力还是要注意备份，这种折腾的设备刷机还是有风险。
Select Language