* 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:
* 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
* 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!
- Really big font (150 pt), plus lots of editing caused segfault
- 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:
| Maximum column
- 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 <firstname.lastname@example.org> ]
- "changed" emitted when doing deletes on empty Text widget.
- Delete IC in editable->unrealize, not editable->finalize?
- 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.
- The widget should be nicely resizeable vertical too.
- CALENDAR_MARGIN should be removed, uses INNER_BORDER and
- 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.
- 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