mirror of https://github.com/tLDP/LDP
updated
This commit is contained in:
parent
6beaab6302
commit
4da42a3bfd
|
@ -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>
|
||||
|
|
Loading…
Reference in New Issue