FAQ Update: - Minor cleanups (Emmanuel, me) - New questions: I need to add

[~andy/gtk] / 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>