Majorsilence.Forms

八月以来的进展：26.9.0、四个新后端、CSS 主题，以及行为审计

2026-10-08T14:30:00+00:00

上一篇文章是基于 26.0.30 写的。自 2026-08-17 以来，仓库新增了 557 次提交，当前发布版本是 26.9.0。这是一篇面向现有用户和评估者的汇总：有哪些变化，各部分的成熟度如何，以及升级时你必须做的那一件事。

四个新后端

之前有三个宿主——Avalonia、Uno、Headless。现在有七个，全都运行同一套控件；区别只在于由谁来创建窗口、呈现 Skia 表面。

GTK 4（Majorsilence.Forms.Gtk4）是一个 Linux 优先的宿主，基于 gir.core 构建：每个窗体对应一个真正的Gtk.Window，使用 GLib 主循环，在装有 GTK 4 运行时的 Windows 和 macOS 上同样可用。在 Application.Run之前用 Gtk4Application.Use (); 显式选择它。嵌入可双向进行（ToGtkWidget()、ToGtkWindow()），NativeControlHost 没有空域（airspace）问题，因为 GTK 4 以单一渲染树进行合成；WebBrowser 由WebKitGTK 6.0 支撑。已在 Wayland 上验证。已知缺口：无法控制屏幕位置（GTK 4 移除了该 API），SetIcon(byte[]) 是空操作，原生文件选择器返回空结果因此使用回退对话框，仅支持整数缩放因子，尚未做 AOT 分析。

Terminal（Majorsilence.Forms.Terminal，2026-10-04）把一个窗体以单视图的形式宿主在控制台里——窗体填满终端，没有标题栏，就像手机一样。在可用的情况下，它以真实像素分辨率使用 Kitty graphics 或 Sixel，否则使用 Unicode 块元素；检测方式是向终端查询，MF_TERMINAL_GRAPHICS=halfblock|kitty|sixel 可锁定某种模式。鼠标和键盘可用；Ctrl+C 始终退出。用 TerminalApplication.Use (options); 选择它。仅在 xterm 和WezTerm 中验证过。没有原生选择器、NativeControlHost 或 webview。

WinForms（Majorsilence.Forms.WinForms）是一个仅限 Windows 的迁移后端：在 Win32 消息泵上使用真正的System.Windows.Forms 窗口，Skia 通过 GDI 位图呈现。它的存在是为了让你能把 Majorsilence.Forms 控件一个一个地嵌入现有的 WinForms 应用——myMfControl.ToWinFormsControl()、myForm.ToWinFormsForm()、MajorsilenceFormsPresenter——等全部移植完成后再把宿主切换到 Avalonia 或 Uno。不支持手势，没有IWebViewFactory。它不同于更早的 WindowsFormsInterop，后者是在 Avalonia 宿主上桥接整个窗体。

WPF（Majorsilence.Forms.Wpf）对 WPF 应用而言有着相同的形态和用途：一个真正的 WPF Window、WriteableBitmap 呈现、ToWpfElement() 和 ToWpfWindow()。用Platform.Backend = new Majorsilence.Forms.Wpf.WpfPlatformBackend (); 选择它。

Avalonia、WinForms 和 GTK 4 提供真正的操作系统级模态对话框；Uno 则会打开一个独立窗口，因此在那里请使用Form.ShowDialog(parent)。

.NET Framework 4.8 与 netstandard2.0

核心包——Majorsilence.Forms、.Drawing.Common、.Telerik——现在多目标于 net8.0、net10.0以及 netstandard2.0，WinForms 和 WPF 后端还增加了 net48。因此，一个 .NET Framework 4.8 应用可以在不先迁移到现代 .NET 的情况下宿主 Majorsilence.Forms 控件，这消除了许多迁移项目曾面临的先后顺序问题。

行为缺口审计

两份 API 表面缺口计划（WinForms 和 GDI+）已归零：上游拥有的每一个成员都已声明。但这一直是不太有意思的那一半。一个存在却只是存储一个无人读取的值、或者引发一个无人触发的事件的成员，能让你迁移后的应用编译通过，然后悄悄地什么也不做。

