GNU bug report logs -
#71180
[ELPA Feature Request] Package thumbnail
Previous Next
To reply to this bug, email your comments to 71180 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Fri, 24 May 2024 22:32:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
"Elijah G." <eg642616 <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Fri, 24 May 2024 22:32:01 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Sun, 26 May 2024 09:25:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 71180 <at> debbugs.gnu.org (full text, mbox):
tags 71180 - notabug
severity 71180 wishlist
thanks
"Elijah G." <eg642616 <at> 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.
Removed tag(s) notabug.
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 26 May 2024 09:25:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Sun, 26 May 2024 11:02:01 GMT)
Full text and
rfc822 format available.
Message #13 received at 71180 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> tags 71180 - notabug
> severity 71180 wishlist
> thanks
>
> "Elijah G." <eg642616 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Mon, 27 May 2024 02:17:02 GMT)
Full text and
rfc822 format available.
Message #16 received at 71180 <at> debbugs.gnu.org (full text, mbox):
Stefan Kangas <stefankangas <at> gmail.com> writes:
> tags 71180 - notabug
> severity 71180 wishlist
> thanks
>
> "Elijah G." <eg642616 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Mon, 27 May 2024 18:12:02 GMT)
Full text and
rfc822 format available.
Message #19 received at 71180 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Philip Kaludercic <philipk <at> posteo.net> writes:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>
>> tags 71180 - notabug
>> severity 71180 wishlist
>> thanks
>>
>> "Elijah G." <eg642616 <at> 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
[elpa-thumbnail.png (image/png, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Tue, 28 May 2024 06:22:02 GMT)
Full text and
rfc822 format available.
Message #22 received at 71180 <at> debbugs.gnu.org (full text, mbox):
"Elijah G." <eg642616 <at> gmail.com> writes:
> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>
>>> tags 71180 - notabug
>>> severity 71180 wishlist
>>> thanks
>>>
>>> "Elijah G." <eg642616 <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Thu, 30 May 2024 03:14:02 GMT)
Full text and
rfc822 format available.
Message #25 received at 71180 <at> debbugs.gnu.org (full text, mbox):
Philip Kaludercic <philipk <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#71180; Package
emacs.
(Sun, 02 Jun 2024 19:43:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 71180 <at> debbugs.gnu.org (full text, mbox):
"Elijah G." <eg642616 <at> gmail.com> writes:
> Philip Kaludercic <philipk <at> 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
This bug report was last modified 1 year and 14 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.