Skip to content
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

Implement notification layer backend and qml component for tray window #2220

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

DominiqueFuchs
Copy link
Contributor

@DominiqueFuchs DominiqueFuchs commented Jul 20, 2020

Base for #2217

Implements the backend part (QStringList as current list of notifications + signals / helper functions) + new QML component and Connection in Window.qml to show and dismiss notifications.

@jancborchardt Design here?

Code-review: Please roast. Regarding the QStringList: Wasn't sure about this. I decided for that way for now b/c

  1. Yeah I was glimpsing towards a more general container approach too, but then I thought KISS and not try to make this a working base for the future implementation of all notifications handled in the sync view (settings) right now. However, if we start to do that at some point, changing from the QStringList to a more sophisticated connection is still possible.
  2. I didn't implement a model/delegate system for this b/c I don't think it is the right case for that. We might have multiple notifications in the queue. but we always will only show one per time (at least I don't see a reason for showing multiple with the limited space we have here). If the most recent is dismissed, the next one will show up.

Also UX regarding point 2: Right now only the last notification (i.e.: The one added most recently) is show, it's a LIFO. Could be reversed, though?

traynotify

Copy link
Contributor

@nicolasfella nicolasfella left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code-review: Please roast

Done :-) If any of my comments is unclear please ask.

src/gui/systray.cpp Outdated Show resolved Hide resolved
@@ -0,0 +1,85 @@
import QtQuick 2.9
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this need a copyright header?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, please add a copyright notice with the matching license header

property alias text: notificationMessage.text
signal dismissNotification()

width: parent.width - Style.trayWindowBorderWidth*2
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I usually consider it bad style when QML components make assumptions about their size/placement. It makes it harder to reuse them. Therefore width/height/anchors should only be set from the outside. Given that this one is only used in one place it's probably not a big deal though

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Could you please clarify this? As I see it, I'm relying here on an external style property already (trayWindowBorderWidth) and only care about making it full-width of the tray window minus it's decoration border (whatever size it may be now or in the future). Guess I'm just don't getting it.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am with @nicolasfella here.
This sizing property should be set in the parent but not in the child. That makes it much easier to reuse and to maintain in the future. So move it to places where you use the Notification component.

src/gui/tray/Notification.qml Outdated Show resolved Hide resolved
src/gui/systray.h Outdated Show resolved Hide resolved
src/gui/systray.h Outdated Show resolved Hide resolved
src/gui/tray/Notification.qml Show resolved Hide resolved
src/gui/tray/Notification.qml Outdated Show resolved Hide resolved
@jancborchardt
Copy link
Member

Good stuff @DominiqueFuchs! Design-wise I'd say it's a bit better if the notification is part of the scrollable container of the activity list, but the first entry.

This is because all focus in that new tray is on the top – controls are there and the newest entries are there as well. So a notification on the bottom is likely to be missed.

@er-vin
Copy link
Member

er-vin commented Jul 21, 2020

Looks too big and intrusive so late in the 2.7 cycle, we're more slowly freezing to reach rc1. I'll move the milestone for 2.8.

@er-vin
Copy link
Member

er-vin commented Sep 16, 2020

/rebase

@er-vin
Copy link
Member

er-vin commented Sep 16, 2020

@DominiqueFuchs are you still planning to work on this? Now would be the right time to be on the 3.1 train.

@DominiqueFuchs
Copy link
Contributor Author

@DominiqueFuchs are you still planning to work on this? Now would be the right time to be on the 3.1 train.

I'd say you choose 🙃 I'll still limited time for this project within the next few weeks - without any external guidance I would have worked on bugs in the existing timeframes, but if this is something you are prioritizing I'll put it to the top.

@DominiqueFuchs
Copy link
Contributor Author

I revisited and changed code according to comments so far (thanks @nicolasfella), aside from the one where I asked for clarification.

Another thing is: I just noticed how misleading the "notification" naming is regarding the code. Actually, "notifications" are a different thing (real notifications based on OS mechanisms, the one we push out for things like update, sync errors, etc.). Thus, we have a "NotificationHandler" that has nothing to do with this in-tray notification just showing special information in the bottom line until dismissed. I think we should rename this "Notification.qml" and corresponding properties to not lead new contributors to think this would be correlated and keep the overall syntax clear. Sugestions?

@er-vin
Copy link
Member

er-vin commented Sep 17, 2020

@DominiqueFuchs are you still planning to work on this? Now would be the right time to be on the 3.1 train.

I'd say you choose 🙃 I'll still limited time for this project within the next few weeks - without any external guidance I would have worked on bugs in the existing timeframes, but if this is something you are prioritizing I'll put it to the top.

Don't want to put pressure on you, pushing it back by one release is fine. I'll do that.

@er-vin er-vin modified the milestones: Desktop 3.1, 4.0 🥚 Sep 17, 2020
@er-vin
Copy link
Member

er-vin commented Sep 17, 2020

Another thing is: I just noticed how misleading the "notification" naming is regarding the code. Actually, "notifications" are a different thing (real notifications based on OS mechanisms, the one we push out for things like update, sync errors, etc.). Thus, we have a "NotificationHandler" that has nothing to do with this in-tray notification just showing special information in the bottom line until dismissed. I think we should rename this "Notification.qml" and corresponding properties to not lead new contributors to think this would be correlated and keep the overall syntax clear. Sugestions?

This is a very good point... Random ideas on top of my head: ServerNotification? ServerMessage? Announcement? (that one could be confusing as well...) StickyActivity?

@nextcloud-desktop-bot
Copy link

AppImage file: Nextcloud-PR-2220-3a9a9db259bbd85c038360dedaae8f0f7e6ae131-x86_64.AppImage

To test this change/fix you can simply download above AppImage file and test it.

Please make sure to quit your existing Nextcloud app and backup your data.

@DominiqueFuchs
Copy link
Contributor Author

This is a very good point... Random ideas on top of my head: ServerNotification? ServerMessage? Announcement? (that one could be confusing as well...) StickyActivity?

They all could be misleading somehow (isn't a activity, but also hasn't necessarily to be coming from the server, too), even though I thought about similar ones initially..

Maybe we simply rename it to "Notice.qml" or "ClientNotice.qml" (and corresponding properties getLastNotice etc.). Depending on context the meaning of both words is mostly the same, but this is more or less the point here, they could at least clearly be distinguished and don't cross in search results?

@er-vin
Copy link
Member

er-vin commented Sep 17, 2020

I like the Notice naming. Good idea.

Copy link
Collaborator

@mgallien mgallien left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@DominiqueFuchs thanks and sorry for the delay. Do you still plan to work on that ?
there is ongoing work from @camilasan on this and you will need to rebase your on top of her work.
Please let us know if you need advice there

property alias text: notificationMessage.text
signal dismissNotification()

width: parent.width - Style.trayWindowBorderWidth*2
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am with @nicolasfella here.
This sizing property should be set in the parent but not in the child. That makes it much easier to reuse and to maintain in the future. So move it to places where you use the Notification component.

@@ -0,0 +1,85 @@
import QtQuick 2.9
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, please add a copyright notice with the matching license header

@mgallien mgallien removed this from the 4.0 🥚 milestone Sep 8, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants