liferea should be added to the indicator applet

Here is a patch adding the messaging indicator, tested against version 1.7.4. A PPA with this patch applied can be found here: https://launchpad.net/~sikon/+archive/liferea-libindicate

Same patch, but for upstream SVN - I'll send it upstream. Differs from the previous one only in configure.ac.

The patched version falls back to the tray icon if the indicator applet is not present. If it is, it doesn't even show the preference checkboxes for configuring the tray icon.

This works nice, a couple of issues though:
1. I'm using Google Reader as a single feed source, and the "Google
Reader" menu, while taking me to Liferea and opening the "Google Reader"
item in the left, doesn't display anything on the right.

2. The translations err a bit - do they differ from the Lucid version?

For Google Reader, it is in fact supposed to display each subitem separately. That it doesn't display a separate counter for each subitem and instead presents one for the entire source is my oversight, and I'll fix it.

Thanks Maia!

Another thing: when Liferea is activated, the messaging icon should become grey again (per https://wiki.ubuntu.com/MessagingMenu/#Title).

The problem here is that, even though you bring Liferea to the front, there are still unread messages. The indicators will go away when you mark the messages as read. This is because, unlike in an IM client, messages aren't automatically marked as read when you open the window.

From a technical perspective, the way it's implemented now, performing any action that can update the unread message count causes Liferea to rebuild all indicators. So, if you have 5 unread messages in a feed, and read one, you get an indicator for 4.

There are in fact two more minor problems in this patch:
- The number of indicators isn't limited, so 100 unread feeds mean 100 menu items. The specification recommends at most 6.
-

Also, upstream doesn't like this patch because it uses an Ubuntu-specific library, in Ubuntu-specific ways. So we'll apparently have to carry the divergence until the indicator libraries become part of standard GNOME.

Er. The other minor problem is a mistake in configure.ac that breaks --disable-libindicate - irrelevant for the archive since we'll always build with libindicate, but something that should be fixed for aesthetical reasons regardless.

Another issue with this patch: if the indicator applet is reloaded, the normally-hidden tray icon appears alongside the indicator until Liferea is restarted.

One way to fix the "when Liferea is activated, the messaging icon should become grey again" issue would be disabling indicator updates while the Liferea window is active.

another issue, I think envelope should be colored only, if new articles are occurred (when liferea is minimalized and notify is shown like Evolution)

В Вск, 09/05/2010 в 09:25 +0000, Maia Kozheva пишет:
> The problem here is that, even though you bring Liferea to the front,
> there are still unread messages. The indicators will go away when you
> mark the messages as read. This is because, unlike in an IM client,
> messages aren't automatically marked as read when you open the window.

Evolution, on the other hand, grays the indicator as soon as its window
is opened, while everything I see of the new messages is "Bugs (1)" or
"Inbox (2)".

New version of the 1.7 series patch.

    - Bring the Liferea window to front in liferea_shell_activate
      (makes indicators bring it to front if it is already open).
    - When an indicator is clicked, remove it and the draw attention status
      of other indicators, and block further indicator updates while the
      Liferea window is active.
    - For items with subitems (such as a feed source), show one indicator per
      each subitem separately.
    - Limit maximum number of indicators to 6 (MAX_INDICATORS).

And here comes a patch for the sponsors - the previous patch backported to 1.6.2-1ubuntu6.

Note to sponsors: this patch modifies configure.ac and two Makefile.am's, so it will need an "autoreconf" - either invoking ./autogen.sh in rules, or a separate really large autoreconf.patch.

An alternative would be to hack into the upstream build system instead of letting autofoo regenerate it. Here is what needs to be done:
- Adding src/ui/ui_indicator.c and src/ui/ui_indicator.h to sources.
- Adding libindicate headers to the include path.
- Linking with libindicate.

The new patch introduces a problem with Google Reader: the "attention" status will be dropped only when I click on the subscription item, not on "Liferea" item.

I have to second Alexey's report:
Since the new patch, the indicator does not disengage its notification-status until I clicked each & every single feed-source listed under Liferea in the indicator-applet. This breaks usability for the whole indicator-applet as it is now always in the "Need attention" mode.

I'll correct this in the PPA today, thank you.

Do you think it would be reasonable behavior to remove *all* feeds from the indicator menu when clicking one of them brings up the Liferea window? You can see the unread feeds in the window itself after that.

> I'll correct this in the PPA today, thank you.
Thanks for keeping this up!

> Do you think it would be reasonable behavior to remove *all* feeds from
> the indicator menu when clicking one of them brings up the Liferea
> window? You can see the unread feeds in the window itself after that.
Yes. This way, for example, I will know that a new mail has arrived in
Evolution while I'm busy reading the news.

@Maia Kozheva:
I'd say it only makes sense when all feeds are ALSO removed from the indicator when I click the main "Liferea" entry (the parent-element). Otherwise people would lose the ability to open Liferea with the "Unread" category because clicking on one specific feed-entry in the indicator opens Liferea with that specific feed opened and not with the global "Unread" category.

Thank you for patching this!!

Sorry, I meant the attention status should be removed... for the lines, the wiki states:
"Selecting an item from the menu should send the associated signal, and also remove the item from the menu."
So the other items should stay.

But that's what the current code does! It removes the one item that was clicked and resets attention status from the others.

Perhaps *closing* the Liferea window should remove all indicators? As it is currently implemented, if you click some indicators now, then close the Liferea window, the other indicators will stay in the menu until the next scheduled feed update.

Maia:

I am using the "Unread" function of Liferea. Therefore, ALL unread items are listed there once I've opened the program-window.

Because of that, my proposal is that all feed-indicators simply open the main Liferea window like the main indicator-entry "Liferea" does.

Here's why: We simply do not know how a user has setup his/her Liferea. For example: If someone clicked on a specific feed entry now, you force Liferea to show the headlines only of that specific feed-entry. But people (like me!) have setup their Liferea without any left pane, so that clicking a specific feed opens up the list of recent articles of that feed - but without left pane I am left to wonder what that feed actually was.

I have never used single-feed view in Liferea - therefore I was really irritated when I clicked on a feed and my beloved feedreader showed me a strange view of some feeds that were clearly not from the global "Unread" category I saw last when closing Liferea before.

Right now, you'e basically f* with the user's experience because Liferea opens up in a way in which they did not leave it behind the last time they viewed their feeds. When closing Liferea, it remembers which view had been selected last, which panes are visible etc. Therefore, your indicators MUST also open up Liferea in the same way users left it. Otherwise you're confusing people - like me. :)

The possible solutions I see are:
a) Perceive the specific feed-entries in the indicator-applet merely as simple previews of what's new. But clicking them only opens the main Liferea window (like the user left it!) just as if they had clicked the main Liferea entry in the indicator-applet.
b) Completely kick out the specific feed-sources listing in the indicator-applet and simply show the line:
"[ICON] Liferea (123)"
So basically the main Liferea entry in the indicator applet, but with the total sum of new, unread feeds listed in brackets behind it. Clicking it also must only open the main Liferea window like the user left it behind.

