TODO.xml 26.2 KB
Newer Older
1 2 3 4 5 6
<!-- 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:

Tim Janik's avatar
Tim Janik committed
7
     $ docs/make-todo TODO.xml > /dev/null
8 9

     before committing, or you may screw up the online version --> 
10 11
<todo logourl="gtk-logo-rgb.gif">
  <title>GTK+ TODO list</title>
12 13
  <section>
    <title>GDK</title>
14
    
15
    <entry size="medium" status="90%" target="2.0">
16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41
      <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>

42
    <entry size="medium" status="90%" target="2.0">
43 44 45 46 47 48 49 50 51
      <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>
Owen Taylor's avatar
Owen Taylor committed
52 53
	<p>
	  There are some difficulties with performance in this
Owen Taylor's avatar
Owen Taylor committed
54 55 56
	  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.  
Owen Taylor's avatar
Owen Taylor committed
57
	</p>
58 59 60 61 62
      </description>
      <url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
      <contact>Owen Taylor &lt;otaylor@redhat.com&gt;</contact>
    </entry>

63
    <entry size="small" status="0%" target="2.0">
64 65 66 67 68 69 70 71
      <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>
72
      <contact>gtk-devel-list@gnome.org</contact>
73 74
      <bugs>#3958</bugs>
    </entry>
Havoc Pennington's avatar
Havoc Pennington committed
75

76
    <entry size="small" status="0%" target="2.0">
77 78 79 80 81 82 83 84 85 86 87 88 89
      <title>Make color handling more convenient</title>
      <description>
	<p>
          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 (gdk_blue, gdk_red, etc.), the problem
          being colormap issues.
	</p>
      </description>
      <contact>gtk-devel-list@gnome.org</contact>
    </entry>
Havoc Pennington's avatar
Havoc Pennington committed
90

91
    <entry size="small" status="0%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
92 93 94 95 96 97 98 99 100 101 102 103 104
      <title>Cursors</title>
      <description>
	<p>
          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.
	</p>
      </description>
105
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
106 107
    </entry>

Owen Taylor's avatar
Owen Taylor committed
108
    <entry size="medium" status="100%" target="2.0">
109 110 111 112 113 114 115 116 117
      <title>Make GdkRGB work on any visual</title>
      <description>
	<p>
          GdkRGB should be able to render to an arbitrary visual
          (i.e. the visual shouldn't be fixed at gdk_rgb_init() 
          time). This will break gdk_rgb_gc_set_foreground() and 
          friends, though.
	</p>
      </description>
118
      <contact>gtk-devel-list@gnome.org</contact>
119
    </entry>
Havoc Pennington's avatar
Havoc Pennington committed
120 121

  </section> <!-- GDK -->
122 123 124 125

  <section>
    <title>Internationalization</title>
    
Owen Taylor's avatar
Owen Taylor committed
126
    <entry size="big" status="90%" target="2.0">
127 128 129 130
      <title>Integrate Pango</title>
      <description>
	<p>
	  The purpose of the Pango project is to provide a system for
Owen Taylor's avatar
Owen Taylor committed
131
	  layout and rendering of internationalized text. It handles
132 133 134 135 136 137 138
	  most of the issues necessary to 
	</p>
      </description>
      <url>http://www.pango.org</url>
      <contact>gtk-i18n-list@redhat.com</contact>
    </entry>

139
    <entry size="medium" status="90%" target="2.0">
140 141 142 143 144 145 146
      <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
Owen Taylor's avatar
Owen Taylor committed
147
	  a large degree of compatibility with existing programs.
148 149 150 151 152 153 154 155 156 157 158 159 160
	</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>

Owen Taylor's avatar
Owen Taylor committed
161
    <entry size="big" status="60%" target="2.0">
162 163 164
      <title>Rewrite Input Method Support</title>
      <description>
	<p>
165
	  Support for Input Methods is GTK+-1.2 is done via XIM, with
166 167 168 169 170 171 172 173 174
	  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>
175
	  GTK+-2.0 will have a new system with loadable input method
176 177
	  modules. These modules can either be implemented using XIM,
	  or written from scratch.
178 179 180 181
	</p>
      </description>
      <contact>gtk-i18n-list@redhat.com</contact>
    </entry>
Havoc Pennington's avatar
Havoc Pennington committed
182
  </section> <!-- i18n -->
