01 November 2007

File Permissions Vulnerability

Version 1.4.6 fixes a filesystem permission vulnerability of the feedlist.opml backup file. The backup file created by versions before 1.4.6 has weaker access permissions than the original file. This can expose your feed authentification configuration to malicious users.

Please upgrade to 1.4.6!

19 October 2007

Filtering Planet Feeds

Liferea user Enrico Zini explains in his blog how to filter the "Debian Planet" feed using a compact Python script. This script uses Lifereas per-feed filtering feature to supply downloaded feeds on stdin for a user script to read, which then writes the transformed feed output to stdout so that Liferea can use the filtered/transformed feed.

15 October 2007

Improved Namespace Coverage

SVN trunk (1.5) now reads more namespace infos. There is support for the Yahoo Media (alternative enclosure format), the iTunes (summary text, author, keywords) and the Trackback namespace (original post link). All those metadata is now merged with the default news item information.

Although these namespaces might not be widely used if one or two of your feeds do use them Liferea will now provide you a bit more information than before.

01 October 2007

Atom Link Blog Support

Beginning with 1.4.5 Liferea will render Atom feed links with attribute rel="related" and rel="via". These two link types do allow Atom generators to express the typical link posting life cycle. The "via" link says where you got the link from and the "related" link points to the interesting source.

By displaying those links in the item header Liferea now allows you to follow the so-called link blogs that mostly provide you with link dumps instead of HTML text content with embedded links.

27 September 2007

Liferea with OSX Themed GNOME Desktop

Ever considered using your GNOME desktop as a better OSX? No? Well, Lauri Taimila did and along with an extensive article on how to configure the GNOME desktop to look like OSX also created a Liferea icon theme to match.

While doing so he also found that Liferea is not compatible with the GTK icon scheme design, which allows theme providers to easily exchange application icons to better match the theme. This is something that is still on my todo list...

26 September 2007

Data Loss Bug in 1.4

Hmmm... Another serious bug. This one affects all 1.4 releases until now and is fixed with 1.4.3b. The effect is that flagged items are dropped out of cache like normal (unflagged) items. With this behaviour you will propably have lost all your old flagged items. Newer ones will propably not be affected.

How to verify this: Check your "Important" search folder. Sort by date and look for the oldest flagged items you can rememeber.

Workaround: If you cannot upgrade to 1.4.3b right now please set a very high feed cache size in the preferences and thereby disable the cache dropping.

Solution: upgrade to 1.4.3b

How to recover data: To be honest this is pretty hard. If you just migrated from 1.2 to 1.4 and didn't delete ~/.liferea_1.2 I'd suggest to remove ~/.liferea_1.4, thereby loosing all intermediate changes and to automatically remigrate again. This is a way to recover old important flagged items in case you value those more than the recent new items and their state changes.

