Update systray behavior and context menu:
- left click brings up the new QtQuick based dialogs on all latforms
- right click brings up the new QtQuick based dialog on Mac OS only
- right click brings up a context menu on all other platforms than Mac OS
- "Quit Nextcloud" => "Exit Nextcloud"
- Add "Open main dialog" option.
Signed-off-by: Camila <hello@camila.codes>
Commit a12205f322 (PR #1891) introduced
a circular ownership: qmlRegisterSingletonType<Systray>(...) makes the
QQmlEngine own the resulting singleton Systray instance, however, the
QQmlEngine _trayEngine itself is owned by the Systray instance. This
circular ownership results in a crash when the destructor of Systray
calls the destructor of _trayEngine which attempts to call the destructor
of Systray.
This commit solves this problem by making ownCloudGui, which is the
parent of Systray, the parent of the _trayEngine.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Previously we were showing up the settings dialog but it doesn't quite
make sense anymore now that we got two dialogs.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Note this won't work on all platforms. KDE Plasma and GNOME Shell (with
systray extension) assume that right click is necessarily for a context
menu exposed via D-Bus, there's not nice way to make the right click
popup the main dialog on those platforms.
Signed-off-by: Kevin Ottens <kevin.ottens@nextcloud.com>
Make the codebase consistent, we already have a lot of implicit pointer comparisons.
Exception: Stay explicit on return's, example:
return _db != nullptr;
Signed-off-by: Michael Schuster <michael@schuster.ms>
- Add a new class AccountApp to keep them in an AccountAppList
and also save properties like ID and Icon URL.
- Clear the app list upon re-fetch to avoid endlessly growing lists
like in the previous implementation in ownCloudGui.
Signed-off-by: Michael Schuster <michael@schuster.ms>
Signal the SettingsDialog's window activation event down to ownCloudGui and Application,
so that other classes can hook in to get notified when the SettingsDialog is being shown
again.
This approach has been chosen because we otherwise would have to deal with new instance
pointers of the current SettingsWindow - but Application is already there ;-)
Purpose: The floating re-auth windows of the WebFlowCredentialsDialog often get hidden
behind the SettingsDialog, and the users have to minimize a lot of other windows to find
them again. This commit implements the preparation for the upcoming fix commit.
Signed-off-by: Michael Schuster <michael@schuster.ms>
Reverts back to the SettingsDialog class because of bugs and glitches with
more recent Qt versions (Qt 5.12) and with the macOS Dark Mode.
See upstream: https://github.com/owncloud/client/pull/7492
Signed-off-by: Michael Schuster <michael@schuster.ms>
Instead of adding the "Apps" menu after the apps are fetched, add it
from the start (together with other actions) but in a disabled state,
and enable it after the apps data is ready.
Signed-off-by: Sergey Zolotarev <sryze@protonmail.com>
* Disentangle the previous 'qdbusWorkarounds' into three different
things
* Make not trusting tray.isVisible() a new workaround
* Introduce env vars for all workaround flags
* Use the workaround flags for OSX
* Determine workaround flags for KDE when the plasma integration plugin
is missing
- It checks for the menu title to know where to add the apps menu instead of trying to cast
the menu pointer saved in the sender() property.
- The previous solution was not working reliably - see #523
- Adds TODO.
Signed-off-by: Camila San <hello@camila.codes>
- The crash was happening when the user could not connect and it would
crash on trying to retrieve and display the navigation apps.
- Checks AccountStatePtr earlier in the function
slotNavigationAppsFetched.
- Cast of pointer stored in QVariant to QMenu was not done correctly -
qvariant_cast works best for user type defined or QMetaType known to
QVariant.
Signed-off-by: Camila San <hello@camila.codes>
* The new menu option will fetch shares and create a new link share if
no "context menu share" currently exists.
* Various cleanup of common operations in socketapi happened as well,
in particular there's now FileData::get() that calculates all the
relevant paths that are useful for most socketapi actions.
