Re: (no subject)

[jmartin]

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. :)




On Wed, 12 Jan 2005, Michael Schroeder wrote:

> On Wed, Jan 12, 2005 at 02:41:17PM -0500, jmartin wrote:
> > I guess it wouldn't be too difficult to take existing screen code and hack
> > it into a GUI. Whatever code allows one instance of screen to reconnect
> > (-x) to the already persistant screen session could be integrated into a
> > GUI. But that's far from an actual API.
>
> The important thing is that IMHO the backend shouldn't talk to the
> X server, but to the frontend process which does all the displaying.
> I want to keep the backend simple and stable, I don't want it to
> be linked against Xlib.
>
> Cheers,
>  Michael.
>
> --
> Michael Schroeder           address@hidden
> main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}