Update the screen_internal document.
authorRui Guo <firemeteor.guo@gmail.com>
Wed, 20 May 2009 17:24:25 +0000 (21 01:24 +0800)
committerRui Guo <firemeteor.guo@gmail.com>
Wed, 20 May 2009 17:24:25 +0000 (21 01:24 +0800)
Finish most of the third section (important objects).

src/drafts/screen_internal

dissimilarity index 99%
index 11d30d9..f02339e 100644 (file)
@@ -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.
+
+