2022-12-06 14:53:32 -08:00
|
|
|
use std::{
|
|
|
|
env::{current_dir, current_exe},
|
|
|
|
fs::File,
|
|
|
|
path::PathBuf,
|
|
|
|
sync::mpsc::Receiver,
|
|
|
|
};
|
|
|
|
|
|
|
|
use anyhow::{Context, Result};
|
|
|
|
use const_format::formatcp;
|
|
|
|
|
|
|
|
use crate::{
|
Repaint rework: more responsive, less energy
Previously, we repainted every frame on Windows at full refresh rate.
This is an enormous waste, as the UI will be static most of the time.
This was to work around a bug with `rfd` + `eframe`.
On other platforms, we only repainted every frame when a job was running,
which was better, but still not ideal. We also had a 100ms deadline, so
we'd repaint at ~10fps minimum to catch new events (file watcher, jobs).
This removes all repaint logic from the main loop and moves it into the
individual places where we change state from another thread.
For example, the file watcher thread will now immediately notify egui
to repaint, rather than relying on the 100ms deadline we had previously.
Jobs, when updating their status, also notify egui to repaint.
For `rfd` file dialogs, this migrates to using the async API built on top of
a polling thread + `pollster`. This interacts better with `eframe` on Windows.
Overall, this should reduce repaints and improve responsiveness to
file changes and background tasks.
2023-11-21 11:34:26 -08:00
|
|
|
jobs::{start_job, update_status, Job, JobContext, JobResult, JobState},
|
2022-12-06 14:53:32 -08:00
|
|
|
update::{build_updater, BIN_NAME},
|
|
|
|
};
|
|
|
|
|
|
|
|
pub struct UpdateResult {
|
|
|
|
pub exe_path: PathBuf,
|
|
|
|
}
|
|
|
|
|
Repaint rework: more responsive, less energy
Previously, we repainted every frame on Windows at full refresh rate.
This is an enormous waste, as the UI will be static most of the time.
This was to work around a bug with `rfd` + `eframe`.
On other platforms, we only repainted every frame when a job was running,
which was better, but still not ideal. We also had a 100ms deadline, so
we'd repaint at ~10fps minimum to catch new events (file watcher, jobs).
This removes all repaint logic from the main loop and moves it into the
individual places where we change state from another thread.
For example, the file watcher thread will now immediately notify egui
to repaint, rather than relying on the 100ms deadline we had previously.
Jobs, when updating their status, also notify egui to repaint.
For `rfd` file dialogs, this migrates to using the async API built on top of
a polling thread + `pollster`. This interacts better with `eframe` on Windows.
Overall, this should reduce repaints and improve responsiveness to
file changes and background tasks.
2023-11-21 11:34:26 -08:00
|
|
|
fn run_update(status: &JobContext, cancel: Receiver<()>) -> Result<Box<UpdateResult>> {
|
2022-12-06 14:53:32 -08:00
|
|
|
update_status(status, "Fetching latest release".to_string(), 0, 3, &cancel)?;
|
|
|
|
let updater = build_updater().context("Failed to create release updater")?;
|
|
|
|
let latest_release = updater.get_latest_release()?;
|
|
|
|
let asset = latest_release
|
|
|
|
.assets
|
|
|
|
.iter()
|
|
|
|
.find(|a| a.name == BIN_NAME)
|
2022-12-06 15:09:19 -08:00
|
|
|
.ok_or_else(|| anyhow::Error::msg(formatcp!("No release asset for {}", BIN_NAME)))?;
|
2022-12-06 14:53:32 -08:00
|
|
|
|
|
|
|
update_status(status, "Downloading release".to_string(), 1, 3, &cancel)?;
|
|
|
|
let tmp_dir = tempfile::Builder::new().prefix("update").tempdir_in(current_dir()?)?;
|
|
|
|
let tmp_path = tmp_dir.path().join(&asset.name);
|
|
|
|
let tmp_file = File::create(&tmp_path)?;
|
|
|
|
self_update::Download::from_url(&asset.download_url)
|
|
|
|
.set_header(reqwest::header::ACCEPT, "application/octet-stream".parse()?)
|
|
|
|
.download_to(&tmp_file)?;
|
|
|
|
|
|
|
|
update_status(status, "Extracting release".to_string(), 2, 3, &cancel)?;
|
|
|
|
let tmp_file = tmp_dir.path().join("replacement_tmp");
|
|
|
|
let target_file = current_exe()?;
|
|
|
|
self_update::Move::from_source(&tmp_path)
|
|
|
|
.replace_using_temp(&tmp_file)
|
|
|
|
.to_dest(&target_file)?;
|
|
|
|
#[cfg(unix)]
|
|
|
|
{
|
2022-12-07 22:49:21 -08:00
|
|
|
use std::{fs, os::unix::fs::PermissionsExt};
|
2022-12-06 14:53:32 -08:00
|
|
|
let mut perms = fs::metadata(&target_file)?.permissions();
|
2022-12-06 15:09:19 -08:00
|
|
|
perms.set_mode(0o755);
|
2022-12-06 14:53:32 -08:00
|
|
|
fs::set_permissions(&target_file, perms)?;
|
|
|
|
}
|
|
|
|
|
|
|
|
update_status(status, "Complete".to_string(), 3, 3, &cancel)?;
|
|
|
|
Ok(Box::from(UpdateResult { exe_path: target_file }))
|
|
|
|
}
|
|
|
|
|
Repaint rework: more responsive, less energy
Previously, we repainted every frame on Windows at full refresh rate.
This is an enormous waste, as the UI will be static most of the time.
This was to work around a bug with `rfd` + `eframe`.
On other platforms, we only repainted every frame when a job was running,
which was better, but still not ideal. We also had a 100ms deadline, so
we'd repaint at ~10fps minimum to catch new events (file watcher, jobs).
This removes all repaint logic from the main loop and moves it into the
individual places where we change state from another thread.
For example, the file watcher thread will now immediately notify egui
to repaint, rather than relying on the 100ms deadline we had previously.
Jobs, when updating their status, also notify egui to repaint.
For `rfd` file dialogs, this migrates to using the async API built on top of
a polling thread + `pollster`. This interacts better with `eframe` on Windows.
Overall, this should reduce repaints and improve responsiveness to
file changes and background tasks.
2023-11-21 11:34:26 -08:00
|
|
|
pub fn start_update(ctx: &egui::Context) -> JobState {
|
|
|
|
start_job(ctx, "Update app", Job::Update, move |context, cancel| {
|
|
|
|
run_update(&context, cancel).map(JobResult::Update)
|
2022-12-06 14:53:32 -08:00
|
|
|
})
|
|
|
|
}
|