AppImage launcher icon defaults to Electron default icon

[eriedl-kiban]

Which version of electron-builder are you using?

• 6.7.3

What target are you building for?

• Linux (AppImage target on Ubuntu 16.04)

I have the image sizes 16, 24, 48, 64, 128, 256 and 512 in the icons sub-directory as PNGs. I had to put them there as the Mac OS X ICNS file is missing the 24, 48 and 64 sizes for now.
Anyway, the AppImage is successfully built and shows the correct icon. However, when launching the app the icon shown on the launcher bar defaults to Electron's default icon.
I'm not sure what I'm missing here to display the app icon also on the launcher. Mac OS X and Windows builds show the correct icons when running.

[develar]

launcher bar defaults to Electron's default icon

Please use launch menu to start app, not app image.

Please see AppImage/AppImageKit#174

@probonopd First user issue :( It is really not user-friendly.

[probonopd]

This is also a bit an issue with how icons are handled by e.g., the Unity launcher. I cannot change this, but there is a workaround: In Qt, one can set an icon to the main window using setWindowIcon(QIcon("icon.png")); and Unity (and other launchers) will then use this icon also for the dock. I don't know how to do the same without Qt yet but it should definitely be possible.

This way, the correct icon would show up regardless of how the user launches the app.

[develar]

http://stackoverflow.com/questions/31529772/setting-app-icon-for-electron-atom-shell-app

new BrowserWindow({width: 800, height: 600,icon: __dirname + '/Bluetooth.ico'}); (keep in mind, that currently icons are not copied to packaged app, so, you have to include it somehow).

It is not convenient, but can be as a temporary solution. I will try to fix AppImage/AppImageKit#174 after #529

[probonopd]

Could it use .DirIcon?

[eriedl-kiban]

Please use launch menu to start app, not app image.

I can confirm that searching for the app and then starting it from the Launcher search results shows the correct icon. The correct icon is also shown in the launcher when installed from a Debian package and then run.

new BrowserWindow({width: 800, height: 600,icon: __dirname + '/Bluetooth.ico'}); (keep in mind, that currently icons are not copied to packaged app, so, you have to include it somehow).

I already do that. However, that only works for packaged apps. If the app is run directly using electron without packaging it, the correct icon is shown only Windows. Mac OS X shows the electron default icon and Linux shows a question mark icon in the launcher. That is OK as it's only for local development. The important part is that the correct application icon is shown when the app is shipped and run by the end-user.

Thanks for your help and great work on this project!

[dpalou]

Hi,

I have the same problem. If I start the app from the Launcher it shows the wrong icon too.

We've been investigating this and we see that the icon is copied to: ~/.local/share/icons/hicolor/32x32/apps. The image in there is named "appimagekit-moodl.png". However, the AppImage is looking for an icon named appimagekit-moodledesktop. For some reason, the name of the icon is truncated.

ICNS file:

https://github.com/moodlehq/moodlemobile2/blob/master/resources/desktop/icon.icns

package.json:

https://github.com/moodlehq/moodlemobile2/blob/master/package.json#L137

Before building, I changed the "name" in the package.json to "moodledesktop".

[crazyserver]

There's a problem in the generated AppRun file. As far as I can see if the app has "desktop" on the name, the resources are not being well named because of the following line:

RESOURCE_NAME=$(echo "$VENDORPREFIX-$DESKTOP_FILE_NAME" | sed -e 's/.desktop//g')

As you can see the period on ".desktop" is not escaped to it removes all desktop from the DESKTOP_FILE_NAME. so "moodledesktop.desktop" it will become one "moodl".

This should be fixed by changing the previous line and escape the period to:

RESOURCE_NAME=$(echo "$VENDORPREFIX-$DESKTOP_FILE_NAME" | sed -e 's/\.desktop//g')

[develar]

@dpalou Fix from @crazyserver is applied and your issue will be fixed in the next release (will be on several hours). To avoid such bugs in the future, all such usages of shell were removed — plain good EJS is used instead :)

[develar]

Path to AppImage icon: path.join(process.env.APPDIR, "testapp.png") where testapp.png is the name of your app icon (equals to executableName (by default - package name)).

So, until this issue is not fixed by AppImage somehow, you can explicitly set icon using this path.

[probonopd]

