mirror of
https://gitlab.gnome.org/GNOME/gtk.git
synced 2024-11-10 10:50:10 +00:00
401 lines
15 KiB
XML
401 lines
15 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="70%" target="1.4">
|
|
<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="70%" target="1.4">
|
|
<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="1.4">
|
|
<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@redhat.com</contact>
|
|
<bugs>#3958</bugs>
|
|
</entry>
|
|
</section>
|
|
|
|
<section>
|
|
<title>Internationalization</title>
|
|
|
|
<entry size="big" status="0%" target="1.4">
|
|
<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="20%" target="1.4">
|
|
<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="0%" target="1.4">
|
|
<title>Rewrite Input Method Support</title>
|
|
<description>
|
|
<p>
|
|
Current support for Input Methods 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>
|
|
While adding the above support, it may be desirable to
|
|
generalize the input-method support to the point where
|
|
</p>
|
|
</description>
|
|
<contact>gtk-i18n-list@redhat.com</contact>
|
|
</entry>
|
|
</section>
|
|
|
|
<section>
|
|
<title>GTK+ Core</title>
|
|
|
|
<entry size="big" status="5%" target="1.4">
|
|
<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="1.4">
|
|
<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@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="0%" target="1.4">
|
|
<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="1.4">
|
|
<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="1.4">
|
|
<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="1.4">
|
|
<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="1.4">
|
|
<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@redhat.com</contact>
|
|
</entry>
|
|
|
|
</section>
|
|
|
|
<section>
|
|
<title>GTK+ Widgets</title>
|
|
|
|
<entry size="small" status="0%" target="1.4">
|
|
<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@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="50%" target="1.4">
|
|
<title>Replace GtkText Widget</title>
|
|
<description>
|
|
<p>
|
|
The GtkText widget is badly in need of replacement, since it is
|
|
buggy and insufficiently feature rich. There are a number
|
|
of possible candidates for a replacement, with the most
|
|
promising at the current time being Havoc Pennington's
|
|
(hp@redhat.com) port of the Tk Text widget.
|
|
</p>
|
|
<p>
|
|
As part of this job it will be necessary to add
|
|
<a href="http://www.pango.org">Pango</a> support to the
|
|
replacement. The structure of the Tk text widget port seems
|
|
suited to this as it works paragraph-by-paragraph, and
|
|
Pango works at a sub-paragraph scale.
|
|
</p>
|
|
</description>
|
|
<contact>gtk-devel-list@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="1.4">
|
|
<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@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="1.4">
|
|
<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@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="small" status="0%" target="1.4 ?">
|
|
<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@redhat.com</contact>
|
|
</entry>
|
|
|
|
<entry size="big" status="90%" target="1.4">
|
|
<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 1.4
|
|
proper at some point.
|
|
</p>
|
|
</description>
|
|
<contact>Tim Janik <timj@gtk.org></contact>
|
|
</entry>
|
|
|
|
<entry size="medium" status="90%" target="1.4">
|
|
<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="0%" target="> 1.4">
|
|
<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@redhat.com</contact>
|
|
</entry>
|
|
</section>
|
|
</todo>
|