What do you think?

A small addition:
Option b) - Kicking all specific feed entries - has also the benefit of getting rid of the annoying flickering the indicator-applet currently shows when Liferea is updating its feeds.

Right now, it is next to impossible to click on any entry in the indicator-applet while feeds are being updated because feed-source entries are being posted & removed from the indicator-applet in a matter of milliseconds. Anything listed below the "Liferea" entry in indicator-applet thus is pushed & pulled up&down rapidly while Liferea is updating feeds. That makes these entries (for me that's Pidgin & Pino) impossible to click.

So I'm strongly voting for option b).

Clicking the main "Liferea" menu item (rather than a specific indicator) opens the window in the state in which it was left when it was last closed, without jumping to any specific feed.

> Liferea opens up in a way in which they did not leave it behind the
> last time they viewed their feeds.
No, the design spec I pointed earlier says each item should open the
most relevant view.

> The possible solutions I see are:

> a) Perceive the specific feed-entries in the indicator-applet merely
> as simple previews of what's new. But clicking them only opens the
> main Liferea window (like the user left it!) just as if they had
> clicked the main Liferea entry in the indicator-applet.

> b) Completely kick out the specific feed-sources listing in the
> indicator-applet and simply show the line:
> "[ICON] Liferea (123)"
> So basically the main Liferea entry in the indicator applet, but with
> the total sum of new, unread feeds listed in brackets behind it.
> Clicking it also must only open the main Liferea window like the user
> left it behind.
> What do you think?