So, until this issue is not fixed by AppImage somehow, you can explicitly set icon using this path.

Please elaborate what would need to be changed and how I can test if the change was successful.

[develar]

@probonopd I missed that solution is posted — AppImage/AppImageKit#174 (comment) :) I will try to use it. Am I right, that now AppImage officially doesn't provide desktop integration script (sorry, cannot find it)?

[probonopd]

Right, we don't provide that at the moment since we ask users to install the optional appimaged daemon if they like automatic desktop integration.

[probonopd]

In the meantime, this seems to do the job:

win = new BrowserWindow({
   ...
   icon: path.join(__dirname, '/icon/Icon-512x512.png')
})

#2269 (comment)

[develar]

@probonopd and all other — thanks to "Linux", icon is broken for AppImage regardless of how app is launched (since... well, it is Linux, maybe since Ubuntu 18, maybe it was always broken). Works correctly for Snap.

I don't know why it works in case of Snap, but at least it is clear how to fix for AppImage: https://askubuntu.com/questions/367396/what-represent-the-startupwmclass-field-of-a-desktop-file

Today evening (CET) I will release 20.26.0 — electron-builder will correctly set StartupWMClass in desktop file.

To ensure that all users are aware about this "regression" (thanks to "Linux"), I will inform all via Slack channel.

[jbmorgado]

I - like everyone else - have the same issue. Unfortunately, closing this bug and all the news ones related to the same problem, didn't magically solve the issue.

[triangulum]

Same deal here on CentOS 7.

[probonopd]

Can you please post sceenshots and download URLs of affected AppImages so that I can try to reproduce this on various OSes. Thanks.

[develar]

