search

mridoni / gix

An IDE and platform for GnuCOBOL, providing a native debugger, ESQL and HTTP REST services
GNU General Public License v3.0
31 stars 3 forks source link

FR Debugger (low-priority): TUI client for "remote" debugging #28

Open GitMensch opened 3 years ago

GitMensch commented 3 years ago

QT is nice (and heavy) but I guess it does allow to directly create TUI applications, does it? Even if not - could we have this as "long standing" issue to create one?

Reasoning:

mridoni commented 3 years ago

I get what you mean, but I think a better approach would be having a remote debugger "stub" allowing the IDE (or a compatible client, since the protocol at that point would be documented) on another machine to debug a remote process; something like the Visual Studio Debug Tools, where you run an executable on the remote machine that runs the process and communicates with the remote instance of Visual Studio used for debugging. Writing a TUI would imply a huge amount of code and that would not be really feasible.

While I do not have immediate plans to work on this, this is an interesting development and I agree we should leave it open here: in terms of workflow it actually has a couple of things in common with the whole "attach to running process" thing I will definitely work on sooner or later (I an deeply entrenched in some stuff with my day job at the moment, so I had to slow down the work on Gix-IDE).

GitMensch commented 3 years ago

I agree that it is more reasonable to have a remote debugger stub first, which allows to create additional debug clients, and then have a new minimal TUI connecting to that (either on the same machine or on another), instead of rewriting a complete TUI with the debugger integrated. If the remote stub is speedy enough (it would be good to allow both TCP/IP and pipes to connect with that) it would be possible to decouple that completely - so the IDE would not have any direct dependency on the debugging part any more - and both the QT GUI and whenever possibly later being available a TUI interface - would use the same technique to work with the remote stub.

As that most important main part is quite different from the TUI fronted I've created a new issue for that.