On 05/12/2018 09:52 PM, Joel Kulesza wrote:
>
>
> On Sat, May 12, 2018 at 7:30 PM, Richard Kimberly Heck
> <rikih...@lyx.org <mailto:rikih...@lyx.org>> wrote:
>
>     On 05/12/2018 06:29 PM, Joel Kulesza wrote:
>>     On Sat, May 12, 2018 at 9:04 AM, Jean-Marc Lasgouttes
>>     <lasgout...@lyx.org <mailto:lasgout...@lyx.org>> wrote:
>>
>>         Le 12 mai 2018 16:32:09 GMT+02:00, Joel Kulesza
>>         <jkule...@gmail.com <mailto:jkule...@gmail.com>> a écrit :
>>
>>             LyX Developers,
>>
>>             New and exciting behavior here—I wonder if others have
>>             observed this (maybe a macOS issue?).
>>
>>             Please see https://youtu.be/4qM86HmpDz4
>>             <https://youtu.be/4qM86HmpDz4>
>>
>>             This is from LyX compiled from master at ada97b5161.
>>
>>             Please let me know if/how you'd like me to proceed
>>             (additional debugging info, git bisect, etc.).
>>
>>             Thanks,
>>             Joel
>>
>>
>>         It is almostcertainly my fault but a bisect could help.
>>
>>         JMarc
>>
>>
>>     You may be off the hook; I see upon a complete git bisect
>>     starting at dd2efe8d0d:
>>
>>     8740 jkulesza@tempest[~/GIT/lyx]> g bisect good
>>     19e6977b5b527ec8311da35d8f0a40d6fd509080 is the first bad commit
>>     commit 19e6977b5b527ec8311da35d8f0a40d6fd509080
>>     Author: Richard Kimberly Heck <rikih...@lyx.org
>>     <mailto:rikih...@lyx.org>>
>>     Date:   Wed Apr 25 23:46:13 2018 -0400
>>
>>         Try to fix bug #10989.
>>
>>         The problem is that popping dialogs during reload can cause paint
>>         events for which we are not ready. If this does not work, then we
>>         can introduce a new flag, besides 'busy', for that case. But busy
>>         does not seem to be used very widely, so hopefully this works.
>>
>>     :040000 040000 5ee9f1ef0a75692839e2634baa8c70c8539f9378
>>     27bf85d3eafed6a5790a723dec226c29ffdf1c55 Msrc 
>>
>>     If this seems amiss, please let me know how you'd like me to proceed.
>
>     There was a concern that this might cause other problems.
>
>     So it's after saving that you get a failure to redraw? We probably
>     reload then, so may need
>     to call for a redraw after that.
>
>
> That's correct.  I can use the save dialog to name the file to be
> saved.  Once the dialog is dismissed (I only tested with acceptance,
> not cancellation), the work area vanishes.

Right, in that case, we do reload. So we'll have to request an explicit
redraw of the screen,
and I suppose a reload of the dialogs, etc.

I'm not sure how to do that, but either I'll figure it out or someone
will tell me.....

Riki

Reply via email to