OK. I’ve created https://gerrit.libreoffice.org/c/core/+/207999. While It depends on your relation chain of patches, I marked it as WIP so that your patches can be committed without committing my patch.
Note: the patch works but it causes a ton of “if Apple” conditions so we shouldn’t rush to commit. But at least it is there so you can see if any Qt6 issues are due to scaling or not by temporarily applying my patch in your local build. The big issue is that I merely ported the Retina display (HiDPI) approach that LibreOffice (and OpenOffice before it) has used for macOS. Problem is that Windows and Linux use a very different approach to handling HiDPI displays and, now that Collabora has forked, we have a “bus factor” of 1 (me) for the production macOS HiDPI code. So it might make me sense to *not* commit my patch and work through the pain of switching macOS to the same HiDPI approach as Windows and Linux. A simplistic comparison for anyone who isn’t familiar with the different approaches: - Linux and Windows: the LibreOffice platform independent code scales its window sizes and content to prevent everything being tiny on the HiDPI screen. For example, if a HiDPI display has 4 pixels in the same physical space as a pixel on a normal display (i.e. more pixels are packed in per square inch), then LibreOffice doubles the size and width of everything it draws. - macOS: the LibreOffice platform independent does not do any scaling of windows size or content and the LibreOffice code behaves as if it is drawing to a normal display. Instead, the low level macOS window sizing and drawing functions take normal display sizes and coordinates and double the scaling to behind the scenes. For example, if a Retina display has 4 pixels in the same physical space as a pixel on a normal display, macOS functions will behave as if the display is only half its actual width and height. Then if you draw a one pixel thick line, the macOS functions will actually draw a 2 pixel wide line to the screen. AFAICT, Apple used this approach so that macOS developers wouldn’t need to rewrite their applications to scale for Retina displays. Patrick > On Jul 12, 2026, at 4:45 PM, Patrick Luby <[email protected]> wrote: > > 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