Say there's a noisy feed and a much more interesting, but rarely
updating, one. I'll happily click on the interesting feed item and read
just it, leaving the noisy one for later. So:
(a) contradicts the design guidelines (posted earlier here) - I'm
expecting to see my feed when I click it!
(b) is a good option, configurable like this: "[x] Include individual
feeds".

@Alexey:
You're right about the fact that clicking a specific item should open up that item and not anything different. Still, this can be confusing for people like me who never navigate through single feeds (and have no left pane), but only use the global "Unread" view.

I like your proposal for option b) very much! It would solve all problems: People accustomed to single-feed view could set the "[x] Include individual feeds" marker - like you proposed - and people who only use Liferea's unread-category could deactivate this extra functionality to only see the one-line entry in the indicator-applet.

Clicking the one-line entry should of course reset the notification-status of the indicator-applet.

So, here's the plan for new behavior I'm going to implement:

Clicking on any item in the indicator menu brings up the Liferea window and removes *all* subitems from the indicator menu, leaving only the main "Liferea" one.
If the main item is clicked, the window is shown in the state it had when last closed/minimized/deactivated.
If one of the subitems is clicked, its corresponding feed is selected.
The indicator menu is not updated as long as the Liferea window is active. For example, pressing the update button in the window itself and leaving it in the foreground will not highlight the indicator icon.

As for the setting... I'm really not keen of the idea of introducing non-upstream-compatible gconf keys for something comparatively trivial like this. Ultimately, it depends on what the core developers want to do, since upstream doesn't want a patch for Ubuntu-specific features.

@Maia:

Sounds awesome! And you're right concerning upstream-compatibility.

The only thing it does not fix is the mentioned flickering while Liferea is updating its feeds. The items in the indicator-applet become almost unclickable during that time. Should I open a new bugreport for this?

Everything is now working great!

One last (I believe) thing is when Liferea starts and its window has
focus, it shouldn't set "attention" status when it discovers unread
items.

