aboutsummaryrefslogtreecommitdiffstats
path: root/help/white-papers
diff options
context:
space:
mode:
authorMiguel de Icaza <miguel@src.gnome.org>2000-03-06 08:56:49 +0800
committerMiguel de Icaza <miguel@src.gnome.org>2000-03-06 08:56:49 +0800
commit053267fc5d7a087b315612a43fc493083309f465 (patch)
tree45a670c3550c24efb16686cbf85991172026048a /help/white-papers
parentded421f574b71a3667fd4bac9fe15d9c22aee268 (diff)
downloadgsoc2013-evolution-053267fc5d7a087b315612a43fc493083309f465.tar
gsoc2013-evolution-053267fc5d7a087b315612a43fc493083309f465.tar.gz
gsoc2013-evolution-053267fc5d7a087b315612a43fc493083309f465.tar.bz2
gsoc2013-evolution-053267fc5d7a087b315612a43fc493083309f465.tar.lz
gsoc2013-evolution-053267fc5d7a087b315612a43fc493083309f465.tar.xz
gsoc2013-evolution-053267fc5d7a087b315612a43fc493083309f465.tar.zst
gsoc2013-evolution-053267fc5d7a087b315612a43fc493083309f465.zip
Add stuff, revamp stuff
svn path=/trunk/; revision=2068
Diffstat (limited to 'help/white-papers')
-rw-r--r--help/white-papers/widgets/e-table.sgml70
1 files changed, 55 insertions, 15 deletions
diff --git a/help/white-papers/widgets/e-table.sgml b/help/white-papers/widgets/e-table.sgml
index 50e2aa46e5..5ff4faf2ae 100644
--- a/help/white-papers/widgets/e-table.sgml
+++ b/help/white-papers/widgets/e-table.sgml
@@ -5,6 +5,7 @@
<!entity ETableSimple "<classname>ETableSimple</classname>">
<!entity ETableHeader "<classname>ETableHeader</classname>">
<!entity ETableSpecification "<classname>ETableSpecification</classname>">
+<!entity ETableCol "<classname>ETableCol</classname>">
]>
<article class="whitepaper" id="e-table">
@@ -54,7 +55,7 @@
table. Without any work from the programmer, &ETable; provides
rearrangeable columns and editable data. When finished, &ETable; will
also provide, again with no programmer intervention, easy interactive
- sorting and grouping.
+ sorting and grouping.
</para>
<para>
@@ -64,19 +65,49 @@
However, once you learn it, &ETable; is not very hard at all to
use.
</para>
+
+ <para>
+ &ETable;'s power comes from the fact that it is fully
+ model/view/controller based. Various models are involved into
+ the process of rendering the information, and various views are
+ provided. The programmer has a wide range of options: from the
+ most finely hand-tuned table to a generic all-encompasing widget
+ that takes over most of tasks. It is up to the programmer: he
+ can use the simple to use &ETable; widget that takes care of
+ everything in a generic way, or he can use the various
+ components to roll his own tabular display.
+ </para>
+
+ <para>
+ &ETable; ships with a standard set of information renderers:
+ strings, bitmaps, toggle-buttons, check-boxes, and multi-line
+ strings. But the programmer can write and implement his own
+ renderer for his information. This means that by default
+ &ETable; provides the basic display facilities that programmers
+ required, but they offer the programmer a complete freedom to
+ incorporate new cell renderers.
+ </para>
+
</sect1>
<sect1 id="model">
<title>ETableModel</title>
<para>
- The back end of &ETable; is an &ETableModel;. To use &ETable;
- you have to create a subclass of &ETableModel;. However, to save
- you the work of defining a new <classname>GtkClass</classname>,
- there is a predefined subclass of &ETableModel; called
- &ETableSimple; which simply takes a list of callbacks to perform
- the various operations.
+ The data back end for the &ETable; is an &ETableModel;. The
+ &ETableModel is an abstract interface that acts as the
+ information repository for the various &ETable components.
</para>
+
+ <para>
+ To use &ETable; you have to create a subclass of the abstract
+ &ETableModel; class. However, to save you the work of defining
+ a new <classname>GtkClass</classname> every time you use
+ &ETable, there is a predefined subclass of &ETableModel; called
+ &ETableSimple; which simply takes a list of function callbacks
+ to perform the various operations.
+ </para>
+
</sect1>
<sect1 id="columns">
@@ -84,17 +115,26 @@
<para>
There are two different meanings to the word "column". The first
- is the model column. A model column corresponds to a specific
- type of data. This is very much like the usage in a database
- table where a column is a field in the database.
+ is the model column (defined by the &ETableCol: object). A model
+ column describes how it maps to the column in the &ETableModel;
+ as well as containing information about its properties (name,
+ resizability, resize dimensions, and a renderer for this
+ specific columns).
+ </para>
+
+ <para>
+ &ETable; distinguishes between a model column index, and a view
+ column index. The former reflects the column in which the data
+ is stored in the &ETableModel; The later represents the actual
+ location at which the column is being displayed in the screen.
</para>
<para>
- The second type of column is a view column. A view column
- corresponds to a visually-displayed column. Each view column
- corresponds to a specific model column, though a model column
- may have any number of view columns associated with it
- (including zero).
+ Each view column index corresponds to a specific model column,
+ though a model column may have any number of view columns
+ associated with it (including zero). For example the same
+ column might be rendered twice, or the data from one column
+ could be used to display different bits of information
</para>
<para>