Add Wayland on Mac/Darwin support#2397
Conversation
Adds Wayland on MacOS support via XDG variables :3
Up to standards ✅🟢 Issues
|
|
+1 - This PR is significant to me, as I’m the developer of the Wawona Wayland compositor. We have successfully implemented DRM/KMS and nested Wayland rendering on macOS. However, Fastfetch’s reporting as “aqua de/wm” is highly inaccurate in this context. This PR helps improve the accuracy of screenshots taken from Wayland clients on macOS. I look forward to it being merged upstream. |
|
quartz* |
| if (getenv("WAYLAND_DISPLAY")) { // Is user on wayland? | ||
| const char *desktop = getenv("XDG_CURRENT_DESKTOP"); | ||
|
|
||
| ffStrbufSetStatic(&ds->wmProcessName, "Wayland"); |
There was a problem hiding this comment.
What does this mean? Wayland is a protocol. There's no process named Wayland.
| const char *desktop = getenv("XDG_CURRENT_DESKTOP"); | ||
|
|
||
| ffStrbufSetStatic(&ds->wmProcessName, "Wayland"); | ||
| if (desktop && *desktop) { // If user is on a custom WM that sets XDG_CURRENT_DESKTOP? |
There was a problem hiding this comment.
AFAIK XDG_CURRENT_DESKTOP is the name of the current desktop environment, such as KDE Plasma. While kwin is the name of Window manager (or Wayland compositors, strictly speaking)
In fastfetch they are different modules.
|
I don't like this. Setting an environment variable doesn't magically make you running in wayland. In the implementation of Linux port, we actually connect the wayland protocol and query screen resolutions (in this case, resizing the compositor window should change what |
Not at all. This PR doesn't touch other parts. Fastfetch will be reporting as “aqua de/wm”. BTW, is fastfetch wrong? Does your compositor replace quartz? Instead, your compositor is fully built upon quartz (CoreGraphics, Cocoa, etc), isn't it? |
3 participants
Summary
Adds Wayland on MacOS support via XDG variables :3
see Wawona and iLand.
Related issue (required for new logos for new distros)
N/A
Changes
Screenshots
Checklist