Updated the PPA 1.7.4 patch. Clicking an indicator should no longer recreate the indicator list while the window is opening (and thus won't force you to click an indicator twice to make the notification go away).

Also backported the fixes to 1.6.3 - I think it is time for a sponsorable debdiff now.

liferea (1.6.3-1ubuntu2) maverick; urgency=low

  * Added libindicate.patch: messaging indicator support. (LP: #540490)
  * debian/control:
    - Depend on automake and libtool.
  * debian/rules:
    - Run autogen.sh to regenerate build system for indicator support files.
    - Run configure in --disable-maintainer-mode.
    - Unquote -Wl,--as-needed in LDFLAGS.

 -- Maia Kozheva <email address hidden> Sat, 19 Jun 2010 01:32:55 +0700

Thank you for the patch and forwarding upstream. Since upstream comments don't seem very enthusiastic about including the patch, I'd encourage this be brought to the attention of ayatana folks and we include this as a distro patch.

Nigel: This is failing to build for me on maverick, can you please look into it?

libtool: link: gcc -g -O2 -g -O2 -Wl,-Bsymbolic-functions -o liferea attention.o bacon-message-connection.o browser.o comments.o common.o conf.o db.o dbus.o debug.o e-date.o enclosure.o export.o favicon.o feed.o feed_parser.o feedlist.o folder.o html.o htmlview.o item.o item_state.o itemset.o itemlist.o metadata.o migrate.o net.o newsbin.o node.o node_type.o plugin.o render.o rule.o script.o social.o subscription.o update.o main.o vfolder.o xml.o -pthread -Wl,--export-dynamic -pthread -pthread -pthread -pthread -Wl,--as-needed parsers/libliparsers.a fl_sources/libliflsources.a notification/libnotification.a ui/libliui.a webkit/libwebkit.a /usr/lib/libgconf-2.so /usr/lib/libxslt.so /usr/lib/libsqlite3.so /usr/lib/libglade-2.0.so /usr/lib/libxml2.so -lwebkit-1.0 -lsoup-2.4 -lSM -L/lib -lnm-glib /usr/lib/libnotify.so /usr/lib/libgtk-x11-2.0.so /usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgio-2.0.so /usr/lib/libpangoft2-1.0.so /usr/lib/libgdk_pixbuf-2.0.so -lm /usr/lib/libpangocairo-1.0.so /usr/lib/libcairo.so /usr/lib/libpango-1.0.so /usr/lib/libfreetype.so -lfontconfig /usr/lib/libgmodule-2.0.so -lindicate -ldbusmenu-glib -ldbus-glib-1 -ldbus-1 -lpthread /usr/lib/libgobject-2.0.so /usr/lib/libgthread-2.0.so -lrt /usr/lib/libglib-2.0.so -pthread
collect2: ld terminated with signal 11 [Segmentation fault], core dumped
ui/libliui.a(libliui_a-ui_indicator.o): In function `on_indicator_clicked':
/home/ken/Desktop/liferea-1.6.3/src/ui/ui_indicator.c:71: undefined reference to `feed_list_view_select'

Thanks

New rebased debdiff, since a -1ubuntu2 was uploaded since then.

Your debdiff from comment #33 does build for me in pbuilder, but it is missing a build depends for libindicate and doesn't explicitly enable libindicate so it builds without indicator support. If you add the build depends and enable it with configure i get the same failure in pbuilder for maverick.

Okay, reattached. Turns out I was trying to call a function that is named differently in 1.6 and 1.7. Also added libindicate-dev to debian/control, slipped past me when backporting.

Slightly modified patch, this includes a launcher to embed in the messaging menu so liferea can be launched directly from the menu and specified a minimum version for the libindicate-dev build-depends.

A couple comments on the actually behavior:
 * I noticed while it was refreshing the icon would keep changing color, kind of flickering. I suspect this is because draw-attention is being set on it as the feeds are being refreshed.
 * I don't think liferea should set draw-attention at all, the intention of that is for important messages that need somewhat immediate attention. I think of RSS feeds as rather passive, read them when you can as opposed to an IM that might require a response within a few minutes. Setting draw-attention everytime liferea refreshes will make that property less effective for IMs, calls, emails, etc.

The flicker is caused by ui_indicator_update() removing the old indicators before adding new ones, and the way liferea's ui_tray_update() (which calls ui_indicator_update()) works means it happens after updating every feed, I couldn't find a way to hook it after the entire update is complete. I could work around this by first adding new indicators and then removing old ones, but if, as you said, it's better to remove the draw-attention hint, I'll do just that.

New debdiff, with the draw-attention hint #ifdefed out.

Hallo, I found one issue

Everytime I start liferea, then envelope goes green, but I think, it should go green only if new articles are occured (I don't mean unread articles)

I think the debdiff in comment #39 works well, thanks!

Converted to dh_autoreconf

This bug was fixed in the package liferea - 1.6.3-1ubuntu3

---------------
liferea (1.6.3-1ubuntu3) maverick; urgency=low

  * Added libindicate.patch: messaging indicator support. (LP: #540490)
  * debian/control:
    - Depend on libindicate-dev, automake and libtool.
  * debian/rules:
    - Run autogen.sh to regenerate build system for indicator support files.
    - Run configure in --disable-maintainer-mode.
    - Unquote -Wl,--as-needed in LDFLAGS.

  [Ken VanDine]
  * debian/control
    - Specify version libindicate build depends (>= 0.3.0)
    - change build depends for automake and libtool to dh-autoreconf
  * debian/rules
    - explicitly enable libindicate with configure to avoid accidentally
      getting builds without libindicate support
    - use dh_autoreconf instead of running autogen.sh
  * debian/liferea.install debian/liferea.indicate
    - Install a launcher to appear in the messaging menu
 -- Maia Kozheva <email address hidden> Wed, 14 Jul 2010 22:39:01 +0700

Shouldn't there be an option, to let the user choose, if he wants Liferea in the Indicator menu or the get the old behavior? I just upgraded to 10.10 and must say, that I don't like it to be in the indicator menu. Is there a way to force it manually to the old style?

Just uninstall indicator-appmenu and the fallback for all applications indicator will be the systray.

Correction: Since Liferea uses the messaging menu, the least intrusive way to get rid of it would be to remove indicator-messages. indicator-appmenu is the global menu bar.

As lucidfox rightly noticed, it's the messaging indicator which is used there. So either removing indicator-messages or removing the messaging applet should work.

This is in response to #44 to #47

One 'official' way of turning off the use of indicator-messages is to blacklist the app (e.g. a symbolic link in ~/.config/indicators/messages/applications-blacklist/). However, I cannot get this to work for Liferea, which may be a bug.