Allow maximizing client window

Expected behaviour

The Nextcloud client has become a complex application. It has tabs, sub-tabs, and even modal windows. I'd like to be able to maximized such a complex window. (Yes, I know I can manually drag the window bigger but that is not the same.)

Actual behaviour

Instead the window is a dialog which cannot be maximized nor minimized. Pretty annoying. Would it do any harm to allow maximizing it? Thanks!

Steps to reproduce

1. Open Nextcloud client
2. Try to maximize window

Client configuration

Client version: 2.3.3

[camilasan]

Hi, We have simplified quite a bit... could you try one of our daily builds (use with a test account):
https://download.nextcloud.com/desktop/daily/
Thanks.

It is still not possible to maximize the window, though. 😞

[hirkah]

Agree, this (and minimization) would be a good feature.

[elsiehupp]

I am synchronizing a large number of different Folder Connections on Nextcloud, and I've been leaving the "Settings" window open to monitor the progress. It would really be nice to be able to maximize and minimize this window, on both macOS and on Linux (Gnome), rather than having to use secondary desktops/workspaces.

Additionally, since the Account tabs in the Settings window show sync progress which is not visible anywhere else, is "Settings" really the best name for this window anymore? The mode paradigm of the desktop application is kind of confusing and feels like it could stand to be redesigned from the ground up...

Today I just noticed that the new popup (which came with version 3) is called "Main Dialog". That really made my day! Because I think it is funny to make people see a small popup with some summary data as main dialog! For me "Settings" still is the main window, as it tells me everything what is going on.

[elsiehupp]

I actually did some poking around with this a couple weeks ago. While it's possible to make the window maximizable, on macOS in particular there are a series of cascading side effects that I didn't get to the bottom of.

[elsiehupp]

I've had a pair of pull requests that fix this pending for like six months. The fact that the Settings window isn't a foreground window (and can't be maximized) creates all sorts of janky side effects. It makes sense for the popover (in its current form) not to be a foreground window, because it disappears when you click away from it, but it does not make sense for the Settings window to omit most of the functionality of the macOS window manager.

The main use case for me is doing a substantial sync where I would like to be able to regularly check in on the sync status. Clicking through the popover is not an option because the tray icon popover have a tendency to become unresponsive during substantial sync operations. Yes, this unresponsiveness is a separate issue, but allowing the Settings window to work properly with the window manager mitigates the problem because if you leave the Settings window open you can look at it even when the application is unresponsive.

If the Settings window is properly a foreground window, it will appear in Cmd-Tab and Mission Control. If the Settings window is not properly a foreground window, it will not appear in Cmd-Tab, so you will need to manually click over to it. (I can't really speak to other desktop environments at the moment, but IIRC on GNOME the Settings window already works correctly with Alt-Tab, so merging this change would bring feature parity to macOS.)

If the Settings window can be maximized, it will be able to be pinned to an exclusive desktop of its own, so you will be able to pan over to it with a three-finger swipe. If the Settings window cannot be maximized, you can still put it in its own desktop, but other windows can still appear in front of it, and Cmd-Tab will still not work unless the Settings window is properly a foreground window. (Maximizing the Settings window without making it a foreground window on macOS makes it hard to un-maximize the window because non-foreground windows don't have access to the menubar, so the top bar of the window—with the "stoplight" buttons—is inaccessible in full screen, all the more suggesting that a persistent window like the Settings window should be a foreground window.)

There are other design quirks that I personally think should be addressed (especially in the context of macOS), but merging my pull requests that fix this particular issue would make them less obtrusive on their own.

[elsiehupp]

Basically the way I think the "window status" of the Settings window and the popover should be addressed is that:

1. The Settings window and the popover should be combined back into a single window like they used to be; and
2. This combined window should behave like a transitory popover initially, with the option of "tearing off" or "pinning" the combined window and making it behave like a persistent window instead. The persistent window would be able to be turned back into a popover using an "unpin" button.
3. In desktop environments without a "system tray" (like GNOME or Elementary), the window could be a persistent window at all times, because a transitory popover doesn't really make sense absent the "system tray" icon. (And, indeed, IIRC, on Elementary—but not on GNOME—the popover behaves like a persistent window regardless, while still being separate from the Settings window for no good reason.)

The current behavior of the popover and the Settings window suggests that the @nextcloud/desktop maintainers generally don't actually use macOS (or GNOME or Elementary), and that these desktop environments are "second-class citizens" in the Nextcloud ecosystem.

My apologies, perhaps, for being particularly strident here. I had a lot more patience for this issue when I initially submitted my pull requests six months ago.

[mgallien]

Basically the way I think the "window status" of the Settings window and the popover should be addressed is that:

1. The Settings window and the popover should be combined back into a single window like they used to be; and

2. This combined window should behave like a transitory popover initially, with the option of "tearing off" or "pinning" the combined window and making it behave like a persistent window instead. The persistent window would be able to be turned back into a popover using an "unpin" button.

3. In desktop environments without a "system tray" (like GNOME or Elementary), the window could be a persistent window at all times, because a transitory popover doesn't really make sense absent the "system tray" icon. (And, indeed, IIRC, on Elementary—but not on GNOME—the popover behaves like a persistent window regardless, while still being separate from the Settings window for no good reason.)

The current behavior of the popover and the Settings window suggests that the @nextcloud/desktop maintainers generally don't actually use macOS (or GNOME or Elementary), and that these desktop environments are "second-class citizens" in the Nextcloud ecosystem.

The thing is that we want to improve every where the integration. We are more missing available time to push forward this subject.
Keep in mind that those part of the desktop client are heavily design related and we need to involve the designers in the loop before we work on code to ensure that what we do is compatible with the design.*

We did modify the design of the main dialog to make it easier to use with Gnome in response to the feedback we were getting.I have here to disagree with you.

My apologies, perhaps, for being particularly strident here. I had a lot more patience for this issue when I initially submitted my pull requests six months ago.

We have a lot of colleagues that make heavy usage of Mac. You are not alone and please if we had let you believe that is the case, this is a wrong feeling.