If you have questions join the IRC channel (#liferea at freenode) or the mailing list. Sorry to everyone that lost flagged items this way!!!

24 September 2007

Dangerous bug in 1.4.2b

There is a pretty bad bug in 1.4.2b (but not in 1.4.2). If you have set the global feed update interval to 0, which normally means do not update any feeds per-default, the bug causes every feed to be updated continuously.

Please update to 1.4.3!

Workaround: If you are using 1.4.2b please ensure your default update interval is not set to zero!!!

Webmasters: Sorry!!! If you are hit by traffic from an 1.4.2b installation I'd suggest to block the user agent (e.g. "Liferea/1.4.2b (Linux; en_US; http://liferea.sf.net/)")! Using HTTP 410 you could also tell Liferea to stop updating permanently.

19 August 2007

Contributions to 1.4

Just to say thanks here I compiled an unordered list of all the people who have contributed for the upcoming 1.4!

Bart Kreska, Emilio Pozuele Monfort, tsukasa, Eric Anderson, mooonz, Emanuele Grande, Ihar Hrachyshka, Sargate Kanogan, Takeshi AIHANA, Aristotle Pagaltzis, Khaled Hosny, Fernando Ike de Oliveira, Dario Conigliaro, Alexander Hess, Vincent Lefevre, Daniel Nylander, Luis Rodrigo Gallardo Cruz, Mehmet Atif Ergun, Jean Diraison, p3pilot, Og Maciel, Frank Pletz, Hubert Figuiere, Gilles Gravier, Iñaki Larrañaga Murgoitio, jtjt, Arjan van de Ven, Mike Auty, Ori Avtalion, Joseph Sacco, Aaron Crane, Christian Dywan, Benoît Dejean...

I'm pretty sure I forgot the one or the other, but nonetheless thanks to everyone who helped!

09 August 2007

Experimental WebKit Support

After the media buzz about Epiphany supporting WebKit I wanted to see how it works and if it is a viable alternative to Mozilla/XulRunner. So I added an experimental WebKit rendering plugin to the 1.4 sources. With the help of the nice guys in #webkit (freenode.org) it took only some hours to compile WebKit and create a simple browser test plugin. Besides some specific features like mouse cursor change, zooming and automatic scrolling on next-unread everything works as it should. Wether WebKit can be really used as a HTML rendering library for Liferea of course depends on the availability of the library itself in the Linux/Unix distributions out there. At the moment most distributions do not yet provide packages to compile against, so I assume not many end users can use WebKit at the moment.

24 June 2007

Transparent Tray Icon

Since several releases the tray icon transparency was broken. After giving up on fixing it for several weeks with several implementation prototypes the current releases now make a compromise:

  • No transparency (only theme background color) when you have the tray icon with new count display enabled.

  • Full transparency when you have the tray icon without new count enabled.

The reason why transparency does not work with new item count display enabled is that to draw the number one has to aquire and install a GTK drawing widget which itself is not transparent and additionally there is no reasonable way to get the "real" background below the widget to draw it into the widget whenever necessary (first rendering, after panel movement, after panel sliding...).

So to allow the user to decide how important transparency is, for the configuration variant without new item count rendering, the old code supporting transparency (using a GtkImage widget) is used. And if you absolutely want to see the new item count number you have to live with a non-transparent icon background, which should be ok when you use non-transparent panels. To change the settings have a look at the preferences tab "GUI".

Solution in upcoming 1.2.18 and 1.4-RC1

16 June 2007

Menu Reorganisation

After thinking a lot over it, here is my most recent try of a logical menu structure.

Update All
Mark All Read
Add Subscription
Add Folder
Add Search Folder
Add Source
Add Newsbin
Import from OPML
Export as OPML
Mark As Read
Remove All Items
Next Unread
Toggle Read Status
Toggle Item Flag
Launch In Browser
Increase Text Size
Decrease Text Size
Normal View
Wide View
Combined View
Update Monitor
Script Manager
Quick Reference

Everyone who misses "Edit": with me in a program which does not do the sligtest bit of editing will never have an editing menu. And the same for a "File" menu. The good thing is even the HIG agrees that "File" does not always apply and often the first menu can simply be the object the program is primarily about (e.g. "Game" or "Subscriptions").

So what do you all think?

11 June 2007

Localized Default Feed List

To help new users trying out Liferea and maybe to learn about a feed reader for the first time Liferea loads a default feed list of about 20 example feeds on the first startup. There is a English default feed list but there are also default feed lists (containing both an English part and localized example feeds) for the following languages:

bg ca de es eu fr nl pl ru sk sv

If your native locale is not among them contribute a default feed list with your favourite feeds in your own language! The only criteria: the feeds should be unpolitical, with general agreeable content and of websites where you can be sure that the webserver can handle the traffic. If you want to create a example feed list just export your feeds using the "Program" menu, open the OPML file in an editor and remove the lines with all feeds you do not want to be included. Finally post the feed list in the patch tracker or in the mailing list.

10 June 2007

Improved Proxy Preferences

One improvement coming with the next unstable release 1.3.7 is a bit more intuitive proxy configuration. So here is like it currently (1.2.x) looks:

and here is the new interface:

While the changes do seem cosmetical at first the rewrite also solved some problems in the code behind it. So until now Liferea just reused the GNOME proxy gconf keys as it's own. Thereby you could mess up other GNOME programs from within Liferea. Also due to the limited options until now you couldn't use the environment $http_proxy variable to overrule manual settings. There was also no way to enforce no proxy when $http_proxy was set. These configuration variants are now covered by the improved dialog.

And finally: no explanation text anymore about the handling of the GNOME proxy preferences.

09 June 2007

Freeing Memory...

From time to time you might look at the memory usage of Liferea and you might ask what does it need that much RAM for? And often it is just leakage that causes such high allocation. In fact the next release 1.2.17 will fix two leaks discovered and fixed by Hubert Figuiere.

At the moment it is quite hard to debug memory issues in Liferea because the termination code does not clean up all used memory. This makes it hard to distinguish between lost and just not free'd pieces of memory when using tools like valgrind.

And the reason why there is no complete clean up on shutdown? Laziness and poor design. In fact without having a clear object hierarchy destroying structures without knowing all implications can cause crashes. Also there are a lot of static unwrapped pseudo-global data structures without a good way to free them. And last but not least: freeing complex glib structures in C is ugly and no fun at all.

The good news: with the current 1.3.x branch I started to clean up this mess. As a first step I'll try to clean up as much data structures as possible without a major redesigns and on the long term there will be rewrites...

Want to help? But you do not have the time to write code? Do a review, look through the code and send in a code review!

05 June 2007

64bit Test

Good news for all 64bit users. I now own a AMD64 laptop and can now test on 32 and 64bit. I think this will improve stability and reduce cross platform programming mistakes (already found some type mismatches).

Power Consumption Issues

A lot of users did report that current Liferea 1.2.x releases did waste a lot of CPU cycles. For laptop users this means a significantly higher power consumption. After a crucial hint by Liferea user jtjt the problem is now fixed beginning with version 1.2.16b.

When you use "powertop" now to check the idle activity you should see something similar to this
0.7% ( 2.3) liferea-bin : futex_wait (hrtimer_wakeup)

compared to the previous extreme results in this range:
47.4% (196.0) liferea-bin : futex_wait (hrtimer_wakeup)

Thanks to everyone who helped debugging these timer problems!!!

05 May 2007

Flash 9 Problems

As you propably already know Liferea allows to play MP3 enclosures in the application using the XSPF flash player. When you update your local Flash installation to Flash 9 you might see an error message similar to the following when trying to play some MP3.

The error is caused by missing priviledges of the Flash file installed with Liferea. Beginning with Flash 9.0 there seems to be a stricter checking for Flash applets.

The problem will be solved in the upcoming releases 1.2.14 and 1.3.4. If you want to fix the problem yourself you can download the Flash Local Content Updater from Adobe and run the following command to add the missing priviledges:
   $sudo ./LocalContentUpdater -a /usr/share/liferea/media/xspf_player_slim.swf

Please adapt the "/usr" path prefix to match your Liferea installation.
Much thanks go to tsukasa for pointing this out (German blog post).

22 April 2007

1.3.x Progress

The 1.3 development is coming along very well. With todays release 1.3.3 there is a pretty reliable implementation for the old problem of how to determine the number of unread items of each feed and folder in the feed list.

What is missing is the calculation of the unread count for search folders which is pretty problematic. Search folders are internally realized with sqlite views and every item modification can change the unread count of each search folder. So the only way to update the unread count of all search folders after a user interaction is to recount it for each search folder or to determine which of the search folders was affected and to increment/decrement the unread count appropriately.

The disadvantage of both solutions is that the unread count update processing time increases directly with the number of search folders. Choosing to recount on each update additionally decreases performance with a growing total number of items, while the delta processing depends on the matching rule complexity.

Anyone knows a good design pattern for realizing such a dynamic counting functionality?

13 April 2007

First 1.3.x series release

Today I created the first release in the new unstable series. It introduces a sqlite backend and simple comment feed support. This release is intended for development purposes only, so that one can compare 1.2.x and 1.3.x performance. I invite everyone interested in getting Liferea faster to have a look at the DB schema (src/db.c) and the current access patterns. Reviews!!!

If you want to try 1.3.x you can run it without influencing 1.2.x. It will create an own cache directory ~/.liferea_1.3 and migrate the 1.2.x cache automatically on the first startup (which might take some seconds).

This release is not intended for production. It is missing several features (searching, search folders...), that I hope to add in the next weeks again. For testing you should be able to use the basic feed reader features.

11 April 2007

Liferea & AWN

Do you use AWN (Avant Window Navigator)? Want to display the number of unread or new items in Liferea with AWN instead of using the system tray? Liferea user tsukasa has created an AWN plugin using the LUA scripting support to do exactly this!

23 March 2007

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

22 March 2007

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!

19 March 2007

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!

14 March 2007

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!

07 March 2007

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).

