From 70f304dd2be75dacd85d690d12aa36cc1f0f324b Mon Sep 17 00:00:00 2001 From: Rui Guo Date: Thu, 21 May 2009 01:24:25 +0800 Subject: [PATCH] Update the screen_internal document. Finish most of the third section (important objects). --- src/drafts/screen_internal | 99 +++++++++++++++++++++++++++++++++++++--------- 1 file changed, 81 insertions(+), 18 deletions(-) rewrite src/drafts/screen_internal (99%) diff --git a/src/drafts/screen_internal b/src/drafts/screen_internal dissimilarity index 99% index 11d30d9..f02339e 100644 --- a/src/drafts/screen_internal +++ b/src/drafts/screen_internal @@ -1,18 +1,81 @@ -A display stands for an attached display area. Since there can be multiple -users, the possibly multiple displays are chained together in a single -linked-list 'displays'. - -Canvas is a place to draw on. They logically belong to a specific display. -However, a display can be further divided to several sub-regions. As a result, -The regions need corresponding canvases. Moreover, the way that a display is -organised can be saved by layout object. - -Each window in screen stands for a sub-terminal that runs inside screen. -When shown in foreground, the window draws a layer on the showing canvas. -A layer can be drawn on multiple canvas, either in different regions or in -different displays. So it also make sense to call it 'view'. However, the name -layer tells us that it's stackable. One can add an overlay to the existing -one, such as the help page. - -Finally, to ease the clipping of layer, there is also a viewport object to -track the boundary of each canvas. (But why not the canvas itself?) +I. Disclaimer + +This document includes some of my personal understanding about the internal +structure of GNU Screen. It's written to serve as a remainder to myself. I +hope that it can help those not familiar with GNU Screen already. But be aware +of any possible mistake in this document. + + +II. Architecture + +GNU Screen works in a client-server way. The two participants are called +front-end and back-end respectively, sharing the same code base. When an +instance of Screen launches, the command line arguments determines the role +and the corresponding action. + +Front-end send requests to back-end through a named-pipe or socket. And the +back-end gives feed back by signal. The requests include attach, detach, +resize, window create and command execution. The front-end does nothing more +than send requests and act upon responses. When there are no such events, it +simply sleeps to kill it's boring time. All other works are handled by the +back-end. + + +III. Important objects + +There are several kinds of objects in Screen. Here are some of them. + +A. Display + +A Display stands for an attached display area. It corresponds to the real user +tty that the attaching front-end runs in. Since there can be multiple users +(or multiple attach from the same user), the possibly multiple displays are +chained together in a single linked-list 'displays'. An Display object +contains many global statuses and flags (terminal modes & flags etc.), also +includes some events such as tty read & write. + +B. Canvas, Viewport & Layout + +Canvas is a place to draw contents on. They logically belong to a specific +display. However, a display can be further divided to several sub-regions, +using the split command. As a result, the regions need corresponding canvases. +Moreover, the way that a display is organised can be saved by Layout object. +All Layout objects are linked together as a list. The active layout used by +Display is stored with it. The canvas in a display that has input focus is +called forecv. + +To track the Canvases in a Display, Screen uses a two-dimensional link list. +One list link (slnext & slprev) together all adjacent Canvases that are +spitted in the same direction. The other is the stacking direction, or the +Z-axis in 3D graphics. All such adjacent Canvases shares one container Canvas, +which is inserted when a split with different direction is about to happen. +Each Canvas points to it's container using slback and a container points to +one of its random child using slprep. This structure actually link the +Canvases together as a tree, which is very helpful when doing free and resize. + +Finally, to ease the clipping when drawing in the canvas, there is also a +viewport object to track the boundary of each canvas. (But why not the canvas +itself?) + +C. Window & Layer + +Each Window in screen stands for a pseudo-terminal (or telnet connection, +depending on the type of window) that runs inside screen. All relevant +statuses and events are stored in this object. Many Windows can be shown in +Display at once, the one that has input focus is called the fore Window. + +To be shown in Canvases, a Window needs a object called Layer. A Layer can be +drawn on multiple Canvases, either in one Display or in different Displays. So +it also make sense to call it 'view'. However, the name Layer tells us that +it's stackable. One can add an overlay to the existing one, such as the help +page. Each Layer contains an operation function structure, providing important +operation to process the input, draw line, clear, redraw, resize, abort and +restore etc. + +E users & ACL + +TODO + +IV. Event dispatching. + + -- 2.11.4.GIT