[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#38181: Actual height of mode-line not taken into account
From: |
martin rudalics |
Subject: |
bug#38181: Actual height of mode-line not taken into account |
Date: |
Sat, 16 May 2020 10:44:38 +0200 |
>> And obviously native tooltip frames which suffer the
>> same problem using
>>
>> (progn
>> (setq x-gtk-use-system-tooltips nil)
>> (set-face-background 'internal-border "red"))
>>
>> would still not display borders correctly. Or should we set their
>> titles too?
>
> Is that a serious question?
Given my current knowledge of the matter, yes. Note that ATK apparently
even mandates that tooltip windows have some sort of title set.
> Anyway, if we want to be able create frames without titles,
Our tooltips are frames and don't have titles so we do that already.
>> This way of setting things confuses me. What is then that global
>> face_change bool needed for?
>
> For when we don't want to loop over all the frames setting their
> individual flags, I guess.
Agreed. But does our code adhere to that idea? gui_set_font_backend
sets face_change to true and so does IT_set_frame_parameters (not that
it matters here - I'm just talking about the idea) while working on a
specific frame. And in x_create_tip_frame and w32_create_tip_frame we
even have to save the value of it via face_change_before even though
these two functions really should only affect the tip frame about to be
created. All other settings of face_change happen in xfaces.c and that
one really should know better.
> "Initially run with old character sizes" doing what? AFAIR, we do the
> frame title thingy quite early during the redisplay cycle. What is
> done before that that needs to know about the faces change?
Earlier, when debugging this issue, I spent some time stepping through
the iterator with the old faces in place and just wondered why the new
faces would not get applied. Whenever I'm back there I might be able to
tell more. But before that I'd rather wait whether your
> I guess we
> should simply arrange for the face cache to be cleared and the basic
> faces recomputed somewhere near the beginning of redisplay_internal.
could be implemented and solve all these problems in one rush.
>> >> Sheer luck, I presume. Couldn't PRODUCE_GLYPHS set
>> >> inhibit_free_realized_faces iff redisplaying_p is true?
>> >
>> > No, because some functions we call from Lisp actually write into the
>> > current matrix. For example, tool-bar-height and tab-bar-height.
>>
>> Then there's more to it than the above "the flag must be set during
>> redisplay, until update_frame finished its job"?
>
> More in what way? This just means we sometimes set it elsewhere as
> well.
With the inevitable consequence that redisplay_internal restores it to
true when it exits. Is that the idea behind "we sometimes set it
elsewhere as well" or just some sort of collateral damage?
>> We should say that in the doc-string of 'inhibit-free-realized-faces',
>> maybe.
>
> We should? why?
Because it might help people like me understand this issue. Do you
think that my questions are provocative? Maybe they are, but then
that's a consequence of the fact that I don't get the picture of our
implementation of faces.
martin
- bug#38181: Actual height of mode-line not taken into account, (continued)
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/06
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/06
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/06
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/07
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/07
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/06
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/07
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/10
- bug#38181: Actual height of mode-line not taken into account, martin rudalics, 2020/05/11
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/15
- bug#38181: Actual height of mode-line not taken into account,
martin rudalics <=
- bug#38181: Actual height of mode-line not taken into account, Eli Zaretskii, 2020/05/16