-
Notifications
You must be signed in to change notification settings - Fork 81
Conversation
@electron/maintainers Looking for reviewers for this. Thanks |
63f9a0f
to
9407556
Compare
@@ -35,6 +36,11 @@ bool SaveIconToPath(const SkBitmap& bitmap, const base::FilePath& path) { | |||
|
|||
// static | |||
NotificationPresenter* NotificationPresenter::Create() { | |||
auto version = base::win::GetVersion(); | |||
if (version < base::win::VERSION_WIN7) |
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.
Chrome 50 dropped support for Vista so this check isn't strictly needed.
DesktopNotificationController* controller = nullptr; | ||
|
||
std::wstring caption; | ||
std::wstring bodyText; |
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 use snake_case
elsewhere in the codebase. Could snake_case
for locals and struct members and snake_case_
for class members?
🙇 Thank you so much for this mountain of work. Tons of people will be very happy - I'll try to take a quick look on Monday. |
Does the code under |
No, it's 100% new code. That part under the subdirectory is functionally independent, that's maybe why it looks like a separate library - it's structured that way. |
This looks 👏 really good. As discussed in person, I'm so very happy we have this PR. Thank you so much! I have only three requests: 1️⃣ As mentioned by @poiru, snake_case would be a good change. Both 2 and 3 could easily be another PR in the future. EDIT: Talked to @kevinsawicki, let's get this in - we can go off-standard on |
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.
snake_case
, otherwise 👍 💯
I will post an update with snake casing later. I also have a fix for a small DPI related bug that I discovered, but I still need to test it in a multi-monitor setup. We should think more about the right approach for explicitly selecting the type of notification from the calling code. First thing that comes to mind is consistency across non-Windows OSes. But I do support the general idea. The color is now derived from the one which the user has selected for windows in the Control Panel. I see some value in being able to change it (e.g. to add category classification). Still, we should give it a bit more thought to make sure the feature doesn't make the user's desktop a playground for every app developer's creativity. Which brings me to an issue which should be addressed as well at some point - this currently doesn't consider a scenario where multiple Electron apps generate notifications at the same time. Right now these would simply overlap each other. |
#285 has been merged which enables |
browser/notification_presenter.cc
Outdated
@@ -18,7 +18,8 @@ NotificationPresenter::~NotificationPresenter() { | |||
|
|||
base::WeakPtr<Notification> NotificationPresenter::CreateNotification( | |||
NotificationDelegate* delegate) { | |||
Notification* notification = Notification::Create(delegate, this); | |||
Notification* notification = CreateNotificationObject(delegate); | |||
if (!notification) return {}; |
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.
notification
can't be nullptr
here, failed new
would throw std::bad_alloc
.
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're not calling new
here and CreateNotificationObject
could return null depending on the implementation, so it's safer to check for it. Alternatively (if we say the return value must not be null) there should at least be an assertion check.
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.
Current design is, if a platform does not have a implementation then we do not create a NotificationPresenter
at all (i.e. returning null in GetNotificationPresenter
), and if an error happens when creating the native notification, NotificationFailed
would be called.
So CreateNotificationObject
is guaranteed to return a Notification
object with new
, and doing assertion would be unnecessary since failed new
would simply crash.
Any progress on this @alespergl 🤗 |
…er` so that we can create different types of notifications based on runtime conditions.
…ace/line_length] [2]"
…ild/include] [4]"
…ould be: toast.h, c system, c++ system, other. [build/include_order] [4]"
…ng-declarations instead. [build/namespaces] [5]"
…evious line [whitespace/braces] [4]"
…>(...) instead [readability/casting] [4]"
…preceding } [whitespace/newline] [4]"
…ace brightray" [readability/namespace] [5]"
…ss NotificationPresenterWin7 [whitespace/indent] [3]"
…ing in the class [readability/constructors] [3]"
…omments [whitespace/comments] [2]"
… be marked explicit. [runtime/explicit] [5]"
…whitespace/blank_line] [3]"
9407556
to
8dc68da
Compare
Thanks! |
Hello @alespergl, Could this part of code ported to a single module that can be used in C#? I'm working on another project in windows forms, which needs to send a notification on windows 7. And I found your solution is the greatest one. It is very appreciated that if you could you help to give me some guides/tips to do that. |
This is the implementation of desktop notifications for Windows 7.
Resolves electron #8384