|
From: | Jonathan Martin |
Subject: | Re: (no subject) |
Date: | Mon, 4 Apr 2005 13:49:40 -0400 |
Pardon me while I daydream for a second...- A dedicated OSX screen terminal client, it could be configured to bounce the dock icon when a bell is received or a monitored window changed. Similarly, in Windows or contemporary unix desktops like Gnome, tasktray icons could flash or otherwise indicate alerts from a screen backend.
- On OSX, other clients could be created dedicated to just monitoring or controlling a screen backend session instance. For example, a process could monitor screen and make Growl notifications that a bell was received in window X. Or a Konfabulator widget (lol, Tiger dashboard widget) could monitor screen windows.
- Whatever protocol that spans between the front-end and back-end is tunnel-able over SSH. Clients are optionally linked with ssh libraries and can tunnel themselves.
- The architecture and protocols could be designed to fully mesh backends, so that for example backend instance A (securely) connected to B and C; B to A and C; C to A and B.. then by connecting to any of the backends, the client would be aware of any windows in all the instances (permission permitting of course).
Again, just daydreaming. :) On Apr 4, 2005, at 12:59 PM, Xavier Nicollet wrote:
Le 11 janvier 2005 à 11:43, jmartin a écrit:I've also contemplated separating out the display logic from the backend pty logic into more of a client-server model to achieve two goals: first, to build non-terminal front-ends, like a tabbed terminal emulator in X, oran OSX Cocoa tabbed terminal; second, to securely (ssh?) interconnect screen backends, so that you could bridge two (or more) hosts running screen, and switching between screens on different hosts would be transparent.Great ! I don't know if it would be very easy with the current screen codebase. -- Xavier Nicollet http://nicollet.jeru.org/
[Prev in Thread] | Current Thread | [Next in Thread] |