-TODO BEFORE GTK 1.0
--------------------
-
+For 1.2.0 release:
+- remove deprecated functions from *.[hc] files.
+- finish composite child stuff.
+- implement constructor functionality for all widgets.
+
Bugs:
- * Scrolled windows (GtkList?) get cought in an endless reallocation loop
- under certain (rare) circumstances.
+ * Change bitfields to guints from enums, or vice versa?
+
+ * MappingNotify events produce warnings.
- * Widget redrawing when the window resizes sometimes messes up.
- GtkLabels sometimes redraw without clearing up the underlying background on
- window resizes.
+ * the type system (gtktypeutils.c) has to handle creations of fundamental
+ types seperatedly from derived types, so we don't screw foreign
+ fundamental types with an already extensively increased seqno.
- * delay dnd settings to take effect once a widget is realized, this is
- to avoid force realizations. i think this goes along with owens dnd
- changes?
- -timj
- The way DND data types are set in GtkWidget really needs to be fixed.
- This is pretty high on my priority list, and I'll get to it as soon as
- the column list widget is done. The correct way dnd data needs to be set
- is to have a additional keyed data type with GtkWidget, which is applied to
- the widget's window upon realize.
- There also needs to be a way to set dnd-data on widget windows which are
- not the main window (for widgets that create more than one window).
- -Jay Painter
- DnD seems to work for me, but yes, there needs to be some sort of
- gtk_widget layer that makes it easier... Also, adding support for drop
- zones might be nice.
- -Elliot
- This one is reproducabel for me:
- testgtk --sync
- popup colorselection
- drag/drop works
- start up preview color
- drag works but not dropping
- end preview color
- drag/drop works
- start up prewiev color
- segfault in malloc
- -timj
-
- * Change bitfields to guints from enums for C++ ?
-
- * Expose events aren't being generated correctly for DND demo
+ * A filter function which destroys the GDK window it is filtering
+ events on is bad news.
Additions:
- * GScanner: it might be good to ues stdio and getch() instead of 1-character
- reads. so one can take advantage of buffering. Currently each read() takes
- a separate syscall.
-
- * implement gtk_default_draw_oval
+ * focus handling for GtkOptionMenu (needs the previous)
+
+ * implement gtk_default_draw_oval and other missing things in gtkstyle.c.
* Lists should scroll to center the recently selected item if it isn't
visible.
* enforce invariants on *_RESIZE* and *_REDRAW* flags.
- * asure that child widgets are really get gtk_widget_destroy()ed in their
- parents destroy handler, and not just unparented or somesuch.
-
* GtkToolTips:
allocate GtkTooltipsData from memchunks
look into incorporation of outdated/gtk-dairiki-971208-[01].patch.gz
- * Make widget attributes configurable after the widget is created (timj).
-
- * Change gtk_widget_propagate_default_style() mechanism to
- void gtk_rc_string_export (const gchar *rc_additions,
- gboolean override_rc_styles);
-
- * Should release grab before activating menu item (and remove
- menu from screen?)
-
-TODO AFTER GTK 1.0
-------------------
-
* Make all widget attributes configurable after the widget is created (timj).
* Widgets dervied from GtkButton need to be able to override
* Radio buttons need to display CAN/HAS_DEFAULT correctly.
- * GtkCList improvements. (Jay Painter)
-
- * Seperate GtkObject and signaling system from Gdk dependancies?
-
+ * Seperate GtkObject, type and signaling system from Gdk dependancies,
+ by moving them into a seperate libgtkobj.
* move *_input_add (wrappers for select(2)) mechanism into glib.
- * Make sure a widget added to a list is a list item and a widget added
- to a menu is a menu item, etc. GTK_BASIC was a first attempt at this,
- but it fails with subsequent container_add()s. maybe have another
- GTK_PARENT_BASIC (similar to GTK_PARENT_SENSITIVE) flag, to prevent
- tree iterations upon every container addition.
-
* gdk_expose_compress: ala-Xt, this would really help for opaque moves and
such
* Entry should have a password mode (and it should show stars
for user feedback).
- * More dialogs: Print, GtkFontSelector, maybe others...
+ * Entry should allow set_usize to work better, and should compute
+ a different width when a maximum length is used.
- * Multiple document interface (MDI)?
+ * More dialogs: Print, GtkFontSelector, maybe others...
- * Support another widget style? Should be possible using GtkStyle's, but
- there may be some work needed to remove any style dependencies in widget
- code. Maybe GtkStyle's should have 'draw_push_button', 'draw_check_button',
- etc, functions to draw the various widgets.
- This will be covered by upcoming themability, raster is working on it.
-
* make the gtk_main callbacks consistent in their add/remove behaviour.
* More work on Documentation
retrieve X values, and so they don't have to know the value of the
XNxxx character constants.
- * The "-geometry" option should be supported
+ * 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)
( You'd have to extend gdk_window_set_hints to accept the
window gravity option to get it right. )
- * Text/Edit widget: (some of these might be bugs that should be fixed now)
+ ? Allow moving the separator for paned widgets by dragging
+ it directly instead of using the handle.
+
+ ? Mark public use of gtk_tree_remove_item as deprecated - it should be used
+ as:
+ gtk_container_remove (GTK_CONTAINER(tree), widget);
+
+ * Standardize that all strings should be passed as gchar *, not
+ guchar *. But what about non-string data? (gdk_property_change,
+ gtk_selection_data_set) X makes these sort of things guchar...
+
+ * Check into XAddConnectionWatch - is this needed for XIM?
+
+ * Places where a _full variant is needed:
+
+ gtk_clist_set_row_data
+ gtk_init_add
+ gtk_menu_popup
+ gtk_toolbar_prepend_element
+ gtk_toolbar_insert_element
+ gtk_widget_dnd_data_set (should be guchar * with a copy?
+ shouldn't be there at all...)
+
+ * 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.
+
+ * If a window spontaneously resizes itself N times before any
+ ConfigureNotify events are received, then due to the interaction
+ of the ConfigureNotify compression code in GDK and the resize
+ count used for the window, the window will be size_allocated
+ the next N-1 times it is moved.
+
+ Fix: Only send GDK_EVENT_CONFIGURE when the window is resized,
+ create a new event type for toplevel motion. (GDK_EVENT_REPOSITION?)
+ and eliminate the resize count in GtkWindow.
+
+ * Generic ScrolledWindow interface, which provide automatic scrollbar
+ capability to Viewport, Text, and CList widgets.
+
+ * GTK_POLICY_NEVER for scrolled windows.
+
+ * Consider caching more state in GdkWindowPrivate. Currently,
+ every widget realization involves a XGetGeometry and a
+ XGetWindowAttributes. And every GdkWindow destruction
+ involves a XQueryTree.
+
+ * 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.
+
+Text/Edit widget:
Bugs:
- - Who knows?
+ - Really big font (150 pt), plus lots of editing caused segfault
Improvements:
aaaaaaaaaaa bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb
as:
- | Maximum column
+ | Maximum column
aaaaaaaaaaa bbbbbbbbbbb|
bbbbbbbbbbbbbbbbbbbbbbb|
bbbbbbbbb |
Instead of:
- |
+ |
aaaaaaaaaaa |
bbbbbbbbbbbbbbbbbbbbbbb|
bbbbbbbbbbbbbbbbbbbb |
mouse click, some function to get the word/line under the mouse pointer
[ From: Stefan Jeske <jeske@braunschweig.netsurf.de> ]
- - Really big font (150 pt), plus lots of editing caused segfault
+ - "changed" emitted when doing deletes on empty Text widget.
- ? Allow moving the separator for paned widgets by dragging
- it directly instead of using the handle.
+ - Delete IC in editable->unrealize, not editable->finalize?
- ? Mark public use of gtk_tree_remove_item as deprecated - it should be used
- as:
- gtk_container_remove (GTK_CONTAINER(tree), widget);
+Themes
+======
- * Standardize that all strings should be passed as gchar *, not
- guchar *. But what about non-string data? (gdk_property_change,
- gtk_selection_data_set) X makes these sort of things guchar...
+ - When a scale gets shown/hidden only queue a redraw on the
+ non-window portion, not the whole area.
- * Check into XAddConnectionWatch - is this needed for XIM?
+ - 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.
- * Places where a _full variant is needed:
+ Such calls exist in: GtkButton, GtkHandeBox, GtkItem,
+ GtkListItem, GtkMenu, GtkMenuItem, GtkMisc,
+ GtkNoteBook, GtkOptionMenu, GtkPaned, GtkPreview,
+ GtkSpinButton and GtkTreeItem.
- gtk_clist_set_row_data
- gtk_init_add
- gtk_menu_popup
- gtk_toolbar_prepend_element
- gtk_toolbar_insert_element
- gtk_widget_dnd_data_set (should be guchar * with a copy?
- shouldn't be there at all...)
- ??? GtkDrawingarea.draw_data
-
- * gtk_rc_add_[name/class]_style are broken for bg pixmaps, because
- styles are broken for bg pixmaps, and RC styles only hack around
- that.
+ - 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.
- * 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.
+=======
- * --g-fatal-warnings flag that does
- g_set_warning_handler ((GWarningHandler)g_error);
+Calendar Widget:
- * If a window spontaneously resizes itself N times before any
- ConfigureNotify events are received, then due to the interaction
- of the ConfigureNotify compression code in GDK and the resize
- count used for the window, the window will be size_allocated
- the next N-1 times it is moved.
+ - 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 it's 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)
- Fix: Only send GDK_EVENT_CONFIGURE when the window is resized,
- create a new event type for toplevel motion. (GDK_EVENT_REPOSITION?)
- and eliminate the resize count in GtkWindow.
projects / ~andy / gtk / blobdiff