RFC: Activity feature #11826

1. 
   promag commented at 2:14 am on December 5, 2017: member

   This is a RFC regarding adding a new Activity window in the UI, which allows to:

   • have activity history (truncated, etc);
   • pause or cancel tasks if supported individually;
   • have multiple progresses concurrently.

   In terms of patch, ShowProgress() signal is removed everywhere and a RAII class is added along with some UI classes:

   0class Activity
   1{
   2    std::shared_ptr<ActivityData> const d;
   3public:
   4    Activity(const std::string& title);
   5    ~Activity();
   6
   7    void SetTitle(const std::string& title);
   8    void SetProgress(int progress);
   9};
   

   Consider this the minimal interface for an activity. Some other ideas:

   • custom progress range (so the caller doesn’t have to calculate percentage)
   • add something like SetPause(bool), IsPaused();
   • also Cancel() and IsCancelled();
   • add something like SetSource(string) (for instance SetSource("wallet1")).

   The current implementation is thread safe. For now, I’ve also added a new menu item Window where I think we could add Console too (another discussion thou).

   Please see the capture below.

   

2. 
   TheBlueMatt commented at 3:14 am on December 5, 2017: member

   I mean looks cool, but I dont know how many parallell things we’re gonna have (seems like mostly just the rescanning stuff, afaiu, everything is is gonna block RPC), it seems like it’d be a bit of building a neat progress framework that nothing is gonna use. If we were to go down the route of encouraging more rescanning or so this may make sense, but I konw a bunch of folks hate rescan generally.
3. 
   promag commented at 7:54 am on December 5, 2017: member

   I already have identified a bunch of stuff other than rescanning. Everything that happens asynchronously to the UI has the potential to be an activity: creating transactions, dump/import wallets, process blocks, db verification, blockchain check…

   Beside, IMO the RAII here fits better (because of all it’s benefits) than the signal. Also, the interface turns to be more organised.

   This is an alternative solution to #11200.

4. 
   promag commented at 7:57 am on December 5, 2017: member

   Pinging @jonasschnelli @ryanofsky @luke-jr since you have been working on the UI.
5. 
   promag commented at 8:11 am on December 5, 2017: member

   Following #11200#pullrequestreview-59957173 @ryanofsky with this approach callbacks are not needed.
6. 
   ryanofsky commented at 12:06 pm on December 5, 2017: member

   Sounds great! I would love to see the code changes. An RAII class seems perfect for managing start/stop/progress of ongoing tasks.

   As far as UI, I would probably suggest embedding activity display into the main window to avoid the distracting popup. In the special case when activity is triggered by an RPC console command, progress for that one activity could be mirrored in the RPC console (as well as overall activity display).

   @ryanofsky with this approach callbacks are not needed

   Just a semantic nitpick but in my mind signals, virtual methods, and function pointers are all “callbacks”, so any Activity class implementation would need to use some form of callback to avoid creating a dependency of non-gui code on gui code.

7. 
   promag commented at 2:40 pm on December 5, 2017: member

   An RAII class seems perfect for managing start/stop/progress of ongoing tasks.

   :+1:

   to avoid the distracting popup

   At the moment it’s not a popup, it is up to the user to open the activity window. I don’t think this is a first class citizen for the main window. Maybe add an activity icon on the status bar, like:

   .

   Anyway, for now I’m more interested in having concept ACK’s than discussing the looks of it.

   Regarding the callback discussion, this is what I’m planning to support:

   0Activity a;
   1a.SetTitle(...);
   2a.SetAllowCancel(true);
   3
   4while (!a.IsCancelled()) {
   5    ...
   6    a.SetProgress(current, total);
   7}
   

