Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application icon updates #2083

Merged
merged 7 commits into from
Sep 12, 2018
Merged

Application icon updates #2083

merged 7 commits into from
Sep 12, 2018

Conversation

ferdnyc
Copy link
Contributor

@ferdnyc ferdnyc commented Sep 11, 2018

A raft of fixes related to the application icon. If viewing on Github, expand entries for details.

Optimize the SVG icon file

To reduce the size of the icon SVG, I...

  • Brought it into Inkscape, let it adjust the DPI, and then saved it as a Plain SVG (rather than an Inkscape SVG), which removed a bunch of inkscape-specific tags/attributes that only serve to bloat the file.

  • Hand-edited the output to remove an Illustrator <foreignobject> definition that Inkscape can't process, as well as a giant chunk of Illustrator metadata (<i:pgf> tag) that was hanging around.

File size change: 629 KB => 183 KB
Visible differences: None, also see below.
Differences in exported PNG: None. I exported a 64x64 PNG from the updated .SVG file and ran an image-diff with ImageMagick compare. It produced a completely empty image.


Add 256x256 and 512x512 pixel icons

Gnome just released 3.30, and with it some new Design Guidelines to prepare for 3.32 (when they'll go into effect).

One of them is a new requirement that applications provide a 256x256 pixel icon for their application, to go along with the previous 48x48 icon. (OpenShot has been shipping a 64x64 icon, which is fine as it
gets scaled down when necessary.) They also recommend a 512x512 icon for HiDPI devices.

Since scaling the 64x64 icon up to those sizes looks horrible, this change adds xdg/icon/256/openshot-qt.png and xdg/icon/512/openshot-qt.png to the repo, exported from the scalable SVG source just like the 64x64 icon.


Install icons to freedesktop paths from `setup.py`

The setup.py installer in the repo root directory has only been installing the SVG icon file, and into /usr/share/pixmaps/ which is a path only used by the Debian menu system1 (not by XDG, as the file claims.)

XDG uses Freedesktop's icon theme specification2, which instructs application developers to install their icon files in the theme directories: $prefix/share/icons/hicolor/*/apps (sorted by size).

This change installs the existing openshot-qt.svg scalable icon and openshot-qt.png (64x64) icon, as well as the new 256x256 and 512x512 PNGs, into their appropriate places in the icon theme hierarchy.

Again, this is something we've been taking care of "manually" on the packaging end. I'd prefer to offload it to setup.py, which we're running anyway as part of the package-build process, so that everyone building the package can benefit from it.


The only part of this change which might break anything is the relocation of xdg/openshot-qt.png to xdg/icon/64/openshot-qt.png. This is done because setup.py can't rename files during the install process, according to its docs, and since the icon files all need to be named openshot-qt.png when installed into the various $prefix/share/icons/hicolor/*/apps/ directories, I achieved this by setting them up the same way in the source.

I actually couldn't find anything within the repo that consumes xdg/openshot-qt.png — both setup.py and the various scripts in installers/ only ever operated on the SVG icon file (which is not
moved), and ignore the PNG icon entirely. (This is changed with my edits to setup.py, of course.)

So, at least in the context of the repo, this change has no effect. But if there's some script outside
of the repo that expects xdg/openshot-qt.png to be present, it will break. I have no way of knowing
whether any such dependency exists.

The move isn't strictly necessary, since the 64x64 icon could be installed from xdg/ while the
other two sizes install from xdg/icon/256/ and xdg/icon/512/. That just strikes me as really ugly and hackish, which is why I didn't do it. But it's an option, if it comes to that.

ferdnyc and others added 7 commits September 10, 2018 20:57
To reduce the size of the icon SVG, I...

* Brought it into Inkscape, let it adjust the DPI, and then saved it
  as a Plain SVG (rather than an Inkscape SVG), which removed a bunch
  of inkscape-specific tags/attributes that only serve to bloat the file.

* Hand-edited the output to remove an Illustrator `<foreignobject>`
  definition that Inkscape can't process, as well as a _giant_ chunk of
  Illustrator metadata (`<i:pgf>` tag) that was hanging around.

**File size change:** 629 KB => 183 KB

**Visible differences:** None, also see below.

**Differences in exported PNG:** None. I exported a 64x64 PNG from the
updated .SVG file and ran an image-diff with ImageMagick `compare`.
It produced a completely empty image.
Gnome just released 3.30, and with it some [new Design Guidelines][1]
to prepare for 3.32 (when they'll go into effect).

One of them is a new requirement that applications provide a 256x256
pixel icon for their application, to go along with the previous 48x48
icon. (OpenShot has been shipping a 64x64 icon, which is fine as it
gets scaled down when necessary.)

Since scaling the 64x64 icon _up_ to 256x256 looks **horrible**, this
change adds `xdg/openshot-qt_256.png` to the repo, exported from the
scalable SVG source just like the 64x64 icon.

[1]: https://help.gnome.org/misc/release-notes/3.30/developers.html.en#design-guidelines
Gnome also recommends a 512x512 pixel variant of the application
icon, for HiDPI displays.
`setup.py` can't rename files during the install process, according
to its docs, so the icon files all need to be named `openshot-qt.png`
as that'll be their destination name. Achieve this by putting them
all in a directory hierarchy named by size.
The `setup.py` installer in the repo root directory has only
been installing the SVG icon file, and into `/usr/share/pixmaps/`
which is a path only used by the Debian menu system[1] (not by
XDG, as the file claims.)

XDG uses Freedesktop's icon theme specification[2], which instructs
application developers to install their icon files in the theme
directories: `$prefix/share/icons/hicolor/*/apps` (sorted by size).

This change installs the existing `openshot-qt.svg` scalable icon
and `openshot-qt.png` (64x64) icon, as well as the new 256x256 and
512x512 PNGs, into their appropriate places in the icon theme
hierarchy.

Again, this is something we've been taking care of "manually" on
the packaging end. I'd prefer to offload it to `setup.py`, which
we're running anyway as part of the package-build process, so that
everyone building the package can benefit from it.

[1]: https://www.debian.org/doc/packaging-manuals/menu.html/ch3.html#s3.7
[2]: https://specifications.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#install_icons
@DylanC
Copy link
Collaborator

DylanC commented Sep 12, 2018

@ferdnyc - Apologies for the delay. I've been away for a few days on a trip but I didn't get a chance to go on my laptop. Happy to merge this one too... once it passed our new shiny Travis CI. ;-)

@DylanC DylanC merged commit 85b433b into OpenShot:develop Sep 12, 2018
@ferdnyc ferdnyc deleted the icon-install branch September 17, 2018 00:15
ferdnyc added a commit to ferdnyc/openshot-qt that referenced this pull request Nov 2, 2018
PR OpenShot#2083 cleaned up and optimized the application icon
in `xdg/openshot-qt.svg`, but the old, crufty, bloated
version is still in the tree at `src/images/openshot.svg`.

This change copies the cleaned-up version there, so that
the version of the icon being loaded (most importantly)
in all of the interface `.ui` files is the cleaner,
optimized SVG.

Eliminates these log messages from OpenShot:
```
link SVGID_18_-5 hasn't been detected!
link SVGID_18_-5 hasn't been detected!
link SVGID_22_-5 hasn't been detected!
link SVGID_24_-2 hasn't been detected!
link SVGID_24_-2 hasn't been detected!
```
...which it turns out were due to structural errors
in the uncleaned, unoptimized `openshot.svg`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants