This commit adds a tray icon to the application, shown in the system
tray bar, that can be used to minimise the application window. This
is a common feature on most desktop messaging apps (e.g. Telegram
Desktop or Slack) and allows to save space in the system task bar.
The tray icon provides a context menu that contains a button to
show/hide the application window, and a button to quit the
application. When the tray icon is clicked, the visibility of the
window is toggled. When the close (x) button of the window is
pressed, the application is not terminated but minimised to the tray
icon instead (it can be terminated by using the "Quit" entry in the
File menu or in the context menu of the tray icon).
The tray icon is disabled by default, and two command line arguments
are available to enable it:
--use-tray-icon: enables the tray icon
--start-in-tray: enables the tray icon and the application starts
minimised in the tray bar
Resolves: #1480
* Added top level menu shortcuts (Fixes#1688 and #1695).
The ampersand (&) character in front of a letter in a menu label
indicates that the letter that follows '&' will be used as a keyboard
shortcut letter to access this menu. In Windows/Linux, the default
shortcut combination is Alt+<letter>.
* Use non-hardcoded menu labels.
The menu labels were hardcoded in English.
We should not be using plain strings right in the source code, but
pulling them from the `messages.json` files instead.
* Script for beta config; unique data dir, in-app env/type display
To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.
The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.
Note: Beta builds can be installed alongside production builds.
As part of this, a couple new bits of data are shown across the app:
- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)
These are shown in:
- The window title - both environment and app instance. You can tell
beta builds because the app name, preceding these data bits, is
different.
- The about window - both environment and app instance. You can tell
beta builds from the version number.
- The header added to the debug log - just environment. The version
number will tell us if it's a beta build, and app instance isn't
helpful.
* Turn on single-window mode in non-production modes
Because it's really frightening when you see 'unable to read from db'
errors in the console.
* aply.sh: More instructions for initial setup and testing
* Gruntfile: Get consistent with use of package.json datas
* Linux: manually update desktop keys, since macros not available
* Remove reload options, new file/help menus, tools/log at bottom
* Further menus refactor: install handlers at template creation
* WIP: Further tune menus, add custom about window
* New About window, new help menu items, menu labels now i18n
* Default device name on registration is now computer hostname
The OS of the device makes sense for those of us testing across a lot of
different OSes. And maybe for a user with just one desktop device. But
most users with multiple desktop devices are using the same OS for both.
* About window: Only show window when content is ready
* Fix typo in app/menu.js
An immediate response to the user request to see the log, and then we
show the real data as soon as we've loaded it from disk.
Changes:
- the IPC exchange to get the log data is now async
- the API to fetch the log on the client side now returns a Promise
- in the main process, the only disk access done synchronoously is
reading the contents of the log directory. The JSON parsing of the
resultant log data is now split up into three chunks.
- We only send three keys from each log item to the renderer process:
msg, time, level. Previously we sent the entire log entry with extra
keys: hostname, pid, name.
FREEBIE
This should allow us to get an insight into auto-update behavior and
other low-level behaviors happening in the Electron process which would
be useful for debugging.
FREEBIE
Beacause so many of our tests have hardcoded english strings. We could do
better, but for now anyone running tests locally must simply do so in english,
even if they usually use Signal in another language.
// FREEBIE
- Logging is available in main process as well as renderer process, and
entries all go to one set of rotating files. Log entries in the
renderer process go to DevTools as well as the console. Entries from
the main process only show up in the console.
- We save three days of logs, one day per file in %userData%/logs
- The 'debug' object store is deleted in a new database migration
- Timestamps and level included in the new log we generate for publish
as well as the devtools
- The bunyan API is exposed via windows.log (providing the ability to
log at different levels, and save objects instead of just text), so we
can move our code to it over time.
FREEBIE
Just send an event from the main process to the renderer,
The latter routes it the appropriate view method.
For now it's a no-op unless the main window exists and it is showing the inbox,
which will be addressed in a future commit.
// FREEBIE
