Re: (no subject)

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/