bug#71180: [ELPA Feature Request] Package thumbnail

bug#71180: [ELPA Feature Request] Package thumbnail

[Elijah G.]

Tags: notabug

Hi, i'm wondering if would be a good idea add support for thumbnail for
elpa packages (for elpa website and package-menu *Help* buffers).
I think this is a missing feature that most other editors and non-editors
does (such as synaptic and vscodium).

My idea is to only support 1 image (jpg or png, adding more than 1
thumbnail would be hard to read the package *Help* buffer) and resize it
(if possible) for not take all the buffer size.

For packages developers i think would be fine define new header comment
line for let them to choose which image they want to use, something like:
;;; Thumbnail: ./image.png

Thanks.

bug#71180: [ELPA Feature Request] Package thumbnail

[Stefan Kangas]

tags 71180 - notabug
severity 71180 wishlist
thanks

"Elijah G." <eg642616@gmail.com> writes:

> Tags: notabug
>
> Hi, i'm wondering if would be a good idea add support for thumbnail for
> elpa packages (for elpa website and package-menu *Help* buffers).
> I think this is a missing feature that most other editors and non-editors
> does (such as synaptic and vscodium).
>
> My idea is to only support 1 image (jpg or png, adding more than 1
> thumbnail would be hard to read the package *Help* buffer) and resize it
> (if possible) for not take all the buffer size.
>
> For packages developers i think would be fine define new header comment
> line for let them to choose which image they want to use, something like:
> ;;; Thumbnail: ./image.png
>
> Thanks.

I think this could be a good idea, but it would also depend on how the
idea is executed.  We would obviously need knobs to turn it off, the
feature would need to be tested on text displays, etc.

Instead of a header comment, we could just say that the thumbnail should
always be called "thumb.png" and be in the root directory of the
package, or something along those lines.

bug#71180: [ELPA Feature Request] Package thumbnail

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> tags 71180 - notabug
> severity 71180 wishlist
> thanks
>
> "Elijah G." <eg642616@gmail.com> writes:
>
>> Tags: notabug
>>
>> Hi, i'm wondering if would be a good idea add support for thumbnail for
>> elpa packages (for elpa website and package-menu *Help* buffers).
>> I think this is a missing feature that most other editors and non-editors
>> does (such as synaptic and vscodium).

I am not sure if you mean this as a kind of "logo" or as a kind of
screenshot?  I assume you mean the latter.

>> My idea is to only support 1 image (jpg or png, adding more than 1
>> thumbnail would be hard to read the package *Help* buffer) and resize it
>> (if possible) for not take all the buffer size.
>>
>> For packages developers i think would be fine define new header comment
>> line for let them to choose which image they want to use, something like:
>> ;;; Thumbnail: ./image.png

