Allow Maximizing Settings Window

[elsiehupp]

Fixes #700.

I haven't tested this on Windows or Linux, but the main problem I'm facing is on macOS. What I've done so far is:

1. I added the flag Qt::Window to settingsdialogue.cpp, which allowed the window to be maximized.
2. When maximized, the settings window could not show its titlebar because it didn't have a menubar, so it couldn't be un-maximized. To fix this:
   a. I removed LSUIElement = True from Info.plist
   b. I converted the existing toolbar to a toolbar (rather than a menubar)
   c. I added an empty menubar (which macOS could use to push the titlebar back on screen and allow the window to un-maximized).

This left Nextcloud Desktop with a dock icon when it is running. To get rid of it I tried adding the following to cocoainitializer_mac.mm:

[NSApplication sharedApplication].activationPolicy = NSApplicationActivationPolicyAccessory;

It didn't crash the application or anything, but neither did it have any effect. (Apparently setting activationPolicy is more or less equivalent to setting LSUIElement or LSBackgroundOnly.)

It seems like what needs to happen to make the dock icon hidden would be to dynamically switch the application between being a Status Bar icon (no menubar or dock icon) and being a foreground application (both menubar and dock icon) when the settings window is open or closed, which involves something along the lines of the following:

// when initially launching the application and when closing the settings window
ProcessSerialNumber psn = { 0, kCurrentProcess };
TransformProcessType(&psn, kProcessTransformToUIElementApplication);

// when opening the settings window
ProcessSerialNumber psn = { 0, kCurrentProcess };
TransformProcessType(&psn, kProcessTransformToForegroundApplication);

The issue here is that settingsdialog.cpp is cross-platform and also C++ rather than Objective-C, so I wasn't able to add the AppKit import at the top, and I imagine doing so might present issues when building the application for Windows or Linux.

Does anybody know what would be a safe and feasible way of adding this code to the settings window? Thanks!

[elsiehupp]

I'm provisionally not marking this as a draft because I don't know if doing so hides it from the main least, and my reason for posting it is that I do, in fact, need help figuring this out.

[FlexW]

It seems like the settings dialog is inherited from a QDialog. From the documentation:

A dialog window is a top-level window mostly used for short-term tasks and brief communications with the user. QDialogs may be modal or modeless. QDialogs can provide a return value, and they can have default buttons. QDialogs can also have a QSizeGrip in their lower-right corner, using setSizeGripEnabled().

I've read through the issue and it seems like the people want the settings dialog to behave like a normal window. If this is really needed why not convert the settings dialog to a proper window? I guess a lot of the problems are then gone but maybe there was a good reason that it is just a dialog.

I would say this also involves some design questions so input from @jancborchardt would be valuable.

@er-vin @camilasan @allexzander What do you think about this?

[elsiehupp]

@FlexW why not convert the settings dialog to a proper window?

Adding the Qt::Window flag (the first change I made) does precisely this. The only perceptible change on macOS after doing so is that the settings dialogue can be maximized. Everything else is dealing with other peculiarities (not being able to un-maximize on macOS without a menubar) and external consequences (the change allowing un-maximizing the window causing there to be a dock icon).

Again, the current place I'm at is that as far as I can tell the I've basically fixed the titular issue in #700; I just need help figuring out how to make the dock icon go away when the settings dialogue is inactive. (There needs to be a dock icon when the settings dialogue is active in order for there to be a default macOS menubar, which is necessary for the window to be able to be un-maximized.)

I haven't built these changes on Linux or Windows, but I can't imagine them breaking anything. Worst case scenario, there might be an empty menubar, though Qt might be clever and hide it on Linux and Windows (whereas in macOS it just has the default menu with the name of the application).

FWIW it might not be the end of the world to have, like, other (fully redundant) menubar menus, at least on macOS (where they are generally expected) but obviously that's beyond the scope of fixing #700. (GNOME and Windows both seem to be trying to phase menubars out, but I can't speak to KDE or any of the other shells.)

[elsiehupp]

As you can see in these two screenshots, the settings dialog takes up basically the entire screen on my MacBook:

Being able to maximize the window on macOS would allow me to give it its own "workspace" and better integrate with the macOS window manager. (I use mostly full-screen windows on my MacBook.)

