wishlist: add indication of background tab buffer change

Bug #509544 reported by JP Vossen
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
roxterm (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: roxterm

SecureCRT and "Multi Gnome Terminal" (seems to be adandonware at http://multignometerm.sourceforge.net/) have a great feature that tell you when a background tab's status or buffer has changed. As MGT puts it: "Notification that an inactive terminal buffer has changed, or is in the process of changing, via colors on Tab labels."

This is really handy when using many terminals to connect to remote hosts via SSH (indicator when beuufer changes on connection lost), or to run long jobs (e.g. rsync), but still get a clue when they finish.

It would be awesome if something like that could be added to roxterm. Perhaps the "X" to close the tab could change color, or maybe just color the tab or font, whatever.

PS--I just ran across roxterm and I like it much better than gnome-terminal. Also,zero open bugs is awesome! (Well, until this one... Sorry... :)

Related branches

Revision history for this message
Tony Houghton (h-realh) wrote :

Can you get ssh etc to beep at the crucial moment? If a beep/bell goes off in an inactive tab there's an option to make the label flash (and in the next release, to set an inactive window's urgency hint).

Otherwise I think this is a good idea. To make sure I'm thinking of the right thing: you want the label to clearly change appearance (but not flash because it isn't as urgent as a beep) if there's text output in an inactive tab, then change back to normal when you select it?

Personally I think I'd like it to change to bold text.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

> Can you get ssh etc to beep at the crucial moment?

Probably, but I think that would be manual. I'd have to remember to add '|| beep' or '; beep' on the end of the commands, like 'ssh user@host || beep' or 'rsycn stuff user@host:elsewhere ; beep'. Not a bad work-around though.

> ...you want the label to clearly change appearance...

Correct. Especially depending on color scheme, I'm not sure just bolding the font would be noticeable enough. And I'm not sure how much we want to overload the tab name. Just to brainstorm:

1) Add a special-purpose indicator to each tab (e.g., see attached).

2) Overload the "X" in each tab to change color depending on status (could be tricky depending on color scheme, esp. if using the GTK/system scheme).

3) Overload the text font in each tab to change color depending on status (could be tricky depending on color scheme, esp. if using the GTK/system scheme).

4) Change the tab background color depending on status (could be tricky depending on color scheme, esp. if using the GTK/system scheme), watch out for white on white font/background issues. (The ColorfulTabs FF addon has pretty useful options like this.)

5) User selectable and of the above.

6) Semi-OT; Allow user-selectable tab background color. I can see how that could be handy for grouping tabs. I usually just use different windows, but... Mat also complicate the items above. (Just brainstorming. :)

Then there is the question of state. Again to brainstorm, there is at least:

A) There was output [and/or something beeped?] Arguably, this could be tricky with e.g., IRC clocks. A complicated solution might be to allow the user to define a section of the window/line to ignore for changes. But that might be overkill too. I personally have never had a problem like that; someone at a LUG mentioned it to me.

B) Something beeped

C) The session disconnected

D) The tab has become "stale" (IOW, has not been the active tab in N seconds)

Sample from SecureCRT (Windows) attached. Green = good/no change, Blue = buffer change (i.e. output), Red = disconnected. I realize that SecureCRT is a dedicated SSH/telnet/etc. tool, and not quite the same as a general "xterm" so "disconnected" might not make sense. Then again, depending on the "when command exits" setting maybe that does make sense...

Revision history for this message
Tony Houghton (h-realh) wrote :

I had an idea and decided rather than adding more to the tab area I could use different icons in the close button to show the terminal's status. It now uses a warning sign if there's a beep, an info sign if the text content changes, and an error sign if the command exits. They all change back to the close icon if the tab is selected.

Unfortunately some of the icons are slightly bigger than the close icon so I had to make the button bigger too to avoid clipping them, which makes the whole tab bigger. I've removed the tab border to compensate, but that makes the top of the the button merge with the top of the tab.

Please test the latest svn.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

Thank you for the quick response on this, it's really great to see!

It sort-of works, in that the tab background will now flash if the background tab beeps, but not if it just changes. I am testing by opening two tabs, and typing 'sleep 5 ; echo test' in the first then switching to the second.

Expected: when on the second tab and the sleep expires, the first tab should "indicate something"
Observed: not so much, unless the first tab has 'sleep 5 ; beep'

Also tried 'sleep 5 ; ls' but no effect, beep works, echo and ls don't. And, the indicator is not as described above.

