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">
Havoc Pennington's avatar
Havoc Pennington committed
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>
Havoc Pennington's avatar
Havoc Pennington committed
606
      </description>
607
      <contact>gtk-devel-list@gnome.org</contact>
Havoc Pennington's avatar
Havoc Pennington committed
608
609
    </entry>

610
    <entry size="medium" status="0%" target="> 2.0">
Havoc Pennington's avatar
Havoc Pennington committed
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>
Havoc Pennington's avatar
Havoc Pennington committed
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>

Owen Taylor's avatar
Owen Taylor committed
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