AuroraMiddleware/gtk2
1
0
Fork 0
forked from AuroraMiddleware/gtk
Code Issues Pull Requests Projects Releases Wiki Activity
98bacfb792
gtk2/TODO.xml
Owen Taylor 8a7664a1ae Change 1.4 version numbers to 2.0. 
Wed Jun 21 19:45:02 2000  Owen Taylor  <otaylor@redhat.com>

	* TODO.xml: Change 1.4 version numbers to 2.0.
2000-06-21 23:45:41 +00:00

740 lines
26 KiB
XML
Raw Blame History

<!-- 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 &lt;otaylor@redhat.com&gt;</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 &lt;otaylor@redhat.com&gt;</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="0%" 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="85%" 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="40%" 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 &lt;timj@gtk.org&gt;</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 &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>
<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 &lt;timj@gtk.org&gt;</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 &lt;timj@gtk.org&gt;</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="0%" 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="50%" 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="40%" 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 &lt;timj@gtk.org&gt;</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 &lt;timj@gtk.org&gt;</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="0%" 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>
Reference in New Issue View Git Blame Copy Permalink