关于 MaaToolkit 的 struct DesktopWindow 的多平台支持的一些讨论

[YJBeetle]

我正在尝试为MacOS上的原生屏幕截取和鼠标键盘输入做实现，但是在实现DesktopWindowMacOSFinder时候遇到了一些问题。

目前的struct DesktopWindow定义如下：

struct DesktopWindow
{
    void* hwnd = nullptr;
    std::wstring class_name;
    std::wstring window_name;
};

这段定义显然是为了win而设计的，macOS上使用一个无符号整数来标记窗口，称之为Window ID，此外，对于输入，我们将可能会用到目标窗口的PID（调用CGEventPostToPid等），当前的DesktopWindow结构体无法完全满足需求，之所以说是不完全，因为也有折中办法：比如对hwnd进行强制类型转换来存储WindowID、在Control初始化时候通过CGWindowListCopyWindowInfo然后遍历匹配WindowID来获取PID等方法，但是这显然不优雅，另外强制转换存储WIndowID可能会导致Py等的binding那边出现一些奇怪状况。

我想在这里询问并讨论，对于struct DesktopWindow是否有什么更新计划（比如使用union等），以及是否有什么其他好的想法？

我在这里做了一些测试：https://github.com/YJBeetle/MacOSScreenCaptureDemo 可以用来参考MacOS的实现需要用到哪些。

[YJBeetle]

https://github.com/YJBeetle/MaaFramework/blob/ae1d14d49a7bb154803cafdb52b0d11453d21c56/source/MaaToolkit/DesktopWindow/DesktopWindowMacOSFinder.mm#L50

目前尝试所做的实现中将WindowID整数强制类型转换为指针（当然这个指针指向的地址是无效的，使用的只是地址本身，使用时需转换回来）

[YJBeetle]

https://github.com/YJBeetle/MaaFramework/blob/181cf168bfa08c39e83c5043b5f20498d4d9c65f/source/MaaToolkit/API/MaaToolkitBufferTypes.hpp#L29
https://github.com/YJBeetle/MaaFramework/blob/181cf168bfa08c39e83c5043b5f20498d4d9c65f/source/MaaToolkit/DesktopWindow/DesktopWindowBuffer.hpp#L20

在这个分支我尝试对结构体进行扩展，作为一种备选方案之一，扩展后结构体如下：

struct DesktopWindow
{
    // Win32 字段
    void* hwnd = nullptr;
    std::wstring class_name;
    std::wstring window_name;
    // MacOS 字段
    uint32_t window_id = 0;      // macOS 窗口ID
    std::string title;           // macOS 窗口标题
    int32_t pid = 0;             // macOS 进程ID
    std::string bundleId;        // macOS Bundle ID
    std::string applicationName; // macOS 应用程序名称
};

[litwak913]

对于 Linux 上的 wlroots 支持，设计上计划每个 wlroots 合成器即为一个可操作的会话，因此我扩展后的结构体如下：

struct DesktopWindow
{
    // ...
    // wlroots 片段
    std::filesystem::path socket_path; // Wayland Socket 路径
};

[neko-para]

看起来没啥问题，但是如果要改这里的话要考虑要不要整体调整对外接口的逻辑。目前是每个字段都有一个getter函数，这个结构体只是内部的模型而已。
这里我目前看了下，最大的问题其实是mac上搜到的需要两个WindowID和Pid两个联合起来用，导致hwnd这边没法简单的处理了（其实要说的话，我记得WindowID和Pid都是32位的，还真能强行搞到一起，但是太蠢了）；剩下的title对应window_name, bundleid对应class_name也就还好

[YJBeetle]

大概我的想法还是会首选#ifdef， 毕竟 DesktopWindow*Finder.h 三个文件里 第一行其实就是 #if defined(xxx)

[neko-para]

你这里fw内部的结构体怎么定义都行，核心是对外接口怎么办。目前的接口就只有获取window name，class name以及hwnd的

[neko-para]

你用ifdef还是三个类型都无所谓

[YJBeetle]

想了下， 无论是什么平台 有两个字段是一定通用的： Handle 和 WindowName

其中 Handle 对win来说就是hwnd，macos来说就是WindowID。 Handle 应该更具有通用性，目前 MaaToolkitDesktopWindowGetHandle 返回 void*, 应该改成 uint64 。

对于 ClassName 是 win 特有， 同时 MacOS 也有其特有的字段 比如 bundle_id application_name ， 我认为这些应该冠以平台前缀。

最后可能就应该是这样的：
uint64_t MaaToolkitDesktopWindowGetHandle
char* MaaToolkitDesktopWindowGetWindowName
char* MaaToolkitDesktopWindowGetWin32ClassName
int32_t MaaToolkitDesktopWindowGetMacOSPID
char* MaaToolkitDesktopWindowGetMacOSBundleID
char* MaaToolkitDesktopWindowGetMacOSApplicationName

[neko-para]

看起来不错@MistEO