Liferea Blog

New Features in 1.8

2011-12-23T02:42:00.000-08:00

When you upgrade to 1.8 you might be searching for new features and be a bit disappointed. The thing is that we put our development focus into performance improvements and removing bottlenecks. Still there are some hidden small functional improvements (I'll leave out the performance measures) that I want to outline in the following...

Google Reader Labels: Liferea now supports folders (so called labels) in your Google Reader subscription. Please be aware that in Google Reader a subscription can be in multiple labels, but Liferea organising feeds in a tree can only use one (the first) label. Effectively you have a one-level folder tree only.
TinyTinyRSS 1.5+ Support: Starting with 1.8 you can now subscribe to another great online aggregator. The huge advantage of TinyTinyRSS is that you can host it yourself and do not need to entrust your feeds to a 3rd party online service provider.
Sorting Subscriptions: In the folder context menu you now find a new option to sort all child subscriptions alphabetically.
New Inline Browser Link+Image Actions: You can now run "Copy Link" or "Save Link" in the inline browser for both images and hyperlinks.
Indicator Applet Support: All Ubuntu users can now compile Liferea with support for the indicator applet.
Reorder Browser Tabs: You can now Drag and Drop open browser tabs.

That's it. As I said not much on the feature side, but we did a lot of work on performance. Maybe this is even more important. I'm also aware that the performance improvements did not satisfy our power users with >100k headlines in cache, but there'll be a followup post on the performance measures soon.

1.8.0 Released

2011-12-10T02:52:00.001-08:00

The new stable releases seemingly get finished only around christmas each year. Summer just isn't a good time for getting things done.Well, here it is: It's finally done. The new stable line with many performance improvements and better Google Reader and TinyTinyRss 1.5+ support. Grab it from the project page or ask your package maintainers to upload it!

Accidental Drag&Drop in HTML Pane Fixed

2011-06-21T15:16:00.000-07:00

Many bug reporters mentioned accidentally subscribing to arbitrary text "URLs" by selecting stuff in the HTML pane and then unwillingly dragging it. This always led to a new subscription in the feed list.

The new releases 1.6.6 and 1.7.6 provide a fix requiring links to be dragged over the feed list. When dragging and dropping in the HTML pane or elsewhere in the window nothing happens now.

Google Reader Label Support Added

2011-06-18T00:00:00.000-07:00

Many users have asked for quite some time... Yesterday we added Google Reader label support to git. So now you get Google Reader labels as folders in Liferea. This sync feature was contributed by Peter Oliver and Sergey Snitsaru.

Right now labels are only sync'ed from Google to Liferea, but not yet the other way around.

Support will first be included with 1.7.6

TinyTinyRSS API Change

2011-06-17T14:39:00.000-07:00

TinyTinyRSS has changed the JSON API in an incompatible way with tt-rss release 1.5. If you are using the tt-rss support with Liferea 1.7.5 you will not be able to connect to tt-rss 1.5+ anymore.

Support for the new tt-rss JSON API will be provided with the next unstable release of Liferea 1.7.6. If you really need to use tt-rss in the meantime please use the latest code from our git repository.

Also starting with Liferea 1.7.6 you will not be able to access tt-rss 1.4 setups anymore. Please upgrade your tt-rss to the newest release.

Added libindicate Support

2011-06-15T14:25:00.000-07:00

Previously we were asked why we do not support the Ubuntu menu indicator applet as another notification variant. The reason was simple: all active developers did use Debian so far.

Now Maia Kozheva offered to maintain the indicator code in Liferea, so starting with 1.7.6 we will include a both compile and runtime optional libindicate support. Compile time optional meaning libindicate auto-detection and runtime optional meaning indicator applet auto-detection with tray icon fallback and flexible preferences.

Full Screen Mode

2011-04-20T15:08:00.000-07:00

One thing I'm wondering about: are Liferea users interested in a full screen mode? For example for viewing websites after opening them in a tab, or to simply have Liferea use all available screen space.

Popup Menu Key Support

2011-04-20T13:42:00.000-07:00

Did you know that there is a popup menu key, that allows you to open the context menu in list views?

Well the GTK default binding is - and on Windows Keyboards the context menu key (usually near to the right of your ey) . As GTK does not handle it as an alias for the 3rd mouse button event each application needs to implement this event for each list view separately :-(

Until now Liferea did not implement this keybinding. Keyboard users will be happy with the upcoming release 1.7.6 which introduces support for this feature based on a patch by Ricardo Cruz.

Working TinyTinyRSS Support!

2011-04-19T14:51:00.001-07:00

With the new unstable release 1.7.5 TinyTinyRSS (tt-rss) support is now usable. All relevant features are implemented. While the implementation might not yet be optimal (doing single item fetches/updates, no async handling for offline state...) it is still usable in normal situations.

Feel free to test and give feedback!

Started tt-rss support implementation

2010-10-25T13:41:00.001-07:00

I want to hear a "Yeah!" from all commenters asking for Tiny Tiny RSS (tt-rss) support in the Feature Poll and in other feedback channels!

But don't get too excited as the implementation has only started. Current git master has login, subscription list fetching and initial item fetching. There are a lot of callbacks missing. It's still long way to go...

Problems with Ubuntu 10.10 indicator applet

2010-10-25T13:31:00.000-07:00

Several users did report problems with the indicator applet with the new Ubuntu 10.10. This seems to be a problem with the patch Ubuntu applies to Liferea to work with the Ubuntu specific indicator applet. Evolution seems to suffer a similar effect.

As I'm not an Ubuntu user (none of the current team is) we cannot support you in this case and strongly advise to contact downstream Ubuntu about this.

Enhanced Browser Context Menu

2010-10-12T11:15:00.000-07:00

One of the topics raised in the recent feature poll was the browser context menu. There were several requests for the following menu options

Copy URL
Save Link As...
Save Image As...

The current unstable code now has those three options (based on the click context). For saving links and images the download tool configured in the preferences is used. Before downloading you are presented with a dialog preset with the configured default download directory.

Don't forget that we changed to a Git repository in case you want to try the code!

Liferea switched to git

2010-10-09T11:37:00.001-07:00

Liferea now uses git instead of SVN, please do not use the old SVN repository anymore.

You can browse the git repository online here.

Instructions for compiling Liferea master (the unstable development code) from git:

git clone git://liferea.git.sourceforge.net/gitroot/liferea/liferea
cd liferea
./autogen.sh
make
make install

Bloglines support removed from trunk

2010-10-05T14:38:00.000-07:00

Ask.com announced that Bloglines will be shut down on Novenber 1st.

The Bloglines code is now removed from Liferea trunk (that will become Liferea 1.8), and Bloglines subscriptions are automatically removed.

At least as long as Bloglines is available it will stay supported in the stable Liferea 1.6.

For users of Blogline with Liferea the best choice for similar functionality is to switch to Google Reader and use Liferea's Google Reader support.

Update:
Bloglines support is now also removed in the 1.6 branch, the change will be in 1.6.6.

Sorting Feeds

2010-07-27T13:53:00.001-07:00

During the recent feature poll, during discussion in IRC and the occasional feature request in the tracker users did ask for the ability to sort larger feed lists. To allow this we've added a sorting feature to the folder context menu:

It is a simple implementation lexicographically sorting the feeds in ascending order. Nothing more. And we plan to keep it that simple.

In several discussion about the need of this feature the usual argument was about the feed lists being much too long and a specific feed to hard to locate. Sorting all feeds would speed up the feed lookup. To everyone having this problem: please use folders! Organize your feeds in topic folders, don't add more than ~10 feeds to a folder. Don't even start loosing the overview!

I personally do believe the sorting option shouldn't even be necessary. Using folders has too many advantages (recursive viewing, hiding read items) to not utilize them.

Nonetheless "Sort Feeds" is added to SVN trunk to be released with 1.7.5

Use Case 2 - Read latest headlines

2010-07-12T20:43:00.000-07:00

The user launches Liferea by single clicking the notification tray icon. Liferea displays the main interface. The user clicks the “Next Unread Item” icon in the toolbar. Liferea moves focus from the currently-selected headline to the next unread headline. If no headline is selected then the first headline in the top-most feed in the tree-view is selected. The contents of the feed item are displayed in the content pane if visible. Liferea marks the feed item as read and updates the font of the headline to indicate as much. The user can continue to advance to the next unread headline by either clicking the button again, or using a configured keyboard shortcut (set in the user's preferences) to page through the article's content and then on to the next unread item once the article's content has all been displayed. Alternately if the focus is on a headline or a feed in the tree view the user can advanced to the next unread headline by using the 'n' keyboard shortcut.

Thoughts and Considerations

The 'n' key shortcut seems to stop working as soon as the contents of an article are clicked (e.g. a hyperlink is clicked). In order to re-enable the 'n' key shortcut the user has to click a headline or feed name. Is it possible to allow the 'n' key shortcut to always work? Note that CTRL-N always seems to work, but if we can simply have 'n' work without CTRL it saves my fingers from cramping. Is 'n' an undocumented shortcut?
There might be some confusion around the configurable shortcut to “Skim” through headlines and skipping to the next unread item. They are not the same thing, but the difference is not immediately clear to the user without trial and error (and reading the mailing list in my case). It might be beneficial to look at clarifying the two ideas. One suggestion might be to make it configurable which key is used to skip through as well as which key is to skim through. I'd suggest finding two concrete and distinct words, either within the mental metaphor you're trying to leverage (e.g. newspapers I believe) or within the expected user's vernacular.

For reference, this is related to my intro post.
Other use cases:

Use Case 1 - Add URL Subscription

Feature Poll Results

2010-07-01T12:18:00.001-07:00

A while ago I posted a "Feature Poll" blog post which as I expected had a lot of feedback. Everyone simply loves feature wishing list, must remind most of us of birthdays or Christmas :-)

We after reading through the various comments I tried to consolidate the topics and to weight them for the number of mentions (listed in braces). Here are the results and some thoughts on each:

Performance (6): Well... not actually a feature. But we are working on it!
tt-rss Sync (6): Syncing to tt-rss or another open source Google Reader competitor

Browser Context Menu (4): I grouped several points under this topic:
- Save Link As (2)
- Save Image As (1)
- Copy URL (1)

Ubuntu Messaging Menu Integration (3): Actually a patch exists for this. But not a single developer runs Ubuntu, so we cannot really maintain this feature. For now we therefore have decided not to include it.
More Google Reader Features (3): Most asked for is the folder support. Problem is that Google Reader has label-based folders, where Liferea has stricly hierarchic folders, so there is no unique mapping in all cases and we see no sane way to map non-hierarchic labels into the feed list.
Better Tray Icon (2): Here we need artistic contributions! We are developers, not artist. Anyone? Volunteers!
Stability (2): Not a feature, but it is important. We believe the current code is pretty stable.
Alternative DB (2): While I understand the wish, this is a level of complexity 2-3 part-time developers cannot maintain. Sorry, but this is just unrealistic.
Confirm "mark all read" (2): This pops up more often lately. But does your favourite email client ask for confirmation? I believe it to be an untypical behaviour. What could be a solution would be a generic Undo feature requested one time in the comments and regularily in the bug tracker.
Small Icons Toolbar (1): We try to support all toolbar styles GTK does, which currently doesn't include the small icons mode.
Windows Port (1): I understand the wish, but we cannot support an OS we do not use ourselves. This is something that needs a maintainer.

Note: the list above is a quick summary and might miss some topics mentioned.

What happens next?

Please do not despair if your suggestion isn't immediatly realized. We will carefully consider complexity and importance and will realize as much improvements as possible. I believe we should start with improving the context menu and implement tt-rss support.

Use Case 1 - Add URL Subscription

2010-06-27T10:06:00.001-07:00

Current dialogue (Liferea 1.6.3)

Use Case Description
The user launches Liferea. The user clicks the “New Subscription...” button which results in the New Subscription dialogue being displayed. The user manually types in the feed subscription URL (e.g. http://planet.gnome.org/) (or pastes text from the clipboard) and clicks OK. A new feed item appears in the left-hand subscription tree directly below the last selected feed, at the same hierarchical level. Liferea processes the feed and displays the configured default number of unread items in the headline pane. Liferea fetches any applicable favicon icons for the site and replaces the default icon for the feed based on the feed type with the favicon. Liferea changes the name of the subscription from the initial value of “New Subscription” to the name provided by the feed. Liferea displays the headlines in the appropriate pane, as dictated by the current view.

Thoughts and Considerations

When adding a feed there is no user feedback while updating the feed for the first time. There is some considerable lag time and it is not clear that anything is happening. The status bar indicates it is updating the subscription, but does not provide any moving indicator to let the user know the app has not frozen. Is it possible to somehow inform the user that an initial set of headlines is being downloaded, along with the other info (name, favicon, etc). Just some UI indication that Liferea is working. Ideal might be to have the icon of the feed not appear as a static default feed type but rather a progress indicator such as a spinner (like the browser tabs often have).
Is it possible that the Advanced feed dialogue be changed into a disclosure triangle? For example I've simply merged the two dialogues into one in the mockup below, and made a few minor changes to spacing and wording. The one key value this affords the user is the ability to switch back to the basic dialogue without restarting the “Add ...” use case. It also reduces application complexity (2 different add subscription dialogues). The mockup below is just a first brush at creating the right unified dialogue. It is meant for discussion. Further refinement/polishing/HIG-ifying is possible if/when the direction is agreed upon.

My name is Kirk and I want to focus on Liferea's user experience

2010-06-27T09:42:00.000-07:00

Hi everyone - quick introduction: I'm Kirk Bridger. I'm an analyst by day (what that exactly means is a post all by itself) and am eager to give back to this fabulous project. The best way to do that is by applying my skills, which do not include strong programming anymore. So what I can I offer?

The project leaders have given me the opportunity to take a look at Liferea from the user experience point of view. I'd like to throw a few idea out on this blog for discussion, to see if there are improvements the community agrees on that the developers are interested in implementing.

This will range from simply documenting the existing app's use cases (including using the existing dialogues etc.) to doing a full blown heuristic evaluation using the latest Gnome HIG. Other things I'm keen on doing include creating mockups to help describe and explore ideas - yours and mine.

Over the next little while I plan on posting a few basic use cases and some observations/suggestions based on my own use of Liferea, just to get things started. The purpose of these posts is to get your feedback and suggestions to ensure that any changes that result from the discussion best meet the community's needs and app-specific workflows. So please feel free to chime in if you have any thoughts or feedback.

So that's my intro. I like to think I am clearly separated from my designs so please feel free to be as hard as you want on the ideas I put forward here. Note that I said to be hard on the "ideas". Design discussions can sometimes get heated so I'd like to suggest that we all keep the end goal in mind:

Liferea (Linux Feed Reader) is an aggregator for online news feeds. There are many other news readers available, but these others are not available for Linux or require many extra libraries to be installed. Liferea tries to fill this gap by creating a fast, easy to use, easy to install news aggregator for Gtk/Gnome.

Google Reader Authentication Problem

2010-06-23T14:50:00.000-07:00

Sorry everyone using Google Reader: authentication is currently broken in all releases!

The cause for this is Google migrating to another authentication schema and us missing the announcement of this change. Now it did happen and we have a problem. We try to fix it asap and release a new 1.6 version. Hopefully distros will catch up quickly.

Update: Fixed in 1.6.4

Feature Poll

2010-06-10T13:53:00.000-07:00

Simple question: What feature do you miss most?

Disclaimer: This is not a promise to implement anything :-)

Serious performance issues with ext4fs barriers

2010-06-06T06:34:00.000-07:00

More often lately users ask for support because they experience horrendously slow performance. In almost all cases they run Liferea on ext4fs where sqlite, when used with a lot of small update operations doing a lot of fsync() calls, is quite slow. This is not a specific problem of sqlite though, it just is very visible with applications performing a lot of write access like Liferea does using sqlite.

The important difference in this aspect from ext4fs to ext3fs is that ext4fs comes with barriers enabled, which is a filesystem feature (optional in ext3fs) that tries to improves filesystem integrity. But this comes at a cost: depending on your application use case this might decrease filesystem throughput a lot, which is what many Liferea users experience.

A workaround is to disable the ext4fs barriers by adding "barrier=0" to the mount options in /etc/fstab and remount the partition.

Recent Work on Liferea 1.8

2010-06-05T18:24:00.000-07:00

Sorry, long time no post here. Nonetheless there is work ongoing on Liferea 1.8. We do mostly performance work and small improvements. I want to keep you updated about the latter. Here is a list of interesting improvements we have now in SVN trunk:

GTK 3.0 compatibility (Emilio Pozuelo Monfort and Adrian Bunk)
identica.ca bookmarking support (Adrian Bunk)
Copy select text to clipboard from HTML pane (Ricardo Cruz)
New DBUS method to trigger a feed update (Matthew Bauer)

Docky Helper

2010-01-15T19:45:00.000-08:00

omgubuntu.co.uk reports that the GNOME dock "docky" of the Gnome-Do suite got special support for Liferea: It presents the number of unread items in the icon. I guess using our DBUS method to query the number. In fact this is much nicer than the tray icon solution we have to use with panels!

Tab Cycling Fixed

2009-11-14T01:11:00.001-08:00

Over time Liferea users did report the broken key widget cycling. The symptom was that the focus always got stuck in the item list. Now Simon Lipp provided a quite simple patch that fixes the problem. The cause was a wrong "return TRUE" instead of a "return FALSE" in the main window key handler. Argh...

Well starting with 1.6.1 and 1.7.2 our keyboard users should be happy again. I know that this was frustrating to some of you!

Work on 1.8

2009-10-21T16:17:00.000-07:00

Just a short note on what we are doing for 1.8. Right now we try to reduce startup time by killing costly cleanup stuff done on startup by cleaning up the DB schema and we are also thinking about a good way to periodically vacuum the database on startup. The problem there is to find a good interval and to avoid doing it too often as it costs time even if the DB is in a 100% clean state.

If you want to test try running SVN trunk which performs a cache migration to the new DB schema. By reducing the schema by one unnecessary table we now skip some consistency checks which sometimes took around 10s of startup time.

If you do test it please post us some comparison values in the comments! You can gather the startup time by launching both 1.6 and trunk using this command:

liferea --debug-db --debug-performance | grep "startup took"

Contributions to 1.6

2009-07-26T11:51:00.000-07:00

With the new stable release out there I want to say thanks to all contributors!

Arnold Noronha, Adrian Bunk, Emilio Pozuelo Monfort, Daniel Nylander, Hubert Figuiere, Khaled Hosny, Leon Nardella, Takeshi Aihana, Vincent Lefrevre, Gianvito Cavasoli, Antonio Lima, Sven Hartge, Gustavo Noronha Silva, andoo, kalikiana, Christian Dywan, Robin Stoker, Mikel Olasagasti, Ariel Pablo Topasso, Yanko Kaneti, Mathie Leplatre, Martin Müller, Leon Nardella, Kai Willadsen, Diego E. Petteno, Maik Zumstrull, Rene Koecher, Lars Strojny, Martin Picek, Paul Keusemann, Jeff Fortin, goyko, Gustavo Chain, Jon Forsberg

The list is propably incomplete: so thanks to everyone not listed that helped with 1.6 too!

New Stable Release 1.6

2009-07-25T11:49:00.000-07:00

Liferea has a new stable release line 1.6. Download the new version 1.6.0 from our project page!

Here is a summary of the new functionality

Full Google Reader synchronization
Reduced feed list mode (hiding all feeds without unread items)
Enabling of browser plugins is now configurable (disabled by default)
GeoRSS support (rendering maps with OpenStreetMap)
New search engines you can subscribe to: Twitter, Identi.ca
Improved RSS namespace support: Itunes, Yahoo Media, Trackback
Improved presentation of enclosures

If you are interested in one of the above features or have problems in stability or performance of 1.4 please upgrade to this new release! If you have problems with the new release please use the IRC channel, the mailing list or the SF tracker for support requests! Everyone who posts complaints here in the comments gets -5 points (on a random account of some type of anything...).

And finally do not forget to write a bit of occasional positive feedback on the features you like most. It's hard to tell which features or users like the most to avoid accidentily dropping them.

Problems with gwget 1.0.[01]

2009-06-05T15:30:00.000-07:00

If you use Liferea with gwget to download enclosures please ensure you do not use gwget 1.0.0 or 1.0.1 as downloads won't work with those versions. The reason is an API change in the DBUS API of gwget. For gwget the DBUS function Liferea did use until now was considered an internal API not used by external programs.

Adrian Bunk contacted the gwget developers and with gwget 1.0.2 we will have a working DBUS interface again. In the meantime please reconfigure Liferea to use an alternative downloader!

Liferea v1.6 RC1

2009-05-01T12:59:00.000-07:00

Today we've released the first release candidate for v1.6. We'd like to ask everyone to install it and give feedback. We are mostly interested in functional regressions compared to 1.4.

If you need help with installation or compilation join us at #liferea (freenode.org). If you find a bug please check the SF tracker and report a new bug if you've found a new issue.

1.4.28: Possible Solution for the 100% CPU Usage

2009-04-12T14:04:00.000-07:00

Some days ago Axel Beckert suggested that the Mozilla preference "places.frecency.updateIdleTime" is known to causes CPU usage problems when not configured. With release 1.4.28 this preference is now set to 0. Several users already did test this change and reported back that there problems were gone.

While we are not yet 100% sure if this is *THE* fix I still like to ask everyone with problems to upgrade to 1.4.28 and give feedback (in the comments) if there it helped (let's say if you ran for 3 days without issues)!

Update: After some testing and user feedback: This was the correct solution!

How to Compile from SVN

2009-04-03T12:47:00.000-07:00

Update: We have switched to Git! Please follow the new instructions!

Here is a short command list for SVN trunk check-out and compilation:

svn co https://liferea.svn.sourceforge.net/svnroot/liferea/trunk/liferea
cd liferea
sh autogen.sh
make
make install

That's all. The really hard part is to have all necessary development tools and header packages to be installed. It's hard to say how they are named in your distribution, but they should include:

Tools: automake, autoconf, gettext, libtool, intltool
Libraries+Headers: sqlite3, webkit, GTK, libsoup2.4

libsoup migration

2009-03-13T10:35:00.000-07:00

Hello! I'm Emilio Pozuelo Monfort and this is my first post to the Liferea blog. Hopefully there will be more to come!

In the beginning of the 1.5 development cycle, Lars replaced the old proprietary networking code with a libcurl implementation. This had several benefits, including more maintainable code, but brought a new problem: the user interface didn't respond when there was network operations, for example when updating feeds, making Liferea unusable during that time. I heard WebKit GTK+ port had switched from libcurl to libsoup too and thought I would look if it was suitable for our needs.

Using libsoup has some benefits. It integrates very well with GLib-based applications (like Liferea) by having an asynchronous (GMainLoop based) interface. It also supports most of our needs: cookies, proxy (including authentication), SSL... meaning we can have a libsoup-based Liferea without regressions from the previous implementations.

I started working in migrating our code, since the unresponsive GUI was marked as a blocker for the 1.6 release. It wasn't easy for me as I'm not very skilled yet :-) but given the nice libsoup API I could do the work. Adrian Bunk tested it a lot and reported me some issues, and after fixing all the concerns from Lars, the patch landed yesterday in trunk! It will be released with the next unstable release, 1.5.14.

So if you feel like giving a hand and feel comfortable with unstable releases (beware it can kill your cat!), testing and reporting bugs is much appreciated!

GeoRSS Support Added

2009-03-04T14:02:00.000-08:00

Thanks to Mikel Olasagasti Liferea will support GeoRSS starting with release 1.5.11. GeoRSS allows to attach geographic coordinates to feed items. Liferea will render those using a OpenStreetMap widget. Below you find an example screenshot:

WebKit ABI Incompatibility

2009-02-07T10:12:00.001-08:00

Recently Webkit changed the ABI making Liferea compilation fail if you try to compile Liferea version up to 1.4.23 and 1.5.x against WebKit 1.1 (SVN revision 39804) or newer. If you run into this problem please use Liferea version 1.4.24 or 1.6-RC1 which was adapted to the new WebKit version.

Release Manager Found

2009-02-01T15:20:00.000-08:00

Good news. The last two releases 1.5.8 and 1.4.24 were not posted by myself, but by Adrian Bunk who volunteered as release manager. Additionally he identified some configure issues and right now works on a clean source compilation.

Thanks Adrian!

Bye Bye Flash Content!

2009-01-25T12:16:00.000-08:00

Today I solved one of the topics mentioned in "Liferea Development Failures" post: the Flash content removal.

With the yet to be released 1.4.24 and 1.6-RC1 the default behaviour will be to strip Flash embedding tags from the feed content. The rationale is to prevent freezes and crashes due to Flash player issues. So if you upgrade you won't see Flash anymore...

...unless you enable it in the preferences as shown in the screenshot below.

I hope this will help everyone having a XulRunner-Flash setup to tends that crash/freeze and all those using Webkit and having problems with the DSP device locking.

Redesign Feedback

2009-01-14T13:39:00.000-08:00

There was a lot of feedback to my last post about a rewrite/redesign of Liferea. Practically everyone agrees with the performance problems to be the top priority and most of you believe that a rewrite is the way to go.

Current ideas include further improving the UI code to simpler and conceptually clean GObject implementations (suggested by Arnold Noronha) and redesigning the Liferea core to use a task handling solving the performance issues as implemented by GTask (suggested by Christian Hergert).

Several commentors mentioned a missing general plugin system for easy extensibility. It may be that such a plugin system might motivate the one or the other to hack some quick add-on and might get more advanced users interested in doing things with Liferea.

For everyone who contacted me via blog/chat/mail: Let's wait till coming sunday to gather all feedback and then make some plans. I plan to collect everyones topics of interest so we can make a list and organize appropriately.

Rewrite/Redesign From Scratch

2009-01-12T12:30:00.000-08:00

One of the commentors of the previous post pointed out the possibility of a clean start without rewriting the existing code base. The idea being that there might be people willing to start from scratch while unwilling to dig through an existing code base.

As of now, despite continuous attempts, I'm not successful with motivating developers to actively and long-time participate in Liferea development. Maybe a new restart with the same or another project name. With me or someone else leading everything. With the goal to provide an better alternative to Liferea.

So is there anyone out there, reading this, willing to start a new GTK or GNOME feed reader project in C or C++ in the next two months? Feel free to comment or contact me directly!

The alternative will be a redesign of the existing code.

Liferea Development Failures So Far

2009-01-07T14:46:00.000-08:00

From time to time it helps to look back and to reflect on the results so far. When doing so you do sum up your success stories and your significant/total failures. I want to focus on the latter ones for this post.

Liferea v1.2

Let's exclude the v1.0 branch as the initial implementation of features and start with the goals and their results of the v1.2 line:

Fixing 64bit Instabilites: In fact v1.0 was unusable on x86_64. During the year to reach v1.2 a lot of patches and debugging went into the stability issues and reduced the crashes. But never completely, v1.2 still crashed. Later when the last issue was fixed during v1.4 preparation the most crashes where caused by the HTTP-client code.

What should have been done: not having own HTTP-client code would have skipped almost all of the 64bit problems. But due to missing GPL'd network libraries for C supporting cookies this was not possible at the time. Right now v1.5 switched to libcurl.
Correct Locking: With v1.0 a lot of users had problems with the locking of the cache directory (XML files that only one instance could write at a time). Crashes often lead to stale lock files and the running instance detection not working perfectly often prevented removing the lock file. The result was an annoying dialog warning of a (not really) running instance.

What should have been done: Use a standard locking mechanism ripped from another reliable open source project. Done after 2 years later by using BaconMessageConnection from libbacon of the GNOME project with v1.4.

Liferea v1.4

XulRunner Flash Crashes: Starting with Flash 9 (now 10) Liferea when running Flash applets in the GtkMozEmbed widget on 64bit systems very often crashed and as often just froze the application. Both behaviours unacceptable and causing dozens of bug reports.

What should have been done: Note: there is no reasonable way to disable Flash in GtkMozEmbed. So the only thing left is a HTML postprocessing stripping all <embed> and <object> tags to not even allow execution. Sadly it's still not realized. Also starting with v1.5 the renderer is switched to Webkit which is much more stable and faster than GtkMozEmbed.
Fixing Slow XML Cache: That's the #1 failure in the Liferea development so far. After a lot of discussion in the mailing list a lot of people hinted about using sqlite as a leight-weight DB backend. And in fact coding against sqlite is pretty simple, runtime stability and version compatibility is good too. The thing is you have to know about the downsides of sqlite:
- Heavy disk activity (Firefox3 Places users are suffering too).
- Continuing DB fragmentation and no runtime auto-reorganization.
- Very long startup time for fragmented DBs (e.g. 30s for 50MB).
- VACUUM (the manual reorganization SQL command) not working when you JOIN on ROWIDs. This I never read in the sqlite documentation but a user gave this hint.
Right now there are many users dropping Liferea for excessive startup times and temporary freezing when doing massive feed updates.

What should have been done: I'm not even sure. The XML based cache was as slow as sqlite is now when it got large enough and it also caused a lot of disk accesses. The only really advantage of the DB is easier search folder rule implementation and simple transaction based migration.

Liferea 1.8 or 2.0?

So what's in for the next release cycle? When asking what users would care most about it then it is PERFORMANCE. The question remains what to change? Right now I think using sqlite is not wrong itself, but the schema might have to be changed significantly and the expensive use cases (search folders rules) should not be realized using SQL views. To change this the feature and others might need to be removed altogether. Additionally in-memory caching of items (e.g. all unread) might be wise as they will be accessed with a high-propability anyway. When thinking about it changing the features in favour of performance means having a v2.0 line mercilessly reducing features eliminating everything effecting runtime performance.

Feel invited to comment your opinions and experiences!

Wanted: Release Manager

2008-12-20T16:10:00.000-08:00

Anyone interested in the job of a Liferea release manager? I think it would help to have someone enforcing a tighter release schedule, who also could priorize and enforce bug reports. Now and then (especially in the last time) releases do not come in the 2-4 weeks period and I believe a dedicated release manager could improve this.

Here is what this unpaid job is about:

Deciding on release dates
Creating releases (SVN checkout, creation of distribution tarball, creation SF new release)
Propagating release (SF news feed, mailing list, webpage)
Closing solved bug reports

I know this is quite a lot of work, as I'm doing this for some years now. It would be nice to have someone to take care of it, so that I could spend more time on the code and the bugs.

If you are interested (no matter what expierences) post a comment or write a mail to the mailing list. All contributions are welcome!

Webkit Support Progress

2008-12-11T15:08:00.000-08:00

In SVN trunk the Webkit rendering has now correct context menu support. While I'm not sure that the Webkit API part handling the popup is a stable interface, for now it works. Epiphany doesn't seem to use the popup handling right now...

The good news is that this was the last missing functionality for the Webkit rendering. Now you can zoom in/out, copy links, open links in internal and external browser, bookmark pages with Webkit too.

Note: There are stability issues with Webkit. Users report random crashes when surfing and also crashes when using Flash. Hopefully this will improve in the future for Webkit rendering to become useful.

64bit Flash for Linux

2008-12-10T13:41:00.000-08:00

The new 64bit Flash 10 player for Linux seems to do real wonders. I read more and more reports of people who solved their crashing issues for Firefox and Liferea with the new plugin.

Compiling with Automake 1.10

2008-10-25T05:00:00.001-07:00

Right now Liferea doesn't build with Automake 1.10 (it works up to 1.9.x). When running configure you get errors like these:

configure.ac:178: warning: macro `AM_GCONF_SOURCE_2' not found in library configure.ac:16: warning: LT_AC_PROG_SED is m4_require'd but not m4_defun'd acinclude.m4:6: LIFEREA_CONFIG_NICE is expanded from... configure.ac:16: the top level configure.ac:16: warning: LT_AC_PROG_SED is m4_require'd but not m4_defun'd acinclude.m4:6: LIFEREA_CONFIG_NICE is expanded from... configure.ac:16: the top level configure.ac:16: warning: LT_AC_PROG_SED is m4_require'd but not m4_defun'd acinclude.m4:6: LIFEREA_CONFIG_NICE is expanded from... configure.ac:16: the top level configure.ac:7: error: possibly undefined macro: AC_ENABLE_SHARED If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:8: error: possibly undefined macro: AC_ENABLE_STATIC configure.ac:20: error: possibly undefined macro: AC_LIBTOOL_DLOPEN configure.ac:21: error: possibly undefined macro: AC_PROG_LIBTOOL configure.ac:178: error: possibly undefined macro: AM_GCONF_SOURCE_2 configure:2694: error: possibly undefined macro: LT_AC_PROG_SED autoreconf: /usr/bin/autoconf failed with exit status: 1

I've searched the net for answers and tried a lot of thing, but couldn't find much on the issue. Does anyone reading the blog know about what to do to migrate from automake 1.9 to 1.10?

Update: After a hint from Adrian Bunk the solution to the problem above is to ensure a correct libtool installation. Reinstalling the libtool package did solve the problem for me.

Filter for laconi.ca Micro Blog Feeds

2008-09-21T13:35:00.000-07:00

Jens Vierbuchen posted a hint on the mailing list about a filter for laconi.ca micro blog feeds. With this filter you get items using the same HTML layout as the laconi.ca websites themselve use (shaded background, author images...).

("identiger" screenshot taken from project page)

Finished GSoC Project

2008-09-05T15:25:00.000-07:00

Some days ago the 2008 Google Summer of Code final examinations took place and you might ask how did the Liferea application work out. Well Arnold Noronha reached all goals we defined back in May/June and we now have full Google Reader synchronisation for the 1.5.x branch!

So thanks to Google for sponsering the student and thanks to Arnold for completing everything planned!

Google Reader Synchronization

2008-08-16T22:03:00.000-07:00

As you might know I've been working on Google Reader Synchronization in Liferea for a Google SoC project.

Let me go through what has been done, and what has not.

What's new

A noticeable change has been the ability to items "Mark as Important", or in the Google Reader lingo, "Mark as Starred". Liferea will synchronize this flag to, and from, Google Reader.

Another cool feature that has been added is an efficient feed updater (Let's call this fast-update). So here's how it works: Every 10 minutes, Liferea will make a request to Google Reader asking for a list of modified feeds. The response is very small, and hence this does not affect your bandwidth. But from this small request, we can determine a list of feeds that have been updated, and so we can download exactly these feeds. This means that when a new post is available, you will get the update within 10 minutes! Every 24hrs, a full-update is done to complete the synchronization, because there are some situations where fast-update can miss out subscriptions.

What does not work

Comments do not work (as I have pointed out in the past, this is something I cannot fix). I decided not to implement Labels as Folders, simply because some users (who might have been more generous at tagging their subscriptions!) would not like it.

Synchronization with other Web-based aggregators

True --- I wanted to work on this. However, I couldn't get myself motivated enough, because I didn't think I will be using it. :-) I would have had to learn the intricacies of the new API. (Btw, the Google Reader API is *nasty*!) And plus, since I won't be using it, I won't be able to maintain it properly. (oh, excuses!) If you need help implementing synchronization for another web-based aggregator, I will be ready to help. As long as they provide a clean API, it should not be too hard.

That's all folks!

Although SoC is almost over, I will continue developing and maintaining the Google Reader code in Liferea. So you are most welcome to give me suggestions at any time.

Video Bug Reports

2008-08-12T14:06:00.000-07:00

Today I found this video a Liferea user created and posted in his YouTube video channel.:

It describes two problems with the current handling of the 'updated' item state:

Changes are not persistent. There is a bug preventing correct saving of the state change into the DB.
Many users confuse this state with the item read state and wonder why "Mark All Read" cannot be used to reset the 'updated' state.

While the first problem is a functional one and could be fixed I still decided to solve everything by removing the current 'updated' state UI (the icon in the item list). The reason is that I believe it to be of low value to most of the users, to be not inituitive when distinguishing it from the 'read' state and to be visually disturbing if you do see it in the itemlist. Just too many disadvantages and it removing it will save code, documentation and support efforts.

If you got ever confused by this feature starting with 1.4.19 this will be fixed.

How to run VACUUM

2008-08-01T11:26:00.000-07:00

As explained in the last post I see no way to automatically run the "VACUUM" command of sqlite which more or less defragments the DB structure. Nonetheless for everyone who wants to run it manually here is how to do it:

Shutdown Liferea
Start the sqlite client by running: "sqlite3 ~/.liferea_1.4/liferea.db"
At the prompt enter: "VACUUM;"
Wait until the prompt reappears.
Restart Liferea

Situations when you might want to VACUUM

When the DB file (~/.liferea_1.4/liferea.db) is very large (e.g. >50MB)
When you have only a few feeds with a low cache setting (e.g. 30 feeds and 100 items) and believe Liferea to be unreasonably slow.
When you have run Liferea for ages.

If you don't know what this is all about: please do not worry about it. In many cases you might not need to do anything.

Why auto-VACUUM is no good...

2008-08-01T11:16:00.000-07:00

During the various performance discussions during the last time here and there people suggested to run "VACUUM" on the Liferea database once it gets slow. This is in line with the sqlite documentation which says:

When an object (table, index, or trigger) is dropped from the database, it leaves behind empty space. This makes the database file larger than it needs to be, but can speed up inserts. In time inserts and deletes can leave the database file structure fragmented, which slows down disk access to the database contents.

The VACUUM command cleans the main database by copying its contents to a temporary database file and reloading the original database file from the copy. This eliminates free pages, aligns table data to be contiguous, and otherwise cleans up the database file structure.

The problem with it is that it also takes very long. With a 50MB DB file I experienced a runtime of over 1 minute. This is why this can be only a tool for experienced users that know how to do it manually knowing what to expect. For executing such a long term operation automatically on runtime would surely be unacceptable to the unsuspecting user. Also there is no good way how to decide when to do a VACUUM to save disk space and improve performance.

Fix for 100% CPU Usage Problem

2008-07-28T10:14:00.000-07:00

After reports from several users that tested with the new release 1.4.18 I believe the 100% CPU issue along with other related symptoms is fixed. Thanks to everyone who retested!

Here is what happened: the release 1.4.16 did bring a DB schema migration that fixed a design problem that caused "loosing" of comment items in the DB. Comments must be removed when there parent items are removed and this didn't work well before 1.4.16. Now I have to admit I tested the comment removal with 1.4.16 very well and it worked as expected, but I failed to notice that the changed DB schema caused the parent item removal to silently do nothing.
The effect is a slow one: your DB file grows and on each feed merge you get more and more old items that should have been removed due to the cache size setting. Now merging (sometimes including full text comparison) against a growing list of items becomes slower each time. For users with lots of feeds updated regularily Liferea finally became unusable because it was merging items constantly.

Now when you start 1.4.18 you still might see some CPU usage during the first update run, because it has to delete a lot of stale items, but afterwards it should run as fast as earlier versions.

Everyone please upgrade to 1.4.18

Performance Poll Results

2008-07-26T14:05:00.000-07:00

First thanks to everyone who answered the three questions!

Your feedback definitively helped to get a better image of the type of setups out there. Here are my conclusion based on the feedback:

A significant amount of the users is subscribed to a number of feeds that is often twice the expected number of feeds. The Liferea target use case that I had in mind up to now was only up to 100 feeds. I think it is necessary to correct the number of acceptable subscriptions to somewhere around 250 and ensure performance with such a number of feeds.
Not all but many users (feels like 80%) do suffer from bad performance. I consider all GUI delays for simple actions (e.g. switching feeds, marking a single feed read) > 2s as bad.
Definitively all users suffer from the linear cost of the complex operations (loading huge item lists, full text search).

Now just redefining the target use case won't do anything good. The question is wether the implementation can be improved to significantly improve the performance. And the answer is simple: No. It can't. The current overly simple design is chosen and limited based on the efforts spent on the project. "Simple" means both simple use cases and no elaborate internal architecture.

So the problem is to solve the issues above. To enable better scaling the internal architecture has to be changed. Right now feed merging (downloading the XML, parsing it, merging items against DB) is done synchronously in the GUI thread. This makes it easy to implement, but hurts each time you navigate Liferea while a background update is in progress and results are processed. The second point from above could be addressed by correctly decoupling GUI and merging. The third point could be solved by shifting the focus from processing subscription caches as a whole to batch processing their items in background...

But not to forget these are only ideas. And Liferea is in need of developers! I'm a professional SW tester with some administration skills and do the development only as a hobby. While I'll try to improve the program other really skilled developer might be able to do the same much much better with less effort.

So again: Please consider contributing code!

Concerning immediate solutions: please try the upcoming release 1.4.18 which should solve the 100% CPU issue.

Performance Poll

2008-07-20T09:35:00.001-07:00

Today I'd like everyone following this blog (or accidentily reading this) to take part in a small poll. I'm interested in subjective performance feed back.

Please answer the following questions using a comment post:

Is Liferea loading feeds / search folders quickly enough?
How many feed subscriptions do you have?
What is the longest unresponsiveness in seconds when you use Liferea. Please name the feature causing it.

Just post something like

no, 100, 5s clicking on "Unread" search folder...

You can post comments anonymously!

Serious Problems with XulRunner 1.9

2008-07-01T07:44:00.000-07:00

With more and more distributions upgrading to the new XulRunner version 1.9 more and more users send bug reports of Liferea becoming unusable because of constant 100% CPU usage.

Right now I'm sorry to say that I have no clue what causes this, debugging is still going one. Hopefully we will find the problem.

Affected versions: There seems to be no limit to the affected versions. I got reports from 1.4.12 up to 1.4.16b all affected. The common symptom was all setups are using a recent XulRunner 1.9. Until now there were no reports about setups with XulRunner 1.8 having the problem.

If someone reading this with insight in XulRunner/Gecko/Mozilla has any idea please post a comment or send a mail!

Flash 10 with Liferea using XulRunner

2008-05-22T10:38:00.000-07:00

Stebalien explains how to get Flash working when your Liferea installation uses XulRunner for rendering, but your distro didn't install the Flash plugin for XulRunner.

Google Reader Sync Support: a progress report

2008-05-18T05:54:00.000-07:00

Hello folks, this is Arnold here. Lars had posted about my Summer of Code project: Google Reader Integration with Liferea.

The project got mentioned recently in a Free Software Magazine column (The 2008 Google Summer of Code: 21 Projects I'm Excited About), that also got slashdotted.

Anyway, a lot of work has been done, and it is (seemingly!) pretty much usable. So here is a progress report.

Installation and migration issues

Installation. Checkout the latest subversion repositories, and build it. Now in the left panel, right click, and choose New->Source, and choose Google Source. Give your email ID (which can also be non-gmail google IDs) and password. And you're set. You should see your feedlist on the leftpanel. You will observe the the "Read/Unread" status of all your items should be preserved from Google Reader.

A few notes about migration. If you have a Google Source from a previous installation, it will automatically be converted to a synchronized Google Source. So beware if you don't want Liferea to automatically modify your Google Reader data. You might also notice that some of the "Read/Unread" statuses before migrating have changed, this is because the synchronized Google Source gives preference to the "Read/Unread" statuses from Google Reader.

What works

Lets say you have been using the Google Reader online (For clarity, by Google Reader I will be referring to the online Google Reader API and/or interfaces. I will use the term Google Source for the Google functionality within Liferea). Now, on adding the Google Source, the first thing you will notice is that the "Read/Unread" statuses are retrieved from Google.

Liferea will synchronize subscription lists, and "Read/Unread" statuses both to, and from, Google Reader. This is the main functionality. If you are offline when a local change is made, it will propagate the changes to Google Reader later, when you get connected.

Another cool feature that you will notice is the "broadcast-friends" node. You can now read all the posts that are shared by your Google Reader friends from within Liferea. Although, as of right now, this doesn't show the name of the person who shared it.

What does not work, or does not work correctly

Comments do not work. This is an inherent issue with using Google Reader as a source: if you have been using Google Reader, you would have noticed that Google Reader does not show you a list of comments to an item, while Liferea can (for most feeds which support it). Liferea relies on some information in the feed, which the Google Reader API discards. Until Google makes changes to their API, we really can't do much about it.

Labels. Or Folders. All the posts within Google Source in Liferea, will fall in the same folder. Google Reader categorizes feeds by labels, which can be used to produce a hierarchical folder structure. I will definitely be implementing this over the summer.

Stars, and the "Important" flag. Liferea can flag an item as "Important", and Google Reader can mark an item as "starred". Eventually, I would like to synchronize these two.

Sharing. While you can see posts shared by others, you cannot share an item from within Liferea.

Efficient Updating

In my SoC abstract, I proposed that we can use Google Reader to save the user's bandwidth while updating. Here is the idea I had in mind:

Normally a user can have hundreds of feeds in his feedlist. Whenever Liferea does an update, it has to update each one of these, even if usually only one or two of them have changed. This wastes both time and bandwidth. Using Google Reader API, however, it is possible for us to download only the "reading-list" -- the reading list over all subscriptions -- in one HTTP request. In some sense I'm downloading all the changes to all my feeds in one go. I can use this to recover the "Read/Unread" flags: for any item in the reading-list, the item is marked as Unread. Any unread item under the Google Source, which does not appear in the reading-list, is marked as read.

However, as simple and clean as this might sound, this is flawed: say, while you are at office, you receive some new posts in the Google Reader webapp. You then read it, and so those items are marked as read. Now once you are back at home, you do an update on liferea: this new post will not appear in the "reading-list", so Liferea will never come to know that this post ever existed. You might say its not a cause for concern, since you have already read that post -- but maybe you want that post for offline reading.

So ideally, instead of requesting the "reading-list", I would like to request a list of "Changes since so-and-so date." Unfortunately, the Google Reader API has no such feature as far as I, and the pyrfeed Google Reader API page knows. I am keen on getting feedback and suggestions regarding this, since I would love to have this feature myself!

Feedback, Suggestions and About Me

For a good part of the IST-day, you can catch me on #liferea by the nick arnstein. You can also mail me at arnstein87 AT gmail DOT com.

I have just completed my undergraduate studies from Chennai Mathematical Institute, and will be joining University of Pennsylvania for a PhD in Computer Science this fall. I blog here.

New Subscription Options in 1.5.3

2008-05-05T16:04:00.000-07:00

Release 1.5.3 will introduce new subscription options that might help with some minor use cases where you want to modify the Liferea default behaviour for certain subscriptions:

Full Google Reader Sync Support

2008-05-03T13:29:00.000-07:00

With the currently ongoing Google Summer of Code 2008, Arnold Noronha is implementing full Google Reader synchronization support in Liferea! He's already started coding and SVN trunk already provides item download via Google Reader, while previously there was only Google Reader to Liferea feed list synchronization. So everyone who ever asked for that feature have a look at the Liferea again in two months after the Google Summer of Code 2008 application is over!

Advanced Searching

2008-03-16T15:20:00.000-07:00

Over time many users asked to be able to make more complex searches using the search box (e.g. matching multiple terms or doing exclusive matches...). The new unstable release 1.5.1 introduces an "Advanced..." button in the standard search dialog. When you click this button the dialog will change and a dialog very similar to the search folder properties dialog will appear. Here you can define one or matching search rules to realize much more complex queries. This advanced search functionality thereby should now cover a lot more use cases.

Note: Liferea still does not allow you to search only the current feed or all feeds of a given folder. The current DB schema doesn't allow building views with such filters. But given time this might be improved...

Liferea + Firefox + Ubuntu

2008-03-12T13:01:00.000-07:00

Recently quite a few Ubuntu users had troubles getting feed subscription with Firefox to work. In all cases it turned out that the Ubuntu package firefox-gnome-support was missing. So if you are using Ubuntu and Firefox please check if you this package installed!

Favicons and Hosted Blogging

2008-03-01T08:40:00.000-08:00

When looking at your subscription list you might notice that many feeds have the same icon. For example a white-on-orange "B" for Blogger, a blue pencil for LiveJournal, a flame icon for FeedBurner and propably others...

If you visit the website of the respective feeds your browser will usually present a different icon in the URL bar. Now one might ask why cannot Liferea use the same one.

The problem is that there are two ways of retrieving these icons.

Relatively to the URL of the website (e.g. as "<webserver>/favicon.ico")
A specific icon file linked in each HTML documented served.

Of course just placing a "favicon.ico" file in the root directory of the webpage is the easiest way to provide a favicon. But this doesn't work anymore with hosted blogging (as provided by Blogger, LiveJournal and many others) or feed caching (as used by FeedBurner and many others). The hosted blogging solutions just do not allow you to put an "favicon.ico" file anywhere (thereby breaking discovery variant #1) and the feed cachers usually work with URL redirection to serve the cached feed content (and thereby breaking discovery variant #2).

So what should I do to help the feed reader to find my favicon?

Solution for hosted blogging: You cannot rely on a "favicon.ico" file so to replace your providers icon you have to upload an favicon image (with arbitrary name) and add a link to it directly into you HTML template. The link needs to be placed under the <head> tag and could look like this:

<link rel="shortcut icon" type="image/png" href="http://myhoster.com/content?blogId=4396446&fileId=4387343">

Note: that Liferea relies on the MIME type and will refuse all images without specified MIME type.

Solution for feed caching: You can either use the "shortcut icon" link mechanism described above or you use Atom feeds you can also specify the original "favicon.ico" file there. For RSS feeds you must fallback to specifying the icon link in the website HTML.

If you think there are better solutions please let me hear about it in the comments!

Attention Profile

2008-02-28T11:54:00.000-08:00

Liferea is a news aggregator and each day allows its users to read maybe hundreds of new blog posts, news articles or podcasts. Many of those are tagged by their authors by descriptive categories. So if it know what the user likes to read most why cannot it preselect those favourite "type" of articles?

The new 1.5 code now keeps track of the absolute number of read categories. Under the "Tools" menu you can now find a new option "Attention Profile" to view the per-category count.

While this might not yet be very useful, this statistic keeping opens up the possibility for more sophisticated features. For example search folders for your most favourite categories, feed and item rating, APML exporting...

Be warned this is experimental, it might work out, it might not. It might hurt performance, or not. Also it arises ethical questions about creating user profiles. All things that still need to be thought about.

Update: Due to performance problems, the Attention Profile has been disabled for Liferea 1.6

"All Rules Match" Search Folders

2008-02-26T15:43:00.000-08:00

Until now search folder rules were "additive" or "removing". This mean when only one of the "additive" and none of the "removing" match rules did match an item it was displayed by the search folder. User feedback over time did show that this is not always intuitive and does not match each use case.

To improve this the search folder properties for 1.5 have changed:

Instead of the long logic explanation there are now two radio buttons allowing to define the intended logic. With "Any Rule Matches" you can create search folders that for example match several rare terms. And using "All Rules Must Match" you can filter all feeds for items on a specific topic identified by one or more keywords.

To give proper credit I must mention that this change was motivated by the searching dialog of RSSOwl (a great platform independant Java based aggregator) which has even more nice feature like instant preview and live updating.

Release Schedule Calendar

2008-02-26T12:56:00.000-08:00

For everyone who needs to know when the next Liferea version will be released (approximately) I created an online calendar, which is embedded at the bottom of the blog main page and can be subscribed in ICAL and Atom format.

Better Handling Plain Text Content

2008-02-12T14:30:00.000-08:00

Current Liferea releases do not handle plain text RSS item content gracefully. If item content is not HTML markup-escaped by the feed generator all text of such an new items ends up in one line without it's line breaks being rendering. This doesn't look very well and makes lists or formatted plain texts unreadable.

For 1.5.x the plan is to solve the problem by auto-detecting the text type of the item description. If it contains no markup than it is to be treated as plain text and all ASCII line breaks need to be converted to HTML line breaks for correct rendering. The critical point here is the plain text/HTML detection. The test implementation in SVN trunk currently only checks for physical HTML tags like <i>, <b> or <a href=""> indicating HTML markup. The risk of this approach is to add additional line breaks to valid HTML content that is not correctly recognized.

If you try 1.5.x/SVN trunk and experience formatting problems with twice as much line breaks or missing line breaks for pure plain text please give some feedback!

Handling Redundancy in Content

2008-02-11T15:41:00.000-08:00

Nowadays many feed sources do provide content using Atom or RSS and augment it with application specific namespace providing own tags that often duplicate the content in the container format. For example an iTunes podcast can have an item <description> in the Atom/RSS <item> tag along with an <itunes:summary> description of different quality.

Up until 1.4.x Liferea had a simple implementation primarily using the Atom/RSS description. With the exception of the <content:encoded> tag from the Content-Namespace which depending on tag order will always overrule the default description. Only if there was no default item description additional namespace infos (atom:summary, dc:description...) where used as a content source.

This was an unsatisfactory solution for several reasons:

More detailed infos in application specific namespaces are invisible.
Ordering problems with <description> and <content:encoded> did sometimes hide better content.
Dublin Core description (while rare to encounter) did never win.
The scenario of a better summary than description always caused the short description to win.

As a simple solution Liferea 1.5.x now selects the "best content" by simple length comparsion. The assumption is that the format of the content (plain text, HTML, XHTML...) doesn't matter, or more exactly the additional length of (X)HTML encoding indicates better content.

As a result you might see additional content in namespace-rich feeds (e.g. iTunes podcast feeds).

Frothing

2008-02-06T14:40:00.000-08:00

Liferea on Hildon by Ian Lawrence.

Improved LiveJournal BlogRoll Support

2008-01-31T14:35:00.000-08:00

Todays stable release 1.4.12 adds support for the non-standard "xmlURL" OPML attributes LiveJournal uses in it's blogrolls mentioned in the post from yesterday. So if you do use LiveJournal and want to subscribe to your friends blogroll then you should upgrade to 1.4.12!

LiveJournal BlogRoll Export Problems

2008-01-30T13:16:00.000-08:00

Nikolasco describes in detail how to workaround LiveJournal blogroll export problems using a Ruby script and cron.

File Permissions Vulnerability

2007-11-01T07:10:00.000-07:00

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!

Filtering Planet Feeds

2007-10-19T12:12:00.000-07:00

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.

Improved Namespace Coverage

2007-10-15T14:48:00.000-07:00

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.

Atom Link Blog Support

2007-10-01T12:41:00.001-07:00

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.

Liferea with OSX Themed GNOME Desktop

2007-09-27T12:27:00.000-07:00

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

Data Loss Bug in 1.4

2007-09-26T01:39:00.001-07:00

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!!!

Dangerous bug in 1.4.2b

2007-09-24T14:06:00.000-07:00

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.

Contributions to 1.4

2007-08-19T10:34:00.000-07:00

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!

Experimental WebKit Support

2007-08-08T18:03:00.000-07:00

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.

Transparent Tray Icon

2007-06-24T14:18:00.000-07:00

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

Menu Reorganisation

2007-06-16T12:13:00.000-07:00

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


Subscriptions
   Update All
   Mark All Read
   ---
   Add Subscription
   Add Folder
   Add Search Folder
   Add Source
   Add Newsbin
   ---
   Import from OPML
   Export as OPML
   ---
   Quit
Feed
   Update
   Mark As Read
   Remove All Items
   Remove
   Properties
Item
   Next Unread
   Toggle Read Status
   Toggle Item Flag
   ---
   Launch In Browser
View
   Increase Text Size
   Decrease Text Size
   ---
   Normal View
   Wide View
   Combined View
Tools
   Update Monitor
   Script Manager
   Preferences
Help
   Contents
   Quick Reference
   FAQ
   ---
   About

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?

Localized Default Feed List

2007-06-11T12:16:00.000-07:00

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.

Improved Proxy Preferences

2007-06-10T03:27:00.000-07:00

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.

Freeing Memory...

2007-06-08T15:07:00.000-07:00

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!

64bit Test

2007-06-05T13:58:00.000-07:00

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

2007-06-05T11:09:00.000-07:00

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!!!

Flash 9 Problems

2007-05-05T10:06:00.000-07:00

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

1.3.x Progress

2007-04-22T08:37:00.000-07:00

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?

First 1.3.x series release

2007-04-13T14:54:00.000-07:00

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.

Liferea & AWN

2007-04-11T13:59:00.000-07:00

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!

Enhanced Notification Preferences

2007-03-22T17:05:00.000-07:00

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

2007-03-21T17:53:00.000-07:00

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

2007-03-19T14:49:00.000-07:00

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

2007-03-14T15:28:00.000-07:00

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

2007-03-12T15:05:00.000-07:00

#liferea at freenode.org

Feed List Recovery

2007-03-06T15:50:00.000-08:00

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

2007-03-01T15:40:00.000-08:00

The current results:

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

Liferea & GNOME

2007-02-27T14:56:00.000-08:00

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!

DB Backend Progress

2007-02-24T14:06:00.000-08:00

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?

Item Duplicate Detection

2007-02-07T16:36:00.000-08:00

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:

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

Orange...

2007-01-31T12:40:00.000-08:00

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