Created attachment 23631 [details] [review]
Patch showing feature

Created attachment 23632 [details]
Screenshot of highlighting

Marked this as depending on 132610, which is the cause for your using
cursor-moved instead of contents-changed here.

*** Bug 93578 has been marked as a duplicate of this bug. ***

From 93578:

------- Additional Comments From Havoc Pennington 2002-09-22 18:17 -------

We probably need a comprehensive tabbed-MDI UI recommendation.

Anyway, I think it's a good idea to do the colors thing, 
though there are possible accessibility issues to sort out.

------- Additional Comments From Calum Benson 2002-09-23 07:35 -------

There's no such spec yet, but a few ideas were also mentioned in  in
bug #72101.  (And yes, any colours we used for this idea would need to
be themable-- my guess is font styles or a small icon might be more
workable in practice).

Another desirable thing would be to have two colours, and in the old
Multi Gnome Terminal. Red marks that there has been a content change
in the last 1-2 seconds, and blue that there is static, not seen,
changes in the tab.

With this you could left something compiling in a tab (as content
changes, it will be red) and when the compilation stops it will be
blue. Very convenient.

Gnome-terminal is a tool for hackers, so I think it should aim more
features, as the konsole from kde or the old multi-gnome-terminal. I
like the HIG for user apps, but the terminal is not a common user app.

Yep, gaim is also doing the red/blue stuff.
So we need to poke HIG people to get a UI recommendation for this
stuff during 2.7 development.

*** Bug 148005 has been marked as a duplicate of this bug. ***

The red/blue in multignometerminal (mgt) is not about the time.

red signals a running programm
blue signal new output

blue has higher priority

anyway this is not perfect as, all combiunations of the state can happen

*** Bug 155561 has been marked as a duplicate of this bug. ***

155561 wants to get beeps reported by color changes in the tab labels.

*** Bug 312356 has been marked as a duplicate of this bug. ***

Please also see bug 116647 against gtk+, which asks for a notebook tab state API.

Note that the Epiphany Tab States extension uses bold text for changed tab labels instead of a different text color, for a11y reasons (color blindness).

Has there been any progress on this bug?  People who have terminals with lots of tabs open would surely find it very useful.

Whenever I'm using a Knoppix disc (and hence am forced to use Konsole), I'm reminded of how much I would like activity notification in gnome-terminal.

I'm assuming that the patch Fernando produced originally would need a lot of work to fit in with the current gnome-terminal?

*** Bug 415930 has been marked as a duplicate of this bug. ***

*** Bug 501986 has been marked as a duplicate of this bug. ***

Bug 501986 has a patch (attachment 108150 [details] [review]).

*** Bug 528534 has been marked as a duplicate of this bug. ***

I try all the patch i found on this BUG and duplicate ones, but unfortunatelly i can't get it work.. I've poor coding experience, there's anyone who has merged this feature in "mainstream" release?
Thanks

I think the patches (mine from Bug 501986) and this one here and not production state. 

Mine only flashes the whole terminal window in the taskbar without highlighting the tab. This patch highlights the tab. Maybe the same highlighting function which is used in Pidgin can be used ? 

Furthermore my patch works for both: for activity and inactivity monitoring by automatic detection (see #501986). Unfortunately my C++ coding experience is very poor, so it would be great if somebody could merge the patches together.

Any change or decision about this bug? I think it is a very important enhancement and there are a lot of patches? Why isn't it resolved?

I will try to find someone on rent a coder for this ...

Created attachment 135022 [details] [review]
Monitor for activity / inactivity.

Hello.

I am someone who was contracted by Alex Menk to implement this feature. My work is now complete and I am contributing this patch to the community in the hopes it will be useful and that it will get accepted to the official gnome-terminal distribution. As part of our contract, we agreed that the copyrights for this work remains with me. I will also personally contact the gnome-terminal maintainers.

The patch is made against the gnome-terminal git repository master branch, so you will have to clone it to your local machine to apply this patch.

Comments are welcome. Thanks.

* When the terminal screen loses focus, 2 second analysing period is
  entered. If terminal screen's contents change during this period,
  enters the 'monitor for inactivity' state; otherwise enters the
  'monitor for activity'.

What has 'focus' got to do with 'activity'? The activity monitoring should be independent of focus. 


"label" public variable is added to the TerminalScreen structure.

This is not a good design. 'activity' status should be a property on TerminalScreen, and the tab label should listen to notifications for this property and update itself, instead of accessing the tab label from within TerminalScreen code.


The following new properties are added to terminal profiles:

 * default-monitor-activity
 * libnotify-enable
 * libnotify-timeout
 * libnotify-summary
 * libnotify-body1
 * libnotify-body2
 * libnotify-urgency
 * libnotify-category

This looks like total overkill to me. Why would one want notifications using libnotify per profile, instead of a global setting? And why have 3 strings for summary/body[12] instead of just 'text' or maybe if there's a really good reason for more than one string, have 'primary' and 'secondary' text like in message dialogues? Why make the 'urgency' configurable? And 'category'? And 'timeout' ?



Now some comments on the patch itself:

+   libnotify >= $LIBNOTIFY_REQUIRED])

Let's please make this an optional dependency, and disabled by default.

+  guint state;
+  gboolean had_activity;
+  guint timeout_id;
+};
+
+enum
+{
+  HAS_FOCUS,
+  ANALYSE_ACTIVITY,
+  MONITOR_ACTIVITY,
+  MONITOR_INACTIVITY
 };

Make that a typedef enum, and then use the type, instead of guint.

Also 'activity' has nothing to do with whether the widget has focus. So HAS_FOCUS is misnamed.

+  priv->state = HAS_FOCUS;
It most definitely does not have focus in init().


+  g_signal_connect (G_OBJECT (screen), "contents-changed",
+                    G_CALLBACK (terminal_screen_contents_changed),
+                    NULL);

I wonder if that's going to be a perf problem, this signal is potentially emitted very often.

+  if (screen->priv->timeout_id)
+    g_source_remove (screen->priv->timeout_id);

Need to set timeout_id = 0 since dispose can run multiple times.

+static void
+notify_user (TerminalScreen *screen, TerminalNotificationType type)
+{
+  TerminalScreenPrivate *priv = screen->priv;
+  TerminalProfile *profile = priv->profile;
+  GtkWindow *w = GTK_WINDOW (priv->window);
+
+  if (!terminal_window_get_monitor_activity (priv->window))
+    return;
+
+  if (terminal_window_get_active (priv->window) != screen)
+    terminal_tab_label_set_bold (TERMINAL_TAB_LABEL (screen->label), TRUE);
+
+  if (!w->is_active)
+    gtk_window_set_urgency_hint (w, TRUE);
+
+  if (terminal_profile_get_property_boolean (profile, TERMINAL_PROFILE_LIBNOTIFY_ENABLE))
+    terminal_notification_show (profile, type);
+}

This code does not belong here. There shouldn't be any references to the containing window be used in TerminalScreen (I know there's one, which I just haven't got around to removing; but we're not going to add more). This code should be in TerminalWindow for the urgency hint, and TerminalTabLabel for the bolding, and in TerminalApp for the management of all the notifications, I think. Plus, I don't think the window hint should be set at all.

+static gboolean
+terminal_screen_timeout (TerminalScreen *screen)

The name of this func doesn't tell me anything; use something more descriptive.

+  else if (priv->state == MONITOR_INACTIVITY)
+    notify_user (screen, TERMINAL_NOTIFICATION_TYPE_INACTIVITY);

priv->timeout_id isn't reset to 0 in this case?

+  g_signal_connect (G_OBJECT (screen), "focus-out-event",
+                    G_CALLBACK (terminal_screen_focus_out_event),
+                    NULL);
+  g_signal_connect (G_OBJECT (screen), "focus-in-event",
+                    G_CALLBACK (terminal_screen_focus_in_event),
+                    NULL);

As I said above, I don't think activity monitoring should monitor focus.

+  GtkAction *action;
+
+  window->priv->monitor_activity = setting;
+  window->priv->use_default_monitor_activity = FALSE;
+

Use a TerminalWindowPrivate *priv local var.

---

Thinking about this some more, I wonder if the 'activity status' should instead be monitored directly in VteTerminal?

Oh and another thing: boldening the tab label as notification for activity conflicts with the use of boldening to alert of bell status that bug 557593 wants to introduce.

(In reply to comment #26)
> Oh and another thing: boldening the tab label as notification for activity
> conflicts with the use of boldening to alert of bell status that bug 557593
> wants to introduce.
> 

Depends on the semantics of "bold tab". If its described at "requires attention", its probably fine to have multiple reason for it. Its only getting a problem if bold is turned off by anything except navigating to that tab. Unfortunately this is an interesting use case (not sure if the current patch addreses this). I usualy fire a couple of build jobs from tabbed terminals and I'd like to see when they are done (aka, the activity has stopped).

I am not sure hom much people would like to see icons in the tab (a bell for the bell, spinning arrows for activity).

>Thinking about this some more, I wonder if the 'activity status' should instead
>be monitored directly in VteTerminal?

yes maybe. How easy would it be to move the logic?

I like the functionality a lot and I hope that after some cleanup it would soon be in the gnome main branch, as this feature is requested so often again and again.

Hello. Thanks for your comments and sorry for my late reply.

>* When the terminal screen loses focus, 2 second analysing period is
>  entered. If terminal screen's contents change during this period,
>  enters the 'monitor for inactivity' state; otherwise enters the
>  'monitor for activity'.
>
>What has 'focus' got to do with 'activity'? The activity monitoring should be
>independent of focus. 

This was the original idea:

My client wanted to have both activity and inactivity monitored and then get notified when one of those two states are triggered.

Lets say you run a program which outputs a lot of text (such as ./configure). Ideally the user wants to know when the operation concludes after he has switched the focus to another window via some soft of notifcation. Or lets say you run a program which takes a lot of time to process and then outputs something simple as a result. In this case he would perhaps wish to know when the operations has concluded also. Since (to my understanding) there is no way to monitor from inside gnome-terminal when a command ends and the underlaying shell begins to prompt for the next one, it can only monitor for rudimentary content changes. My client proposed me an idea that a some sort of analysis period is needed when the gnome-terminal window loses focus.

If during this 2 second analysis period something changes in the window, the application enters into a state where it waits for this activity to end. This is basically done by using a timer. Each time an activity is detected (that is, the contents of the window are changed) the timer is reset. If the timer runs out (2 seconds again if I recall) then it is concluded that the ongoing activity has stopped and the user should be notified.

However if nothing happens during this 2 second analysis period, monitor for activity state is entered. This basically waits until something happens in the window and then notifies the user when something does.

This was the original idea proposed to me and I implemented it. Since it is not possible to know when a command is under execution (compared to the state where the shell is asking the next command to be typed in), this sort of analysis period is required in order to decide whether to monitor for activity or inactivity. Thus, activity monitoring is related to focus. If there would be some way to know, when an actual command starts executing then the implementation would be simpler.

If somebody has a better idea of how to do this then please let me know but please do it politely :)

> "label" public variable is added to the TerminalScreen structure.
>
>This is not a good design. 'activity' status should be a property on
>TerminalScreen, and the tab label should listen to notifications for this
>property and update itself, instead of accessing the tab label from within
>TerminalScreen code.

Yes you're right. This would be a better way to do this. Thanks.

> * default-monitor-activity
> * libnotify-enable
> * libnotify-timeout
> * libnotify-summary
> * libnotify-body1
> * libnotify-body2
> * libnotify-urgency
> * libnotify-category
>
>This looks like total overkill to me. Why would one want notifications using
>libnotify per profile, instead of a global setting? And why have 3 strings for
>summary/body[12] instead of just 'text' or maybe if there's a really good
>reason for more than one string, have 'primary' and 'secondary' text like in
>message dialogues? Why make the 'urgency' configurable? And 'category'? And
>'timeout' ?

Why not to have notifications configurable per profile? So is the menu bar. Why not to have 'summary' and 'body' and make 'urgency, 'category' and 'timeout' configurable? This allows the notifications to be fine tuned by the user. I thought this was a nice idea.

>Now some comments on the patch itself:
>
>+   libnotify >= $LIBNOTIFY_REQUIRED])
>
>Let's please make this an optional dependency, and disabled by default.

> Make that a typedef enum, and then use the type, instead of guint.

Sure. These are good ideas.

>+  g_signal_connect (G_OBJECT (screen), "contents-changed",
>+                    G_CALLBACK (terminal_screen_contents_changed),
>+                    NULL);
>
>I wonder if that's going to be a perf problem, this signal is potentially
>emitted very often.

I think this is the only way to monitor changes on the terminal.

---

I would be willing to work more on this but we would have to first come up with some sort of design which would suit your needs and ideals. If you have any ideas on how this should be done please let me know.

Created attachment 182539 [details]
Minimal patch

Hi,
This bug has been open for 7 years. Maybe, if the previous patches do not match the coding guidelines and imply unwanted dependencies, can we start with something "simple" ?
My main goal was to monitor the termination of a command. This would be a pain with "contents-changed". Since modern shells set the title on every command termination, I modified the terminal_screen_window_title_changed function. The behavior I aimed at was :
 - if the tab is focused, do nothing
 - if the window is focused but on another tab is focused, prepend "Done : " to the tab title. As soon as we go in the tab, remove the prefix
 - if the window does not have focus, do a gtk_window_present and switch to the tab if needed.

The main idea behind this is to notify the user, but be as little disruptive as possible. At the moment the window stuff is coded inside terminal-screen.c, but perhaps we can move it to terminal-window.c and use a signal.

IMHO, it is too bad to have so much work done, and not having anything implemented yet.
Cheers,
Thomas

Have you tried gnome 3 gnome-terminal? It looks like it got color notifications implemented.

I just built gnome-terminal 3.1.0 from git, and haven't found anything lokking like notifications.

So it's been another two years. It does not look like this sort of feature exists in gnome-terminal yet, but I also would like to see it. I was told today that OSX's built-in terminal emulator has this feature. It basically just changes tab styles when the content has been updated.

Before I start discussing this bug I want to say that I'm the developer of ROXTerm, which is in big trouble at the moment, and I think my effort would be better spent contributing to gnome-terminal, but I want to be sure the other developers are open to my ideas and patches. There doesn't seem to be a mailing list for gnome-terminal so I hope it's OK to bring that up here.

Back to this issue, this is the feature that I think people would miss most if they have to switch from ROXTerm to gnome-terminal. I'd be willing to work on it as long as I can be confident that work will make it into release and not just sit in forgotten patches here for years.

We should also consider other conditions besides new text appearing: whether there's been a bell signal and whether the child process is still busy or has apparently completed (something ROXTerm doesn't currently distinguish):- either using the window-title-changed signal or the same check for a child process that I think is used to check for active tasks when closing a tab.

And how do we show the status? I think the way that ROXTerm does it - changing the icon in the close button while it still behaves as a close button - is too unconventional. iTerm 2 changes the tab text colour, but that has its own problems: using hard-wired colours would inevitably clash with some themes, while making the colours configurable could result in an unwieldy UI. So I think a good strategy would be to replace the close button icon, but also remove its border and make it inactive while it's showing a status.

(In reply to Tony Houghton from comment #34)
> Before I start discussing this bug I want to say that I'm the developer of
> ROXTerm, which is in big trouble at the moment,

Why is ROXTerm "in big trouble at the moment"?

(In reply to Debarshi Ray from comment #35)
> Why is ROXTerm "in big trouble at the moment"?

Discussing that here is probably abusing the bugzilla too far, so please see <https://sourceforge.net/p/roxterm/discussion/422638/thread/57dab858/> and <https://sourceforge.net/p/roxterm/bugs/125/>.

May I refer to comment #14, I still think that is the best solution to indicate status changes.

The trouble with using bold is that we can only show one condition. I think we should ideally differentiate between all of these:

1. Terminal is in the currently active/focused tab in the notebook.

2. Terminal is unfocused, but was "idle" when focus was switched away and it still is. This could have the same style as the focused tab as long as we avoid this potential problem:
<https://bugs.launchpad.net/ubuntu/+source/ubuntu-themes/+bug/1399734>.

3. Terminal is "busy" (its child process isn't a shell, or it's a shell with a child process).

4. Some new text has appeared.

5. Terminal was busy but is now idle (a shell without a child process, waiting for input).

6. Terminal's child process has exited.

7. Terminal has activated the bell.

If bold is the only option we should probably use bold for 4-7 and normal for 1-3.

(In reply to Tony Houghton from comment #38)

> If bold is the only option we should probably use bold for 4-7 and normal
> for 1-3.

You might use some nice Unicode symbols such as Bell (U+1F514) to indicate additional statuses.

(In reply to Reinout van Schouwen from comment #39)

> You might use some nice Unicode symbols such as Bell (U+1F514) to indicate
> additional statuses.

That's worth exploring, but can you think of symbols for idle, busy, exited etc?

None of the common fonts seem to have nice glyphs for U+1F514, they just render the hex code in a box. There's another type of bell at U+237E which could be usable, but it doesn't stand out very well, and I had to think a couple of seconds to work out what sort of bell it's supposed to represent:

⍾

It might be easier to use stock icons where possible and provide our own for conditions where there seems to be nothing appropriate.

Hi there! Is there any progress on this matter?

Thanks!

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gnome-terminal/-/issues/2638.