Created attachment 83742 [details]
hi16-action-im-sipe.png

Created attachment 83743 [details]
hi22-action-im-sipe.png

Created attachment 83744 [details]
hi32-action-im-sipe.png

Created attachment 83745 [details]
hi48-action-im-sipe.png

If pidgin-sipe installs them, why do we have to? 
Can we not set the .profile file to use the same icon name?

(In reply to comment #5)
> If pidgin-sipe installs them, why do we have to? 
> Can we not set the .profile file to use the same icon name?
because, pidgin-sipe installs than in a bit strange place

% equery f pidgin-sipe | grep im-sipe
/usr/share/empathy/icons/hicolor/16x16/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/22x22/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/24x24/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/32x32/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/48x48/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/scalable/apps/im-sipe.svg

Yes, that's quite strange place. Is it the source that installs it there or the distro package?

OK, so this will work if we do a KIconLoader::addAppDir("empathy") somewhere globally (so every KTp app has it) 

or we ship duplicate icons, I'm not sure which is the lesser of two evils

(In reply to comment #7)
> Yes, that's quite strange place. Is it the source that installs it there or
> the distro package?

This is default path from pidgin-sipe package, yep it looks like upstream (pidgin-sipe) issue, but I'm not sure when they will fix it, if bug will be opened.

./contrib/rpm/pidgin-sipe.spec contains
%{_datadir}/empathy/icons/hicolor/*/apps/im-sipe.png
%{_datadir}/empathy/icons/hicolor/*/apps/im-sipe.svg

pixmaps/Makefile.common.am contains
if SIPE_INCLUDE_TELEPATHY
empathyappsiconsdir    = $(datadir)/empathy/icons/hicolor/$(pixmapinst)/apps
empathyappsicons_DATA  = im-sipe.$(pixmapext)
DISTCLEANFILES         = im-sipe.$(pixmapext)

frankly speaking , pidgin-sipe - is the only one who installs icons on my system is so strange place... And I want to remind one more issue:

pidgin-sipe installs this icons ONLY when it compiled in telepathy mode. If pidgin sipe compiled without telepathy, and users use sipe via haze - no any sipe icons installed! 

So, I still think that ktp-common-internals should provide sipe icon.

even more. pidgin-sipe just copy-paste icons in many places

/usr/share/empathy/icons/hicolor/16x16/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/22x22/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/24x24/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/32x32/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/48x48/apps/im-sipe.png
/usr/share/empathy/icons/hicolor/scalable/apps/im-sipe.svg
/usr/share/pixmaps/pidgin/protocols/16/sipe.png
/usr/share/pixmaps/pidgin/protocols/22/sipe.png
/usr/share/pixmaps/pidgin/protocols/24/sipe.png
/usr/share/pixmaps/pidgin/protocols/32/sipe.png
/usr/share/pixmaps/pidgin/protocols/48/sipe.png
/usr/share/pixmaps/pidgin/protocols/scalable/sipe.svg

I think this should be fixed upstream, either pidgin-sipe directly or at least at a distro level. If we'd install that icon too, it would be just more pointless copying around and basically just a workaround to the original problem, which is wrong install directory for those icons.

So, please let's fix this properly where it should be fixed.

I agree we should email first, if upstream cause a problem - then we can look at workarounds.

Maksim, are you happy to email them?

(In reply to comment #13)
> Maksim, are you happy to email them?
I would like to ask you (ktp team) to handle this, you understand entirely this situation better than I'm...

I would like to re-open this, because situation not properly handled, e.g.
1. ktp team could ask pidgin-sipe team about images path
2. in haze/sipe mode, when pidgin-sipe compiled with --disable-telepathy, images not installed at all

Given we're building the sipe plugin unconditionally, let's just ship the icons with KTp. There can be just too many things going wrong and having couple small files duplicated on a disk is not a problem.

Dear user, unfortunately Telepathy is no longer maintained.

Please migrate to another solution, e.g. for Jabber a possibility is Kaidan, for Matrix a candidate is NeoChat.