7:24 p.m.
Version: 21.2.37, 21.2.38
Platform: SCO 5.0.2, gcc 2.95.2
1. Run `xemacs -q'
2. Evaluate (set-specifier menubar-visible-p nil 'global)
Gutter with buffer tabs remains located as if there is still a frame
menu. Upper text window of the same frame becomes attached to frame
upper edge, so that part of its text is overlapped by gutter.
9:21 a.m.
At 19:24 14/12/00 +0000, Golubev I. N. wrote:
Version: 21.2.37, 21.2.38
Platform: SCO 5.0.2, gcc 2.95.2
1. Run `xemacs -q'
2. Evaluate (set-specifier menubar-visible-p nil 'global)
Gutter with buffer tabs remains located as if there is still a frame
menu. Upper text window of the same frame becomes attached to frame
upper edge, so that part of its text is overlapped by gutter.
This fixes. Thanks for the report.
andy
2000-12-29 Andy Piper <andy(a)xemacs.org>
* menubar.c (menubar_visible_p_changed): signal the frame changed.
* glyphs-x.c (x_redisplay_widget): Re-calculate widget offsets if
the frame has changed so that we pick up geometry changes such as
menubar visibility.
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
7:49 p.m.
* menubar.c (menubar_visible_p_changed): signal the frame changed.
Thanks. It works. And it looks very suboptimal. Marking frame
changed should cause also many other redisplay calculations to be
done.
(Top) toolbar is (by default) also located just under menubar. But
somehow changing menubar visibility did not require `dirtying' frame
to make toolbar location honor the change. Do you understand why is
it needed for gutter but not for toolbar?
10:01 a.m.
At 19:48 04/01/01 +0000, Golubev I. N. wrote:
> * menubar.c (menubar_visible_p_changed): signal the frame
changed.
Thanks. It works. And it looks very suboptimal. Marking frame
changed should cause also many other redisplay calculations to be
done.
The problem is that it is not actually the gutter that is misplaced but the
widgets within it. The each widget has to be offset within the frame
according to the other junk in the frame. When the junk in the frame
changes the offsets have to be recalculated, doing this on frame changed
seems reasonably sensible to be - although we could attach it to other
things or introduce yet another redisplay variable.
(Top) toolbar is (by default) also located just under menubar. But
somehow changing menubar visibility did not require `dirtying' frame
to make toolbar location honor the change. Do you understand why is
it needed for gutter but not for toolbar?
Good question
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
1:46 p.m.
The menubar actually indirectly sets size_slipped, and thus size_changed,
so keying off that works also.
andy
2001-01-05 Andy Piper <andy(a)xemacs.org>
* glyphs-x.c (x_redisplay_widget): use size changed for offset
adjustment.
* menubar.c (menubar_visible_p_changed): don't mark frame changed.
At 19:48 04/01/01 +0000, Golubev I. N. wrote:
> * menubar.c (menubar_visible_p_changed): signal the frame
changed.
Thanks. It works. And it looks very suboptimal. Marking frame
changed should cause also many other redisplay calculations to be
done.
(Top) toolbar is (by default) also located just under menubar. But
somehow changing menubar visibility did not require `dirtying' frame
to make toolbar location honor the change. Do you understand why is
it needed for gutter but not for toolbar?
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
9 p.m.
At 16:16 05/01/01 +0000, Golubev I. N. wrote:
> The menubar actually indirectly sets size_slipped, and thus
size_changed,
> so keying off that works also.
It looks like xemacs has more mysteries in it. After applying
"opt.patch" to my 21.2.38 the misplacement returned.
No mystery - the patch relies on another patch that is only in CVS, so b38
will not cut it. The patch unconditionally calls MARK_FRAME_SIZE_CHANGED in
frame.c:change_frame_size().
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
8833
days inactive
8855
days old
6 comments
2 participants
participants (2)
-
Andy Piper -
Ilya N. Golubev