If app has Electron icon — it means that for some reasons electron-builder ignores your icon configuration, in this case please file new issue with attached debug output (set env DEBUG=electron-builder (https://www.electron.build/#debug) and attach log of the terminal output).

If no icon at at all, the only known reason for me — invalid StartupWMClass due to using non-ascii symbols in app product name (e.g. Test App ßW). To fix it, we need to fix electron (https://github.com/electron/electron/blob/2-0-x/atom/browser/native_window_views.cc#L226). For this case there is easy workaround (explicitly set browser window icon).

I recently tested AppImage quite a lot to verify other tasks and I can say that for now no other known reasons. No need to comment closed issue because real cause of your issue is definitly different.

[akashnimare]

@probonopd I can't see my app icon in the dash while using AppImage. Can you help me out?
https://github.com/zulip/zulip-electron/

[probonopd]

Are you doing something like

win = new BrowserWindow({
   ...
   icon: path.join(__dirname, '/icon/Icon-512x512.png')
})

for your main window?

[akashnimare]

For the main window -

https://github.com/zulip/zulip-electron/blob/master/app/main/index.js#L50-L54

This works as expected for Deb + Snap. For AppImage, I can see the icon in unity launcher but it's missing in the dash menu.

[probonopd]

What are you using for AppImage desktop integration? The optional appimaged daemon? It needs to find an icon in usr/share/icons/hicolor/xxxxx/apps/yyyy.zzz that matches to what is specified in the desktop file.

[celodauane]

I am facing exactly the same issue. I tried everything suggested in this thread but unfortunately, nothing worked. At this point, I'm not sure how I can address this issue.

electron-builder: 21.2.0
electron: 3.1.13

[probonopd]

@dvuvne which daemon or tool are you using on your system for AppImage desktop integration?

[trongate]

This is also a bit an issue with how icons are handled by e.g., the Unity launcher. I cannot change this, but there is a workaround: In Qt, one can set an icon to the main window using setWindowIcon(QIcon("icon.png")); and Unity (and other launchers) will then use this icon also for the dock. I don't know how to do the same without Qt yet but it should definitely be possible.

This way, the correct icon would show up regardless of how the user launches the app.

Look, no disrespect.... but I wish you'd stop helping people. You've been following people around GitHub for four years and STILL people are having problems. Nothing that you are saying works and your explanations aren't up to the job. That's nothing against you as a person. I'm just saying, you're wasting a lot of time here. If you can't explain something properly then please just don't. Maybe it's a language thing. In any event, none of what you're saying makes sense and your stuff isn't working. Love you madly. I absolutely love you. I'm sure you're great in every way imaginable. No doubt you're an awesome developer. I hope some day I can be as good as you. But please, for the sake of humanity, STOP HELPING PEOPLE.

[probonopd]

Err, what? I like how you phrase your post seemingly positive @davidjconnelly but I fail at why me trying to help people is a bad thing. Did you consider that if "STILL people are having problems" that might also mean that the problems are real, stuff is complicated and/or broken (not by me!) and/or that people may need more help? Nothing against you as a person @davidjconnelly but if you don't know how to do the equivalent of the Qt code for setWindowIcon(QIcon("icon.png")) in Electron then maybe Google can help you. I don't have the slightest clue about Electron and I don't claim to. I am just trying to be helpful.

[trongate]

Err, what? I like how you phrase your post seemingly positive @davidjconnelly but I fail at why me trying to help people is a bad thing. Did you consider that if "STILL people are having problems" that might also mean that the problems are real, stuff is complicated and/or broken (not by me!) and/or that people may need more help? Nothing against you as a person @davidjconnelly but if you don't know how to do the equivalent of the Qt code for setWindowIcon(QIcon("icon.png")) in Electron then maybe Google can help you. I don't have the slightest clue about Electron and I don't claim to. I am just trying to be helpful.

Okay. I apologise if I've ruffled your feathers. What I'm about to say is said thoughtfully. I had assumed that you were involved with Electron.

I happen to think that Electron has issues when it comes to dealing with icons on Linux. Now, I may be wrong but I've invested long hours in this and the evidence is overwhelming.

My frustration is that nobody is putting their hands up and saying, "this is something that we haven't figured out yet". I cannot find anyone taking responsibility for this. If the people behind Electron just said, "We haven't figured it out but here's a workaround" then that would be cool. However, it's not happening and people are having vast amounts of hours WASTED.

Now, if the situation is that there's no prospect of Electron figuring out how to get it working happily with Linux then I'd like to know. I'd like to know because it has implications for whether or not I'm going to even continue using Electron in the future.

Again... nothing.

It's worse than nothing. Instead of having silence, which would be bad, I'm seeing conversation after conversation where people keep offering bad, poorly described advice that DOES NOT WORK.

Now, isn't a shame that I can't say that without offending you? It's it just the greatest shame that you and I can't enjoy a conversation about this without somebody being offended? I think it is!

But here's the truth, I have wasted a lot of time today by following your advice. Not just here, but on other threads talking about the same issue. You advice does not work. If there's a graceful way to say that then let me know and I'll say it.

Of course, now it has came to light that you "don't have the slightest clue about Electron".

Well... if that's the case, why are you making a career out of answering questions about Electron?

That's outrageous! I wouldn't go on and offer advice about how to fix some Go language problem if I never knew about the language in question.

No doubt your intentions are good. No doubt you're nice and a great developer. I do not for one second question your integrity or your abilities. HOWEVER, you are wasting time. You are NOT helping. None of your answers are helpful. I've gone over several of them and I honestly believe you'd be doing everyone a favour if you stopped responding.

AT THE VERY LEAST you should be letting people know in advance that you "don't have the slightest clue about Electron". That critical piece of information might help when people decide whether or not to download the NPM module that you recommended in another answer to this question - just one of your many time wasting exercises that you have eagerly posted.

The question that we all must ask is,

"What's the most helpful... somebody wasting time by dishing out rubbish advice OR somebody just not saying anything?"

I say the latter and if that makes me a bad person then I apologise. If you don't know what you're doing then stop posting crap answers - for the love of all things good!

DC

[probonopd]

Now, isn't a shame that I can't say that without offending you?

It's alright, I am not offended.

But here's the truth, I have wasted a lot of time today by following your advice.

I can feel with you, my whole Linux (development) experience largely has been based on trial end error. This way you end up becoming somewhat of an expert over time, in the area you are focusing on (which for me is AppImage, not Electron).

Of course, now it has came to light that you "don't have the slightest clue about Electron".

Well... if that's the case, why are you making a career out of answering questions about Electron?

I am not. I am just trying to helpful whenever I see people asking questions that are related to the software I am working on, AppImage.

Please bear in mind that in open source, people are usually helpful but overloaded with way too many different issues.

[probonopd]

I think the answer was given here by the way:

• AppImage launcher icon defaults to Electron default icon #748 (comment)