The summaries stress on describing what the class is commonly used
for and what other classes are designed to cooperate with the class.
The classes are presented in alphabetical order. Some classes that
are closely related and have symbol-names (>, +) are
combined into one description, sometimes violating the alphabetical
order.
- :=()
-
Instances of this class are used to specify named arguments, see
section 2.4. Example:
...,
send(Editor, style,
sensitive, style(underline := @on,
colour := dark_green)),
...,
- ==()
-
- \==()
-
Conditional code object that succeeds if both arguments evaluate to the
same object. Normally used to specify the conditions of if
or
while. The following
example yields the names of all user-defined classes:
?- new(UDC, chain),
send(@classes, for_all,
if(@arg2?creator \== built_in,
message(UDC, append, @arg1))).
- ?()
-
Class ?, pronounced as
`obtainer', represents a `dormant' get-operation. Obtainers are commonly
used to `obtain' arguments for other code objects. For example:
...,
send(Dialog, append,
new(TI, text_item(name))),
send(Dialog, append,
button(ok, message(Dialog, return, TI?selection))),
- @=()
-
Class @= assigns a symbolic
reference name to the argument object. It is used to define global
objects in the class-variable display.initialise. See the system
defaults file
<pcehome>/Defaults. The following example
from Defaults creates the objects @_dialog_bg
and @_win_pen depending on whether
or not the display is monochrome or colour.
display.initialise: \
and(_dialog_bg @= when(@colour_display, \
grey80, white), \
_win_pen @= when(@colour_display, \
0, 1))
- and()
-
Code object that executes its arguments one by one. It fails as soon as
one of the arguments fails and succeeds otherwise. Commonly used to
specify multiple actions for controllers. For example:
...,
get(Dialog, frame, Frame),
send(Dialog, append,
new(Function, text_item(function))),
send(Dialog, append,
button(switch_to,
and(message(Frame, switch_to,
Function?selection),
message(Function, clear)))),
...,
- application()
-
An application object is a visual
object used to combine multiple frames.
See section 10.5 for a
discussion on its usage.
- arc()
-
Graphical primitive describing a section from a circle. It may be used
to create a pie-chart segment.
?- new(A, arc(100, 20, 50)),
send(A, close, pie_slice).
- area()
-
Combination of X, Y, Width and Height
used by
graphical to store
the bounding box of the graphical. Also used to communicate with
graphical objects and frames about their dimension.
...,
get(Box, area, area(X, Y, W, H)),
...,
- arrow()
-
Arrow-head. Normally only used implicitly to attach arrows to a
line, arc
or path, the subclasses
of class
joint. See `joint
->arrows'. arrow
can be used directory to create fancy arrows.
?- new(L, line(0, 0, 100, 50, second))
- assign()
-
Assign a value to an instance of class var,
an XPCE variable. Used to realise variables in
compound executable objects.
and(assign(new(C, var), @arg1?controller),
message(C, ...),
message(C, ...),
...)
- attribute()
-
Attributes can be associated with any object to store data related to
that object without the need to create a subclass. Normally attribute
objects are used implicitly through the method
`object
<->attribute'.
send(Frame, attribute, visualises, bicycle24)
- behaviour()
-
Super class of method
and variable,
representing the two types of objects that can realise behaviour in
classes. Not useful for the application programmer.
- bezier_curve()
-
Create a Bezier curve from start to end using one
or two control-points (quadradic or cubic Bezier curve). Bezier curves
are nice smooth curves departing and arriving in a specified direction.
See also path.
- binary_condition()
-
- <()
-
- =()
-
- =<()
-
- >()
-
- >=()
-
Arithmetic conditional code objects. These objects are normally used to
specify the conditions of if
or while. The following
example creates a chain
holding all graphicals on a device that either have
<-width <
5 or <-height < 5.
...,
get(Device?graphicals, find_all,
or(@arg1?width < 5,
@arg1?height < 5),
SmallGraphicals),
...,
- binary_expression()
-
- *()
-
- +()
-
- -()
-
- /()
-
Arithmetic functions, commonly used for computation of graphical
dimensions or to specify spatial relations using class spatial
or for simple functional computation from Prolog. For example:
...
send(Box, height, Text?height + 10),
...
- bitmap()
-
A bitmap turns an image
or pixmap into a
graphical object that can be displayed on a device.
?- new(I, image('pce.bm')),
new(B, bitmap(I)).
- block()
-
A block is similar to and,
but provides formal parameters.
?- send(block(new(A, var),
new(B, var),
message(@pce, write_ln, A, B)),
forward, hello, world).
hello world
- bool()
-
Class bool defines two
instances: @on and @off,
representing `true' and `false'. The use cannot create instances of this
class.
...,
send(Image, transparent, @on)
...
- box()
-
Graphical representing a rectangle. Corners can be rounded, the interior
can be filled, the texture and thickness of the line can be controlled
and a shadow can be defined.
?- new(B, box(100, 50)),
send(B, radius, 10).
- browser()
-
A browser is a window
version of a list_browser.
A browser visualises a list of dict_item
objects. The items are organised in a dict,
providing fast access to browser items, even if there are many items in
the browser. Individual items may be coloured, underlined, etc. using
the style mechanism also
available for editor.
Columns can be realised using tab_stops on the text_image
object that displays the actual text of the browser.
?- new(B, browser),
send_list(B, append, [gnu, gnat]).
- browser_select_gesture()
-
Internal class dealing with selection handling in class
list_browser.
- button()
-
A button is a push-button controller. It has an associated
message that is
executed if the button is activated using the mouse. Inside a dialog,
one button can be assigned as `default' button.
?- new(B, button(hello,
message(@pce, write_ln, hello))).
- c()
-
Class c is a subclass of
class host, providing
communication to C and C++ code. It is not used directly by the
application programmer.
- c_pointer()
-
Class c_pointer
encapsulates an anonymous C pointer (void *). It is used to
register references to Prolog predicates with XPCE
methods. See also chapter 7.
?- pce_predicate_reference(gnat:gnu(_,_), X).
X = @1190997/c_pointer
- chain()
-
Class chain represents a
single-linked list of arbitrary objects. Chains are commonly used inside XPCE
to represent collections. Chains have methods to find elements, sort the
chain, delete elements, etc. The predicate chain_list/2
converts between an XPCE chain and a Prolog list.
It also provides methods to run code on all elements of the list, which
is generally faster than translating the chain to a Prolog list and
using Prolog iteration. In the example, `device
<-graphicals'
returns a chain holding the graphicals displayed on the device. The
example changes the font of all objects of class text
to `bold'.
...,
send(Device?graphicals, for_all,
if(message(@arg1, instance_of, text),
message(@arg1, font, bold))),
...
- chain_hyper()
-
Link two objects with a `chain'. If either dies, the other will die with
it. See also the library
library(hyper) and section
10.11.
- chain_table()
-
Version of a hash_table
that allows multiple values to be associated with the same key. The key
can be any object. If the value for a key is requested, a chain of
values associated with this key is returned.
- char_array()
-
Class char_array is
a super-class of the classes string,
representing modifiable text and name,
representing read-only unique textual constants. Class char_array
defines most of the analysis methods for its two subclasses. Almost the
only usage of this class for application programmers is as type
specifier for methods in user-defined classes that do not modify textual
arguments.
insert_bold_text(Editor, Text:char_array) :->
"Insert text with fragment of bold text"::
get(Editor, caret, Start),
send(Editor, insert, Text),
get(Editor, caret, End),
Len is End-Start,
new(_, fragment(Editor, Start, Len, bold)).
- circle()
-
Equivalent to an ellipse with the same
<-width
and <-height. Not used frequently.
- class()
-
All XPCE classes are represented by an instance of
class class. A class is
a normal object and can thus be manipulated using
send/[2-12], get/[3-13]
and new/2.
Classes are normally only created and modified through the user-defined
class layer described in
chapter 7. Get methods on classes are
used to extract meta-information about its instances, as exploited by
the online manual tools.
?- get(@pce, convert, box, class, ClassBox),
get(ClassBox, super_class, X).
X = @graphical_class/class.
- class_variable()
-
A class_variable
provides can be used to describe class properties as well as to provide
access to the XPCE
Defaults database. Typically, class-variables are defined
similar to instance-variables in the XPCE/Prolog
class definition:
:- pce_begin_class(title_text, text).
class_variable(font, font, huge, "Default font for titles").
...
- click_gesture()
-
Class click_gesture
is a recogniser
that parses button-events to a click. If the click is detected, it will
execute the associated message. This class is normally used to make
graphical objects sensitive to clicks.
...,
send(Bitmap, recogniser,
click_gesture(left, double, message(Bitmap, open))),
...
- code()
-
Class code is a
super-class for all `executable' objects. An important sub-class is
class function,
representing executable objects that yield a value. The method `code
->forward:
any ...' pushes the var
objects @arg1, ... and then executes
the code object. Code objects are often associated with controllers to
describe the action the controller should perform. They also serve the
role of lambda functions. See also section
10.2.
?- send(message(@prolog, format, 'Hello ~w.', @arg1),
forward, world).
Hello world.
- code_vector()
-
A code_vector is a
subclass of class vector
that can represent functions as well as normal objects. It is used for
packing multiple arguments passed to a variable-argument method. Do not
use this class directly. See section
7.5.2.
- colour()
-
A colour represents an
`RGB' triple.21Colour screens
create their colour by mixing the `primary' colours `red', `green' and
`blue'. With an `RBG' triple, we refer to a triple of three numeric
values representing the intensities of the three primary colours
Colours are used as attributes to graphicals, windows, styles
and
pixmaps
- colour_map()
-
Manipulate the colourmap. Colourmaps are normally left untouched, but
using a 256 entries colour palette in MS-Windows they can be used to
improve full-colour image rendering. See also section
10.10.1.
- connect_gesture()
-
A connect_gesture
allows the user to connect two graphicals by dragging from the first to
the second. This requires two graphicals with handless
attached, a link that is
compatible with the handles and a connect_gesture
associated width the graphical at which the connection should start. The
demo program PceDraw as well as the XPCE Dialog
Editor described in chapter A
exploit connections and connect_gestures.
- connection()
-
A connection is a
line between two graphical objects that automatically updates on
geometry, device and displayed-status changes to either of the connected
graphicals. Both of the graphicals must have one or more handles
associated with them. The connection can be attached to a specific
handle, or to any handle of the proper
`handle
<-kind'.
In the latter case, the system will automatically choose the
`best-looking' handle.
- constant()
-
A constant is a
unique handle. XPCE predefines the following
constants: @nil, @default,
and from the subclass bool, @on
and @off. The use can define additional
constants and give them their own unique meaning. The most obvious usage
is to indicate a slot that can hold arbitrary data including @nil
and @default is in a special state.
?- new(@uninitialised,
constant(uninitialised,
'Not yet initialised slot')).
- constraint()
-
A constraint is a relation between 2 objects that has to be maintained
if either of the objects is changed. The `constraint
<-relation'
is a description of the relation maintained by the constrained. The
system defines the relations identity
(both objects have an attribute that has same value) and spatial
(general purpose geometry-relation between two (graphical) objects. It
is possible to define new relation
classes. Constraints are getting out of fashion as XPCE
lacks a good mechanism to detect when an object has been changed and
therefore evaluates the relation far too often. User-defined classes,
possibly combined with hyper
objects form an attractive alternative. The following keeps a text
centered in a box.
...,
new(_, constraint(Box, Text, identity(center))),
...
- create()
-
Function that creates an instance of a class. It is often required if a
code fragment executed by an `iterator' method such as `chain
->for_all'
has to create objects. The following code generates dict_items
from all send_methods
of the specified class and displays them to a browser.
send_methods_of_class(ClassName) :-
new(B, browser(ClassName)),
get(@pce, convert, ClassName, class, Class),
get(Class, send_methods, SendMethods),
send(SendMethods, for_all,
message(B, append,
create(dict_item,
@arg1?name,
@default,
@arg1))),
send(B, open).
- cursor()
-
A cursor defines the
shape that indicates the position of the
pointer (also called mouse).
The system provides a large set of predefined cursors from X11.
The Win32 version adds the standard Windows cursors to this set. Cursors
can also be created from an image.
The demo program Cursors displays all defined cursors.
Cursors can be associated with graphicals and windows using the ->cursor
method. They are also associated to gestures,
where they define the cursor that is visible while the gesture is active
(i.e. while the mouse-button that activated the gesture is down).
Type-conversion converts names into cursor objects. Explicit creation
of cursors is rarely used.
...,
send(Box, cursor, gobbler),
...
- date()
-
A date objects represents
a point in time. The underlying representation is the POSIX file
time-stamp: seconds elapsed since 00.00, Jan 1-st, 1970. This limits the
applicability of this class to time-stamps of computer resources
(files), agenda systems and other domains that do not require a
granularity below 1 second or have to represent time-stamps in far
history or future. Class date
can parse various textual representations into date objects.
?- send(@pce, format, 'It is now "%s"\n',
new(date)?string).
It is now "Tue Jan 30 14:07:05 1996"
- device()
-
A graphical device is a compound graphical.
It is the super-class of class window.
It is a sub-class of graphical,
which implies devices can be used to create a consist-of structure of
graphical objects, giving structure to a diagram. Devices are commonly
refined to establish user-defined graphics,
see section 10.12. See also
class figure.
make_icon(Icon, Image, Label) :-
new(Icon, device),
send(Icon, display,
new(BM, bitmap(Image))),
send(Icon, display,
new(T, text(Label, center))),
send(T, y, BM?bottom_side),
send(T, center_x, BM?center_x).
- dialog()
-
A dialog is a window
specialised for the layout and message handling required by dialog_items,
the super-class of the XPCE controllers.
In most cases, controller-windows are created by simply
->appending
a number of controllers to a dialog window. The frame-
and dialog-layout
services take care of proper window sizes and layout of the controllers.
Dialog windows are also involved in forwarding ->report
messages (see section 10.7) and
keyboard accelerators, handling the default button.
:- pce_autoload(file_item, library(file_item)).
edit_file_dialog :-
new(D, dialog('Edit File')),
send(D, append,
file_item(edit_file, '')),
send(D, append,
button(edit, message(@prolog, emacs, @arg1))),
send(D, append,
button(cancel, message(D, destroy))),
send(D, open).
- dialog_group()
-
A dialog_group is
a collection of dialog_items.
Dialog groups may be used to realise a (labeled) box around a group of
controllers, or to combine multiple controllers into a compound one for
technical or layout reasons. See also tab.
- dialog_item()
-
Class dialog_item
is a super-class of all XPCE controllers. It
contains the code necessary to negotiate geometry with its neighbours
and enclosing dialog
window and provides default fonts for the label, etc. Class graphical
defines similar methods to allow integration of raw graphical objects
into dialog windows easily, but
graphical uses the
more expensive object-level attributes for storing the necessary status.
Open the class-hierarchy below class
dialog_item to
find all available controllers.
- dict()
-
A dict is an abbreviation
of dictionary. Dicts map keywords to dict_item
objects. Small dicts simply use a linear list (chain)
of items. Large dicts will automatically built a
hash_table for
quick lookup on the first request that profits from the availability of
a table. A dict provides the storage for a
list_browser. See
also class browser.
- dict_item()
-
Item in a dict. The key
is used for lookup. label is the text displayed by the browser
(@default uses the key).
Object is an arbitrary object that can be associated to the
dict. If a dict presents a set of XPCE objects, it
is common practice to extract the key and or label from the object and
store the object itself in the
`dict_item
<->object'
slot.
A name is translated
to a dict_item using the name as key, default label and @nil
object. `dict_item<->style'
can be used to give an item special attributes (colour, font, etc.).
- directory()
-
A directory
represents an node (folder) in the
computer's file-system. Directories are most commonly used to enumerate
the files and sub directories. Directory objects can also be used to
create or delete directories from the file-system.
?- get(directory(.), files, Files).
- display()
-
A display represents
what X11 calls a screen, a desktop on which
windows can be displayed with a mouse and keyboard attached to it.
XPCE support multiple display instances under X11
and only the predefined default display @display
under Win32. The display implements a number of global operations:
getting the screen
<-size, showing modal message
boxes using ->inform and ->confirm,
etc.
?- get(@display. size, size(W, H)).
W = 1024, H = 786
- display_manager()
-
The object @display_manager
is the only instance of this class. It represents the collection of
available display
objects and provides access to the system-wide event-dispatching
services. It is the root of the consist-of hierarchy of visual
objects as displayed by the Visual Hierarchy tool.
- edit_text_gesture()
-
Used internally to handle selection inside a text
object. See also the library
library(pce_editable_text).
- editor()
-
An editor is a
general-purpose text editor. It is a graphical. Class view
provides a window-based version of the editor. XPCE's
editors have commands and key-bindings that are based on
GNU-Emacs. Editors are fully
programmable. The associated
key_binding object
parses key-strokes into commands that are defined as methods on the
editor.
An editor is a compound object and a subclass of device.
The other components are a text_image
to form the actual display, a
text_buffer to
provide the storage for the text, elementary operations on the text and undo,
a text_cursor to
indicate the location of the caret, and optionally a text_margin
to visualise the presence of annotations.
A single text_buffer
can be associated with multiple
editor objects,
providing shared editing.
Editors can handle sensitive regions, different fonts, colours and
attributes using fragment
objects. All text windows in XPCE's demo programs
(PceEmacs, cards from the online help, application help, etc.) either
use class view or class editor to display the text.
- elevation()
-
An elevation object
describes an elevated region on the screen. Elevations come in two
flavours: as a shadow for monochrome displays and using light and dark
edges on colour displays. The elevation object itself just contains the
colour definitions. The actual painting is left to the graphical object
the elevation is attached to.
Most controllers handle elevations. The only general purpose
graphical supporting an elevation is figure.
- ellipse()
-
Elliptical shape. Class ellipse
defines similar attributes as
box: pen, texture,
fill_pattern and shadow. See also
circle.
- error()
-
An error object
represents a runtime message. Whenever an error is trapped or a message
needs to be displayed, the system will invoke
`object
->error:
id, context ...' to the object that trapped the error. If this method is
not redefined, the system will report the error using the `object->report'
mechanism described in section 10.7.
Errors can be prevented from being reported using pce_catch_error/2.
The
Error Browser of the online manual shows all defined
errors.
The development system will report errors that are considered
`programming errors' (undefined methods, type violations, invalid object
references, etc.) to the terminal and start the tracer. See also
section 12.
- event()
-
An event represents an
action from the application user: pressing a key, moving the mouse,
pressing a mouse-button, or entering or leaving an area with the mouse.
The main loop of XPCE will read window-system
events from the computing environment (X11 or Win32). If the event
concerns a repaint or similar system event, it will be handled
appropriately. If it can be expressed as an XPCE
event, an
event object will be
created and send to the window for which the event was reported by the
system using the method `event
->post'.
Graphical objects and windows can redefine their event handling using
two mechanisms: by redefining the ->event method
or by associating a recogniser
object using `graphical->recogniser'.
Normally, XPCE will read and dispatch events
when `there is nothing else to do'. For processing events during
computation, see `graphical
->synchronise' and `display->dispatch'.
- event_node()
-
An event_node is a
node in the event `is_a' hierarchy. See the demo program Events.
Event-types are normally tested using
`event
->is_a'.
event(Dev, Ev:event) :->
"Forward all keyboard events to the text"::
( send(Ev, is_a, keyboard)
-> get(Dev, member, text, Text),
send(Ev, post, Text)
; send(Dev, send_super, event, Ev)
).
- event_tree()
-
Event `is_a' hierarchy. The only instance is @event_tree.
- figure()
-
A figure is a
refinement of a device.
It is a compound graphical, but in addition can define a background,
surrounding box with margin, possibly rounded corners and elevation
and a
clipping region. Finally, figures may be
used not only to display all member graphicals, but also to show `one
of' the member graphicals only. See `figure
->status'.
An example of the usage of figures are the `object cards' of the Inspector
tool.
- file()
-
An XPCE file
object represents a file on the computers file-system. It can be used to
specify a file, query a file for various attributes, read a file, etc.
See also directory.
?- get(file('summary.doc', size, Size).
Size = 30762
- font()
-
A font is a reusable
object that describes the typeface of text.
Section 10.9 documents the
specification of physical and logical fonts.
...,
send(Text, font, bold),
...
- format()
-
A format describes the layout of graphicals
on a
device. It can specify
`tabular' and `paragraph'
style layout. A format itself just specifies the parameters, `device
->format' actually realises the format.
- fragment()
-
A fragment defines a
region of text in a text_buffer
using a start-position and a length. Fragments are automatically updated
if the contents of the text_buffer changes. A fragment can be assigned a
logical `category', called `style'. The editor
visualising the text_buffer maps the style-names of fragments into
style objects using `editor
->style'.
...,
send(Editor, style, title, style(font := huge)),
new(_, fragment(Editor, Start, Len, title)),
...
- frame()
-
A frame is a collection
of tiled
windows. Frames handle the layout, resizing, etc. of its member windows.
Any XPCE window is enclosed in a frame, though it
is often not necessary to specify a frame explicitly. Applications are
often implemented as subclasses of frame. Section
10.6 describes the layout of windows inside a frame.
...,
new(F, frame('My application')),
send(F, append, new(B, browser)),
send(new(P, picture), right, B),
...
send(F, open).
- function()
-
A function is a code
object that yields a value when executed. See section
10.2.2.
- gesture()
-
Class gesture is the
super-class for the recogniser
classes that deal with the sequence mouse-button-down ... dragging ...
mouse-button-up. This super-class validates the various conditions,
handles the cursor and focus and activates the
->initiate,
->drag and ->terminate
methods that are redefined in its subclasses. This class is often
sub-classed.
- get_method()
-
Specification of get-behaviour that is associated with a class using
`class
->get_method'
or with an individual object using `object
->get_method'. Normally specified through the
preprocessor layer defined in chapter 7.
- graphical()
-
The most generic graphical object. This class defines generic geometry
management, display, update, event-handling, etc. This class can be
sub-classed to defined specialised graphics. See section
10.12.
- grbox()
-
Embed a graphical in a parbox.
Using
left or
right alignment, grbox
can also be used to have text floating around graphical illustrations.
See section 11.10.
- handle()
-
A handle defines a
typed and named position on a graphical used by connections to connect
to. The positions are formulas expressed in the with and height of the
graphical. The following definitions are encountered regularly:
:- pce_global(@north_handle,
new(handle(w/2, 0, link, north))).
:- pce_global(@south_handle,
new(handle(w/2, h, link, south))).
:- pce_global(@east_handle,
new(handle(0, h/2, link, east))).
:- pce_global(@west_handle,
new(handle(w, h/2, link, west))).
- handler()
-
A handler is the most
primitive recogniser,
mapping an event-type to a message. Since the introduction of the more
specialised
gesture and key_binding
as well as the possibility to refine the `graphical
->event'
method, it is now rarely used.
...,
send(Graphical, recogniser,
handler(area_enter,
message(Graphical, report,
'Hi, I''m %s',
Graphical?name))),
...
- handler_group()
-
A handler_group
is a compound recogniser
object. When asked to handle an event, it will try each of its members
until one accepts the event, after which it will return success to its
caller. The following defines a combined move- an resize-gesture. Note
the order: resize gestures only activate close by the edges of the
graphical, while move gestures do not have such a limitation.
:- pce_global(@move_resize_gesture,
new(handler_group(new(resize_gesture),
new(move_gesture)))).
- hash_table()
-
A hash_table is a
fast association table between pairs of objects. For example, @classes
is a hash_table mapping class-names into class objects. Names are often
used as keys, but the implementation poses no limit on the type
of the key.
?- new(@ht, hash_table),
send(@ht, append, gnu, image('gnu.img')).
?- get(@ht, member, gnu, Image).
- hbox()
-
Superclass of tbox and grbox
dealing with document-rendering. Instances of hbox
itself can be used to define `rubber'. See section
11.10 for details.
- host()
-
Class host represents the host-language,
Prolog for this manual. It predefines a single instance called @prolog.
Sending messages to @prolog calls
predicates. See also section 6.
?- send(@prolog, write, hello).
hello
- host_data()
-
Support class for passing data of the host-language natively around in
XPCE. The Prolog interface defines the subclass
prolog_term and the interface-type
prolog.
Details are discussed in the interface definition in section
6.2.
- hyper()
-
A hyper is a binary relation
between two objects. The relation can be created, destroyed and
inspected. It is automatically destroyed if either of the two connected
objects is destroyed. The destruction can be trapped. Messages may be
forwarded easily to all related objects. See also section
10.11.
- identity()
-
An identity is a relation
that maintains the identify between an attribute on one object and an
attribute on another object. Given a slider and a box, the following
ensures the selection of the slider is the same as the width of the box,
regardless of which of the two is changed. See also constraint.
new(_, constraint(Slider, Box,
identity(selection, width)))
- if()
-
Code object implementing a branch. All
three arguments are statements. Both `then' and `else' are optional, and
when omitted, simply succeed. Class if
is most commonly used in combination with the iteration methods such as `chain
->for_all':
...,
send(Device?graphicals, for_all,
if(message(@arg1, instance_of, device),
...)),
...
- image()
-
An image is a
two-dimensional array of pixels. Images come in two flavours:
monochrome, where each pixel represents a boolean and colour, where each
pixel represents a colour. XPCE can save and load
both monochrome and colour images. Images are displayed on a graphical
device using a bitmap.
They are also used to specify
cursor objects and the
icon associated with a `frame'. See section
10.10.
- int_item()
-
Subclass of text_item
for entering integer values. Has stepper buttons for incrementing and
decrementing the value.
- joint()
-
Class joint is a
super-class of the various line-types with a start- end end-point. It
provides the code dealing with attached
arrow-heads at
either end. As well as common code to reason about the start and end.
See also line, path,
arc and connection.
- key_binding()
-
A key_binding
object parses events into messages or methods on the object for which it
is handling events. Key-bindings are used by the classes text, text_item, editor
and
list_browser.
They can be used to defined
keyboard-accelerators, though `menu_item
<->accelerator'
is generally more suitable for this purpose.
- label()
-
A label is a controller
used to display read-only text or
image. Labels can handle
->report
messages. See section 10.7. The
code below is the typical way to associate a label that will catch
report messages for all windows of the frame
in which the
dialog is enclosed.
...,
send(Dialog, append, label(reporter)),
...
- label_box()
-
Subclass of dialog_group
for the definition of compound controllers with a properly aligned label
at their left-hand side.
- layout_manager()
-
- layout_interface()
-
A layout_manager
may be attached to a graphical device
(including a window) to
manage the layout of graphicals displayed on the device, as well as
painting the background of the device. See table
for a typical example.
- lbox()
-
Class of the document-rendering system to render a list environment, a
sequence of labels and text. See section
11.10 for details.
- line()
-
A line is a straight
line-segment with optional arrows, thickness and texture. Class path
implements a `multi-line'.
- link()
-
A link is a reusable
specification for a connection.
Links are used for defining connections and connect_gesture
objects. A connection knows about the link used to instantiate it. The
example defines the handles, link
and
connect_gesture
and shapes that allows the user to create links with an error from `out'
ports to `in' ports.
:- pce_global(@in_handle,
new(handle(0, h/2, in, in))).
:- pce_global(@out_handle,
new(handle(w, h/2, out, out))).
:- pce_global(@inout_link,
new(link(out, in,
line(arrows := second)))).
:- pce_global(@link_in_out_gesture,
new(connect_gesture(left, '',
@inout_link))).
make_shape(S) :-
new(S, box(50,50)),
send_list(S, handle,
[@in_handle, @out_handle]),
send(S, recogniser, @link_in_out_gesture).
- list_browser()
-
A list_browser is
a graphical version of a browser,
the visualisation of a list of items (dict_item)
stored in a
dict. The graphical
version is sometimes displayed with other controllers on a dialog
window. The example created a
list_browser
holding all current Prolog source files. Double-clicking a file will
start PceEmacs on the file. Selecting a file and
pressing Consult will (re)consult the file.
show_source_files :-
new(D, dialog('Prolog Source Files')),
send(D, append, new(B, list_browser)),
forall(source_file(X), send(B, append, X)),
send(B, open_message,
message(@prolog, emacs, @arg1?key)),
send(D, append,
button(consult,
message(@prolog, consult,
B?selection?key))),
send(D, open).
- menu()
-
Class menu realises
various different styles of menus and is the super-class for popup.
Basically, a menu presents multiple values, allows the user to choose
one or more items (`menu
->multiple_selection') and defines a `look'. The `menu->kind'
set the various attributes to often-used combinations. The other
`look-and-feel' attributes may be used to fine-tune the result
afterwards.
Menu-items can have a textual or image
label. Labels can be coloured and specify a different font.
...,
new(M, menu(gender, choice)),
send_list(M, append, [male, female]),
send(M, layout, horizontal),
...,
- menu_bar()
-
A menu-bar is a row of pull-down menus. Many applications define a
single menu-bar at the top of the frame presenting the various commands
in the application.
:- pce_begin_class(my_application, frame).
initialise(F) :->
send(F, send_super, initialise,
'My Application'),
send(F, append, new(MBD, dialog)),
new(V, view),
send(new(B, browser, left, V)),
send(B, below, MBD),
send(MBD, append, new(MB, menu_bar)),
send(MB, append, new(F, popup(file))),
send(MB, append, new(E, popup(edit))),
send_list(F, append,
[ menu_item(load,
message(F, load)),
...
- menu_item()
-
Item of a menu or popup.
For popup menus, the
items are normally created explicitly as each item often defines a
unique command. For menus,
it is common practice to simply append the alternatives as menu_item
will translate a
name into a menu_item
with this
<-value, <-message @default
and a <-label created by `capitalising' the
value.
- message()
-
A message is a dormant
`send-operation'. When executed using
->execute or ->forward, a
message is sent to the receiver. Message are the most popular code
objects. See section 10.2 and
many examples in this chapter.
- method()
-
Class method is the
super-class of send_method
and
get_method.
Instances of this class itself are useless.
- modifier()
-
A modifier is a
reusable object that defines a condition on the status of the three
`modifier keys' shift, control
and
meta/alt. Modifiers
are used by class gesture
and its sub-classes. They are normally specified through their
conversion method, which translates a name
consisting of the letters
s, c and m into a modifier that
requires the shift, control and/or meta-key to be down an the other
modifier keys to be up. The example specifies a `shift-click'
gesture.
...,
click_gesture(left, 's', single,
message(...)),
...
- move_gesture()
-
If a move_gesture
is attached to a graphical,
the graphical can be moved by dragging it using the specified
mouse-button. See also move_outline_gesture.
...,
send(Box, gesture, new(move_gesture)),
...
- move_outline_gesture()
-
Similar to a move_gesture,
but while the gesture is active, it is not the graphical itself that is
moved, but a dotted box indicating the outline of the graphical. If the
button is released, the graphical is moved to the location of the
outline. Should be used for complicated objects with many constraints or
connections as a direct move_gesture would be too slow.
- name()
-
A name is a unique
textual constant, similar to an atom in
Prolog. Whenever an atom is handed to XPCE, the
interface will automatically create a name
for it. There is no limit to the number of characters that can be stored
in a name, but some Prolog implementations may limit the number of
characters in an atom. On these platforms, it is
implementation-dependent what will happen to long names that are handed
to the Prolog interface.
- node()
-
A node is a node in a tree
of graphical
objects.
...,
new(T, tree(new(Root, node(text(shapes))))),
send(Root, son, node(circle(50))),
send(Root, son, node(box(50, 50))),
...
- not()
-
Code object that inverses the success/failure of its argument statement.
Often used for code objects that represent conditions.
primitives(Device, Primitives) :-
get(Device?graphicals, find_all,
not(message(@arg1, instance_of, device)),
Primitives).
- number()
-
A number is the object
version of an integer (int). If may be as a
storage bin. To compute the widest graphical of a device:
widest_graphical(Device, Width) :-
new(N, number(0)),
send(Device, for_all,
message(N, maximum, @arg1?width)),
get(N, value, Width),
send(N, done).
- object()
-
Class object is the
root of XPCE's class-inheritance hierarchy. It
defines methods for general object-management, comparison, hypers,
attributes, etc. It is possible to create instances of class
object, but generally
not very useful.
- operator()
-
Part of XPCE's object parser. Not (yet) available
to the application programmer.
- or()
-
Disjunctive code object.
An or starts executing its argument statements left-to-right and
terminates successfully as soon as one succeeds. The empty or
fails immediately.
- parbox()
-
Class to render text with mixed fonts and colours together with
graphics. Class parbox
is the heart of the document-rendering primitives described in section
11.10.
- parser()
-
Part of XPCE's object parser. Not (yet) available
to the application programmer.
- path()
-
A path is a multi-segment line.
It comes in two flavours:
poly as a number of straight connected line-segments and
smooth as an interpolated
line through a number of `control-points'. Its line attributes can be
defined and the interior can be filled. Paths are used both to define
new graphicals, for example a triangle,
or to defines curves.
draw_sine :-
send(new(Pict, picture), open),
send(Pict, display, new(P, path)),
( between(0, 360, X),
Y is sin((X * 6.283185)/360) * 100,
send(P, append, point(X, Y)),
fail
; true
).
- pce()
-
Class pce defines a single
instance called @pce. Actions that
cannot sensibly be related to a particular object are often defined on
class pce.
?- get(@pce, user, User).
User = jan
- pen()
-
Reserved for future usage.
- picture()
-
A picture is a window
with scrollbars, normally used for application graphics. If a graphical
window without scrollbars is required, window
should be considered.
- pixmap()
-
A pixmap is a subclass
of image that is
reserved for colour images. All functionality of this class is in class
image. The main reason
for its existence is that some graphical operations require a
colour image and the introduction of a class for it is the only way to
allow this to be specified using XPCE's type
system. The
->initialise method is specialised
for handling colour images.
- point()
-
Position in a two-dimensional plane. Together with size
and
area used to communicate
with graphicals about geometry.
...
get(Box, center, Point),
get(Point, mirror, Mirrored),
send(Box, center, Mirrored),
...
- popup()
-
A popup menu is a menu
that is shown after pressing a button on the object the menu is attached
to. Popups are used in two different contexts, as pulldown
menus attached to a menu_bar
and as popup-menus associated with windows or individual graphical
objects.
Popups are ->appended to menu_bars. Various
classes define the method
->popup to associate popup menus. Finally, class popup_gesture
provides a gesture that operates popup menus.
A popup consists of menu_items,
each of which normally defines a message to be executed if the
corresponding item is activated. Pull-right sub-menus are realised by
appending a popup to a popup.
...,
new(P, popup(options)),
send(P, append,
new(L, popup(layout, message(Tree, layout, @arg1)))),
send_list(L, append, [horizontal, vertical, list]),
send(P, append,
menu_item(quit, message(Tree, destroy))),
...
- popup_gesture()
-
A popup_gesture
parses events and activates a popup
menu. Popup gestures are explicitly addressed by the application
programmer to define compound gestures involving a popup:
:- pce_global(@graph_node_gesture,
make_graph_node_gesture).
make_graph_node_gesture(G) :-
new(P, popup),
send_list(P, append, [...]),
new(G, handler_group(connect_gesture(...),
move_gesture(middle),
popup_gesture(P))).
- process()
-
A process encapsulates
a stream- or terminal program to get its input from a graphical program
and redirect its output to the same graphical program. Various of the XPCE
tools and demo programs exploit processes: The M-x shell, M-x
grep and other shell commands of PceEmacs, the ispell
program and the chess front-end. See also socket.
- progn()
-
Code object with semantics like the LISP progn function. A progn
executes its statements. If all statements are successfully executed and
the last argument is a function,
execute the function and return the result of it or, if the last
argument is not a function, simply return it. Used infrequently in the XPCE/Prolog
context.
- program_object()
-
The super-class of almost the entire `meta-word' of XPCE: classes,
behaviour, attributes, types, etc. Class program_object
defines the XPCE tracer. See tracepce/1
and breakpce/1.
- quote_function()
-
Most of XPCE is defined to evaluate function
objects at the appropriate time without the user having to worry about
this. Sometimes however, type-checking or execution of a statement will
enforce the execution of a function where this is not desired. In this
case class
quote_function
can help. As a direct sub-class of
object, it will
generally be passed unchanged, but type-conversion will translate
extract the function itself if appropriate, while delegation allows the
quote_function to be treated as a function.
In the example, ChainOfChains is a chain holding chains as
its elements. The task is to sort each of the member chains, using the
function ?(@arg1,
compare, @arg2) for sorting. If
not enclosed in a quote_function,
the message will try to evaluate the function. Now it passes the
quote_function unchanged. The `chain->sort'
method requires a code
argument and therefore the function will be extracted from the
quote_function.
...,
send(ChainOfChains, for_all,
message(@arg1, sort,
quote_function(?(@arg1, compare, @arg2)))),
...
- real()
-
A real is XPCE's
notion of a floating-point number. Reals are represented using a C
single-precision `float'. Reals define the
same operation as class number,
its integer equivalent.
- recogniser()
-
Class recogniser is
the super-class of all event-parsing classes. The sub-tree gesture
handles mouse-button related events, key_binding
handles typing and handler
may be used for all events. The main purpose of this class itself is to
provide a type for all its sub-classes.
- regex()
-
A regex is XPCE's
encapsulation of the (GNU) Regular Expression
library. Regular expression form a powerful mechanism for the analysis
of text. Class regex can
be used to search both char_array
(name and string)
text and text from a text_buffer
as used by editor. It
is possible to access the `registers' of the regular expression.
?- new(S, string('Hello World')),
new(R, regex('Hello\s +\(\w+\)')),
send(R, match, S),
get(R, register_value, S, 1, name, W).
W = 'World'
- region()
-
A region defines a
sub-region of a graphical. They are used to restrict handler
objects to a sub-area of a graphical. Backward compatibility only.
- relation()
-
Class relation is the
super-class of identity
and
spatial. Relations
form the reusable part of
constraints. Class relation
may be sub-classed to define new relation-types.
- resize_gesture()
-
A resize_gesture
handles mouse-drag events to resize a graphical object on the corners or
edges. See also move_gesture
and
resize_outline_gesture.
...,
send(Box, recogniser, new(resize_gesture)),
...
- resize_outline_gesture()
-
Outline version of the resize_gesture,
often used to resize objects that are expensive to resize, such as editor
or
list_browser.
- resize_table_slice_gesture()
-
Gesture that can be used together with class table
to allow the user dragging the boundaries between columns and rows in a
table. See also section 11.5.
- resource()
-
A resource is data
associated with the application. It is most commonly used to get access
to image-data. Example:
resource(splash, image, image('splash.gif')).
show_splash_screen :-
new(W, window),
send(W, kind, popup), % don't show border
new(I, image(resource(splash))),
get(I, size, size(W, H)),
send(W, size, size(W, H)),
send(W, display, bitmap(I)),
send(W, open_centered),
send(timer(2), delay),
send(W, destroy).
- rubber()
-
Defines how elastic objects in the document-rendering system such as
hbox and its subclasses
are. Used by parbox to
realise layout. See section 11.10
for a full description of the rendering primitives.
- scroll_bar()
-
A scroll_bar is
used to indicate and control the visible part of a large object viewed
through a window. Though possible, scroll_bars are rarely used outside
the context of the predefined scrollbars associated with list_browser, editor
and window.
...,
send(Window, scrollbars, vertical),
...
- send_method()
-
A send_method maps
the name of a method selector onto an implementation and
defines various attributes of the method, such as the required
arguments, the source-location, etc. Send-methods are normally specified
through user-defined classes preprocessor as described in chapter
7.
- sheet()
-
A sheet is a dynamic set
of attribute/value pairs. The introduction of object-level attributes
implemented by `object
<->attribute' and user-defined classes have
made sheets obsolete.
- size()
-
Combination of
<-width and <-height
used to communicate with graphical objects about dimension. See also point
and area.
- slider()
-
Controller for a numeric value inside a range that does not require
exact values. Specifying volume or speed are good examples of the use of
sliders. They can also be used to realise a percent-done
gauge.
...,
new(Done, slider(done, 0, 100, 0)),
send(Done, show_label, @off),
send(Done, show_value, @off),
...
send(Done, selection, N),
send(Done, synchronise),
...
- socket()
-
Communication end-point for a TCP/IP or
Unix-domain interprocess communication stream. XPCE
supports both `server' and `client' sockets. On the Win32 platform, only
TCP/IP sockets are provided and only Windows-NT supports server sockets.
The
library(pce_server) provides a good starting point for
defining server sockets. The support executable xpce-client
may be used to communicate with XPCE server
sockets. See also PceEmacs server mode as defined in library('emacs/server').
- source_location()
-
Specifies the location in a source file. Used by method
objects to register the location they are defined.
- source_sink()
-
Abstract super-class of file, resource
and
text_buffer for
type-checking purposes. All source_sink
objects may be used for storing and retrieving image-data. Notably a resource
can be used for creating images (see
section 9 and text_buffer
can be used to communicate images over network connections (see section
11.9).
- spatial()
-
A spatial defines a
geometry relation
between two objects. The first two equations express the reference
point of the 1st graphical in terms of its x, y, w and h. The second
pair does the same for the second graphical, while the remaining two
equations relate the mutual widths and heights. The example defines the
second graphical to be 10 pixels wider and higher than the first, to
share the same lower edge and be centered horizontally.
new(_, constraint(Gr1, Gr2,
spatial(xref=x+w/2, yref=y+h,
xref=x+w/w, yref=y+h,
w2=w+2, h2=h+2)))
- stream()
-
Class stream is the
super-class of socket
and
process, defining the
stream-communication. It handles both synchronous and asynchronous input
from the socket or process. It is not possible to created instances of
this class.
- string()
-
A string represents a
string of characters that may be modified. This class defines a large
number of methods to analyse the text that are inherited from char_array
and a large number of methods to manipulate the text. Class regex
can analyse and modify string objects. There is no limit to the number
of characters in a string. Storage is (re)allocated dynamically and
always is `just enough' to hold the text. For large texts that need many
manipulations, consider the usage of text_buffer
that implement more efficient manipulation.
Strings are commonly used to hold descriptions, text entered by the
user, etc.
- style()
-
A style defines
attributes for a text fragment
as handled by a editor/classtext_buffer
or a dict_item as
handled by a list_browser/dict.
It defines the font, fore- and background colours as well as
underlining, etc. The example defines a browser that displays files
using normal and directories using bold font.
make_browser(B) :-
new(B, browser),
send(B, style, file, style(font := normal)),
send(B, style, directory, style(font := bold)),
send(B, open).
append_file(B, Name) :-
send(B, append,
dict_item(Name, style := file)).
append_dir(B, Name) :-
send(B, append,
dict_item(Name, style := directory)).
- syntax_table()
-
Syntax tables are used by class text_buffer
to describe the syntax of the text. They describe the various
syntactical categories of characters (word-characters,
digit-characters), the syntax for quoted text, for comments as well as a
definition for the end of a sentence and paragraph. Syntax tables are
introduced to support the implementation of modes
in PceEmacs. See also the
emacs_begin_mode/5
directive as defined in
library(emacs_extend).
- tab()
-
A tab is a subclass of dialog_group,
rendering as a collection of dialog_items
with a `tag' associated. Tabs are normally displayed on a tab_stack,
which in turn is displayed on a dialog.
Skeleton:
new(D, dialog(settings)),
send(D, append, new(TS, tab_stack)),
send(TS, append, new(G, tab(global))),
send(TS, append, new(U, tab(user))),
...,
<fill G and U>
...,
send(D, append, button(ok)),
send(D, append, button(cancel)).
- tab_stack()
-
Defines a stack of tagged sub-dialogs (tab
objects) that can be displayed on a dialog.
See tab for an example.
- table()
-
A table defines a
two-dimensional tabular layout of graphical objects on a graphical device.
The functionality of XPCE tables is modelled after
HTML-3. Example:
simple_table :-
new(P, picture),
send(P, layout_manager, new(T, table)),
send(T, border, 1),
send(T, frame, box),
send(T, append, text('row1/col1')),
send(T, append, text('row1/col2')),
send(T, next_row),
send(T, append,
new(C, table_cell(text(spanned, font := bold)))),
send(C, col_span, 2),
send(C, halign, center),
send(P, open).
- table_cell()
-
Provides the layout_interface
to a table. Table cells
are automatically created if a graphical is appended to a table.
Explicit creation can be used to manipulate spanning, background and
other parameters of the cell.
- table_column()
-
- table_row()
-
- table_slice()
-
These classes are used for storing row- and column information in
table objects. They are
normally created implicitly by the table. References to these objects
can be used to change attributes or delete rows or columns from the
table. Example:
...,
get(Table, column, 2, @on, Column),
send(Column, halign, center),
...
- tbox()
-
Add text using a defined style
to a parbox. Part of
the document-rendering infra-structure. See section
11.10.
- relation_table()
-
A relation_table
defines a multi-column table data object that can have one or more
indexed key fields. They are (infrequently) used for storing
complex relational data as XPCE objects.
- text()
-
Graphical representing a string in a specified font. Class text defines
various multi-line and wrapping/scrolling options. It also implements
methods for editing. Class editable_text as defined in
library(pce_editable_text)
exploits these methods to arrive at a flexible editable text object.
- text_buffer()
-
A text_buffer
provides the storage for an editor.
Multiple editors may be attached to the same text_buffer,
realising shared editing on the same text. A text_buffer has an
associated syntax_table
that describes the character categories and other properties of the text
contained. It can have fragment
objects associated that describe the properties of regions in the text.
See class editor for
an overview of the other objects involved in editing text.
- text_cursor()
-
Cursor as displayed by an editor.
Not intended for public usage. The example hides the caret from an
editor.
...,
send(Editor?text_cursor, displayed, @off),
...
- text_image()
-
A text_image object
is used by the classes editor
and
list_browser to
actually display the text. It defines the tab-stops
and line-wrapping properties. It also
provides methods to translate coordinates into character indices and
vise-versa. The user sometimes associates recogniser
objects with the text_image
to redefine event-processing.
- text_item()
-
A text_item is a
controller for entering one-line textual values. Text items (text-entry-field)
can have an associated
type and/or value-set.
If a value-set is present or can be extracted from the type using `type
<-value_set',
the item will perform completion, which
is by default bound to the space-bar. If a type is specified, the typed
value will be converted to the type and an error will be raised if this
fails. The following text-item is suitable for entering integers:
...,
new(T, text_item(height, 0)),
send(T, type, int),
send(T, length, 8),
...
- text_margin()
-
A text_margin can
be associated with an editor
using
`editor
->margin_width' >
0. If the text_buffer
defines fragments, and the style
objects define `style<-icon',
the margin will show an icon near the start of the fragment. After the
introduction of multiple fonts, attributes and colour this mechanism has
become obsolete.
- tile()
-
Tiles are used to realise the `tile-layout' of windows in a
frame. Section
10.6 explains this in detail. Tiles can also be used to realise
tabular layout of other re-sizable graphical objects.
- tile_adjuster()
-
Small window displayed on top of a frame
at the right/bottom of a user-adjustable window. Dragging this window
allows the user the adjust the subwindow layout.
- timer()
-
Timers are used to initiate messages at regular intervals, schedule a
single message in the future or delay execution for a specified time.
The example realises a blinking
graphical. Note that prior to destruction of the graphical, the timer
must be destroyed to avoid it sending messages to a non-existing object.
...,
new(T, timer(0.5, message(Gr, inverted,
Gr?inverted?negate))),
...
- tokeniser()
-
A tokeniser returns
tokens from the input source according to the syntax specified. It is
part of the XPCE object parser and its
specification is not (yet) public.
- tree()
-
Trees realise hierarchical layout for graphical
objects. Class
tree itself is a subclass
of figure. The
hierarchy is built from node
objects, each of which encapsulates a graphical. Trees trap changes to
the geometry of the displayed graphicals and will automatically update
the layout. For an example, see node.
- tuple()
-
Anonymous tuple of two objects. Commonly used by get-methods that have
to return two values.
- type()
-
A type defines,
implicitly or explicitly, a set of object that satisfy the type, as well
as optional conversion rules to translate certain other object to an
object that satisfies the type. The basic set consists of a type for
each class, defining the set of all instances of the class or any of its
sub-classes, a few `primitive' types (int, char and event_id are
examples). Disjunctive types can be created. See also
section 3.2.1 and section
7.5.1.
?- get(type(int), check, '42', X). X = 42
- var()
-
A var object is a function
that yields the stored value when evaluated. Vars in XPCE
have global existence (like any object), but local, dynamically scoped,
binding. Scopes are started/ended with the execution of (user-defined)
methods, `code
->forward'
and the execution of a block.
The system predefines a number of var
objects providing context for messages, methods, etc: @arg1,
... @arg10 for argument forwarding,
@event for the current event, @receiver
for the receiver of an event or message and @class
for the class under construction are the most popular ones. Class block
and and give examples of
using these objects.
- variable()
-
A variable is a
class' instance-variable. They are, like
send_method and get_method,
normally defined through the user-defined classes preprocessor described
in chapter 7.
- vector()
-
Vector of arbitrary objects. Vectors can be dynamically expanded by
adding objects at arbitrary indices. Vectors are used at various places
of XPCE's programming world: specifying the types
of methods, the instance variables of a class, to pack the arguments for
variable-argument methods, etc. They share a lot of behaviour with
chain can sometimes be
an attractive alternative.
- view()
-
A view is a window
displaying an editor.
View itself implements a reasonable powerful set of built-in commands
conforming the GNU-Emacs key-bindings. See also PceEmacs
and
show_key_bindings/1.
- visual()
-
Visual is the super-class of anything in XPCE that
can `visualise' things. The class itself defines no storage. Each
subclass must implement the `visual
<-contains'
and `visual<-contained_in'
methods that define the visual consists-of hierarchy as shown by the
Visual Hierarchy. Class visual itself plays a role in
the
->report mechanism as described in section
10.7 and defines
`visual->destroy'
to ensure destruction of a sub-tree of the visual consists-of hierarchy.
- when()
-
Class when realises a
function version of if. It
evaluates the condition and then returns the return-value of
either of the two functions. It is commonly used to define conditional
class-variable values.
editor.selection_style: \
when(@colour_display, \
style(background := yellow), \
style(highlight := @on))
- while()
-
Code statement executing body as long as condition
executes successfully. Not used frequently. Most iteration in XPCE
uses the
->for_all, ->for_some, <-find
and <-find_all methods defines on most collection
classes.
- window()
-
The most generic XPCE window class. A window
is a sub-class of
device and thus capable
of displaying graphical objects. One or more windows are normally
combined in a frame as
described in section 10.6.
The four main specialisations of window are dialog
for windows holding controllers, view
for windows holding text, browser
for windows displaying a list of items and finally, picture
for displaying graphics.
Class window can be
used as a graphics window if no scrollbars are needed.
- window_decorator()
-
A window_decorator
is a window that displays another window and its `decorations':
scrollbars and label. A picture
for example is actually a window displayed on a window-decorator
displaying the scrollbars. Almost never used directly by the application
programmer.
