Author(s): Isabel Martín García.
Version: 1.11#222 (2004/5/24, 13:8:7 CEST)
Version of last change: 1.9#154 (2003/12/4, 17:39:3 CET)
This library is intended to eaose the task of displaying some graphical results. This library allows the programmer to visualize different graphs and tables without knowing anything about specific graphical packages.
You need to install the BLT package in your computer. BLT is an extension to the Tk toolkit and it does not require any patching of the Tcl or Tk source files. You can find it in http://www.tcltk.com/blt/index.html
Basically, when the user invokes a predicate, the library (internally) creates a bltwish interpreter and passes the information through a socket to display the required widget. The interpreter parses the received commands and executes them.
The predicates exported by this library can be classified in four main groups, according to the types of representation they provide.
To represent graphs, the Cartesian coordinate system is used. I have tried to show simple samples for every library exported predicate in order to indicate how to call them.
In this section we shall introduce the general issues about the set of barchart predicates. By calling the predicates that pertain to this group a bar chart for plotting two-dimensional data (X-Y coordinates) can be created. A bar chart is a graphic means of comparing numbers by displaying bars of lengths proportional to the y-coordinates they represented. The barchart widget has many configurable options such as title, header text, legend and so on. You can configure the appearance of the bars as well. The bar chart widget has the following components:
"
no text will be displayed.
"
no title will be displayed.
"
no x axis title will be displayed.
"
no y axis title will be displayed.
"
no header text will be displayed.
All of them are arranged in a window. However you can, for example, show a bar chart window without legend or header text. Other configuration options will be explained later.
In addition to the window appearance there is another important issue about the bar chart window, namely its behaviour in response to user actions. The association user actions to response is called bindings. The main bindings currently specified are the following:
The predicates that belong to this group are those whose names begin with barchart and genmultibar. If you take a look at the predicate names that pertain to this group, you will notice that they are not self-explanatory. It would have been better to name the predicates in a way that allows the user to identify the predicate features by its name, but it would bring about very long names (i.e barchart_WithoutLegend_BarsAtUniformIntervals_RandomBarsColors). For this reason I decided to simply add a number after barchart to name them.
It is frequently the case that several datasets need to be displayed on the same plot. If so, you may wish to distinguish the points in different datasets by joining them by lines of different color, or by plotting with symbols of different types. This set of predicates allows the programmer to represent two-dimensional data (X-Y coordinates). Each dataset contains x and y vectors containing the coordinates of the data. You can configure the appearance of the points and the lines which the points are connected with. The configurable line graph components are:
Smooth
argument. Smooth can be either linear, step, natural and quadratic. Furthermore, you can select the appearance of the points and lines.
The elements header, footer, quit and save buttons, the titles and the axes are quite similar to those in barchart graphs, except in that the tick labels will be numbers. All of them are arranged in a window by the geometry manager. However you can, as we mentioned in the above paragraphs, show a line graph window without any titles or footer text. Other configuration options will be explained later in this section or in the corresponding modules.
Related to the behaviour of the widgets in response to user actions (bindings) we will remark the following features:
The predicates that belong to this group are those whose names begin with graph_.
The challenge of this section is to introduce some general aspects about the scatter graph predicates group. By invoking the scatter graph predicates the user can represent two-dimensional point datasets. Often you need to display one or several point datasets on the same plot. If so, you may wish to distinguish the points that pertain to different datasets by using plotting symbols of different types, or by displaying them in different colors. This set of predicates allows you to represent two-dimensional data (X-Y coordinates). Each dataset contains x and y vectors containing the coordinates of the data. You can configure the appearance of the points. The configurable scatter graph components are:
The elements header, footer, quit and save buttons, the titles and the axes are similar to those in barchart graphs except for that, as in line graphs, the tick labels will be numbers. All of them are arranged in a window by the geometry manager. However you can, for example, show a scatter graph window without titles or footer text, as we mentioned before. Other configuration options will be explained later, in the corresponding modules.
Related to the behaviour of the widgets in response to user actions (bindings) the following features are:
The predicates that belong to this group are those whose names began with scattergraph_.
The purpose of this section is to allow the user to display results in a table. A table is a regular structure in which:
The widget configurable components are as follows:
"
no title will be displayed.
"
no header text will be displayed.
"
no header text will be displayed.
If the arguments are not in a correct format an exception will be thrown. Moreover, these widgets have the default bindings and the binding related to the quit button: The set of predicates that belongs to this group are those which names begin with table_widget.
Although you don't have to worry about how to arrange the widgets, here is an overview of how Tcl-tk, the underlying graphical system currently used by chartlib, performs this task. Quoting from the book Tcl and Tk toolkit, John K. Ousterhout.
The X Window System provides many facilities for manipulating windows in displays. The root window may have any number of child windows, each of wich is called a top-level window. Top-level windows may have children of their own, wich may have also children, and so on. The descendants of top-level windows are called internal windows. Internal windows are usedfor individual controls such as buttons, text entries, and for grouping controls together. An X-application tipically manages several top-level windows. Tk uses X to implement a set of controls with the Motif look and feel. These controls are called widgets. Each widget is implemented using one X window, and the terms "window" and "widget" will be used interchangeably in this document. As with windows, widgets are nested in hierarchical structures. In this library top-level widgets (nonleaf or main) are just containers for organizing and arranging the leaf widgets (components). Thereby, the barchart widget is a top-level window wich contains some widget components.
Probably the most painstaking aspect of building a graphical application is getting the placement and size of the widgets just right. It usually takes many iterations to align widgets and adjust their spacing. That's because managing the geometry of widgets is simply not a packing problem, but also graphical design problem. Attributes such as alignment, symmetry, and balance are more important than minimizing the amount of space used for packing. Tk is similar to other X toolkits in that it does not allow widgets to determine their own geometries. A widget will not even appeared unless it is managed by a geometry manager. This separation of geometry management from internal widget behaviour allows multiple geometry managers to exist simultaneously and permits any widget to be used with any geometry manager. A geometry manager's job is to arrange one or more slave widgets relative to a master widgets. There are some geometry managers in Tk such as pack, place and canvas widget. We will use another one call table.
The table geometry manager arranges widgets in a table. It's easy to align widgets (horizontally and vertically) or to create empty space to balance the arrangement of the widgets. Widgets (called slaves in the Tk parlance) are arranged inside a containing widget (called the master). Widgets are positioned at row,column locations and may span any number of rows or columns. More than one widget can occupy a single location. The placement of widget windows determines both the size and arrangement of the table. The table queries the requested size of each widget. The requested size of a widget is the natural size of the widget (before the widget is shrunk or expanded). The height of each row and the width of each column is the largest widget spanning that row or column. The size of the table is in turn the sum of the row and column sizes. This is the table's normal size. The total number of rows and columns in a table is determined from the indices specified. The table grows dynamically as windows are added at larger indices.
chartlib
):- use_module(library(chartlib)).
chartlib
)
Imported from
genbar1
(see the corresponding documentation for details).
Imported from
genbar1
(see the corresponding documentation for details).
Imported from
genbar1
(see the corresponding documentation for details).
Imported from
genbar2
(see the corresponding documentation for details).
Imported from
genbar2
(see the corresponding documentation for details).
Imported from
genbar2
(see the corresponding documentation for details).
Imported from
genbar3
(see the corresponding documentation for details).
Imported from
genbar3
(see the corresponding documentation for details).
Imported from
genbar3
(see the corresponding documentation for details).
Imported from
genbar4
(see the corresponding documentation for details).
Imported from
genbar4
(see the corresponding documentation for details).
Imported from
genbar4
(see the corresponding documentation for details).
Imported from
genmultibar
(see the corresponding documentation for details).
Imported from
genmultibar
(see the corresponding documentation for details).
Imported from
table_widget1
(see the corresponding documentation for details).
Imported from
table_widget1
(see the corresponding documentation for details).
Imported from
table_widget2
(see the corresponding documentation for details).
Imported from
table_widget2
(see the corresponding documentation for details).
Imported from
table_widget3
(see the corresponding documentation for details).
Imported from
table_widget3
(see the corresponding documentation for details).
Imported from
table_widget4
(see the corresponding documentation for details).
Imported from
table_widget4
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph1
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
gengraph2
(see the corresponding documentation for details).
Imported from
chartlib_errhandle
(see the corresponding documentation for details).
Imported from
chartlib_errhandle
(see the corresponding documentation for details).
Go to the first, previous, next, last section, table of contents.