I appreciate Libre Office and would use it as a primary office program if there was a native full screen mode with the Mac OS X. I love using full screen mode with my internet browser, mail program, etc. and would love to do three finger swipes to move between programs, including Libre Office. Currently, it can take up most of the screen, but covers the desktop and doesn't leave it available for view unless the whole window is moved. In the past, you had a full screen mode, but it was buggy, partly because it wasn't really worked on as a feature and because of the bugginess, it was removed. I think this feature would be really nifty and probably lots of people would be happy. Here's one example of a bunch of people who like full screen mode: https://www.reddit.com/r/osx/comments/3mw9va/do_people_actually_use_full_screen_apps_in_os_x/ Please do make it so! Thanks, Dimitri
Tor concluded in bug 117872 that reverting macOS FullScreen mode work of bug 115284 because there is no way to effectively use Apple full screen with the LO code base. "tdf#117872: Revert "tdf#115284: Unify LibreOffice and system full-screen..." Instead, never participate in the macOS system full-screen mode. There is just too much complexity involved, and the way LibreOffice works really isn't prepared for the concept of windows having the option from a system point of view to being full-screenable or not. ..." I don't beleive anything has changed in that regard, meaning this would have to be refactored as native Apple controls--not trivial. Should this native code requirement be driven by UX? Is it needed? IMHO probably not and => WF
The first round of this was for bug 39983, and there the thought was that to do it on OSX that LibreOffice's own fullscrren mode would need to be pruned out to replace with native Apple controls. We didn't go that way.
Would agree with the requirement since we aim for full integration in every OS/DE. Up to the experts, @Tor, whether the technical barrier is too high. Anyway, I would keep the ticket open at the wishlist.
I agree that native macos fullscreen would be fantastic! Any news? All the best
Even though native macOS full screen was disabled in commit c1452e73091412ba0bb72306329e1912df2ba513, while working on tdf#161623 I found that in certain cases, macOS will force a LibreOffice window into native full screen mode. So I implemented very limited native full screen functionality to handle cases where macOS forces a window into native full screen mode. Right now, my code only fixes tdf#161623. But hopefully in the future I can build on this code to enable switching any document window into full screen mode by pressing the green button in the window titlebar. You can try out my code using the following steps: 1. Download tomorrow's (18 December 2024) nightly master build using the steps in https://bugs.documentfoundation.org/show_bug.cgi?id=161623#c6. 2. Follow the steps in https://bugs.documentfoundation.org/show_bug.cgi?id=161623#c0 to force a LibreOffice window into full screen mode. The window will only occupy half the Desktop but it is actually a native macOS full screen window. From there you can hover over the green button in the window titlebar to display more native full screen options.
While fixing tdf#161623, I read through the more recent descriptions of problems that Tor encountered in the previous attempt to implement native full screen mode and I think my fix for tdf#161623 also fixes the following two past problems. Hopefully, further testing won't prove me wrong: Closing a native full screen window ----------------------------------- I also ran this problem when I implemented native full screen windows in NeoOffice. Through frantic trial and error, I found that you can't call -[NSWindow orderOut:] to hide a window while it is in native full screen mode. You must call -[NSWindow close]. Who knows why. Probably just a quirky macOS bug. LibreOffice vs. native full screen mode --------------------------------------- From what I understand, Tor was trying to implement automatically switching into LibreOffice full screen mode when a document entered native full screen mode. In NeoOffice, I never figured how to make LibreOffice full screen mode work in native full screen mode so IIRC (it was over a decade ago so my memory is hazy) I added a hack somewhere to override the View > Full Screen menu and just force the native window into native full screen mode. Basically I did what Tor recommended: remove LibreOffice's full screen mode (at least on macOS). But I took another look at the vcl portion of the LibreOffice full screen code and, at the macOS level, and it wasn't doing much different that native full screen mode other than hiding/showing the menubar and the Dock. Most of the LibreOffice full screen mode stuff is within the window and is handled by the LibreOffice in the Writer and Calc code so no problem keeping that. Most of this problem was in the code that hides and shows the menubar and the Dock. Once I figured out that unexpected things happen when hiding the menubar in native full screen mode, LibreOffice full screen mode now works within a native full screen window.
Created attachment 198165 [details] Snapshot of Writer doc in both LibreOffice and native full screen mode. Note the "Full Screen" button in the top left corner.
Created attachment 198166 [details] Snapshot of Writer doc in only native full screen mode (i.e. after the LibreOffice "Full Screen" button has been pressed).
Update: a nightly master build that includes my fix is finally available. To test my fix, use the steps in comment #5.
Hi Patrick, It has been a long time since I played with this, as I don't use full screen much at all on my Mac (probably because LO didn't play nicely at the time!) With Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 2f5e75ed134cfd0224e03411ca9d7d81f319c91b CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Raster; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded I don't see the fullscreen representation you show in comment 8. I turned Rectangle off, as I thought that might be interfering with the screen draw, but even when off, if I choose the fullscreen option (black rectangle within frame) when hovering on the green button, the window including frame expands to fill up to the limit of the Dock (at the bottom) and the top application menu bar. The application doesn't fill the whole screen. Am I doing something wrong, or perhaps there is some other option I need to fiddle with to reproduce what you see and have illustrated in your screenshot?
(In reply to Alex Thurgood from comment #10) > Am I doing something wrong, or perhaps there is some other option I need to > fiddle with to reproduce what you see and have illustrated in your > screenshot? The green button does not yet work. It is still a "zoom" button. That is a later phase. In this phase, the code can only handle cases where macOS forces a LibreOffice window into full screen mode. To force a LibreOffice window into native full screen mode, following the steps in https://bugs.documentfoundation.org/show_bug.cgi?id=161623#c0. Basically, you have to hover over the green button in a different application such as Safari, Firefox, Finder, etc. and get that application to resize to half screen. Then you select LibreOffice for the other half screen. Once you have LibreOffice in full screen mode (but it only occupies half the screen), the green button will act like it does in other applications. But once you click the green button and exit native full screen mode, the green button will go back to being a "zoom" button.
(In reply to Alex Thurgood from comment #10) > > Once you have LibreOffice in full screen mode (but it only occupies half the > screen), the green button will act like it does in other applications. But > once you click the green button and exit native full screen mode, the green > button will go back to being a "zoom" button. Thanks for the explanation, I could reproduce the behaviour with your description of how to force LO into full-screen mode.
I just tried the half screen to full screen trick and it worked for me. I did see an issue where the cursor was off by a row when hovering/clicking on the toolbar buttons - it's like they are off by the window title bar height. The cursor needs to be below the buttons on the screen to interact with them.
(In reply to Dustin from comment #13) > I just tried the half screen to full screen trick and it worked for me. I > did see an issue where the cursor was off by a row when hovering/clicking on > the toolbar buttons - it's like they are off by the window title bar height. > The cursor needs to be below the buttons on the screen to interact with them. Hmmm. I cannot reproduce this with the 2024-12-30 nightly build. Immediately after using another application to pull an empty Writer document into native full screen mode (but only filling half the screen), the mouse pointer matches the edges of the toolbar buttons and tooltips appear just below and to the right of the mouse pointer. Is there anything different I should try?: Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: ca8c079aa1b42c9a7d582dc04be0437aca1084a5 CPU threads: 8; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
(In reply to Patrick (volunteer) from comment #14) > Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community > Build ID: ca8c079aa1b42c9a7d582dc04be0437aca1084a5 > CPU threads: 8; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx > Locale: en-CA (en_CA.UTF-8); UI: en-US > Calc: threaded @Dustin: Can you copy your LibreOffice version data by selecting the LibreOfficeDev > About LibreOfficeDev menu item and pressing the Version Information button and paste it in this bug? It should look similar to what I pasted above. I ask this because what you describe in comment #13 sounds like tdf#161623 which I fixed around 2 weeks ago so that fix. The Build ID in the Version Information will help me determine if your installation has the fix for tdf#161623 or not.
@Patrick - here's the info: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 16; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Where can I install the latest build with the fix(es)?
(In reply to Dustin from comment #16) > Where can I install the latest build with the fix(es)? Nightly master builds for macOS are at the bottom of the following link. Download whichever "MacOSX-x86_64" build that has the latest date: https://dev-builds.libreoffice.org/daily/master/current.html Important note:: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/39f5af68e9cc7691f8f085af08ef6bf9f9172c6b tdf#128186 Enable native full screen mode on macOS It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have committed a change that enables native full screen mode. With this change, clicking the green button in a window's titlebar will toggle the window in and out of native full screen mode. The old "zoom" behavior is still available by double clicking on the window's titlebar. The change should be in tomorrow's (11 February 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
Another long time issue for LibreOffice on macOS, so your work is very much appreciated Patrick. Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: e79e12484f5a7ec20e48233a2b5b60d7bd8b54ab CPU threads: 12; OS: macOS 15.3.1; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Tested todays main build: - hovering green pill button in top left shows "Move & Resize" and "Fill & Arrange" options of macOS and operations work as expected - clicking green pill switches to fullscreen, to exit move mouse to top until green pill floats into screen, click again switches back to window mode - ctrl+cmd+f switches to fullscreen, this fullscreen view differs in that it shows the "fullscreen" button shown in attachment in https://bugs.documentfoundation.org/show_bug.cgi?id=128186#c7 "Snapshot of Writer doc in both LibreOffice and native full screen mode" The latter is confusing as it is possible to click the green pill while already in fullscreen leading to some sort of double fullscreen mode. clicking the green pill yet again then does not leave fullscreen which could be confusing to users. I have not grasped all reasoning in all the past and recent commit irt macOS fullscreen support in LO, so this all may be as expected. Hope this feedback is useful. Not yet setting to verified.
(In reply to steve from comment #20) > - ctrl+cmd+f switches to fullscreen, this fullscreen view differs in that it > shows the "fullscreen" button shown in attachment in > https://bugs.documentfoundation.org/show_bug.cgi?id=128186#c7 "Snapshot of > Writer doc in both LibreOffice and native full screen mode" > > The latter is confusing as it is possible to click the green pill while > already in fullscreen leading to some sort of double fullscreen mode. > clicking the green pill yet again then does not leave fullscreen which could > be confusing to users. This is expected. LibreOffice has its own feature that is called "Full Screen" but what it really is a "low distraction" layout. So that and native full screen mode have some similarities but they are different. For example, when you use the green button and switch a document into native full screen mode, all of the toolbars, etc. stay visible. But if you select the View > Full Screen, all of the toolbars, the sidebar, and the status bar are hidden. Previous attempts to implement native full screen mode tried to always force LibreOffice into its internal full screen mode when a window went into native full screen mode.
I keep forgetting to note a bug that I found: 1. Open an existing LibreOffice Writer document 2. Press the green button to go into native full screen mode 3. Press Command+w to close the window 4. Reopen the document from the Finder (don't display the Start Center) to reopen the document *not* in native full screen mode The above steps succeed, but the size of the non-full screen window is set fill the entire screen instead of its last non-full screen size.
(In reply to Patrick (volunteer) from comment #21) > This is expected. LibreOffice has its own feature that is called "Full > Screen" but what it really is a "low distraction" layout. So that and native > full screen mode have some similarities but they are different. > > For example, when you use the green button and switch a document into native > full screen mode, all of the toolbars, etc. stay visible. But if you select > the View > Full Screen, all of the toolbars, the sidebar, and the status bar > are hidden. > > Previous attempts to implement native full screen mode tried to always force > LibreOffice into its internal full screen mode when a window went into > native full screen mode. Just wanted to opine as mac LO user keen for this to land! How much confusion might be averted if the View->Full Screen option currently in the UI was instead called "Low Distraction Mode"? At least, on macOS? Because on macOS "full screen" means native full screen. That's the expectation. A low-distraction mode may *imply* full screen, but the inverse does not follow. Green pill works now perfectly according to a mac user's expectations for just entering native full screen and *NOT* entering low distraction mode. Then, if you like, you can *also* enter low distraction mode and it does so in this native full-screen mode and that's fine. And you can exit low distraction mode too without exiting native full screen, and that's fine too. That's all working now, and means it's usable for me now. The issue seems to be "what should happen when you enter low distraction mode, when you're not already full screen?" I suggest what we actually want here is: Enter native full screen, THEN enter low distraction mode, consecutively, as if the user did it manually as described a couple of paragraphs up. Then: "what should happen when the user is in native full screen AND low distraction mode, and they move the pointer to the top to show the titlebar and hit the green pill to exit full screen?" I suggest what we want here is: it exits low distraction mode, THEN exits native full screen mode, consecutively; again exactly as if the user did the two operations manually. (For instance, Sublime Text behaves exactly in this fashion. You can even see that it's doing the two changes consecutively. Ulysses is also similar, with a full screen that keeps the extra in-window furniture visible, and a separate "focused editor" mode that also goes full screen but removes everything but the editor, and exiting that mode goes back to the window with the extra furniture.) That behaviour would accord with mac user expectations. There's just a couple of other bits and pieces. 😉 1: The exit from native full screen back to the desktop seems to be using the wrong animation. On entry to native full screen, it expands the window and slides the desktop aside in one animation, which is correct. On exit, it snaps the window instantly back to its original size (no animated resize), *then* slides the desktop back behind it. It should be the reverse of the entry animation. The final state is correct, it's just the transition animation seems wrong. 2: Because the menubar is hidden in native full screen, but accessible by moving the pointer to the top of the screen, it's unnecessary and in fact wrong to shade and disable all the menu items when in low distraction mode. They should still work. In particular, doing so might obviate the need for having that button in the corner to exit from low-distraction mode, as you can just select it from the View menu, or from hitting the green pill when the titlebar slides down. (Also, maybe then the keyboard shortcut could work to exit that mode if the menu items weren't disabled?) BTW many mac apps *also* have a Window->Zoom item that does what the green-pill button does now on LibreOffice: Enlarge the window to fill the current desktop without going to native full screen. If some people really like it like that, maybe offer that as a new item? But that said, these days macOS has window tiling features which probably obviate it, although they have a "Fill", "Center", and "Move & Resize" submenu under Window that offers those various tiling options. This paragraph is beyond the scope of this ticket though.
(In reply to Rachel Greenham from comment #23) > How much confusion might be averted if the View->Full Screen option > currently in the UI was instead called "Low Distraction Mode"? At least, on > macOS? Because on macOS "full screen" means native full screen. That's the > expectation. A low-distraction mode may *imply* full screen, but the inverse > does not follow. That is an issue that you need to take up with the UX people. Changing the name of any label in LibreOffice requires changes to not only translations but also to the translated help. I am just a volunteer who knows how to wire up LibreOffice to macOS at a very low level. I don't have much time available so I avoid making any UI changes at all. It is administratively a lot of work and a lot of people are involved so others, like yourself, would not to lobby the idea at a UX committee meeting.
(In reply to Patrick (volunteer) from comment #24) > (In reply to Rachel Greenham from comment #23) > > How much confusion might be averted if the View->Full Screen option > > currently in the UI was instead called "Low Distraction Mode"? At least, on > > macOS? Because on macOS "full screen" means native full screen. That's the > > expectation. A low-distraction mode may *imply* full screen, but the inverse > > does not follow. > > That is an issue that you need to take up with the UX people. Changing the > name of any label in LibreOffice requires changes to not only translations > but also to the translated help. > > I am just a volunteer who knows how to wire up LibreOffice to macOS at a > very low level. I don't have much time available so I avoid making any UI > changes at all. It is administratively a lot of work and a lot of people are > involved so others, like yourself, would not to lobby the idea at a UX > committee meeting. The point is taken. It is wrongly named, but we can't change it; or at least it's way too hard and would explode the work needed for this ticket, so, OK, we work with it. 😉 Therefore the actions should be: Green-pill on windowed mode goes to normal native full screen, as the daily does now. Again takes you out again, as the daily does now (although still prefer that exit transition be fixed). View->Full Screen on windowed mode does the action as proposed: Enters native full screen and THEN immediately switches to low-distraction mode. Clicking on green-pill OR the Full Screen button, does the reverse: Switches off low-distraction mode, THEN immediately exits native full screen. Because you can't have that button there and have it *not* exit full screen when you click it. And that's it. You can still enter low-distraction mode from inside native full screen (as you can in the daily now) by doing View->Full Screen, but you can't get back out of low distraction mode but stay in native full screen. You'd have to exit back to windowed, then click the green pill to go back into normal native full-screen mode. But that's still way better than what we have now. 😀
(In reply to Rachel Greenham from comment #25) > View->Full Screen on windowed mode does the action as proposed: Enters > native full screen and THEN immediately switches to low-distraction mode. This is incorrect. Native and low-distraction mode are independent states that can coexist. Switching a document window in and out of native full screen mode does not change the low-distraction mode state. Also, I just tested in my local build and the menubar is always available (although hidden) when in low distraction mode so you can toggle a low-distraction mode window in and out of native full screen mode. In essence, native full screen mode mostly changes the native window border whereas low-distraction mode changes the document layout inside of the window border so no conflicts there.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6dd8de16f20be7d7e4e4581ef303a44b480dd5cb tdf#128186 use non-full screen values for native full screen windows It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have committed a change that fixes the window sizing issue described in comment #22 and the fix should be in tomorrow's (11 March 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
(In reply to Patrick (volunteer) from comment #26) > In essence, native full screen mode mostly changes the native window border > whereas low-distraction mode changes the document layout inside of the > window border so no conflicts there. One correction: there is a slight difference between how native full screen mode and LibreOffice's "low-distraction" mode handle the macOS menubar and Dock so here is what my code currently does: 1. No native fullscreen and no low-distraction mode - Both macOS menubar and Dock are displayed 2. Native fullscreen enabled but no low-distraction mode - Both macOS menubar and Dock are hidden but display when you move your mouse to the top of bottom of the screen 3. Low-distraction mode enabled but no native fullscreen - Both the macOS menubar and Dock are hidden and the LibreOffice menus in the menubar are disabled 4. Both low-distraction mode and native fullscreen enabled - Same as 2 above i.e. the native fullscreen macOS menubar and Dock settings are used) except for one thing: LibreOffice's low-distraction mode disables all of the LibreOffice menus in the menubar. Hope that makes sense.
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/e8f8af2b9872ff8ce646a0278f142cdb5c4005f7 Related: tdf#128186 force key window to a native full screen window It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Created attachment 199980 [details] Snapshot of the new EnableNativeFullScreenWindows expert preference Just in case, I have added an expert preference that can be set to disable native full screen mode. The new expert preference should be in tomorrow's (24 March 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
(In reply to Rachel Greenham from comment #25) > The point is taken. It is wrongly named, but we can't change it; or at least > it's way too hard and would explode the work needed for this ticket, so, OK, > we work with it. 😉 The "we can't change it" (and even "it's way too hard") is a severe over-estimation. While I totally agree with Patrick, and myself tend to avoid UI changes as much as possible - this is actually not a matter of "we work with it", but rather "this should be filed as a separate request, and tracked separately, by people who, to the contrary, like to work with improvements like making names better".
(In reply to Mike Kaganski from comment #32) > (In reply to Rachel Greenham from comment #25) > > The point is taken. It is wrongly named, but we can't change it; or at least > > it's way too hard and would explode the work needed for this ticket, so, OK, > > we work with it. 😉 > > The "we can't change it" (and even "it's way too hard") is a severe > over-estimation. While I totally agree with Patrick, and myself tend to > avoid UI changes as much as possible - this is actually not a matter of "we > work with it", but rather "this should be filed as a separate request, and > tracked separately, by people who, to the contrary, like to work with > improvements like making names better". I agree, and is what I tried to say with that "and would explode the work needed for this ticket". 😀
Patrick Luby committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/eba768cb5588c8b3b30a530028b8ee0a67177b18 Related: tdf128186 update native collection behavior when window becomes key It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
In my previous commit, the new EnableNativeFullScreenWindows expert preference did not change the behavior of windows that are open when that preference is changed. So I committed a new patch today that updates the full screen mode behavior of the green button in each window's titlebar depending on the setting for the new EnableNativeFullScreenWindows expert preference. The new expert preference should be in tomorrow's (25 March 2025) nightly master builds: https://dev-builds.libreoffice.org/daily/master/current.html Note for macOS testers: the nightly master build installer does not overwrite any LibreOffice official versions. Instead, it will be installed as a separate application called "LibreOfficeDev" in the /Applications folder. Because this is a "test" build, you will need to do the following steps before you launch the LibreOfficeDev application: 1. Go to the Finder and navigate to the /Applications/Utilities folder 2. Launch the "Terminal" application 3. Paste the following command in the Terminal application window and press the Return key to execute the command: xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app
*** Bug 165892 has been marked as a duplicate of this bug. ***
(In reply to Patrick (volunteer) from comment #35) > In my previous commit, the new EnableNativeFullScreenWindows expert > preference did not change the behavior of windows that are open when that > preference is changed. So I committed a new patch today that updates the > full screen mode behavior of the green button in each window's titlebar > depending on the setting for the new EnableNativeFullScreenWindows expert > preference. > > The new expert preference should be in tomorrow's (25 March 2025) nightly > master builds: > > https://dev-builds.libreoffice.org/daily/master/current.html > > Note for macOS testers: the nightly master build installer does not > overwrite any LibreOffice official versions. Instead, it will be installed > as a separate application called "LibreOfficeDev" in the /Applications > folder. > > Because this is a "test" build, you will need to do the following steps > before you launch the LibreOfficeDev application: > > 1. Go to the Finder and navigate to the /Applications/Utilities folder > 2. Launch the "Terminal" application > 3. Paste the following command in the Terminal application window and press > the Return key to execute the command: > > xattr -d com.apple.quarantine /Applications/LibreOfficeDev.app I tested the nightly build from today (25 March 2025). I can confirm that native full screen mode seems to working as expected. Not sure if its relatable or not, but changing window size e.g. double click on border to resize / restore to previous also seems more smooth than stable release. Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: eba768cb5588c8b3b30a530028b8ee0a67177b18 CPU threads: 8; OS: macOS 15.3.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_NO.UTF-8); UI: en-US Calc: threaded
Going back from native full screen mode does seem to have the incorrect animation. I see that Rachel also commented on this earlier in the thread.