It isn't possible to quit the first-launch wizard (on macOS)

[elsiehupp]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

Expected behaviour

If you open Nextcloud Desktop for the first time, you should be able to abort the first-launch wizard and in so doing quit the application

Actual behaviour

If you close the wizard window with the red "close window" button, the applications active. If you click the Status Bar icon (which is how you would usually approach the quit button), it just reopens the window.

Steps to reproduce

1. Delete or rename the Nextcloud Desktop preferences files in ~/Library
2. Launch Nextcloud Desktop
3. Try to quit without completing the wizard.

Client configuration

• Client version: 3.1.50git
• Operating system: macOS Big Sur 11.2.1
• OS language: English
• Installation path of client: /usr/local (test build)

Logs

Gist -> here.

[elsiehupp]

Incidentally, in the process of writing this Issue, I maximized the first-launch wizard and discovered that it can't be un-maximized, which suggests a potential overlap with Issue #700. Basically, if the first-launch wizard (like the settings window) were to have the default macOS toolbar and change mode from background to foreground and then back to background in order to show and hide the dock icon, the user would be able to use both the default application menu and the dock-icon context menu to quit the application from the wizard.

[elsiehupp]

FWIW, I don't know what sort of effect pull-request #2895 might have on this issue, but the approach of changing the application mode probably isn't part of the makeover.

[FlexW]

That's an 'issue' on all platforms not just on MacOS.

[elsiehupp]

One potential fix for this is to make it so that if you close the wizard window without completing it, the application quits. This could just be the OS-default "close window" button in the window's titlebar, or it could also be a "Quit" or "Cancel" button next to the "Next" button.

I could try and do the close-window fix myself, but I don't know how to add another button to the interface, since if I understand correctly this requires using Qt's interface designer, which I don't know how to use. That said, this could be a good opportunity for me to learn how to use it!

As a third potential fix, there could be a version of the popover that just has a "Quit" option in it if the setup process hasn't been completed. On certain versions of Linux, the tray menu isn't actually the popover but rather a native menu (akin to the macOS application menu), so this wouldn't be necessary on all platforms. (If the wizard itself includes a "Quit" or "Cancel" button, though, the current approach of the tray icon just foregrounding the wizard might be okay to keep.)

Enabling the dock icon and application menu on macOS (by using the functions I added in #2959 on the setup wizard, as well) could make the "Quit" popover unnecessary on macOS, as well. I don't know about Linux or Windows, but it could make sense to do something with foregrounding the application (i.e. showing it on the dock or taskbar) when a window is open, but I'm not immediately familiar with how to do this. (I was able to figure it out on macOS, though, so I could probably figure it out on Linux and/or Windows if I tried.)

Because #2959 would help in this situation, getting some traction on testing and merging that code would help get additional traction here.

[er-vin]

That's an 'issue' on all platforms not just on MacOS.

Well not completely... the other platforms shall have a context menu on the systray icon and you can quit from there. It's an unforeseen consequence of not having a context menu on mac... indeed on that platform you need something else to be able to quit.

Simplest path would be to allow the context menu on mac too (back then I wasn't too hot on not having it anyway), this way it'd be more consistent behavior wise with the other platforms... @jancborchardt any chance to get you to change your mind there? I mean even in support and documentation situation this is adding some strain. "Oh wait you're on mac? sorry you can't use that context menu described in the doc" (not that the documentation is super up to date but you get the idea :-))

[elsiehupp]

Having a right-click menu on the status-bar icon on macOS would be an even more non-standard behavior than the nearly unusable windowlet that the status-bar icon currently spawns. Nothing else in the menu bar on macOS has a right-click menu.

The fact of the matter is that different platforms have different user-interface norms, and trying to make a Mac application behave exactly like a Windows or KDE application will just make it grotesque. Having a window that can't be minimized and that doesn't hide when the parent application is not in the foreground is user-hostile behavior.

[er-vin]

Having a right-click menu on the status-bar icon on macOS would be an even more non-standard behavior than the nearly unusable windowlet that the status-bar icon currently spawns.

This is setting this conversation on an interesting footing...

Nothing else in the menu bar on macOS has a right-click menu.

Fair enough. Let's not go that route...

The fact of the matter is that different platforms have different user-interface norms, and trying to make a Mac application behave exactly like a Windows or KDE application will just make it grotesque. Having a window that can't be minimized and that doesn't hide when the parent application is not in the foreground is user-hostile behavior.

... especially if it's so infuriating.

In any case, even for other platforms it probably makes sense to quit the application when the wizard is rejected and no account was configured at all. So that's not a bad fix.

What I'm trying to highlight is a) this (obviously) is more work than having something consistent across platforms and b) the more platform specific behavior is introduced the more expensive things become during maintenance and support. They both need to be kept in mind for the decision making and that's a constant trade-off to strike between looking more "native" on a given platform and being more expensive (due to (a) and (b)).

[elsiehupp]

Having a right-click menu on the status-bar icon on macOS would be an even more non-standard behavior than the nearly unusable windowlet that the status-bar icon currently spawns.

This is setting this conversation on an interesting footing...

In all fairness, I mainly dislike the windowlet on my Ubuntu, since the AppIndicator button doesn't open it directly, and dealing with sync conflicts involves clicking on one of many identical list items, since the path and filename are cut off... But that's a different conversation. Fortunately I haven't had any sync conflicts on macOS for whatever reason.

[jancborchardt]

One potential fix for this is to make it so that if you close the wizard window without completing it, the application quits. This could just be the OS-default "close window" button in the window's titlebar, or it could also be a "Quit" or "Cancel" button next to the "Next" button.

Yeah, agree with @elsiehupp these would be the best solutions, we could even do both.

I would only put a "Cancel" button in the first step, on the left, where the "Previous" button then is in subsequent steps. Otherwise it’s too easy to accidentelly press "Cancel" if it’s right next to the "Next" button.

And yeah, about the context menu for the tray icon → that’s not a thing on macOS as was said, so not something we can do. Also this is not a place I would look to cancel the setup. I would expect it to simply cancel when the dialog is closed.

[er-vin]

One potential fix for this is to make it so that if you close the wizard window without completing it, the application quits. This could just be the OS-default "close window" button in the window's titlebar, or it could also be a "Quit" or "Cancel" button next to the "Next" button.

Yeah, agree with @elsiehupp these would be the best solutions, we could even do both.

I would only put a "Cancel" button in the first step, on the left, where the "Previous" button then is in subsequent steps. Otherwise it’s too easy to accidentelly press "Cancel" if it’s right next to the "Next" button.

Right, then in that case it's "just" about having it and handling it. Should issue a regular reject if there's already an account and just quit the application if there's no account.

[Rello]

The client has improved a lot since the ticket was opened.
If it is still relevant, please create a fresh ticket.
Thank you for your support