1 <!-- This is used to generate the online TODO list for GTK+ using
2 the script docs/make-todo. Whenever a change to this file is
3 committed to CVS,the file is run through make-todo and the online
4 version updated. If you modify this file, you should check for
5 parse errors by running:
7 $ docs/make-todo > /dev/null
9 before committing, or you may screw up the online version -->
14 <entry size="medium" status="70%" target="1.4">
15 <title>Add backing store support</title>
18 GTK+'s drawing model involves clearing to a background, and
19 then drawing widgets on top of this. Without having
20 backing-store support, this results in flickering in various
21 situations. Backing store cannot be added widget-by-widget,
22 because the drawing in a particular window is not confined
23 to a single widget. Instead it needs to be added per GDK
27 The way this is done is by having
28 <tt>gdk_window_begin_paint()</tt>
29 and <tt>gdk_window_end_paint()</tt> functions that
30 redirect all drawing to a particular window to an offscreen
31 pixmap, and then copy that offscreen pixmap back onto the
32 screen when the paint operation is done. The implementation
33 of this is mostly complete in the <tt>gtk-no-flicker</tt> branch of
37 <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
38 <contact>Owen Taylor <otaylor@redhat.com></contact>
41 <entry size="medium" status="70%" target="1.4">
42 <title>32 Bit Coordinates</title>
45 GTK+-1.2 and earlier share X's limitation on the
46 size of coordinates and restrict all dimensions
47 to 16 bit quantities. By clever use of X it is
48 possible to lift this restriction and present a
49 full 32-bit space to the user.
52 There are some difficulties with performance in this
53 approach - mostly because scrolling can involve mapping and
54 unmapping lots of widgets, but in general, current
55 trials in this area seem to work pretty well.
58 <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
59 <contact>Owen Taylor <otaylor@redhat.com></contact>
62 <entry size="small" status="0%" target="1.4">
63 <title>Customizable double-click timeout</title>
66 The current fixed double-click timeout in GTK+
67 is too small for some users. This needs to be
71 <contact>gtk-devel-list@redhat.com</contact>
77 <title>Internationalization</title>
79 <entry size="big" status="0%" target="1.4">
80 <title>Integrate Pango</title>
83 The purpose of the Pango project is to provide a system for
84 layout and rendering of internationalized text. It handles
85 most of the issues necessary to
88 <url>http://www.pango.org</url>
89 <contact>gtk-i18n-list@redhat.com</contact>
92 <entry size="medium" status="20%" target="1.4">
93 <title>Switch to using UTF-8</title>
96 This is closely related to Pango integration. Pango deals
97 with all strings in terms of UTF-8; by switching GTK+ over
98 to UTF-8 we make it considerably simpler for developers to
99 support multiple languages properly while still retaining
100 a large degree of compatibility with existing programs.
103 Some work has already been done on this as part of the Win32
104 port, since the Win32 port is currently using UTF-8 for all
105 strings. In general, this should be an easy job; the hardest
106 parts are places like GtkFileSelection, cut and paste, and
107 input method support where there is interaction between GTK+
108 and the operating system.
111 <contact>gtk-i18n-list@redhat.com</contact>
114 <entry size="big" status="0%" target="1.4">
115 <title>Rewrite Input Method Support</title>
118 Current support for Input Methods is done via XIM, with
119 supported styles being over-the-spot and the root-window
120 styles. However, the over-the-spot style is not going to
121 work well with the Pango integration, since it relies on the
122 text rendering in the program being done in the standard
123 Xlib style, so it will be necessary to also support
124 on-the-spot input. On-the-spot input is done by supplying a
125 set of callbacks that are invoked by the input methods.
128 While adding the above support, it may be desirable to
129 generalize the input-method support to the point where
132 <contact>gtk-i18n-list@redhat.com</contact>
137 <title>GTK+ Core</title>
139 <entry size="big" status="5%" target="1.4">
140 <title>GLib based object and type system</title>
143 The GTK+ object system is already in use in quite a few different
144 non-GUI applications; it would be desirable for these uses
145 to have the object and type systems separated from the GUI portions
146 of GTK+ and be generalized for non-GUI usage.
149 <contact>Tim Janik <timj@gtk.org></contact>
152 <entry size="big" status="1%" target="1.4">
153 <title>Overall callback improvements</title>
156 The GTK+ type and signal systems need significant improvements to
157 allow signal creation with default handlers from language bindings
158 and to aid language bindings in deriving new objects.
159 One aspect of this is the Closure support, recently suggested by
160 Karl Nelson <kenelson@ece.ucdavis.edu>, but this also
161 requires a GLib based type and parameter system (ties in with
162 "GLib based object and type system").
165 <contact>gtk-devel-list@redhat.com</contact>
168 <entry size="big" status="0%" target="1.4">
169 <title>State change notification</title>
172 GTK+ objects emit various types of signals, some to perform
173 arbitrary actions, some to allow customization from user code,
174 and some signals are emitted to notify of certain changes
175 of an object. For the latter, what really is required is a
176 gneneric signal that can be used to monitor *any* kind of object
177 changes. For that, all object changes need to be routed through
178 a central point (otherwise the signal emissions are spread all
179 over the object implementation), i.e. an object argument setter.
180 The state change notification signal doesn't need to be emitted
181 syncronously, in fact, it's probably most effective to always
182 emit this asynchronously, so subsequent changes are accumulated.
185 <contact>Tim Janik <timj@gtk.org></contact>
188 <entry size="big" status="5%" target="1.4">
189 <title>Widget as sensitivity/grab state machine</title>
192 Maintenance of pointer and keybnoard grabs is currently very
193 tedious and error-prone, most widget's cook up their own stuff
195 By moving the general concept of "Grabs" to the GTK+ level as
196 a widget state, and providing a new signal for alterations of
197 a widget's state ("visible", "visible+insensitive",
198 "visible+grab", "hidden", "hidden+insensitive", etc.), things
199 can be unified and more stabelize. A couple of bugs, such as
200 insensitive widgets still holding a grab, or buttons that
201 still think they are depressed when hidden, will be squeezed
202 automatically with that.
205 <contact>Tim Janik <timj@gtk.org></contact>
208 <entry size="big" status="0%" target="1.4">
209 <title>Allow argument customization</title>
212 Many types of object arguments (expander style in the CList,
213 default padding in button boxes, etc), conceptually go with
214 the theme, or as user preferences; they should not be set by
215 a particular program.
218 There needs to be a mechanism for themes to be able to
219 control these arguments from the RC file.
224 <entry size="medium" status="0%" target="1.4">
225 <title>Allow global customization</title>
228 There are a number of global parameters in GTK+ and GDK that should be
229 customizable by the user, such as the double-click timeout,
230 or whether widgets should be backing-stored by default.
233 If we had argument customization from an RC file, it might
234 be possible to do this simply with a global object with
235 arguments for the various global parameters that was
236 customized in the same fashion as object arguments.
241 <entry size="small" status="0%" target="1.4">
242 <title>Gtk+ Modules installation directory</title>
245 Gtk+ needs to support an extra lib/ directory, to search
246 for dynamically loadable modules, it also needs to support
247 an environment variable to specify module search paths.
248 This has quite some cross-platform issues with the GModule
249 code (especially on AIX).
252 <contact>gtk-devel-list@redhat.com</contact>
258 <title>GTK+ Widgets</title>
260 <entry size="small" status="0%" target="1.4">
261 <title>Make GtkFrame use a label</title>
264 The title of a frame should simply be another child widget
265 which, by default, holds a label widget. This will important
266 with Pango where proper text behavior will be more complex to
267 implement, but is also useful for certain user-interface
268 designs. (It can be useful, for example, to put a checkbutton
272 <contact>gtk-devel-list@redhat.com</contact>
275 <entry size="big" status="50%" target="1.4">
276 <title>Replace GtkText Widget</title>
279 The GtkText widget is badly in need of replacement, since it is
280 buggy and insufficiently feature rich. There are a number
281 of possible candidates for a replacement, with the most
282 promising at the current time being Havoc Pennington's
283 (hp@redhat.com) port of the Tk Text widget.
286 As part of this job it will be necessary to add
287 <a href="http://www.pango.org">Pango</a> support to the
288 replacement. The structure of the Tk text widget port seems
289 suited to this as it works paragraph-by-paragraph, and
290 Pango works at a sub-paragraph scale.
293 <contact>gtk-devel-list@redhat.com</contact>
296 <entry size="small" status="0%" target="1.4">
297 <title>Improve Radio/Checkbutton Look</title>
300 The default look for the radio and checkbuttons is both
301 unattractive and not friendly to the user . Motif did not
302 get this one right, and we should not keep on following the
303 Motif look. The right thing here is probably to copy the
304 Windows appearance for these controls fairly closely. This
305 will fit in with well with the rest of the GTK+ look.
308 <contact>gtk-devel-list@redhat.com</contact>
311 <entry size="small" status="0%" target="1.4">
312 <title>Improve Submenu Navigation</title>
315 Navigating through a deep menu tree in GTK+ is currently
316 quite tricky, because as soon as one leaves a menu item,
317 the submenu disappears. The way that the Macintosh is
318 reputed to handle this is that to pop down the current
319 submenu, you have to leave the triangle defined by the
320 upper left hand corner of the menu item and right
324 <contact>gtk-devel-list@redhat.com</contact>
327 <entry size="small" status="0%" target="1.4 ?">
328 <title>Improve Spinbutton Look</title>
331 Spinbuttons currently appear to have lumpy boundaries,
332 because sides of the arrows aren't at an angle that
333 meshes well with the pixel grid. However, fixing this
334 would require making the spinbuttons narrower and
335 harder to hit. This points out a general problem with
336 the spinbutton (and the arrows on the scrollbars) - the
337 target area for clicks actually the bounding box of the
338 arrows, but the user thinks that they must click on the
339 arrows themselves. It would probably be more friendly
340 to use a square button with an arrow drawn on top instead
341 of a arrow-shaped button, the approach taken by most other
345 <contact>gtk-devel-list@redhat.com</contact>
348 <entry size="big" status="90%" target="1.4">
349 <title>Supply horizontable/vertical wrapping boxes</title>
352 An often requested feature are wrapping containers, at this
353 point, gimp's development version already uses such widgets:
354 horizontable/vertical wrap boxes, that need to go into 1.4
355 proper at some point.
358 <contact>Tim Janik <timj@gtk.org></contact>
361 <entry size="medium" status="90%" target="1.4">
362 <title>Improved generic combo support</title>
365 Gtk+'s combo box has several drawbacks in design and
366 implementation. An new attempt at providing the combo box
367 functionality with improved flexibility has been made with
368 the GtkClueHunter widget, sitting in the CVS module "gle".
371 <contact>Tim Janik <timj@gtk.org></contact>
374 <entry size="big" status="0%" target="> 1.4">
375 <title>Add unified set of List/Tree/Grid widgets</title>
378 Currently, GTK+ has a large number of list and tree widgets
379 (GtkList, GtkTree, GtkCList, GtkCTree), none of which are
380 ideal. The GtkList and GtkTree widgets perform badly on large
381 number of items. (GtkTree widget is also quite buggy.) GtkCList
382 and GtkCTree mostly solve the size problem, but are quite
383 complex and, despite that, not very flexible. They are limited to
384 displaying pixmaps and text, and can neither support arbitrary
385 widgets nor custom drawing functions.
388 In addition to list and tree widgets, a closely related need
389 is a sheet widget that displays a (possibly editable) 2-D grid.
390 It would be desirable to have a complete set of widgets that
391 could be presented as the one-true-solution for these needs.
392 Model/View techniques could be used effectively to increase
393 both the simplicity and power of the interfaces.
396 <contact>gtk-devel-list@redhat.com</contact>