Skip to content

New project modal: Display logs + Cancel task#257

Open
ThierryBerger wants to merge 7 commits into
jbuehler23:mainfrom
ThierryBerger:cancelling_tasks
Open

New project modal: Display logs + Cancel task#257
ThierryBerger wants to merge 7 commits into
jbuehler23:mainfrom
ThierryBerger:cancelling_tasks

Conversation

@ThierryBerger
Copy link
Copy Markdown
Contributor

@ThierryBerger ThierryBerger commented May 21, 2026

jackdaw_logs

wip attempt on improving the new project modal:

  • makes error enums more specific
  • have a automatically scrolling log (be able to see if something goes wrong (libssl)
    • reusing existing scroll could be made but we'd need to pin it to bottom, I'll consider this out of scope because the component may be reworked to use feathers.
  • be able to cancel tasks (when cargo generate / when building the project)
    • I considered a timeout but coming up with a default is not really possible, a cancel makes more sense (low internet may make that longer, and a long timeout defeats the purpose)
  • the back button now shows "back" to close the modal, and "Cancel" to cancel the scaffolding/building.

possible follow ups

  • Consider using the cancelation logic for the modal opening an existing project
  • Check if the scrolling component is needed / usable elsewhere.

Comment thread src/project_select.rs Outdated
Comment thread src/lib.rs
Comment thread src/scrolling_log.rs
@ThierryBerger ThierryBerger force-pushed the cancelling_tasks branch 3 times, most recently from a051cf8 to 9a754bd Compare May 21, 2026 09:51
Comment thread src/project_select.rs Outdated
Comment on lines +2196 to +2201
// Cooperative cancel: flip the flag the worker polls and
// keep the modal open showing "Cancelling…". The poller's
// Err(Cancelled) arm will switch the status to
// "Cancelled." once the worker unwinds (the worker kills
// the child + drainer threads join + final Err returns),
// leaving the user free to tweak inputs and retry.
Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

while interesting, not sure implementation details are well served in comments, as it is it's describing the code..

Comment thread src/command_runner.rs Outdated
let mut cancelled = false;
let status = loop {
// Don't busy wait (try_wait is non-blocking).
std::thread::sleep(Duration::from_millis(50));
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

https://doc.rust-lang.org/std/hint/fn.spin_loop.html might be a better fit or another way of awaiting/polling without any blocking but I dont think it's a big deal if it works and doesn't potentially deadlock.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think spin_loop is particularly better than a sleep here as we expect the wait to take some time anyway.

That being said, I can see sleep being a problem if we target web ? Any insight about that ?

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dont think it will deadlock on web currently but it might lag. I'm not sure how realistic targeting web is at this stage so not sure we can try it out at this time.

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think spin_loop is particularly better than a sleep here as we expect the wait to take some time anyway.

Fair enough, I agree if it doesn't cause issues its fine.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You actually convinced me:

  • sleep is probably blocking in single thread environment, where tasks have to run on the same thread
  • not really an issue, but web wouldn't like us using sleep 😅

Copy link
Copy Markdown
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i don't have plans to support jackdaw on web.....yet

Comment thread src/ext_build.rs Outdated
.unwrap_or_default();
return Err(BuildError::Cancelled { stderr_tail: tail });
}
std::thread::sleep(Duration::from_millis(50));
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here I guess

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let's keep the discussion on #257 (comment) then.

Comment thread src/project_select.rs

// Scaffold.
if let Some(task) = state.scaffold_task.as_mut()
&& let Some(result) = future::block_on(future::poll_once(task))
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be fine but block_on could also potentially cause deadlocks down the line if called from the main UI thread on Windows/MacOS while requiring the main thread inside the child somewhere (e.g. a popup file dialog)

Copy link
Copy Markdown
Contributor Author

@ThierryBerger ThierryBerger May 21, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here we use poll_once, so we're not really blocking here 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants