path: root/TODO.xml

<!-- 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="70%" target="1.4">
      <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="70%" target="1.4">
      <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="1.4">
      <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@redhat.com</contact>
      <bugs>#3958</bugs>
    </entry>
  </section>

  <section>
    <title>Internationalization</title>
    
    <entry size="big" status="0%" target="1.4">
      <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="20%" target="1.4">
      <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="0%" target="1.4">
      <title>Rewrite Input Method Support</title>
      <description>
	<p>
	  Current support for Input Methods 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>
	  While adding the above support, it may be desirable to
	  generalize the input-method support to the point where 
	</p>
      </description>
      <contact>gtk-i18n-list@redhat.com</contact>
    </entry>
  </section>

  <section>
    <title>GTK+ Core</title>

    <entry size="big" status="5%" target="1.4">
      <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="1.4">
      <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@redhat.com</contact>
    </entry>

    <entry size="big" status="0%" target="1.4">
      <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="1.4">
      <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="1.4">
      <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="1.4">
      <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="1.4">
      <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@redhat.com</contact>
    </entry>

  </section>

  <section>
    <title>GTK+ Widgets</title>

    <entry size="small" status="0%" target="1.4">
      <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@redhat.com</contact>
    </entry>

    <entry size="big" status="50%" target="1.4">
      <title>Replace GtkText Widget</title>
      <description>
	<p>
	  The GtkText widget is badly in need of replacement, since it is
	  buggy and insufficiently feature rich. There are a number
	  of possible candidates for a replacement, with the most
	  promising at the current time being Havoc Pennington's
	  (hp@redhat.com) port of the Tk Text widget.
	</p>
	<p>
	  As part of this job it will be necessary to add
	  <a href="http://www.pango.org">Pango</a> support to the
	  replacement. The structure of the Tk text widget port seems
	  suited to this as it works paragraph-by-paragraph, and
	  Pango works at a sub-paragraph scale.
	</p>
      </description>
      <contact>gtk-devel-list@redhat.com</contact>
    </entry>

    <entry size="small" status="0%" target="1.4">
      <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@redhat.com</contact>
    </entry>

    <entry size="small" status="0%" target="1.4">
      <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@redhat.com</contact>
    </entry>

    <entry size="small" status="0%" target="1.4 ?">
      <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@redhat.com</contact>
    </entry>

    <entry size="big" status="90%" target="1.4">
      <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 1.4
	  proper at some point.
	</p>
      </description>
      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
    </entry>

    <entry size="medium" status="90%" target="1.4">
      <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="0%" target="> 1.4">
      <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@redhat.com</contact>
    </entry>
  </section>
</todo>