183 184 185 186

  <section>
    <title>GTK+ Core</title>

187
    <entry size="big" status="60%" target="2.0">
188
      <title>GLib based object and type system</title>
189 190 191 192
      <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
193 194 195 196 197 198 199
	  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>

200
    <entry size="big" status="1%" target="2.0">
201 202 203 204 205 206 207 208 209 210 211 212
      <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>
213
      <contact>gtk-devel-list@gnome.org</contact>
214 215
    </entry>

216
    <entry size="big" status="0%" target="2.0">
217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235
      <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>

236
    <entry size="big" status="5%" target="2.0">
237 238 239 240 241 242 243 244 245 246 247 248 249 250
      <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.
251 252 253 254 255
	</p>
      </description>
      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
    </entry>

256
    <entry size="big" status="0%" target="2.0">
257 258 259 260 261 262 263 264 265 266 267 268 269 270 271
      <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>

272
    <entry size="medium" status="0%" target="2.0">
273 274 275 276 277 278 279 280 281 282 283 284 285 286 287
      <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>
288

289
    <entry size="small" status="0%" target="2.0">
290 291 292 293 294 295 296 297 298 299
      <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>
300
      <contact>gtk-devel-list@gnome.org</contact>
301 302
    </entry>

303

Owen Taylor's avatar
Owen Taylor committed
304
    <entry size="small" status="20%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
305 306 307 308 309 310 311 312 313 314 315 316 317 318 319
      <title>Convenient widget setup</title>
      <description>
	<p>
          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.
	</p>
        <p>
          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.
        </p>
320

Havoc Pennington's avatar
Havoc Pennington committed
321
      </description>
322
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
323 324
    </entry>

325
    <entry size="medium" status="0%" target="> 2.0">
Havoc Pennington's avatar
Havoc Pennington committed
326 327 328 329 330 331 332
      <title>Make selections/clipboard more convenient</title>
      <description>
	<p>
          Make GtkSelectionData more like the MIME blobs in Swing and Qt.
          Consider a GtkClipboard object to simplify cut-and-paste handling.
	</p>
      </description>
333
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
334 335 336
    </entry>


Owen Taylor's avatar
Owen Taylor committed
337
    <entry size="small" status="80%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
338 339 340 341 342 343 344 345 346 347 348 349
      <title>Stock label/icon system</title>
      <description>
	<p>
          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.
	</p>
      </description>
      <contact>hp@redhat.com</contact>
    </entry>


350
    <entry size="big" status="0%" target="> 2.0">
Havoc Pennington's avatar
Havoc Pennington committed
351 352 353 354 355 356 357 358
      <title>Session Management</title>
      <description>
	<p>
          Look in to session management. Consider whether to use 
          X11R6 SM, or some custom spec shared with KDE. Create
          GTK+ API for this.
	</p>
      </description>
359
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
360 361
    </entry>

362
    <entry size="big" status="0%" target="> 2.0">
Havoc Pennington's avatar
Havoc Pennington committed
363 364 365 366 367
      <title>Online help enhancements</title>
      <description>
	<p>
          Look at a small "What's This" popup widget, 
          and a What's This system in general (this part 
368 369
          could maybe be done for 2.0). A more difficult, probably 
          a post-2.0 task, is to integrate a very simple little
Havoc Pennington's avatar
Havoc Pennington committed
370 371 372
          help browser gizmo into GTK.
	</p>
      </description>
373
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
374 375 376
    </entry>


377
    <entry size="medium" status="0%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
378 379 380 381 382 383 384
      <title>GUI-editable means of user configuration</title>
      <description>
	<p>
          Need to be able to set double click time, whether cursors
          blink, etc., from a control panel type of deal.
	</p>
      </description>
385
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
386 387
    </entry>

Havoc Pennington's avatar
Havoc Pennington committed
388
  </section> <!-- Core -->
389 390 391 392

  <section>
    <title>GTK+ Widgets</title>

393
    <entry size="small" status="100%" target="2.0">
394 395 396 397 398 399 400 401 402 403 404
      <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>
405
      <contact>gtk-devel-list@gnome.org</contact>
406 407
    </entry>

408
    <entry size="big" status="90%" target="2.0">
409 410 411
      <title>Replace GtkText Widget</title>
      <description>
	<p>
412 413 414
	  The GtkText widget is badly in need of replacement, since it
	  is buggy and insufficiently feature rich. This is being done
	  using Havoc Pennington's port of the Tk Text widget.