因此在 2026-08-25，一次覆盖十二个领域的审计把每个领域与上游实现逐一对比，记录了 483 项行为不一致的发现。此后，阶段 0–4 和大部分按控件族划分的工作已经落地。现在已经真实可用的具体项目包括：ProcessCmdKey预处理链、单一的焦点/验证汇聚点、标题栏移出客户区、AutoScaleMode.Font 真正进行缩放、实时数据绑定（CurrencyManager、BindingNavigator）、ListView.View = Details、按上游顺序执行的窗体生命周期（Load → VisibleChanged → Activated，Shown 以投递方式触发）、DataGridView 列重排、文本控件中的 Ctrl+Z、系统托盘中的 NotifyIcon、Application.AddMessageFilter，以及释放窗体时同时释放其控件。

空心的表面现在也被度量了：基线文件锁定了已知的空操作方法、惰性事件和仅存储的属性，因此再往里添加就成了有意识的行为，而不是意外。存根策略不变——空操作或返回默认值，绝不抛出 NotImplementedException。

逻辑单位：你必须做的那一件事

在 2026-10-01，ClientRectangle、ClientSize 和绘制画布（OnPaint、Paint、e.ClipRectangle、e.Canvas）改为使用逻辑单位，与 Width/Height/Bounds 和 MouseEventArgs 保持一致。框架会替你把画布缩放到显示器。

如果某个自定义控件调用了 e.Graphics.ScaleTransform (e.Scaling, e.Scaling)，请把它删掉——否则绘制现在会被缩放两次。设备像素仍可通过 Scaled* 系列（ScaledWidth、ScaledBounds……）、PaintEventArgs.Scaling 和 LogicalToDeviceUnits 获得。唯一的例外是所有者绘制事件（DrawItem、DrawNode、CellPainting），它们交给你的仍然是设备像素边界。用 MF_HEADLESS_SCALE=2 运行你的测试，以捕获任何依赖旧行为的地方。

浏览器与移动端

在 net10.0-browser、-android 和 -ios 上，Avalonia 后端报告 CanRunModalLoop = false，而那些阻塞调用——Form.ShowDialog、MessageBox.Show、文件选择器、TaskDialog.ShowDialog、VbInteraction.MsgBox/InputBox、RadMessageBox.Show——现在会在显示任何内容之前抛出 PlatformNotSupportedException 并指出对应的异步版本，而不是挂起。异步形式（ShowDialogAsync、MessageBox.ShowAsync、FileDialog.ShowDialogAsync……）在每个宿主上都可用，因此惯用写法是带 await 的 async void 处理程序。核心包中的一个 Roslyn 分析器可以提前找出这些问题——MFB001 阻塞式模态调用、MFB002 对 Task 的同步等待、MFB003 Thread.Sleep，每一项都附带代码修复——对浏览器 TFM 自动启用，或在 .editorconfig 中设置majorsilence_forms.browser_target = true 启用。

浏览器目标还在画布旁边维护一棵无障碍 DOM：每个控件对应一个透明、可点击穿透的元素，带有 ARIA 角色、名称、状态和边界，由框架自身的自动化树构建而成。屏幕阅读器、页内查找以及基于 DOM 的测试工具现在都能看到这个 UI 了。

在 Android 和 iOS 上，TextBox 获得焦点时会弹出屏幕键盘，TextBoxBase.InputKind 决定键盘类型，安全区内边距通过 Form.SafeAreaPadding 生效，WindowBase.BackRequested 处理 Android 的返回键。坦白说明现状：Android 已完成一轮初步的真机测试（在硬件上确认了启动、点击、渲染缩放、触摸滚动）；键盘、安全区和旋转仅有单元测试。iOS CI 会编译真正的应用头并在模拟器中做启动冒烟检查，但还没有人以交互方式运行过它，该任务仍然是 continue-on-error。

手机风格的布局控件也随之到来：StackPanel、Card、RichListBox（多行模板化行）和 NavigationHost（带返回按钮的页面栈）。

CSS 主题与 Theme Studio

主题现在可以用一个严格、有文档的 CSS 子集来编写：@theme "Ocean" extends Dark;、每个 Theme 属性对应一个 :root 令牌、像 Button:hover { … } 这样的控件类型规则、通过 Type::part 指定部件。解析器绝不会悄悄失败——ThemeStyleSheet.Parse 会收集诊断信息。用 Theme.LoadFromCssFile 加载，或用Theme.RegisterThemeCssFromFile + Theme.ApplyTheme ("Ocean")；用 Theme.ExportCss 导出。每个控件，包括 Telerik 兼容层，都有选择器，而更早的 <Theme> XML 仍然可用。