If anything, I think it would be best to mandate SVG, which after all we
can easily generate using (x-export-frames nil 'svg), if supported.
That should solve the scaling issue.  AFAIK we currently don't support
animated SVGs in Emacs, right?  That might be a nice feature for some
packages.

Two points I am not fond of is that screenshots on sites like GitHub are
often not uniform and contain a lot of noise.  It would be nice if we
could give some guidelines, or better yet generate the screenshots
ourselves from a given sequence of keys.  That might not be nice from a
security or performance perspective and could still be circumvented.

Otherwise, I also dislike the notion of having package developers
version effectively binary data (especially if we are dealing with
non-vector graphics) in their repositories -- if one can't meaningfully
generate a patch whenever the file changes, I take the position that one
should think twice about versioning it in a Git repository.

>> Thanks.
>
> I think this could be a good idea, but it would also depend on how the
> idea is executed.  We would obviously need knobs to turn it off, the
> feature would need to be tested on text displays, etc.

If we are talking about screenshots, that these aren't hard
requirements to understand what a package does, just as describe-package
can do its job now without the help of images.  Visual examples should
be regarded as an enchantment, where they make sense.

> Instead of a header comment, we could just say that the thumbnail should
> always be called "thumb.png" and be in the root directory of the
> package, or something along those lines.

I agree that would be better.

-- 
	Philip Kaludercic on peregrine

bug#71180: [ELPA Feature Request] Package thumbnail

[Elijah G.]

Stefan Kangas <stefankangas@gmail.com> writes:

> tags 71180 - notabug
> severity 71180 wishlist
> thanks
>
> "Elijah G." <eg642616@gmail.com> writes:
>
>> Tags: notabug
>>
>> Hi, i'm wondering if would be a good idea add support for thumbnail for
>> elpa packages (for elpa website and package-menu *Help* buffers).
>> I think this is a missing feature that most other editors and non-editors
>> does (such as synaptic and vscodium).
>>
>> My idea is to only support 1 image (jpg or png, adding more than 1
>> thumbnail would be hard to read the package *Help* buffer) and resize it
>> (if possible) for not take all the buffer size.
>>
>> For packages developers i think would be fine define new header comment
>> line for let them to choose which image they want to use, something like:
>> ;;; Thumbnail: ./image.png
>>
>> Thanks.
>
> I think this could be a good idea, but it would also depend on how the
> idea is executed.  We would obviously need knobs to turn it off, the
> feature would need to be tested on text displays, etc.

I agree, i would like to help, but i don't know how *Help* buffer
parses the package info or where is stored its code.

> Instead of a header comment, we could just say that the thumbnail should
> always be called "thumb.png" and be in the root directory of the
> package, or something along those lines.

I think that it would be better in the root directory, the reason why i
choose the header comment is allow for 3rd-party package archives use
that feature it for *help* buffers.

bug#71180: [ELPA Feature Request] Package thumbnail

[Elijah G.]

[-- Attachment #1: Type: text/plain, Size: 2397 bytes --]

Philip Kaludercic <philipk@posteo.net> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> tags 71180 - notabug
>> severity 71180 wishlist
>> thanks
>>
>> "Elijah G." <eg642616@gmail.com> writes:
>>
>>> Tags: notabug
>>>
>>> Hi, i'm wondering if would be a good idea add support for thumbnail for
>>> elpa packages (for elpa website and package-menu *Help* buffers).
>>> I think this is a missing feature that most other editors and non-editors
>>> does (such as synaptic and vscodium).
>
> I am not sure if you mean this as a kind of "logo" or as a kind of
> screenshot?  I assume you mean the latter.

I meant a screenshot.

>>> My idea is to only support 1 image (jpg or png, adding more than 1
>>> thumbnail would be hard to read the package *Help* buffer) and resize it
>>> (if possible) for not take all the buffer size.
>>>
>>> For packages developers i think would be fine define new header comment
>>> line for let them to choose which image they want to use, something like:
>>> ;;; Thumbnail: ./image.png
>
> If anything, I think it would be best to mandate SVG, which after all we
> can easily generate using (x-export-frames nil 'svg), if supported.
> That should solve the scaling issue.  AFAIK we currently don't support
> animated SVGs in Emacs, right?  That might be a nice feature for some
> packages.

About animated screenshot/thumbnail i think that GIF images fits
better with this.

> Two points I am not fond of is that screenshots on sites like GitHub are
> often not uniform and contain a lot of noise.  It would be nice if we
> could give some guidelines, or better yet generate the screenshots
> ourselves from a given sequence of keys.  That might not be nice from a
> security or performance perspective and could still be circumvented.

I agree about a guideline.

> If we are talking about screenshots, that these aren't hard
> requirements to understand what a package does, just as describe-package
> can do its job now without the help of images.  Visual examples should
> be regarded as an enchantment, where they make sense.

Of course, the screenshot would be something optional, allowing
packages add a screenshot/thumbnail would make more easy watch what does
a package or what can do a package (instead going to their repository or
read its description).

Here is a little mockup how i think it would look like in
package-describe *Help* buffer


[-- Attachment #2: elpa-thumbnail.png --]
[-- Type: image/png, Size: 58219 bytes --]

bug#71180: [ELPA Feature Request] Package thumbnail

[Philip Kaludercic]

"Elijah G." <eg642616@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> tags 71180 - notabug
>>> severity 71180 wishlist
>>> thanks
>>>
>>> "Elijah G." <eg642616@gmail.com> writes:
>>>
>>>> Tags: notabug
>>>>
>>>> Hi, i'm wondering if would be a good idea add support for thumbnail for
>>>> elpa packages (for elpa website and package-menu *Help* buffers).
>>>> I think this is a missing feature that most other editors and non-editors
>>>> does (such as synaptic and vscodium).
>>
>> I am not sure if you mean this as a kind of "logo" or as a kind of
>> screenshot?  I assume you mean the latter.
>
> I meant a screenshot.
>
>>>> My idea is to only support 1 image (jpg or png, adding more than 1
>>>> thumbnail would be hard to read the package *Help* buffer) and resize it
>>>> (if possible) for not take all the buffer size.
>>>>
>>>> For packages developers i think would be fine define new header comment
>>>> line for let them to choose which image they want to use, something like:
>>>> ;;; Thumbnail: ./image.png
>>
>> If anything, I think it would be best to mandate SVG, which after all we
>> can easily generate using (x-export-frames nil 'svg), if supported.
>> That should solve the scaling issue.  AFAIK we currently don't support
>> animated SVGs in Emacs, right?  That might be a nice feature for some
>> packages.
>
> About animated screenshot/thumbnail i think that GIF images fits
> better with this.

The issue is that .gif is still a bitmap format, so we wouldn't have the
advantage of scaling that vector graphics give us.

As this is a feature that would only be added in a future version of
Emacs, we could start another feature request to support SVG animations
as well, perhaps even a way to record Emacs into such a animation.

See https://en.wikipedia.org/wiki/SVG_animation for a few examples.

>> Two points I am not fond of is that screenshots on sites like GitHub are
>> often not uniform and contain a lot of noise.  It would be nice if we
>> could give some guidelines, or better yet generate the screenshots
>> ourselves from a given sequence of keys.  That might not be nice from a
>> security or performance perspective and could still be circumvented.
>
> I agree about a guideline.

It might even be worth considering restricting screenshots to GNU ELPA
packages, so that the guidelines can be enforced more effectively.

>> If we are talking about screenshots, that these aren't hard
>> requirements to understand what a package does, just as describe-package
>> can do its job now without the help of images.  Visual examples should
>> be regarded as an enchantment, where they make sense.
>
> Of course, the screenshot would be something optional, allowing
> packages add a screenshot/thumbnail would make more easy watch what does
> a package or what can do a package (instead going to their repository or
> read its description).
>
> Here is a little mockup how i think it would look like in
> package-describe *Help* buffer

That seems like the screenshot is part of the README file?  I would have
imagined them before or after the file, perhaps even in a different buffer.

> x
>

-- 
	Philip Kaludercic on peregrine

bug#71180: [ELPA Feature Request] Package thumbnail

[Elijah G.]

Philip Kaludercic <philipk@posteo.net> writes:

> The issue is that .gif is still a bitmap format, so we wouldn't have the
> advantage of scaling that vector graphics give us.
>
> As this is a feature that would only be added in a future version of
> Emacs, we could start another feature request to support SVG animations
> as well, perhaps even a way to record Emacs into such a animation.
>
> See https://en.wikipedia.org/wiki/SVG_animation for a few examples.

I think it would not be hard to make it (as far as how Emacs supports
SVG), i just thought in .gif files for being more easy to implement than
animated svg (despite being rasterized and perhaps losing more quality).

> That seems like the screenshot is part of the README file?  I would have
> imagined them before or after the file, perhaps even in a different buffer.

Maybe something like this?

   Requires: emacs-28.1, compat-29.1.4.4
   Keywords: faces tools matching
   [See Screenshot]
   ^^^^^^^^^^^^^^^^

And when the user clicks it pop up a buffer with the screenshot,
similar in how Synaptic does.

bug#71180: [ELPA Feature Request] Package thumbnail

[Philip Kaludercic]

"Elijah G." <eg642616@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> The issue is that .gif is still a bitmap format, so we wouldn't have the
>> advantage of scaling that vector graphics give us.
>>
>> As this is a feature that would only be added in a future version of
>> Emacs, we could start another feature request to support SVG animations
>> as well, perhaps even a way to record Emacs into such a animation.
>>
>> See https://en.wikipedia.org/wiki/SVG_animation for a few examples.
>
> I think it would not be hard to make it (as far as how Emacs supports
> SVG), i just thought in .gif files for being more easy to implement than
> animated svg (despite being rasterized and perhaps losing more quality).

Well yes, because animated Gifs are already supported, while animated SVGs
are not.

>> That seems like the screenshot is part of the README file?  I would have
>> imagined them before or after the file, perhaps even in a different buffer.
>
> Maybe something like this?
>
>    Requires: emacs-28.1, compat-29.1.4.4
>    Keywords: faces tools matching
>    [See Screenshot]
>    ^^^^^^^^^^^^^^^^
>
> And when the user clicks it pop up a buffer with the screenshot,
> similar in how Synaptic does.

Right, I think that would be good.  Perhaps we could even allow for more
than just one screenshot + some captions.

-- 
	Philip Kaludercic on peregrine