search

AppImage / AppImageKit

Package desktop applications as AppImages that run on common Linux-based operating systems, such as RHEL, CentOS, openSUSE, SLED, Ubuntu, Fedora, debian and derivatives. Join #AppImage on irc.libera.chat
http://appimage.org
Other
8.65k stars 552 forks source link

Thumbnailer: icons have wrong/mixed size on HiDPI screens #783

Open probonopd opened 6 years ago

probonopd commented 6 years ago

Icons have wrong/mixed size on HiDPI screens. Example: Ubuntu 18.04 on a HiDPI machine.

TheAssassin commented 6 years ago

Did you check whether there's big icons at all in these AppImages? It seems to me like the PdftoWord AppImage's icon has a higher resolution than all the other ones'.

probonopd commented 6 years ago

May be the case, nevertheless it looks like the thumbnailer needs to upscale the lower-resolution icons...

TheAssassin commented 6 years ago

That would involve linking to some library like imagemagick (and all its dependencies) to support all possible formats. I doubt we'd want that.

Maybe check your DE's settings? I could imagine there's an option to have it upscale the icons.

azubieta commented 6 years ago

Are we already making use of some image manipulation lib ? As there are so many image formats I'm wondering which would be the best for our needs.

El dom., 20 de may. de 2018 1:07 PM, probonopd notifications@github.com escribió:

May be the case, nevertheless it looks like the thumbnailer needs to upscale the lower-resolution icons...

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/AppImage/AppImageKit/issues/783#issuecomment-390500210, or mute the thread https://github.com/notifications/unsubscribe-auth/ABFdrpijkq3e-t4RMKWQkmBSMaoFy8uhks5t0bDKgaJpZM4UGINu .

azubieta commented 6 years ago

This issue doesn't happen with the kde thumbnailer because it does chamges the images size to match the standard. I've investigating a bit and I think that thunar is capable of using gnome thumbnailers. So if we make a gnome thumbailer we will have covered the major DE. I'm just wondering if there is a simple thumbailer code that I could use as template.

probonopd commented 6 years ago

linking to some library like imagemagick

Possibly https://lazka.github.io/pgi-docs/GdkPixbuf-2.0/classes/Pixbuf.html#GdkPixbuf.Pixbuf.scale_simple

TheAssassin commented 6 years ago

I'm using CImg to get the resolution of image files. It's a lightweight header-only library. But for obvious reasons it requires to be linked to libpng, libjpeg etc. I guess GdkPixbuf requires shipping those libraries, too. I'm pretty sure we don't want that in the runtime. The only solution I see is to check whether tools like convert (ImageMagick) are available, and implicitly use them.

probonopd commented 6 years ago

Ideally, the desktop environment would do the resizing, but apparently not all do. So we need to do the resizing in the thumbnailer, don't we? Or we need to enforce that certain resolution icons need to be in the AppImage at the AppImage creation time.

azubieta commented 6 years ago

We could do it at the moment of packing by means of "linuxdeploy" so the two icons get created. There is no problem of including image manipulation libraries. And yes we should warn developers about missing icons at a given resolution.

probonopd commented 6 years ago

We could do it at the moment of packing by means of "linuxdeploy" so the two icons get created. There is no problem of including image manipulation libraries.

Yes, or even in the lower-level appimagetool that gets used by most AppImage creation methods.

TheAssassin commented 6 years ago

appimagetool shouldn't take care of icon manipulation. It should only package what it gets presented.

probonopd commented 6 years ago

Using the UNIX philosophy, we should have a makeicons command line tool that would put the appropriate icons in the appropriate sizes into the appropriate locations in a user-defined $PREFIX a.k.a. AppDir structure. This could be called by the user or by out other tools (if it is installed/bundled).

TheAssassin commented 6 years ago

I'd rather build something into linuxdeploy which upscales icons, and prints warnings about the lack of HiDPI support.

I am strongly opposed to appimagetool itself containing functionality regarding desktop integration. This is out of scope.

probonopd commented 6 years ago

Whatever we put in linuxdeploy will not end up being used by

TheAssassin commented 6 years ago

@probonopd that was just an example. The point is, adding image processing to AppImageKit adds a lot of dependencies. And since this is desktop integration stuff, it's actually out of scope. AppImageKit change too much in a given AppDir to keep it simple to deploy.

If you think there is the need for an external solution, we should really think about creating a separate tool/library. Heck, we could simply write it as a linuxdeploy plugin, as they're standalone tools, they can be used on any AppDir, independently from linuxdeploy.

probonopd commented 6 years ago

Architecturally, appimagetool currently takes an existing AppDir and puts it into an AppImage unchanged. (My test for this is that I frequently mount an AppImage and run appimagetool on the read-only mount point of the mounted AppImage - it will produce a new AppImage). Possibly it should stay like this.

So I think we should have a command line tool that would do the modification/preparation/checking of the AppDir. Possibly the tool scope of that tool could even be more than just icons - e.g., linting the AppDir (doing plausibility checks), taking care of metadata, AppStream information, etc. - everything that makes a "good AppDir"?

But ideally not baked into linuxdeployqt, linuxdeploy, etc. because a) there's always more than 1 such tool and b) not everyone will use those tools.

TheAssassin commented 6 years ago

linuxdeploy provides a standalone AppDir class, which will soon receive a verify() method that will implement exactly what you said.

probonopd commented 6 years ago

Which is probably shorthand for "the standalone command line tool that takes care of the icons could also be used as a linuxdeployplugin"?

TheAssassin commented 6 years ago

No. All I'm saying is that liblinuxdeploy_core will receive that feature. You could use it to build your standalone tool if you want to. You know that I build my software so that it's as reusable as possible.

probonopd commented 6 years ago

Why not make a separate plugin = standalone executable for the icon handling stuff? Then other consumers (outside of linuxdeploy) could just invoke it without having to "extract it" from liblinuxdeploy_core...

TheAssassin commented 6 years ago

The verify function is just a linter, it doesn't modify the deployed icons. You mentioned you wanted hints that e.g., icons are too small, and that's exactly what a verification function should recognize.

The problem with an icon is that at the moment, the linuxdeploy plugin spec requires plugins to not depend on any kind of order. They must be able to be run in any order. We'd have to introduce plugin priorities or anything like that to make sure such a plugin would be the last one that is run. That's not really trivial.

probonopd commented 6 years ago

Or we make the plugin not just lint the icons, but create/fix them, right?

TheAssassin commented 6 years ago

That'd be the plugin's scope, yes. AppDir's verify() shall just check for common issues and tell the user about them, but won't yield errors and interrupt linuxdeploy's workflow.

All I'm saying is that if it'll be a plugin for linuxdeploy, we need to find a way to make sure it's the last thing to be run unless you think that won't be a problem.