Sorry for the delayed response.
I like the mockup, I think the in progress section could also show the total running time of the "QUEUED/RUNNING" jobs (this is helpful in the remote client and would be easy to track on the local runs).
Some additional thoughts to consider:

1. SUCCESS, SKIPPED nodes probably don't need to stay in the list of nodes (to keep this from getting too long), similarly for PENDING node (not sure what the right answer here it).
2. I think in running pointing to the log instead of the command would be useful

As for the metrics, it looks like rich as a inspection/paging feature which might be better suited. I think that is something that the summary function would handle, so it might be okay to skip that for now.

We don't have any obvious easy hooks to handle multiple running jobs in a single view (I suspect we would need to allow the dashboards to connect to eachother to pass information around). I think it would make sense to start with a single job and figure out the multiple job mechanics once one is working. Once this is working it would be easier to add the multi-job thing (I think this would be particularly useful for jobs submitted to slurm or the remote runners).
I think it could look something like:

No problem. I got busy some something else. I like your suggestions. I modified the mockup to match that.

Running with fails

The [1/2] next to the progress represents [pending/running]. Is this what you had in mind? I'm not sure if it's immediatly intuitive to the user.

Done with fails

Done Success

Running with fails multi-job

Does this get closer to something useful?

Yeah I agree, not sure if the [pending/running] adds anything (it certainly does make is harder to understand), so lets not do that.
I think as a first stab, just keep the SUCCESS/PENDING, etc ones in the list (like it was in your first set of images), we can figure out a pruning mechanism later that makes sense.

I like the logger view (I accidentally cropped it in the image I uploaded). There is one obvious issue at the moment with this, right now the loggers just send to stdout, but for the this work properly, the way loggers are handled might need some improvement. (I'm happy to make those changes once there is something to test against).

Once we get a prototype it will be quite easy to update the UI. I can't promise anything this week since I have other things that require my attention. but I will get to it eventually.

Regarding the logger, I think rich supports capturing the stdout and stderr of subcommands, so maybe we can capture chip.run. But I'll have to look more into it.

Sounds good. I appreciate the effort and suggestion.

I think I have a solution in #3386, essentially just pipe all the console logging back to the thread and allow use to swap out the log handler that way.
I tried it on your branch, but its only showing the running node. (I was running the GCD example with the dashboard enabled). (I see why)

To test to, modify the cli dashboard set logger code:

        if logger:
            self.__logger = logger
            self.__log_handler = LogBufferHandler(event=self.__render_event)
            # Hijack the console
            self.__logger.removeHandler(self._chip.logger._console)
            self._chip.logger._console = self.__log_handler
            self.__logger.addHandler(self.__log_handler)

To keep it simple, I push the changes to https://github.com/siliconcompiler/siliconcompiler/tree/cli_dashboard

Awesome. That works nicely! Thanks for looking into it.

There are still some messages coming from the core.py::_add_input_output. To get around those the user will need to register the dashboard before registering any inputs.

So there are two this pending:

• Testing
• Multi-job support

I'll work on testing, but I don't know where to start with the multi job. I guess we need make the CliDashboard a singleton and then let the chip register itself to the dashboard? Or what would be the best approach here?

I think focusing on getting the testing done and then getting this in as a PR. Once this is working and tested, then I think the multijob support can be considers (you are correct about the need for a singleton of some kind, but I think it will be easier to figure out properly in a separate PR).

I just pushed some tests on my branch. That should cover the important aspects of the dashboard. Let me know if there is something you think should be added.

There is one small annoying thing with rich that I need to figure out. After running the application it doesn't restore the terminal settings. So I probably need to save the terminal state and restore it. But I need to look more into it.

@Ciprian167 I have an initial "version" of getting the dashboard to handle multiple jobs with a singleton, it needs some cleanup before it's ready for testing, but that shouldn't take too long (probably later this week).

To fix that, you can remove the extra padding for the job board.

<<<         return Group(Padding("", (0, 0)), table, Padding("", (0, 0)))


>>>         return Group(table, Padding("", (0, 0)))

In the case of no-header, should the Padding be preserved?

I'm fine with both. If it make things easier to test, we can drop it.

One other thing I'm not sure about is clearing the console before we start the live.

            self._console.clear()
            live.start()

That is a bit invasive on the terminal. At least I see some weird behavior. Like after everythin is done, I can't scroll up to see what was previously run in the terminal. But maybe that's terminal dependent. I'm experiencing that in the VSCode terminal.

@Ciprian167 I added that to get around some issues I noticed, but now that the console rendering is working better, they are not needed.

Thank you for making it work. I really appreciate it.

@Ciprian167 thats great to hear. I got a draft of this working, but it's fairly ugly at the moment, so I suspect I'll have something for a PR later this week.

Always one step ahead. Thanks. Let me know if I can help.

I have the PR here: #3478
Could you please try it out and see that it works. If the dashboard is activated after a call in multiprocessing.Process then it's a completely separate python instance and I haven't solved the singleton in that case (FYI), but since my plan is to initialize the cli dashboard automatically (later) then that won't be an issue.