GNU bug report logs - #19972
24.4; Font size change doesn't update (window-total-width)

Previous Next

Full log

Message #194 received at 19972 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: steve <at> sanityinc.com, jan.h.d <at> swipnet.se, 19972 <at> debbugs.gnu.org
Subject: Re: bug#19972: Font size change doesn't update (window-total-width)
Date: Wed, 04 Mar 2015 20:59:30 +0200

> Date: Wed, 04 Mar 2015 19:45:39 +0100
> From: martin rudalics <rudalics <at> gmx.at>
> CC: jan.h.d <at> swipnet.se, steve <at> sanityinc.com, 19972 <at> debbugs.gnu.org
> 
>  > Feel free to ignore, btw.  But to clarify, what I had in mind was call
>  > MoveWindow, and wait for WM_SIZE before we call change_frame_size.  I
>  > have no idea whether this is a good idea, though.
> 
> It's not the idea that bothers me but the implementation.  Looking at
> what Jan did in x_wait_for_event it seems very unlikely that I could
> come up with an equivalent solution.  Think of the input un-/blocking
> part:
> 
>    int level = interrupt_input_blocked;
>    ...
>    while (f->wait_event_type)
>      {
>        pending_signals = true;
>        totally_unblock_input ();
>        /* XTread_socket is called after unblock.  */
>        block_input ();
>        interrupt_input_blocked = level;
> 
> Would this work on Windows?  And on Gtk he does
> 
>        (void)gtk_events_pending ();
>        gdk_flush ();
> 
> before calling x_wait_for_event.  Would we have to flush old messages on
> Windows and if so how?  All this is probably over my head.

I don't see why do we have to block and wait.  Why not simply go about
our business, and let the WM_SIZE message come in when it does, and be
handled?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.