8. 
   ryanofsky commented at 3:22 pm on December 5, 2017: member

   At the moment it’s not a popup

   Oh, misinterpreted the animation. In any case I just wanted to bring up the possibility integrating the progress display into existing windows instead of having a separate window. Just a suggestion which you should feel free to take or leave.

   I don’t think this is a first class citizen for the main window. Maybe add an activity icon on the status bar

   An activity indicator with optional progress bar and pause / cancel buttons on or above the status line was what I was thinking. The same display could be shown in the RPC console for actions triggered by console commands. Again though, this is just a suggestion.

   Regarding the callback discussion, this is what I’m planning to support […]

   I personally like that a lot. I think it looks better than adding more arguments to uiInterface.ShowProgress, and would be less error-prone (though equivalent). @TheBlueMatt, I don’t think I understand your fears of this turning into some kind of “progress framework.” It just seems like replacing or wrapping the overloaded uiInterface.ShowProgress callback with a pretty simple class.

9. 
   jonasschnelli commented at 7:09 pm on December 5, 2017: contributor

   I like the activity window. The same approach you see often in software that do heavy CPU usage. Things like Video-Cutting, 3D rendering, etc. I also have an activity window in my Mail app.

   The activity window could include: -> Block syncing state (progress) -> Rescan (progress) -> Validating block (when in sync) (progress) -> Peer disconnect (auto-disappearing action entry) -> Peer connecting (auto-disappearing action entry) -> Mempool dumps (progress)

   The activity window could be the enlarged view of the progress bar… though, someone needs to come up with a nice concept how this would fit together with the current single element progress bar, the modal overlay progress info.

10. 
    promag commented at 7:19 pm on December 5, 2017: member

    You mean the overlay that shows up on start?
11. 
    jonasschnelli commented at 8:06 pm on December 5, 2017: contributor

    @promag: Yes. This is also sort of an activity (with more details). It can stay, but it should also pop up in the activity window somehow.
12. 
    KanoczTomas commented at 4:28 pm on December 7, 2017: none

    Wow this looks cool, I could imagine a realtime mempool tx activity if one chooses that to be shown in the gui :)
13. 
    promag commented at 4:47 pm on December 7, 2017: member

    realtime mempool tx activity

    I don’t understand what you mean.

14. 
    laanwj commented at 4:57 pm on December 7, 2017: member

    Concept ACK.

    Also the idea of having all operations be performed asynchronously makes sense, this is how a GUI should work. Currently way too many things block the GUI thread. Ideally nothing that requires either the wallet lock or the cs_main lock would be executed in the GUI thread, but in a separate thread, akin to how RPC commands are processed.

15. 
    promag commented at 4:03 am on December 14, 2017: member

    An activity discussed with @sipa is Gathering data for fee estimation that should show up while fee estimation is not ready. cc @morcos
16. 
    ryanofsky commented at 3:24 pm on December 14, 2017: member

    Not sure what progress on the overall issue is, but one suggestion I might have would be to make the data structure that will hold the list of current activities independent from Qt code. This could allow us also to have RPC calls / notifications that also have access to the progress information.
17. 
    promag commented at 3:49 pm on December 14, 2017: member

    There is “core” code and Qt code.

    That is a nice idea!

18. fanquake added the label Feature on Sep 6, 2018
19. fanquake added the label GUI on Sep 6, 2018
20. 
    Sjors commented at 5:48 pm on January 29, 2019: member

    Concept ACK, but I don’t like having yet another popup. Let’s reuse the bottom progress bar (used during IBD). When you click on that, show different interruptible processes.

    In the (probably rare) case that there is more than one process, use either the slowest or the oldest for the progress bar.

21. 
    fanquake commented at 10:09 am on August 14, 2020: member

    Discussion here has dried up. Maybe it can be rebooted over in the GUI repo. I’ve moved this issue over there: https://github.com/bitcoin-core/gui/issues/57. @promag if you’re no-longer interested in this, just let me know and I’ll close the new issue.
22. fanquake closed this on Aug 14, 2020

    ---

23. DrahtBot locked this on Feb 15, 2022

Contributors
promag TheBlueMatt ryanofsky jonasschnelli KanoczTomas laanwj Sjors fanquake

Labels
Feature GUI