[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: (no subject)

From: jmartin
Subject: Re: (no subject)
Date: Wed, 12 Jan 2005 16:27:59 -0500 (EST)

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.


Michael Schroeder           address@hidden

reply via email to

[Prev in Thread] Current Thread [Next in Thread]