14 November 2009

Tab Cycling Fixed

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!

22 October 2009

Work on 1.8

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"

26 July 2009

Contributions to 1.6

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!

25 July 2009

New Stable Release 1.6

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.

06 June 2009

Problems with gwget 1.0.[01]

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!

01 May 2009

Liferea v1.6 RC1

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.

12 April 2009

1.4.28: Possible Solution for the 100% CPU Usage

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!

03 April 2009

How to Compile from SVN

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

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

  1. svn co https://liferea.svn.sourceforge.net/svnroot/liferea/trunk/liferea
  2. cd liferea
  3. sh autogen.sh
  4. make
  5. 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

13 March 2009

libsoup migration

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!

04 March 2009

GeoRSS Support Added

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:

07 February 2009

WebKit ABI Incompatibility

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.

02 February 2009

Release Manager Found

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!

25 January 2009

Bye Bye Flash Content!

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.

14 January 2009

Redesign Feedback

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.

12 January 2009

Rewrite/Redesign From Scratch

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.

07 January 2009

Liferea Development Failures So Far

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!