Automatically Updating Interfaces

[cgbsu]

Let me start out by saying this is amazing! I was listening to cppcast when I heard about this project. I'm in crunch time for a project and it would at least be way harder (or not get done) without this project. Awesome job! Your a life saver! Before this I was just trying to parse the output of make with clang format and reading it in the vscodium editor, but sometimes it was tens of thousands of lines long.

I wanted to know if you may plan on separating the core code from the GUI so it could be used in other places?

Also to avoid copy/pasting some much, one idea that comes to mind is to use a server where you can pipe the output of build commands/scripts and have it automatically update the error log in browser (probably the easiest way to do it).

You mentioned in your video that you don't have much GUI experience, but would you consider of this to a command line utility via FTXUI similar too fx (this could be achieved by separating out the core code-base into its own library)?

[jake-arkinstall]

Thank you so much for the kind words! I had several updates to the project in the pipeline but my free time has somewhat vanished, and seeing comments like this make me desparate to get back onto it!

I think separating concerns as you suggest would be a fantastic idea. A backend producing JSON output and the frontend providing a view on it would be a very reasonable next step, and this also opens the door to handling multiple forms of input.

Since releasing this, I have been shown fdiagnostics-format=json which would not only form a great input, forms a fantastic example of how the compiler thinks the output should be structured (which is ultimately better than I do it at present, but gives me something to aim for).

As for allowing error piping, that would be a great addition. I think this issue establishes that there are three main concerns that should be more separated than they are - and they're the three main concerns in any program: input, processing, and output.

I definitely want to keep the option of pasting the error to a website because it keeps things simple for average joe who already has the error and just wants to resolve it (for me, that's usually "the build server failed to compile this project after 30 minutes, here's the log") but piping is another great usecase. Another one might even be a godbolt link.

For output, a TUI might be nice. I like it. It wouldn't be my first rodeo with them (and I've been looking for a good excuse to learn FTXUI so... I think you have found me one) but I do want to ensure that it isn't a path users are forced into (a good example is GDB TUI mode - absolutely incredible to use when you know how, but it isn't used anywhere near as much as it should be, possibly because it's scary to newcomers).

For processing... That's an interesting one. Piping to a TUI would probably involve dropping the javascript processing, but dropping the javascript processing would drop the "client only" side of the existing frontend. So this all points to a technology that I have no experience in yet: node.js. An interesting prospect - what do you think?

(Sorry about closing/unclosing - it was unintentional)