oustanding gtkwindow.c FIXME
- From: Tim Janik <timj gtk org>
- To: Havoc Pennington <hp redhat com>
- Cc: Gtk+ Developers <gtk-devel-list gnome org>
- Subject: oustanding gtkwindow.c FIXME
- Date: Wed, 15 Aug 2001 11:44:22 +0200 (CEST)
static void
gtk_window_move_resize (GtkWindow *window)
{
[...]
/* Increment the number of have-not-yet-received-notify requests */
window->configure_request_count += 1;
/* We have now sent a request since the last position constraint
* change
*/
info->position_constraints_changed = FALSE;
/* we are now awaiting the new configure notify event in response to our
* resizing request. the configure event will cause a new resize
* with ->configure_notify_received=TRUE.
* until then, we want to
* - discard expose events
* - coalesce resizes for our children
* - defer any window resizes until the configure event arrived
* to achieve this, we queue a resize for the window, but remove its
* resizing handler, so resizing will not be handled from the next
* idle handler but when the configure event arrives.
*
* FIXME: we should also dequeue the pending redraws here, since
* we handle those ourselves in ->configure_notify_received==TRUE.
*
* FIXME: not sure the above FIXME is correct, because we only
* queue draw in size allocate if the size actually changes,
* so if the update area for the window contains stuff
* unrelated to sizing (should be rare actually) then we
* might lose that info.
*/
gtk_widget_queue_resize (widget);
if (container->resize_mode == GTK_RESIZE_QUEUE)
_gtk_container_dequeue_resize_handler (container);
havoc, the first FIXME is still correct, and we're not loosing
redraw portions, because when we receive the new configure_event
with configure_notify_received=TRUE, we unconditionally queue
a resize in gtk_window_configure_event() and therefore also expose
the whole window. the code here just knows that, because we just
resized or moved the window, we'll definitely receive a configure
event and therefore reallocate and redraw the whole GtkWindow at
some point, so until then, we shouldn't do either.
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]