mirror of
https://gitlab.gnome.org/GNOME/gtk.git
synced 2024-12-25 05:01:09 +00:00
740 lines
26 KiB
XML
740 lines
26 KiB
XML
<!-- 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:
|
|
|
|
$ docs/make-todo TODO.xml > /dev/null
|
|
|
|
before committing, or you may screw up the online version -->
|
|
<todo logourl="gtk-logo-rgb.gif">
|
|
<title>GTK+ TODO list</title>
|
|
<section>
|
|
<title>GDK</title>
|
|
|
|
<entry size="medium" status="90%" target="2.0">
|
|
<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 <otaylor@redhat.com></contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="90%" target="2.0">
|
|
<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>
|
|
<p>
|
|
There are some difficulties with performance in this
|
|
approach - mostly because scrolling can involve mapping and
|
|
unmapping lots of widgets, but in general, current
|
|
trials in this area seem to work pretty well.
|
|
</p>
|
|
</description>
|
|
<url>http://www.gtk.org/~otaylor/gtk/1.4/gdk-drawing.html</url>
|
|
<contact>Owen Taylor <otaylor@redhat.com></contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
<bugs>#3958</bugs>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="100%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
</section> <!-- GDK -->
|
|
|
|
<section>
|
|
<title>Internationalization</title>
|
|
|
|
<entry size="big" status="90%" target="2.0">
|
|
<title>Integrate Pango</title>
|
|
<description>
|
|
<p>
|
|
The purpose of the Pango project is to provide a system for
|
|
layout and rendering of internationalized text. It handles
|
|
most of the issues necessary to
|
|
</p>
|
|
</description>
|
|
<url>http://www.pango.org</url>
|
|
<contact>gtk-i18n-list@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="90%" target="2.0">
|
|
<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
|
|
a large degree of compatibility with existing programs.
|
|
</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>
|
|
|
|
<entry size="big" status="60%" target="2.0">
|
|
<title>Rewrite Input Method Support</title>
|
|
<description>
|
|
<p>
|
|
Support for Input Methods is GTK+-1.2 is done via XIM, with
|
|
supported styles being over-the-spot and the root-window
|
|
styles. However, the over-the-spot style is not going to
|
|
work well with the Pango integration, since it relies on the
|
|
text rendering in the program being done in the standard
|
|
Xlib style, so it will be necessary to also support
|
|
on-the-spot input. On-the-spot input is done by supplying a
|
|
set of callbacks that are invoked by the input methods.
|
|
</p>
|
|
<p>
|
|
GTK+-2.0 will have a new system with loadable input method
|
|
modules. These modules can either be implemented using XIM,
|
|
or written from scratch.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-i18n-list@redhat.com</contact>
|
|
</entry>
|
|
</section> <!-- i18n -->
|
|
|
|
<section>
|
|
<title>GTK+ Core</title>
|
|
|
|
<entry size="big" status="60%" target="2.0">
|
|
<title>GLib based object and type system</title>
|
|
<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
|
|
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 <timj@gtk.org></contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="1%" target="2.0">
|
|
<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 <kenelson@ece.ucdavis.edu>, but this also
|
|
requires a GLib based type and parameter system (ties in with
|
|
"GLib based object and type system").
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="0%" target="2.0">
|
|
<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 <timj@gtk.org></contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="5%" target="2.0">
|
|
<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.
|
|
</p>
|
|
</description>
|
|
<contact>Tim Janik <timj@gtk.org></contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="0%" target="2.0">
|
|
<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>
|
|
|
|
<entry size="medium" status="0%" target="2.0">
|
|
<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>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
|
|
<entry size="small" status="20%" target="2.0">
|
|
<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>
|
|
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="0%" target="> 2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
|
|
<entry size="small" status="80%" target="2.0">
|
|
<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>
|
|
|
|
|
|
<entry size="big" status="0%" target="> 2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="0%" target="> 2.0">
|
|
<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
|
|
could maybe be done for 2.0). A more difficult, probably
|
|
a post-2.0 task, is to integrate a very simple little
|
|
help browser gizmo into GTK.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
|
|
<entry size="medium" status="0%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
</section> <!-- Core -->
|
|
|
|
<section>
|
|
<title>GTK+ Widgets</title>
|
|
|
|
<entry size="small" status="100%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="90%" target="2.0">
|
|
<title>Replace GtkText Widget</title>
|
|
<description>
|
|
<p>
|
|
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.
|
|
</p>
|
|
<p>
|
|
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.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="20%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="99%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="2.0 ?">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="90%" target="2.0">
|
|
<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:
|
|
horizontable/vertical wrap boxes, that need to go into 2.0
|
|
proper at some point.
|
|
</p>
|
|
</description>
|
|
<contact>Tim Janik <timj@gtk.org></contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="90%" target="2.0">
|
|
<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 <timj@gtk.org></contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="40%" target="2.0?">
|
|
<title>Add unified set of List/Tree/Grid widgets</title>
|
|
<description>
|
|
<p>
|
|
Currently, GTK+ has a large number of list and tree widgets
|
|
(GtkList, GtkTree, GtkCList, GtkCTree), none of which are
|
|
ideal. The GtkList and GtkTree widgets perform badly on large
|
|
number of items. (GtkTree widget is also quite buggy.) GtkCList
|
|
and GtkCTree mostly solve the size problem, but are quite
|
|
complex and, despite that, not very flexible. They are limited to
|
|
displaying pixmaps and text, and can neither support arbitrary
|
|
widgets nor custom drawing functions.
|
|
</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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<title>GtkImage</title>
|
|
<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>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="95%" target="2.0">
|
|
<title>Decruft GtkProgress, GtkProgressbar</title>
|
|
<description>
|
|
<p>UPDATE: this is done, just need to apply the patch.
|
|
</p>
|
|
|
|
<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>
|
|
<contact>hp@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="0%" target="> 2.0">
|
|
<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>
|
|
<p>
|
|
(Havoc has a proposed interface for this, mail hp@redhat.com)
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="0%" target="> 2.0">
|
|
<title>Icon List Widget</title>
|
|
<description>
|
|
<p>
|
|
A simple icon list widget, suitable for creating a file selector or
|
|
the like.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="0%" target="> 2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="0%" target="> 2.0">
|
|
<title>Canvas widget</title>
|
|
<description>
|
|
<p>
|
|
Figure out how to get GnomeCanvas or a derived work into GTK+ itself.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="57%" target="2.0">
|
|
<title>Menu scroll</title>
|
|
<description>
|
|
<p>
|
|
When menus are bigger than the screen, allow scrolling
|
|
as on the Mac.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="20%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
|
|
<entry size="small" status="100%" target="2.0">
|
|
<title>Don't highlight first menu item when menus come up</title>
|
|
<description>
|
|
<p>
|
|
Keep GtkMenu from prelighting the first menu item.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="100%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="70%" target="2.0">
|
|
<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>
|
|
<contact>gtk-devel-list@gnome.org</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
|
|
<entry size="small" status="0%" target="2.0">
|
|
<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>
|
|
</entry>
|
|
|
|
</section> <!-- GTK+ -->
|
|
</todo>
|
|
|