[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: (no subject)
Re: (no subject)
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
- 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
pty logic into more of a client-server model to achieve two goals:
to build non-terminal front-ends, like a tabbed terminal emulator in
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
I don't know if it would be very easy with the current screen codebase.
- Re: (no subject), Xavier Nicollet, 2005/04/04
- Re: (no subject),
Jonathan Martin <=