弃用 Flet 作为 CFMS 客户端的 UI 框架

长期以来，作为 Confidential File Management System 的上游维护者，我在着手实现该系统面向用户的客户端时，出于上手难度的考虑，均采用了 Flet ——一个允许利用 Python 来编写和构建 Flutter 应用的框架——作为客户端的 UI 框架。

这个决定最初的确起到了作用，它使得我可以更好地专注于网络通信细节的实现，而不必为了开发客户端额外学习过多的前端知识——然而，在客户端的开发工作日益深入之后，该框架却逐渐成为了我们在提高客户端易用性和美观性上的最大阻碍。

首先，由于该框架的作用是实现 Flutter 与 Python 的桥接，由它产生的应用程序必须捆绑 Python 运行时，并在实际运行前释放运行时及 Python 源码。基于包括这一因素在内的种种原因，Flet 应用的初始化和启动速度均缓慢到了一个不可忽视的速度；其次，可能是受维护者精力的限制，Flet 对最新版本的 Python 的支持也相当消极，这对移动端应用的影响是巨大的，因为 Python 中用于加密等的 C 库需要专门为移动设备重新编译，而无论是 Flet 的维护者还是我们似乎都缺乏为 Python 和这些 C 库的新版本更新编译工作流的精力。

再次，该框架在控件的管理上的实现也是相当低效的，对于行和列数稍微大些的表格（如 100*10），Flet 要将其显示出来就需要惊人的数秒时间。这无疑是不可忍受的。

另外，Flet 的开发文档也相当不利于阅读，充斥着大量缺乏说明的接口，一些文档也已经过时，令开发者在功能的用途上产生迷惑。而 Flet 的实现也显得有些混乱，以至于在发生问题时我们甚至无法判断是使用这些功能的方法错误，还是这些功能本身存在未修复的问题。而即使功能的实现确实存在问题，它们也迟迟得不到修复。

基于上述的种种原因，为了将来的可维护性和可拓展性着想，我最终决定弃用 Flet 这一 UI 框架，而改用全新的技术栈重新实现 CFMS 客户端。同时，随着大语言模型的能力成熟，合适的时机也已经到来。

正在使用 CFMS 的用户可能已经注意到，在过去的一段时间里，借助当前几个前沿大模型的支持，我们已在新的客户端上复现了旧有客户端的所有功能，并实现了那些我们过去在技术上所无法实现的构想，使得客户端能够更好地从用户操作的角度减少数据的泄露。我们有理由认为，尽管或许还需要接受一些安全审计，但从客户端的标准而言，新的客户端实现已经足够成熟，以至于我们认为是时候停止对旧客户端的维护，而推荐所有用户改用新的客户端。

尽管新的客户端在 UI 的设计上仍有一些 AI 痕迹的残留，但在我们重新设计出一套足够美观的显示方案前，我决定暂时不对 UI 的设计风格进行修改。我们也欢迎任何人给出在 UI 设计上的建议，帮助我们开发出美观、实用与安全性并存的客户端应用。

如果感兴趣的话，可以在此访问新的客户端的代码仓库。