mirror of
https://github.com/quine-global/hyper.git
synced 2026-01-12 20:18:41 -09:00
Quine's fork of "Hyper" by Vercel, A terminal built on web technologies
5d7142c2df
* 1. Restored the ability to turn the "bell" sound on and off using the "bell" config parameter. 2. Restored the ability to change the bell sound by providing a URL. These changes allow for a web url or local absolute file path to an audio file. The goal with these changes was to fix the issue causing the bell to never sound due to a difference in the underlying terminal emulators configurations from the previous one. While in the area, also decided to make sure that the sound can be changed by supplying a web url to an audio file or an absolute path to an audio file within the local machine * Code style changes * Code style changes * 1. More code style changes * 1. Spacing changes to try and abide by the linter * 1. Applied all suggested changes by eslint * 1. Removed functionality to specify a remote url to set a sound file for the bell sound. The amount of effort for handling when there is no internet connection, queuing and so forth wasn't worth keeping the feature. It is likely that the url could be used to download the file in which the user would be able to specify the file path tho this download file. 2. Created a new property that gets passed down from the terms container all the way to the individual term. We want to be able to evaluate if the bellSoundURL has changed to determine if we really need to read the sound file. 3. Moved logic to read the audio file into the main process. Setup a new action in the 'actions/ui' that will update the bell sound when it is finished and ready. This should prevent blocking the terminal from loading and thus increasing loading times. * 1. Modified the file reading method to be more generic to increase reusability. 2. Updated the "arrBuf2Base64" method to utilize the node Buffer class which helped to reduce some complexity and seems to run more efficiently. 3. Removed the CONFIG_ASYNC action and reducer in favor of reusing CONFIG_RELOAD when the process is finished reading the file for the bell sound. In order to achieve this, we had to merge the config from "config.getConfig()" method with the "bellSound" property before dispatching to "reloadConfig". * 1. Removed reference to now removed method * 1. Removed the arrBuf2Base64 as it seemed unnecessary now that the function would be reduced to a single line. Moved the one-liner into file.js. Removed references to arrBuf2Base64 method. 2. Refactored the logic that handles reloading the config when it has been updated to fix an issue that would set the bell sound back to the default sound when the config is saved without changing the value of "bellSoundURL". Setup now to either read file and reload the config, or reuse the "bellSound" value saved in state and reload the config. This removes an inefficiency with the reloadConfig being dispatched twice when "bellSoundURL" has changed as well. * 1. Removed a file that contained a single function, referenced in only one place that is performing a fairly simple task. 2. Updated the "getBase64FileData" method to use "Buffer.from()" instead of "Buffer()" due to messages stating that "Buffer()" is deprecated due to security and usability issues. * Adjustments and regression issues fixed 1. Updated the default config file to better explain the supported options for the "bell" config property. 2. Rearranged the bellSoundURL default property to make it easier to find should one decide to change the bell sound. 3. Typos fixed in comments. 4. Update fetchFileData to utilize the configData provided as function argument. There appeared to be no reason to reference different sources of config data within the same method. * 1. Removed the "BELL_STYLE" constant since it was only being used in one place. 2. Updated comment block to accurately reflect the current logic and made the comment much more concise. |
||
|---|---|---|
| .circleci | ||
| .github | ||
| .vscode | ||
| app | ||
| assets | ||
| bin | ||
| build | ||
| cli | ||
| lib | ||
| test | ||
| .editorconfig | ||
| .eslintignore | ||
| .gitattributes | ||
| .gitignore | ||
| .travis.yml | ||
| .yarnrc | ||
| appveyor.yml | ||
| jsconfig.json | ||
| LICENSE | ||
| package.json | ||
| PLUGINS.md | ||
| README.md | ||
| release.js | ||
| tsconfig.json | ||
| webpack.config.js | ||
| yarn.lock | ||
For more details, head to: https://hyper.is
Usage
Linux
Arch and derivatives
Hyper is available in the AUR. Use an AUR package manager like aurman
aurman -S hyper
macOS
Use Homebrew Cask to download the app by running these commands:
brew update
brew cask install hyper
Windows
Use chocolatey to install the app by running the following command (package information can be found here):
choco install hyper
Note: The version available on Homebrew Cask, Chocolatey, Snapcraft or the AUR may not be the latest. Please consider downloading it from here if that's the case.
Contribute
Regardless of the platform you are working on, you will need to have Yarn installed. If you have never installed Yarn before, you can find out how at: https://yarnpkg.com/en/docs/install.
- Install necessary packages:
- Windows
- Be sure to run
yarn global add windows-build-toolsfrom an elevated prompt (as an administrator) to installwindows-build-tools.
- Be sure to run
- macOS
- Once you have installed Yarn, you can skip this section!
- Linux (You can see here what your Linux is based on.)
- RPM-based
GraphicsMagicklibicns-utilsxz(Installed by default on some distributions.)
- Debian-based
graphicsmagickicnsutilsxz-utils
- RPM-based
- Fork this repository to your own GitHub account and then clone it to your local device
- Install the dependencies:
yarn - Build the code and watch for changes:
yarn run dev - To run
hyper
yarn run appfrom another terminal tab/window/pane- If you are using Visual Studio Code, select
Launch Hyperin debugger configuration to launch a new Hyper instance with debugger attached. - If you interrupt
yarn run dev, you'll need to relaunch it each time you want to test something. Webpack will watch changes and will rebuild renderer code when needed (and only what have changed). You'll just have to relaunch electron by using yarn run app or VSCode launch task.
To make sure that your code works in the finished application, you can generate the binaries like this:
yarn run dist
After that, you will see the binary in the ./dist folder!
Known issues that can happen during development
Error building node-pty
If after building during development you get an alert dialog related to node-pty issues,
make sure its build process is working correctly by running yarn run rebuild-node-pty.
If you are on macOS, this typically is related to Xcode issues (like not having agreed
to the Terms of Service by running sudo xcodebuild after a fresh Xcode installation).
Error with c++ on macOS when running yarn
If you are getting compiler errors when running yarn add the environment variable export CXX=clang++
Error with codesign on macOS when running yarn run dist
If you have issues in the codesign step when running yarn run dist on macOS, you can temporarily disable code signing locally by setting
export CSC_IDENTITY_AUTO_DISCOVERY=false for the current terminal session.