search

AppImageCommunity / libappimage

Implements functionality for dealing with AppImage files
https://appimage.org
Other
46 stars 29 forks source link

Shows wrong icon when icon is svgz #132

Closed probonopd closed 5 years ago

probonopd commented 5 years ago

kdenlive-19.04.2d-x86_64.appimage contains usr/share/icons/hicolor/scalable/apps/kdenlive.svgz.

Yet just a weird placeholder icon gets shown:

placeholder

Tested with

me@host:~$ appimaged --version
appimaged, continuous build (commit 8f26d64), build 204 built on 2019-05-31 15:04:05 UTC

cc @azubieta

azubieta commented 5 years ago

@probonopd in this case no icon was generated. The svgz format is not supported and it is not part of the standard see https://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#file_formats

We should encourage AppImage creators to stick to the standard. IMHO this is an issue for appimagelint

TheAssassin commented 5 years ago

appimagelint already complains about this.

probonopd commented 5 years ago

Only that the Kdenlive people are not running appimagelint... should we make it mandatory in appimagetool?

azubieta commented 5 years ago

I guess that the whole appimagelint (feature wise) should be part of appimagetool. Actually I would prefer to see all the AppImage creation tools (at least the one we maintain) blended into one.

Users still complain of having too many options

TheAssassin commented 5 years ago

Users still complain of having too many options

There's no evidence for such a claim.

Unix has always followed the motto "make an app so it does exactly one thing and does it right". There's no need to bloat tools with functionality.

azubieta commented 5 years ago

There's no evidence for such a claim.

I guess that IRC chat logs can serve as evidence. Every day shows up a new person asking whether to use appimagetool, linuxdeploy or linuxdeployqt

It's not about making feature bloated tools but to create a single tool to create AppImage. I guess that a similar rationale took you to create AppImageCraft, one tool to make AppImages right.

probonopd commented 5 years ago

I think it's good to separate concerns in separate tools, but then make the higher-level tools automatically run the lower-level ones. E.g., if appimagetool is the tool to make AppImages, it should bundle and invoke the tool to verify AppDirs before converting them to AppImages. So that the user doesn't have to do an extra step manually.

TheAssassin commented 5 years ago

I guess that IRC chat logs can serve as evidence. Every day shows up a new person asking whether to use appimagetool, linuxdeploy or linuxdeployqt

That's purely a docs issue. If linuxdeployqt went away people wouldn't be confused by it.

It's not about making feature bloated tools but to create a single tool to create AppImage. I guess that a similar rationale took you to create AppImageCraft, one tool to make AppImages right.

Not exactly, but similar. appimagecraft doesn't do anything by itself really, it just calls other tools the right way in the right order. It doesn't ship other tools or anything. It doesn't "come" with anything. You can enhance your workflow by putting the tools nearby and then enable them.

I think appimagecraft is the way to go here. It should just call appimagelint on the final build product.

probonopd commented 5 years ago

if linuxdeployqt went away

That will happen only once we have a drop-in replacement for it that has a compatible CLI. E.g., a wrapper that uses linuxdeploy under the hood. Hundreds of projects don't want to touch their build scripts and change them to a tool that needs to be invoked totally differently.

TheAssassin commented 5 years ago

They only have to change their build scripts because someone provided them with some scripts they never invested 5 minutes in trying to understand that magically do stuff...

probonopd commented 5 years ago

Exactly. They should not need to care. It just needs to work.

TheAssassin commented 5 years ago

Developers must know how things work. Even if just for compliance reasons. AppImage has a tendency to create many many license compliance problems.

probonopd commented 5 years ago

Exactly as many, or few, as ISO or ZIP.

TheAssassin commented 5 years ago

Does that make it any better?

Also there's that problem of the runtime and a few other files being licensed under the terms of the MIT license, which in theory requires attribution inside the packaged applications. Therefore I want to write any new version of the runtime with something more permissive, e.g., the zlib license, which doesn't require attribution when used in binary form. The IP in the runtime isn't really worth requiring the MIT license. We can be more liberal there.

TheAssassin commented 5 years ago

Anyway, all of this is off-topic. Please focus on the actual issue again.

I think we can close this issue until there are better rules on this in the AppImage spec (e.g., when using PNG for .DirIcon is a rule, not a recommendation). You might also create an issue in AppImageKit about this. It's certainly not a libappimage issue, though.

probonopd commented 5 years ago

MIT license, which in theory requires attribution inside the packaged applications

Please open an issue about this; if this really turns out to be a concern for anyone we can either amend the license for runtime.c or switch it to Public Domain entirely.

TheAssassin commented 5 years ago

Closing this issue as resolved.