publishing-requirements: Allow use of single svg icon instead of svg icons for each size

Open
#235 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
48/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Domain
documentation

Research direction

Open the publishing requirements page at the linked Icons section and compare its wording with the linked Flathub and Flatpak icon requirements. Update the documentation to allow one scalable SVG while retaining the separate-size requirement for PNG icons, then verify that the revised guidance clearly distinguishes both cases.

Written by the indexing model from the issue text.

Description

Needs Design Priority: Wishlist
Problem

We explicit that third-party app developers must provide icons in size of 32px, 48px, 64px, and 128px at least in the publishing requirements:

Your app must install icons to /usr/share/icons/hicolor in 32px, 48px, 64px, and 128px. These are the icon sizes that will be displayed in the Applications menu's search, grid, and category views, Multitasking View, the dock, and in AppCenter.

And we also follow this requirement by ourselves; we provide svg icons in these sizes in our core apps.

However, most of GNOME apps only provide single scalable svg icon instead of svg icons for each size:

Flathub also does not require app icons for each size:

https://docs.flathub.org/docs/for-app-authors/requirements#icons

Proposal

Allow use of single svg icon instead of svg icons for each size.

I think developers must still provide icons for each size if in PNG format, but they don't need to provide them if in Scalable Vector Graphics format, unless they want to do so for some reason e.g. detailed design in 128px.

Prior Art (Optional)
Dominant language
No language data
Stars
88
Forks
30
Avg merge
3h 28m
Merged PRs (30d)
1

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from elementary/docs

All issues in elementary/docs

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.