
Salvage the Primebox widget from the code I wrote this summer.

Make a unified function to enter stuff. If it looks like an expression
(i.e. parses without error using the default interpreter) it is inserted
as an expression, otherwise it is inserted as a label. That way it will
be much easier to enter labels that start with a digit and expressions
that start with a letter.

Change default size to 640x440.

Take a good look at integration with KDE and Gnome:
 - How to detect that they are installed
 - How to add programs to panels and such
 - What the standard icons look like

Move resizing into Table widget.

Add a flag to choose between plugin printing and default printing.

Make configure allow docs to go elsewhere.

S Lockwood's first patch (in siagp1).

Make formats follow when selection is copied or cut-and-pasted.

Enter date in a convenient way. I.e. unbreak enter-date and enter-time.

"Toy" bar with user configurable icons for calendar, notebook, postit
notes et al. New file toys.scm in common makes this available in all
programs.

Subclass widgets from Frame so they get 3d appearance for free. While
I'm at it, replace the Label and Command widgets. That would leave
Form, Box, scrollbars and menus.

Display negative values in red.

> 5 - What about adding to the Block menu a function for deleting a
> block of the sheet and prompting the user if they want to move the
> lines below up or the columns to the left to fill the gaps ?

Internal plugins for common UI components like text boxes, command
buttons, toggles. Menus?

Use the mouse to move the plugin.

Store the plugin's position in pixels within the document,
rather than line/column coordinates.

Plotting plugin with "live" update

Popup menu for plugins (right click on the border). Has menu with
plugin operations that affect this plugin, e.g. move, resize, delete.

Collect image formats under a separate menu item.

Make the format selector in the file dialog a combo box, so we don't
get the ridiculous lists with 20+ formats.

Write a constraint widget that can be used as a toplevel shell for
an application. Child widgets are arranged around the edges, on
different sides depending on resource settings. The remaining space
in the middle is used for the main application. The menu, toolbar and
so on don't need to be displayed at all, in which case the space is
reused for the application. Ideally, it will be possible to detach the
controls and move them around the screen.
	Step 1: A composite widget where the layout is hardcoded
so that for n children, the first n-2 are arranged at the top, the
last one at the bottom and the last but one occupies all the remaining
space. Every child widget occupies the full width of the parent.
	This widget will be sufficient for Siag, PW and Egon but
won't satisfy my requirements from the first paragraph.

Spelling checker like the one in PW. Toolbar button for spelling.

Cross-sheet references. Why not something like [buffer:sheet]R1C1, where
buffer is the name of a buffer and sheet is the sheet in the buffer. There
will be defaults, so that [buffer:] means the first sheet in the buffer
and [:sheet] or simply [sheet] means a sheet in the current buffer.

Open a toplevel window for each document. Clicking the New button opens
a new window with a new noname.siag, rather than launching a new Siag.
One problem with the multiple toplevels is that all toplevels need a
certain baseline, like menus and toolbars. It should be recorded what
those should be so that they can be reproduced for each and every
toplevel created.

Write a new font selector box. The old one had to go because it was
too closely tied to the old encoding.

Help in *all* dialogs.

Show page boundaries in the grid.

Absolute and relative references.

Make the C interpreter 1-2-3 compatible.

Limit the amount of memory allocated by cmalloc et al.

Make file formats external.

Date and time (entering, displaying).

Make the .siag file format handle all the info in the .wk1 format.

sin(cos(r1c1)) in the C interpreter.

Optimal recalculation: maintain two lists for each cell, one for the
cells this cell depends on (dep_up) and one for those that depend
on it (dep_dn). When a cell is changed, the following takes place:
1. It is removed from the dep_dn list of every cell in its dep_up list.
2. Its dep_up is cleared.
3. Its value is calculated.
4. All cells in its dep_dn list are recalculated.
5. Its value is calculated again. All referenced cells are added to
   its dep_up.
6. All cells in dep_dn are recalculated again.
7. It is added to the dep_dn lists of all cells in its dep_up.
Steps 4 and 6, recalculation of all cells in dep_dn, require some
clarification. It is clearly not enough to calculate the cells in
dep_dn of the first cell, but it is necessary to also process the
dep_dn lists of those cells and so on, recursively. To avoid looping
over cyclic dependencies, every cell has a serial number.
Cells which have already been done all have the same serial number.
The serial number is a long integer, which should ensure reasonable
uniqueness.
The algorithm will calculate all affected cells twice. This is
to allow cyclic dependencies.
It is still likely that the current algorithm (calculate everything
always) will work more reliably, but it can be combined with the
optimal recalculation.
To handle troublesome cells, individual cells or ranges thereof
can be marked as such. They will then be recalculated every time
as part of the optimal recalculation. There should be a visual cue
that a cell is marked, perhaps with a border in a different colour.

While we're already busy bloating the cell structure, why not add
another field for pre-parsed expressions.

Basic file manipulation routines for the structured file handling and more:
make_directory(dirname, mode) creates a directory hierarchy.
copy_file(from_file, to_file) copies a file.
exist_file(filename) 1 if file exists, 0 if not.
untar_file(filename, directory) unpack a tar archive in a directory
tar_file(filename, directory) create tar archive of directory
All functions return -1 for failure and 0 for success.

Gnuplot can be handled by a plugin which separates data from
control, launches gnuplot and controls it. It should be possible to
use pipes to control gnuplot. The EXEC command to the plugin would
then be used.
Create the command and data files in a temporary directory. Tar up the
results, creating a file with .plot extension. Import this file using
the normal plugin system, which will copy it into a subdirectory of the
$(HOME)/.siag structure.
The plugin will take it from there.

A PW plugin will have only the grid widget, which is a Richtext
widget and does not handle small sizes very well. I need to address
that problem if PW is to be a reasonable plugin.

Generally look into how window managers work, since I'm trespassing
on window manager territory. I should probably reparent the windows
into something other than a plain Composite. Something that would
allow me to move and resize using the mouse.

Remove the distinction between windows and buffers and instead have
a 1:1 relationship between them. This will make life much easier for
plugins (or rather, much easier for me), because I won't have to
display a single plugin in several windows. Doing that would be
really tricky.

Form input for gsiag

Form input for tsiag

Menus for tsiag

Click grid, rownum, colnum in gsiag

Split window in tsiag

Confirm delete of nonempty cells

Add Scheme functions to create user interface elements, in order
to make it more customizable.

4th support (but is 4th really flexible enough?)

Perl support

Truncate at cell border (Table widget)

Read csv files as all labels, including numeric fields

Use grid-, row- and column-wide default formats.

Multi-level undo would be trivial to implement. Making undo handle
huge changes or moving ranges is more work.

An eval-expr similar to exec-expr, but returns a value.

(remove-window)
(next-window)
(split-window)
(activate-window)
How to reference a window from Lisp
(savematrix path buffer type)
	Path is the full path, buffer is the name of the buffer
	(NIL for current), type is file format
(fsel-input path name patterns fmt)
	Path is starting directory, name is file name, patterns is list
	of extensions, fmt is osmething else
(listsel prompt list)
	list is a list of strings. Returns the index
Stylelist
Fmtstyles

Goal seeking.

Record macros.

Handle huge documents that are too big to fit in virtual memory. It
should be possible to do like this: Keep all cells in a file. Keep
an index to the offset of every cell in core. Every time a cell is
added or changed, it is added at the end of the file along with a link
to the previous version. This allows unlimited undo. When the file grows
over a configurable size, it is shrunk by discarding all the old cells.
One advantage of this scheme is that disaster recovery becomes almost
automatic.

