Allow maximizing client window

[LukeOwlclaw]

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.

[LukeOwlclaw]

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...

[LukeOwlclaw]

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.

[FlexW]

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.

You are aware that we implemented a logic that makes it possible that the main dialog gets shown as a normal window if no tray system is available?

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.

You opened a lot of pull requests (https://github.com/nextcloud/desktop/pulls/elsiehupp) besides we were asking you to only submit one at a time. For me, it's impossible to review all your pull requests. Reviewing code takes a lot of time and my time is constrained, and I only want to invest this time if I can see that it will lead to a result. For example, you mentioned a pull request that you opened six months ago. Which one is it? Is it this one #2959 that is marked as a draft? I would really recommend that you close all pull requests from you now or mark them as draft and then we try to review one pull request after another. If one got merged, we can take a look at the next one. Otherwise, it is just too much.

[elsiehupp]

we were asking you to only submit one at a time.

IIRC @er-vin specifically asked my to divide it up into multiple pull requests rather than just the one specifically in order to make them easier to review. See this comment. (I can’t find the original request because, again, it’s been eight months.)

The way the three pull requests are structured is as follows:

• Show/Hide Menubar and Dock Icon on macOS #3014 is a prerequisite because it allows maximized windows on macOS to be unmaximized. It also indirectly fixes It isn't possible to quit the first-launch wizard (on macOS) #2969. (Note that the initial-setup Wizard can already be maximized on macOS but cannot easily be unmaximized. There doesn’t appear to be a separate issue for this.)
• Allow Maximizing Settings Window #2959 allows the Settings window to be maximized (fixing Allow maximizing client window #700) and is marked as a draft because it indirectly depends on Show/Hide Menubar and Dock Icon on macOS #3014 (so that it can be unmaximized).
• Allow Quit from Initial Setup #2974 is actually a draft because it explores adding a more explicit Quit command to the initial-setup Wizard.

#3014 could easily be merged back into #2959, but, again, if I remember correctly I separated the two because @er-vin specifically asked me to.

The source of my frustration is that #2959 and #3014 were being actively reviewed by multiple people, and I made the changes requested by the reviewers, only to be met with eight months of silence. Basically I’m salty because I feel like one or more people (I honestly can’t remember who) abruptly ghosted me, and (to a lesser extent) because #700 does, in fact, affect me on a regular basis.

[FlexW]

@elsiehupp I messaged you in private.

[Rello]

Hello,
due to the recent merge to QT6 and and the ongoing enhancements for a more native integration, I close this ticket and we are following the individual subtickets