This bug was subtle. Basically, on OS X only, we use
window.setAspectRatio() to make the player window match the video size.
But this is maintained even in fullscreen mode, which makes the window
actually not use up the fullscreen, and there are black bars above and
below the video player controls, which looks really weird.
Unset the aspect ratio in fullscreen mode, then set it again upon
leaving fullscreen mode.
Apparently, electron.* is actually a getter, so whenever a component of
electron is referenced for the first time, it's require()'d. So, there
are theoretical performance benefits to not declaring all electron.*
upfront.
Instead of:
var autoUpdater = electron.autoUpdater
Just use electron.autoUpdater directly when needed.
The goal here is to remove shortcut handling from the renderer and
unify it all in menu.js and shortcuts.ks (for alternate shortcuts).
I would rather name it "Play" and change to "Pause" when video is
playing, but Electron doesn't support this (yet).
The goal of this commit is to merge the two torrent status lines onto a
single, concise line which has high signal and information density.
- Hide download speed, upload speed, and number of peers when 0,
because that's just noise.
- Remove number of files, because that information can be found by
expanding the torrent.
This also allowed the further reduction of the torrent item height from
110px to 100px.
WebTorrent 0.91 changed how duplicate torrents are handled, which broke
handling in WebTorrent Desktop.
After this PR:
- No more try-catch on client.add -- this has never thrown errors.
- No check for duplicate torrent.key value since client.add no longer
returns the same torrent object when adding a duplicate torrent. It
emits 'error' instead, and that case is already handled :)
Based on @watson's PR #463.
Differences:
- Remove the "Open Folder" link from expanded torrent view.
- Use showItemInFolder instead of openItem electron API
- Add a separator
- Use IPC to invoke electron.shell.showItemInFolder from main process
This works around a WebTorrent bug where calling client.add(torrentFilePath) to add a duplicate torrent -- in other words, one whose infoHash we're already torrenting -- creates a new torrent object and later throws an error. Inconsistently, calling client.add(magnetURI) or client.add(infoHash) to add a duplicate torrent returns the existing torrent object that we're already torrenting and doesn't throw an error.
This also fixes a prety nasty bug where pasting a dupe magnet link changed the torrentKey of an existing torrent, breaking the communication between the main and WebTorrent windows
Fixes#364
