GNU bug report logs -
#23847
24.5; dired icon too large
Previous Next
To reply to this bug, email your comments to 23847 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Sat, 25 Jun 2016 17:09:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
sanette-linux <sanette-linux <at> laposte.net>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 25 Jun 2016 17:09:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi
When starting emacs in a graphical ubuntu 16.04 session, the "dired"
icon in the toolbar is much larger than the other ones, making the
result quite ugly.
It might be related to the fact that I have a hi-dpi display and set
scale=2 in the unity Display setting. However, other icons in the
toolbar have the right size, therefore there surely is something wrong.
In GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
of 2016-04-17 on lgw01-04, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11803000
System Description: Ubuntu 16.04 LTS
Configured using:
`configure --build x86_64-linux-gnu --prefix=/usr
--sharedstatedir=/var/lib --libexecdir=/usr/lib
--localstatedir=/var/lib --infodir=/usr/share/info
--mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
--build x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
--libexecdir=/usr/lib --localstatedir=/var/lib
--infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes
--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.5/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.5/site-lisp:/usr/share/emacs/site-lisp
--with-x=yes --with-x-toolkit=gtk3 --with-toolkit-scroll-bars
'CFLAGS=-g -O2 -fstack-protector-strong -Wformat
-Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
-D_FORTIFY_SOURCE=2' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro''
Important settings:
value of $LANG: fr_FR.UTF-8
value of $XMODIFIERS: @im=ibus
locale-coding-system: utf-8-unix
Major mode: Python
Minor modes in effect:
shell-dirtrack-mode: t
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
Mark set [6 times]
Mark saved where search started
Saving file /media/san/linux/5 min
Lebesgue/2016-06-21_Christophe/titre.py...
Wrote /media/san/linux/5 min Lebesgue/2016-06-21_Christophe/titre.py
<f5> is undefined
Making completion list...
No match
<backtab> is undefined [2 times]
No match
<backtab> is undefined [2 times]
Load-path shadows:
/usr/share/emacs/24.5/site-lisp/debian-startup hides
/usr/share/emacs/site-lisp/debian-startup
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils term disp-table ehelp shell pcomplete
help-mode misearch multi-isearch python easymenu json comint ring
cl-loaddefs cl-lib ansi-color time-date tooltip electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)
Memory information:
((conses 16 94205 9952)
(symbols 48 19284 0)
(miscs 40 87 339)
(strings 32 14730 3963)
(string-bytes 1 432803)
(vectors 16 11398)
(vector-slots 8 405884 5042)
(floats 8 68 675)
(intervals 56 1622 16)
(buffers 960 15)
(heap 1024 41824 889))
Merged 21659 23847.
Request was from
Glenn Morris <rgm <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Mon, 27 Jun 2016 15:58:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Mon, 27 Jun 2016 16:08:02 GMT)
Full text and
rfc822 format available.
Message #10 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Thanks, this sounds like http://debbugs.gnu.org/21659 .
According to that report, the solution is to delete
("etc/images/diropen" . "n:system-file-manager")
from x-gtk-stock-map in x-win.el.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Mon, 27 Jun 2016 17:09:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Glenn Morris wrote:
> Thanks, this sounds like http://debbugs.gnu.org/21659 .
> According to that report, the solution is to delete
>
> ("etc/images/diropen" . "n:system-file-manager")
>
> from x-gtk-stock-map in x-win.el.
But that would leave that icon unthemed and looking weird for every Gtk user.
I guess the right solution is to find whatever stock Gtk item best maps
to dired and use that instead of the current application icon.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Mon, 27 Jun 2016 20:01:01 GMT)
Full text and
rfc822 format available.
Message #16 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Actually looking at
https://developer.gnome.org/icon-naming-spec/
there does not seem to be anything better to use.
So maybe Emacs needs to explicitly set the size for Gtk svg icons?
I don't know.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Tue, 09 Aug 2016 10:06:01 GMT)
Full text and
rfc822 format available.
Message #19 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Le 27/06/2016 à 19:07, Glenn Morris a écrit :
> Glenn Morris wrote:
>
>> Thanks, this sounds like http://debbugs.gnu.org/21659 .
>> According to that report, the solution is to delete
>>
>> ("etc/images/diropen" . "n:system-file-manager")
>>
>> from x-gtk-stock-map in x-win.el.
> But that would leave that icon unthemed and looking weird for every Gtk user.
> I guess the right solution is to find whatever stock Gtk item best maps
> to dired and use that instead of the current application icon.
I'm sorry I didn't have access to the laptop recently. Now I have tested
this, and indeed it works.
thanks a lot.
I agree that the unthemed icon is not very nice and looks weird, but for
me this is still better than
the too large one.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Tue, 09 Aug 2016 10:16:01 GMT)
Full text and
rfc822 format available.
Message #22 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Le 27/06/2016 à 21:59, Glenn Morris a écrit :
> Actually looking at https://developer.gnome.org/icon-naming-spec/
> there does not seem to be anything better to use. So maybe Emacs needs
> to explicitly set the size for Gtk svg icons? I don't know.
by the way I have an aside (newbie) question:
when I customize the variable
x-gtk-stock-map
in my .emacs, it works, but if I try to modify directly x-win.el, it has
no effect.
(this is in /usr/share/emacs/24.5/lisp/term, I gunzip x-win.el.gz,
modify it, then byte-compile it)
what did I miss ?
thx
S.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Tue, 09 Aug 2016 12:02:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Le 27/06/2016 à 21:59, Glenn Morris a écrit :
> Actually looking at
> https://developer.gnome.org/icon-naming-spec/
> there does not seem to be anything better to use.
> So maybe Emacs needs to explicitly set the size for Gtk svg icons?
> I don't know.
I should also mention that the problem is present for ubuntu 16.04 with
GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9)
but *not* for ubuntu 14.04 with GNU Emacs 24.3.1 (x86_64-pc-linux-gnu,
GTK+ Version 3.10.7)
In the latter case, the correct nautilus icon shows up with the right size.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Tue, 09 Aug 2016 17:21:01 GMT)
Full text and
rfc822 format available.
Message #28 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Le 27/06/2016 à 21:59, Glenn Morris a écrit :
> Actually looking at
> https://developer.gnome.org/icon-naming-spec/
> there does not seem to be anything better to use.
> So maybe Emacs needs to explicitly set the size for Gtk svg icons?
> I don't know.
additional information: this is indeed related to the scale=2 setting
in the gnome display setting: if I set scale=1, then the opendir icon
has the right size (meaning the same size as the other icons, which are
of course very tiny for me with the setting scale=1)
So, for some reason when scale=2, the icon sizes are multiplied by 2
(this is normal behaviour) except for the opendir icon which is
multiplied by 4.
Maybe this means that scale is applied twice for this "named" icon ?
Just a guess.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Tue, 02 Jun 2020 15:03:01 GMT)
Full text and
rfc822 format available.
Message #31 received at 23847 <at> debbugs.gnu.org (full text, mbox):
It seems that "n:system-file-manager" is not the only problem
icon in the emacs toolbar. I faced the problem with the Breeze
KDE theme and emacs-25.2 in Ubuntu-18.04.
Is there a particular reason of the choice for the help icon
that appears e.g. for customize mode?
- ("etc/images/help" . ("help-browser" "gtk-help"))
Would not it better to use "n:help-contents" for help? Unlike
"help-browser" that comes from apps, "help-contents" belongs to the
Actions category, so its style is uniform with other toolbar icons.
Unfortunately I could not suggest an equivalent for "diropen", e.g.
"n:folder-new" could be misleading.
Maybe I have missed something but it looks like as a quite sour story.
KDE developers believes that the problem should be fixed in emacs, see
https://bugs.kde.org/show_bug.cgi?id=353496
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=21659
I am not familiar with Gtk so I am unaware if it is possible to adjust
breeze gtk theme to override compiled-in icon size (22px as default in
KDE theme vs. 24px used by Gtk).
I am really puzzled by the following statement, I could not get where
related user preferences could be set:
https://developer.gnome.org/gtk3/stable/GtkToolbar.html#gtk-toolbar-set-icon-size
> gtk_toolbar_set_icon_size ()
> ...
> This should only be used for special-purpose toolbars,
> normal application toolbars should respect
> the user preferences for the size of icons.
Preferences in settings.ini are ignored, see
https://developer.gnome.org/gtk3/stable/GtkSettings.html#GtkSettings--gtk-icon-sizes
Likely it is impossible to override GtkToolbar icon-size though theme
CSS as well.
Obviously KDE-specific hints in index.theme are not taken
into account by Gtk
ToolbarDefault=22
ToolbarSizes=16,22,32,48
It looks like that it is completely up to the particular application if
icon sizes other than compiled-in defaults should be used. I would
expect some high-level API in Gtk that ensures reasonable icon
sizes across displays of various sizes with minimal efforts of
developers of an application but from the first glance I have not
noticed any traces of code that runs behind the scene ensuring
meaningful defaults. Maybe there is no simple way to properly handle
screens with significantly different resolution connected to the same
box, so such work must be done in every application.
Other application experienced similar problems as well, e.g. inkscape
and gparted. They were solved by adding dedicated icons, adjusting
Breeze theme to allow scaling of icons in some directories, or by
modifying application code to force desired size through explicit scaling.
I do not know if using of gtk_icon_theme_load_icon()
with GTK_ICON_LOOKUP_FORCE_SIZE is a viable approach for emacs.
Are there any objections against "help-contents" icon for help?
P.S. GtkToolbar has been removed from the Gtk master branch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Tue, 08 Feb 2022 06:51:01 GMT)
Full text and
rfc822 format available.
Message #34 received at 23847 <at> debbugs.gnu.org (full text, mbox):
sanette-linux <sanette-linux <at> laposte.net> writes:
> When starting emacs in a graphical ubuntu 16.04 session, the "dired"
> icon in the toolbar is much larger than the other ones, making the
> result quite ugly.
> It might be related to the fact that I have a hi-dpi display and set
> scale=2 in the unity Display setting. However, other icons in the
> toolbar have the right size, therefore there surely is something wrong.
(I'm going through old bug reports that unfortunately weren't resolved
at the time.)
I'm unable to reproduce this on a HiDPI display with Gnome Shell with
the current Emacs. Are you still seeing this issue in recent Emacs
versions?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Added tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Tue, 08 Feb 2022 06:51:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Thu, 10 Feb 2022 10:31:02 GMT)
Full text and
rfc822 format available.
Message #39 received at 23847 <at> debbugs.gnu.org (full text, mbox):
On 08/02/2022 13:50, Lars Ingebrigtsen wrote:
> sanette-linux writes:
>
>> When starting emacs in a graphical ubuntu 16.04 session, the "dired"
>> icon in the toolbar is much larger than the other ones, making the
>> result quite ugly.
>> It might be related to the fact that I have a hi-dpi display and set
>> scale=2 in the unity Display setting. However, other icons in the
>> toolbar have the right size, therefore there surely is something wrong.
>
> (I'm going through old bug reports that unfortunately weren't resolved
> at the time.)
>
> I'm unable to reproduce this on a HiDPI display with Gnome Shell with
> the current Emacs. Are you still seeing this issue in recent Emacs
> versions?
Lars, thank you for grooming the bug tracker.
I faced this bug as unrelated to HiDPI display and namely in KDE. Help
and open folder toolbar icons have normal sizes in Gnome.
I do not have a VM with latest KDE plasma and Emacs, but I had to add
the following to my init file on Ubuntu-20.04 focal (latest long time
support release) with Emacs-26.3:
'(icon-map-list
(quote
((("etc/images/diropen" . "n:folder-new")
("etc/images/help" . "help-contents"))
x-gtk-stock-map)))
Warning: do not try to to create such structure from easy customization
UI. Alist pairs will not be wrapped in a list, invalid values will not
be e.g. rejected by setter and you will get semi-broken emacs spitting
icon-related errors on attempts of various actions.
The problem is that KDE does not provide these non-standard icons in
sizes suitable for toolbar, Gtk takes larger versions while other icons
have normal size.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Thu, 10 Feb 2022 11:47:01 GMT)
Full text and
rfc822 format available.
Message #42 received at 23847 <at> debbugs.gnu.org (full text, mbox):
Maxim Nikulin <m.a.nikulin <at> gmail.com> writes:
> I faced this bug as unrelated to HiDPI display and namely in KDE. Help
> and open folder toolbar icons have normal sizes in Gnome.
>
> I do not have a VM with latest KDE plasma and Emacs, but I had to add
> the following to my init file on Ubuntu-20.04 focal (latest long time
> support release) with Emacs-26.3:
>
> '(icon-map-list
> (quote
> ((("etc/images/diropen" . "n:folder-new")
> ("etc/images/help" . "help-contents"))
> x-gtk-stock-map)))
Thanks. I don't have a KDE setup here, so I can't really test easily.
Hopefully somebody else with KDE can debug this further.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Thu, 10 Feb 2022 14:31:02 GMT)
Full text and
rfc822 format available.
Message #45 received at 23847 <at> debbugs.gnu.org (full text, mbox):
On 10/02/2022 18:46, Lars Ingebrigtsen wrote:
> Maxim Nikulin writes:
>
> Thanks. I don't have a KDE setup here, so I can't really test easily.
> Hopefully somebody else with KDE can debug this further.
Lars, what do you mean by "debug this further"?
breeze-icon-theme version 4:5.68.0-0ubuntu1 and other KDE themes does
not have 24x24 system-file-manager icon, so a larger one is used. E.g.
adwaita theme has an icon with such size so Gnome does have such
problem. Emacs uses icons from "applications" category for "actions"
buttons. I just can not easily confirm the problem for latest versions
of KDE and Emacs.
/usr/share/icons/Adwaita/16x16/legacy/system-file-manager.png
/usr/share/icons/Adwaita/22x22/legacy/system-file-manager.png
/usr/share/icons/Adwaita/24x24/legacy/system-file-manager.png
/usr/share/icons/Adwaita/256x256/legacy/system-file-manager.png
/usr/share/icons/Adwaita/32x32/legacy/system-file-manager.png
/usr/share/icons/Adwaita/48x48/legacy/system-file-manager.png
/usr/share/icons/breeze/apps/16/system-file-manager.svg
/usr/share/icons/breeze/apps/22/system-file-manager.svg
/usr/share/icons/breeze/apps/32/system-file-manager.svg
/usr/share/icons/breeze/apps/48/system-file-manager.svg
/usr/share/icons/breeze/apps/64/system-file-manager.svg
See my older comment:
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=23847#31
P.S. Lars, sorry, at first I sent this message just to you instead of to
the bug tracker.
Removed tag(s) moreinfo.
Request was from
Lars Ingebrigtsen <larsi <at> gnus.org>
to
control <at> debbugs.gnu.org
.
(Sat, 12 Mar 2022 22:46:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#23847
; Package
emacs
.
(Fri, 11 Aug 2023 04:14:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 23847 <at> debbugs.gnu.org (full text, mbox):
On 10/02/2022 18:46, Lars Ingebrigtsen wrote:
> Maxim Nikulin writes:
>>
>> '(icon-map-list
>> (quote
>> ((("etc/images/diropen" . "n:folder-new")
>> ("etc/images/help" . "help-contents"))
>> x-gtk-stock-map)))
>
> Thanks. I don't have a KDE setup here, so I can't really test easily.
> Hopefully somebody else with KDE can debug this further.
- Debian 12 bookworm
- plasma-desktop 5.27.5-2
- emacs 28.2+1-15
The system-file-manager icon is rendered with reasonable size.
The help-browser icon, that appears e.g. in easy customization
interface, is still too large.
dpkg -S help-browser.svg
breeze-icon-theme: /usr/share/icons/breeze/apps/48/help-browser.svg
breeze-icon-theme: /usr/share/icons/breeze-dark/apps/48/help-browser.svg
Notice that no icons appears at all in Emacs, just text is shown with
default "Main toolbar label: besides icons". Icons with not text appears
in Emacs when it is changed to "below icon". (System settings /
Appearance / Global Theme / Application Style / Configure Icons and
Toolbars)
~/.config/gtk-3.0/settings.ini
gtk-toolbar-style=2
vs. default
gtk-toolbar-style=3
In Kubuntu-20.04 I have
gtk-toolbar-style=GTK_TOOLBAR_BOTH_HORIZ
and icon+text on the same line are rendered, but it is unrelated to the
excessively large help icon, it is a hint for those who do not see icons
at all.
This bug report was last modified 1 year and 319 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.