Changing Terminal emulator

[dcihon]

I wanted it to use alacritty.
Chaning the Exec line worked but it also ran konsole and alacritty. i am using Plasma 6

[Antiz96]

Hi,

Thanks for the ticket.

What do you mean "it worked but also ran konsole and alacritty"?

The way to force arch-update to use a specific terminal emulator is described here. Have you followed those instructions?

[Antiz96]

I think I was able to understand and reproduce the issue in a test environment. Indeed, when I change the Exec line in the desktop file to use alacritty, it opens both alacritty and also a konsole window that shows some errors:

However I tried using xfce4-terminal instead of alacritty and everything worked as expected (with no konsole window opening).
In fact, if you try to open an alacritty window from alacritty itself, you will face the same issue:

This is most likely an alacritty and / or a driver issue (e.g. mesa), but definitely not an issue with Arch-Update.
Assuming this is indeed the problem you're facing, there's nothing I can do about it at my level 😕

[leyyce]

I also had the same problem with kitty, so it's definitely not an alacritty exclusive issue. If it is a driver issue, I can not say.

What I can say though, is that I've found a workaround for the problem. In GLib/gio there are hardcoded terminal emulators that the code is looking for and the order they are defined in kind of gives them a precedence over each other. So when you want to run another terminal emulator instead of Konsole, you just have to symlink the terminal you want to use to one of the other ones that are defined above Konsole in this list. The list defines the executable names of the terminal emulators the code is looking for, alongside the flag it needs to run another command upon launching.

Because the syntax to run another program with kitty is simply kitty <command>, I just symlinked the kitty executable to xdg-terminal-exec, which also doesn't need another flag. As far as I know, to do this with alacritty you would run alcritty -e <command>, so for alacritty you should choose something from the list that also needs an -e flag. The one with the highest precedence here would be kgx.

So to run arch-update with alacritty instead of Konsole, you could simply create a symlink named kgx pointing to the alacritty executable like so

ln -s /usr/bin/alacritty /usr/bin/kgx

Edit: I also think that the info in the readme with using "xterm" is kind of wrong, or at least doesn't work in some cases, because it takes the least precedence of all the terminal emulators defined in the list linked above. If you for example have Konsole installed and create the xterm symlink, it will still use Konsole, as that has a higher position in the list.

[Antiz96]

Hi @leyyce, thanks for the details!

I also think that the info in the readme with using "xterm" is kind of wrong, or at least doesn't work in some cases [...]

This assume that you don't have any other terminal emulators than e.g. alacritty installed (or at least that you don't have any other terminal emulators present in the list of gio known terminals), indeed.

I will enhance the documentation with your findings and / or link to your comment in it :)

[leyyce]

After looking into this further, I think the "correct" way to approach this would be to actually install xdg-terminal-exec and to set it up correctly according to the info provided in the projects README.

I'll try this out when I find the time and report back here. Might add a tutorial section to the readme according to my findings if you want me to 🙂

[Antiz96]

After looking into this further, I think the "correct" way to approach this would be to actually install xdg-terminal-exec and to set it up correctly according to the info provided in the projects README.

I'll try this out when I find the time and report back here. Might add a tutorial section to the readme according to my findings if you want me to 🙂

I've already studied that route in the past, but currently this xdg-terminal-exec specification is only a proposal that is not officially supported by gio (yet?). See the related MR / discussion (opened 5 years ago 🫤) at https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/3.

I'd rather not document it until it is actually merged / supported.

[leyyce]

I've already studied that route in the past, but currently this xdg-terminal-exec specification is only a proposal that is not officially supported by gio (yet?). See the related MR / discussion (opened 5 years ago 🫤) at https://gitlab.freedesktop.org/terminal-wg/specifications/-/merge_requests/3.

I'd rather not document it until it is actually merged / supported.

As far as I understood it, it's a proposal that's not officially integrated into the freedesktop.org specifications (yet), but it's kind of already (unofficially) supported by GLib as a bandaid solution (evident by xdg-terminal-exec even being present in the known-terminal list with the highest priority of all the included terminals) until they either accept the proposal or come up with something else. And seeing the pull request for xdg-terminal-exec already being 5 years old, I don't see either of those happening any time soon. So imo it could just as well be included here as a intermediate solution.

To be real, neither this, nor symlinking a terminal emulator executable to the place where another terminal emulator is actually expected to reside is a clean or "officially supported" solution, but imo using a specification that was specifically proposed to handle situations like this and can actually be configured (even without root rights and on a per user basis) instead of manually creating a random symlink is the saner and cleaner choice, wouldn't you agree?

Anyway, that's just my two cents 😄

[Antiz96]

And seeing the pull request for xdg-terminal-exec already being 5 years old, I don't see either of those happening any time soon. So imo it could just as well be included here as a intermediate solution.

In fact, the discussion on the MR is still ongoing and some commits / comments have been made recently (respectively 2 and 1 month ago), so I still have hope that this gets merged & officially supported at some point.

To be real, neither this, nor symlinking a terminal emulator executable to the place where another terminal emulator is actually expected to reside is a clean or "officially supported" solution

I admit I'm not so happy with the symlink workaround either, that's definitely not a clean solution indeed.

but imo using a specification that was specifically proposed to handle situations like this and can actually be configured (even without root rights and on a per user basis) instead of manually creating a random symlink is the saner and cleaner choice, wouldn't you agree?

Fair enough. If you're still down to experiment with this a bit and report your findings (or even make a modification proposal for the related section in the README via a pull request, if you feel like it), that would be really appreciated! 🙏

Hopefully that can be documented in a short, simple & intelligible enough way though.
While I'm totally fine documenting such workarounds, it's fair to say that this is a gio issue that isn't directly related nor specific to Arch-Update. Any other ".desktop" file launching a terminal based application (e.g. the htop one) would produce the exact same behavior. As such, we would ideally avoid writing an exhaustive full-on "tutorial" that would clutter the documentation 😅

[Antiz96]

@leyyce 👋

Sorry to ping... Just wanted to ask if you're still interested to experiment a bit with xdg-terminal-exec & report your findings here or in a PR?
No urgency at all, it's just to know if you're still up for this or if I should plan that on my side :)

Also, happy holidays if you have some :)

[leyyce]

Hi @Antiz96 ,

I'm basically still up for it, I just have to find the time 😄 I'm tied up in two projects for my bachelor's degree that take up a lot of my time right now, but I'm still set on doing this. I'll try to work on it as soon as I can.

Also wishing you happy holidays :)

[Antiz96]

I'm basically still up for it, I just have to find the time 😄 I'm tied up in two projects for my bachelor's degree that take up a lot of my time right now, but I'm still set on doing this. I'll try to work on it as soon as I can.

Sure, no problem.
As I said, no urgency. It was just to know 🙂

Good luck for your bachelor's projects 😉