Re: GtkWindow changes



Tim Janik <timj gtk org> writes:

> On 24 Sep 2001, Owen Taylor wrote:
> 
> > @@ -4281,8 +4256,22 @@ gtk_window_move_resize (GtkWindow *windo
> >      }
> >    else
> >      {
> > -      /* Not requesting anything new from WM, just had a queue resize
> > -       * for some reason, so handle the resize queue
> > +      /* Handle any position changes.
> > +       */
> > +      if (configure_request_pos_changed)
> > +	{
> > +	  if (window->frame)
> > +	    {
> > +	      gdk_window_move (window->frame,
> > +			       new_request.x - window->frame_left,
> > +			       new_request.y - window->frame_top);
> > +	    }
> > +	  else
> > +	    gdk_window_move (widget->window,
> > +			     new_request.x, new_request.y);
> > +	}
> > +      
> > +      /* And run the resize queue.
> >         */
> >        if (container->resize_widgets)
> >          gtk_container_resize_children (container);
> 
> hum, doesn't this mess up the window->configure_request_count here?
> iirc, a window manager should honour any of move/resize/move_resize
> with a configure event.

We are always have to be prepared to get more configure notifies
than we requested changes; the user might resize or move the window.
request_count allows us to optimize when we _know_ we are going
to get another configure notifies. But it doesn't hurt us if
request_count is too small.

Also, that optimization is only interesting when resizing, not for
pure moves, so it wouldn't help us much here; running the resize queue
immediately is a more important optimization.

Finally, the window manager would not send a notification if we
happened to already be at that position (*); the missing notificiation
is OK for resizing for rather complicated reasons (**), but with all
the screwiness between window managers for exactly how positions are
handled I don't really trust our ability to predict when we'll
get ConfigureNotify for position changes we request.

Regards,
                                        Owen

(*) The ICCCM seems to imply that you'll always get a real
    or synthetic notify for each configure request even if
    no changes are made. Window managers universally don't
    do this ... no change == no notify.

(**) We only expect if a configure notify if the last configure
     notify was at a different size than what we are going
     to request. With that condition, either:

      - The window manager has (in response to a user resize)
        already changed the size to what we are going to 
        request, and we get a configure notify from that, though
        not from our request.

      or:

      - we get a notify from our request.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]