Skip to content
This repository has been archived by the owner on Apr 12, 2024. It is now read-only.

Windows 7 notifications #279

Merged
merged 20 commits into from
Apr 11, 2017
Merged

Windows 7 notifications #279

merged 20 commits into from
Apr 11, 2017

Conversation

alespergl
Copy link
Contributor

This is the implementation of desktop notifications for Windows 7.

Resolves electron #8384

@alespergl
Copy link
Contributor Author

@electron/maintainers Looking for reviewers for this. Thanks

@alespergl alespergl force-pushed the win7_notifications branch 3 times, most recently from 63f9a0f to 9407556 Compare March 16, 2017 16:24
@@ -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)
Copy link
Contributor

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;
Copy link
Contributor

@poiru poiru Mar 16, 2017

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?

@zcbenz zcbenz self-assigned this Mar 16, 2017
@felixrieseberg
Copy link
Contributor

🙇 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.

@zcbenz
Copy link
Contributor

zcbenz commented Mar 20, 2017

Does the code under browser/win/win32_desktop_notifications come from an existing library? It seems that the implementation is glueing an library instead of writing everything from scratch.

@alespergl
Copy link
Contributor Author

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.

@felixrieseberg
Copy link
Contributor

felixrieseberg commented Mar 23, 2017

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.
2️⃣ We frequently fail to send notifications using the native ToastNotifier in Windows 8, 8.1, and 10. I would love an option to use this notification object even from versions newer than Windows 7.
3️⃣ I'd love to be able to configure the background color.

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 Notification in a separate PR, allowing us to, for instance, pass type: 'fallback' (or something like that.

Copy link
Contributor

@felixrieseberg felixrieseberg left a comment

Choose a reason for hiding this comment

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

snake_case, otherwise 👍 💯

@alespergl
Copy link
Contributor Author

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.

@kevinsawicki
Copy link
Contributor

#285 has been merged which enables cpplint on CI builds so if you rebase/merge master it should pull in those changes.

@@ -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 {};
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

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.

@akashnimare
Copy link

Any progress on this @alespergl 🤗

alespergl added 13 commits April 5, 2017 14:30
…er` so that we can create different types of notifications based on runtime conditions.
…ould be: toast.h, c system, c++ system, other. [build/include_order] [4]"
…ng-declarations instead. [build/namespaces] [5]"
@alespergl alespergl force-pushed the win7_notifications branch from 9407556 to 8dc68da Compare April 5, 2017 12:33
@zcbenz
Copy link
Contributor

zcbenz commented Apr 11, 2017

Thanks!

@kafka-yu
Copy link

kafka-yu commented Nov 8, 2018

Hello @alespergl,
Thanks for the great work on this feature.

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.
Thank you very much!

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants