BTW, for Maverick+1, I found a new way to do this, that works for both screen sessions, ssh sessions and the perverse case of remote screen sessions displayed multiple times on multiple terminals.
Changes to Desktop Notification specs/notify-daemon/notify-osd: 1. Add a ID field to the notification: this is an optional 128/256-bit integer randomly generated by the client 2. Add a "holding time" field to the notification 3. If the "holding time" is specified, the notification daemon will wait that amount of time before displaying the notification, and then only display it if a "do not show" flag was not set 4. Any notification with the same ID of a notification being currently held is silently dropped, with the holding time period ending at the maximum of the end of the two holding periods. Optionally, the daemon is allowed to also drop those with the same ID of any notification ever seen. It may also choose to not do this to avoid unlimited memory requirements. 5. A new kind of request is added, called an "notification inhibition request", which contains a required ID like those for notification 6. If a "notification inhibition request" is received, and a notification with that ID is being held, set the "do not show" flag on that notification Changes to the VT100/xterm terminal specification: 1. Add a new escape code, that carries a full notification as specified in the D-BUS Notification specification plus the extension detailed above Changes to the bash prompt_command 1. Generate a unique notification ID 2. Pass that to notify-send, along with a sensible holding timeout (e.g. half second) 3. Also print the notification escape code, with all the data Changes to gnome-terminal, konsole, rxvt, xterm: 1. If a notification escape code is received, and the terminal is active, send a "notification inhibition request" with the ID provided via D-BUS to inhibit the notification 2. If a notification escape code is received, and the terminal is not active, send a notification with the ID and data provided via D-BUS to show it (if not inhibited by another active terminal) Example results: 1. For local (and bound "screen") sessions on inactive terminals, both the shell and terminal sends a notification: one notification is displayed 2. For local (and bound "screen") sessions on active terminals, the shell sends a notification and terminal sends an inhibition: nothing is displayed 3. For detached local "screen" sessions, the shell sends a notification: one notification is displayed 4. For remote sessions on active terminals, the terminal sends an inhibition: nothing is displayed 5. For remote sessions on inactive terminals, the terminal sends a notification: one notification is displayed 6. For remote "screen" sessions attached to from multiple terminals, all inactive, all the terminals send a notification: one notification is displayed 6. For remote "screen" sessions attached to multiple terminals, with one active, all inactive terminals send a notification, and the active one sends an inhibition: nothing is displayed Hence, the proposed solution works properly in all cases, as long as the terminal has been patched. The rationale is: 1. If the session is not displayed (e.g. detached screen), we must notify. Hence, the shell must notify. 2. We need a way to find out if the session is being displayed, regardless of whether screen or ssh is in between. Thus, we need a new escape, since it's the only reliable way to do so. 3. If nothing handles the escape, the notification should display. Thus, things handling the escape should actually inhibit the notification. This requires a timeout, unique ID, and central inhibition management as proposed. 4. If the session is remote, the shell cannot notify. Hence, the terminal must also notify in response to the escape. 5. Multiple agents can notify, so we need to only display one notification, as proposed Note again that this is proposed for Maverick+1, while the solution initially posted here is proposed for Maverick, and is much less invasive, at the expense of not handling ssh and screen sessions. -- [PATCH] Add desktop notification of completed commands https://bugs.launchpad.net/bugs/315932 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
