Method of opening UI is awkard

[awsdert]

I'd rather gdbfrontend open it's own window with the webpage embedded in it instead of manually opening a web tab, even with the control & click of the terminal it is still awkward, for instance what if I want to run gdbfrontend from Geany's terminal? I won't be able to click the link there I expect, much easier if it just auto opens a window with the URL already loaded, also makes it easier to end the debug session if it just ends with the window, otherwise the UI seems like a good substitute for gede which is currently not downloading from AUR for me

[rohanrhu]

Thank you for your suggestion. I'm planning a standalone window mode with v1.0. You can look Radmap of v1.0. I will do all of my ideas and your suggestions when I come back from military.

[rohanrhu]

I've added the feature. It opens GDBFrontend on the browser automatically on startup. Also it will open too from WSL. Thank you for your feedback.

[awsdert]

Just tried it, certainly better than before but I did say in it's OWN window, didn't mean just open a tab for it directly, the reason I say own window is because it would be useful to make the window small so that it can hover over my text editor, be more ideal to have a plugin for Geany that handles it but I doubt you're gonna put int the effort to create and maintain a plugin for specific app, might eventually try myself but I got bigger priorities

Edit: Found this resource, may take a little effort to create the wrapper binary but once done that should be all you need to do to ensure the front end always opens in it's own window.

https://www-archive.mozilla.org/unix/gtk-embedding.html

[rohanrhu]

Just tried it, certainly better than before but I did say in it's OWN window, didn't mean just open a tab for it directly, the reason I say own window is because it would be useful to make the window small so that it can hover over my text editor, be more ideal to have a plugin for Geany that handles it but I doubt you're gonna put int the effort to create and maintain a plugin for specific app, might eventually try myself but I got bigger priorities

Edit: Found this resource, may take a little effort to create the wrapper binary but once done that should be all you need to do to ensure the front end always opens in it's own window.

https://www-archive.mozilla.org/unix/gtk-embedding.html

Standalone window mode is a TODO for now. You can create a shortcut for GDBFrontend as a Chrome App window.

You should check "Open as window".

[rohanrhu]

Another better way running as a real Chrome application from command line.

It is like this for me:

"c:\Program Files\Google\Chrome\Application\chrome.exe" --app="http://127.0.0.1:5550/terminal"

With this way you will not see address bars on additional windows. You can simply create a startup shortcut/script that suits your requirements.

• Start GDBFrontend gdbfrontend
• Open UI as Chrome app chrome --app="http://127.0.0.1:5550/terminal"

But for now, GDBFrontend opens its URL for startup, I will add an option for GDBFrontend to not open its URL on startup. It will be useful for this use case.

[awsdert]

Was about to post this when your next message showed up.

It's not the shortcut I need, opening from command line works fine but it just hooks into existing browser window for itself, oh side not I tried launching with the argument that's supposed to forward a string to gdb as it's launched but that didn't work, I had to manually attach to my binary.