415 416
	</p>
	<p>
417 418 419 420 421 422 423
	  As part of this job <a href="http://www.pango.org">Pango</a>
	  support is being added to the replacement. The structure of
	  the Tk text widget port is suited to this as it works
	  paragraph-by-paragraph, and Pango works at a sub-paragraph
	  scale. The main remaining tasks here are to implement
	  incremental reflow to make performance acceptable and to
	  implement embedded pixmaps and widgets.
424 425
	</p>
      </description>
426
      <contact>gtk-devel-list@gnome.org</contact>
427
    </entry>
428

429
    <entry size="small" status="20%" target="2.0">
430 431 432 433 434 435 436 437 438 439 440
      <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>
441
      <contact>gtk-devel-list@gnome.org</contact>
442 443
    </entry>

444
    <entry size="small" status="99%" target="2.0">
445 446 447 448 449 450 451 452 453 454 455 456
      <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>
457
      <contact>gtk-devel-list@gnome.org</contact>
458 459
    </entry>

460
    <entry size="small" status="0%" target="2.0 ?">
461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477
      <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>
478
      <contact>gtk-devel-list@gnome.org</contact>
479
    </entry>
480

481
    <entry size="big" status="90%" target="2.0">
482 483 484 485 486
      <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:
487
	  horizontable/vertical wrap boxes, that need to go into 2.0
488 489 490 491 492 493
	  proper at some point.
	</p>
      </description>
      <contact>Tim Janik &lt;timj@gtk.org&gt;</contact>
    </entry>

494
    <entry size="medium" status="90%" target="2.0">
495 496 497 498 499 500 501 502 503 504 505 506
      <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>

507
    <entry size="big" status="40%" target="2.0?">
508 509 510 511
      <title>Add unified set of List/Tree/Grid widgets</title>
      <description>
	<p>
	  Currently, GTK+ has a large number of list and tree widgets
Owen Taylor's avatar
Owen Taylor committed
512
	  (GtkList, GtkTree, GtkCList, GtkCTree), none of which are
513
	  ideal. The GtkList and GtkTree widgets perform badly on large
Owen Taylor's avatar
Owen Taylor committed
514
	  number of items. (GtkTree widget is also quite buggy.) GtkCList
515 516
	  and GtkCTree mostly solve the size problem, but are quite
	  complex and, despite that, not very flexible. They are limited to
Owen Taylor's avatar
Owen Taylor committed
517
	  displaying pixmaps and text, and can neither support arbitrary
518 519 520 521 522 523 524 525 526 527 528
	  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>
529
      <contact>gtk-devel-list@gnome.org</contact>
530
    </entry>
531

532 533
    <entry size="small" status="0%" target="2.0">
      <title>GtkImage</title>
534 535 536 537 538 539 540 541 542
      <description>
	<p>
          gdk-pixbuf is moving to become a GTK+ dependency, a new image-display
          widget is thus needed.
	</p>
      </description>
      <contact>hp@redhat.com</contact>
    </entry>

543
    <entry size="small" status="0%" target="2.0">
544 545 546 547 548 549 550 551 552
      <title>Attempt to fix GtkStatusbar</title>
      <description>
	<p>
          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().
	</p>
      </description>
553
      <contact>gtk-devel-list@gnome.org</contact>
554 555
    </entry>
    
556
    <entry size="small" status="95%" target="2.0">
557 558
      <title>Decruft GtkProgress, GtkProgressbar</title>
      <description>
559 560 561
        <p>UPDATE: this is done, just need to apply the patch.
        </p>
        
562 563 564 565 566 567 568 569 570
	<p>
          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.
	</p>
      </description>
571
      <contact>hp@redhat.com</contact>
572 573
    </entry>

574
    <entry size="small" status="0%" target="2.0">
575 576 577 578 579 580 581 582 583 584 585
      <title>Entry validation hooks</title>
      <description>
	<p>
          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.
	</p>
      </description>
586
      <contact>gtk-devel-list@gnome.org</contact>
587 588
    </entry>

589
    <entry size="big" status="0%" target="> 2.0">
590 591 592 593 594 595 596 597 598 599 600 601 602
      <title>pseudo-MDI Widget</title>
      <description>
	<p>
          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.
	</p>
603 604 605
        <p>
          (Havoc has a proposed interface for this, mail hp@redhat.com)
        </p>
