* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
@ 2016-07-13 12:16 Stephen Berman
2016-07-13 17:34 ` martin rudalics
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Berman @ 2016-07-13 12:16 UTC (permalink / raw)
To: 23966
When I disable the tool bar before entering the Gnus Summary buffer and
then re-enable it while in that buffer, it appears as an 8-pixel high
empty strip below the menu bar. When I switch to another buffer, the
tool bar is displayed normally but the frame height increases by two
lines, and when I switch back to the Gnus Summary buffer the tool bar
again appears as an empty strip and the frame height stays at the new
height; this pattern can be repeated and each time the frame height
increases. I see the same thing when the tool bar is displayed at the
bottom of the frame; if it is displayed on the left or right side of the
frame, the frame width increases instead of the height.
I see this in builds from emacs-25 and master, as well as in 24.5, all
64-bit GNU/Linux, GTK+ Version 3.14.15 (not built --with-cairo). In the
24.5 build, when switching back to the Gnus Summary buffer, the console
displays a message like this:
(emacs:4487): Gtk-WARNING **: GtkToolbar 0x313ca90 reported min size 42
and natural size 8 in get_preferred_width(); natural size must be >= min
size
There is no such message with the emacs-25 or master builds. (In the
latter two builds, the initial frame height is 36 and increases to 38;
in the 24.5 build, the initial height is 35 and increases to 37.)
I haven't seen this issue with any other buffer than the Gnus Summary
buffer. Moreover, if I disable the tool bar only after entering the
Gnus Summary buffer and then re-enable it there, the tool bar is
displayed in that buffer normally and there is no resizing after
switching away and back.
To reproduce, start emacs with -Q and evaluate the following sexp in
*scratch*:
(let ((testfile "~/tool-bar-Gnus-frame-bug"))
(with-temp-file testfile
(insert "From nobody Wed Jul 13 13:55:54 CEST 2016
To: stephen.berman@gmx.net
Subject: bug test message
From: Stephen Berman <stephen.berman@gmx.net>
Date: Wed Jul 13 13:55:54 CEST 2016
Message-ID: <87twg9y16a.fsf@gmx.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 1
test
"))
(message "Emacs started; frame height: %d" (frame-height))
(require 'gnus)
(let ((gnus-select-method '(nnnil "")))
(message "Gnus started; frame height: %d" (frame-height))
(gnus-1)
(gnus-group-make-doc-group testfile 'mbox)
(tool-bar-mode -1)
(message "Tool bar disabled; frame height: %d" (frame-height))
(sit-for 1)
(gnus-group-select-group)
(message "Entered Summary buffer; frame height: %d" (frame-height))
(sit-for 1)
;; Uncommenting these three lines and commenting out the same three
;; lines above results in a normal tool bar and no resizing.
;; (tool-bar-mode -1)
;; (message "Tool bar disabled; frame height: %d" (frame-height))
;; (sit-for 1)
(tool-bar-mode 1)
(message "Tool bar enabled; frame height: %d" (frame-height))
(sit-for 2)
(switch-to-buffer (other-buffer))
(message "Other buffer; frame height: %d" (frame-height))
(sit-for 1)
(switch-to-buffer (other-buffer))
(message "Back to Summary buffer; frame height: %d" (frame-height)))
(sit-for 1)
;; Suppress further messages and clean up in order to repeat the test
;; simply by evaluating this sexp.
(let (message-log-max)
(gnus-summary-exit-no-update t)
(goto-char (point-min))
(gnus-group-kill-group)
(let ((gnus-expert-user t))
(gnus-group-quit))
(delete-file testfile)
(when (file-exists-p (gnus-dribble-file-name))
(delete-file (gnus-dribble-file-name))))
(switch-to-buffer "*Messages*"))
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2016-07-13 12:16 bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus Stephen Berman
@ 2016-07-13 17:34 ` martin rudalics
2016-07-13 19:21 ` Stephen Berman
0 siblings, 1 reply; 18+ messages in thread
From: martin rudalics @ 2016-07-13 17:34 UTC (permalink / raw)
To: Stephen Berman, 23966
> To reproduce, start emacs with -Q and evaluate the following sexp in
> *scratch*:
Here this gets me the following text written to *Messages*:
Emacs started; frame height: 36
Gnus started; frame height: 36
Opening nnfolder server on archive...done
No new newsgroups
Checking new news...
Reading active file via nnnil...done
Checking new news...done
No news is good news
Opening nndoc server on /home/martin/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame height: 36
Entered Summary buffer; frame height: 36
Tool bar enabled; frame height: 36
Other buffer; frame height: 36
Back to Summary buffer; frame height: 36
Tested with both release version and current master/trunk. With GTK
version 3.4.2 (IIRC). Is this expected and/or what you get? In any
case, the frame has the same height before and after executing this
form.
martin
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2016-07-13 17:34 ` martin rudalics
@ 2016-07-13 19:21 ` Stephen Berman
2016-07-14 9:01 ` martin rudalics
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Berman @ 2016-07-13 19:21 UTC (permalink / raw)
To: martin rudalics; +Cc: 23966
On Wed, 13 Jul 2016 19:34:46 +0200 martin rudalics <rudalics@gmx.at> wrote:
>> To reproduce, start emacs with -Q and evaluate the following sexp in
>> *scratch*:
>
> Here this gets me the following text written to *Messages*:
>
> Emacs started; frame height: 36
> Gnus started; frame height: 36
> Opening nnfolder server on archive...done
> No new newsgroups
> Checking new news...
> Reading active file via nnnil...done
> Checking new news...done
> No news is good news
> Opening nndoc server on /home/martin/tool-bar-Gnus-frame-bug...done
> Tool bar disabled; frame height: 36
> Entered Summary buffer; frame height: 36
> Tool bar enabled; frame height: 36
> Other buffer; frame height: 36
> Back to Summary buffer; frame height: 36
>
> Tested with both release version and current master/trunk. With GTK
> version 3.4.2 (IIRC). Is this expected and/or what you get? In any
> case, the frame has the same height before and after executing this
> form.
I did in fact see this lack of height change, but only once among the
probably dozens of times I executed that code before filing the bug
report; I was surprised but since I couldn't reproduce it, I thought it
was a fluke. All the other times, *Messages* showed this with emacs-25
and master:
Emacs started; frame height: 36
Gnus started; frame height: 36
Reading /home/steve/.newsrc.eld...
Opening nnfolder server on archive...done
No new newsgroups
Checking new news...
Reading active file via nnnil...done
Reading active file from archive via nnfolder...done
Reading active file via nndraft...done
Checking new news...done
Opening nndoc server on /home/steve/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame height: 36
Entered Summary buffer; frame height: 36
Tool bar enabled; frame height: 36
Other buffer; frame height: 38
Back to Summary buffer; frame height: 38
With 24.5 the frame height numbers were 35 (five times) followed by 37
(twice).
When the tool bar was enabled in the Gnus Summary buffer, did you see it
displayed as I describe in the OP: an empty 8-pixel high strip?
Steve Berman
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2016-07-13 19:21 ` Stephen Berman
@ 2016-07-14 9:01 ` martin rudalics
2016-07-14 9:55 ` Stephen Berman
0 siblings, 1 reply; 18+ messages in thread
From: martin rudalics @ 2016-07-14 9:01 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
> I did in fact see this lack of height change, but only once among the
> probably dozens of times I executed that code before filing the bug
> report; I was surprised but since I couldn't reproduce it, I thought it
> was a fluke. All the other times, *Messages* showed this with emacs-25
> and master:
>
> Emacs started; frame height: 36
> Gnus started; frame height: 36
> Reading /home/steve/.newsrc.eld...
> Opening nnfolder server on archive...done
> No new newsgroups
> Checking new news...
> Reading active file via nnnil...done
> Reading active file from archive via nnfolder...done
> Reading active file via nndraft...done
> Checking new news...done
> Opening nndoc server on /home/steve/tool-bar-Gnus-frame-bug...done
> Tool bar disabled; frame height: 36
> Entered Summary buffer; frame height: 36
> Tool bar enabled; frame height: 36
> Other buffer; frame height: 38
> Back to Summary buffer; frame height: 38
‘frame-height’ is not necessarily a reliable reflection of what you see
on screen.
> With 24.5 the frame height numbers were 35 (five times) followed by 37
> (twice).
>
> When the tool bar was enabled in the Gnus Summary buffer, did you see it
> displayed as I describe in the OP: an empty 8-pixel high strip?
No. I see a 35-pixel high strip. With the following definitions
adapted from yours
(defun gtk-tool-bar-height (&optional frame)
(let* ((frame (window-normalize-frame frame))
(geometry (frame-geometry frame)))
(cddr (assq 'tool-bar-size geometry))))
(let ((testfile "~/tool-bar-Gnus-frame-bug"))
(with-temp-file testfile
(insert "From nobody Wed Jul 13 13:55:54 CEST 2016
To: stephen.berman@gmx.net
Subject: bug test message
From: Stephen Berman <stephen.berman@gmx.net>
Date: Wed Jul 13 13:55:54 CEST 2016
Message-ID: <87twg9y16a.fsf@gmx.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Lines: 1
test
"))
(sit-for 0.1) (message "Emacs started; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
(require 'gnus)
(let ((gnus-select-method '(nnnil "")))
(sit-for 0.1) (message "Gnus started; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
(gnus-1)
(gnus-group-make-doc-group testfile 'mbox)
(tool-bar-mode -1)
(sit-for 0.1) (message "Tool bar disabled; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
(sit-for 1)
(gnus-group-select-group)
(sit-for 0.1) (message "Entered Summary buffer; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
(sit-for 1)
;; Uncommenting these three lines and commenting out the same three
;; lines above results in a normal tool bar and no resizing.
;; (tool-bar-mode -1)
;; (sit-for 0.1) (message "Tool bar disabled; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
;; (sit-for 1)
(tool-bar-mode 1)
(sit-for 0.1) (message "Tool bar enabled; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
(sit-for 3)
(switch-to-buffer (other-buffer))
(sit-for 0.1) (message "Other buffer; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
(sit-for 3)
(switch-to-buffer (other-buffer))
(sit-for 0.1) (message "Back to Summary buffer; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height)))
(sit-for 3)
;; Suppress further messages and clean up in order to repeat the test
;; simply by evaluating this sexp.
(let (message-log-max)
(gnus-summary-exit-no-update t)
(goto-char (point-min))
(gnus-group-kill-group)
(let ((gnus-expert-user t))
(gnus-group-quit))
(delete-file testfile)
(when (file-exists-p (gnus-dribble-file-name))
(delete-file (gnus-dribble-file-name))))
(sit-for 0.1) (message "Final; frame pixel height: %d toolbar height: %d" (frame-pixel-height) (gtk-tool-bar-height))
(sit-for 5)
(switch-to-buffer "*Messages*"))
and `eval-buffer' of these in an emacs -Q of the release version I get
Emacs started; frame pixel height: 648 toolbar height: 44
Gnus started; frame pixel height: 648 toolbar height: 44
Opening nnfolder server on archive...done
No new newsgroups
Checking new news...
Reading active file via nnnil...done
Checking new news...done
No news is good news
Opening nndoc server on /home/martin/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame pixel height: 648 toolbar height: 0
Entered Summary buffer; frame pixel height: 648 toolbar height: 0
Tool bar enabled; frame pixel height: 657 toolbar height: 35
Other buffer; frame pixel height: 648 toolbar height: 44
Back to Summary buffer; frame pixel height: 657 toolbar height: 35
Final; frame pixel height: 648 toolbar height: 44
You can run the command ‘eval-buffer’ with M-x ev-b RET
Final; frame pixel height: 648 toolbar height: 44
So the "empty strips" here have a height of 35 pixels while the "normal"
toolbar has 44 pixels. BTW, before getting the "Tool bar enabled"
message I briefly see some toolbar contents flashing and getting erased
immediately thereafter.
The entire frame height doesn't change here probably due to rounding and
size hints. However, when I set `frame-resize-pixelwise' to t it
changes as follows:
Emacs started; frame pixel height: 648 toolbar height: 44
Gnus started; frame pixel height: 648 toolbar height: 44
Opening nnfolder server on archive...done
No new newsgroups
Checking new news...
Reading active file via nnnil...done
Checking new news...done
No news is good news
Opening nndoc server on /home/martin/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame pixel height: 648 toolbar height: 0
Entered Summary buffer; frame pixel height: 648 toolbar height: 0
Tool bar enabled; frame pixel height: 657 toolbar height: 35
Other buffer; frame pixel height: 657 toolbar height: 44
Back to Summary buffer; frame pixel height: 666 toolbar height: 35
Final; frame pixel height: 666 toolbar height: 44
So the pixel height of my frame has increased by 18 (2 times 9 pixels
from the difference between 44 and 35).
What do you get with my modifications?
martin
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2016-07-14 9:01 ` martin rudalics
@ 2016-07-14 9:55 ` Stephen Berman
2016-07-14 17:33 ` martin rudalics
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Berman @ 2016-07-14 9:55 UTC (permalink / raw)
To: martin rudalics; +Cc: 23966
On Thu, 14 Jul 2016 11:01:39 +0200 martin rudalics <rudalics@gmx.at> wrote:
> ‘frame-height’ is not necessarily a reliable reflection of what you see
> on screen.
Why not? What's more reliable?
>> When the tool bar was enabled in the Gnus Summary buffer, did you see it
>> displayed as I describe in the OP: an empty 8-pixel high strip?
>
> No. I see a 35-pixel high strip. With the following definitions
> adapted from yours
[...]
> and `eval-buffer' of these in an emacs -Q of the release version I get
I assume you mean from emacs-25? With 24.5 I get "Symbol's function
definition is void: frame-geometry".
> Emacs started; frame pixel height: 648 toolbar height: 44
> Gnus started; frame pixel height: 648 toolbar height: 44
> Opening nnfolder server on archive...done
> No new newsgroups
> Checking new news...
> Reading active file via nnnil...done
> Checking new news...done
> No news is good news
> Opening nndoc server on /home/martin/tool-bar-Gnus-frame-bug...done
> Tool bar disabled; frame pixel height: 648 toolbar height: 0
> Entered Summary buffer; frame pixel height: 648 toolbar height: 0
> Tool bar enabled; frame pixel height: 657 toolbar height: 35
> Other buffer; frame pixel height: 648 toolbar height: 44
> Back to Summary buffer; frame pixel height: 657 toolbar height: 35
> Final; frame pixel height: 648 toolbar height: 44
> You can run the command ‘eval-buffer’ with M-x ev-b RET
> Final; frame pixel height: 648 toolbar height: 44
>
>
> So the "empty strips" here have a height of 35 pixels while the "normal"
> toolbar has 44 pixels. BTW, before getting the "Tool bar enabled"
> message I briefly see some toolbar contents flashing and getting erased
> immediately thereafter.
I didn't consciously notice that before, but now that you mention it, I
do see that too.
> The entire frame height doesn't change here probably due to rounding and
> size hints. However, when I set `frame-resize-pixelwise' to t it
> changes as follows:
>
>
> Emacs started; frame pixel height: 648 toolbar height: 44
> Gnus started; frame pixel height: 648 toolbar height: 44
> Opening nnfolder server on archive...done
> No new newsgroups
> Checking new news...
> Reading active file via nnnil...done
> Checking new news...done
> No news is good news
> Opening nndoc server on /home/martin/tool-bar-Gnus-frame-bug...done
> Tool bar disabled; frame pixel height: 648 toolbar height: 0
> Entered Summary buffer; frame pixel height: 648 toolbar height: 0
> Tool bar enabled; frame pixel height: 657 toolbar height: 35
> Other buffer; frame pixel height: 657 toolbar height: 44
> Back to Summary buffer; frame pixel height: 666 toolbar height: 35
> Final; frame pixel height: 666 toolbar height: 44
>
>
> So the pixel height of my frame has increased by 18 (2 times 9 pixels
> from the difference between 44 and 35).
>
> What do you get with my modifications?
On emacs-25 with -Q and frame-resize-pixelwise nil:
Emacs started; frame pixel height: 576 toolbar height: 53
Gnus started; frame pixel height: 576 toolbar height: 53
Reading /home/steve/.newsrc.eld...
Opening nnfolder server on archive...done
No new newsgroups
Checking new news...
Reading active file via nnnil...done
Reading active file from archive via nnfolder...done
Reading active file via nndraft...done
Checking new news...done
Opening nndoc server on /home/steve/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame pixel height: 576 toolbar height: 0
Entered Summary buffer; frame pixel height: 576 toolbar height: 0
Tool bar enabled; frame pixel height: 621 toolbar height: 8
Other buffer; frame pixel height: 608 toolbar height: 53
Back to Summary buffer; frame pixel height: 645 toolbar height: 8
Final; frame pixel height: 640 toolbar height: 53
On master with -Q and frame-resize-pixelwise nil the results were the
same except for the third to last line:
Other buffer; frame pixel height: 608 toolbar height: 45
On emacs-25 with -Q frame-resize-pixelwise t:
Emacs started; frame pixel height: 576 toolbar height: 53
Gnus started; frame pixel height: 576 toolbar height: 53
Reading /home/steve/.newsrc.eld...
Opening nnfolder server on archive...done
No new newsgroups
Checking new news...
Reading active file via nnnil...done
Reading active file from archive via nnfolder...done
Reading active file via nndraft...done
Checking new news...done
Opening nndoc server on /home/steve/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame pixel height: 576 toolbar height: 0
Entered Summary buffer; frame pixel height: 576 toolbar height: 0
Tool bar enabled; frame pixel height: 621 toolbar height: 8
Other buffer; frame pixel height: 621 toolbar height: 53
Back to Summary buffer; frame pixel height: 666 toolbar height: 8
Final; frame pixel height: 666 toolbar height: 53
On master with -Q and frame-resize-pixelwise t the results were the
same except for the last three lines:
Other buffer; frame pixel height: 621 toolbar height: 45
Back to Summary buffer; frame pixel height: 658 toolbar height: 8
Final; frame pixel height: 658 toolbar height: 53
Steve Berman
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2016-07-14 9:55 ` Stephen Berman
@ 2016-07-14 17:33 ` martin rudalics
2016-07-14 19:14 ` Stephen Berman
0 siblings, 1 reply; 18+ messages in thread
From: martin rudalics @ 2016-07-14 17:33 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
>> ‘frame-height’ is not necessarily a reliable reflection of what you see
>> on screen.
>
> Why not?
Because of rounding. Tool bar, menu bar and scroll bars do not have
necessarily sizes that are multiples of a frame's default character
size. And often you're losing pixels when the frame gets maximized or
‘frame-resize-pixelwise’ is non-nil during resizing.
> What's more reliable?
Everything that counts in pixels like ‘frame-pixel-height’.
>> ... in an emacs -Q of the release version I get
>
> I assume you mean from emacs-25?
Yes.
> With 24.5 I get "Symbol's function
> definition is void: frame-geometry".
Indeed.
>> What do you get with my modifications?
>
> On emacs-25 with -Q and frame-resize-pixelwise nil:
[...]
> Other buffer; frame pixel height: 608 toolbar height: 53
[...]
>
> On master with -Q and frame-resize-pixelwise nil the results were the
> same except for the third to last line:
>
> Other buffer; frame pixel height: 608 toolbar height: 45
Not here. I get 648 and 44 in both cases.
> On emacs-25 with -Q frame-resize-pixelwise t:
>
> Emacs started; frame pixel height: 576 toolbar height: 53
[...]
> Final; frame pixel height: 666 toolbar height: 53
So your frame has grown by 90 pixels. Remarkable. BTW setting
‘frame-inhibit-implied-resize’ to t would avoid that.
> On master with -Q and frame-resize-pixelwise t the results were the
> same except for the last three lines:
>
> Other buffer; frame pixel height: 621 toolbar height: 45
> Back to Summary buffer; frame pixel height: 658 toolbar height: 8
> Final; frame pixel height: 658 toolbar height: 53
Here all lines are the same, again.
The problem is not GTK specific. Lucid and Motif behave similarly. I
suppose that just enabling ‘tool-bar-mode’ is not sufficient to make a
gnus tool bar once gnus has started. Maybe this deficiency is inherent
to ‘tool-bar-mode’ itself. But it would be interesting to find out
who's responsible for making such small (8 pixels in your, 35 pixels in
my case) tool bars in the first place.
martin
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2016-07-14 17:33 ` martin rudalics
@ 2016-07-14 19:14 ` Stephen Berman
2018-04-12 15:01 ` Lars Ingebrigtsen
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Berman @ 2016-07-14 19:14 UTC (permalink / raw)
To: martin rudalics; +Cc: 23966
On Thu, 14 Jul 2016 19:33:41 +0200 martin rudalics <rudalics@gmx.at> wrote:
>>> ‘frame-height’ is not necessarily a reliable reflection of what you see
>>> on screen.
>>
>> Why not?
>
> Because of rounding. Tool bar, menu bar and scroll bars do not have
> necessarily sizes that are multiples of a frame's default character
> size. And often you're losing pixels when the frame gets maximized or
> ‘frame-resize-pixelwise’ is non-nil during resizing.
>
>> What's more reliable?
>
> Everything that counts in pixels like ‘frame-pixel-height’.
Thanks.
>>> What do you get with my modifications?
>>
>> On emacs-25 with -Q and frame-resize-pixelwise nil:
> [...]
>> Other buffer; frame pixel height: 608 toolbar height: 53
> [...]
>>
>> On master with -Q and frame-resize-pixelwise nil the results were the
>> same except for the third to last line:
>>
>> Other buffer; frame pixel height: 608 toolbar height: 45
>
> Not here. I get 648 and 44 in both cases.
>
>> On emacs-25 with -Q frame-resize-pixelwise t:
>>
>> Emacs started; frame pixel height: 576 toolbar height: 53
> [...]
>> Final; frame pixel height: 666 toolbar height: 53
>
> So your frame has grown by 90 pixels. Remarkable. BTW setting
> ‘frame-inhibit-implied-resize’ to t would avoid that.
Ah, indeed. I didn't know about that variable, thanks.
> The problem is not GTK specific. Lucid and Motif behave similarly. I
Interesting; I had suspected it was just a GTK issue.
> suppose that just enabling ‘tool-bar-mode’ is not sufficient to make a
> gnus tool bar once gnus has started. Maybe this deficiency is inherent
> to ‘tool-bar-mode’ itself. But it would be interesting to find out
> who's responsible for making such small (8 pixels in your, 35 pixels in
> my case) tool bars in the first place.
Indeed.
Steve Berman
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2016-07-14 19:14 ` Stephen Berman
@ 2018-04-12 15:01 ` Lars Ingebrigtsen
2018-04-13 9:16 ` Stephen Berman
0 siblings, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2018-04-12 15:01 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
Stephen Berman <stephen.berman@gmx.net> writes:
>> suppose that just enabling ‘tool-bar-mode’ is not sufficient to make a
>> gnus tool bar once gnus has started. Maybe this deficiency is inherent
>> to ‘tool-bar-mode’ itself. But it would be interesting to find out
>> who's responsible for making such small (8 pixels in your, 35 pixels in
>> my case) tool bars in the first place.
>
> Indeed.
Do you still see this on Emacs master now? There have been quite a few
pixel-sizing fixes applied to Emacs over the past year...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2018-04-12 15:01 ` Lars Ingebrigtsen
@ 2018-04-13 9:16 ` Stephen Berman
2020-07-19 16:02 ` Lars Ingebrigtsen
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Berman @ 2018-04-13 9:16 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 23966
On Thu, 12 Apr 2018 17:01:35 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>>> suppose that just enabling ‘tool-bar-mode’ is not sufficient to make a
>>> gnus tool bar once gnus has started. Maybe this deficiency is inherent
>>> to ‘tool-bar-mode’ itself. But it would be interesting to find out
>>> who's responsible for making such small (8 pixels in your, 35 pixels in
>>> my case) tool bars in the first place.
>>
>> Indeed.
>
> Do you still see this on Emacs master now? There have been quite a few
> pixel-sizing fixes applied to Emacs over the past year...
Yes, with (a gtk3 build of) current master I still get frame resizing
both with my original recipe and with Martin's pixelwise adjustment.
For the latter, here are the outputs
with frame-resize-pixelwise nil:
Emacs started; frame pixel height: 648 toolbar height: 42
Gnus started; frame pixel height: 648 toolbar height: 42
Opening nnfolder server on archive...done
Subscribe newsgroup: nnfolder+archive:sent
Subscribe newsgroup: nnfolder+archive:emacs-personal
2 new newsgroups have arrived
Checking new news...
Reading active file via nnnil...done
Reading active file from archive via nnfolder...done
Checking new news...done
Opening nndoc server on /home/steve/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame pixel height: 648 toolbar height: 0
Entered Summary buffer; frame pixel height: 648 toolbar height: 0
Tool bar enabled; frame pixel height: 683 toolbar height: 7
Other buffer; frame pixel height: 666 toolbar height: 42
Back to Summary buffer; frame pixel height: 701 toolbar height: 7
Final; frame pixel height: 684 toolbar height: 42
and with frame-resize-pixelwise t:
Emacs started; frame pixel height: 648 toolbar height: 42
Gnus started; frame pixel height: 648 toolbar height: 42
Opening nnfolder server on archive...done
Subscribe newsgroup: nnfolder+archive:sent
Subscribe newsgroup: nnfolder+archive:emacs-personal
2 new newsgroups have arrived
Checking new news...
Reading active file via nnnil...done
Reading active file from archive via nnfolder...done
Checking new news...done
Opening nndoc server on /home/steve/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame pixel height: 648 toolbar height: 0
Entered Summary buffer; frame pixel height: 648 toolbar height: 0
Tool bar enabled; frame pixel height: 683 toolbar height: 7
Other buffer; frame pixel height: 683 toolbar height: 42
Back to Summary buffer; frame pixel height: 718 toolbar height: 7
Final; frame pixel height: 718 toolbar height: 42
Steve Berman
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2018-04-13 9:16 ` Stephen Berman
@ 2020-07-19 16:02 ` Lars Ingebrigtsen
2020-07-20 9:10 ` Stephen Berman
0 siblings, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2020-07-19 16:02 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
OK, I'm trying to reproduce this in Emacs 28, and... I'm getting all
kinds of strangeness.
I usually don't use tool bars, but if I just enter a summary mode buffer
and say M-x tool-bar-mode, then I don't actually get a tool bar -- I
just get a ~10-pixel high grey stripe at the top.
This may be because gnus-summary-tool-bar is
'gnus-summary-tool-bar-retro?
If, on the other hand, I switch tool-bar-mode on before starting Gnus,
then I do get a tool bar, and that variable is
'gnus-summary-tool-bar-gnome.
This is because
(defcustom gnus-summary-tool-bar (if (eq gmm-tool-bar-style 'gnome)
'gnus-summary-tool-bar-gnome
'gnus-summary-tool-bar-retro)
and
(defcustom gmm-tool-bar-style
(if (and (boundp 'tool-bar-mode)
tool-bar-mode
(not (memq (display-visual-class)
(list 'static-gray 'gray-scale
'static-color 'pseudo-color))))
'gnome
'retro)
"Preferred tool bar style."
:type '(choice (const :tag "GNOME style" gnome)
(const :tag "Retro look" retro))
:group 'gmm)
so that's set at load time, and depends on whether you've switched tool
bar mode on or not before loading the file. Which seems less than
optimal...
Anyway, is this a different bug than what you were all talking about?
:-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2020-07-19 16:02 ` Lars Ingebrigtsen
@ 2020-07-20 9:10 ` Stephen Berman
2020-07-20 9:31 ` Lars Ingebrigtsen
2020-07-20 9:33 ` Lars Ingebrigtsen
0 siblings, 2 replies; 18+ messages in thread
From: Stephen Berman @ 2020-07-20 9:10 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 23966
On Sun, 19 Jul 2020 18:02:15 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> OK, I'm trying to reproduce this in Emacs 28, and... I'm getting all
> kinds of strangeness.
>
> I usually don't use tool bars, but if I just enter a summary mode buffer
> and say M-x tool-bar-mode, then I don't actually get a tool bar -- I
> just get a ~10-pixel high grey stripe at the top.
>
> This may be because gnus-summary-tool-bar is
> 'gnus-summary-tool-bar-retro?
>
> If, on the other hand, I switch tool-bar-mode on before starting Gnus,
> then I do get a tool bar, and that variable is
> 'gnus-summary-tool-bar-gnome.
>
> This is because
>
> (defcustom gnus-summary-tool-bar (if (eq gmm-tool-bar-style 'gnome)
> 'gnus-summary-tool-bar-gnome
> 'gnus-summary-tool-bar-retro)
>
> and
>
> (defcustom gmm-tool-bar-style
> (if (and (boundp 'tool-bar-mode)
> tool-bar-mode
> (not (memq (display-visual-class)
> (list 'static-gray 'gray-scale
> 'static-color 'pseudo-color))))
> 'gnome
> 'retro)
> "Preferred tool bar style."
> :type '(choice (const :tag "GNOME style" gnome)
> (const :tag "Retro look" retro))
> :group 'gmm)
>
> so that's set at load time, and depends on whether you've switched tool
> bar mode on or not before loading the file. Which seems less than
> optimal...
>
> Anyway, is this a different bug than what you were all talking about?
> :-)
It seems like the same bug, or at least related. In any case, when I
run the test code Martin posted in <578754F3.9060800@gmx.at> on a
currentish (2020-07-01) build from master, I get similar but not
identical results to those I got two years ago:
Emacs started; frame pixel height: 612 toolbar height: 41
Gnus started; frame pixel height: 612 toolbar height: 41
Opening nnfolder server on archive...done
Subscribe newsgroup: nnfolder+archive:sent
Subscribe newsgroup: nnfolder+archive:##
Subscribe newsgroup: nnfolder+archive:emacs-personal
3 new newsgroups have arrived
Checking new news...
Reading active file via nnnil...done
Reading active file from archive via nnfolder...done
Checking new news...done
Opening nndoc server on /home/steve/tool-bar-Gnus-frame-bug...done
Tool bar disabled; frame pixel height: 612 toolbar height: 0
Entered Summary buffer; frame pixel height: 612 toolbar height: 0
Tool bar enabled; frame pixel height: 646 toolbar height: 7
Other buffer; frame pixel height: 646 toolbar height: 41
Back to Summary buffer; frame pixel height: 680 toolbar height: 7
Final; frame pixel height: 680 toolbar height: 41
Moreover, I get these exact same results regardless of whether
frame-resize-pixelwise it nil or t, which is different from two years
ago, and also when I set gmm-tool-bar-style to 'gnome or
gnus-summary-tool-bar to 'gnus-summary-tool-bar-gnome before evaluating
the test code.
Steve Berman
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2020-07-20 9:10 ` Stephen Berman
@ 2020-07-20 9:31 ` Lars Ingebrigtsen
2020-07-20 9:50 ` Stephen Berman
2020-07-20 9:33 ` Lars Ingebrigtsen
1 sibling, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2020-07-20 9:31 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
Stephen Berman <stephen.berman@gmx.net> writes:
> Moreover, I get these exact same results regardless of whether
> frame-resize-pixelwise it nil or t, which is different from two years
> ago, and also when I set gmm-tool-bar-style to 'gnome or
> gnus-summary-tool-bar to 'gnus-summary-tool-bar-gnome before evaluating
> the test code.
If you switch tool-bar-mode on before starting Gnus (well, before
loading anything else), do you get a proper tool bar in Gnus buffers?
In that case, I think we're seeing the same thing...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2020-07-20 9:10 ` Stephen Berman
2020-07-20 9:31 ` Lars Ingebrigtsen
@ 2020-07-20 9:33 ` Lars Ingebrigtsen
2020-07-20 9:43 ` Lars Ingebrigtsen
1 sibling, 1 reply; 18+ messages in thread
From: Lars Ingebrigtsen @ 2020-07-20 9:33 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
Hm! If I call
(gnus-summary-make-tool-bar)
after switching tool-bar-mode on (in the summary buffer), I then get a
proper tool bar.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2020-07-20 9:33 ` Lars Ingebrigtsen
@ 2020-07-20 9:43 ` Lars Ingebrigtsen
2020-08-04 9:29 ` Lars Ingebrigtsen
[not found] ` <87mu3arc6u.fsf@gnus.org>
0 siblings, 2 replies; 18+ messages in thread
From: Lars Ingebrigtsen @ 2020-07-20 9:43 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
As somebody who doesn't use tool bars normally, I'm wondering -- do we
really need two different tool bar styles in Gnus? Can't we just rip
out the `retro' stuff and thing will possibly be less confusing?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2020-07-20 9:31 ` Lars Ingebrigtsen
@ 2020-07-20 9:50 ` Stephen Berman
2020-07-23 15:25 ` Lars Ingebrigtsen
0 siblings, 1 reply; 18+ messages in thread
From: Stephen Berman @ 2020-07-20 9:50 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: Stephen Berman, 23966
On Mon, 20 Jul 2020 11:31:16 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> Moreover, I get these exact same results regardless of whether
>> frame-resize-pixelwise it nil or t, which is different from two years
>> ago, and also when I set gmm-tool-bar-style to 'gnome or
>> gnus-summary-tool-bar to 'gnus-summary-tool-bar-gnome before evaluating
>> the test code.
>
> If you switch tool-bar-mode on before starting Gnus (well, before
> loading anything else), do you get a proper tool bar in Gnus buffers?
Yes.
> In that case, I think we're seeing the same thing...
On Mon, 20 Jul 2020 11:33:56 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> Hm! If I call
>
> (gnus-summary-make-tool-bar)
>
> after switching tool-bar-mode on (in the summary buffer), I then get a
> proper tool bar.
Me too.
On Mon, 20 Jul 2020 11:43:06 +0200 Lars Ingebrigtsen <larsi@gnus.org> wrote:
> As somebody who doesn't use tool bars normally, I'm wondering -- do we
> really need two different tool bar styles in Gnus? Can't we just rip
> out the `retro' stuff and thing will possibly be less confusing?
I stopped regularly using tool bars a while ago, and even before I don't
think I knew about the Gnus retro tool bar... so as far as I'm
concerned, rip away!
Steve Berman
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2020-07-20 9:50 ` Stephen Berman
@ 2020-07-23 15:25 ` Lars Ingebrigtsen
0 siblings, 0 replies; 18+ messages in thread
From: Lars Ingebrigtsen @ 2020-07-23 15:25 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966
Stephen Berman <stephen.berman@gmx.net> writes:
>> As somebody who doesn't use tool bars normally, I'm wondering -- do we
>> really need two different tool bar styles in Gnus? Can't we just rip
>> out the `retro' stuff and thing will possibly be less confusing?
>
> I stopped regularly using tool bars a while ago, and even before I don't
> think I knew about the Gnus retro tool bar... so as far as I'm
> concerned, rip away!
I'm wondering whether the -gnome tool bare really are connected to Gnome
in any way (i.e., they can only be used when Emacs is compiled with the
gtk toolkit), or whether they're just "Gnome-style".
If it's the latter, we can rip out the other ones, I guess, but not if
it's the former...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
2020-07-20 9:43 ` Lars Ingebrigtsen
@ 2020-08-04 9:29 ` Lars Ingebrigtsen
[not found] ` <87mu3arc6u.fsf@gnus.org>
1 sibling, 0 replies; 18+ messages in thread
From: Lars Ingebrigtsen @ 2020-08-04 9:29 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966, ding
Lars Ingebrigtsen <larsi@gnus.org> writes:
> As somebody who doesn't use tool bars normally, I'm wondering -- do we
> really need two different tool bar styles in Gnus? Can't we just rip
> out the `retro' stuff and thing will possibly be less confusing?
Perhaps somebody on the Gnus mailing list has some input here.
To recap -- there's some bugs in enabling the Summary mode tool bar,
because there's some setup being done at Gnus load time. This can be
fixed, I'm just wondering whether the proper fix here is to simplify the
code.
There's currently two tool bars for Gnus summary mode:
gnus-summary-tool-bar-retro
gnus-summary-tool-bar-gnome
I propose to get rid of the -retro one. Does anybody object to that?
Or is the -gnome tool bar really specific to Gnome, and it won't work on
other OS-es or something?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus
[not found] ` <87mu3arc6u.fsf@gnus.org>
@ 2022-04-30 16:18 ` Lars Ingebrigtsen
0 siblings, 0 replies; 18+ messages in thread
From: Lars Ingebrigtsen @ 2022-04-30 16:18 UTC (permalink / raw)
To: Stephen Berman; +Cc: 23966, ding
Lars Ingebrigtsen <larsi@gnus.org> writes:
> I propose to get rid of the -retro one. Does anybody object to that?
Nobody objected in a year, so I've now done so in Emacs 29.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-04-30 16:18 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2016-07-13 12:16 bug#23966: 25.1.50; Frame resizing due to tool bar + Gnus Stephen Berman
2016-07-13 17:34 ` martin rudalics
2016-07-13 19:21 ` Stephen Berman
2016-07-14 9:01 ` martin rudalics
2016-07-14 9:55 ` Stephen Berman
2016-07-14 17:33 ` martin rudalics
2016-07-14 19:14 ` Stephen Berman
2018-04-12 15:01 ` Lars Ingebrigtsen
2018-04-13 9:16 ` Stephen Berman
2020-07-19 16:02 ` Lars Ingebrigtsen
2020-07-20 9:10 ` Stephen Berman
2020-07-20 9:31 ` Lars Ingebrigtsen
2020-07-20 9:50 ` Stephen Berman
2020-07-23 15:25 ` Lars Ingebrigtsen
2020-07-20 9:33 ` Lars Ingebrigtsen
2020-07-20 9:43 ` Lars Ingebrigtsen
2020-08-04 9:29 ` Lars Ingebrigtsen
[not found] ` <87mu3arc6u.fsf@gnus.org>
2022-04-30 16:18 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).