Allow Maximizing Settings Window

[elsiehupp]

I accidentally messed up #2959. Fixes #700.

[elsiehupp]

I'm leaving this tab open to make sure I see any responses.

It looks like I need to change the commit message? It's been so long since I opened a pull request here that I have no idea what's involved anymore.

[Rello]

Hello,
what is the problem here that needs to be solved?
Am I missing something? on macOS, I can maximise the settings.
The reason is questionable because of the move to VFS of all sync clients out there - but still. its working for me.
Is it any different for you?

[elsiehupp]

On macOS, I can maximise the settings.

You can "zoom" the window—expanding it to fill the screen—but you can't have the window enter full screen. Having the window enter full screen means that it gets its own dedicated space in the macOS desktop manager.

Note the "+" when you mouse over the green button:

By contrast, here's the corner of a Finder window (with the mouse over to show the button icons):

I haven't checked the behavior of the application on Linux in a while or on Windows ever, but IIRC on some Linux desktop environments at least there isn't a distinction between expanding the window to fill the screen and having the window enter full screen.

I also just realized, another quirk of the settings window being a quasi-dialog rather than a proper window is that it can't be minimized, at least on macOS. If you look at the first screenshot again, you can see that the yellow button is grayed out, whereas in the second screenshot the yellow button is available.

Also sometimes you get weird behavior like this, where the non-window window accidentally invades the space of a full screen app. This literally happened just now:

If you look at the Qt documentation for flags Qt::WindowFlags, Qt::Window is described as:

Qt::Window Indicates that the widget is a window, usually with a window system frame and a title bar, irrespective of whether the widget has a parent or not. Note that it is not possible to unset this flag if the widget does not have a parent.

By contrast, Qt::Dialog is described as:

Qt::Dialog Indicates that the widget is a window that should be decorated as a dialog (i.e., typically no maximize or minimize buttons in the title bar). This is the default type for QDialog. If you want to use it as a modal dialog, it should be launched from another window, or have a parent and used with the QWidget::windowModality property. If you make it modal, the dialog will prevent other top-level windows in the application from getting any input. We refer to a top-level window that has a parent as a secondary window.

Currently the Nextcloud Desktop settings window seems to default to being a weird non-modal Qt::Dialog. The settings window being a Qt::Dialog can be a problem specifically when running a large, long sync, where you want to keep an eye on the progress until it completes.

The settings window being a Qt::Dialog means that the settings window sort of awkwardly floats in the macOS desktop environment, lacking the conveniences of being able to be minimized or made full screen, which one expects of a window that remains open for an extended period of time.

By contrast, one might think of the "Open...", "Save", "Save As..." or "Print" dialogs, which, as the Qt::Dialog describes, are launched from another window. The Global Ignore Settings sheet that launches from the General Settings tab in the settings window is more akin to this, whereas the settings window itself can be expected to persist in the background for an extended period of time as needed.

Adding the Qt::Window flag would not create any problems on macOS, and I expect that it would not create any problems on Linux or Windows, either. Adding the Qt::Window flag only adds functionality and does not remove any functionality.

The settings window as it currently exists is a weird quasi-dialog that can be expected to persist for extended periods of time in the desktop environment as needed, but because it is not a proper window it lacks basic functionality that one expects of windows that can be left open for extended periods of time in the desktop environment, and this lack of basic functionality has been an annoyance for me for literally five years now.

Adding this one flag in this one place would fix that annoyance. If I remember correctly from back in 2021, the only reason the Qt::Window flag could not be added earlier is that doing so without the foreground-background switching in #3014 would have allowed anomalous behavior where the window could enter full screen but would lack the foreground menubar and therefore would not be able to exit fullscreen using the red or green window buttons as usual.

I discussed this all in #2959 back in 2021. IIRC #3014 was originally part of #2959, but I separated it into two pull requests at the request of the reviewers in order to make the pull requests easier to review. I do not know why @claucambra merged #3014 in 2024 and not #2959, because, as I mentioned earlier, by that point I had completely peaced out.

I feel like I am just rambling with my summary of past comments at this point...

[elsiehupp]

Fixed the block unconventional commits error!

[elsiehupp]

Looking further at the documentation, it appears that the following flags could achieve the same effect, at least on macOS:

Qt::WindowFullscreenButtonHint On macOS adds a fullscreen button.

Qt::WindowMinimizeButtonHint Adds a minimize button. On some platforms this implies Qt::WindowSystemMenuHint for it to work.

Simply using the Qt::Window flag defers behaviors to platform norms, though, rather than over-specifying just for macOS. (IIRC platform-specific quirks are not preferred by the Nextcloud maintainers.)

[mgallien]

@elsiehupp might be fine as is

[elsiehupp]

@elsiehupp might be fine as is

@mgallien Thanks! I guess we're just waiting on the code owners now? 😬

[github-actions]

Artifact containing the AppImage: nextcloud-appimage-pr-8834.zip

Digest: sha256:5301cc5ffa9793eaa213751e8747273a053fa9b8c173ff2633e8c1ee659163b7

To test this change/fix you can download the above artifact file, unzip it, and run it.

Please make sure to quit your existing Nextcloud app and backup your data.

[Rello]

/backport to stable-4.0

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)