【调查研究】swt集成的可能性以及它的意义

[Gaubee]

swt 本身就是基于 jni 技术，渲染原生的 UI。
所以它的文件选择器也是原生级别的。所以在 desktop 平台上，文件选择器的功能可以使用swt 的 fileDialog 来实现。

目前我没看到 compose-multiplaform 官方有对 swt 的支持。
但是文件选择器它是一个原生的弹出层，理论上可以直接使用。

---

swt 官方还提到对 webview2 的支持:eclipse.platform.swt/bundles/org.eclipse.swt/Readme.WebView2.md at master · eclipse-platform/eclipse

swt 虽然不能和 compose 直接工作，但是 swt 可以嵌入 awt，然后 awt 再和 compose 进行协作：

import org.eclipse.swt.awt.SWT_AWT
import androidx.compose.ui.awt.ComposePanel
val frame = SWT_AWT.new_Frame() // 创建可以在swt中嵌入 awt的jframe
val panel = ComposePanel().setContent{} // 创建可以在awt中渲染compose的jpanel
frame.add(panel) // 组合在一起

但是据说 swt 的 Browser 目前还不支持 macOS 的 WKWebView issues/792。

不过它这种使用 jni 的技术，与语言级别的互操作性有很大差异，本身就不得不抹掉很多底层技术细节，只暴露部分结果上来使用，这就会带来难以做底层自定义的问题。比如说有些属性就无法访问，反射也不行。

---

我粗略阅读了 swt 的源代码后发现，它其实是native层提供反射能力，然后在java层暴力枚举了 appkit 的 API：

• OS.java
• os.c

比如说：通过objc_getClass("NSArray")来获取类的指针；可以用 Selector.java 来创建属性访问器。

也就意味着，完全可以自主实现 WkWebView.java