02 March 2007

Results of the GNOME Poll

The current results:

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

27 February 2007

Liferea & GNOME

During several code reorganisations for the slowly progressing sqlite support I thought a lot over the ugly things in Liferea (podcast support, media playback, own network code, proxy preference) and ways to overcome them. One conclusion was that one reason for those quality problems is the missing platform. Its hard to admit but Liferea's platform SW stack is to small.

Examples for this is the need for high-level rendering provided by libxul while at the same moment implementing own networking. Or of searching for a way to play podcasts and use the ugly solution of a Flash plugin.

The topic of using GNOME was discussed on the list some times and I usually argumented with high efforts and massive dependencies. I now think at least the first point is incorrect and the other point might have lost its strength because I believe most users running Liferea along with a GNOME installation.

So should Liferea move to GNOME? Are there more benefits than repelled users? What do you think?

To get more opinions on those questions I did ask for advice on gnome-list@gnome.org. If you are involved with GNOME and use Liferea please join the discussion there!

24 February 2007

DB Backend Progress

Here is a short update on the 1.3.x progress. The promised comments support already works properly and is available from SVN HEAD. The rewrite with a DB backend using sqlite has started and there is a first prototype able to load and write items to the database. During the first integration work the necessary work became much clearer and I think the effort is now more predictable. My current estimation is somewhere between 3 to 6 months until a first stable version.