Help > About gives 1.18.0+svn1. I had a little trouble installing it. I'm using checkinstall to build a trivial .deb and installing that. A simple dpkg -i didn't seem to really install, as Help > About was still the stock Karmic 1.15.x and I was getting a bdus error (which I didn't write down). Once I did an 'aptitude purge roxterm' then a 'dpkg -i roxterm_1.18.0-svn1-1_amd64.deb' Help > About is OK and the dbus error is gone, but I am not seeing differences in the close icon, nor am I seeing an indicator on text content change as noted.

Did I somehow check out the wrong thing? Here's what I did:

$ sudo aptitude install autoconf2.13 libtool gettext libglib2.0-dev
libgtk2.0-dev libdbus-glib-1-dev libvte-dev libglade2-dev
### Other things might be needed, that was all I needed, but I've already got quite a bit installed on my Karmic
$ svn co
https://roxterm.svn.sourceforge.net/svnroot/roxterm/trunk/roxterm ROXTerm
$ cd ROXTerm/
$ ./bootstrap.sh
$ ./configure
$ make
$ sudo checkinstall make install
$ sudo aptitude purge roxterm
$ sudo dpkg -i roxterm_1.18.0-svn1-1_amd64.deb

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

Doing a regular 'sudo make install' did not change anything above.

$ sudo make uninstall gave me:
[...]
/bin/bash: line 4: cd: /usr/local/share/roxterm: No such file or directory
make[1]: *** [uninstall-nobase_pkgdataDATA] Error 1
make[1]: Leaving directory `/home/jp/testing/ROXTerm'
make: *** [uninstall-recursive] Error 1

But otherwise seemed to work (roxterm didn't exist after that. sudo dpkg -i roxterm_1.18.0-svn1-1_amd64.deb put it back so I can still use it.

Revision history for this message
Tony Houghton (h-realh) wrote :

Did you enable the new option? It's in the Window/Tabs part of the profile, "Show terminal status in close buttons". The background only flashes for beeps, I think it would be too distracting having all that going on just because there's some text output. Instead, the close button icon will change.

The best way to build a roxterm debian package from svn is to check out the debian directory too. While in the ROXTerm directory:

$ svn co https://roxterm.svn.sourceforge.net/svnroot/roxterm/trunk/debian
$ ./bootstrap.sh
$ sudo apt-get build-dep roxterm
$ debuild -uc -us

lintian will complain about debian/.svn but it doesn't matter for private builds.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

Duh! Yes, it works perfectly if you actually turn it on... :-) Never even occurred to me...

That build process also worked better. I'd seen the Debian module, but initially didn't want to confuse the issue, then forgot about it when I went ahead and confused the issue with checkinstall anyway.

roxterm_1.18.0-1_amd64.deb is now in production on my main workstation, and I'll let you know if I run into any problems.

I did not notice any issues with tab size, so whatever changed there is subtle.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

So far it's been perfect on my two main workstations (Karmic 64-bit & Jaunty LPIA)! I'd vote to include in Lucid if possible.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

Of course I spoke too soon... The Karmic install is still working fine and as expected.

The Jaunty (i386 on LPIA) version has an odd bug (that I don't see in Karmic).

To reproduce:

1) Open 3 or more tabs
2) Switch to tab 2 & do 'sleep 5; echo test'
3) Switch to some other tab

Results: when tab 2's status changes, ALL other tabs, except the one in the foreground, change status (so you need at least 3 open to see the problem)
Expected: only tab 2's status indicator should change

Notes: The affected binary was built on an i386 Jaunty install in a VM, as per comment #6 above. It is actually running on Jaunty LPIA (Dell Mini9) and seems fine except for this glitch, AFAICT. LPIA and i386 are supposed to be compatible, and in fact Canonical is dropping LPIA as of Lucid.

I can provide the exact steps I used to build the .deb, the .deb itself, or whatever else might be useful.

Revision history for this message
Tony Houghton (h-realh) wrote :

Please svn update (update the debian subdirectory too because I've added an option to disable a feature that isn't ready for use yet) so you end up with 1.18.0+svn10/1.18.0-2. Then run it from a different terminal and/or use --separate and capture the output for me.

Revision history for this message
Tony Houghton (h-realh) wrote :

Do the update (again if you already did it before +svn11) but don't worry about capturing the output. I've found a better signal to connect to for detecting when the text has changed ("cursor-moved" instead of "contents-changed") which should hopefully fix that problem - which I think was some quirk in the LPIA build of VTE, not my fault :-P.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

First, I installed the version from comment 9 on the i686 machine on which I build the package that I was using on the LPIA machine, and had the same problem, so it wasn't *just* the LPIA machine. It's odd that it was not reproducible on AMD64, but it's also now moot since the update fixed it.

I updated both ROXTERM and debian to r703 via 'svn up', then:
$ ./bootstrap.sh
$ sudo aptitude build-dep roxterm ## no change, no op, as expected
$ debuild -uc -us
$ sudo dpkg -i ../roxterm_1.18.0+svn13-1_*.deb

This version fixes the bug in #9, and so far works as expected on i686 & LPIA (Jaunty) and AMD64 (Karmic).

There is one item to note, and I feel like I mentioned this before but now can't find it. Anyway, if I run a command [1] that causes ROXTerm to open and switch to a new tab, the "changed" indicator comes up on the tab I just left, presumably because I leave it before it registers the command prompt being displayed again. This is not a problem for me, just an FYI. I was thinking that a small delay before looking for the change indicator would fix that, but it also might open up some race conditions and may not be worth it. It is probably worth a note in the docs some-place though.

[1] alias rxssh='roxterm --tab --execute ssh'
Use case: 'rxssh user@host' opens a new tab directly into an SSH session.

Revision history for this message
Tony Houghton (h-realh) wrote :

> There is one item to note, and I feel like I mentioned this before but
> now can't find it. Anyway, if I run a command [1] that causes ROXTerm
> to open and switch to a new tab, the "changed" indicator comes up on the
> tab I just left, presumably because I leave it before it registers the
> command prompt being displayed again. This is not a problem for me,
> just an FYI. I was thinking that a small delay before looking for the
> change indicator would fix that, but it also might open up some race
> conditions and may not be worth it. It is probably worth a note in the
> docs some-place though.

There's already a flag to get roxterm to ignore certain side-effects of adding a tab to a window, which is checked by the notification code. Clearly in this case the tab has been added and the flag cleared by the time the first tab gets the cursor-moved signal. I don't think I can easily do anything about that, at least not without a probability of some unwanted side-effects.

Revision history for this message
Tom Metro (tmetro+ubuntu) wrote :

> ...I think I'd like it to change to bold text.

That probably would have been my first pick too. It fits the model used by other applications.

Though if tabs adjust their width to the text, that can trigger undesired movement in the tab bar contents. (It looks like ROXTerm tabs are fixed width, and if so, this concern isn't applicable.)

> ...the close button icon will change.

That sounds OK too, though there isn't a good UI metaphor or precedent for using the close button real estate as a notification area.

(I've always found close buttons on tabs that aren't in the foreground to be problematic. Occasionally it is handy to be able to close a tab without bringing it into the foreground. But sometimes it can make it too easy to close the wrong tab. I think my ideal tab close button would stay hidden unless the tab was in the foreground and the mouse was hovering over the tab corner. This requires some user training to know that it is there, but affords more space for titles.)

> ...new option..."Show terminal status in close buttons". The background only flashes for beeps...

Off the top of my head, I can't think of any good use cases that I personally encounter where a general change notification would be useful. Sure, there's the rare occasion when I'm moving or copying a large file, and an indication of when that completes could be handy. Aside from that, I think it would mostly get triggered by the error messages spit out by ssh when a network connection drops and it reconnects. Due to automation and 'screen' such a disconnect has no real impact, so it isn't something I'd want my attention drawn to.

I'd have to try it for a while to see whether it ends up being more useful or more distraction, so I'd want to make sure that the status notification can be disabled independent of the beep notification, which I do find useful.

I'll provide some more feedback after I've used the svn version for a while and give an opinion on whether this feature should be on or off by default.

Revision history for this message
JP Vossen (jp-jpsdomain) wrote :

roxterm_1.18.0+svn728 (2010-03-05) has been working flawlessly on LPIA (using i386) Jaunty and AMD-64 Karmic.

I see that Lucid only has: Version: 1.17.1-1, it'd be great to bump this up ASAP!!!

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package roxterm - 1.18.2-1

---------------
roxterm (1.18.2-1) unstable; urgency=low

  * New upstream release:
    + Fix crash when using --tab with no pre-existing windows
      (upstream SourceForge tracker (SF) #2996294).
    + Hide/show menu bar setting is inherited from other windows (SF 2996296).

roxterm (1.18.1-1) unstable; urgency=low

  * New upstream release:
    + Support X session management (SF #2779052).
    + Added "Restart Command" menu action (SF #2810001).
    + Ensure no associated menus/dialogs are left open when a terminal exits.
    + Profile editor redesign with new fullscreen/maximise options
      (SF #2942755).
    + Option to reflect terminal status in tab close icon (LP: #509544).
    + Fix --hide-/--show-menubar (SF #2942481).
    + Rudimentary ssh support (SF #2810009).
    + New Window/Tab With Profile menu items (SF #2928415).
    + Moved Always show tabs option to Appearance and made it on by default;
      single tabs no longer fill available space.
  * Upgraded to debian source format 3.0 (quilt).
  * debian/control:
    + Updated long description.
    + Updated Standards-Version.
  * debian/rules: Parse DEB_BUILD_OPTIONS to support parallel build etc
    (based on <http://lists.debian.org/debian-policy/2007/06/msg00022.html>).
 -- Ubuntu Archive Auto-Sync <email address hidden> Sun, 09 May 2010 14:01:49 +0100

Changed in roxterm (Ubuntu):
status: New → 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.