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 TODO.xml > /dev/null
9 before committing, or you may screw up the online version -->
10 <todo logourl="gtk-logo-rgb.gif">
11 <title>GTK+ TODO list</title>
15 <entry size="medium" status="90%" target="2.0">
16 <title>Add backing store support</title>
19 GTK+'s drawing model involves clearing to a background, and
20 then drawing widgets on top of this. Without having
21 backing-store support, this results in flickering in various
22 situations. Backing store cannot be added widget-by-widget,
23 because the drawing in a particular window is not confined
24 to a single widget. Instead it needs to be added per GDK
28 The way this is done is by having
29 <tt>gdk_window_begin_paint()</tt>
30 and <tt>gdk_window_end_paint()</tt> functions that
31 redirect all drawing to a particular window to an offscreen
32 pixmap, and then copy that offscreen pixmap back onto the
33 screen when the paint operation is done. The implementation
34 of this is mostly complete in the <tt>gtk-no-flicker</tt> branch of
38 <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
39 <contact>Owen Taylor <otaylor@redhat.com></contact>
42 <entry size="medium" status="90%" target="2.0">
43 <title>32 Bit Coordinates</title>
46 GTK+-1.2 and earlier share X's limitation on the
47 size of coordinates and restrict all dimensions
48 to 16 bit quantities. By clever use of X it is
49 possible to lift this restriction and present a
50 full 32-bit space to the user.
53 There are some difficulties with performance in this
54 approach - mostly because scrolling can involve mapping and
55 unmapping lots of widgets, but in general, current
56 trials in this area seem to work pretty well.
59 <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
60 <contact>Owen Taylor <otaylor@redhat.com></contact>
63 <entry size="small" status="0%" target="2.0">
64 <title>Customizable double-click timeout</title>
67 The current fixed double-click timeout in GTK+
68 is too small for some users. This needs to be
72 <contact>gtk-devel-list@gnome.org</contact>
76 <entry size="small" status="0%" target="2.0">
77 <title>Make color handling more convenient</title>
80 Add some color convenience functions; such as a way to get an
81 allocated GdkColor from GdkRGB, and export functions from gtkstyle.c
82 that lighten/darken a given color, and set a color from HSV in
83 addition to RGB. Also, consider having static variables that contain
84 preallocated common colors (gdk_blue, gdk_red, etc.), the problem
85 being colormap issues.
88 <contact>gtk-devel-list@gnome.org</contact>
91 <entry size="small" status="0%" target="2.0">
92 <title>Cursors</title>
95 Two tasks: 1) move the cursors in the cursor font that people actually
96 care about to the top of the gdkcursor.h header file, and put a nice
97 list of the 15 cursors people actually care about in the docs 2) if
98 the cursor font lacks some commonly-useful cursors (like magnifying
99 glass), add these cursors to gdkcursor.h and then emulate them in
100 gdk_cursor_new by transparently creating the cursor from a bitmap.
101 The list of Qt cursors is worth http://doc.trolltech.com/qcursor.html
102 looking at for this task.
105 <contact>gtk-devel-list@gnome.org</contact>
108 <entry size="medium" status="0%" target="2.0">
109 <title>Make GdkRGB work on any visual</title>
112 GdkRGB should be able to render to an arbitrary visual
113 (i.e. the visual shouldn't be fixed at gdk_rgb_init()
114 time). This will break gdk_rgb_gc_set_foreground() and
118 <contact>gtk-devel-list@gnome.org</contact>
121 </section> <!-- GDK -->
124 <title>Internationalization</title>
126 <entry size="big" status="85%" target="2.0">
127 <title>Integrate Pango</title>
130 The purpose of the Pango project is to provide a system for
131 layout and rendering of internationalized text. It handles
132 most of the issues necessary to
135 <url>http://www.pango.org</url>
136 <contact>gtk-i18n-list@redhat.com</contact>
139 <entry size="medium" status="90%" target="2.0">
140 <title>Switch to using UTF-8</title>
143 This is closely related to Pango integration. Pango deals
144 with all strings in terms of UTF-8; by switching GTK+ over
145 to UTF-8 we make it considerably simpler for developers to
146 support multiple languages properly while still retaining
147 a large degree of compatibility with existing programs.
150 Some work has already been done on this as part of the Win32
151 port, since the Win32 port is currently using UTF-8 for all
152 strings. In general, this should be an easy job; the hardest
153 parts are places like GtkFileSelection, cut and paste, and
154 input method support where there is interaction between GTK+
155 and the operating system.
158 <contact>gtk-i18n-list@redhat.com</contact>
161 <entry size="big" status="40%" target="2.0">
162 <title>Rewrite Input Method Support</title>
165 Support for Input Methods is GTK+-1.2 is done via XIM, with
166 supported styles being over-the-spot and the root-window
167 styles. However, the over-the-spot style is not going to
168 work well with the Pango integration, since it relies on the
169 text rendering in the program being done in the standard
170 Xlib style, so it will be necessary to also support
171 on-the-spot input. On-the-spot input is done by supplying a
172 set of callbacks that are invoked by the input methods.
175 GTK+-2.0 will have a new system with loadable input method
176 modules. These modules can either be implemented using XIM,
177 or written from scratch.
180 <contact>gtk-i18n-list@redhat.com</contact>
182 </section> <!-- i18n -->
185 <title>GTK+ Core</title>
187 <entry size="big" status="60%" target="2.0">
188 <title>GLib based object and type system</title>
191 The GTK+ object system is already in use in quite a few different
192 non-GUI applications; it would be desirable for these uses
193 to have the object and type systems separated from the GUI portions
194 of GTK+ and be generalized for non-GUI usage.
197 <contact>Tim Janik <timj@gtk.org></contact>
200 <entry size="big" status="1%" target="2.0">
201 <title>Overall callback improvements</title>
204 The GTK+ type and signal systems need significant improvements to
205 allow signal creation with default handlers from language bindings
206 and to aid language bindings in deriving new objects.
207 One aspect of this is the Closure support, recently suggested by
208 Karl Nelson <kenelson@ece.ucdavis.edu>, but this also
209 requires a GLib based type and parameter system (ties in with
210 "GLib based object and type system").
213 <contact>gtk-devel-list@gnome.org</contact>
216 <entry size="big" status="0%" target="2.0">
217 <title>State change notification</title>
220 GTK+ objects emit various types of signals, some to perform
221 arbitrary actions, some to allow customization from user code,
222 and some signals are emitted to notify of certain changes
223 of an object. For the latter, what really is required is a
224 gneneric signal that can be used to monitor *any* kind of object
225 changes. For that, all object changes need to be routed through
226 a central point (otherwise the signal emissions are spread all
227 over the object implementation), i.e. an object argument setter.
228 The state change notification signal doesn't need to be emitted
229 syncronously, in fact, it's probably most effective to always
230 emit this asynchronously, so subsequent changes are accumulated.
233 <contact>Tim Janik <timj@gtk.org></contact>
236 <entry size="big" status="5%" target="2.0">
237 <title>Widget as sensitivity/grab state machine</title>
240 Maintenance of pointer and keybnoard grabs is currently very
241 tedious and error-prone, most widget's cook up their own stuff
243 By moving the general concept of "Grabs" to the GTK+ level as
244 a widget state, and providing a new signal for alterations of
245 a widget's state ("visible", "visible+insensitive",
246 "visible+grab", "hidden", "hidden+insensitive", etc.), things
247 can be unified and more stabelize. A couple of bugs, such as
248 insensitive widgets still holding a grab, or buttons that
249 still think they are depressed when hidden, will be squeezed
250 automatically with that.
253 <contact>Tim Janik <timj@gtk.org></contact>
256 <entry size="big" status="0%" target="2.0">
257 <title>Allow argument customization</title>
260 Many types of object arguments (expander style in the CList,
261 default padding in button boxes, etc), conceptually go with
262 the theme, or as user preferences; they should not be set by
263 a particular program.
266 There needs to be a mechanism for themes to be able to
267 control these arguments from the RC file.
272 <entry size="medium" status="0%" target="2.0">
273 <title>Allow global customization</title>
276 There are a number of global parameters in GTK+ and GDK that should be
277 customizable by the user, such as the double-click timeout,
278 or whether widgets should be backing-stored by default.
281 If we had argument customization from an RC file, it might
282 be possible to do this simply with a global object with
283 arguments for the various global parameters that was
284 customized in the same fashion as object arguments.
289 <entry size="small" status="0%" target="2.0">
290 <title>Gtk+ Modules installation directory</title>
293 Gtk+ needs to support an extra lib/ directory, to search
294 for dynamically loadable modules, it also needs to support
295 an environment variable to specify module search paths.
296 This has quite some cross-platform issues with the GModule
297 code (especially on AIX).
300 <contact>gtk-devel-list@gnome.org</contact>
304 <entry size="small" status="0%" target="2.0">
305 <title>Convenient widget setup</title>
308 Make it simpler to set all the basic attributes of a widget. Might
309 want set_tooltip(), set_accel(), set_color(FOREGROUND, color),
310 set_min_size() (usize does this, but needs a rename), set_whatsthis(),
311 etc. set_accel() may not work for all widgets, may need a convenience
312 API for button and label accelerators specifically.
315 The idea is that it should be easy, out of the box, to set up a widget
316 with all the nice touches and features the widget really should
317 have. Users shouldn't need to do their own convenience functions for
322 <contact>gtk-devel-list@gnome.org</contact>
325 <entry size="medium" status="0%" target="> 2.0">
326 <title>Make selections/clipboard more convenient</title>
329 Make GtkSelectionData more like the MIME blobs in Swing and Qt.
330 Consider a GtkClipboard object to simplify cut-and-paste handling.
333 <contact>gtk-devel-list@gnome.org</contact>
337 <entry size="small" status="50%" target="2.0">
338 <title>Stock label/icon system</title>
341 A system like GnomeStock for getting a standard labels/icons
342 for menus and toolbars. Should be extensible by themes, and
343 by libgnomeui. Some work already done on this.
346 <contact>hp@redhat.com</contact>
350 <entry size="big" status="0%" target="> 2.0">
351 <title>Session Management</title>
354 Look in to session management. Consider whether to use
355 X11R6 SM, or some custom spec shared with KDE. Create
359 <contact>gtk-devel-list@gnome.org</contact>
362 <entry size="big" status="0%" target="> 2.0">
363 <title>Online help enhancements</title>
366 Look at a small "What's This" popup widget,
367 and a What's This system in general (this part
368 could maybe be done for 2.0). A more difficult, probably
369 a post-2.0 task, is to integrate a very simple little
370 help browser gizmo into GTK.
373 <contact>gtk-devel-list@gnome.org</contact>
377 <entry size="medium" status="0%" target="2.0">
378 <title>GUI-editable means of user configuration</title>
381 Need to be able to set double click time, whether cursors
382 blink, etc., from a control panel type of deal.
385 <contact>gtk-devel-list@gnome.org</contact>
388 </section> <!-- Core -->
391 <title>GTK+ Widgets</title>
393 <entry size="small" status="100%" target="2.0">
394 <title>Make GtkFrame use a label</title>
397 The title of a frame should simply be another child widget
398 which, by default, holds a label widget. This will important
399 with Pango where proper text behavior will be more complex to
400 implement, but is also useful for certain user-interface
401 designs. (It can be useful, for example, to put a checkbutton
405 <contact>gtk-devel-list@gnome.org</contact>
408 <entry size="big" status="90%" target="2.0">
409 <title>Replace GtkText Widget</title>
412 The GtkText widget is badly in need of replacement, since it
413 is buggy and insufficiently feature rich. This is being done
414 using Havoc Pennington's port of the Tk Text widget.
417 As part of this job <a href="http://www.pango.org">Pango</a>
418 support is being added to the replacement. The structure of
419 the Tk text widget port is suited to this as it works
420 paragraph-by-paragraph, and Pango works at a sub-paragraph
421 scale. The main remaining tasks here are to implement
422 incremental reflow to make performance acceptable and to
423 implement embedded pixmaps and widgets.
426 <contact>gtk-devel-list@gnome.org</contact>
429 <entry size="small" status="20%" target="2.0">
430 <title>Improve Radio/Checkbutton Look</title>
433 The default look for the radio and checkbuttons is both
434 unattractive and not friendly to the user . Motif did not
435 get this one right, and we should not keep on following the
436 Motif look. The right thing here is probably to copy the
437 Windows appearance for these controls fairly closely. This
438 will fit in with well with the rest of the GTK+ look.
441 <contact>gtk-devel-list@gnome.org</contact>
444 <entry size="small" status="40%" target="2.0">
445 <title>Improve Submenu Navigation</title>
448 Navigating through a deep menu tree in GTK+ is currently
449 quite tricky, because as soon as one leaves a menu item,
450 the submenu disappears. The way that the Macintosh is
451 reputed to handle this is that to pop down the current
452 submenu, you have to leave the triangle defined by the
453 upper left hand corner of the menu item and right
457 <contact>gtk-devel-list@gnome.org</contact>
460 <entry size="small" status="0%" target="2.0 ?">
461 <title>Improve Spinbutton Look</title>
464 Spinbuttons currently appear to have lumpy boundaries,
465 because sides of the arrows aren't at an angle that
466 meshes well with the pixel grid. However, fixing this
467 would require making the spinbuttons narrower and
468 harder to hit. This points out a general problem with
469 the spinbutton (and the arrows on the scrollbars) - the
470 target area for clicks actually the bounding box of the
471 arrows, but the user thinks that they must click on the
472 arrows themselves. It would probably be more friendly
473 to use a square button with an arrow drawn on top instead
474 of a arrow-shaped button, the approach taken by most other
478 <contact>gtk-devel-list@gnome.org</contact>
481 <entry size="big" status="90%" target="2.0">
482 <title>Supply horizontable/vertical wrapping boxes</title>
485 An often requested feature are wrapping containers, at this
486 point, gimp's development version already uses such widgets:
487 horizontable/vertical wrap boxes, that need to go into 2.0
488 proper at some point.
491 <contact>Tim Janik <timj@gtk.org></contact>
494 <entry size="medium" status="90%" target="2.0">
495 <title>Improved generic combo support</title>
498 Gtk+'s combo box has several drawbacks in design and
499 implementation. An new attempt at providing the combo box
500 functionality with improved flexibility has been made with
501 the GtkClueHunter widget, sitting in the CVS module "gle".
504 <contact>Tim Janik <timj@gtk.org></contact>
507 <entry size="big" status="40%" target="2.0?">
508 <title>Add unified set of List/Tree/Grid widgets</title>
511 Currently, GTK+ has a large number of list and tree widgets
512 (GtkList, GtkTree, GtkCList, GtkCTree), none of which are
513 ideal. The GtkList and GtkTree widgets perform badly on large
514 number of items. (GtkTree widget is also quite buggy.) GtkCList
515 and GtkCTree mostly solve the size problem, but are quite
516 complex and, despite that, not very flexible. They are limited to
517 displaying pixmaps and text, and can neither support arbitrary
518 widgets nor custom drawing functions.
521 In addition to list and tree widgets, a closely related need
522 is a sheet widget that displays a (possibly editable) 2-D grid.
523 It would be desirable to have a complete set of widgets that
524 could be presented as the one-true-solution for these needs.
525 Model/View techniques could be used effectively to increase
526 both the simplicity and power of the interfaces.
529 <contact>gtk-devel-list@gnome.org</contact>
532 <entry size="small" status="0%" target="2.0">
533 <title>GtkImage</title>
536 gdk-pixbuf is moving to become a GTK+ dependency, a new image-display
537 widget is thus needed.
540 <contact>hp@redhat.com</contact>
543 <entry size="small" status="0%" target="2.0">
544 <title>Attempt to fix GtkStatusbar</title>
547 GtkStatusbar is too inconvenient to use.
548 The only non-breakage-inducing fix we could
549 come up with is to permit 0 as a context ID, so you
550 don't have to use gtk_statusbar_get_context_id().
553 <contact>gtk-devel-list@gnome.org</contact>
556 <entry size="small" status="95%" target="2.0">
557 <title>Decruft GtkProgress, GtkProgressbar</title>
559 <p>UPDATE: this is done, just need to apply the patch.
563 This interface is just a disaster of overcomplexity;
564 it should pretty much just be set_percentage(),
565 pulse() (to move during activity mode), and set_text().
566 There's no reason that there are two objects, should
567 just be one interface. Almost all the functions
568 that currently exist should be deprecated.
571 <contact>hp@redhat.com</contact>
574 <entry size="small" status="0%" target="2.0">
575 <title>Entry validation hooks</title>
578 Simple hooks for validation in a GtkEntry. Pretty much just a
579 "validate" callback which takes a string (current entry contents) and
580 returns either VALID, INVALID, or COULDBEVALID. Then the
581 GtkEntry calls this function if it's set, and does the appropriate
582 UI things. GTK should come with validators for int and float,
583 see GtkSpinButton where these are already implemented.
586 <contact>gtk-devel-list@gnome.org</contact>
589 <entry size="big" status="0%" target="> 2.0">
590 <title>pseudo-MDI Widget</title>
593 Add a widget that lets you rearrange various views (similar to many
594 IDEs, like Visual SlickEdit or JBuilder). Basically there should be a
595 central slot and 4 slots around the sides; each slot holds one or more
596 views. If two views are dropped in the same slot, then a notebook is
597 created displaying both views. If a view is dropped outside the
598 application window, it becomes a standalone window. It should be
599 possible to restrict whether a view can be dropped on the sides,
600 horizontal/vertical sides only, in the central content area, or in
604 (Havoc has a proposed interface for this, mail hp@redhat.com)
607 <contact>gtk-devel-list@gnome.org</contact>
610 <entry size="medium" status="0%" target="> 2.0">
611 <title>Icon List Widget</title>
614 A simple icon list widget, suitable for creating a file selector or
618 <contact>gtk-devel-list@gnome.org</contact>
621 <entry size="medium" status="0%" target="> 2.0">
622 <title>Dock widget</title>
625 Add a widget like GnomeDock (perhaps based on GnomeDock)
626 that allows people to put rearrangeable toolbars, menubars, etc.
627 around a central content area. The widget should have hooks for
628 saving the current positions of the various docked bars.
631 <contact>gtk-devel-list@gnome.org</contact>
634 <entry size="big" status="0%" target="> 2.0">
635 <title>Canvas widget</title>
638 Figure out how to get GnomeCanvas or a derived work into GTK+ itself.
641 <contact>gtk-devel-list@gnome.org</contact>
644 <entry size="medium" status="0%" target="2.0">
645 <title>Menu scroll</title>
648 When menus are bigger than the screen, allow scrolling
652 <contact>gtk-devel-list@gnome.org</contact>
655 <entry size="medium" status="20%" target="2.0">
656 <title>Toolbar/menubar wrap</title>
659 When toolbars and menubars are too wide, do some sort of
660 wrapping or drop-down deal. (See Windows/Mac apps for examples.)
663 <contact>gtk-devel-list@gnome.org</contact>
666 <entry size="small" status="0%" target="2.0">
667 <title>Blink cursor in GtkEntry</title>
670 Make the cursor optionally blink in GtkEntry. Beware, the entry code
671 is somewhat in flux; mail Owen and ask.
674 <contact>otaylor@redhat.com</contact>
677 <entry size="small" status="100%" target="2.0">
678 <title>Don't highlight first menu item when menus come up</title>
681 Keep GtkMenu from prelighting the first menu item.
684 <contact>gtk-devel-list@gnome.org</contact>
687 <entry size="small" status="100%" target="2.0">
688 <title>Integrate new color selector</title>
691 There's a new color selector in CVS (module gnome-colorsel),
692 it needs to be folded in to GTK and any remaining issues resolved.
693 (This new selector is API-compatible with the old one, and
694 still called GtkColorSelector).
697 <contact>gtk-devel-list@gnome.org</contact>
700 <entry size="medium" status="70%" target="2.0">
701 <title>Write new font selector</title>
704 Pango introduces a new font handling system,
705 replacing the XLFD system. Need a font selector for this.
706 The XLFD selector should probably remain, for apps where
707 it makes sense (like gnome-terminal probably).
710 <contact>gtk-devel-list@gnome.org</contact>
713 <entry size="small" status="0%" target="2.0">
714 <title>Stack Widget</title>
717 Jonathan has a widget like a tabless/frameless notebook, used for
718 something like the GNOME control center where you want to toggle which
719 widget is visible to the user. Needs to be cleaned up and considered
723 <contact>gtk-devel-list@gnome.org, jrb@redhat.com</contact>
726 <entry size="small" status="0%" target="2.0">
727 <title>Clean up GtkNotebook</title>
730 GtkNotebook currently breaks GTK invariants about
731 mapping/visibility/etc., needs fixing.
734 <contact>gtk-devel-list@gnome.org</contact>
737 </section> <!-- GTK+ -->