Add brand new "gnome console" terminal

[Poyoman39]

This is the new default terminal for gnome users

Fixes #104

[CLAassistant]

All committers have signed the CLA.

[pimterry]

Thanks @Poyoman39! Reporting this is super helpful, I wasn't aware that Gnome had added a new default terminal.

In theory this fix is fine, and it will work in many cases, but in practice it's a little more complicated. I've just tested and it looks like (just like Gnome Terminal) kgx uses a single shared process for all terminals. That means that if it's already open, running kgx will just open a new window in the same process and then exit, instead of starting another independent app.

That's a problem, because HTTP Toolkit needs to set the env vars for the launched process, and that won't happen if this just opens a new window for an existing non-intercepted process... If you're already running kgx elsewhere, and then you try to launch an intercepted terminal via HTTP Toolkit like this, it will just open another non-intercepted window for your existing terminal, which is not a great result.

Does that make sense?

In gnome terminal, we solve this using the --wait argument, which forces it to actually run a separate process (see getGnomeTerminalCommand in this same file). Unfortunately, on my machine at least it seems that this is still a WIP for kgx (--help shows (TODO) next to it), and so presumably they're going to support this but it doesn't quite work yet. You could get in touch with the kgx team about supporting that in future to help move this forward.

One other fallback option is to set a DBUS_SESSION_BUS_ADDRESS= env var when launching the app. This ensures it can't communicate with other already running apps, and so guarantees it'll always launch a new terminal. Unfortunately though, it'll also propagate into the launched terminal too, so that might mean some apps run within kgx (anything that uses DBUS) behave weirdly. Probably not a big problem, and so this is usable as a fallback, but I'd definitely prefer to use --wait as we do with gnome terminal once it's available.

What do you think? Can you reproduce the issue? Do you want to extend this to try unsetting DBUS_SESSION_BUS_ADDRESS and see if that works as a reasonable fallback?

[Poyoman39]

Hi @pimterry thank you for your answer. I think you are more expert than i am with those terminals problems ^^

• I can confirm the wait option is in "TODO" on my distribution too (v 45.0)
• From tests i made i think this is possible to have independent environment variables using the "-e" argument of kgx. This way : kgx -e 'SOMEVAR=hello zsh' (change zsh with your shell ^^)
• I can confirm SOMEVAR=hello kgx opens a terminal ignoring the env variable ^^

I think since the --wait would fix the issue and will be developed by gnome team, this could wait for their development ^^. If we want to make a workaround without waiting for this development i guess it's possible to exploit the "-e" option.

What do you think ? :)

[pimterry]

From tests i made i think this is possible to have independent environment variables using the "-e" argument of kgx. This way : `kgx -e 'SOMEVAR=hello zsh' (change zsh with your shell ^^)

Ah, in fact it's actually easier than that.

You can think of env vars as an inherited property, so by default a kgx process is launched with HTTP Toolkit's env vars, and then every process it launches inherits those in turn, but at any step you can modify the variables as they're passed down. In your test, using -e to set SOMEVAR means that kgx itself launches without the variable, but then it sets the variable for zsh when that launches, and then every child beyond that point (everything run inside your zsh) does see it. Does that make sense?

That means we can directly set the env var when actually launching kgx itself, without passing it as an option or anything. All terminals are actually spawned here - we run the detected command (command), with any detected arguments we'll need (args), and then set a whole bunch of env vars already (currentEnv and getTerminalEnvVars(...) - this is how HTTP Toolkit's config is injected). We just need to add another set of env vars here too. All vars here are received by the terminal itself when it starts.

So, to make this work, I think we need to:

• Make getTerminalCommand optionally return an envVars argument
• Extend your changes to create a getKgxCommand which returns something like { command, envVars: { 'DBUS_SESSION_BUS_ADDRESS': '' } }
• Use that getKgxCommand for commandExists('kgx') but also if kgx is found as the default terminal value elsewhere (e.g. look at where getGnomeTerminal is used and do the same)
• Modify the spawn() call later, so if any env vars are required for the terminal, it includes them when launching

[Poyoman39]

Hi @pimterry thank you for your detailed answer. I will try to implement it in my PR ^^

[Poyoman39]

I finally found some time to update my PR ... I'm not a typescript expert I guess you will want i edit it a bit :D

[pimterry]

Thanks @Poyoman39! This looks good.

I've fixed the TypeScript issue, the problem was just that envVars needs to be an optional field (because only the KGX functions return it - the others can still skip it) so you just needed a ? there.

I've done some testing, and I ran into some issues when kgx was used via the x-terminal-emulator symlink (which distros like Debian use to allow configuration of the preferred terminal). I've fixed that now, extending that detection a bit to spot kgx. Can you update your local branch, and check the current version here with all those changes works for you?

The build is failing right now because of an unrelated issue where it looks like the Chrome APT repo we used has updated its keys or something - I'll fix that now elsewhere, but don't worry about it here.

[Poyoman39]

Hi @pimterry thank you for the detailed review :) I'm afraid i've no idea how to test this code ^^ i've started the server and it does not bug, but i'm a bit lost how to interact with it ^^

[pimterry]

To test locally, you just need to run the server (nom install, npm start) and then open app httptoolkit.tech in a browser (but not Safari, doesn't work there annoyingly). That's the production version of the UI. It should load up and let you use it just like normal HTTP Toolkit.

In this case, if kgx is configured as your default terminal, it should launch that when you click 'Fresh Terminal', and it definitely shouldn't do anything else weird (like launching termina unexpectedly during startup).

[Poyoman39]

Tank you for your fast answer ^^ I think i have problems with a port conflit Should i specify a port when starting the server or the ui ?

[pimterry]

Ah, no, that means something is already using the port. You need to stop the other thing. It's probably HTTP Toolkit itself, or window where you're already running the server. Only one HTTP Toolkit server can run at a time on your computer.

[Poyoman39]

@pimterry ... fun fact, it looks gnome team is gonna add again a new one :sweat_smile: https://www.phoronix.com/news/GNOME-Terminal-Prompt

[pimterry]

fun fact, it looks gnome team is gonna add again a new one

Haha uh oh 😅. Sounds like that's a new project though, so at least it probably won't be default or widely used for a while! PRs to add support for that too are welcome though :smile:.

In the meantime, did you have a chance to test the changes on this branch, and check they work for you?

[Poyoman39]

Sry i'm a bit busy at work right now, but i don't forget this PR i will treat it ^^

[Poyoman39]

Hi @pimterry, i finally found some time to .... read the doc :D ... Easier to make it start then ^^

I can confirm that this PR works at least on my machine

I tested with "fresh terminal" button.

Thank you for your patience :pray: i can do some more tests if you want to :)

[pimterry]

Thanks @Poyoman39! Now rebased to get the tests green, and merged :+1:. I'm not going to rush this out immediately, but it'll be included in the next HTTP Toolkit update very soon, watch this space :smile:.

In case you're not aware - HTTP Toolkit Pro is free for all contributors. If that'd be useful, just send me an email at tim @ httptoolkit.com and let me know the email to use for your account, and I'll set it up. Thanks for contributing!

[Poyoman39]

Hi @pimterry such a good surprise !!! :star_struck: i would be really interested to get an access to pro account and it would be a really good motivation to add any additional terminals that gnome teams is producing :D Gonna send you an email ;)