Commit 76145121 authored by Matthias Clasen's avatar Matthias Clasen
Browse files

Remove some files whose content is either obsolete or has been moved

	* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
	docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
	gdk/TODO: Remove some files whose content is either obsolete or
	has been moved elsewhere.

	* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
	to these files.
parent ae89375b
2002-04-20 Matthias Clasen <maclas@gmx.de>
* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
gdk/TODO: Remove some files whose content is either obsolete or
has been moved elsewhere.
* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
to these files.
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
......
2002-04-20 Matthias Clasen <maclas@gmx.de>
* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
gdk/TODO: Remove some files whose content is either obsolete or
has been moved elsewhere.
* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
to these files.
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
......
2002-04-20 Matthias Clasen <maclas@gmx.de>
* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
gdk/TODO: Remove some files whose content is either obsolete or
has been moved elsewhere.
* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
to these files.
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
......
2002-04-20 Matthias Clasen <maclas@gmx.de>
* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
gdk/TODO: Remove some files whose content is either obsolete or
has been moved elsewhere.
* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
to these files.
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
......
2002-04-20 Matthias Clasen <maclas@gmx.de>
* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
gdk/TODO: Remove some files whose content is either obsolete or
has been moved elsewhere.
* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
to these files.
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
......
2002-04-20 Matthias Clasen <maclas@gmx.de>
* TODO, TODO.xml, README.nanox, docs/Changes-1.2.txt,
docs/Changes-2.0.txt, docs/gtk-config.txt, docs/debugging.txt,
gdk/TODO: Remove some files whose content is either obsolete or
has been moved elsewhere.
* Makefile.am, gtk+.spec.in, docs/Makefile.am: Remove references
to these files.
Fri Apr 19 21:31:04 2002 Kristian Rietveld <kris@gtk.org>
* gtk/gtktreeview.c (gtk_tree_view_row_changed): cancel editing
......
......@@ -15,7 +15,6 @@ EXTRA_DIST = \
ChangeLog.pre-1-2 \
README.cvs-commits \
README.win32 \
README.nanox \
config.h.win32 \
gtk-zip.sh \
sanitize-la.sh \
......
Gtk port to nano-X
STATUS
Once upon a time I got a few apps working, then started merging
the new features added by Owen (32 bit sizes for windows and buffering).
Since then I haven't found the time to work on it:-/
TODO
Finish internal window manager abstraction or add proper support in nano-X.
Fix event polling.
Implement GdkImage, GdkRgb stuff.
Put generic region code in generic gdk and/or use the region code from nano-X.
Fix ugly automake stuff for make dist.
TODO in nano-X
We need to be able to clip and change the background of windows at runtime
for apps to not look so ugly!
Fonts: wait for better nano-X font implementation.
Properties on windows.
Provide a pango module.
If you want to work on this port or get additional informnation, get in
touch with me.
Configure gtk with the --with-gdktarget=nanox to compile with nano-X support.
Paolo Molaro
lupus@linuxcare.com
Outstanding items:
* focus handling for GtkOptionMenu (needs the previous)
* implement gtk_default_draw_oval and other missing things in gtkstyle.c.
* enforce invariants on *_RESIZE* and *_REDRAW* flags.
* GtkToolTips: allocate GtkTooltipsData from memchunks
* Make all widget attributes configurable after the widget is created (timj).
* Radio buttons need to display CAN/HAS_DEFAULT correctly, if draw_inidicator
is TRUE. (Radio buttons do not need to CAN_DEFAULT! OWT)
* More dialogs: Print, maybe others...
* make the gtk_main callbacks consistent in their add/remove behaviour.
* Check return values on all calls to XIC[Get/Set]Values
* The "--geometry" option should be supported
- Having gdk_init() parse the geometry option. (putting it into
GDK means you can use XParseGeometry() without wrapping it)
- Add a call gdk_get_geometry() that retrieves the results
in a form like that returned by XParseGeometry()
- The application then can modify the results (as would gemvt)
then call a routine gtk_window_set_geometry() on whatever
it considers to be its main window.
- Then in some manner GtkWindow takes that into account when
setting its hints. (Probably it uses the size and position
as the current uposition and usize, and modulates that
be the equivalents of the X flags
XValue, YValue, WidthValue, HeightValue, XNegative, or YNegative
( You'd have to extend gdk_window_set_hints to accept the
window gravity option to get it right. )
* Allow moving the separator for paned widgets by dragging
it directly instead of using the handle.
* Check into XAddConnectionWatch - is this needed for XIM?
* Places where a _full variant is needed:
gtk_init_add
gtk_menu_popup
gtk_toolbar_prepend_element
gtk_toolbar_insert_element
* Try to rationally deal with someone else deleting one of our
windows??? This would mean keeping track of our window heirarchy
ourselves, for one thing, and will never be safe, because of
race conditions.
* Should all the default handlers really return FALSE? This can
cause confusing presses to be sent to containers that actually
want to get events on themselves.
* The menu code should skip separators during keyboard navigation,
whether they are sensitive or insensitive.
* OwnerButtonPressGrab needs to go!
Text/Edit widget:
Bugs:
- Really big font (150 pt), plus lots of editing caused segfault
Improvements:
- Unify the key binding support in some fashion between the
Entry and Text widget widgets, use GtkBindings for this.
- Figure out a way not to recompute the geometry on insertions/deletions
which are large, but not a significant fraction of the
entire text. (e.g., compute the changes as when the widget
is not frozen, but without the actual scrolling)
- Prune the line start cache. But since it is only 68 bytes
per line, and it is a lot faster when lines are in the cache,
it may be better not to, at least for now.
- Show the non-editable state by changing colors. (Use the
style entries for insensitive?)
- Multibyte support for the Text widget.
- Unicode support to do the multi-byte right.
- Support an .inputrc. (The readline one doesn't really work,
unless it is extended because it can't represent X keysyms,
just terminal type input)
- A vi mode
- Word wrap, instead of line folding. (Should the continuation
characters be shown?)
- Horizontal scrolling
- Disable pasting compound text
- When showing background pixmap (not editable) actually set
the background pixmap as the windows bg pixmap, to improve
appearance on exposes. But this would require using another
window to get the origins.
- In word wrap mode, break:
aaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
as:
| Maximum column
aaaaaaaaaaa bbbbbbbbbbb|
bbbbbbbbbbbbbbbbbbbbbbb|
bbbbbbbbb |
Instead of:
|
aaaaaaaaaaa |
bbbbbbbbbbbbbbbbbbbbbbb|
bbbbbbbbbbbbbbbbbbbb |
- Blinking cursor
- API's : gtk_text_clear, gtk_text_delete_lines (gint start, gint end),
gtk_text_append/prepend, gtk_text_insert_at (gint row, gint column),
some function to get the row/column from the x/y-coordinates of a
mouse click, some function to get the word/line under the mouse pointer
[ From: Stefan Jeske <jeske@braunschweig.netsurf.de> ]
- "changed" emitted when doing deletes on empty Text widget.
- Delete IC in editable->unrealize, not editable->finalize?
Themes
======
- When a scale gets shown/hidden only queue a redraw on the
non-window portion, not the whole area.
- In various places, to avoid shaping windows excessively,
we set parent relative backgrounds. This is an ugly
hack and needs a better solution. Plus, I don't think
these parent-relative backgrounds always persist to
when they are actually needed.
Such calls exist in: GtkButton, GtkHandeBox, GtkItem,
GtkListItem, GtkMenu, GtkMenuItem, GtkMisc,
GtkNoteBook, GtkOptionMenu, GtkPaned, GtkPreview,
GtkSpinButton and GtkTreeItem.
- For menus and for GtkWindow's, the realize() function
calls paint(), so that background pixmaps can be set
ahead of time, and prevent flashing when the window is
shown. This is an ugly hack and needs a better solution.
=======
Calendar Widget:
- The widget should be nicely resizeable vertical too.
- CALENDAR_MARGIN should be removed, uses INNER_BORDER and
style->class->[xy]thickness insted.
- Flag to choose between using standard three letter abbreviated
weekday name or just the first character from it. It looks like
that is what most other calendar-widgets do.
- Arrows should resize with the header-font.
- The keyboard support has to be finished.
DND
===
- Use a cursor instead of an ICON when over Motif windows,
to get rid of the current junk that Motif leaves because
of its XCopyArea stupidity for doing highlighting.
- Add a GTK_DRAG_VERIFY target flag and a "drag_data_verify"
signal so that apps can easily check if a, say,
text/uri-list URL looks OK during the drop.
- Check more for memory leaks.
- Drag and drop for Entry and Text widgets.
- Send synthetic motion events on structure changes so
drag_enter/leave get sent properly. (See the popup
in testdnd)
<!-- 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="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 &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="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.