As always I want to motivate everyone to join development. You don't need to bring anything with you beside a little bit of C coding knowledge and time to spend. After all how many users are out there? And what is a good user/developer ratio? While I think 100/1 might be normal is 1000/1 also ok? Anyone knowing about typical open source numbers?

08 February 2007

Item Duplicate Detection

The new release 1.2.6 introduces a solution for item duplicate detection. My goal was to make a simple unobtrusive implementation that will avoid encountering the same article twice as unread.

Here is what it does:
  1. When rendering an item which is duplicated in other feeds there will be an extra "Also in [feed]" header line for each feed with a duplicate.
  2. When changing the read state of an item with duplicates the read state change will be propagated to all other duplicates.
An open problem is the question what should happen when a new duplicate item arrives after reading a copy of it. Should it be added as unread or changed to match the state of all other duplicates? Is one interested in the fact that a new blog posted the same item?

Well the current implementation does add the new duplicate as unread (leaving the older duplicated items as they are). This has the advantage of being noticed that the item was posted somewhere else. But depending on the spreading time of an item (maybe due to slow planet updates) this might be unpractical. Therefore please give it a try and tell me of your experiences!

31 January 2007


After the suggestings in the comments of the recent trayicon post I changed the trayicon's "new" number background to orange:

So it should be more RSS like...

