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.

The way this is done is by having gdk_window_begin_paint() and gdk_window_end_paint() 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 gtk-no-flicker branch of GTK+.

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.

The current fixed double-click timeout in GTK+ is too small for some users. This needs to be customizable

The purpose of the Pango project is to provide a system for layout and rendering of internationlized text. It handles most of the issues necessary to

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 compatiblity with existing programs.

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.

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.

While adding the above support, it may be desirable to generalize the input-method support to the point where

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 system separated from the GUI portions of GTK+.

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.

There needs to be a mechanism for themes to be able to control these arguments from the RC file.

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.

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.

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.)

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.

As part of this job it will be necessary to add Pango 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.

Currently, GTK+ has a large number of list and tree widgets (GtkList, GtkTree, GtkCList, GtkCTree), non of which are ideal. The GtkList and GtkTree widgets perform badly on large sets. (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 neither support arbitrary widgets nor custom drawing functions.

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.