Number of unread emails not shown (appind branch)
Basically the icon stays as it is shown on the image: http://x.rushbase.net/02dc090a4ba6f0c44e83976687c00da33d24ad4f/screenshot.png
Hi, this is a known issue. I suggest you turn to the appindicator community and ask them to add PixBuf support.
That issue has 3 years ... to not have such important feature looks like libindicator is dead. :-( I think KDE has some alternative systray icon implementation, utilized via dbus. Could that be supported?
I think this is what I'm seeing as well. Latest update messed up the read/unread indication in the icon. Neither "unread messages" or "new messages" counts works. I also can't seem to change included accounts or folders.
I tried to express my position. Basically, I can't provide KDE-specific support. Patches welcome though.
Using (and adding depency on)libappindicator is an attempt to both provide AppIndicator/KSNI support, and limit environment-specific code.
What can be done to overcome AppIndicator limitations is:
- KDE/Unity users to ask the libappindicator community to enable more flexibility (like PixBuf support)
- FireTray should implement an option for enabling/disabling libappindicator
@tdn120, the included accounts bug is tracked in #139.
Yeah sounds like I'm seeing #139. Thanks.
Could this be used as a replacement for libappindicator? https://github.com/jjk-jacky/statusnotifier
@Rush I'm afraid libstatusnotifier is not widely available. And I'd rather not provide the lib (for multiple architectures) within FireTray. The benefits of libappindicator are that it's directly available under Unity and (mostly) works with KDE. Still I agree that, if libappindicator doesn't get more KDE-friendly, libstatusnotifier might become an option. Do we know how libstatusnotifier behaves under Unity ? Would you be willing to work on this ?
I started work on my own little library that will be basically either single .h file on a MIT license or a small library that does dlopen on libdbus. Do you think it's viable? I have researched talking to dbus over libdbus during Christmas time and I have a small prototype already. It could expose an API that you can dlopen as well so your users would only need to install my library and FireTray would dlopen it. Can you bind to C functions that report events over call backs or do you prefer a polling approach? I will have to forward you events like "Activate" or "ContextMenu".
@Rush I don't know. We could give it a try. But I'm a little concerned about the maintainability of all this, compared to libappindicator. FireTray relies on GTK+ and uses gio which does not rely on libdbus, but libxul (Mozilla) depends on libdbus.
But, again, if it fixes libappindicator shortcomings under KDE and works well under Unity, then it could be an option. I should be able to embed the lib in FireTray itself, and bind it with js-ctypes. I would prefer callbacks over polling.
Why not just contribute to libappindicator for ensuring it works well under KDE ?
I think it's easier. I didn't wanna fight with libappindicator since it appears dead and I don't fancy how it's written. It's not even easy to open an issue there .. compared to how responsive you sir are! My intuition is that my changes would be rejected. I could be wrong of course but in any case I wanted to learn some DBUS anyway. I'll try to post my proof of concept code this evening. (edit: seems not yet working on Ubuntu yet, will try to debug why)
@foudfou https://github.com/encharm/libsystemtray
Little delay. Please see examples. Api is in the .h file. You can also set icon by pixel data. All features of KDE system tray should be supported. Sadly I am not sure why these icons don't show up on my Ubuntu. Can you test for yourself?
@Rush you had mentioned C, not C++. The problem is that js-ctypes (the thing that makes it possible to call C code from JS) doesn't work well with C++.
@foudfou: there is a C API.See https://github.com/encharm/libsystemtray/blob/master/tests/iconbyname.c
@Rush oh right, I just looked at the github analysis and missed it. Nice work BTW! I'll give it a try when I get a chance. In the meantime, if you want you can try to replace FiretrayAppIndicator.jsm by something of your own in FireTray's code. Places to look at:
src/modules/ctypes/linux/appindicator.jsm
src/modules/linux/FiretrayAppIndicator.jsm
src/modules/linux/FiretrayStatusIcon.jsm
and 270807380 for a ctypes binding.
I won't be able to test for icons under Ubuntu before a week at least.
Hi foudfou, I may be a bit late but I want to let you know that appindicator is not meant to support "left click" old behavior : https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Proposed_changes https://unity.ubuntu.com/projects/appindicators/ "Application indicators are more consistent – no more left and right-click inconsistency. Always left click to see the items."
Here's how syncthing-gtk handled it if you're interested : https://github.com/syncthing/syncthing-gtk/issues/73#issuecomment-74874981 https://github.com/syncthing/syncthing-gtk/pull/96
And you have a nice comparison table about the support of StatusIcons on DEs here : https://github.com/alexander255/syncthing-gtk/blob/49c0ba01c57845c48c1a7ac623fc5fcf86858130/syncthing_gtk/statusicon.py
I come here by link in lp#812067 bug report. I faced such problem when trying to port some gnome/kde accessibility system tray icons to Ubuntu Unity. Issue here https://askubuntu.com/questions/402315/ .
The solution I came with is to store the dynamically generated icon in /tmp/ folder . To notify libappindicator about the change, trick it, I flip between 2 theme paths (/tmp/ & /tmp) or 2 icons names (icon0.svg & icon1.svg)
Used here, https://github.com/sneetsher/indicator-xkbmod . Anyway, even this it's just a workaround.
Hi @sneetsher, nice work! I'd prefer to try embedding @Rush's lib though, as it would be a more radical solution.
For unread count issue on Plasma 5 I did a brutal patch - https://github.com/michal-karpinski/FireTray
It's not nice but it seems to do the job.
@michal-karpinski I think your patch is interesting. How about creating the file from the pixbuf ? See gdk_pixbuf_save. The code for creating the pixbuf should be factored from modules/linux/FiretrayGtkStatusIcon.jsm, probably to modules/linux/FiretrayStatusIcon.jsm.
That would definitely be a cleaner way, however, as I'am not really familiar with these libraries and I was afraid of caching issues etc... I guess that in the end, there should be a possibility of using a pixbuf directly. In the mean time, we can use this simple patch as a workaround.
Nevertheless, if I come across any problems with my solution, I will give your suggestion a try. BTW, thanks for this great plugin :)