badabing2005
commented
3 days ago Agreed 100% in principal, however aside from the fact that it adds complexity, one needs to worry about each and every background process function and accordingly manage the UI by disabling features that shouldn't be executed while the background process is still running. Forwarding logs from background thread process to UI console in real time rather than after completion is yet another non-trivial challenge. Another concern is, if you let the user interact with the UI while running a background process that produces logs, (by design PixelFlasher is highly verbose to help users with troubleshooting) you end up with interlaced logs, which makes it quite difficult to troubleshoot and trace down problems.
I spend a lot of time helping users (on xda forums and here) with their support files troubleshooting problems, the last thing I want when tracing events is interlaced events and logs, I understand I could create log categories and group them and what not, but I have no intentions on refactoring a lot of the code just so that the UI is not blocked while flashing, incidentally it is not totally blocked, there are Yield operations almost everywhere.
I have implemented thread based running background shell process, you can see here and it is used for certain invocations, however using it for flashing proved to be highly unreliable and problematic.
As stated in the readme, this was my first wxpyton project, and when I started coding this, I didn't know much about it, although I learned a lot along the way, by no means I consider myself an expert in the subject matter, and in fact I would welcome pull requests that make the project better and simpler.
Tiebe
You shouldn't run the fastboot flashing comamnds on the UI thread, since this causes the application to hang (unable to resize or move window, etc) while flashing.
Instead, run this on a background thread, and keep the main thread for the UI, while forwarding the logs to the this thread.