Update window title in terminal #120

New Issue

sloum · 2019-12-15T18:52:40Z

sloum commented

2019-12-15 18:52:40 +00:00

This one is maybe ill-advised maybe not. What I want to happen is that when a user launches bombadillo the window title (which would include tab title for tab aware applications) is changed to Bombadillo. This is very doable for all xterm based systems:

fmt.Print("33]0;Bombadillo07") # instead of 07 a could be used

That will set the title pretty effectively. I have tested this as working in both st and in gnome-term (the two terminals I have on my system). The issues come when exiting. When I quit Bombadillo gnome-term returns the title to whatever it was prior to starting Bombadillo. However, st just keeps the title as Bombadillo.

I read a little bit online and found that there are escape codes to get this value and push it onto an xterm stack and later take it off. However, this did not end up changing the behavior of either terminal.

I know the behavior I want is doable because cmus does it. They use curses though... which means there may be a lot of code behind it.

I do not think this is in any way an urgent story. As such, I have not added it to the 2.1.0 milestone (yet). However, adding the title to the window does provide a certain amount of polish that would be nice to have. It also helps when visually grepping tabs or the like.

I would love more tests in other terminals.

Additionally, youtube-dl seems to be using the same solution (implying theirs would fail in st as well):
824fa51165/youtube_dl/YoutubeDL.py (L528)

This one is maybe ill-advised maybe not. What I want to happen is that when a user launches bombadillo the window title (which would include tab title for tab aware applications) is changed to `Bombadillo`. This is very doable for all xterm based systems: ```go fmt.Print("�33]0;Bombadillo�07") # instead of �07 a could be used ``` That will set the title pretty effectively. I have tested this as working in both `st` and in `gnome-term` (the two terminals I have on my system). The issues come when exiting. When I quit Bombadillo `gnome-term` returns the title to whatever it was prior to starting Bombadillo. However, `st` just keeps the title as _Bombadillo_. I read a little bit online and found that there are escape codes to get this value and push it onto an xterm stack and later take it off. However, this did not end up changing the behavior of either terminal. I know the behavior I want is doable because `cmus` does it. They use curses though... which means there may be _a lot_ of code behind it. I do not think this is in any way an urgent story. As such, I have not added it to the `2.1.0` milestone (yet). However, adding the title to the window does provide a certain amount of polish that would be nice to have. It also helps when visually grepping tabs or the like. I would love more tests in other terminals. Additionally, youtube-dl seems to be using the same solution (implying theirs would fail in st as well): https://github.com/ytdl-org/youtube-dl/blob/824fa51165d92ceee01589bf995ebbf009df328c/youtube_dl/YoutubeDL.py#L528

sloum added the

enhancement

non-urgent

labels 2019-12-15 18:52:40 +00:00

sloum commented

2019-12-15 19:01:25 +00:00

At present there is a branch called window-title that can be pulled to test this.

At present there is a branch called `window-title` that can be pulled to test this.

asdf commented

2019-12-16 01:23:38 +00:00

I can confirm this behaviour in st on my system (installed from ubuntu repos, not built from source). rxvt-unicode, gnome-terminal, xfce4-terminal do not have this issue.

I can confirm this behaviour in `st` on my system (installed from ubuntu repos, not built from source). `rxvt-unicode`, `gnome-terminal`, `xfce4-terminal` do not have this issue.

sloum commented

2019-12-16 05:55:07 +00:00

Interesting. So they must already be doing some kind of refresh on the title automagically. Leaving st...

What do you think? Is this:

A feature worth pursuing at all?
If 1, acceptable in its current state?

If seems like this would be something that would fail gracefully in terms that did not support this... mostly. I think the st issue would be the worst of it. So it could be a nice thing to add... but I'm not sure if the st issue will be easily fixable or not, nor if it is limited to st (my guess is that it isnt, but given the sample size of 4 terms we are at 25%).

