
The file selector is incredibly convoluted. Change it like this:

 - Initialize creates all the widgets *except* the directory and
   format menus (including buttons). The noncreated buttons are set
   to None. directory is initialized to the current working directory,
   filename is initialized to the empty string, format is initialized
   to the "All (*)" string from the standard patterns.

 - fsel_scan scans the directory for directories and files, updates
   the directory and file lists, creates the directory and format menus.
   This means that we must add a resource for the formats, so the menu
   can be recreated when needed.
   It also sets dirbutton, formatbutton labels and filetext string.
   It does not recreate the extra command buttons.
   fsel_scan is the function to call when anything has changed or been changed.

 - MwFileselSetFormats is removed.

 - MwFileselAddExtra is removed and replaced with a resource.
---

More widgets:

 - Calendar
 - Ghostview?
 - HTML
 - Animator
 - Colorpicker
 - Colorwheel
 - Richtext
 - Table

Most widgets are used in Siag Office today.

---

ANSI C everywhere.

---

Fix compiler warnings.

---

Seems like all calendar widgets are unnecessarily complex. All I need
is something that can:

 - display the year + something to change it (set, step up, step down)
 - ditto for month
 - ditto for day of month
 - display the current month with the current day highlighted
 - change the current date when user clicks
 - call callback when current data changes

That should be no more than a couple hundred lines.

Maybe I shouldn't even bother with the year, month, day display thingie.

---

The Table widget should be relatively easy to add, but it requires
some work. First of all, it should be possible to use the widget
without adopting the font attribute scheme from Siag. That's
pretty straightforward, just add default resources that are used
when some other resource isn't set. It must also be possible to do
something like:

XtVaCreateManagedWidget("table",
	mwTableWidgetClass, topbox,
	(char *)0);

and have it behave reasonably. That includes adjustable row heights
and column widths, moving about using arrow keys, editing cells if
the table is editable, selecting using the mouse and so on. It's
quite a mess. There are numerous callbacks that must be defined,
such as:

 - cell changed
 - point moved
 - selection changed
 - cell was edited
 - cell being edited

and so on.

Data representaion is a bit of a problem. One solution is to cook
up some reasonably efficient representation for a sparse matrix and
use that. The column widths and row heights can all be stored in
simple arrays; that's no problem.

There is a problem, though: how do I deal with alien objects that
are not part of the grid, such as images or graphs? Maybe another
array called "aliens".

When a cell is edited, something like this must happen:

1. The textfield is put up over the cell as usual.
2. For every character typed, a callback is made so the
   application can update label1.
3. When the user presses Enter, a callback is made so the application
   can store the new value.
4. The application deals with the value as usual, figuring out what
   it is supposed to be.
5. The application stores the new text in the cell using a convenience
   function. That is, the string sent to the application in step 3
   was "2+2" and the string being stored here is "4".
6. The table redisplays itself.

---

Patches for existing applications to use Mowitz.

Sample applications for all widgets.

Drop-in replacement for Dialog as example application.

Utility routines:

 - Converting from Pixmap to XImage and back
 - Dithering
 - Support for major Drag and Drop protocols
 - Font management