The main case for maximizing the window (and setting it aside in its own workspace) is when there's a long sync going on, and I'd like to be able to Cmd-Tab or three-finger-swipe over to it to check on the progress from time to time.

Without being able to maximize the window, yes, I can assign it to a second desktop, but it looks stupid filling the screen without actually being able to maximize.

(Also note that the interface is squished when the window is zoomed—using the zoom button, which is the alternative to the maximize button—to less than a certain height. This is a Qt problem, as I ran into it with the Qt installer window, as well. It's also beyond the scope here, though, too.)

[elsiehupp]

It works! I was able to add code (wrapped in if (OCC::Utility::isMac()) {}) that dynamically enables and disables the menubar and dock icon when the settings window is opened or closed. (This code could easily be added to other maximizable windows, like the first-run wizard; see: #2969.)

[elsiehupp]

FYI, this is working perfectly for me on macOS, but while I was able to resolve any overt build issues on Linux, the build didn't actually seem to work. I'm not sure if it's just me, though, or something with my code, since this was the first time I had tested a Linux build.

[elsiehupp]

Current status:

• The build was failing because the CI doesn't recognize the LINUX flag.
• A Linux-specific foreground-background implementation was unnecessary because the dock icon comes automatically with the Qt::Window flag.
• It still isn't showing the "maximize" button on Linux, for whatever reason, though.
• I have no idea how this behaves on Windows because I don't have a working copy of Windows at the moment.

To Do:

• Use Events instead of direct invocation
• Build and test on Windows
• Implement Windows taskbar button if necessary
• Maybe figure out why it's not able to be maximized on Linux

[elsiehupp]

It turns out I was running the Flatpak version of Nextcloud Desktop on my Linux computer. When I ran the build I was actually working on, it was able to maximize. (Somewhat strangely, it didn't respect the dark-mode skin, though.)

Next up, I guess, is setting up a Windows VM.

Also I'm not sure the best way to handle the overlap between this pull request and #2974.

[allexzander]

Also I'm not sure the best way to handle the overlap between this pull request and #2974.

@elsiehupp

As soon as you have merged the current one, you're going to need to manually resolve conflicts between the master and the other PR. Just removing those classes you've added here from that other branch, and then reusing the ones from the current branch. I see no other way.

[er-vin]

It's overall going in a better direction now (although I still need things which need changing but let's deal with the broad strokes first then move on to more detailed points). Still I'm wondering something, don't you need this foreground/background mechanism for every type of dialogs? I'm thinking of the share dialog for instance.

[elsiehupp]

Still I'm wondering something, don't you need this foreground/background mechanism for every type of dialogs? I'm thinking of the share dialog for instance.

Yes, it would make sense for Nextcloud Desktop to show a Dock icon whenever there is any sort of window on screen that doesn't disappear when it loses focus. I could change the scope of this pull request and fold in the foreground/background logic of other windowlets here, since the foreground/background logic is really the bulk of the changes here. The only remaining change to settingsdialog.cpp at this point is Qt::Window flag, and adding it without adding the foreground/background logic creates the problem of not being able to unmaximize. Granted, this problem already exists for the wizard; it's just no one seemed to have noticed it before I went in to try and implement the ability to quit.

[er-vin]

Looks good to me. Just need to cleanup history in the branch now.

[elsiehupp]

This should be ready to merge, except that it suffers from the problem of not being easily able to exit fullscreen on macOS. The fix for this is #3014, so essentially we should wait for that to get merged first. (I'll try and get it done soon.)

[nextcloud-desktop-bot]

AppImage file: Nextcloud-PR-2959-068ca4108fe777dd227689d4871f3361f8a930fb-x86_64.AppImage

To test this change/fix you can simply download above AppImage file and test it.

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

[Rello]

Hello @elsiehupp
are you still being able to support here? the clients were moved to QT6 and it would be interesting if this is still possible here

[Rello]

Hello,

Thank you for your contribution to the Desktop Client with this pull request.
We are closing this request as it is outdated, no longer relevant (e.g., due to Qt 6), or does not align with the current roadmap.

We truly value your support and hope to see more contributions from you in the future!

Best regards,
Nextcloud Desktop Team