Interesting. So they must already be doing some kind of refresh on the title automagically. Leaving st... What do you think? Is this: 1. A feature worth pursuing at all? 2. If 1, acceptable in its current state? If seems like this would be something that would fail gracefully in terms that did not support this... mostly. I think the st issue would be the worst of it. So it could be a nice thing to add... but I'm not sure if the st issue will be easily fixable or not, nor if it is limited to st (my guess is that it isnt, but given the sample size of 4 terms we are at 25%).

asdf commented

2019-12-16 07:41:06 +00:00

I tested two other terminals - kitty and xterm - both worked as expected.

st provides some useful error information to stdout/error - starting st from a terminal implies there are several escape sequences it can't interpret. This might help?

To answer your question:

st seems like an outlier here
technically there doesn't seem to be a good reason not to implement this as is
my concerns are about how this change might affect conventions

I tested lynx, w3m, elinks, top, alsamixer and ranger, and none of these applications change the window title. A question for thought: is it rare for applications to do this, and if so, why?

At worst, this change could overwrite some status information the user might expect. For example, if I connect to rawtext club the title shows that I'm connected to a remote system. Bombadillo would change this information.

There is an example of someone disliking this feature in cmus here. It seems they built an option to disable this function.

Despite this, I don't see that the change could be an problem when Bombadillo is started from the desktop shortcut. A conservative approach might see the change limited to this situation.

Sorry for the wall of text, it's an interesting topic and an interesting idea - I agree with the 'polish' aspect and it makes sense for a GUI.

I tested two other terminals - `kitty` and `xterm` - both worked as expected. `st` provides some useful error information to stdout/error - starting `st` from a terminal implies there are several escape sequences it can't interpret. This might help? To answer your question: - `st` seems like an outlier here - technically there doesn't seem to be a good reason not to implement this as is - my concerns are about how this change might affect conventions I tested lynx, w3m, elinks, top, alsamixer and ranger, and none of these applications change the window title. A question for thought: is it rare for applications to do this, and if so, why? At worst, this change could overwrite some status information the user might expect. For example, if I connect to rawtext club the title shows that I'm connected to a remote system. Bombadillo would change this information. There is an example of someone disliking this feature in cmus [here](https://superuser.com/questions/308650/keep-cmus-from-changing-terminal-title). It seems they built an option to disable this function. Despite this, I don't see that the change could be an problem when Bombadillo is started from the desktop shortcut. A conservative approach might see the change limited to this situation. Sorry for the wall of text, it's an interesting topic and an interesting idea - I agree with the 'polish' aspect and it makes sense for a GUI.

sloum commented

2019-12-16 19:12:55 +00:00

You bring up good questions. I, personally, like the title to reflect the application that is running. However, I do not necessarily feel that should be pushed onto users.

I do know from a bit of research that it seems like OSX's terminal.app does not support the escape codes to use the stack to pop on and off application names. This seems to be true of st as well. As a result, both allow the title to be changed, but do not automatically change it back.

It is good to know that those are outliers... but does leave the question of expectations by users. I do know that it is easy to write a script that will always update the x title when an application is launched using args[0] as the title. But that leaves it to the user, which I suppose it probably the right place for it to be. It is their system after all.

I dont believe there is a way for me to know that Bombadillo is started from a desktop shortcut. However, we could add a flag (-t or the like) and have that be a part of the Exec line in the bombadillo.desktop file. It would also be available to users that wanted to use it at their whim without forcing things or adding more parsing to the config...

What do you think about that as an approach?

You bring up good questions. I, personally, like the title to reflect the application that is running. However, I do not necessarily feel that should be pushed onto users. I do know from a bit of research that it seems like OSX's `terminal.app` does not support the escape codes to use the stack to pop on and off application names. This seems to be true of `st` as well. As a result, both allow the title to be changed, but do not automatically change it back. It is good to know that those are outliers... but does leave the question of expectations by users. I do know that it is easy to write a script that will always update the x title when an application is launched using args[0] as the title. But that leaves it to the user, which I suppose it probably the right place for it to be. It is their system after all. I dont believe there is a way for me to know that Bombadillo is started from a desktop shortcut. However, we could add a flag (`-t` or the like) and have that be a part of the `Exec` line in the `bombadillo.desktop` file. It would also be available to users that wanted to use it at their whim without forcing things or adding more parsing to the config... What do you think about that as an approach?

