Don't raise settings window when the client is invoced a second time without "--show-settings" (depends on #8377)

[pulkin]

... while there is no reason for it to behave like that. I remember this consistently happening across versions and distros for 4 years or so. I am mostly using Gnome.

[dragotin]

Same on KDE Plasma with version 2.7.6

[gabi18]

I see the 'Syn Activity Notifications' popping up after autostart of the client (openSUSE Leap 15.2, KDE Plasma 5.18.6, client version 2.7.6).

Is that meant here?

[pulkin]

I see a full-blown window with buttons and account lists each time I start my machines.

[gabi18]

I cannot confirm this on my openSUSE 15.2 system.

Do you use Ubuntu 20.04?

[pulkin]

Currently Fedora 33 and 34.

[TheOneRing]

Might be multiple invocations caused by auto start and session restore.
https://github.com/owncloud/client/blob/master/src/gui/application.cpp#L554

[pulkin]

I vaguely remember a discussion about window popping up in case owncloud is invoked multiple times after login. But I was never able to confirm it. Currently, removing the autostart checkbox in the client will make the client not start up automatically, as expected.

[jnweiger]

Tested on Ubuntu 20.10 with gnome 3.38.1, autostart includes the ownCloud desktop client, I cannot confirm either:

On a reboot, the desktop client comes up, but only the small tray icon. The full blown settings window is not shown unless I click the icon, or trigger the client manually.
Tested with both ownCloud client 2.7.1 and 2.8.0RC1

[jnweiger]

On a Fedora 33 with gnome 3.38.5, I have ownCloud client 2.7.2 in autostart. I can confirm the issue:
Upon logout/login, or reboot/login the client opens its settings window.

Same with 2.8.0RC1

[TheOneRing]

I guess ubuntu != gnome

[jnweiger]

I guess ubuntu != gnome

Both my Ubuntu 20.10 and my Fedora 33 run Gnome 3.38.x; Fedora has Wayland, Ubuntu has X11

[fmoc]

Can either of you please provide a screenshot for reference?

[fmoc]

Reproducible in a Fedora 34 VM with 2.7.6 (Fedora 33 package):

Just logged out and logged in again.

The issue is not limited to autostart, you can also just close the client and open it again. The main UI is always shown then. This makes sense, as the desktop entry in ~/.config/autostart also just calls /opt/ownCloud/ownCloud/bin/owncloud. It's almost like _showSettings was set to true. This makes little sense, as on 2.7 (like in master), its initial value is set to false, and is only overwritten if --showsettings is passed. Also, I am relatively sure the settings dialog isn't triggered via the socket API, as there's a 10 seconds period after the startup in which such requests are ignored.

Looking explicitly for calls to showSettingsDialog, I found the most likely issue: the system tray is not available on GNOME, and the existing filter only checks for Ubuntu, not Fedora. In this case, main force-shows the settings dialog. This same code still exists in master (which I have not tried yet).

client/src/gui/main.cpp

Lines 152 to 160 in 38ba32c

	if (QSystemTrayIcon::isSystemTrayAvailable()) {
	app.tryTrayAgain();
	} else if (desktopSession != "ubuntu") {
	qCInfo(lcApplication) << "System tray still not available, showing window and trying again later";
	app.showSettingsDialog();
	QTimer::singleShot(10000, &app, &Application::tryTrayAgain);
	} else {
	qCInfo(lcApplication) << "System tray still not available, but assuming it's fine on 'ubuntu' desktop";
	}

Related issues: #6518 #4693 #4747

Commits related to workaround:

• https://github.com/owncloud/client/blame/0da2adcbe02eb9499e90622ca60a726ba75d0188
• 3169833 (regression was likely introduced here)
• https://github.com/owncloud/client/blame/a2b817f0c0ec00ce7755092a2d562e5535940fbf
• 5639572
• 18a58f7 (filter originally introduced to work around missing system tray on Unity)

This issue has been around for many, many years already. I don't think adding additional filtering on distros/DEs is a good idea. We have to re-engineer the system tray handling. I am relatively sure the issue exists on all GNOME(-based) desktops, regardless of the distribution.

[TheOneRing]

Yes that sounds pretty reasonable.
As you can nowadays use the desktop entry actions or just reinvoke the client there is no reason to force show the window.

[github-actions]

This issue was marked stale because it has been open for 30 days with no activity. Remove the stale label or comment or this will be closed in 7 days.

[TheOneRing]

I think we should remove that behaviour once we implemented #8377