两个配套包把同一份样式表应用到其他宿主上：Majorsilence.Forms.Theming.WinForms 重新设置真正的System.Windows.Forms 控件的样式（仅限 Windows），Majorsilence.Forms.Theming.Avalonia 重新设置原生Avalonia Fluent 控件的样式，因此一个 CSS 文件就能为混合的迁移应用设置主题。samples/ThemeStudio 是一个带预览和诊断的实时编辑器；预构建的二进制文件附在 GitHub Releases 上。

MVVM、Essentials、动画

Majorsilence.Forms.Mvvm 是建立在 INotifyPropertyChanged 和 ICommand 之上、对裁剪和 AOT 安全的接线层，不用反射，不依赖任何工具包：viewModel.Observe (nameof (VM.Count), vm => vm.Count, …)、双向的BindText/BindChecked/BindSelectedIndex/BindValue、BindCommand，以及一个用来统一释放的BindingScope。它可以与 CommunityToolkit.Mvvm 一起使用。

Majorsilence.Forms.Essentials 把各平台特有的能力放在核心之外：SecureStorage、Speech 文本转语音、Launcher.OpenAsync（http/https/mailto/tel/sms）和 FileSystem.OpenAppPackageFileAsync。一切都会降级为空操作；请检查 IsSupported。

control.RequestAnimationFrame 加上 Majorsilence.Forms.Animation（Tween<T>、Easing、Animator）在 Avalonia 上提供与显示器对齐的动画，在 Headless 上提供手动时钟。

工具

MCP 服务器现在是一个已发布的 dotnet 工具：dotnet tool install -g Majorsilence.Forms.Mcp，然后claude mcp add majorsilence-ui -- majorsilence-mcp --port 4444。它暴露 ui_snapshot、ui_find、ui_click、ui_type、ui_wait_for 和 ui_screenshot，与你应用中的 WebDriverServer 通信。
samples/AutomationTarget 是一个刻意设计得别扭的小应用（有拒绝点击的控件，还有一个没有命名），用于学习这套工具。自定义绘制的控件通过 IAutomationStateProvider 发布值和状态。
迁移器现在仅以 dotnet 工具的形式发布（dotnet tool install -g Majorsilence.Forms.Migrator）；不再向发布版附加自包含二进制文件。新增开关：--map、--dual-build、--strict、--dry-run --diff。
Majorsilence.Forms.WinFormsShims.Compat 是一个概念验证性质的源生成器，它生成由 Majorsilence.Forms支撑的 System.Windows.Forms 和 System.Drawing 命名空间，让未经修改的 WinForms 源码——包括Designer.cs——得以编译。面向公共 API 以 WinForms 类型声明的控件库。目前为 PoC 状态；参见samples/WinFormsCompatDemo。

升级说明

锁定 26.9.0。该项目仍是测试版（beta），仍然没有可视化设计器。
删除自定义绘制代码中所有的 ScaleTransform (e.Scaling, e.Scaling)（见上文）。
模板包 id 为 Majorsilence.Forms.Templates，用 dotnet new install Majorsilence.Forms.Templates 安装。dotnet new majorsilenceforms 现在会搭建一个包含共享 UI 库和桌面头的解决方案；--IncludeAndroid、--IncludeiOS 和 --IncludeWasm 可添加其他头。
破坏性变更列在 MIGRATION.md 中：SplitContainer.Orientation、TreeViewDrawMode.OwnerDrawContent、事件委托类型现在与 WinForms 一致，以及渐变/阴影线画刷已调整为与 GDI+ 一致。
在浏览器、Android 和 iOS 上，把阻塞式对话框调用替换为对应的异步版本；让 MFB001–MFB003 帮你找到它们。

Majorsilence.Forms 简介

2026-07-21T15:00:00+00:00

要把一个 WinForms 应用从仅限 Windows 的桌面环境中迁出，传统做法意味着从头重写：XAML、被迫改成 MVVM 结构，或者转向 Web。这样做成本高、风险大，而且会丢掉多年积累下来、运转良好的业务逻辑和用户体验——而这套代码往往只是需要换一层新外观而已。

