feat: tray redesign

[camilasan]

Resolves

Implements #9902

Summary

TODO

• macOS - Objective-C
  
  
• Linux - QML
  
  
• Windows - QML
  
  
• add second account
• add screenshot without mouse over
• change "App settings" to "Settings"
• add screenshot in light mode
• ping Designers in PR
• compare Objective-C to QML for other platforms
• add "Add account" action

Checklist

• Sign-off message is added to all commits.
• The commit history is clean with no merge commits.
  • How to rebase your commits
  • How to squash commits with rebase
• Uploaded screenshots from before and after for UI changes.
• Documentation has been updated or is not required.
• Backports requested where applicable (critical bugfixes).
• Labels added where applicable (bug/enhancement).
• Milestone added for target version.

AI (if applicable)

• The content of this PR was partly or fully generated using AI

[Rello]

@kra-mo Are we supposed to add the "Add account" to the tray window even so its not in the mock-up or should this go somewhere else?

[kra-mo]

@kra-mo Are we supposed to add the "Add account" to the tray window even so its not in the mock-up or should this go somewhere else?

Since it's not that common of an action, it's fine either way, but I suppose why not since we want to move everything here eventually :)

[jancborchardt]

@kra-mo Are we supposed to add the "Add account" to the tray window even so its not in the mock-up or should this go somewhere else?

@Rello @kra-mo also, we probably should have it in there anyway in case people accidentally or for whatever reason close the first run dialog and have no account configured.

Then it makes more sense to have "Add account" as the only item in that list rather than it being empty and knowing you need to go to "Settings".

[kra-mo]

Looks pretty good generally from the screenshot :)

two pieces of feedback:

• The margins between the two menu items (Settings and Quit) is quite large. It should be as big as on the top/bottom.
• The status icons on the Mac version should have a white foreground instead of transparent, like in the Qt version, so that they are always visible, even if the background is green for example.

[jancborchardt]

Since now "Add account" moves down one order of magnitude, we need to include it on this new screen. We should have an entry "Add account" between "Settings" and "Quit" which launches the account wizard.

[Rello]

macos

[i2h3]

macos

I would leave out "Add account" as well because it is rarely relevant and only clutters the user interface. Most users likely set up their single account and they are good. Power users, administrators or whoever uses multiple at once probably are the minority and might survive clicking "Settings" first to add an account there. And even people are constantly setting up accounts (like me in daily development workflow), they also can use the CLI for that.

[kra-mo]

We can think about how to organize it later, I think for now, having it mirror the menu in the main popover makes sense.

I do see your point. This is something to think about when we expand this one. (And eventually remove the menu from the main dialog as well.)

[Rello]

Settings are being re-done as part of #10031
so I would suggest that we move the "Add Account" there right away because we are touching it anyway.
OK to remove here again?

[github-actions]

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

Digest: sha256:b0b6a6805e626e45b9bfaded9d866596deb0636f9b04cdf1927bce02419706b0

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.

[sonarqubecloud]

Quality Gate failed

Failed conditions
1 Security Hotspot
0.0% Coverage on New Code (required ≥ 80%)
D Maintainability Rating on New Code (required ≥ A)
67 New Code Smells (required ≤ 0)

See analysis details on SonarQube Cloud

Catch issues before they fail your Quality Gate with our IDE extension SonarQube for IDE

[jancborchardt]

Approval based on the screenshot in #9977 (comment)
Where the "Add account" is present.

@i2h3 my concern is that there are several cases where "Add account" is needed:

• Accidental closing of the first run wizard
• Want to add a second account
• Removed the only account
• Want to add a second or third account MUCH later than you added the other one and forgot how it works

It's not bad to have multiple entry points, like here in the menu directly, as well as also in the settings dialog.

[Rello]

Ok. Will keep it. Thank you

• Accidental closing of the first run wizard
• Removed the only account

For the sake of completeness: the client does not start without an account. It will always force the account wizard in that case

[i2h3]

@i2h3 my concern is that there are several cases where "Add account" is needed:

• Accidental closing of the first run wizard
• Want to add a second account
• Removed the only account
• Want to add a second or third account MUCH later than you added the other one and forgot how it works

It's not bad to have multiple entry points, like here in the menu directly, as well as also in the settings dialog.

@jancborchardt I did not mean it is bad, under certain circumstances it likely is clutter.

It does not have to be present statically. In example, when no account is set up yet, it makes sense to keep the menu item around (implicitly includes the "Removed the only account" and "Accidental closing of the first run wizard" states). "Want to add a second or third account MUCH later than you added the other one and forgot how it works" is logically the same as "Want to add a second account" just with an arbitrarily larger time delay.

I brought that up to @Rello directly as well: this is an inconsistency I see in our user experience. We have central app settings but account management is not possible there but only buried in popup menus in the menu bar extra. The latter likely is the place with highest interaction rate of which account removal and addition probably is not part of for the vast majority of users, I assume.

Accidental closing of the first run wizard

Thank you for pointing this out. I have never noticed this. Keeping the app running despite no account being configured and the only relevant user interface (wizard) dismissed appears irrational and (at least on macOS) counterintuitive (background apps terminate when they serve no purpose or activity) and inefficient (resource consumption for idling).

@Rello @camilasan @nilsding @mgallien Do you know why it is like that?

On a second thought, I would suggest to have this simple logic:

flowchart TD
    L[Launch app]
    L --> F{Any account configured?}
    F -- Yes --> M[Present menu bar extra]
    F -- No --> W[Present wizard]
    W --> N{Account configuration completed?}
    N -- Yes --> M
    N -- No --> T{Quit app}
    M -- Account removal -->W

Loading

Given that logic and the additional account configuration trigger in the central app settings there is no state management necessary and the item can be omitted completely.

[Rello]

@Rello @camilasan @nilsding @mgallien Do you know why it is like that?.

See my answer above. It is not.