2017-10-13 23:49:16 +00:00
|
|
|
<html>
|
|
|
|
|
<head>
|
|
|
|
|
<link href="stylesheets/manifest.css" rel="stylesheet" type="text/css" />
|
|
|
|
|
<style>
|
|
|
|
|
|
|
|
|
|
body {
|
|
|
|
|
text-align: center;
|
|
|
|
|
background-color: #2090EA;
|
|
|
|
|
color: white;
|
|
|
|
|
font-size: 14px;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
img {
|
|
|
|
|
margin-top: 2em;
|
|
|
|
|
margin-bottom: 1em;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
a {
|
|
|
|
|
color: white;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
</style>
|
|
|
|
|
</head>
|
|
|
|
|
<body>
|
|
|
|
|
|
|
|
|
|
<img src='images/icon_250.png'>
|
|
|
|
|
|
|
|
|
|
<div>
|
|
|
|
|
<script>
|
2018-06-21 19:02:19 +00:00
|
|
|
document.write('v', window.getVersion());
|
2017-10-13 23:49:16 +00:00
|
|
|
</script>
|
|
|
|
|
</div>
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* 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
2017-10-30 20:57:13 +00:00
|
|
|
<div>
|
|
|
|
|
<script>
|
2018-06-21 19:02:19 +00:00
|
|
|
const states = [];
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* 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
2017-10-30 20:57:13 +00:00
|
|
|
|
2018-06-21 19:02:19 +00:00
|
|
|
if (window.getEnvironment() !== 'production') {
|
|
|
|
|
states.push(window.getEnvironment());
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* 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
2017-10-30 20:57:13 +00:00
|
|
|
}
|
2018-06-21 19:02:19 +00:00
|
|
|
if (window.getAppInstance()) {
|
|
|
|
|
states.push(window.getAppInstance());
|
Beta versions support: SxS support, in-app env/instance display (#1606)
* 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
2017-10-30 20:57:13 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
document.write(states.join(' - '));
|
|
|
|
|
</script>
|
|
|
|
|
</div>
|
2017-10-13 23:49:16 +00:00
|
|
|
<div>
|
|
|
|
|
<a href="https://signal.org">signal.org</a>
|
|
|
|
|
</div>
|
|
|
|
|
|
2018-05-20 03:53:12 +00:00
|
|
|
<script type='text/javascript' src='node_modules/jquery/dist/jquery.js'></script>
|
2017-11-21 23:23:18 +00:00
|
|
|
<script>
|
|
|
|
|
$(document).on('keyup', function(e) {
|
|
|
|
|
if (e.keyCode === 27) {
|
|
|
|
|
window.closeAbout();
|
|
|
|
|
}
|
|
|
|
|
});
|
|
|
|
|
</script>
|
|
|
|
|
|
|
|
|
|
|
2017-10-13 23:49:16 +00:00
|
|
|
</body>
|
|
|
|
|
|
|
|
|
|
</html>
|