Majorsilence.Forms 采取了不同的思路：它镜像 WinForms 的 API 表面——Form、控件、事件处理程序，甚至 *.Designer.cs 代码隐藏文件——并提供一个兼容层，让现有的窗体和控件以小得多的改动迁移过来。编程模型不变；改变的只是它运行的地方。

它是如何构建的

每个控件都通过 SkiaSharp 绘制到一个 SKSurface 上，下面是一个可替换的宿主后端：

Avalonia（默认）——开箱即用地支持 Windows、macOS、Linux 桌面，并自带 Android、iOS 和Browser（WebAssembly）目标，因此也是通往移动端和 Web 的一条路径。
Uno Platform——覆盖面最广：桌面、iOS、Android 和 WebAssembly。
Headless（无头）——不依赖任何显示环境的离屏渲染，用于 CI 和自动化测试。

核心程序集 Majorsilence.Forms 完全不引用任何窗口工具包——只引用 SkiaSharp。各个后端是独立的程序集，通过两个小接口 IPlatformBackend 和 IWindowBackend 接入。正是这条接缝（seam）让完全相同的应用今天可以面向 Avalonia、明天面向 Uno，而应用代码无需任何改动。详见平台后端。

它适合谁

如果你手上有一套目前仅限 Windows 的 WinForms 代码库，又想保持前进的势头——复用你的控件、团队的既有习惯和业务逻辑——而不是开启一场持续多年的重写，那么它就是为你而设计的。

这个项目仍处于早期阶段：API 正在趋于稳定，WinForms 的每个角落尚未全部覆盖。它已经很适合用于新的跨平台业务（LOB）应用，如果锁定版本，也可以用于迁移真实的生产应用。请查看兼容性矩阵，了解目前哪些已实现、哪些还是存根。

试一试

dotnet new --install MajorsilenceForms.Templatesdotnet new majorsilenceformsdotnet run

或者直接研究一个真实的应用——samples/Explorer是一个完整的 Windows 资源管理器克隆，samples/Outlaw是一个 Outlook 克隆，两者都在同一套控件上跨平台原样运行，无需修改。

参阅快速上手来搭建你的第一个应用。

平台后端：Avalonia、Uno 与 Headless

2026-07-21T11:00:00+00:00

Majorsilence.Forms 用 SkiaSharp 完成全部自己的绘制。每个控件都绘制到一个 SKSurface/SKCanvas 上；底下的窗口工具包只是一个宿主——它创建原生窗口、运行消息循环、传递输入，并把 Skia 表面呈现到屏幕上。正是这种分离，让完全相同的一套控件今天能在三个差异极大的工具包上运行。

接缝

两个接口定义了宿主必须提供的一切：

IPlatformBackend 负责应用级服务——调度器（Post/Invoke）、计时器、剪贴板、屏幕枚举以及模态循环。IWindowBackend 负责单个原生窗口——尺寸和位置、显示/隐藏/关闭、光标、窗口装饰、文件对话框。输入和绘制请求则沿相反方向流动：后端直接调用窗口的中立方法 RenderFrame(SKCanvas, …) 和 Handle*。没有任何平台类型——没有 Avalonia 类型，也没有 WinUI 类型——会越过边界进入 Majorsilence.Forms 的核心代码。

今天的三个后端

Majorsilence.Forms.Avalonia 是默认后端——基于 Avalonia 12，零配置即可支持 Windows、macOS 和 Linux桌面。引用它，然后 Application.Run(new MyForm()) 就能直接工作。它也不仅限于桌面：Avalonia 自带 Android、iOS 和 Browser（WASM）目标，因此这同一个后端也是通往移动端和 Web 的第二条路径，与下文专门的 Uno 后端并行。

Majorsilence.Forms.Headless 是最简单的后端，同时也是编写新后端的参考模板：一个工作队列式消息循环、一个内存剪贴板、一个虚拟屏幕，以及离屏渲染。它不需要显示器，因此单元测试套件就运行在它之上；它还能把ControlGallery 示例直接渲染成 PNG，供 CI 做像素差异比对：

dotnet run --project samples/ControlGallery -- --render-headless out.png 1100 750 --select-row 0

