LDP
/
LDP
mirror of https://github.com/tLDP/LDP
0
1
Fork 0
Code Releases Activity

updated

This commit is contained in:
gferg 2001-05-23 22:50:25 +00:00
parent 6beaab6302
commit 4da42a3bfd
1 changed files with 14 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

19
LDP/howto/docbook/XWindow-Overview-HOWTO.sgml
View File

@ -12,6 +12,14 @@
</author>
<revhistory>
<revision>
<revnumber>1.0.1</revnumber>
<date>2001-05-22</date>
<authorinitials>dm</authorinitials>
<revremark>
Some grammatical corrections, pointed out by Bill Staehle
</revremark>
</revision>
<revision>
<revnumber>1.0</revnumber>
<date>2001-05-20</date>
@ -53,7 +61,7 @@ are provided.
</para>
<para>
This document is, deliberately, not too technically oriented. It's
based on the author's (empyrical) knowledge of the subject, and while
based on the author's (empirical) knowledge of the subject, and while
it's primarily meant as a non-technical introduction, it can certainly
benefit from any kind of comments, further examples and explanations,
and technical corrections. The author welcomes all questions and
@ -83,10 +91,11 @@ other inherently graphical data).
<para>Historically, UNIX has had a lot of improvements done by
academic types. A good example is the BSD networking code added to it
in the late 1970's, which was, of course, the product of work at
the University of California at
Berkeley. As it turns out, the X Window System (also called X, but
never X Windows), which is the foundation for most GUI subsystems
found in modern UNIX (unices?), Linux and the BSD's included, was also
the result of an academic project, namely the Athena project at MIT.
the result of an academic project, namely the Athena project at the Massachusetts Institute of Technology (MIT).
</para>
<para>Unix has been a multiuser, multitasking, timesharing operating
system since its beginnings. Also, since the incorporation of
@ -162,7 +171,7 @@ work done.
<para>At this point everything seems to be working fine. We have a
server in charge of visual output and data input, client applications,
and a way for them to communicate between each other. In picturing a
hypotetical interaction between a client and a server, the client
hypothetical interaction between a client and a server, the client
could ask the server to assign a rectangular area on the screen. Being
the client, I'm not concerned with where i'm being displayed on the
screen. I just tell the server "give me an area X by Y pixels in
@ -202,7 +211,7 @@ which support different ways for the user to interact with windows and
different styles of window layout, decoration, and keyboard and
colormap focus."
</para>
<para>The X architecture provides with ways for a window manager to
<para>The X architecture provides ways for a window manager to
perform all those actions on the windows; but it doesn't actually
provide a window manager.
</para>
@ -414,7 +423,7 @@ possible. Going back to the policy/mechanism paradigm, the MacOS
provides mostly policies. Mechanisms are there, but they don't
encourage people to play with those. As a result I lose versatility;
if I don't like the way MacOS manages my windows, or the toolkit
doesn't provide a function I need, i'm pretty much out of luck. This
doesn't provide a function I need, I'm pretty much out of luck. This
doesn't happen under X, altough as seen before, the price of
flexibility is greater complexity.
</para>