Setting an initial title (-T or --title) breaks dynamic titles

Bug #1359547 reported by C. Jeffery Small
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
xfce4-terminal
Fix Released
Medium
xfce4-terminal (Debian)
Fix Released
Unknown
xfce4-terminal (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Setting up a new Xubuntu 14.04.1 system, I discovered that if xfce4-terminal (0.6.3-1ubuntu1) is started with an initial title using the -T or --title flags, then dynamic title updating can never occur. Starting the terminal without using -T or --title option results in proper window decoration updating. The xfce4-terminal preferences include a default initial title string (which is used if no title is specified on the command line) and the option is set to "Replace initial title."

Revision history for this message
In , G-hintermayer (g-hintermayer) wrote :

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061221 BonEcho/2.0.0.1
Build Identifier:

although I set Dynamically-set title to "replaces intitial title", the title is frozen to the original title specified on the command line. When calling Terminal without title option (or directly vte), the title changes as expected (e.g. when editing a file with vi filename etc. is shown in title)

Reproducible: Always

Steps to Reproduce:
1. invoke Terminal --title=Frozen
2. edit some file with vim -> no changes
3. invoke Terminal
4. edit some file with vim -> title changes

Actual Results:
title frozen to title specified on command line

Expected Results:
dynamically set title

Revision history for this message
In , Benedikt Meurer (benny-xfce) wrote :

Sure, that's the expected behavior. The user specified title overrides all other titles.

Revision history for this message
In , G-hintermayer (g-hintermayer) wrote :

and what's the purpose of the possible settings, if user set title always overrides dynamic titles ? especially ..goes before/after would'nt make any sense then, and replaces .. would only replace the standard (default) title.
I'd expect to Terminal exactly do what the options say, regardless of how the title was initialised and see no reason, why it should'nt do so.

Revision history for this message
In , G-hintermayer (g-hintermayer) wrote :

so now I'm again on the machine where xfce 4.4 is installed.
Your explanation doesn't satisfy me (and probably lot of others)
In the current behavior dynamically set titles work only when *not* specifyig -T or --title= on the command line, which results in the default title "Untitled".
I don't want to hang around a dozen or more untitled Terminal windows housing different shells (ssh or telnet to different hosts and/or with different users). So I name the Terminals <user>@<hostname> to distinguish them. Your desribed behavior forces anybody to refrain from using anything than the default title when he likes to have dynamically set titles.
So why is the described behavior the expected one for you ?
The button in the Terminal prefs window also speaks of initial title, regardless where it did come from.

Revision history for this message
In , G-hintermayer (g-hintermayer) wrote :

This issue is still not resolved for me. Dynamically set title do also no work, when specifying -e or -x on command line. Why does this have to be so ?

Revision history for this message
In , 8-nick (8-nick) wrote :

Titles support tokens since 0.4.3. So you can now type something like:

terminal --title "Remote server: %w", which will act like an appended dynamic title.

Revision history for this message
In , G-hintermayer (g-hintermayer) wrote :

(In reply to comment #5)
> Titles support tokens since 0.4.3. So you can now type something like:
>
> terminal --title "Remote server: %w", which will act like an appended dynamic
> title.

Sorry, but this gives me "Remote server: %w" as title, not exactly what I want. (at least with Terminal 0.4.2). Obviously noone is using Terminal to manage multiple hosts with application set dynamic titles, but with the need of a prepended FIXED host identification text :-(

Revision history for this message
In , G-hintermayer (g-hintermayer) wrote :

(In reply to comment #5)
> Titles support tokens since 0.4.3. So you can now type something like:
>
> terminal --title "Remote server: %w", which will act like an appended dynamic
> title.
Sorry just noticed the version you mentioned. And I'm lagging one minor number behind. Unfortunately 0.4.3 is not yet in Gentoo portage tree, so I'm going to set up an overlay and give it a try. Thanks for your time.

Revision history for this message
In , 8-nick (8-nick) wrote :

Well if the token substitution suits you needs i can close the bug.

Revision history for this message
In , G-hintermayer (g-hintermayer) wrote :

(In reply to comment #8)
> Well if the token substitution suits you needs i can close the bug.

Ok, I get the desired result, but I'm not quite happy with the solution. I can e.g. emerge -Dpu world on multiple hosts and see both progress AND hostname in the Terminal window, but I have to run Terminal remotely on the machine I'm maintaining, which gives a lot of X protocol over the network.
What I did before is (1): Terminal --title user@host --execute ssh -l user host

so Terminal ran locally and only output of the pty was sent over the net. Obviously running an emerge on the remote host did'nt show any progress in the window title bar.

Now I would have to (2): ssh -l user host Terminal
the token substitution is not necessary here since the title is set to %w:%D anyhow.

But wait, I just tried (1) without the --title option with a 0.2.8 (very old,I know) Terminal and this gives me now the desired result (e.g. not setting the window title to Untiteled ,but to something like %w:%D) on recent distros (Gentoo up to date system, which was not present when I originally filed the bug report, so I thought "This doesn't work on all machines") but still the "Untitled" old quite old installations. Can somebody tell me what or who sets the Title to something different than "Untitled" ? Maybe I have to set up a env var to have this working on the old machines.

So the point is, how do I set the title to %w:%D on the old distros ?

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue you are reporting is an upstream one and it would be nice if somebody having it could send the bug to the developers of the software by following the instructions at https://wiki.ubuntu.com/Bugs/Upstream/Xfce. If you have done so, please tell us the number of the upstream bug (or the link), so we can add a bugwatch that will inform us about its status. Thanks in advance.

Revision history for this message
In , C. Jeffery Small (loyhz2ay-jeff-h670zbts) wrote :

xfce4-terminal 0.6.3-1ubuntu1
Xubuntu 14.04.1
Intel Xeon 64-bit system

I have to agree with Gerhard on this issue. I was also ready to file a new bug report until I ran across this one. By logic it should follow that if you can specify an "Initial title" in the preferences which can then be overwritten if "Replace initial title" is specified, you should be able to do the same thing from the command line. The setting of the initial title and the dynamic behavior are two separate things and should have independent controls. Consider my issue:

I have a script that populates the desktop with a varying number of terminal windows. If I don't specify a title (with -T or --title) then the default string specified in the preferences is used and, because "Replace initial title" is also set in the preferences, the title will update. If I attempt to specify the user's $HOME in the script when populating these windows, then dynamic updating is lost. If I specify "%w", then the initial title is displayed as "Untitled" but will dynamically update.

One possible solution to this problem is to allow -T (--title) to set an initial title, and have another command line option that determines the dynamic update policy, mirroring the four choices offered on the preferences menu.

BTW, where are the title tokens discussed? I do not find them in my man page and I believe I am using the latest version of xfce4-terminal. If these worked, I might be able to solve my problem, but I still think there is a serious inconsistency between the way the preference and command line options are working, and this is a poor UI decision in my book.

I hope this adds to the discussion.

Regards.

Revision history for this message
C. Jeffery Small (loyhz2ay-jeff-h670zbts) wrote :

Sorry for the confusion on my part and thanks for pointing me in the proper direction. I did find an open bug (#2908) discussion this issue which you can find here:

https://bugzilla.xfce.org/show_bug.cgi?id=2908

I added some additional comments to that thread.

I assume you will now close this bug.

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

We should leave this bug report open as for now. Moreover, it could be marked as feature request (wishlist).

Changed in xfce4-terminal (Debian):
status: Unknown → New
Changed in xfce4-terminal:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
In , Leeman (me-mooluv) wrote :

Docs for the tokens are in http://docs.xfce.org/apps/terminal/usage search on token.

Had a hell of a time getting this to work for me due to the unusual requirement of a space between options and their string component

eg: -T"foo foo" breaks things in neat ways...

-T"foo foo" stuff -e "bash -l"
  results in a realized command like:
-T stuff -e "bash -l"

Changed in xfce4-terminal:
status: Confirmed → Fix Released
Unit 193 (unit193)
Changed in xfce4-terminal (Ubuntu):
status: New → Fix Committed
Changed in xfce4-terminal (Debian):
status: New → Fix Released
Revision history for this message
Theo Linkspfeifer (lastonestanding) wrote :

Fixed in version 0.8.6+ (Xubuntu 18.04).

https://git.xfce.org/apps/xfce4-terminal/tree/NEWS

Changed in xfce4-terminal (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.