1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
|
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. )
* Text/Edit widget: (some of these might be bugs that should be fixed now)
Bugs:
- In Entry and Text widget, you can ungrab while still
dragging by pressing button-1, pressing button 3, releaseing 3,
then releasing 1.
- When selecting on a Text or Entry widget, the selection isn't
claimed until you release the button, and that shows by the
color of the selection. (Which is the real problem - it probably
is OK/better to delay claiming the selection)
- Related to the above, when you Shift/arrow to select text, the
selected text doesn't show that you have the selection immediately.
- Selecting an entire line with triple-click doesn't work write -
it should select the wrapped portion too.
- Selecting an entire line should probably select the newline as
well, so when the selection is cut/deleted, the newline goes
along.
- Do something about the bg pixmap situation. (It will produce
garbage when editing is enabled)
Improvements:
- Finish making the key bindings consistent between the Entry
and Text widgets
- Unify the key binding support in some fashion between the
two widgets (???)
- When inserting or deleting large chunks of text, do a freeze/thaw
automatically, to avoid scrolling around for ever on screen.
- Jump scroll on large insertions/deletions
- 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
|
