Make terminal emulator binary overridable using Xresources

[sliedes]

This change makes the terminal emulator configurable using the Xresource i3-wm.terminal.binary instead of hardcoding it to /usr/bin/st. The default is still /usr/bin/st.

[gardotd426]

Well, there are a few issues with this PR, both on philosophical grounds and on technical grounds.

First and foremost, regarding the technical issues, this PR isn't functional. At least it shouldn't be. The patch is bad. See, your patch removes the x-terminal-emulator line, but there is no such line because that line has already been edited in the PKGBUILD:

sed -i 's/x-terminal-emulator/st/g' "${pkgdir}"/etc/regolith/i3/config

This was obviously done because Arch doesn't use x-terminal-emulator as an alias or whatever it's called, that's a Debuntu thing. So in Arch x-terminal-emulator is meaningless, so that had to be modified. Which leads to the philosophical issue:

While this project started out as a one-man community volunteer project because I saw people begging Ken (the Regolith creator) to make Regolith DE available for Arch and I thought "well I can do that," and did it (despite the fact that I don't even use i3 or Regolith myself, but I believe desktop environments should be cross platform), and it was completely unofficial with nothing from upstream other than Ken's encouragement, things have changed, and now this is at minimum the semi-official Regolith-DE-on-Arch project. Ken made me a member of Regolith, I have administrative privileges on Regolith repositories, and am one of the main people consulting Ken on making Regolith more distro-agnostic. So this is basically "unofficially official." Which means I intend to keep the Regolith DE experience as close to upstream as possible. I've only patched files to fix compatibility issues created due to being on Arch instead of Ubuntu.

Making unnecessary changes to Regolith files is something that I am not really willing to do. That said, "unnecessary" isn't black and white. But in this situation, I'm wondering why it needs to be changed at all. The terminal binary is already overridable. You simply have to change the terminal in your user's Regolith i3 config (in ~/.config/regolith/i3/config), and that overrides anything in the default.

Because Arch doesn't use x-terminal-emulator, I had to choose a specific terminal to have set as the default. Because Regolith offers a patched st build, and st is minimal and likely to create controversy (the only other option would have been gnome-terminal, which Regolith also has direct support for), I chose st.

I'm not denying this PR because I'm not completely opposed to it. Maybe we can think of a better way to go about it, I don't know. Maybe if you could explain to me why the current standard method of changing terminals (editing the config) isn't sufficient, that might help me make a decision.

[sliedes]

Well, there are a few issues with this PR, both on philosophical grounds and on technical grounds.

First and foremost, regarding the technical issues, this PR isn't functional. At least it shouldn't be. The patch is bad. See, your patch removes the x-terminal-emulator line, but there is no such line because that line has already been edited in the PKGBUILD:

sed -i 's/x-terminal-emulator/st/g' "${pkgdir}"/etc/regolith/i3/config

This was obviously done because Arch doesn't use x-terminal-emulator as an alias or whatever it's called, that's a Debuntu thing. So in Arch x-terminal-emulator is meaningless, so that had to be modified. Which leads to the philosophical issue:

Yes. My patch also removes this line from the PKGBUILD, if you look closely.

While this project started out as a one-man community volunteer project because I saw people begging Ken (the Regolith creator) to make Regolith DE available for Arch and I thought "well I can do that," and did it (despite the fact that I don't even use i3 or Regolith myself, but I believe desktop environments should be cross platform), and it was completely unofficial with nothing from upstream other than Ken's encouragement, things have changed, and now this is at minimum the semi-official Regolith-DE-on-Arch project. Ken made me a member of Regolith, I have administrative privileges on Regolith repositories, and am one of the main people consulting Ken on making Regolith more distro-agnostic. So this is basically "unofficially official." Which means I intend to keep the Regolith DE experience as close to upstream as possible. I've only patched files to fix compatibility issues created due to being on Arch instead of Ubuntu.

Making unnecessary changes to Regolith files is something that I am not really willing to do. That said, "unnecessary" isn't black and white. But in this situation, I'm wondering why it needs to be changed at all. The terminal binary is already overridable. You simply have to change the terminal in your user's Regolith i3 config (in ~/.config/regolith/i3/config), and that overrides anything in the default.

Thanks for the background. I appreciate it and your packaging efforts.

Correct me if I'm wrong here (as I'm completely new to Regolith), but it was my impression that having a ~/.config/regolith/i3/config not only overrides the changed settings in /etc/regolith/i3/config, but causes that file to not be used at all. That is all good until a new version of regolith has an updated config file, which causes these to get out of sync in a way that needs a manual merge.

I believe this is in fact the entire motivation for using Xresources. There's a comment explaining this in the config file:

# This configuration file utilizes Xresource variables to change configuration
# without having to make a copy of this config file.
# The benefit to not copying this file is easier upgrades in the future.
# To update a value in this config without making a copy, update the Xresource
# value in the file ~/.config/regolith/Xresources.

Thus, I'd say it's definitely in the spirit of this to have the terminal as an Xresource, especially since you have to change this line in the config file anyway to make things work under Arch.

I would have rather proposed this change upstream, but since the upstream at least seems to only target Debian-based distributions which have the alternatives system, I thought it might not be well received. But if the upstream is not against enabling more distro support there, I'd argue it would make more sense to make this change there (i.e. have this resource, defaulting to /usr/bin/x-terminal-emulator).

Because Arch doesn't use x-terminal-emulator, I had to choose a specific terminal to have set as the default. Because Regolith offers a patched st build, and st is minimal and likely to create controversy (the only other option would have been gnome-terminal, which Regolith also has direct support for), I chose st.

I'm not denying this PR because I'm not completely opposed to it. Maybe we can think of a better way to go about it, I don't know. Maybe if you could explain to me why the current standard method of changing terminals (editing the config) isn't sufficient, that might help me make a decision.

Sorry for not explaining it to begin with. I take pride in trying to make good bug reports and pull requests etc. This is already the second one to you that I consider below my standards. Hope I made my motivation now more clear!

[gardotd426]

Well, the problem is that Regolith 2.0 is in heavy development right now, no more changes are going to be accepted into 1.6, Ken has made that very clear, unless they are complete system-breaking bugs. And I'll have to check with Ken, but I know for sure that Regolith is moving away from Rofi for 2.0, and I believe they might be moving away from Xresources in large part. I don't recall completely but I will check later this evening and get back to you on that (I have some family business to take care of for the next few hours so I'm unable to do it this second). I'm already swamped in trying to help Ken with moving Regolith to a more distro-agnostic approach while also preparing the PKGBUILD from the move to Regolith 2.0. 2.0 is almost a complete reimplementation, on the level of GNOME 3.38 to GNOME 40, but even more so.

I'm a little scatterbrained with everything going on, so please excuse me if I'm derping out right now, but I'm a bit confused still on the point of this or how it would even work. See, I understand that your PR replaces the defaulting of st in the config file and instead sets it to the default through the set-from-resource functionality of i3+Xresources. I get that. But the problem is, that would be overwritten on every regolith-look change. What I mean is, Regolith uses ~/.Xresources-regolith, but all it does is point to /etc/regolith/styles/<style>/root, which then contains #includes for the other files in that styles directory. So if you added a terminal to ~/.Xresources-regolith, it would be removed every time you run regolith-look set <style> followed by regolith-look refresh.

Or are you suggesting setting it in the regular ~/.Xresources file? Because that would make way more sense, and Regolith does indeed read both ~/.Xresources and ~/.Xresources-regolith. I believe I've answered my own question, so only correct me if that's wrong.

Correct me if I'm wrong here (as I'm completely new to Regolith), but it was my impression that having a ~/.config/regolith/i3/config not only overrides the changed settings in /etc/regolith/i3/config, but causes that file to not be used at all. That is all good until a new version of regolith has an updated config file, which causes these to get out of sync in a way that needs a manual merge.

I'm not quite sure what you're asking here (and that may be my fault). But Regolith encourages users to have a ~/.config/regolith/i3/config. It's literally part of the documentation and it's what regolith-look stage does. It's kind of required to use regolith-look at all, really. regolith-look stage creates ~/.Xresources-regolith and ~/.config/regolith/i3/config. So I mean, ~/.config/regolith/i3/config is supposed to exist, just like /.config/i3/config is supposed to exist and is what the user is supposed to use for their configuration changes.

I'm confused on what you mean when you talk about changes to the /etc/regolith/i3/config file requiring a manual merge. Regolith will always use ~/.config/regolith/i3/config, as long as it is present.

Again, I'm not opposed to this PR on principle. I'd like some more clarification, I'd like to check and see what Ken's plans are with 2.0 and Xresources, but I'm inclined to just accept this PR in the meantime and just revert it or remove it when necessary, I'm just not quite there yet. But do know that I am inclined to just go ahead, but like I said I have some stuff going on I need to take care of and don't really have the capacity for the mental and emotional labor that this issue requires right this minute, but don't be surprised if I accept the PR this evening or in the next day or two. But I would like some clarifications on the questions I ask above if you don't mind, just for posterity.

[sliedes]

Well, the problem is that Regolith 2.0 is in heavy development right now, no more changes are going to be accepted into 1.6, Ken has made that very clear, unless they are complete system-breaking bugs. And I'll have to check with Ken, but I know for sure that Regolith is moving away from Rofi for 2.0, and I believe they might be moving away from Xresources in large part. I don't recall completely but I will check later this evening and get back to you on that (I have some family business to take care of for the next few hours so I'm unable to do it this second). I'm already swamped in trying to help Ken with moving Regolith to a more distro-agnostic approach while also preparing the PKGBUILD from the move to Regolith 2.0. 2.0 is almost a complete reimplementation, on the level of GNOME 3.38 to GNOME 40, but even more so.

Fair enough. I wasn't at all aware of Regolith 2.0; I had probably tried out Regolith for 2-3 days at the point I made this PR. I don't know why they're moving out from Xresources, but I can understand it; it had immediately this feeling of being a bit of a hack :)

I'm a little scatterbrained with everything going on, so please excuse me if I'm derping out right now, but I'm a bit confused still on the point of this or how it would even work. See, I understand that your PR replaces the defaulting of st in the config file and instead sets it to the default through the set-from-resource functionality of i3+Xresources. I get that. But the problem is, that would be overwritten on every regolith-look change. What I mean is, Regolith uses ~/.Xresources-regolith, but all it does is point to /etc/regolith/styles/<style>/root, which then contains #includes for the other files in that styles directory. So if you added a terminal to ~/.Xresources-regolith, it would be removed every time you run regolith-look set <style> followed by regolith-look refresh.

Or are you suggesting setting it in the regular ~/.Xresources file? Because that would make way more sense, and Regolith does indeed read both ~/.Xresources and ~/.Xresources-regolith. I believe I've answered my own question, so only correct me if that's wrong.

Yeah, or ~/.config/regolith/Xresources. That's how I do it. Here's what I currently have in my ~/.config/regolith/Xresources:

#include "/etc/regolith/styles/ubuntu/root"

gnome.gtk.theme: Adwaita
gnome.wm.theme: Adwaita
rofi.theme: /home/sliedes/.local/share/rofi/themes/spotlight.rasi
i3-wm.client.focused.color.child_border: #ff0000
i3-wm.client.focused.color.indicator: #00ff00
i3-wm.window.border.size: 3
i3-wm.floatingwindow.border.size: 3
i3-wm.gaps.inner.size: 0
gnome.terminal.font: DejaVu Sans Mono 11
i3-wm.terminal.binary: /usr/bin/gnome-terminal

I'm not quite sure what you're asking here (and that may be my fault). But Regolith encourages users to have a ~/.config/regolith/i3/config. It's literally part of the documentation and it's what regolith-look stage does. It's kind of required to use regolith-look at all, really. regolith-look stage creates ~/.Xresources-regolith and ~/.config/regolith/i3/config. So I mean, ~/.config/regolith/i3/config is supposed to exist, just like /.config/i3/config is supposed to exist and is what the user is supposed to use for their configuration changes.

I don't have a ~/.config/regolith/i3/config, and I can override most of the settings in /etc/regolith/i3/config by using Xresources. I understand this is exactly the intent of the Xresources thing in Regolith.

So the way I understood the comment I quoted in /etc/regolith/i3/config:

# This configuration file utilizes Xresource variables to change configuration
# without having to make a copy of this config file.
# The benefit to not copying this file is easier upgrades in the future.
# To update a value in this config without making a copy, update the Xresource
# value in the file ~/.config/regolith/Xresources.

is that the problem with copying this file to ~/.config/regolith/i3/config is that package updates to the file in /etc no longer have an effect on your config ("The benefit to not copying this file is easier upgrades in the future"), and that it does not encourage people to have ~/.config/regolith/i3/config. By not copying it and overriding individual settings in Xresources, you effectively have better granularity in overriding configuration.

I'm confused on what you mean when you talk about changes to the /etc/regolith/i3/config file requiring a manual merge. Regolith will always use ~/.config/regolith/i3/config, as long as it is present.

Yes. I believe the solution is to not have it present. Only that way you can have both these true at the same time:

1. Your modified settings (in the Xresources file) take effect.
2. Updates to the regolith packages that contain updates to /etc/regolith/i3/config cause those configuration changes to take effect, unless those specific variables are overridden in the Xresources.

Again, I'm not opposed to this PR on principle. I'd like some more clarification, I'd like to check and see what Ken's plans are with 2.0 and Xresources, but I'm inclined to just accept this PR in the meantime and just revert it or remove it when necessary, I'm just not quite there yet. But do know that I am inclined to just go ahead, but like I said I have some stuff going on I need to take care of and don't really have the capacity for the mental and emotional labor that this issue requires right this minute, but don't be surprised if I accept the PR this evening or in the next day or two. But I would like some clarifications on the questions I ask above if you don't mind, just for posterity.

Fair enough, and thanks for your time. :)