Mercurial > hg > xemacs-beta

comparison src/scrollbar-gtk.c @ 2195:23d90a805259

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
[xemacs-hg @ 2004-07-31 12:03:05 by malcolmp] Fix cases where GTK scrollbars are left in the middle of a frame.
author malcolmp
date Sat, 31 Jul 2004 12:03:05 +0000
parents 95fee4a1420e
children 04bc9d2f42c7
comparison
equal deleted inserted replaced
2194:9b40b475f33f 2195:23d90a805259
219 (wid->allocation.height != pos_data->scrollbar_height)) 219 (wid->allocation.height != pos_data->scrollbar_height))
220 { 220 {
221 gtk_widget_set_usize (wid, 221 gtk_widget_set_usize (wid,
222 pos_data->scrollbar_width, 222 pos_data->scrollbar_width,
223 pos_data->scrollbar_height); 223 pos_data->scrollbar_height);
224
225 /*
226 UGLY! UGLY! UGLY! Changes to wid->allocation are queued and
227 not performed until the GTK event loop. However, when the
228 fontlock progress bar is run, the vertical scrollbar's height
229 is change and then changed back before events are again
230 processed. This means that the change back is not seen and
231 the scrollbar is left too short. Fix this by making the
232 change manually so the test above sees the change. This does
233 not seem to cause problems in other cases.
234 */
235
236 wid->allocation.width = pos_data->scrollbar_width;
237 wid->allocation.height = pos_data->scrollbar_height;
238
224 modified_p = 1; 239 modified_p = 1;
225 } 240 }
226 241
227 /* Ditto for the x/y position. */ 242 /* Ditto for the x/y position. */
228 if ((wid->allocation.x != pos_data->scrollbar_x) || 243 if ((wid->allocation.x != pos_data->scrollbar_x) ||
230 { 245 {
231 gtk_fixed_move (GTK_FIXED (FRAME_GTK_TEXT_WIDGET (f)), 246 gtk_fixed_move (GTK_FIXED (FRAME_GTK_TEXT_WIDGET (f)),
232 wid, 247 wid,
233 pos_data->scrollbar_x, 248 pos_data->scrollbar_x,
234 pos_data->scrollbar_y); 249 pos_data->scrollbar_y);
250
251 /*
252 UGLY! UGLY! UGLY! Changes to wid->allocation are queued and
253 not performed until the GTK event loop. However, when the
254 fontlock progress bar is run, the horizontal scrollbar's
255 position is change and then changed back before events are
256 again processed. This means that the change back is not seen
257 and the scrollbar is left in the wrong position. Fix this by
258 making the change manually so the test above sees the change.
259 This does not seem to cause problems in other cases.
260 */
261
262 wid->allocation.x = pos_data->scrollbar_x;
263 wid->allocation.y = pos_data->scrollbar_y;
264
235 modified_p = 1; 265 modified_p = 1;
236 } 266 }
237 267
238 adj->lower = pos_data->minimum; 268 adj->lower = pos_data->minimum;
239 adj->upper = pos_data->maximum; 269 adj->upper = pos_data->maximum;