GNU bug report logs -
#46773
28.0.50; Different heights for toolbar
Previous Next
Reported by: Lars Ingebrigtsen <larsi <at> gnus.org>
Date: Thu, 25 Feb 2021 15:31:02 UTC
Severity: normal
Tags: notabug
Found in version 28.0.50
Done: Lars Ingebrigtsen <larsi <at> gnus.org>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 46773 in the body.
You can then email your comments to 46773 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Thu, 25 Feb 2021 15:31:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Lars Ingebrigtsen <larsi <at> gnus.org>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 25 Feb 2021 15:31:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Starting from "emacs -Q":
C-h b
and choose the *Help* buffer. You get this tool bar:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
Switch back to the *scratch* buffer. You get this tool bar:
[Message part 4 (image/png, inline)]
[Message part 5 (text/plain, inline)]
Which is taller. This means that the Emacs frame changes size every
time you pop between these two windows, which is highly annoying.
I guess it has something to do with the former toolbar not having any
text?
In GNU Emacs 28.0.50 (build 31, x86_64-pc-linux-gnu, GTK+ Version 3.24.23, cairo version 1.16.0)
of 2021-02-22 built on xo
Repository revision: c1712f55070d1fe861517d2c1a9fe53622f0e6a6
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Thu, 25 Feb 2021 15:38:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 25 Feb 2021 16:30:02 +0100
>
> Which is taller. This means that the Emacs frame changes size every
> time you pop between these two windows, which is highly annoying.
>
> I guess it has something to do with the former toolbar not having any
> text?
Yes. And I think it's a GTK-only thing.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Thu, 25 Feb 2021 16:37:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 46773 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 25 Feb 2021 17:37:24 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Lars Ingebrigtsen <larsi <at> gnus.org>
>> Date: Thu, 25 Feb 2021 16:30:02 +0100
>>
>> Which is taller. This means that the Emacs frame changes size every
>> time you pop between these two windows, which is highly annoying.
>>
>> I guess it has something to do with the former toolbar not having any
>> text?
Eli> Yes. And I think it's a GTK-only thing.
Didnʼt we vaguely agree that we should remove the text from the GTK
toolbar, as itʼs the only one that does it?
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Thu, 25 Feb 2021 18:25:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 46773 <at> debbugs.gnu.org
> Date: Thu, 25 Feb 2021 17:36:34 +0100
>
> >> I guess it has something to do with the former toolbar not having any
> >> text?
>
> Eli> Yes. And I think it's a GTK-only thing.
>
> Didnʼt we vaguely agree that we should remove the text from the GTK
> toolbar, as itʼs the only one that does it?
If we did, I don't remember such an agreement. Which doesn't mean it
didn't happen, of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 09:14:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 46773 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 25 Feb 2021 20:23:42 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
>> From: Robert Pluim <rpluim <at> gmail.com>
>> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 46773 <at> debbugs.gnu.org
>> Date: Thu, 25 Feb 2021 17:36:34 +0100
>>
>> >> I guess it has something to do with the former toolbar not having any
>> >> text?
>>
Eli> Yes. And I think it's a GTK-only thing.
>>
>> Didnʼt we vaguely agree that we should remove the text from the GTK
>> toolbar, as itʼs the only one that does it?
Eli> If we did, I don't remember such an agreement. Which doesn't mean it
Eli> didn't happen, of course.
It was a vague memory of a vague agreement, which I now canʼt find in
my archives. Perhaps we should do it anyway.
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 12:04:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 46773 <at> debbugs.gnu.org, larsi <at> gnus.org
> Date: Fri, 26 Feb 2021 10:13:37 +0100
>
> >> Didnʼt we vaguely agree that we should remove the text from the GTK
> >> toolbar, as itʼs the only one that does it?
>
> Eli> If we did, I don't remember such an agreement. Which doesn't mean it
> Eli> didn't happen, of course.
>
> It was a vague memory of a vague agreement, which I now canʼt find in
> my archives. Perhaps we should do it anyway.
I "vaguely" remember that Dmitry likes that, so let's hear his opinion
first.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 15:49:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 46773 <at> debbugs.gnu.org (full text, mbox):
On 26.02.2021 14:03, Eli Zaretskii wrote:
> I "vaguely" remember that Dmitry likes that, so let's hear his opinion
> first.
Sure.
I'm no GTK expert, but a brief survey of other software shows that
buttons these days usually have text or icon, never both (which is a
waste of space). Some text could reside on the toolbar near the buttons,
though (to describe a group of them).
FWIW, I can't reproduce the scenario in the report here, possibly
because my text height is smaller than the icons, and Lars has it the
opposite. High scale factor? GTK2 build?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 16:09:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> I'm no GTK expert, but a brief survey of other software shows that
> buttons these days usually have text or icon, never both (which is a
> waste of space).
"brief survey", yet "never".
I believe that MS Windows and its apps, and many
non-MS apps that run on Windows, let _users_
choose icons, text, or both. I could be wrong,
but I don't think so.
If I'm right, does that count for you, for
"these days"?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 16:24:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 46773 <at> debbugs.gnu.org (full text, mbox):
On 26.02.2021 18:08, Drew Adams wrote:
> I believe that MS Windows and its apps, and many
> non-MS apps that run on Windows, let_users_
> choose icons, text, or both. I could be wrong,
> but I don't think so.
Evidence welcome.
> If I'm right, does that count for you, for
> "these days"?
Sure.
Even so, if the default behavior is as I said we should do that at least
by default.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 17:04:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 46773 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 26 Feb 2021 18:23:05 +0200, Dmitry Gutov <dgutov <at> yandex.ru> said:
Dmitry> On 26.02.2021 18:08, Drew Adams wrote:
>> I believe that MS Windows and its apps, and many
>> non-MS apps that run on Windows, let_users_
>> choose icons, text, or both. I could be wrong,
>> but I don't think so.
Dmitry> Evidence welcome.
>> If I'm right, does that count for you, for
>> "these days"?
Dmitry> Sure.
Dmitry> Even so, if the default behavior is as I said we should do that at
Dmitry> least by default.
With an option to toggle from icon->icon+text? Sounds good to me
(although I haven't found yet why weʼre only showing text for some of
the icons under gtk).
Robert
--
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 18:15:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 46773 <at> debbugs.gnu.org (full text, mbox):
On 26.02.2021 19:02, Robert Pluim wrote:
> With an option to toggle from icon->icon+text? Sounds good to me
> (although I haven't found yet why weʼre only showing text for some of
> the icons under gtk).
Seems like someone sometime decided that "save" and "undo" need
clarification (due to low-quality icons?), and others don't.
But for the above feature to work, I guess we'll need to annotate all of
them. Well, at least the person working on adding that feature would.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Fri, 26 Feb 2021 19:55:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Drew Adams <drew.adams <at> oracle.com>, Eli Zaretskii <eliz <at> gnu.org>,
> <46773 <at> debbugs.gnu.org>, "larsi <at> gnus.org" <larsi <at> gnus.org>
> Date: Fri, 26 Feb 2021 18:02:58 +0100
>
> Dmitry> Even so, if the default behavior is as I said we should do that at
> Dmitry> least by default.
>
> With an option to toggle from icon->icon+text? Sounds good to me
> (although I haven't found yet why weʼre only showing text for some of
> the icons under gtk).
I think we still need to understand why sometimes the text is too
large, because the tool bar is not supposed to change its height.
Does someone know what determines the size of the font used for these
text labels?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sat, 27 Feb 2021 04:14:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 46773 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> FWIW, I can't reproduce the scenario in the report here, possibly
> because my text height is smaller than the icons, and Lars has it the
> opposite. High scale factor? GTK2 build?
High scale factor.
The icons aren't scaled up, so they look rather awkward on HiDPI
screens.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sat, 27 Feb 2021 07:36:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, Robert Pluim <rpluim <at> gmail.com>,
> 46773 <at> debbugs.gnu.org
> Date: Sat, 27 Feb 2021 05:13:13 +0100
>
> Dmitry Gutov <dgutov <at> yandex.ru> writes:
>
> > FWIW, I can't reproduce the scenario in the report here, possibly
> > because my text height is smaller than the icons, and Lars has it the
> > opposite. High scale factor? GTK2 build?
>
> High scale factor.
>
> The icons aren't scaled up, so they look rather awkward on HiDPI
> screens.
So I guess until we teach Emacs to scale the icons, a user option to
disable the text labels should be a stopgap?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sat, 27 Feb 2021 11:53:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 46773 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> So I guess until we teach Emacs to scale the icons, a user option to
> disable the text labels should be a stopgap?
Or... see what the height of the default font is and use that as a
minimum height? (I haven't actually looked at the code to see whether
there's a way to specify a min height.)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sat, 27 Feb 2021 12:58:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: dgutov <at> yandex.ru, rpluim <at> gmail.com, 46773 <at> debbugs.gnu.org
> Date: Sat, 27 Feb 2021 12:52:17 +0100
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > So I guess until we teach Emacs to scale the icons, a user option to
> > disable the text labels should be a stopgap?
>
> Or... see what the height of the default font is and use that as a
> minimum height?
If we can do that, yes. I assumed that the font used by the GTK tool
bar is not our default font, is it? If it isn't, how can we know its
size?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sat, 27 Feb 2021 14:21:01 GMT)
Full text and
rfc822 format available.
Message #53 received at 46773 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> If we can do that, yes. I assumed that the font used by the GTK tool
> bar is not our default font, is it? If it isn't, how can we know its
> size?
Oh, yeah, I'd forgotten that we leave all that to the toolkit. So
that's no good. We could use heuristics -- that is, look at the default
font size and try to size up the min height based on that. Not very
satisfactory, though.
This reminds me of bug#40978, which is about scaling images in toolbars
and the like based on the same heuristics as we do for in-buffer images
-- I was somewhat leery about going down that path because the
repercussions seem unpredictable, but that would probably have fixed
what I'm seeing in this bug report...
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sat, 27 Feb 2021 16:42:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 46773 <at> debbugs.gnu.org (full text, mbox):
On 27.02.2021 06:13, Lars Ingebrigtsen wrote:
>> FWIW, I can't reproduce the scenario in the report here, possibly
>> because my text height is smaller than the icons, and Lars has it the
>> opposite. High scale factor? GTK2 build?
> High scale factor.
>
> The icons aren't scaled up, so they look rather awkward on HiDPI
> screens.
Is that with a GTK2 build, then?
My scale factor is 2x, and icons are scaled proportionally on GTK3.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sun, 28 Feb 2021 18:22:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 46773 <at> debbugs.gnu.org (full text, mbox):
> From: Lars Ingebrigtsen <larsi <at> gnus.org>
> Cc: 46773 <at> debbugs.gnu.org, rpluim <at> gmail.com, dgutov <at> yandex.ru
> Date: Sun, 28 Feb 2021 14:36:03 +0100
>
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
> > This reminds me of bug#40978, which is about scaling images in toolbars
> > and the like based on the same heuristics as we do for in-buffer images
> > -- I was somewhat leery about going down that path because the
> > repercussions seem unpredictable, but that would probably have fixed
> > what I'm seeing in this bug report...
>
> Or... looking at that again, that's probably a completely separate
> issue, because the toolbar icons probably don't go though the Emacs
> image code at all, but all that stuff is left up to the toolkit, which
> is GTK3 in my instance? (I'm looking at gtkutil.c...)
Yes, I think you are right.
So why does it work fore Dmitry?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sun, 28 Feb 2021 19:41:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 46773 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> From: Lars Ingebrigtsen <larsi <at> gnus.org> Cc:
>> 46773 <at> debbugs.gnu.org, rpluim <at> gmail.com, dgutov <at> yandex.ru Date:
>> Sun, 28 Feb 2021 14:36:03 +0100
>>
>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>>
>> > This reminds me of bug#40978, which is about scaling images in
>> toolbars > and the like based on the same heuristics as we do for
>> in-buffer images > -- I was somewhat leery about going down that
>> path because the > repercussions seem unpredictable, but that
>> would probably have fixed > what I'm seeing in this bug report...
>>
>> Or... looking at that again, that's probably a completely
>> separate issue, because the toolbar icons probably don't go
>> though the Emacs image code at all, but all that stuff is left up
>> to the toolkit, which is GTK3 in my instance? (I'm looking at
>> gtkutil.c...)
> Yes, I think you are right.
> So why does it work fore Dmitry?
Is this what's happening here? If you compile emacs-28 with tookit=lucid
and separately with the default (tookit=gtk3) and compare the two emacs
-q --geometry 83X37 you get different sizes. The gtk3 emacs is slightly
taller than the lucid version. I attach a screen shot. On the right is
lucid and on the left is gtk3. The tool bars are of slightly different
height.
I apologise if my intervention is a irrelevant.
Best wishes,
[lucid-right-gtk3-left.png (image/png, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sun, 28 Feb 2021 22:07:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 46773 <at> debbugs.gnu.org (full text, mbox):
On 28.02.2021 15:31, Lars Ingebrigtsen wrote:
> My Emacs says:
>
> In GNU Emacs 28.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.24, cairo version 1.16.0)
>
> So that's GTK3, I guess?
Seems so. (string-match-p "GTK3" system-configuration-features) should
tell more reliably, though.
Perhaps you icon theme doesn't provide scaled versions of the icons
(mine includes .svg files for scaling) and GTK decided that it shouldn't
scale the icons because of that.
Just guessing, though. I tried a bunch of icons themes already installed
on my machine and couldn't repro, but they probably all do provide
scaled versions of the respective icons.
And my GTK version is 3.24.20. Same Cairo version.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sun, 28 Feb 2021 22:20:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 46773 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Seems so. (string-match-p "GTK3" system-configuration-features) should
> tell more reliably, though.
(string-match-p "GTK3" system-configuration-features)
=> 225
> Perhaps you icon theme doesn't provide scaled versions of the icons
> (mine includes .svg files for scaling) and GTK decided that it
> shouldn't scale the icons because of that.
>
> Just guessing, though. I tried a bunch of icons themes already
> installed on my machine and couldn't repro, but they probably all do
> provide scaled versions of the respective icons.
>
> And my GTK version is 3.24.20. Same Cairo version.
My toolbar looks totally different from all the other screenshots,
though. I mean:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
I'm using a dark mode, but is that (and the lack of scaling of the
icons) the only difference?
Is it possible that Gnome Shell (or something) is somehow interfering
here and substituting other icons?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Sun, 28 Feb 2021 22:32:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 46773 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Is it possible that Gnome Shell (or something) is somehow interfering
> here and substituting other icons?
D'oh!
All this is just user error on my part. I had changed the font scaling
in gnome-tweaks to x2.7, and not done any proper scaling.
Now, with a 200% scaling (and a x1.3 font scaling), I get:
[Message part 2 (image/png, inline)]
[Message part 3 (text/plain, inline)]
Which is more reasonable, and the toolbar no longer changes height.
So I don't think there's anything to fix here, and I'm closing this bug
report.
Sorry for the noise.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) notabug.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 28 Feb 2021 22:32:02 GMT)
Full text and
rfc822 format available.
bug closed, send any further explanations to
46773 <at> debbugs.gnu.org and Lars Ingebrigtsen <larsi <at> gnus.org>
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org.
(Sun, 28 Feb 2021 22:32:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Mon, 01 Mar 2021 12:40:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 46773 <at> debbugs.gnu.org (full text, mbox):
Colin Baxter <m43cap <at> yandex.com> writes:
> Is this what's happening here? If you compile emacs-28 with tookit=lucid
> and separately with the default (tookit=gtk3) and compare the two emacs
> -q --geometry 83X37 you get different sizes. The gtk3 emacs is slightly
> taller than the lucid version. I attach a screen shot. On the right is
> lucid and on the left is gtk3. The tool bars are of slightly different
> height.
My problem was apparently me having set the scaling for the fonts only
in Gnome Shell, and not the "overall" scaling, which also scales icons.
What you're seeing is pretty normal, I think -- different toolkits will
result in (slightly) different Emacs window sizes.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#46773; Package
emacs.
(Mon, 01 Mar 2021 15:19:02 GMT)
Full text and
rfc822 format available.
Message #81 received at 46773 <at> debbugs.gnu.org (full text, mbox):
>>>>> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> Colin Baxter <m43cap <at> yandex.com> writes:
>> Is this what's happening here? If you compile emacs-28 with
>> tookit=lucid and separately with the default (tookit=gtk3) and
>> compare the two emacs -q --geometry 83X37 you get different
>> sizes. The gtk3 emacs is slightly taller than the lucid
>> version. I attach a screen shot. On the right is lucid and on the
>> left is gtk3. The tool bars are of slightly different height.
> My problem was apparently me having set the scaling for the fonts
> only in Gnome Shell, and not the "overall" scaling, which also
> scales icons.
> What you're seeing is pretty normal, I think -- different toolkits
> will result in (slightly) different Emacs window sizes.
Ok, thanks.
Best wishes,
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Tue, 30 Mar 2021 11:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 140 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.