-
Notifications
You must be signed in to change notification settings - Fork 806
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add call notification dialog. #4426
Conversation
Mockup also posted in the issue at #4159 (comment) |
1329abd
to
b77d7af
Compare
3576e51
to
5e99f74
Compare
A couple of updates about my changes:
Now matches designs in #4159 |
214688a
to
7da8baf
Compare
062a65a
to
45da741
Compare
Remaining tasks:
|
Looking good @claucambra! :) Btw quick question about group call notifications:
|
Call notification dialog now shows up in the corners, rather than in the same position as the tray. The exact corner depends on the position of the taskbar and the position of the system tray icon. The notification will stick close to the taskbar and then decide on the exact position depending on which extreme of the task bar the system tray icon is in. I.e.: the task bar is at the top so the notification window will show at the top. But if the system tray icon is left of centre in the taskbar it will show up on the top-left corner, while if the system tray icon is right of center it will show up on the top-right corner.
The talk icon is now white in dark mode. The width of the tray window borders has also been fixed on macOS. Latest screenshot: |
f6c9d6b
to
833a4ff
Compare
Hi @claucambra to make screenshots I was testing a bit. It is a bit unreliable - first, I see calls twice in the menu: And the call screen popup is very unreliable - sometimes it shows, but now I couldn't get it to show up anymore... I use tech-preview.nextcloud.com with user leon green calling user christine and using the desktop client from the build by the bot, 11 hours ago - Nextcloud-PR-4426-833a4ffd774269893a342ac7d765777ff1e8e0a8-x86_64.AppImage You can reproduce that setup with the tech preview login details in our cloud, if you don't have them ping me. Edit: let me add that WHEN it shows up, the call screen looks very nice. I still had to resize it a little on my desktop, but that might be due to the font dpi settings - it seems Qt gets confused by anything not 96 DPI. edit2: forgot to add debug archive: https://cloud.nextcloud.com/s/i5QYwXfKSJBCxRc |
Hi @jospoortvliet, I would say the duplicated entries in the menu are out of scope of this PR, though obviously they are a problem. It is unclear where the issue is stemming from, we will need to investigate the code for fetching/parsing notification data and/or see if this is also an issue on the server side. The client will also only provide the popup once per call, so if this is the same call then there will be no popup (i.e. the same ongoing call, if everyone leaves the call and a new group call starts then the notification will show). Additionally, the notification window will also only show if the notification received from the server is less that 2 minutes old. This is to prevent users from being over-notified by calls. Lastly, depending on if push notifications are configured the call notifications should be near-immediate, but if push notifications are not configured on the server it may take around 60 seconds for the call notification to show as this is how often we poll the server for new notifications. Any more than that and we risk dynamiting the server. I don't have the details for the tech preview server, would be useful to have them :) |
src/libsync/configfile.cpp
Outdated
@@ -557,7 +557,7 @@ chrono::milliseconds ConfigFile::notificationRefreshInterval(const QString &conn | |||
QSettings settings(configFile(), QSettings::IniFormat); | |||
settings.beginGroup(con); | |||
|
|||
auto defaultInterval = chrono::minutes(5); | |||
auto defaultInterval = chrono::minutes(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@claucambra @mgallien I am not sure we need to change this for every user. Won't we end up creating a high load on the server in case of thousands of clients refresh notifications every minute? AFAIK, push notifications will almost always be available, so, we can assume the interval of 5 minutes is fine for the rest of the cases, but, if not, a user can change it directly in the custom config.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, this is true... on the flip side, though, the only connected server I have on my client that supports push notifications is our work instance, and in those conditions this means if we leave it at 5 minutes the likelihood of the call notifications being received in a timely way by the client get really close to 0 :/
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am no expert here, but did we not set the default to 5 min only for cases there is a push server? Did we change it for all desktop clients? Can we not set it to 30 seconds without the HPB and 5 minutes with the HPB?
If you then have load issues from the clients, use the HPB.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @jospoortvliet
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jospoortvliet @mgallien At least in the user model, which handles notifications, this is not the case -- when push notifications are connected to the server, the polling is stopped altogether and notifications are fetched solely through the push notification method. If the connection is lost or the push notifications are no longer available, the polling is re-initiated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Relevant code:
desktop/src/gui/tray/usermodel.cpp
Line 152 in 14220e4
// as we are now able to use push notifications - let's stop the polling timer |
@claucambra Approved. But, please check my comment. |
@jospoortvliet, @claucambra |
Thanks!!! |
I wonder if this could be possible to disable (even if this would be a secret config flag for now) as it would otherwise collide at some point with my small personal project https://github.com/CarlSchwan/talk-desktop and getting two notifications would a bit annoying |
src/gui/systray.cpp
Outdated
if (!useNormalWindow()) { | ||
window->setScreen(currentScreen()); | ||
const auto position = computeNotificationPosition(window->width(), window->height()); | ||
window->setPosition(position); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this doesn't work with wayland :( and on x doesn't follow the kde settings
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(X11)
Ok, so digging into the code, the problem is this: on Linux DEs Qt's QSystemTrayIcon::geometry() is completely broken, which means we have no way of getting the position of the tray icon or, by extension, the task bar.
For the main tray window this is ok with a workaround which checks the position of the cursor and uses this as the position for the tray to open -- the idea being you'll click on the icon, thus giving the position of the icon. This breaks when trying to use it for the call notification dialog as your cursor could be anywhere on the screen at the time of the call, and the call notification position is unpredictable.
Since we have no good way of finding the taskbar position (or size) on Linux, we have to either hardcode a position for the dialog or let the window manager decide where to place it (which will usually be in the center of the screen). Hardcoding it to a corner will risk breaking the convention of the desktop in question (KDE Plasma notifies wherever the taskbar is by default, usually at the bottom-right, whereas GNOME is top-right). @jancborchardt
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For Wayland I will do some more digging, though my hunch is that the positioning will just be handled by the window manager
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For now I have disabled the positioning code for the notification of the system tray icon geometry is invalid
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we have to either hardcode a position for the dialog or let the window manager decide where to place it (which will usually be in the center of the screen)
@claucambra If we have to decide between the 2, then I would say definitely hardcoding makes for a way better UX. If it’s KDE show on bottom right, and if it’s GNOME or anything else show on top right. Just use the default task bar height + some padding for vertical position, and some padding to the right side. Sure that can still lead to overlaps in super super edge cases, but we can fix those as they are reported. Way less bad than having a notification smack dab in the middle of the screen. :)
This is a bad idea in practice -- we do not know the size of the panels, the orientation of the panels, how DPI will affect positioning and padding of the notification, etc. A center position on the screen may not be ideal but, IMO, it is preferable to risking positioning that will be eating into people's panels or showing off-screen for users with a variety of display densities and DEs
I think the only viable solution here for notifications in corners on the Linux DEs is to default to a safe position like the center and then let the user customise the positioning through the application settings. Happy to hear if I have missed something here @mgallien @camilasan @CarlSchwan
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will this issue come up in a default installation of Ubuntu, or where would it happen?
I know hardcoding is not elegant, but putting this notification in the center is quite bad design. I'd say even if the notification is all the way in the top right / bottom right, eating into a panel, that's a better experience than in the very center.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wayland is now the default on GNOME (Ubuntu and Fedora) and KDE (Fedora). So in these cases the system tray and custom notification will be displayed on the middle of the screen.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On X11 GNOME environments, the notification will now be displayed on the top-right.
For Wayland environments, as well as other DEs, we still display in center
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, so as said it sounds bad that centering this would be the default experience, even if it's only Linux. Top right and bottom right would be much better, even if it overlaps something. Cause center overlaps everything always.
But cc @tobiasKaminsky on weighing the workload.
833a4ff
to
907c832
Compare
It should be relatively easy to implement a setting that disables this, I think some users would like this too |
907c832
to
056e379
Compare
I added a checkbox in the client's settings to disable the call notifications: |
src/libsync/configfile.cpp
Outdated
@@ -557,7 +557,7 @@ chrono::milliseconds ConfigFile::notificationRefreshInterval(const QString &conn | |||
QSettings settings(configFile(), QSettings::IniFormat); | |||
settings.beginGroup(con); | |||
|
|||
auto defaultInterval = chrono::minutes(5); | |||
auto defaultInterval = chrono::minutes(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with @jospoortvliet
@claucambra please also have a look at the so called Major issues reported by SonarCloud except for the id length they would be important to fix (and one is duplicating one of my comments) |
14220e4
to
3f8bc03
Compare
3f8bc03
to
e4aac83
Compare
e4aac83
to
666bc8d
Compare
Signed-off-by: Claudio Cambra <claudio.cambra@gmail.com> Co-authored-by: Camila <hello@camila.codes>
666bc8d
to
3f5243a
Compare
AppImage file: Nextcloud-PR-4426-3f5243aaee9994e7f310cf2689b6fd05ef89503f-x86_64.AppImage |
SonarCloud Quality Gate failed. |
Implements #4159
TO DO:
dismiss
) and open the browser (answer call
). It does seem we do too many request for activities which atm triggers way too many call notification popups when you open the client and when you open the systray window. On Android and server they only show the notification on a second request to the server - in our case not show it when we open the client - or when it is a push notification.user
insubjectRichParameters
- https://github.com/nextcloud/notifications/blob/master/docs/ocs-endpoint-v2.md#getting-the-notifications-of-a-user)Current status:
call-.5.mp4