606
      </description>
607
      <contact>gtk-devel-list@gnome.org</contact>
608 609
    </entry>

610
    <entry size="medium" status="0%" target="> 2.0">
611 612 613 614 615 616 617
      <title>Icon List Widget</title>
      <description>
	<p>
          A simple icon list widget, suitable for creating a file selector or
          the like.
	</p>
      </description>
618
      <contact>gtk-devel-list@gnome.org</contact>
619
    </entry>
620

621
    <entry size="medium" status="0%" target="> 2.0">
622 623 624 625 626 627 628 629 630
      <title>Dock widget</title>
      <description>
	<p>
          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.
	</p>
      </description>
631
      <contact>gtk-devel-list@gnome.org</contact>
632 633
    </entry>

634
    <entry size="big" status="0%" target="> 2.0">
635 636 637 638 639 640
      <title>Canvas widget</title>
      <description>
	<p>
          Figure out how to get GnomeCanvas or a derived work into GTK+ itself.
	</p>
      </description>
641
      <contact>gtk-devel-list@gnome.org</contact>
642 643
    </entry>

644
    <entry size="medium" status="57%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
645 646 647 648 649 650 651
      <title>Menu scroll</title>
      <description>
	<p>
          When menus are bigger than the screen, allow scrolling
          as on the Mac.
	</p>
      </description>
652
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
653 654
    </entry>

655
    <entry size="medium" status="20%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
656 657 658 659 660 661 662
      <title>Toolbar/menubar wrap</title>
      <description>
	<p>
          When toolbars and menubars are too wide, do some sort of 
          wrapping or drop-down deal. (See Windows/Mac apps for examples.)
	</p>
      </description>
663
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
664 665
    </entry>

666
    <entry size="small" status="0%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
667 668 669 670 671 672 673 674 675 676
      <title>Blink cursor in GtkEntry</title>
      <description>
	<p>
          Make the cursor optionally blink in GtkEntry. Beware, the entry code
          is somewhat in flux; mail Owen and ask.
	</p>
      </description>
      <contact>otaylor@redhat.com</contact>
    </entry>

677
    <entry size="small" status="100%" target="2.0">
Havoc Pennington's avatar
Havoc Pennington committed
678 679 680 681 682 683
      <title>Don't highlight first menu item when menus come up</title>
      <description>
	<p>
          Keep GtkMenu from prelighting the first menu item.
	</p>
      </description>
684
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
685 686
    </entry>

687
    <entry size="small" status="100%" target="2.0">
688 689 690 691 692 693 694 695 696
      <title>Integrate new color selector</title>
      <description>
	<p>
          There's a new color selector in CVS (module gnome-colorsel),
          it needs to be folded in to GTK and any remaining issues resolved.
          (This new selector is API-compatible with the old one, and 
          still called GtkColorSelector).
	</p>
      </description>
697
      <contact>gtk-devel-list@gnome.org</contact>
698 699
    </entry>

700
    <entry size="medium" status="70%" target="2.0">
701 702 703 704 705 706 707 708 709
      <title>Write new font selector</title>
      <description>
	<p>
          Pango introduces a new font handling system,
          replacing the XLFD system. Need a font selector for this.
          The XLFD selector should probably remain, for apps where
          it makes sense (like gnome-terminal probably).
	</p>
      </description>
710 711 712
      <contact>gtk-devel-list@gnome.org</contact>
    </entry>

713
    <entry size="small" status="0%" target="2.0">
714 715 716 717 718 719 720 721 722 723 724 725
      <title>Stack Widget</title>
      <description>
	<p>
          Jonathan has a widget like a tabless/frameless notebook, used for
          something like the GNOME control center where you want to toggle which
          widget is visible to the user. Needs to be cleaned up and considered
          for GTK.
	</p>
      </description>
      <contact>gtk-devel-list@gnome.org, jrb@redhat.com</contact>
    </entry>

726
    <entry size="small" status="0%" target="2.0">
727 728 729 730 731 732 733 734
      <title>Clean up GtkNotebook</title>
      <description>
	<p>
          GtkNotebook currently breaks GTK invariants about
          mapping/visibility/etc., needs fixing.
	</p>
      </description>
      <contact>gtk-devel-list@gnome.org</contact>
735 736
    </entry>

737
  </section> <!-- GTK+ -->
738
</todo>
739