Majorsilence.Forms.Uno 面向 Uno Platform 的 Skia 渲染器，宿主于一个 SKXamlCanvas 之中，覆盖桌面、iOS、Android 和 WebAssembly。它已在 macOS 上端到端验证：Uno 宿主启动，后端创建窗口，ControlGallery 的完整MainForm 渲染进画布。由于它需要交互式会话，它通过一个专门的应用头——samples/Gallery.Uno——运行，而不是无头的 CI 构建。

有一个细节值得指出：Uno 没有以编程方式”开始拖动窗口”的 API，因此 Majorsilence.Forms 自绘窗口边框的移动/调整大小改为以声明方式处理——一个无边框的 presenter 免费保留了操作系统的调整大小边距，而标题栏拖动在 Windows 桌面头上借助 WinUI 的标题区域（caption-region）API 实现。在 macOS 上，则由原生窗口装饰接管拖动/调整大小。

添加你自己的后端

一个新后端只是另一个程序集：引用核心的 Majorsilence.Forms 和你的工具包，实现 IPlatformBackend 和IWindowBackend，并仿照 Avalonia/Headless/Uno 三者的做法——在平台后端中驱动调度器，在窗口后端中呈现Skia 表面并翻译输入。完整的接口清单请参阅平台后端。

用 majorsilence-migrate 迁移 WinForms 应用

2026-07-21T08:00:00+00:00

majorsilence-migrate 是把 WinForms 解决方案自动迁移到 Majorsilence.Forms 的 CLI 工具。它最核心的设计决策很容易被忽略，值得明确指出：它不解析语法树，也不解析符号。它是一个对原始源代码文本进行多遍处理的文本/正则重写器——而这是有意为之。

为什么基于文本，而不是 Roslyn

引用该工具源码中的一句注释：“这是一个刻意基于文本的转换——它不解析语法树——这让它既快速，又能容忍当前无法编译的文件。”

这种取舍换来了两样符号感知型工具无法提供的东西：

它能处理有问题的代码。 迁移了一半的解决方案、引用了尚未有人移植的类型的文件、缺少引用的项目——这些都不会让重写器停下来，因为它从不需要代码能编译，甚至不需要能完整解析。一个具备真正符号解析能力的Roslyn 工具会拒绝处理任何无法构建的项目，这恰恰违背了对遗留代码库做第一遍处理的初衷。
它很快。 没有编译、没有 MSBuildWorkspace、不加载项目图——它能在几秒内跑完成千上万个文件。

代价是：没有真正的跨项目符号解析。重写器不一定总能分辨一个裸的 Panel 引用指的是System.Windows.Forms.Panel 还是你自己的同名类——它依赖的是命名空间前缀和 using/Imports 上下文。实践中这很少产生歧义（WinForms 和 Telerik 的类型名都很有辨识度），而任何它不认识的东西都会被标记出来供人工审查，而不是悄悄瞎猜。

可选的 Roslyn 引擎

对于真正有歧义的情况——同一个文件里，一个自定义类型与某个 WinForms/GDI+ 类型共用同一个裸名称——有一个可选启用的第二引擎：--engine roslyn。它使用 MSBuildWorkspace 和真正的符号解析来代替正则表达式，并且是叠加在文本引擎之上而非取代它；在 Roslyn 模式下仍有若干遍处理保持为文本方式，因为它们从来就不是符号解析问题。

它的取舍与默认引擎正好相反：它需要一个确实能通过 MSBuild 加载的解决方案或项目（裸目录或单个文件会回退到文本引擎并给出警告）；它慢上几个数量级，因为 MSBuild 求值占据了运行时间的大头；而且如果某个项目加载失败，只有该项目的文件会回退到文本引擎——整个运行不会中止。如果根本找不到 MSBuild，整个运行会直接硬性失败，而不是悄悄降级。

什么时候该用它： 在用默认的 --engine text 跑完第一遍之后，针对一个已经能干净加载的项目，并且你在diff 中看到了某个具体、已确认的名称冲突情况。而对于一个庞大、可能半残的遗留代码库的首次处理，默认的文本引擎仍然是正确的工具。

接下来

参阅仓库中的 MIGRATION.md，了解逐遍处理的完整细目；以及 COMPATIBILITY_MATRIX.md，了解迁移后的代码编译通过之后，哪些功能是真正已实现的。