unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Jim Porter <jporterbugs@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefan@marxist.se>
Cc: 51556@debbugs.gnu.org, kevin.legouguec@gmail.com
Subject: bug#51556: 29.0.50; Poor contrast of Customize SVG icons with dark backgrounds
Date: Tue, 2 Nov 2021 11:43:58 -0700	[thread overview]
Message-ID: <18066bc0-86a6-5901-9a53-e2c6ea13fbc8@gmail.com> (raw)
In-Reply-To: <83a6imjv2o.fsf@gnu.org>

On 11/2/2021 11:01 AM, Eli Zaretskii wrote:
> If the solution you propose only works for SVG that specify no
> foreground, then it won't be able to solve all of the situations where
> a different theme makes an icon barely visible or unpleasant to the
> eye.  Which is why I think a better solution would be to allow themes
> to specify different icons where necessary.

I think it might help to break this problem down into parts. There are a 
few cases I can think of where the question of how to color an SVG might 
come up:

1) Single-color SVGs

Some SVGs are just a single-color shape, like the Customize arrows. 
There's no *particular* color that's right for these, aside from "what 
looks good". In some ways, these SVGs are like an ordinary textual 
glyph, except that we've defined our own fancy shape to use. In this 
case, I think it makes sense to be able to specify what color to use for 
the SVG independently of the shape so that themes can adjust it as-needed.

This case is the one initially described in this bug.

2) Multi-color SVGs

Some SVGs have many colors. There's a particular set of colors that 
makes sense for this SVG, as defined in the file by the author. It would 
be difficult to programmatically alter the colors of such an SVG and 
maintain a good result, so we probably shouldn't try. This is a case 
where it may be nice to let themes specify a completely-different SVG to 
use.

I'd consider this lower priority, since I'm not aware of a specific SVG 
in this category that's causing visual issues with themes.

3) Dynamically-colored SVGs

This could be considered a variant of (1). Sometimes, we might want to 
define a particular shape, but give it different colors in different 
contexts. For example, if we wanted to use SVGs to display something 
similar to the circles in the fringe that mark GDB breakpoints, we could 
have a single breakpoint.svg file that we color bright red or gray 
depending on the breakpoint's state.

This is another case where it would be convenient to be able to set an 
SVG's color independently of its shape.

4) Third-party packages

Some packages might want to provide SVG icons to use in one way or 
another, along the same lines as the Customize arrows (i.e. a 
single-color SVG). If you're the author of a little-known package, you 
can't really expect theme authors to provide customized icons for your 
package that fit with the theme. However, themes *do* specify at least a 
handful of faces. As a package author, it would be convenient to be able 
to say "render this icon using the foreground color of the `error' 
face", for example. Then your package looks good with most themes 
without requiring anyone to provide custom SVGs.





  parent reply	other threads:[~2021-11-02 18:43 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-01 17:56 bug#51556: 29.0.50; Poor contrast of Customize SVG icons with dark backgrounds Kévin Le Gouguec
2021-11-01 19:14 ` Eli Zaretskii
2021-11-01 20:10   ` Kévin Le Gouguec
2021-11-02 12:40     ` Eli Zaretskii
2021-11-01 20:49   ` Jim Porter
2021-11-02 12:49     ` Eli Zaretskii
2021-11-02 14:41       ` Stefan Kangas
2021-11-02 14:59         ` Eli Zaretskii
2021-11-02 15:17           ` Stefan Kangas
2021-11-02 15:26             ` Stefan Kangas
2021-11-02 16:38               ` Eli Zaretskii
2021-11-02 16:43                 ` Lars Ingebrigtsen
2021-11-02 17:01                 ` Stefan Kangas
2021-11-02 17:13                   ` Eli Zaretskii
2021-11-02 17:44                     ` Stefan Kangas
2021-11-02 18:01                       ` Eli Zaretskii
2021-11-02 18:43                         ` Stefan Kangas
2021-11-02 18:53                           ` Eli Zaretskii
2021-11-02 19:26                             ` Stefan Kangas
2021-11-02 18:43                         ` Jim Porter [this message]
2021-11-02 18:58                           ` Stefan Kangas
2021-11-02 19:15                             ` Eli Zaretskii
2021-11-02 19:44                               ` Stefan Kangas
2021-11-02 20:19                           ` Alan Third
2021-11-02 22:56                             ` Kévin Le Gouguec
2021-11-04  8:11                             ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=18066bc0-86a6-5901-9a53-e2c6ea13fbc8@gmail.com \
    --to=jporterbugs@gmail.com \
    --cc=51556@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=kevin.legouguec@gmail.com \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).