GNOME Bugzilla – Bug 714173
new mail notification on system taskbar or launcher
Last modified: 2013-05-01 06:51:00 UTC
---- Reported by adam@yorba.org 2011-07-07 11:28:00 -0700 ---- Original Redmine bug id: 3828 Original URL: http://redmine.yorba.org/issues/3828 Searchable id: yorba-bug-3828 Original author: Adam Dingle Original description: new mail notification on system taskbar Related issues: related to geary - Feature #5648: support Ubuntu messaging menu (Fixed) related to geary - Feature #3693: Monitor Inbox (Fixed) related to geary - Feature #5403: Render avatars in notification bubbles (Fixed) duplicated by geary - Feature #4283: display unread message count in Unity sidebar (Duplicate) ---- Additional Comments From geary-maint@gnome.bugs 2013-05-01 11:51:00 -0700 ---- ### History #### #1 Updated by Adam Dingle over 2 years ago * **Category** changed from _4_ to _13_ #### #2 Updated by Christian Dywan over 1 year ago * **Assignee** set to _Christian Dywan_ #### #3 Updated by Adam Dingle over 1 year ago Christian, this may be a significant project. We're happy to have you take this on, though. Here are some architectural questions - could you investigate and propose answers to these? * Will we need separate implementations for GNOME Shell and for the Unity taskbar? If so, will there be yet another implementation for the Elementary taskbar? * Unity already displays a mail icon in the taskbar at all times. I believe I've seen this mail icon turn blue (sometimes) when new mail is available in Thunderbird. Can we make that work with Geary, or will we display a separate taskbar icon for Geary? * Will the new mail notification work even when the Geary client GUI is not running? If so, will it work by running the Geary engine in the background and communicating with it over our existing DBus API? Or will this work via some other magic? #### #4 Updated by Eric Gregory over 1 year ago Currently there's no way to get an unread count for a folder from Geary. Be forewarned: adding this will require some engine additions. Also: using the DBus API for this isn't an option yet, since the DBus service and Geary GUI cannot run simultaneously. #### #5 Updated by Christian Dywan over 1 year ago I was looking at the folder/ conversation/ server code a bit and couldn't get the DBus service and GUI running, so this is apparently expected. My idea was the DBus service could take care of notifications regardless of the GUI. It could as a first step just monitor the inbox. We're looking at 4 possible kinds of notifications here: - Messaging Indicator, libindicator, "blue envelope" next to battery, sound etc. Applies to: Unity, Elementary, Xfce - Launcher Badge, a number on top of an App Launcher Applies to: Unity, Elementary/ Plank - Notification Bubbles, libnotify, "Mr.Spam<spam@yolk.com> wrote Your order of eggs has arrived." Applies to: freedesktop.org - Classic System Tray Applies to: Xfce, GNOME Classic Personally I've grown to dislike the system tray due to its inconsistent usability. #### #6 Updated by Christian Dywan over 1 year ago This is the vala code needed to integrate a Launcher with an existing DBus service, and that's how Postler does it: [DBus (name = "com.canonical.Unity.LauncherEntry")] class LauncherEntry : Object { PostlerService service; public HashTable<string, Variant> query () { var properties = new HashTable<string, Variant> (str_hash, str_equal); properties.insert ("count", (int64)service.unread); properties.insert ("count-visible", service.unread > 0); properties.insert ("progress", 0.0); properties.insert ("progress-visible", false); properties.insert ("urgent", false); return properties; } public signal void update (string app_uri, HashTable<string, Variant> properties); public LauncherEntry (PostlerService service) { this.service = service; service.notify["unread"].connect ((object, pspec) => { update ("application://postler.desktop", query ()); }); update ("application://postler.desktop", query ()); } } And a matching call in name_aquired: conn.register_object ("/com/canonical/unity/launcherentry", new LauncherEntry (service)); #### #7 Updated by Christian Dywan over 1 year ago Indicators should use libindicator: Indicate.Server indicator; List<Indicate.Indicator> items; void update_inbox_indicator (Indicate.Indicator item) { string path = "search:uri/" + item.get_property ("url") + "/INBOX"; int64 new_messages = 0; notify["unread"].connect ((object, pspec) => { update_inbox_indicator (item); }); try { new_messages = unread_messages (path)[0]; } catch (Error error) { GLib.warning ("Indicator: %s", error.message); } if (new_messages > 0) { item.set_property ("count", new_messages.to_string ()); item.emit_show (); } else item.emit_hide (); } void add_inbox_indicator (AccountInfo info) { if (info.type != AccountType.IMAP) return; var item = new Indicate.Indicator.with_server (indicator); item.set_property ("name", info.display_name); item.set_property ("url", info.path); item.user_display.connect ((item) => { string url = item.get_property ("url"); Postler.App.spawn_uri ("search:uri/" + url + "/INBOX"); }); items.append (item); update_inbox_indicator (item); ... indicator = Indicate.Server.ref_default (); indicator.set_type ("message.email"); /* Work around indicator bug: Manually fallback to system-wide file */ string desktop_file = Config.DATADIR + "/applications/postler.desktop"; if (!FileUtils.test (desktop_file, FileTest.EXISTS)) desktop_file = "/usr/share/applications/postler.desktop"; indicator.set_desktop_file (desktop_file); indicator.server_display.connect (() => { Postler.App.spawn_uri (""); }); var item = new Indicate.Indicator.with_server (indicator); item.set_property ("name", _("Compose Message")); item.user_display.connect (() => { Postler.App.spawn_uri ("mailto:"); }); item.emit_show (); items.append (item); if (Environment.find_program_in_path ("dexter") != null) { item = new Indicate.Indicator.with_server (indicator); item.set_property ("name", _("Contacts")); item.user_display.connect (() => { new Dexter.Dexter ().show_window (); }); item.emit_show (); items.append (item); } foreach (var info in accounts.get_infos ()) add_inbox_indicator (info); indicator.show (); #### #8 Updated by Adam Dingle over 1 year ago Christian, thanks for the information. A few more points: 1. We need to answer some higher-level questions about the role of DBus in Geary (e.g. do we want to move toward a world where Geary always requires a DBus server to be running?) I'd rather wait until Jim returns from his vacation to talk about that, so I think we should stall any DBus-related work here for a couple of weeks. 2. If you want to work on an implementation of this that runs entirely inside the normal Geary client for now, that would be fine with me - we can always migrate the code out into a DBus-based implementation if and when we want to. 3. From a user perspective, I personally **don't** want to receive a new email notification in the taskbar when Geary is not running. If I close Geary, that means that I want to work without distraction; a new email notification would be distracting. So as for me, I would be perfectly content if new notifications arrived only when Geary is actually running. Others may feel differently, though (do you?) If we do want notifications even when Geary is not running, I'd prefer that the user be able to easily configure them to be on or off. It would be annoying to me if after installing Geary the new mail flag always appeared and I couldn't turn it off. #### #9 Updated by Christian Dywan over 1 year ago An example for libnotify/ notification bubbles, for completeless: static Notify.Notification? notification = null; static bool persistence = false; public static void send_notification (string message, int count, string sound) { try { if (!Notify.is_initted ()) { if (!Notify.init (PRGNAME)) throw new FileError.FAILED (_("Failed to initialize.")); } if (notification == null) { notification = (Notify.Notification)GLib.Object.new ( typeof (Notify.Notification), "summary", GLib.Environment.get_application_name (), "body", message); unowned List<string> caps = Notify.get_server_caps (); foreach (string cap in caps) { if (cap == "actions") { notification.add_action ("default", _("Open"), (n, a) => { // Open UI }); } } notification.set ("icon-name", STOCK_INTERNET_MAIL); } else notification.set ("body", message); #### #10 Updated by Christian Dywan over 1 year ago "do we want to move toward a world where Geary always requires a DBus server to be running?" So I think eventually the DBus server could take care of all the hard work. Fetching mail, sending large attachments, keeping track of new mail to minimize the time the UI needs to show the latest mail when you open it. In that spirit, the server could naturally take care of notifications. "If you want to work on an implementation of this that runs entirely inside the normal Geary client for now, that would be fine with me" I'd like that. As the examples hopefully show it can be kept pretty contained, and moving it later should be fine. "From a user perspective, I personally don't want to receive a new email when Geary is not running" What I personally prefer is the bubbles with a preview snippet, which are handy when you're waiting on something. They go away after some seconds. For that use case, they are much more effective if they're always active. The other indicators/ badges fill in as a persistent hint instead of going away - I'm torn on the concept, they became close to insignificant to me after the IM status merged in the same icon and it's impossible to know what kind of status it conveys. So we could probably have an option for transient notifications, and another one for peristent hints. #### #11 Updated by Adam Dingle over 1 year ago Thunderbird also has the bubbles with a preview snippet, and I have to agree those are useful, so it would be nice if we could have those too. So great - let's implement this as part of the client for now, and address the DBus- related issues a little later on. As long as this is in the client, I don't think we need any options for notification just yet - let's just make it always notify, and if it's too annoying then we can discuss options later. #### #12 Updated by Adam Dingle over 1 year ago * **Subject** changed from _new mail notification on system taskbar_ to _new mail notification on system taskbar or launcher_ Note that we have a separate ticket for #### #13 Updated by Adam Dingle over 1 year ago ...for the Unity sidebar (#4283). I'll mark that as a duplicate of this one. #### #14 Updated by Adam Dingle over 1 year ago By the way, Christian, the notification that I'm looking forward to most is a number on top of an app launcher (e.g. the launcher bar on the left side of the screen in Ubuntu Unity). That's the one that would be most useful for me, anyway. #### #15 Updated by Jim Nelson over 1 year ago I'm catching up on the discussion here. A few points to add: Eric is correct, Geary currently doesn't offer a way to determine the number of unread ("unseen" in IMAP parlance) messages. The IMAP layer does fetch that number when it first selects the folder, however the plumbing to deliver that number up to the API layer is not in place. That's not terribly difficult. There are some complications. The way it retrieves that value (as a response to the SELECT/EXAMINE command) is optional according to RFC2060. The bulletproof way to know is to use the SEARCH command, which the Engine doesn't currently do. However, GMail does support this, so we're okay for now. (Unsure if Yahoo! does this, but I bet they do.) We can TODO this for later. What's more involved is maintaining that number as the user reads messages and as new messages arrive. IMAP doesn't report the value as an unsolicited response after the folder has been selected, so it's up to the client to maintain the value. One hitch in all of this: there's no guarantee that a newly arrived message is unread (consider the situation where a user moves an archived message back to the Inbox). The simple solution is to consider all newly arrived messages as unread; the thorough solution is to query the message's flags. The right way to expose this to the client is to add a get_unread_count() method to Geary.Folder and a signal "unread-count-changed" (with a complementary notify_unread_count_changed() vmethod) as well. Or, we can ticket all of this for later and only have the notifier display the total message count, which is currently exposed by the API. Note that the other (original) aspect of this ticket, notifying of new mail, should be doable with the existing Geary.Folder interface by monitoring the appropriate signals. #### #16 Updated by Jim Nelson over 1 year ago Also, regarding when to display notifications, I personally do want at some point in the future to be notified of new mail whether Geary is running or not. It would be even better if I can selectively enable/disable the notifier if I really need to go into "don't interrupt me now" mode. #### #17 Updated by Adam Dingle over 1 year ago It sure would be nice to get some version of this into 0.1, though time is tight since we want to freeze features in a day or two. We discussed at Yorba and I think the most useful single change would be to make the mail indicator in the system top bar turn blue when there is new mail (this may be an Ubuntu- specific enhancement). Christian, do you think you'll have any time to work on that in the next couple of days? If not, would you mind if we attempted to implement that here at Yorba if we can find time (which is debatable)? #### #18 Updated by Jim Nelson over 1 year ago * **Target version** set to _0.2_ Hopefully we can get this in 0.2. #### #19 Updated by Adam Dingle over 1 year ago Christian, I think we need to work on this feature now since it's a must-have for this release and may involve a fair amount of work. Are you available to work on this now? If not we'll start to work on this at Yorba. #### #20 Updated by Christian Dywan over 1 year ago I'm going to see if I can find my initial patch I started on. To get things started I'll put the API place, and then we can see what's needed engine-wise. #### #21 Updated by Christian Dywan over 1 year ago * **File** 0001-Implement-notification-bubble-interface.diff added * **Status** changed from _Open_ to _Review_ I implemented a NotificationBubble interface which encapsules notifications and sound, through libnotify and libcanberra. The latest Geary seems quite laggy here so testing this is tricky, but I think I'm getting the right count of unread messages. #### #22 Updated by Jim Nelson over 1 year ago * **Category** set to _client_ * **Status** changed from _Review_ to _Open_ Christian, this looks great and is quite promising. This is one feature I wish we could've got in to 0.1 because I feel it makes Geary seem more like a "real" email client. So I'm excited to see how close this patch is to completion. Small things and larger things: * We like for source files to represent the class in them (or the "major" class in them, in the situation where it might hold multiple classes). Please rename notifications.vala to notification-bubble.vala. * I like that there's a default action to open Geary on the notification. The "right" way to do this would be to call MainWindow.present(). If the notifier was in a separate project, then invoking the executable would make sense. * I suspect that the lag you're seeing is when a lot of conversations are added (which happens when Geary starts up). Adding a lot of conversations to the MessageListStore is quite slow and something we want to improve in the future. * Note that calling Conversation.is_unread() merely means that the conversation has one unread message in it. This doesn't match the message unread count, which is what the bubble indicates. If we're going to display a message count, it makes sense to add a get_unread_count() to Conversation and use that number. * Also, I would prefer if we don't list the messages that are already in the database and displayed initially at startup are reported when Geary first opens. They're not really new, and it's possible they will go away when Geary connects to the server. (Thunderbird does something like this too, by the way. I don't like it there either.) Instead, I think we should only display messages that are (a) new to the Inbox and (b) unread. What that mean is: * The UI should keep the Inbox folder open at all time and only tie the notification bubble to its signals. If the Inbox is selected in the sidebar, use that folder; if not, open a new folder but keep the Inbox around. * We need to add some kind of flag or signal to ConversationMonitor that indicates whether the appended messages were due to a user-initiated load (in which case there should be no notification bubble) or because of monitoring (which should earn a notification). This will prevent the notification when Geary first starts. * If there's only one new message, it would be nice to display the subject and who it's from. If there's multiple, let's display the count. These are my big points for now. Keep up the great work, this is getting close! #### #23 Updated by Christian Dywan over 1 year ago * **File** 0001-Implement-notification-bubble-interface.diff added Added folder_initially_selected_by_user to distinguish user-initiated conversation changes - it seems racy, I'll need to investigate this. Split notifications off to on_inbox_conversations_added. Added get_unread_count to Geary.Conversation. Display detailed notification for one conversation. The missing bit is picking up the inbox even if not selected by the user, that's not done yet. #### #24 Updated by Jim Nelson over 1 year ago Yeah, this looks much better. Having the notification watch only Inbox is the final piece of the puzzle here. I agree, the initially_selected_by_user flag is a little ugly, but I don't have a much better solution in mind at this time. I think if we have Inbox open at all times and not relying on the user to select an item in the folder sidebar, some of this problem may fall away because we can trap the first call without worrying about Gtk events driving it. #### #25 Updated by Christian Dywan over 1 year ago * **File** 0003-Implement-notification-bubble-interface.diff added Jim, I would appreciate if you can take a look at how I'm approaching this. As I open another monitor in parallel either the notifications or the message list tends to break. For instance I get "INBOX already open" and I'm not sure how to best cope with that. Approach a) is on_folders_added_removed() monitoring the inbox as soon as the folders get listed. Approach b) is do_select_folder(), hidden behind two "#if 0" in the patch. The attempt is to re-use the currently open folder, or otherwise have a separate monitor. #### #26 Updated by Adam Dingle over 1 year ago * **Status** changed from _Open_ to _Review_ #### #27 Updated by Jim Nelson over 1 year ago * **File** 3828-jim.diff added Hi Christian, I looked over your patch and saw what you were trying to do. I decided to clean up the patch a little bit and change some implementation details to show what I was intending this to look like. It would've taken too long to simply write it out here. First, I should mention that your prior two patches won't apply against trunk. The reason is that two of the lines in CMakeLists.txt refer to folks. I think your diff is based off a prior commit in your local branch for auto-complete. I've removed them in the attached diff. Basically, I did the following things (from small to large): * I moved the Gravatar URI generation code into a separate utility namespace. * I refactored a couple of things you were doing into the Engine, as it made sense for it to offer those things. * One thing I should've done long ago: now Geary.Account will return the same Geary.Folder object if the same path is submitted. This makes it easier to do the next bullet point: * Instead of shuffling folders and ConversationMonitors in the various handlers, this patch merely opens the Inbox folder and keeps it open. It attaches to the "locally-appended" signal, which is only fired for email which has not been seen before, not messages re-added to the Inbox (i.e. unarchived). There's some extra steps to be sure we don't close Inbox when changing folders, but it's not too difficult. This patch isn't complete. We need to close the Inbox folder when stopping the application and have inbox_folder use its own Cancellable (marked with TODOs), as we don't want to use the normal Folder cancellable. Also, this works well when multiple emails come in, but when it's only a single email, I don't see a notification popup. (I'm using GNOME Shell, BTW. I haven't tested this on Unity yet.) Let me know what you think. I'll let you pick this up from here -- I think with this patch you see what direction I think this should be headed. #### #28 Updated by Christian Dywan over 1 year ago I love get_primary_originator. Your improvements to falling back and handling errors are much more solid than what I did there. Having build_folder recycle folders is an elegant way to fix main problem I was facing. I have doubts about the Gravatar API - I would actually expect to move consumers away from caring about where avatars come from, in much the same spirit as get_primary_originator(). When we support folks we'll probably always need a chunk of data since we may not have a loadable URI. I'm thinking string Gravatar.get_image_uri should become async Gdk.Pixbuf Avatar.get_pixbuf. This'd also address that notifications aren't required to support URLs. I see single messages in Unity - so this could be notify-osd versus notification-daemon. I'm pondering how to incorporate a test case. I tend to locally add code to send a notification Ctrl+0 because it's cumbersome to send a real message. Postler has a demo mode that among other things fakes a notification, enabled through an environment variable. It's also useful for testing theming since you don't need a developer build. #### #29 Updated by Christian Dywan over 1 year ago * **File** 0001-Implement-notification-bubbles-on-new-mail.diff added Note to self: remember to add ": GLib.Object" to your classes lest you'll see obscure crashes for lack of reference counting. Images in notifications are downloaded dynamically now, avatars are cached in a temporary file, notifications can be prepared() before showing to allow this use case. We could consider caching avatars always in ~/.cache/geary/avatars/ but it might be best to figure that once we have avatars from libfolks working to get the full picture. #### #30 Updated by Christian Dywan over 1 year ago * **File** 0001-Implement-notification-bubbles-on-new-mail.diff added Now inbox has its own cancellable, it cancels if the account switches (is there any we to test this yet?) and when closing. #### #31 Updated by Christian Dywan over 1 year ago One thing to add: the new mail sound isn't shipped with any Ubuntu I think. If that's a problem we need to ship a fallback. #### #32 Updated by Jim Nelson over 1 year ago Hi Christian, To be clear, I'm not trying to create a Gravatar API, I just wanted to move all the logic into a central place. When I looked at the site's spec, I added a few more features in case we wanted to change things (like the default avatar). I too want all this to be handled by libfolks, but with release cycles the way they are, we might not see this feature in general distribution for six months or even a year. So, I'd like to have all this Gravatar stuff in one place rather than interspersed throughout the code. As far as pulling avatars over the wire asynchronously, I'm thinking now we should ticket this separately. I don't want to get in the business of caching avatars -- if anything, we should be using WebKit's caching for this. (Presumably all the network images we load through WebKit is going through its central cache.) I just think there are enough questions about this that we can do this in a different patch. So, for now, let's just show the Geary icon in the notifications. (And hopefully we'll have a better icon soon.) Hopefully this wasn't too much work for you. I can't suggest anything as far as test vectors. I definitely don't like having test code keyed to magic keystrokes in production code -- this should be something compiled in by developers. Until we have a test framework, we should remove this code or #if it out. Finally, regarding inheriting from GLib.Object, what problem were you seeing? Classes that don't inherit from Object do have reference counting, Vala builds its own ref() and unref() methods that use an atomic counter. I feel like the patch is almost ready to commit. If you want to work on it some more, let me know. Otherwise I can quickly make these changes and land it in trunk. #### #33 Updated by Christian Dywan over 1 year ago I mention libfolks because it will not always yield files. It can, but API- wise it can be a blob of data in memory or a stream. libnotify expects file:/// by spec, even if we are not going to maintain a cache. So we have to save the image on disk regardless of where it's coming from. The point of the cache would really be to avoid re-writing the files repeatedly. Vala did not add ref() to the object without GLib.Object here - it errored on a non-existing method. I actually tried because I thought it did. It looked like a reference count problem from the symptoms I was seeing and that indeed solved it. #### #34 Updated by Christian Dywan over 1 year ago * **File** 0001-Implement-notification-bubbles-on-new-mail.diff added Patch without test message and without avatars. #### #35 Updated by Christian Dywan over 1 year ago See issue #5403 for avatars now. #### #36 Updated by Christian Dywan over 1 year ago * **File** 0001-Support-messaging-menu-through-libindicate.diff added Messaging indicator support, based on the previous patch (it relies on the inbox notification work). #### #37 Updated by Jim Nelson over 1 year ago Christian Dywan wrote: > I mention libfolks because it will not always yield files. It can, but API- wise it can be a blob of data in memory or a stream. libnotify expects file:/// by spec, even if we are not going to maintain a cache. So we have to save the image on disk regardless of where it's coming from. The point of the cache would really be to avoid re-writing the files repeatedly. Ok. When we get to the point of using libfolks for avatar support, we'll revisit the issue. > Vala did not add ref() to the object without GLib.Object here - it errored on a non-existing method. I actually tried because I thought it did. It looked like a reference count problem from the symptoms I was seeing and that indeed solved it. Hmm ... that sounds fishy to me. Certainly [Compact] (and, I believe, [SimpleStruct]) classes don't have reference counting, but I've never seen a refcount problem arise from fundamental (i.e. non-Object) types. The problem may've been with our CMake installation. The client code isn't properly dependent on the VAPI our static library generates, so if the ABI/API changes it causes strange compilation and linking problems. Often a `make distclean && ./configure && make` solves the problem. I'll take a look at the patch and commit if ready! #### #38 Updated by Jim Nelson over 1 year ago * **Status** changed from _Review_ to _Open_ First patch is committed: 2c0a210656fddbc1365c48f1b4db3205a5bf0e11 Regarding the libindicate patch, there's a couple of problems: * The patch doesn't apply against trunk now -- I tried applying the patch after the first with no success, but wanted to commit what we had, so went ahead. * The larger issue is, is indicate-0.7 widely available on non-Ubuntu platforms. It looks like a Unity-ism. Since we want Geary to run on non-Ubuntu distros, we need to make this a configure-time option and only use it then. I'd be happy to look at the patch without the second problem worked out. But, as we have people running out of trunk today, I'd only feel comfortable landing this if there's some compile-time magic to turn on this dependency (it should be off by default). #### #39 Updated by Christian Dywan over 1 year ago * **File** 0001-Support-messaging-menu-through-libindicate.diff added This patch includes --disable-libindicate and respective cmake logic. I added two #if in the Indicator class so that no consumers have to care if it's supported or not. I went for a disable switch because in my experience people will assume the feature is absent or broken if it's missing by default, whereas a build error is clear and easy to handle. #### #40 Updated by Adam Dingle over 1 year ago I would strongly prefer that Geary build out of the box on all platforms when the user passes no arguments to configure, including platforms such as Fedora where libindicate is unavailable. Will that work with your patch? If not, can we autodetect in our configure script so that the libindicate code is enabled only when libindicate is actually available? #### #41 Updated by Christian Dywan over 1 year ago * **File** 0001-Support-messaging-menu-through-libindicate.diff added I updated the patch to do what Adam suggests: if no indicators exist, as checked by a glob, the dependency is automatically disabled. #### #42 Updated by Christian Dywan over 1 year ago * **Status** changed from _Open_ to _Review_ #### #43 Updated by Adam Dingle over 1 year ago Christian, I tried your patch. Unfortunately it seems to do nothing: even with two unread messages in my Inbox, the mail icon on my taskbar is still white (I had expected it to turn blue). I'm sure that I compiled with indicator support, since Geary shows this on the console: [deb] 15:03:53 indicator.vala:58: Create indicator [deb] 15:03:53 indicator.vala:38: Add indicator Inbox #### #44 Updated by Christian Dywan over 1 year ago * **File** 0003-Support-messaging-menu-through-libindicate.diff added * **Status** changed from _Review_ to _Open_ Sorry, I didn't realize as I keep Thunderbird open for testing. Actually I found this needs more work on handling the case of updating the count. We probably need to keep track of flag changes and all id's. Updated for working envelope. I'll need to look further into tracking new email id's. #### #45 Updated by Christian Dywan over 1 year ago * **File** 0002-Support-messaging-menu-through-libindicate.diff added * **File** 0003-Implement-unread-count-in-launcher-dock-item.diff added Updated libindicate support following git master. Second patch based on that, adding count to launcher/ dock. #### #46 Updated by Christian Dywan over 1 year ago * **File** 0002-Support-messaging-menu-through-libindicate.diff added * **File** 0003-Implement-unread-count-in-launcher-dock-item.diff added * **Status** changed from _Open_ to _Review_ I seem to never get flag changes, and there's a recurring error which may be related: [deb] 22:20:46 geary-replay-queue.vala:228: Replay local error for [589] FetchEmail: id=48 required_fields=37Fh remaining_fields=37Fh flags=0h on INBOX: Cancelled obtain_lock_async In theory the code keeps track of id's now and updates the count when a message is no longer unread. #### #47 Updated by Jim Nelson over 1 year ago * **Status** changed from _Review_ to _Open_ Hi Christian, I'm still seeing the problems Adam mentioned, namely that it seems like libindicate support is working due to the log but I don't see the envelope icon turn blue or report unread messages. Additionally, it still looks like the configure script is coded to enable libindicate support by default. We'd like the opposite, where it must be explicitly enabled. Is it possible you sent the wrong diffs? Additionally, for the launcher dock item patch, without running it, it looks like if the Unity dock isn't available the code will still attempt to contact it and inform it of changes. Like the first patch, the Unity dock should not be expected, and so if unavailable, there should be no problems or errors. #### #48 Updated by Christian Dywan over 1 year ago * **Status** changed from _Open_ to _Review_ I'm positive the indicator works** for me on Precise. As I mentioned flags updates are not working, but you would definitely see a blue envelope around the time the notification bubble appears. I'm not sure what you mean by errors wrt the launcher - there's a debug message if the DBus service can't be setup. But there's no problem if no dock is running, I actually tested that it'll work fine if you run a dock after running Geary and get new mail afterwards. libindicate is used if the system uses indicators, just like Adam proposed (“can we autodetect in our configure script so that the libindicate code is enabled only when libindicate is actually available”). * What I am newly starting to see now is this, coming from GDBus/ libindicate. Not sure just yet what's happening there, I didn't change the code. Either GLib.Variant is suffering from memory handling problems or libindicate is behaving badly (sadly I can't say I would be surprised). [deb] 00:58:29 indicator.vala:16: Update indicator Inbox: 1 unread (geary:17306): GLib-CRITICAL **: g_variant_ref_sink: assertion `value->ref_count > 0' failed (geary:17306): GLib-CRITICAL **: g_variant_ref: assertion `value->ref_count > 0' failed (geary:17306): GLib-CRITICAL **: g_variant_get_type_string: assertion `value != NULL' failed (gdb) #0 0xb5ea1616 in ?? () from /lib/i386-linux-gnu/libc.so.6 #1 0xb61e3dba in append_value_to_blob (value=<optimized out>, type=<optimized out>, mos=0x861bd88, dos=0x87ab090, out_padding_added=0x0, error=0xbfffed6c) at /build/buildd/glib2.0-2.32.3/./gio/gdbusmessage.c:2135 #2 0xb61e82be in append_body_to_blob (error=0x86f7f28, dos=0x87ab090, mos=0x861bd88, value=<optimized out>) at /build/buildd/glib2.0-2.32.3/./gio/gdbusmessage.c:2193 #3 g_dbus_message_to_blob (message=0x87ab060, out_size=0xbfffeccc, capabilities=G_DBUS_CAPABILITY_FLAGS_UNIX_FD_PASSING, error=0xbfffed6c) at /build/buildd/glib2.0-2.32.3/./gio/gdbusmessage.c:2365 #4 0xb61dc397 in g_dbus_connection_send_message_unlocked (connection=0xb2905030, message=0x87ab060, flags=G_DBUS_SEND_MESSAGE_FLAGS_NONE, out_serial=0x0, error=0xbfffed6c) at /build/buildd/glib2.0-2.32.3/./gio/gdbusconnection.c:1610 #5 0xb61df2fb in g_dbus_connection_send_message (connection=0xb2905030, message=0x87ab060, flags=G_DBUS_SEND_MESSAGE_FLAGS_NONE, out_serial=0x0, error=0xbfffed6c) at /build/buildd/glib2.0-2.32.3/./gio/gdbusconnection.c:1715 #6 0xb61f695e in g_dbus_method_invocation_return_value_internal (invocation=0x85ddcc0, parameters=0x86be608, fd_list=0x0) at /build/buildd/glib2.0-2.32.3/./gio/gdbusmethodinvocation.c:402 #7 0xb6111662 in ?? () from /usr/lib/libindicate.so.5 #8 0xb611280d in ?? () from /usr/lib/libindicate.so.5 #### #49 Updated by Christian Dywan over 1 year ago * **Status** changed from _Review_ to _Open_ After using it for some time I also noticed the badge stays after closing Geary, same issue Thunderbird has, so we probably need to explicitly reset it. #### #50 Updated by Christian Dywan over 1 year ago * **File** 0002-Support-messaging-menu-through-libindicate.diff added * **Status** changed from _Open_ to _Review_ Regarding the crash, apparently Indicate.Indicator.get_property(_variant) always steals the reference and there's no way to ref() Vala. I changed it to a comment we may want to leave as a warning for when somebody is going to look into multiple folder counts, it's no problem at this point. I cannot reproduce the badge staying when Geary quits after solving the above crasher, so it was probably a side effect. #### #51 Updated by Jim Nelson over 1 year ago * **Status** changed from _Review_ to _Open_ I now see the blue badge when I run Geary, but I noticed it only happened when the notification bubble pops up (which it does when I first started Geary, as there were some new emails on the server not yet in the database). From then on, as I read messages, the badge stayed blue and always showed the same number (11), even though I was reading messages (hence, marking them as read). When I exited Geary the badge turned white; that's good. When I re-ran Geary it stayed white and did not display any value for the Inbox although there were unread messages. Only when I sent myself a test message did the badge turn blue and display a number (1), which was not the number of unread messages in the Inbox. Maybe we should revisit what this feature is supposed to do. We expect it (a) to display the number of unread messages in the Inbox, and that value should be accurate at all times (i.e. it should update when the user marks messages as read and unread). (b) the badge should be blue if there are any unread messages in the Inbox. We may in the future want more sophisticated use of the indicator, such as turning it white after reading a message, but that can be ticketed separately. (c) When Geary exits we should "release" the indicator so it does not display Inbox counts, new messages, etc. (Of course, since it's a share resource, other apps may do what they will before and after Geary exits.) It feels like the plumbing is in place, but the above behavior isn't quite implemented. Does this make sense? #### #52 Updated by Jim Nelson over 1 year ago See also our wiki page on our general strategy for Geary status and notifications. #### #53 Updated by Adam Dingle over 1 year ago This ticket covers too much, so I've broken it up into these tickets: #5647 - display new message count in Unity launcher #5648 - support Ubuntu messaging menu See also #5606 - Don't display notification if user is viewing new messages #5607 - Integrate with libindicate and libmessagingmenu #### #54 Updated by Adam Dingle over 1 year ago * **Status** changed from _Open_ to _5_ * **Assignee** deleted (<strike>_Christian Dywan_</strike>) * **Resolution** set to _duplicate_ #### #55 Updated by Charles Lindsay 7 months ago * **Status** changed from _5_ to _Duplicate_ --- Bug imported by chaz@yorba.org 2013-11-21 20:25 UTC --- This bug was previously known as _bug_ 3828 at http://redmine.yorba.org/show_bug.cgi?id=3828 Imported an attachment (id=260877) Imported an attachment (id=260878) Imported an attachment (id=260879) Imported an attachment (id=260880) Imported an attachment (id=260881) Imported an attachment (id=260882) Imported an attachment (id=260883) Imported an attachment (id=260884) Imported an attachment (id=260885) Imported an attachment (id=260886) Imported an attachment (id=260887) Imported an attachment (id=260888) Imported an attachment (id=260889) Imported an attachment (id=260890) Imported an attachment (id=260891) Imported an attachment (id=260892) Unknown milestone "unknown in product geary. Setting to default milestone for this product, "---". Setting qa contact to the default for this product. This bug either had no qa contact or an invalid one.