Re: (no subject)

[jmartin]

Sorry to flood everyone, but I wanted to add one thing. Architecting 
screen into front-end-back-end wouldn't necessarily mean that it would 
require a windows front-end. Actually, what I would envision is that 
screen-5.x itself would have much the same functionality as it does today, 
as in strictly terminal based. Internally however it would be modularized 
so that other front-ends besides the one it comes with could be created. 
Those third-party clients could link against, let's say libscreen, and use 
any gui toolkit imaginable (for that matter, if the protocol to speak to a 
screen back were well-known enough, an app wouldn't even necessarily have 
to link against an official screen library, it could just 'speak' screen 
to a socket, and be written in any language, say Java).

I don't want to scare anyone by implying that screen should move into the 
windowing world, just allow for it.  :)





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);}