I don't use chrome because it's produced by a company that harvests more data than it should, since this is meant for a primarily linux based debugger it should be designed for the de-facto browser on linux, firefox (which is what I'm using)

[rohanrhu]

Was about to post this when your next message showed up.

It's not the shortcut I need, opening from command line works fine but it just hooks into existing browser window for itself, oh side not I tried launching with the argument that's supposed to forward a string to gdb as it's launched but that didn't work, I had to manually attach to my binary.

I don't use chrome because it's produced by a company that harvests more data than it should, since this is meant for a primarily linux based debugger it should be designed for the de-facto browser on linux, firefox (which is what I'm using)

What do you mean with?

I tried launching with the argument that's supposed to forward a string to gdb as it's launched but that didn't work, I had to manually attach to my binary.

Maybe something similar to Chrome apps in Firefox. I will take a look.

[awsdert]

What do you mean with?

I tried launching with the argument that's supposed to forward a string to gdb as it's launched but that didn't work, I had to manually attach to my binary.

I mean I have this in my makefile:

gdbfrontend: debug
    gdbfrontend -G "-ex run --args ./$(debug_program) $(ARGS)"

[rohanrhu]

What do you mean with?

I tried launching with the argument that's supposed to forward a string to gdb as it's launched but that didn't work, I had to manually attach to my binary.

I mean I have this in my makefile:

gdbfrontend: debug
  gdbfrontend -G "-ex run --args ./$(debug_program) $(ARGS)"

Ah.. got it. I can do it like this:

[rohanrhu]

Seems like you are not loading your executable.

Your command should be like this

gdbfrontend --workdir="PROJECT_PATH" -G "-ex \"file ./EXECUTABLE\" -ex \"run\ ARGS\""

[awsdert]

Nope:

gdbfrontend: debug
    gdbfrontend --workdir="$(CWD)" -p 0 -t gf1 -G "-ex \"file ./$(debug_program)\" -ex \"run --args ./$(debug_program) $(ARGS)\""

Still doesn't work out

[rohanrhu]

Nope:

gdbfrontend: debug
  gdbfrontend --workdir="$(CWD)" -p 0 -t gf1 -G "-ex \"file ./$(debug_program)\" -ex \"run --args ./$(debug_program) $(ARGS)\""

Still doesn't work out

Use -p PORT or -t TERMINAL_ID if you need random ports or different debugging sessions in same time only.

Can you check your paths? Also you may need \ for spaces like \.

gdbfrontend: debug
    gdbfrontend --workdir="$(CWD)" -G "-ex \"file ./$(debug_program)\" -ex \"run\ $(ARGS)\""

You may need to escape spaces for $(ARGS). Also can you send your make output to see the final command?

[awsdert]

well ARGS is current just equal to --engine-test (to enter the code path I intend to enter of my app), there's absolutely no need for it to be declared a string, anyways strings don't need spaces to be escaped, I'll do it anyways for the sake of a test run but I don't expect there to be any change

Edit: Btw why the "file" argument? I know my original should've worked because I have a separate rule for running just gdb when in a terminal (don't have a terminal when running via geany's "make custom..." command):

gdb: debug
    gdb -ex run --args ./$(debug_program) $(ARGS)

Edit 2: And nope, still didn't work, the make command is printed automatically in geany's compiler output box, gives this line when it does execute that rule gdbfrontend --workdir="/mnt/MEDIA/HOME/gitlab/dragonbuilder" -G "-ex\ \"file\ ./d.out\"\ -ex\ \"run\ --args\ ./d.out\ --engine-test\""

[rohanrhu]

well ARGS is current just equal to --engine-test (to enter the code path I intend to enter of my app), there's absolutely no need for it to be declared a string, anyways strings don't need spaces to be escaped, I'll do it anyways for the sake of a test run but I don't expect there to be any change

Edit: Btw why the "file" argument? I know my original should've worked because I have a separate rule for running just gdb when in a terminal (don't have a terminal when running via geany's "make custom..." command):

gdb: debug
  gdb -ex run --args ./$(debug_program) $(ARGS)

Edit 2: And nope, still didn't work, the make command is printed automatically in geany's compiler output box, gives this line when it does execute that rule gdbfrontend --workdir="/mnt/MEDIA/HOME/gitlab/dragonbuilder" -G "-ex\ \"file\ ./d.out\"\ -ex\ \"run\ --args\ ./d.out\ --engine-test\""

Must be a problem with escaping chars or paths.. Btw why you want to do this way?

You can load your executable and run it with F5 key on GDBFrontend. It will understand that when you rebuild your executable.

Also you can send run command to your GDB terminal

tmux send-keys -t gdb-frontend "run ARGS" ENTER

gdb-frontend is your terminal id here that you specify with GDBFrontend's -t TERMINAL_ID (which is gdb-frontend as default).

GDB will ask you "Do you want to re-run?" if your application is already running. In this case, you can disable prompts on GDB shell:

set confirm off

But I would suggest you to use ALT+ Tab and F5 to start debugging after build. It is very quick for me.

[awsdert]

You can load your executable and run it with F5 key on GDBFrontend

That's an extra step I shouldn't need in the first place, I'm already going to the effort of custom arguments for my program, why should I then have do extra commands when I should be able to do it automatically, normally I just rely on gede which does exactly as I expect it too but recently I've found that there are occasions when I can't install it (most recent was simply because I didn't know the search ignored AUR if it's not selected directly) so I've taken to adding custom targets for each GUI debugger I can find, this does also mean that other people debugging my code for leasure or because something happened to not work on their system will be able to pick their poison so to speak.

Edit: btw the rule for gede is so much simpler:

gede: debug
    gede --args ./$(debug_program) $(ARGS)

Might I suggest you take a leaf from gede and do likewise and just pass the command on internally, gdbfrontend is supposed to be just that a frontend, so instead of having to pass on the arguments via something like -G it would be better to just support all the options gdb does even if you just pass them on internally, you can always differentiate options for gdbfrontend with something like ---arg, the 3rd - indicating it's a custom option and not to be treated as a gdb option

[rohanrhu]

When you set args it will remember them: or when you send your GDB shell run command it would work on GDBFrontend.

This will run your application

tmux send-keys -t gdb-frontend "run ARGS" ENTER

but you should add this to your gdbfrontend command

gdbfrontend -ex "set confirm off"

If you still want to run debugger on each build from make, it is pretty possible like the example that I've sent, you just should make sure your gdbfrontend command's escape/meta chars which causes the issues.

[awsdert]

Tried both tmux send-keys -t 0 "run ./d.out --engine-test" ENTER and gdbfrontend tmux send-keys -t 0 "run ./d.out --engine-test" ENTER but neither did as expected, the first just exited immediately and the 2nd just gave me the usual result, a blank new instance with no app pre-selected

Edit: I'll mention this since you seem to be overlooking the concept or just ignoring it, a frontend is supposed to make things easier, more flexible, from my experience thus far gdbfrontend only accomplishes that AFTER the app is hooked, everything up to that point though has been made harder than it ever should've been.

[rohanrhu]

Btw I should note that if you want to run multiple GDBFrontend instances at same time, you must give a random id number to debugger's terminal and you must use random ports -p 0.

gdbfrontend -t "gf-$(awk 'BEGIN{srand();printf("%d", 65536*rand())}')" -p 0

Of course you can also make a counter for terminal identifier.

[awsdert]

Btw I should note that if you want to run multiple GDBFrontend instances at same time, you can give a random id number to debugger's terminal.

gdbfrontend -t "gf-$(awk 'BEGIN{srand();printf("%d", 65536*rand())}')" -p 0

That's nice to know but not how I currently use debuggers, I only run them on my local machine for programmes I've made personally, I run them from inside Geany so there's the need to close the current instance before I can start a new instance, speaking of which currently to start a new instance of gdbfrontend after the 1st one was run in Geany I have to shutdown Geany completely to make it let go of a dead hook because it can't detect a tab being closed, neither does it seem to understand that the instance is bound to the browser so even if I close the browser I still need to close down Geany, that's another reason to give gdbfrontend it's own dedicated window, because the current method interferes with GUI based workflow which is ironic given that it's supposed to ease GUI workflow.

Edit: Past midnight, I'm going to get some shut eye so if this conversation is gonna continue then it will do so tomorrow at the earliest

[rohanrhu]

Indeed, possibilities are much more than we've talked about. You can use GDBFrontend's WebSocket or HTTP API to runtime control from your IDE since its main focus is being "extensible and flexible".

You can make a request to /api/runtime/run in your Makefile.

curl http://127.0.0.1:5550/api/runtime/run

[awsdert]

tried it but I think I did the target wrong, either that or it just didn't work, can you show an example of the full target and rules starting with the gdbfrontend: debug

[rohanrhu]

tried it but I think I did the target wrong, either that or it just didn't work, can you show an example of the full target and rules starting with the gdbfrontend: debug

What is the problem exactly?

[awsdert]

As I stated before I need A. the window to appear in front of geany (like a dialogue box would) and B. for the target debug application to immediately start running, neither of which happen currently