moved to manual/BasicClasses.texi

git-svn-id: svn+ssh://svn.gna.org/svn/gnustep/libs/gui/trunk@19599 72102866-910b-0410-8b05-ffd578937521
This commit is contained in:
Adrian Robert 2004-06-22 23:19:22 +00:00
parent ec193a7d5c
commit 33d5d9c1c0

View file

@ -1,100 +0,0 @@
<?xml version="1.0"?>
<!DOCTYPE gsdoc PUBLIC "-//GNUstep//DTD gsdoc 0.6.6//EN" "http://www.gnustep.org/gsdoc-0_6_6.xml">
<gsdoc base="Introduction" next="NSActionCell.html" up="Gui.html">
<head>
<title>Introduction to the AppKit</title>
<author name="Nicola Pero">
<email address="n.pero@mi.flashnet.it"/>
<desc>
At present, I am the only one to blaim for any error in this
text.
</desc>
</author>
<version>$Revision$</version>
<date>$Date$</date>
<abstract>
A short and simple introduction to the GNUstep GUI API.
</abstract>
</head>
<body>
<front>
<contents/>
<chapter>
<heading>Preface</heading>
<p>
This is a simple introduction to the GNUstep GUI library
API. If you know nothing about the OPENSTEP AppKit, it
could be a good idea to read this before you start reading
the reference documentation.
</p>
<p>
I am very interested in comments regarding this text,
particularly from people who are new to the OPENSTEP
AppKit API. Send comments and/or suggestions to
Nicola Pero (n.pero@mi.flashnet.it).
</p>
</chapter>
</front>
<chapter>
<heading>Basic Classes</heading>
<section>
<heading>NSView</heading>
<p>
NSView is the class of objects representing a
rectangular area (usually in a window) with its own
coordinate system. Views have methods to draw inside
the view, to change the view's coordinate system, and to
place the view with arbitrary position and size inside
another view. When you place a view inside another
view, you are technically making the smaller view a
<em>subview</em> of the bigger view. The whole drawable
area inside the window itself is represented by a view,
called the <em>content view</em>. All the visible views
in a window are then subviews of the content view of
that window (or of the content view's subviews etc).
This gives rise to what is called the "view tree" of the
window.
</p>
</section>
<section>
<heading>NSCell</heading>
<p>
NSCell is the class of objects representing a single
amount of displayable data. For example, a cell could
represent a number, or a string, or an image. Cells
have methods to draw the data they represent in a view,
to change the way the data is to be drawn (eg the font
for a string or the border for an image), and to let the
user interact directly (eg editing the data) with the
data in a view.
</p>
</section>
<section>
<heading>NSControl</heading>
<p>
NSControl is the class of objects representing a view
(i.e., a rectangular area in a window) used to manage
one or more cells (i.e., some displayable data). This
class is usually designed to work with a subclass of
NSCell, called <em>NSActionCell</em>, through a system
of target/action. Each actioncell has a <em>target</em>
- an object - and an <em>action</em> - a selector - both
of which can be arbitrarily set. The control can then
ask the cell to send its action to its target (ie, to
invoke the method of the target object identified by the
selector) as a consequence of user actions in the
control. The typical example is a button: a button is a
control with a corresponding cell; when the user presses
the button, the buttoncell sends its action to its
target. Controls are the high-level objects the you
usually deal with when designing everyday-life user
interfaces. You do not usually need to bother about
cells, because the controls manage the cells for you.
</p>
</section>
</chapter>
</body>
</gsdoc>