gtk/TODO

Bugs:
 * Scrolled windows (GtkList?) get cought in an endless reallocation loop
   under certain (rare) circumstances.

 * Widget redrawing when the window resizes sometimes messes up.
   GtkLabels sometimes redraw without clearing up the underlying background on
   window resizes.
 
 * 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, or vice versa?

 * Expose events aren't being generated correctly for DND demo

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
 
 * 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?)
 
 * Make all widget attributes configurable after the widget is created (timj).
 
 * Widgets dervied from GtkButton need to be able to override
   GtkButtonClass.paint. e.g. redrawing of GtkToggleButton with CAN_DEFAULT
   is messed up otheriwse. This does in fact not only apply to (toggle)buttons,
   we should introduce a common paint member for the GtkWidgetClass.
 
 * Radio buttons need to display CAN/HAS_DEFAULT correctly.

 * GtkCList improvements. (Jay Painter)

 * Seperate GtkObject and signaling system from Gdk dependancies?
  
 * 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).

 * Entry should allow set_usize to work better, and should compute
   a different width when a maximum length is used.

 * More dialogs: Print, GtkFontSelector, maybe others...

 * Multiple document interface (MDI)?

 * 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

 * Check return values on all calls to XIC[Get/Set]Values

 * Rewrite the interface to the i18n stuff so GTK widgets don't need to
   retrieve X values, and so they don't have to know the value of the
   XNxxx character constants.

 * 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. 

 ? 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...)
    ??? 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.

 * 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);

 * 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.

 * Scrolled windows need to be smarter about when they size-request/allocate
   their children. In particular, we should not be queuing the resizes
   on the toplevel window, but on the Viewport.

 * 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.

 * Fix block_resize, disable_resize.

 * Buttons's should derive from Bin's. (GTK 2.0 change, breaks
   lots of stuff)

 * New signals to handle accelerators: accel_before and accel_after (or
   somesuch) to pre and post process accelerator calls. [Yosh]

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 (???)

  - 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.