Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> branch: scratch/icons
> commit 09509f4fa1b1a749c767f760c5bb9e0080e303d2
> Author: Stefan Kangas <stefan@marxist.se>
> Commit: Stefan Kangas <stefankangas@gmail.com>
>
>     Import Material design icons
>     
>     * lisp/icons-material.el:
>     * etc/images/material/**/*.svg: New files.

Are there any license problems with those icons?

Further more, shouldn't we make PBM versions of those icons, in case
librsvg is not available?  And preferably use a variant that has colors,
to make it easier to tell them apart from each other?

Thanks.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

>>     Import Material design icons
>>
>>     * lisp/icons-material.el:
>>     * etc/images/material/**/*.svg: New files.
>
> Are there any license problems with those icons?

Not that I'm aware of, no.  They are licensed under the GPL compatible
Apache License Version 2.0.

See these files on the branch for more:
    etc/images/material/README
    etc/images/material/LICENSE

> Further more, shouldn't we make PBM versions of those icons, in case
> librsvg is not available?

There should be some kind of fallback for when SVG is not available,
yes.  I'm not yet sure exactly what that will look like.  The problem
with generating PBM versions AFAIK is that they don't scale, so maybe
we'd want to prefer Unicode symbols in those cases (or even emojis,
though I'm not exactly a huge fan).

> And preferably use a variant that has colors, to make it easier to
> tell them apart from each other?

We don't need to have any different variants: the svg icons will use
whatever foreground/background the current face has.

Thanks for your feedback.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> There should be some kind of fallback for when SVG is not available,
> yes.  I'm not yet sure exactly what that will look like.  The problem
> with generating PBM versions AFAIK is that they don't scale, so maybe
> we'd want to prefer Unicode symbols in those cases (or even emojis,
> though I'm not exactly a huge fan).

We cannot put symbols in the tool bar, AFAIK.  (And what if no such
Unicode font exists, which is the situation under the xfont backend and
Windows 9X for most Unicode Emoji?)

I think relying on the normal, primitive, scaling is fine, should SVG
support not be available.  Modern systems that can display the Unicode
symbols will also be able to run librsvg.

> We don't need to have any different variants: the svg icons will use
> whatever foreground/background the current face has.

No, what I meant was to provide icons that have contrasting colors.
This makes the icons easier to visually identify.  For an example of
this, see how spell.xpm has a green checkmark put up against black text,
which makes it easier to spot in the toolbar than similar icons in an
Android program that uses single-color icons.

Thanks.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Wed, 24 Aug 2022 18:40:53 +0800
> 
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
> > There should be some kind of fallback for when SVG is not available,
> > yes.  I'm not yet sure exactly what that will look like.  The problem
> > with generating PBM versions AFAIK is that they don't scale, so maybe
> > we'd want to prefer Unicode symbols in those cases (or even emojis,
> > though I'm not exactly a huge fan).
> 
> We cannot put symbols in the tool bar, AFAIK.

If that's the tool bar displayed by Emacs (nit by the toolkit), then
yes, we can.  The Emacs tool bar is just a special kind of window,
which displays a Lisp string instead of text of some buffer.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> If that's the tool bar displayed by Emacs (nit by the toolkit), then
> yes, we can.  The Emacs tool bar is just a special kind of window,
> which displays a Lisp string instead of text of some buffer.

Right, but that text is a label which isn't displayed everywhere, most
notably under NS toolkit tooltips.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Lars Ingebrigtsen]

Po Lu <luangruo@yahoo.com> writes:

>> If that's the tool bar displayed by Emacs (nit by the toolkit), then
>> yes, we can.  The Emacs tool bar is just a special kind of window,
>> which displays a Lisp string instead of text of some buffer.
>
> Right, but that text is a label which isn't displayed everywhere, most
> notably under NS toolkit tooltips.

But we're talking about non-toolkit displays here, so we can do what we
want.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Po Lu]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> But we're talking about non-toolkit displays here, so we can do what we
> want.

Aren't we supposed to use the new icons on all tool bars, aside from
GTK, where we use GTK's own icons?

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> Aren't we supposed to use the new icons on all tool bars, aside from
> GTK, where we use GTK's own icons?

The branch I pushed uses them on all tool bars, including GTK.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 24 Aug 2022 20:05:37 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If that's the tool bar displayed by Emacs (nit by the toolkit), then
> > yes, we can.  The Emacs tool bar is just a special kind of window,
> > which displays a Lisp string instead of text of some buffer.
> 
> Right, but that text is a label

What do you mean by "label"?

> which isn't displayed everywhere, most notably under NS toolkit
> tooltips.

If Emacs uses a tool bar provided by some toolkit, then what I said is
not relevant: Emacs doesn't display its own tool bar in those builds.

But how are tooltips relevant to this?

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> What do you mean by "label"?

It's displayed next to any image, leading to a gaping hole if the image
is actually not present, on the GTK build(s).

> If Emacs uses a tool bar provided by some toolkit, then what I said is
> not relevant: Emacs doesn't display its own tool bar in those builds.

We're discussing icons that will be used under both tookit tool bars and
native tool bars.

> But how are tooltips relevant to this?

I meant "toolbars", sorry.

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Stefan Monnier]

>> Further more, shouldn't we make PBM versions of those icons, in case
>> librsvg is not available?
>
> There should be some kind of fallback for when SVG is not available,
> yes.  I'm not yet sure exactly what that will look like.  The problem
> with generating PBM versions AFAIK is that they don't scale, so maybe
> we'd want to prefer Unicode symbols in those cases (or even emojis,
> though I'm not exactly a huge fan).

Wherever possible we should fallback on the tty behavior if there's only
an SVG version of the icon and we don't have an SVG renderer.


        Stefan

Re: scratch/icons 09509f4fa1 05/11: Import Material design icons

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Po Lu <luangruo@yahoo.com>,  emacs-devel@gnu.org
> Date: Wed, 24 Aug 2022 08:09:34 -0400
> 
> >> Further more, shouldn't we make PBM versions of those icons, in case
> >> librsvg is not available?
> >
> > There should be some kind of fallback for when SVG is not available,
> > yes.  I'm not yet sure exactly what that will look like.  The problem
> > with generating PBM versions AFAIK is that they don't scale, so maybe
> > we'd want to prefer Unicode symbols in those cases (or even emojis,
> > though I'm not exactly a huge fan).
> 
> Wherever possible we should fallback on the tty behavior if there's only
> an SVG version of the icon and we don't have an SVG renderer.

Between SVG and TTY there's XPM, and it would be silly on our part to
ignore that.

Re: scratch/icons 67251e79f7 09/11: Use material icons in mpc toolbar

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

>  etc/images/mpc/README     |   6 ------
>  etc/images/mpc/add.pbm    | Bin 81 -> 0 bytes
>  etc/images/mpc/add.xpm    |  31 -------------------------------
>  etc/images/mpc/ffwd.pbm   | Bin 81 -> 0 bytes
>  etc/images/mpc/ffwd.xpm   |  33 ---------------------------------
>  etc/images/mpc/next.pbm   | Bin 81 -> 0 bytes
>  etc/images/mpc/next.xpm   |  33 ---------------------------------
>  etc/images/mpc/pause.pbm  | Bin 81 -> 0 bytes
>  etc/images/mpc/pause.xpm  |  32 --------------------------------
>  etc/images/mpc/play.pbm   | Bin 81 -> 0 bytes
>  etc/images/mpc/play.xpm   |  33 ---------------------------------
>  etc/images/mpc/prev.pbm   | Bin 81 -> 0 bytes
>  etc/images/mpc/prev.xpm   |  32 --------------------------------
>  etc/images/mpc/rewind.pbm | Bin 81 -> 0 bytes
>  etc/images/mpc/rewind.xpm |  32 --------------------------------
>  etc/images/mpc/stop.pbm   | Bin 81 -> 0 bytes
>  etc/images/mpc/stop.xpm   |  32 --------------------------------

I object to removing the existing icons, when no XPM and PBM
replacements are provided.

Especially PBM icons, since it's the only non-SVG format image.c can
manually specify the foreground and background for.

Re: scratch/icons 67251e79f7 09/11: Use material icons in mpc toolbar

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> I object to removing the existing icons, when no XPM and PBM
> replacements are provided.

Thanks, I think this is a valid point.

We should consider leaving these images to use as fallbacks, but that
will also depend on what kind of fallbacks we want to provide more
generally.  Please see my other reply for more details on that.

Re: scratch/icons 4de626ea22 08/11: Support using icons.el in toolbar

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

>      `(find-image (cond ((not (display-color-p))
> -			',(list pbm-spec xbm-spec xpm-lo-spec xpm-spec))
> +                        ',(list svg-spec pbm-spec xbm-spec xpm-lo-spec xpm-spec))
>  		       ((< (display-color-cells) 256)
> -			',(list xpm-lo-spec xpm-spec pbm-spec xbm-spec))
> +                        ',(list svg-spec xpm-lo-spec xpm-spec pbm-spec xbm-spec))

Non-color displays and displays whose visual class is not TrueColor
cannot display SVG images.  The svg code just doesn't work.

So SVG should only be enabled in the case that (display-visual-class) is
true-color.

Re: scratch/icons 4de626ea22 08/11: Support using icons.el in toolbar

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> So SVG should only be enabled in the case that (display-visual-class) is
> true-color.

Thanks, that's good to know.  I'll change this accordingly.

Re: scratch/icons 4de626ea22 08/11: Support using icons.el in toolbar

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> Thanks, that's good to know.  I'll change this accordingly.

Thanks.

Re: scratch/icons 4de626ea22 08/11: Support using icons.el in toolbar

[Stefan Monnier]

> Non-color displays and displays whose visual class is not TrueColor
> cannot display SVG images.  The svg code just doesn't work.

Is that the case for all the SVG renderers?
What does "doesn't work" mean, exactly.  Does it signal an error? draw
something with wrong colors? draw complete random noise? just silently
does nothing?  Is the behavior the same for monochrome displays as for
colormapped displays?

I've used 16bit TrueColor displays until quite recently, but can't
remember using (or hearing someone mention the use of) a colormapped
display in the last ... 20 years?  How common is it nowadays?
What else breaks down?


        Stefan

Re: scratch/icons 4de626ea22 08/11: Support using icons.el in toolbar

[Po Lu]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Is that the case for all the SVG renderers?

We only support one, AFAIK.

> What does "doesn't work" mean, exactly.  Does it signal an error? draw
> something with wrong colors? draw complete random noise? just silently
> does nothing?  Is the behavior the same for monochrome displays as for
> colormapped displays?

It draws big, black squares, if the rendering extension is present on
the X server.

Otherwise, it draws noise of the same kind you would expect if you
simply imported StaticColor pixel data onto a drawable created on a
PseudoColor screen.

> I've used 16bit TrueColor displays until quite recently, but can't
> remember using (or hearing someone mention the use of) a colormapped
> display in the last ... 20 years?  How common is it nowadays?

I don't know, but it's something I use Emacs with once in a while,
because a Java X server that I sometimes need to use has buggy TrueColor
support.

> What else breaks down?

Nothing, I fixed all of those earlier this year.