UI now in separate renderer:
- the permissions popup
- settings dialog
- debug log dialog
- about window
Couple bug fixes:
- About Window: Fix 'escape' to close window
- Remove outdated dist/copy tasks from Gruntfile
Eslintified settings_view.js
Creating/destroying notifications too quickly in testing on macOS would
result in them sticking around forever, requiring manual user dismissal.
We want to dismiss them for the user when we close or our window is
activated. So now we debounce() calls to our notifications code.
* Upgrade to Electron 1.8.2 / Node.js 8.2.1
* Update CI Node.js versions
* Make `engines` top-level property
This was accidentally included under `build` which is disallowed
by `electron-builder`.
* Refactor notification updates
Allows easier debugging through variable inspection.
* Use `appId` for Application User Model ID
Recommended in:
https://github.com/electron/electron/issues/10864#issuecomment-346229090
* Update `spectron` to 3.8.0
* Bump `electron-builder` based dependencies
* Use `config.extraMetadata` instead of `em`
Prevents `Unknown argument: em` error.
See: https://github.com/electron-userland/electron-builder/issues/2615
* Revert AUMID to be based on `packageJson.name`
In our build artifact `packageJson.build.appId` causes an NPE.
This fix is related about issue #1587
window.drawAttention() repositioned to allow complete control over notifications by settings. It now does not draw attention when the notifications are off.
This partially reverts commit 1b444a5e23.
Because support for system-level notification sound settings is inconsistent
across Win/Linux/OSX, do the simplest thing that will produce consistent
behavior on all platforms: suppress the system sound by always passing the
`silent: true` option, and play our own sound clip (copied from ios).
// FREEBIE
This prevents the parade of notifications if a machine wakes up from
sleep. Basically covers situations that the loading screen doesn't
already.
When disabled, notifications will be cached until they are subsequently
re-enabled, at which time all the pending notifications will be summarized.
From the background page, notifications are disabled during connection attempts
until an empty event. This means we can always safely call conversation.notify
to queue a notification for the next batch, dropping some options from message
and conversation model methods.
We've also moved the calls to check window focus and draw attention to the
window, which were previously included in the conversation model, but are now
performed by the Notification system, because the time that the notification is
displayed might be some time after the message is added by the conversation, so
decisions about focus and attention should be made in that moment and not
before.
// FREEBIE
This removes our custom notification sound in favor of the system sound, and
ensures that the system sound is disabled if the user unchecks the audio
notification option.
// FREEBIE
Change the placeholder content for when notifications are configured for
count-only or sender-only. Remove some options that are no longer
supported.
// FREEBIE
Since we no longer have support for list-style notifications, stop
coalescing notifications into batches and just show contents of the last
message received. Also open the window when clicking on a notification
if it has previously been closed.
// FREEBIE
All Whisper.events listeners are now defined and bound in background.js,
and we no longer need global methods for opening the inbox and
conversation views, as those are handled by AppView or internally by
InboxView.
// FREEBIE
* Fetch conversations once, clean up ConversationController API
Race conditions around re-fetching have caused some problems recently,
so this removes the need to re-fetch conversations. They are fetched
once or saved once, and that is it. All interaction goes through the
ConversationController, which is the central source of truth.
We have two rules for Conversations:
1. If a conversation is in the ConversationController it doesn't need
to be fetched, but its initial fetch/save might be in progress. You
can wait for that fetch/save with conversation.initialPromise.
2. If a conversation is not already in the ConversationController, it's
not yet in the database. It needs to be added to the
ConversationController and saved to the database.
FREEBIE
* Remove Conversation.fetch() call in Message.handleDataMessage()
FREEBIE
* ConversationController.API cleanup: Fix two missing spots
FREEBIE
Scott Nonnenberg
Daniel Gasienica
Daniel Gasienica
Scott Nonnenberg
Caner Elci
Lilia
Asa Ayers