forked from AuroraMiddleware/gtk
9205edae41
Sat Feb 28 23:58:54 1998 Owen Taylor <owt1@cornell.edu> * gtk/gtkentry.[ch] gtktext.c gtkeditable.[ch] Created a new base widget type Editable for the entry and text widgets, which encapsulates most of the selection and clipboard handling stuff, plus some common signals. Changed the Entry widget extensively to support this, but the interface and appearance should be the same. Changed the Text widget moderately to support this. It now supports: - Selection style cut and paste - Clipboard style cut and paste - Emacs style key bindings (~same as Entry) - Word motion - "changed" signal There are definitely still some bugs in the new stuff. * gtkfilesel.c gtkspinbutton.c testgtk.c: small changes to fit the new interface more exactly.
145 lines
5.4 KiB
Plaintext
145 lines
5.4 KiB
Plaintext
TODO BEFORE GTK 1.0
|
|
-------------------
|
|
|
|
Bugs:
|
|
* Vertical scrollbar: the expose event looks hosed and is causing
|
|
quite a bit of flickering
|
|
Actually this affects both scrollbar implementation, you can best
|
|
tell if you run the application with --sync (timj)
|
|
|
|
* signal parameters don't seem to get refreshed on recursive invokations
|
|
of GTK_NO_RECURSE signals, which causes the restarted emissions to loose
|
|
their actual point, i.e. parameter changes on the restarted emission,
|
|
needs further investigation.
|
|
|
|
* the GtkText widget needs to be fixed, that means no segfaults, full editing
|
|
facilities, omit the background pixmap for now.
|
|
|
|
* Widget redrawing when the window resizes sometimes messes up.
|
|
GtkLabels sometimes redraw without clearing up the underlying background on
|
|
window resizes.
|
|
|
|
* Are there still some GtkCList changes outstanding? (Jay Painter)
|
|
GtkCList is derived from GtkContainer but doesn't implement the
|
|
need_resize, focus, add and remove methods from containers.
|
|
it should at least issue a warning upon invokation of not supported
|
|
member functions.
|
|
|
|
* GtkTree and GtkList should express in their *_add implementations,
|
|
that they expect GtkListItems/GtkTreeItems as children. Similar
|
|
things might apply to other containers.
|
|
|
|
* 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++ ?
|
|
|
|
Additions:
|
|
* 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 old/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);
|
|
|
|
|
|
TODO AFTER GTK 1.0
|
|
------------------
|
|
|
|
* Make all widget attributes configurable after the widget is created (timj).
|
|
|
|
* 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...
|
|
|
|
* 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.
|
|
|
|
* 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. )
|
|
|