30 January 2007

About Feature Requests...

Some of you might have noticed that the feature request tracker on the SF project page did vanish. Well, this is intentional. I closed it. My goal was to reply on everything posted and getting more and more requests while not being able to fullfill at least some of them is totally pointless. And more important it is totally frustrating, because over time it creates the distinct feeling that one is not able to keep up with the users and that one is heading in a totally wrong direction with the implemented features. I know this is probably just imagination but to say it bluntly: it generates dissatisfaction.

Another point is this: when you post a feature request you mostly outline some way of how to use an interface or how a program should behave. Usually it is a refinement of the existing implementation, sometimes it is asking for a different way of realization. What I miss with most of the requests is the consideration that maybe the developers already thought about it and decided against it for well-thought reasons. These might be technical reasons, but more often these are mismatches with the project goal and program design.

So in the end all the work with feature requests is reduced to these actions:
  • Explaining why something is not possible with the program design.
  • Pointing out why something does not match with the program goal.
  • Pointing out why something is not planned due to shortage of developer resources.
  • And sometimes explaining that something is already implemented. RTFM...
Hmmm... Why do I ask is this necessary? Why is it necessary to spend hours each week just to go over these question in different areas of the program again and again? What does the user get from it? Why does he expect this explanation?

Until today I remember never writing even a single feature request to any open source project out there. It just was not necessary. Now what is wrong with me? I always found that each project implements a certain use case with a certain level of program complexity. And when I found that the program was too simple the answer was to switch to a more complex one. And when I found that a program does not do what I want despite being of the correct complexity I found that usually I tried to use it in totally different way compared to the intention of the developers. When trying to adapt a bit to the intended use case one usually sees that there was a lot of thinking behind. And problems suddenly do solve, but in a different way than my "obvious" one. Sometimes it helps looking for the competetive projects because the realized use case might be closer to my "obvious" one.

When reading reviews of applications the argumentation is often this: "after clicking three times and waiting for several seconds I found the program to be totally useless" or "I didn't find a way to do X and before this is implemented I won't use the program". And I ask myself do these authors even have the faint capability of understanding others people thinking and ways of doing things? They probably do, but they obviously do not want to apply it. The same seems to be true with the human species of feature requesters.

After critisizing the current you-have-to-do-what-I-want feature request praxis I want to give my criteria on useful feature requests:
  1. Feature requests should inform the developers of things they propably won't think of themselves.
  2. The suggested feature should match the programs complexity and the project goal.
  3. The suggested feature should match the development resources.
  4. Explain (at least to yourself) why you consider the effort to implement the new feature worth the developers time.
  5. Optional: only suggest things that you would consider implementing yourself.
Back to my claim that I never wrote a feature request myself: with the above conditions you see that #1 and #5 are almost never given which is why I think feature requests are a pseudo mechanism doing nothing good for the open source world except for eating up support resources. So I conclude: feature requests do not help a project. In the opposite!

What do you think?

Ahh... I forgot to mention: This is a rant!

28 January 2007

Improved Tray Icon

One of the feature differences to Akregator until now was the tray icon representation. Since some time Akregator displayed the number of new items rendered in the item. Liferea only toggled between a shaded and an unshaded globe icon.

SVN trunk now has the same number rendering like Akregator supports. Here a screenshot of the normal icons of both programs (Liferea on the left, Akregator on the right) when nothing new has arrived yet:

And this is how it looks when new items have arrived:

The white on red colors are hard-coded and do not follow the theme. This makes some sense as the blue icon also doesn't and red on white has both a good contrast to the blue icon and most themes.

24 January 2007

Comment Feed Support

Here is a preview of what I'm currently working at: comment feed support. While not many blogs do support comment feeds quite a number already does. And if the blog provides comment feeds per post the news aggregator can retrieve them and display them like seen in the screenshot below: