Thanks Dan! I was able to apply, build, and run your Qt for macOS patches against the latest master commit without any problems. :)
Nice work on the application menu items! Don’t know if you have seen this, but they work when a document item is open and unedited, but not if in the Start Center or no window is open. Hopefully my window sizing and content scaling work isn’t bumping into your work. I’ll work on getting my ugly, experimental macOS patch in https://gerrit.libreoffice.org/c/core/+/207229 into a new Gerrit patch that works with your master patches. BTW, I didn’t see any of the merge conflicts that Gerrit shows so I assume that is good news. I did a git pull -r on master, downloaded the top of the relation chain patch, and rebased the local relation chain branch created by the download to master without any need to merge or resolve conflicts. Patrick > On Jul 12, 2026, at 8:42 AM, Dan Williams <[email protected]> wrote: > > Hi, > > I pushed the Mac-specific patches here: > > remote: https://gerrit.libreoffice.org/c/core/+/207978 configure: accept > --with-qt6-dir in addition to QT6DIR environment variable [NEW] > remote: https://gerrit.libreoffice.org/c/core/+/207979 vcl/osx: refactor > yield mutex and extract printing bits to intermediate class [NEW] > remote: https://gerrit.libreoffice.org/c/core/+/207980 vcl/qt: enable Qt6 > plugin for Mac [NEW] > remote: https://gerrit.libreoffice.org/c/core/+/207981 osx/qt: look for > frameworks, not dylibs [NEW] > remote: https://gerrit.libreoffice.org/c/core/+/207982 vcl/osx: work around > "UInt" name conflict between macOS and Qt6 [NEW] > remote: https://gerrit.libreoffice.org/c/core/+/207983 qt5: fixup for > "Consistently use __EMSCRIPTEN__ instead of EMSCRIPTEN macro" [NEW] > remote: https://gerrit.libreoffice.org/c/core/+/207984 vcl/qt: add Mac > display sleep inhibit support [NEW] > remote: https://gerrit.libreoffice.org/c/core/+/207985 vcl/qt: add Mac > Application menu items to App menu [NEW] > > I think these should be enough to get the plug-in building. I’ll update the > already-posted non-Mac-specific layout/look-and-feel patches quite soon. > > Dan > >> On Jun 23, 2026, at 8:03 AM, Dan Williams <[email protected]> wrote: >> >> >> >>> On Jun 22, 2026, at 9:35 PM, Patrick Luby <[email protected]> wrote: >>> >>> >>> >>>> On Jun 22, 2026, at 1:31 PM, Dan Williams <[email protected]> wrote: >>>> >>>> Yeah, ton of work still; slowly getting spacing/margins/etc where I think >>>> they should be. It’s an interesting exercise and welded dialogs actually >>>> look pretty good on macOS. >>> >>> I’m sure we’ll have to reimplement a bunch of little macOS bug fixes that >>> are in the vcl/quartz and vcl/osx code. The fix for live resizing that >>> forces a bunch of LibreOffice timers to run immediately still makes me >>> wince every time I open vcl/osx/salframeview.mm. :/ >> >> I do wonder how much Qt handles internally on Mac though; perhaps they’ve >> fixed some of those issues already. >> >>> >>>> High DPI is still WIP; when I make it look OK with Qt it isn’t right with >>>> the Aqua plugin. Haven’t debugged that yet, focusing on the spacing stuff. >>> >>> Any chance you could put some #ifdef SOME_NEW_MACRO around your HiDPI code >>> and commit it to your private branch? I have some time this week to debug. >>> Might also give me an entry point for understanding the Qt6 vcl >>> implementation. >> >> I’d love to either figure out a non-ifdef solution or to push it down to the >> VCL plugin. I have two patches in the private branch: >> >> vcl/qt: use physical DPI rather than logical to handle HighDPI >> vcl/window: use 72 DPI for Mac >> >> That if applied make the qt6 Mac VCL plugin look OK, but make >> Aqua/non-Mac-Qt look bad. One works for text and the other to graphics (not >> surprised, but I didn’t expect to have two different paths like this). Some >> of it is cribbed from the existing Aqua plugin. >> >> Those patches cleanly revert so you can test/debug fairly easily that way if >> you like. >> >> Dan
