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.

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.

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

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.

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

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.

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 and type systems separated from the GUI portions of GTK+ and be generalized for non-GUI usage.

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 <kenelson@ece.ucdavis.edu>, but this also requires a GLib based type and parameter system (ties in with "GLib based object and type system").

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.

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.

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.

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

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 (gtk_blue, gtk_red, etc.), the problem being colormap issues.

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.

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.

Make GtkSelectionData more like the MIME blobs in Swing and Qt. Consider a GtkClipboard object to simplify cut-and-paste handling.

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.

Look in to session management. Consider whether to use X11R6 SM, or some custom spec shared with KDE. Create GTK+ API for this.

Look at a small "What's This" popup widget, and a What's This system in general (this part could maybe be done for 1.4). A more difficult, probably a post-1.4 task, is to integrate a very simple little help browser gizmo into GTK.

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.

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.

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.

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.

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.

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

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.

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.

gdk-pixbuf is moving to become a GTK+ dependency, a new image-display widget is thus needed.

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

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.

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.

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.

A simple icon list widget, suitable for creating a file selector or the like.

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.

Figure out how to get GnomeCanvas or a derived work into GTK+ itself.