asdf commented

2019-12-16 23:54:17 +00:00

Yeah I don't disagree with this change, I just don't know enough about it to state the impact.

A command-line option for bombadillo would be a simple way to enable it. Alternatively, can the desktop file be configured to run a command that echos the escape sequence and then starts bombadillo?

Yeah I don't disagree with this change, I just don't know enough about it to state the impact. A command-line option for bombadillo would be a simple way to enable it. Alternatively, can the desktop file be configured to run a command that echos the escape sequence and then starts bombadillo?

sloum commented

2019-12-17 02:07:16 +00:00

Yeah, I'm not sure about the impact either :-/

If we do it as a command line option I can make the bombadillo.desktop file call it with the -t like so: Exec=/usr/local/bin/bombadillo -t. That could more or less achieve what you mentioned and allow users to run it that way if they want.

Yeah, I'm not sure about the impact either :-/ If we do it as a command line option I can make the `bombadillo.desktop` file call it with the `-t` like so: `Exec=/usr/local/bin/bombadillo -t`. That could more or less achieve what you mentioned and allow users to run it that way if they want.

sloum commented

2019-12-17 03:43:36 +00:00

Ok. I updated the branch to use the flag. If you dont mind pulling and trying it out, I would appreciate it!

I also updated the documentation (-h and man page). I'm not too happy with my wording for either. I also updated the syntax descriptions in ways I do not love, but was unsure how else to do so... any advice would be appreciated. It might be easier to see the changes by making a pull request. Let me know if you'd prefer that and I can make one, or feel free to do so yourself as well. Either way.

Ok. I updated the branch to use the flag. If you dont mind pulling and trying it out, I would appreciate it! I also updated the documentation (-h and man page). I'm not too happy with my wording for either. I also updated the syntax descriptions in ways I do not love, but was unsure how else to do so... any advice would be appreciated. It might be easier to see the changes by making a pull request. Let me know if you'd prefer that and I can make one, or feel free to do so yourself as well. Either way.

asdf commented

2019-12-19 02:43:50 +00:00

Oh there is a whole thing about writing the program synopsis that I did not know about...

I've set it to a single line: bombadillo [options] [url], with the binary name in bold and the other two items in italic because:

bold indicates "write the command as is"
italics indicates replaceable arguments
brackets indicates optional arguments

Another options if you prefer a longer, more detailed synopsis, is to do it similar to the man page for less.

I've pushed changes for the man page and main.go, so take a look at your convenience.

Oh there is a whole thing about writing the program synopsis that I did not know about... I've set it to a single line: `bombadillo [options] [url]`, with the binary name in bold and the other two items in italic because: - bold indicates "write the command as is" - italics indicates replaceable arguments - brackets indicates optional arguments Another options if you prefer a longer, more detailed synopsis, is to do it similar to [the man page for less](https://linux.die.net/man/1/less). I've pushed changes for the man page and main.go, so take a look at your convenience.

sloum referenced this issue

2019-12-19 03:13:39 +00:00

Add a flag to change the window title on run #121

sloum commented

2019-12-19 03:20:31 +00:00

Oh! That is awesome. I feel like I intuitively knew that sort of... but was unsure and never quite sure how to write it. That less synopsis is intense.

I have created a pr ( #121 ) so that we can more easily comment on code. I looked for changes to what I had pushed (relating to your description) but did not find any. Did they go to this branch?

Oh! That is awesome. I feel like I intuitively knew that sort of... but was unsure and never quite sure how to write it. That less synopsis is intense. I have created a pr ( #121 ) so that we can more easily comment on code. I looked for changes to what I had pushed (relating to your description) but did not find any. Did they go to this branch?

asdf commented

2019-12-19 04:01:08 +00:00

I pushed but did not commit...they are there now.

sloum self-assigned this 2019-12-20 06:13:26 +00:00

asdf commented

2020-01-08 01:48:19 +00:00

This has been implemented in #121 (we can reopen if any outstanding work is required).

asdf closed this issue

2020-01-08 01:48:19 +00:00

Sign in to join this conversation.