29 August 2006

More search engines!

New in SVN trunk and soon to be released with 1.1.2: more search engines!

Until now there was only Feedster, which I admit was pretty lame. So I extended the "Search" menu with options to create search feeds for:
  • del.icio.us
  • Feedster
  • Google Blog Search
  • Ice Rocket
  • Reddit.com
  • Technorati
  • Yahoo
For now these are the engines that I found to support search feeds. The quality may differ, but it is a nice way to stay up-to-date with certain interesting topics. If the search term is unique enough such search feeds can be really helpful. But be warned for more common terms like "Linux" they are pretty useless. More reason for choosing a unique program name :-)

25 August 2006

The tray icon "problem"

One of the most discussed Liferea behaviours is the tray icon/close button problem. Liferea allows you to have a notification area icon which indicates wether there are new downloaded headlines or not. When there are no new headlines the globe icon is a lighter shade and when there are new headlines it gets a darker shade. So the tray icon (if enabled in the preferences) is permanently visible. Clicking on the tray icon will hide or unhide Lifereas main window.

Now the dispute is about what should happen when the main windows close button (the one in the window manager decoration) is clicked. For Liferea this means the user requested to close the window and not the application. After all a "window close button" was clicked. Therefore with enabled tray icon closing the main window will not terminate Liferea. With disabled tray icon it will. The reasoning is that you requested removal of only one of two GUI elements of the application, therefore it is not to be terminated.

Of course one might argue wether it is correct to have a permanently visible tray icon, because it clutters the panel and the notification area was intented for notifications only. The big advantage of the notification area is that using it is portable accoss many desktop environments, which might not be true when implementing a panel applet e.g. for GNOME.

23 August 2006

Categories vs Folders

I recently found this write up of the Blam! developer(s) on why having file system like folders is user unfriendly compared to have a category system which at a time only shows a flat list of all feeds of a selected category.

Liferea is not the only aggregator with folder-like organization, but it is true many aggregators rely on flat category-based organization. And there are some not even supporting categories.

To be honest in the beginning when adding folder support I just followed the email client interface, not thinking about better alternatives. But after some time working with folders I found it to have some advantages:

Like seen in the above screenshot when the user is allowed to select a folder the aggregator can present a merged item list. Imagine all 10 feeds of the folder posting 1 post per day. With a category based approach you are forced to click each feed once - as long as there is no merged mode presented, which would have to be exposed by some menu or toolbar option.

The same when marking every of those 15 post feeds as read. In Liferea select the folder and mark the folder as read. No extra menu option for marking the whole category as read.

Also there is no need to expand the folder. If you know about the contained feeds anyway and can identify them by their favicon you can have a pretty small view of a handful of collapsed folders (maybe labeled by category type) which you click one after another to read their new content.

Of course there are also the disadvantages some of which the Blam! developers already identified:
  • One has to explicitely collapse folders or scroll to access of the rest of the feed list. Maybe Liferea needs an auto-collapse preference.
  • Folders realized with GTK tree views eat up vertical space. Each indention level eats about 16 pixels.
  • When using folders as categories one cannot have one feed in two categories.

22 August 2006

Why Javascript is enabled per-default

After a new installation of Liferea the "Disable Javascript" preference is not selected per-default. If a user wants to prevent Liferea from running Javascript content in the item rendering or when browsing inside Liferea he has to switch on the preference explicitely.

From time to time I get a bug report saying something like this "You need to disable it per-default otherwise you will endanger you users". Often the one reporting the "problem" is quite amazed that this obvious problem wasn't "discovered" earlier.

Now these are the reasons why Javascript is explicitely not disabled:
  • Mozilla/Firefox which Liferea embeds (with GtkHTML2 Javascript isn't supported) as a standalone application also comes with Javascript enabled. Many of its users use it this way. And it is not considered a flaw in Mozilla.
  • When embedding Mozilla one can only enable/disable Javascript on a global level. So when disabling Javascript to prevent malicious script content in feed items one also disables Javascript for internal browsing.
  • When displaying parser/filter/download errors Liferea uses Javascript to hide the details until a "Details" link is clicked.
  • Enabling Javascript makes internal browsing more barrier-free.
  • Liferea (v1.1) tries to prevent malicious script content by removing it from feed items. While this is still work in progress it already catches a lot of the script insertion scenarios.
Of course you can always patch the default gconf schema of Liferea to install with Javascript disabled.

21 August 2006

Avoiding lax XML parsing

After some discussion with Daniel Veillard (the person behind libxml2) why XML consumers should never process invalid XML and that future libxml2 versions might drop the recovery mode, I reconsiderd the usage of the libxml2 recovery mode in Liferea. It is enabled since the earliest versions to allow parsing the non-XML RSS 0.9x feed formats and to repair occasionally broken XML feeds.

There are two ideological standpoints on parsing of broken XML:
  1. The XML spec says parsing broken XML is forbidden. Tolerant parsing will cause the feed generators to be broken forever.
  2. Some feeds will be always broken. Total perfection of all generators isn't possible and only the user experience counts. Therefore tolerant XML parsing is mandatory for a good aggegrator.
The first opinion is very popular with the XML propagators while the second one (at least I have the impression) is common amongst aggregator developers.

With the rise of Atom 1.0 and the continuous improvements of the major feed generators it is getting more and more realisitic to follow the approach of opinion 1: to refuse broken feeds and force the feed generators to fix the problem. The main reason to forbear the use of libxml2's recovery mode is of course the prospect of its future removal.

The plan:
  • Don't use recovery mode for Atom 1.0 and OPML at once (released with v1.1.1)
  • Continue to use recovery mode for RSS for now.
  • Later split RSS parser into 0.9x and 1.0/2.0 parser where only the 0.9x parser uses the recovery mode.
  • When libxml2 removes recovery mode either drop RSS 0.9x support or write a new parser.
I expect this to cause some user reports about feeds suddenly broken, that worked until now because wrong encoding, broken HTML or unknown entities were recovered/stripped automatically until now.

What this blog will be used for

As mentioned on the mailing list some days ago I plan to document decision regarding Liferea development here. This might draw focus from the mailing list, but it provides better chances to react on feedback from the blogosphere. And if it doesn't work there will be another dead weblog...