Enhanced Notification Preferences

After a discussion started by Richard Hughes on the mailing list and in his blog I have got at least 6 different requests for having the tray icon new item count display as an optional feature (or not at all). While I would have preferred for some of those wishing to have this choice to supply a patch I ended up doing it myself.

This is the new notification preference option group:



The default setting for the new count display will be disabled. So if you do want to use the feature which was on per default in 1.2.7 please take the time to switch it on.

If you are familiar with the preferences you will notice the second new preference "Terminate instead of minimizing..." which solves another problem with the tray icon usability. Among different applications and interface guides there are quite different opinions for the right behaviour of an application with a tray icon when the last window is closed.

This option which is disabled per default (matching the behaviour of older releases) allows you to configure this behaviour.

Last but not least the question about the usability of these configuration flags. From the usability standpoint I think they are definitively too much options, but due to the non-standardized behaviour of tray icons there is no better way than to let the user decide or to enforce the developers view. In this case there is so much negative feedback that I fear the options are justified.

To be released with 1.2.9

Negative Counters

Just a short note: everyone waiting for a fix of the negative new/unread count problem please be patient some days more. I promise to provide a fixed version as soon as possible!

Surviving Hotel Proxy Hell

Ever been to a hotel and used the local internet access? While the local proxy doesn't influence browsing very much it can be devastating to a feed reader. Some insane proxies do return permanent redirects for every HTTP resource you request through it. For a feed reader this means that it rewrites the URLs of all your subscriptions. And you won't notice until you are home again when all those "new" proxy URLs are invalid.

While the problem clearly is with the proxy, which should serve temporary redirects only, there is still the question how to recover from this. Since Liferea 1.1.4 your original subscription URLs are stored in the feed cache, so that it can be used to recover the now invalid URLs.

There is no way to do this in the GUI though, I just see no simple way to provide a GUI based restoration interface. As an alternative I advise you to use this script. After downloading it, terminate Liferea and run it as follows:

   $ sh recoverFromProxyHell.sh > feedlist.opml 

After successful execution (depending on the number of your feeds this can take some time) please check the contents of the created file before copying it to ~/.liferea_1.2/feedlist.opml and backup the old feedlist.opml as necessary.

For completeness: If you value your feed list back it up regularily!

Improving Performance

With the recent release of 1.2.8 I decided to do another significant change in the stable release series of Liferea. I need to thank Matthew Garrett for suggesting a patch to change the internal link list item searching to a hash table based one. Matthew like some other users I know about set the default cache size to a very high value, effectively disabling the cache limit. As a result he suffered significantly from the linear item searching that is necessary on different user interactions.

Now while the hash table lookup improves speed directly for his use case it also does for the default use case with a cache limit of 100 items, but for another reason. And here is why: while trying to find a way to merge the patch I found that I cannot simply use a single hash map to provide a more efficient way to find items in a given item set (e.g. a feed, all items in a folder, all items matched by a search folder...). While there would be the possibility to construct a hash key out of the item number (which is unique per feed) and the feed id, it is easier to have a two level hash structure where there is first a hash of feeds whose items are in the item set and for each feed an own hash containing the item references for each item number.

This simple decision was derived just from the necessity to integrate the patch. But after looking at the search folder code I found that using the new item set lookup structure it could be significantly simplified, because search folders do require exactly this type of searching on exactly this type of hierarchical item list. So merging the patch uncovered a misdesign, a missing abstraction which wasn't obvious before but that made realizing search folders more easier. And more importantly: even more performance gain, even for smaller cache sizes!

So what do we learn from it?

Submitting patches is still one of the best ways to improve your programs!

Get In Contact

#liferea at freenode.org

Feed List Recovery

During the last month I've learned of four cases of feed list loss. While the reason is not 100% clear, it is hard to debug once it did happen, I found at least one issue with the error code handling in the feed list saving logic, that could cause data loss.

Now before I show you a way to recover the feed list some general hints:

• Ensure you are running version 1.2.7+
• Backup you feed list!
  

Now let's assume you have lost your feed list and Liferea comes up with an empty or the default feed list. There is an relatively easy way to recover all feeds and there contents. This is possible because the per feed XML cache files do contain the feed title and source URL. So a simple script can be used to extract those and to generate a new OPML file to be used as the feed list.

To automatically scan the cache and create a feed list file you can use this script: recoverFeedList.sh. To run it call it like this:

    $ sh recoverFeedList.sh > feedlist.opml

After successful execution (depending on the number of your feeds this can take some time) please check the contents of the created file before copying it to ~/.liferea_1.2/feedlist.opml.

Note: the script will not restore the folder hierarchy, search folders, OPML subscriptions and news bins (to do this more manual work is necessary).

Results of the GNOME Poll

The current results:

Liferea should use GNOME: 14 votes
Liferea not based on GNOME: 4 votes