Remove some files whose content is either obsolete or has been moved

	* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
	docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
	gdk/TODO: Remove some files whose content is either obsolete or
	has been moved elsewhere.

	* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
	to these files.

1 files changed, 0 insertions, 739 deletions

diff --git a/TODO.xml b/TODO.xml
deleted file mode 100644
index 09967526c..000000000
--- a/TODO.xml
+++ /dev/null
@@ -1,739 +0,0 @@
-<!-- This is used to generate the online TODO list for GTK+ using
-     the script docs/make-todo. Whenever a change to this file is
-     committed to CVS,the file is run through make-todo and the online
-     version updated. If you modify this file, you should check for
-     parse errors by running:
-
-     $ docs/make-todo TODO.xml > /dev/null
-
-     before committing, or you may screw up the online version --> 
-<todo logourl="gtk-logo-rgb.gif">
-  <title>GTK+ TODO list</title>
-  <section>
-    <title>GDK</title>
-    
-    <entry size="medium" status="90%" target="2.0">
-      <title>Add backing store support</title>
-      <description>
-	<p>
-	  GTK+'s drawing model involves clearing to a background, and
-	  then drawing widgets on top of this. Without having
-	  backing-store support, this results in flickering in various
-	  situations. Backing store cannot be added widget-by-widget,
-	  because the drawing in a particular window is not confined
-	  to a single widget. Instead it needs to be added per GDK
-	  window. 
-	</p>
-	<p>
-	  The way this is done is by having
-	  <tt>gdk_window_begin_paint()</tt>
-	  and <tt>gdk_window_end_paint()</tt> functions that
-	  redirect all drawing to a particular window to an offscreen
-	  pixmap, and then copy that offscreen pixmap back onto the
-	  screen when the paint operation is done. The implementation
-	  of this is mostly complete in the <tt>gtk-no-flicker</tt> branch of
-	  GTK+.
-	</p>
-      </description>
-      <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
-      <contact>Owen Taylor &lt;otaylor@redhat.com&gt;</contact>
-    </entry>
-
-    <entry size="medium" status="90%" target="2.0">
-      <title>32 Bit Coordinates</title>
-      <description>
-	<p>
-	  GTK+-1.2 and earlier share X's limitation on the
-	  size of coordinates and restrict all dimensions
-	  to 16 bit quantities. By clever use of X it is
-	  possible to lift this restriction and present a
-	  full 32-bit space to the user.
-	</p>
-	<p>
-	  There are some difficulties with performance in this
-	  approach - mostly because scrolling can involve mapping and
-	  unmapping lots of widgets, but in general, current
-	  trials in this area seem to work pretty well.  
-	</p>
-      </description>
-      <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
-      <contact>Owen Taylor &lt;otaylor@redhat.com&gt;</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Customizable double-click timeout</title>
-      <description>
-	<p>
-	  The current fixed double-click timeout in GTK+
-	  is too small for some users. This needs to be
-	  customizable
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-      <bugs>#3958</bugs>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Make color handling more convenient</title>
-      <description>
-	<p>
-          Add some color convenience functions; such as a way to get an
-          allocated GdkColor from GdkRGB, and export functions from gtkstyle.c
-          that lighten/darken a given color, and set a color from HSV in
-          addition to RGB. Also, consider having static variables that contain
-          preallocated common colors (gdk_blue, gdk_red, etc.), the problem
-          being colormap issues.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Cursors</title>
-      <description>
-	<p>
-          Two tasks: 1) move the cursors in the cursor font that people actually
-          care about to the top of the gdkcursor.h header file, and put a nice
-          list of the 15 cursors people actually care about in the docs 2) if
-          the cursor font lacks some commonly-useful cursors (like magnifying
-          glass), add these cursors to gdkcursor.h and then emulate them in
-          gdk_cursor_new by transparently creating the cursor from a bitmap.
-          The list of Qt cursors is worth http://doc.trolltech.com/qcursor.html
-          looking at for this task.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="medium" status="100%" target="2.0">
-      <title>Make GdkRGB work on any visual</title>
-      <description>
-	<p>
-          GdkRGB should be able to render to an arbitrary visual
-          (i.e. the visual shouldn't be fixed at gdk_rgb_init() 
-          time). This will break gdk_rgb_gc_set_foreground() and 
-          friends, though.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-  </section> <!-- GDK -->
-
-  <section>
-    <title>Internationalization</title>
-    
-    <entry size="big" status="90%" target="2.0">
-      <title>Integrate Pango</title>
-      <description>
-	<p>
-	  The purpose of the Pango project is to provide a system for
-	  layout and rendering of internationalized text. It handles
-	  most of the issues necessary to 
-	</p>
-      </description>
-      <url>http://www.pango.org</url>
-      <contact>gtk-i18n-list@redhat.com</contact>
-    </entry>
-
-    <entry size="medium" status="90%" target="2.0">
-      <title>Switch to using UTF-8</title>
-      <description>
-	<p>
-	  This is closely related to Pango integration. Pango deals
-	  with all strings in terms of UTF-8; by switching GTK+ over
-	  to UTF-8 we make it considerably simpler for developers to
-	  support multiple languages properly while still retaining
-	  a large degree of compatibility with existing programs.
-	</p>
-	<p>
-	  Some work has already been done on this as part of the Win32
-	  port, since the Win32 port is currently using UTF-8 for all
-	  strings. In general, this should be an easy job; the hardest
-	  parts are places like GtkFileSelection, cut and paste, and
-	  input method support where there is interaction between GTK+
-	  and the operating system.
-	</p>
-      </description>
-      <contact>gtk-i18n-list@redhat.com</contact>
-    </entry>
-
-    <entry size="big" status="60%" target="2.0">
-      <title>Rewrite Input Method Support</title>
-      <description>
-	<p>
-	  Support for Input Methods is GTK+-1.2 is done via XIM, with
-	  supported styles being over-the-spot and the root-window
-	  styles. However, the over-the-spot style is not going to
-	  work well with the Pango integration, since it relies on the
-	  text rendering in the program being done in the standard
-	  Xlib style, so it will be necessary to also support
-	  on-the-spot input. On-the-spot input is done by supplying a
-	  set of callbacks that are invoked by the input methods.
-	</p>
-	<p>
-	  GTK+-2.0 will have a new system with loadable input method
-	  modules. These modules can either be implemented using XIM,
-	  or written from scratch.
-	</p>
-      </description>
-      <contact>gtk-i18n-list@redhat.com</contact>
-    </entry>
-  </section> <!-- i18n -->
-
-  <section>
-    <title>GTK+ Core</title>
-
-    <entry size="big" status="60%" target="2.0">
-      <title>GLib based object and type system</title>
-      <description>
-	<p>
-	  The GTK+ object system is already in use in quite a few different
-	  non-GUI applications; it would be desirable for these uses
-	  to have the object and type systems separated from the GUI portions
-	  of GTK+ and be generalized for non-GUI usage.
-	</p>
-      </description>
-      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
-    </entry>
-
-    <entry size="big" status="1%" target="2.0">
-      <title>Overall callback improvements</title>
-      <description>
-	<p>
-	  The GTK+ type and signal systems need significant improvements to
-	  allow signal creation with default handlers from language bindings
-	  and to aid language bindings in deriving new objects.
-	  One aspect of this is the Closure support, recently suggested by
-	  Karl Nelson &lt;kenelson@ece.ucdavis.edu&gt;, but this also
-	  requires a GLib based type and parameter system (ties in with
-	  "GLib based object and type system").
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="big" status="0%" target="2.0">
-      <title>State change notification</title>
-      <description>
-	<p>
-	  GTK+ objects emit various types of signals, some to perform
-	  arbitrary actions, some to allow customization from user code,
-	  and some signals are emitted to notify of certain changes
-	  of an object. For the latter, what really is required is a
-	  gneneric signal that can be used to monitor *any* kind of object
-	  changes. For that, all object changes need to be routed through
-	  a central point (otherwise the signal emissions are spread all
-	  over the object implementation), i.e. an object argument setter.
-	  The state change notification signal doesn't need to be emitted
-	  syncronously, in fact, it's probably most effective to always
-	  emit this asynchronously, so subsequent changes are accumulated.
-	</p>
-      </description>
-      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
-    </entry>
-
-    <entry size="big" status="5%" target="2.0">
-      <title>Widget as sensitivity/grab state machine</title>
-      <description>
-	<p>
-	  Maintenance of pointer and keybnoard grabs is currently very
-	  tedious and error-prone, most widget's cook up their own stuff
-	  in this regard.
-	  By moving the general concept of "Grabs" to the GTK+ level as
-	  a widget state, and providing a new signal for alterations of
-	  a widget's state ("visible", "visible+insensitive",
-	  "visible+grab", "hidden", "hidden+insensitive", etc.), things
-	  can be unified and more stabelize. A couple of bugs, such as
-	  insensitive widgets still holding a grab, or buttons that
-	  still think they are depressed when hidden, will be squeezed
-	  automatically with that.
-	</p>
-      </description>
-      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
-    </entry>
-
-    <entry size="big" status="0%" target="2.0">
-      <title>Allow argument customization</title>
-      <description>
-	<p>
-	  Many types of object arguments (expander style in the CList,
-	  default padding in button boxes, etc), conceptually go with
-	  the theme, or as user preferences; they should not be set by
-	  a particular program.
-	</p>
-	<p>
-	  There needs to be a mechanism for themes to be able to
-	  control these arguments from the RC file. 
-	</p>
-      </description>
-    </entry>
-
-    <entry size="medium" status="0%" target="2.0">
-      <title>Allow global customization</title>
-      <description>
-	<p>
-	  There are a number of global parameters in GTK+ and GDK that should be
-	  customizable by the user, such as the double-click timeout,
-	  or whether widgets should be backing-stored by default. 
-	</p>
-	<p>
-	  If we had argument customization from an RC file, it might
-	  be possible to do this simply with a global object with
-	  arguments for the various global parameters that was
-	  customized in the same fashion as object arguments.
-	</p>
-      </description>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Gtk+ Modules installation directory</title>
-      <description>
-	<p>
-	  Gtk+ needs to support an extra lib/ directory, to search
-	  for dynamically loadable modules, it also needs to support
-	  an environment variable to specify module search paths.
-	  This has quite some cross-platform issues with the GModule
-	  code (especially on AIX).
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-
-    <entry size="small" status="20%" target="2.0">
-      <title>Convenient widget setup</title>
-      <description>
-	<p>
-          Make it simpler to set all the basic attributes of a widget.  Might
-          want set_tooltip(), set_accel(), set_color(FOREGROUND, color),
-          set_min_size() (usize does this, but needs a rename), set_whatsthis(),
-          etc. set_accel() may not work for all widgets, may need a convenience
-          API for button and label accelerators specifically.
-	</p>
-        <p>
-          The idea is that it should be easy, out of the box, to set up a widget
-          with all the nice touches and features the widget really should
-          have. Users shouldn't need to do their own convenience functions for
-          this.
-        </p>
-
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="medium" status="0%" target="> 2.0">
-      <title>Make selections/clipboard more convenient</title>
-      <description>
-	<p>
-          Make GtkSelectionData more like the MIME blobs in Swing and Qt.
-          Consider a GtkClipboard object to simplify cut-and-paste handling.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-
-    <entry size="small" status="80%" target="2.0">
-      <title>Stock label/icon system</title>
-      <description>
-	<p>
-          A system like GnomeStock for getting a standard labels/icons 
-          for menus and toolbars. Should be extensible by themes, and 
-          by libgnomeui. Some work already done on this.
-	</p>
-      </description>
-      <contact>hp@redhat.com</contact>
-    </entry>
-
-
-    <entry size="big" status="0%" target="> 2.0">
-      <title>Session Management</title>
-      <description>
-	<p>
-          Look in to session management. Consider whether to use 
-          X11R6 SM, or some custom spec shared with KDE. Create
-          GTK+ API for this.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="big" status="0%" target="> 2.0">
-      <title>Online help enhancements</title>
-      <description>
-	<p>
-          Look at a small "What's This" popup widget, 
-          and a What's This system in general (this part 
-          could maybe be done for 2.0). A more difficult, probably 
-          a post-2.0 task, is to integrate a very simple little
-          help browser gizmo into GTK.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-
-    <entry size="medium" status="0%" target="2.0">
-      <title>GUI-editable means of user configuration</title>
-      <description>
-	<p>
-          Need to be able to set double click time, whether cursors
-          blink, etc., from a control panel type of deal.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-  </section> <!-- Core -->
-
-  <section>
-    <title>GTK+ Widgets</title>
-
-    <entry size="small" status="100%" target="2.0">
-      <title>Make GtkFrame use a label</title>
-      <description>
-	<p>
-	  The title of a frame should simply be another child widget
-	  which, by default, holds a label widget. This will important
-	  with Pango where proper text behavior will be more complex to
-	  implement, but is also useful for certain user-interface
-	  designs. (It can be useful, for example, to put a checkbutton
-	  in that slot.)
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="big" status="90%" target="2.0">
-      <title>Replace GtkText Widget</title>
-      <description>
-	<p>
-	  The GtkText widget is badly in need of replacement, since it
-	  is buggy and insufficiently feature rich. This is being done
-	  using Havoc Pennington's port of the Tk Text widget.
-	</p>
-	<p>
-	  As part of this job <a href="http://www.pango.org">Pango</a>
-	  support is being added to the replacement. The structure of
-	  the Tk text widget port is suited to this as it works
-	  paragraph-by-paragraph, and Pango works at a sub-paragraph
-	  scale. The main remaining tasks here are to implement
-	  incremental reflow to make performance acceptable and to
-	  implement embedded pixmaps and widgets.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="20%" target="2.0">
-      <title>Improve Radio/Checkbutton Look</title>
-      <description>
-	<p>
-	  The default look for the radio and checkbuttons is both
-	  unattractive and not friendly to the user . Motif did not
-	  get this one right, and we should not keep on following the
-	  Motif look. The right thing here is probably to copy the
-	  Windows appearance for these controls fairly closely. This
-	  will fit in with well with the rest of the GTK+ look.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="99%" target="2.0">
-      <title>Improve Submenu Navigation</title>
-      <description>
-	<p>
-	  Navigating through a deep menu tree in GTK+ is currently
-	  quite tricky, because as soon as one leaves a menu item,
-	  the submenu disappears. The way that the Macintosh is
-	  reputed to handle this is that to pop down the current
-	  submenu, you have to leave the triangle defined by the
-	  upper left hand corner of the menu item and right
-	  side of the submenu.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0 ?">
-      <title>Improve Spinbutton Look</title>
-      <description>
-	<p>
-	  Spinbuttons currently appear to have lumpy boundaries,
-	  because sides of the arrows aren't at an angle that
-	  meshes well with the pixel grid. However, fixing this
-	  would require making the spinbuttons narrower and
-	  harder to hit. This points out a general problem with
-	  the spinbutton (and the arrows on the scrollbars) - the
-	  target area for clicks actually the bounding box of the
-	  arrows, but the user thinks that they must click on the
-	  arrows themselves. It would probably be more friendly
-	  to use a square button with an arrow drawn on top instead
-	  of a arrow-shaped button, the approach taken by most other
-	  windowing systems.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="big" status="90%" target="2.0">
-      <title>Supply horizontable/vertical wrapping boxes</title>
-      <description>
-	<p>
-	  An often requested feature are wrapping containers, at this
-	  point, gimp's development version already uses such widgets:
-	  horizontable/vertical wrap boxes, that need to go into 2.0
-	  proper at some point.
-	</p>
-      </description>
-      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
-    </entry>
-
-    <entry size="medium" status="90%" target="2.0">
-      <title>Improved generic combo support</title>
-      <description>
-	<p>
-	  Gtk+'s combo box has several drawbacks in design and
-	  implementation. An new attempt at providing the combo box
-	  functionality with improved flexibility has been made with
-	  the GtkClueHunter widget, sitting in the CVS module "gle".
-	</p>
-      </description>
-      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
-    </entry>
-
-    <entry size="big" status="40%" target="2.0?">
-      <title>Add unified set of List/Tree/Grid widgets</title>
-      <description>
-	<p>
-	  Currently, GTK+ has a large number of list and tree widgets
-	  (GtkList, GtkTree, GtkCList, GtkCTree), none of which are
-	  ideal. The GtkList and GtkTree widgets perform badly on large
-	  number of items. (GtkTree widget is also quite buggy.) GtkCList
-	  and GtkCTree mostly solve the size problem, but are quite
-	  complex and, despite that, not very flexible. They are limited to
-	  displaying pixmaps and text, and can neither support arbitrary
-	  widgets nor custom drawing functions.
-	</p>
-	<p>
-	  In addition to list and tree widgets, a closely related need
-	  is a sheet widget that displays a (possibly editable) 2-D grid.
-	  It would be desirable to have a complete set of widgets that
-	  could be presented as the one-true-solution for these needs.
-	  Model/View techniques could be used effectively to increase
-	  both the simplicity and power of the interfaces.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>GtkImage</title>
-      <description>
-	<p>
-          gdk-pixbuf is moving to become a GTK+ dependency, a new image-display
-          widget is thus needed.
-	</p>
-      </description>
-      <contact>hp@redhat.com</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Attempt to fix GtkStatusbar</title>
-      <description>
-	<p>
-          GtkStatusbar is too inconvenient to use.
-          The only non-breakage-inducing fix we could
-          come up with is to permit 0 as a context ID, so you
-          don't have to use gtk_statusbar_get_context_id().
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-    
-    <entry size="small" status="95%" target="2.0">
-      <title>Decruft GtkProgress, GtkProgressbar</title>
-      <description>
-        <p>UPDATE: this is done, just need to apply the patch.
-        </p>
-        
-	<p>
-          This interface is just a disaster of overcomplexity;
-          it should pretty much just be set_percentage(), 
-          pulse() (to move during activity mode), and set_text().
-          There's no reason that there are two objects, should 
-          just be one interface. Almost all the functions
-          that currently exist should be deprecated.
-	</p>
-      </description>
-      <contact>hp@redhat.com</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Entry validation hooks</title>
-      <description>
-	<p>
-          Simple hooks for validation in a GtkEntry.  Pretty much just a
-          "validate" callback which takes a string (current entry contents) and
-          returns either VALID, INVALID, or COULDBEVALID. Then the 
-          GtkEntry calls this function if it's set, and does the appropriate 
-          UI things. GTK should come with validators for int and float,
-          see GtkSpinButton where these are already implemented.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="big" status="0%" target="> 2.0">
-      <title>pseudo-MDI Widget</title>
-      <description>
-	<p>
-          Add a widget that lets you rearrange various views (similar to many
-          IDEs, like Visual SlickEdit or JBuilder). Basically there should be a
-          central slot and 4 slots around the sides; each slot holds one or more
-          views. If two views are dropped in the same slot, then a notebook is
-          created displaying both views. If a view is dropped outside the
-          application window, it becomes a standalone window. It should be
-          possible to restrict whether a view can be dropped on the sides,
-          horizontal/vertical sides only, in the central content area, or in
-          any of those places.
-	</p>
-        <p>
-          (Havoc has a proposed interface for this, mail hp@redhat.com)
-        </p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="medium" status="0%" target="> 2.0">
-      <title>Icon List Widget</title>
-      <description>
-	<p>
-          A simple icon list widget, suitable for creating a file selector or
-          the like.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="medium" status="0%" target="> 2.0">
-      <title>Dock widget</title>
-      <description>
-	<p>
-          Add a widget like GnomeDock (perhaps based on GnomeDock)
-          that allows people to put rearrangeable toolbars, menubars, etc. 
-          around a central content area. The widget should have hooks for 
-          saving the current positions of the various docked bars.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="big" status="0%" target="> 2.0">
-      <title>Canvas widget</title>
-      <description>
-	<p>
-          Figure out how to get GnomeCanvas or a derived work into GTK+ itself.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="medium" status="57%" target="2.0">
-      <title>Menu scroll</title>
-      <description>
-	<p>
-          When menus are bigger than the screen, allow scrolling
-          as on the Mac.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="medium" status="20%" target="2.0">
-      <title>Toolbar/menubar wrap</title>
-      <description>
-	<p>
-          When toolbars and menubars are too wide, do some sort of 
-          wrapping or drop-down deal. (See Windows/Mac apps for examples.)
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Blink cursor in GtkEntry</title>
-      <description>
-	<p>
-          Make the cursor optionally blink in GtkEntry. Beware, the entry code
-          is somewhat in flux; mail Owen and ask.
-	</p>
-      </description>
-      <contact>otaylor@redhat.com</contact>
-    </entry>
-
-    <entry size="small" status="100%" target="2.0">
-      <title>Don't highlight first menu item when menus come up</title>
-      <description>
-	<p>
-          Keep GtkMenu from prelighting the first menu item.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="100%" target="2.0">
-      <title>Integrate new color selector</title>
-      <description>
-	<p>
-          There's a new color selector in CVS (module gnome-colorsel),
-          it needs to be folded in to GTK and any remaining issues resolved.
-          (This new selector is API-compatible with the old one, and 
-          still called GtkColorSelector).
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="medium" status="70%" target="2.0">
-      <title>Write new font selector</title>
-      <description>
-	<p>
-          Pango introduces a new font handling system,
-          replacing the XLFD system. Need a font selector for this.
-          The XLFD selector should probably remain, for apps where
-          it makes sense (like gnome-terminal probably).
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Stack Widget</title>
-      <description>
-	<p>
-          Jonathan has a widget like a tabless/frameless notebook, used for
-          something like the GNOME control center where you want to toggle which
-          widget is visible to the user. Needs to be cleaned up and considered
-          for GTK.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org, jrb@redhat.com</contact>
-    </entry>
-
-    <entry size="small" status="0%" target="2.0">
-      <title>Clean up GtkNotebook</title>
-      <description>
-	<p>
-          GtkNotebook currently breaks GTK invariants about
-          mapping/visibility/etc., needs fixing.
-	</p>
-      </description>
-      <contact>gtk-devel-list@gnome.org</contact>
-    </entry>
-
-  </section> <!-- GTK+ -->
-</todo>
-