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, or
an 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/
_______________________________________________ screen-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/screen-users
