Re: (no subject)

[Brian Mathis]

jmartin wrote:
> Exactly my point. If screen were to be somewhat client/server, the 
> backend would be a fairly static and simple server. It would be roughly 
> the same across platforms, and do nothing more than manage ptys, state 
> info, etc. The front-end clients on the other hand could be any wild mix 
> of libs -- xlib, cocoa under OSX, wxwindows, win32, etc. Furthermore, if 
> the method of communicating between client/server were TCP, the clients 
> could not only be remote, but platform independant. I guess at this 
> point it becomes a really fancy virtual terminal server. :)

Yeah, this is a great idea.  A wrench in the works though is security. 
Somehow you'd need to be able to do this via ssh.

I know you can forward ports in ssh, but that's a nasty hack for 
frequent use.  It'd be a real pain to have to log-in twice to a machine 
you wanted to screen on (login via ssh, then start your screen-gui).

A possibly lighter-weight alternative could be to have your client be 
able to discover what windows you have open, ala "^A w", then display a 
tab for each window.  It could switch between them by inserting "^A #" 
(#=tab number).  Seems pretty simple to me, though it would all be on 
the client side.