29 December 2006

GTK theme colors support

Today I added GTK theme colors support to the 1.3.x code in SVN (update: now merged with stable 1.2.3). Now Liferea adapts the HTML rendering to your GTK theme settings. Here is a screenshot when running with a pretty standard ClearLooks theme:

While the same display in some dark theme looks like this:

Of course depending on your themes contrast settings and base color some elements like the blue links in the above screenshots do hurt the eye, but this is something that is hard to avoid. Despite this I think this improvement helps to blend in more with other applications in your GTK/GNOME desktop. Depending on the used theme the old default gray header styles used until now could look "cold" or out of place.

If you have significant problems with the new rendering please send a screenshot of the problem and if possible a link to the theme definition online or at least the name of the theme to the mailing list or post a new item in the bug tracker at SF.

21 December 2006

Problems With the Current Menu Structure

As promised I want to start another HIG compliance discussion to make using the Liferea menu more standard compliant. This is the current menu layout:
  • Program
    • Preferences
    • Update Monitor
    • Script Manager
    • Work On-/Offline
    • Exit
  • Feeds
    • Update Selected
    • Update All
    • Mark Selected As Read
    • Mark All As Read
    • New Subscription
    • New Folder
    • New Search Folder
    • New Source
    • New News Bin
  • Items
    • Next Unread
    • Toggle Read Status
    • Toggle Item Flag
    • Remove Selected
    • Remove All
    • Launch In Browser
  • View
    • Increase Text Size
    • Decrease Text Size
    • Normal View
    • Wide View
    • Combined View
  • Search
    • Search All Feeds
    • Search With...
  • Help
    • Contents
    • Quick Reference
    • FAQ
    • About
This structure has several problems and questions a lot of user care about. Here is a list I collected.
  • First menu isn't named "Feed".
  • "Feeds" menu is much too long (13 items!).
  • Plural used in "Feeds" and "Items".
  • Not all context menu options can be found in the main menu.
  • No "Edit" menu. Overall shouldn't there be a document centric menu.

Starting from the list above I think it is the best to identify the Liferea core concepts. This should give a hint for the maximal number of menus and the correct assignment of specific menu options to each concept. I think this will resolve the very long "Feeds" menu...

20 December 2006

Plans for 1.3.x

After 1.2 is released (and will get some more maintaince) I want to outline my plans for the 1.3 unstable branch. The idea is to get the same good feedback as with all the different 1.2 features. And maybe to convince you to contribute code and own ideas!

My Ideas
  • Replacing the XML file backend with sqlite
  • Simplify preferences dialog
    • removing memory/disk optimization
    • removing the browser module selection (use priority based plugin loading instead)
  • Main menu redesign (another HIG compliance discussion)
  • Rethinking the suboptimal libnotify popup presentation
  • maybe: extra enclosure download queue (with serialized or only partially concurrent download to avoid eating all bandwidth)
  • maybe: better redirect handling (as discussed some while ago)
  • maybe: replacing networking backend (to avoid having own code)
Additionally ideas? Want to work on some of those topics? Feedback!

12 December 2006

Navigating Liferea with the Keyboard

From time to time people do ask about a possibility to use certain or all functions with hotkeys.

Well first when you wonder about the predefined Liferea hotkeys you should go to the "Help" menu and select the "Short Reference" menu option. After doing this you will get a help page with all important standard hotkeys. Currently the hotkeys are:

Ctrl-AUpdates all your subscriptions at once.
Ctrl-RMarks all items of the selected feed or folder as read.
Ctrl-NJump to next unread headline.
Ctrl-UToggle unread state of selected headline.
Ctrl-TToggle flag of selected headline.
SpaceSkim through the headlines. Depending on your preferences you might need to use the Ctrl or Alt modifier.
uMove up cursor in the feed list.
dMove down cursor in the feed list.
bMove up cursor in the item list.
fMove down cursor in the item list.
DelRemoves the currently selected item.

Defining additional hotkeys

You are not limited to those hotkeys. As every good GTK program Liferea (since v1.1) allows you to dynamically assign key bindings. For this to work the GNOME interface option hidden in GConf needs to be enabled. You can enable it by running

$ gconftool --set --type bool /desktop/gnome/interface/can_change_accels true

If the GTK option is enabled you can open any menu from the menu bar, move the cursor above the relevant menu option and press the shortcut you want to assign. This shortcut should appear right next to the menu option label.

Note: Such shortcuts will be permanent. Ensure not to assign standard key binding like Ctrl-R, Ctrl-A, Ctrl-Q or Ctrl-W which would be taken away from the menu options you normally expect them to invoke (Refresh, Select All, Quit, Close Window...) and when intuitively pressing such hotkeys might lead to unwanted effects.

29 November 2006

Network Manager Support

Daniel Gryniewicz (currently maintaining the Gentoo port of Debian) made Liferea work with Network Manager. The Network Manager controls registered applications using DBUS and HAL to follow the availability state of the managed network connections. For example for a laptop user who is moving with his laptop out of a WLAN the Network Manager will automatically switch the state of all registered applications to offline and will change it to online again once the original or another network connection is established again.

If you want to try this check out SVN trunk (or the next release 1.2-RC4)!

28 November 2006

Browser Integration

For completeness here is another writeup of the integration of Liferea with different browsers:


If you using Epiphany you only need to enable the feed subscription plugin which is delivered per default (in some distributions as a epiphany-plugins package). To do so enable the "News Feed Subscription" extensions under Tools/Extensions. If the plugin is enabled and the currently loaded website provides a feed you will see an icon in the toolbar as shown in this screenshot on the left.

After clicking the icon the subscription will be added.

Mozilla/Firefox 1.5+

If you are using Firefox 1.5 you need the FeedBag extension. You can download it from the Liferea Homepage or from the Mozilla Addons website.

Firefox 2.0+

When using Firefox feeds are represented by the orange feed icon in the URL bar. To subscribe to a feed just click the icon. In the default setting clicking the icon will add the feed to the Live Bookmarks of Firefox. If you want to directly add a subscription to your feed reader you need to change the subscription preferences. This can be done under Tools/Edit Preferences in the "Feed" tab. For Liferea you need to specify the command "liferea-add-feed" as shown in the screenshot below:

The "liferea-add-feed" script should come with your Liferea package and uses DBUS to send a subscription request to the running Liferea instance.

27 November 2006

Softpedia Review

Today I got a notice that there is a new Softpedia review of Liferea. It is interesting to read and gives Liferea an overall rating of 3 out of 5 points. I think this qualifies for "not completely useless". From the functional standpoint out of the possible aggregator features known today this is a good characterisation.

On the negative side the review makes the assumption that Liferea aims for GNOME integration which it doesn't. This is a very common mistake out there. This brings me to two questions:
  1. Does the project wrongly communicate a non-existing GNOME integration?
  2. Is there an overwelming need for GNOME integration?
If the answer to question 2 is "yes" then what are the resulting benefits for the user? Besides some more GNOMEish dialogs and toolbar?

25 November 2006

Caution your font might change...

...when you update to 1.2-RC3 and higher. In fact Michel Salim found out that Liferea uses the wrong GNOME font definition. For starters: in the GNOME preferences you can configure fonts for different use cases: application font, document font, desktop font, window title font and monospace font. Until now Liferea did use the application font instead of the document font.

With the patch from Michel Salim the problem is corrected now and Liferea should use the same font other applications use to present document content to you. So when you start up Liferea after upgrading to 1.2-RC3 it will look much better :-)

05 November 2006

Gecko & Invisible Startup Screen

During the last days a lot of users did report a problem with the Gecko rendering. The effect is that right after startup the HTML pane which normally displays a welcome screen does not get drawn at all. The problem isn't really critical because after the first click the HTML pane will be drawn correctly, it just looks ugly...

While I do not know what exactly causes this effect it seems to affect other applications that use Gecko too (e.g. devhelp). It was evident in Debian Unstable some months ago and now seems to happen to a lot of Gentoo users. If anyone reading this knows more about the exact reason please let me know!

26 October 2006

New Date Format

For Liferea v1.1.8 the date format handling was changed. All previous versions had a preference that allowed you to choose between two default date formats and a user-specified date format. To satisfy the usability gurus out there this preference was dropped.

The new default format is an item age-dependant format as you can see in the screenshot. So items will have descriptive date labels with relative or day of week names. Items older than a week will additionally have the name of the month. Items not from this year will additionally contain the year and will have the exact time dropped.

This date formatting might be familiar to you. The simple reason being that it was copied from the Evolution source. The reasoning is when you have no user defined date formatting in Evolution why should Liferea need it?

For the few user who really did use the user-specified date format preference: there is a new GConf preference "/apps/liferea/date-format" where you can specify your favourite format string. Note: the old user-specified preference was saved into "/apps/liferea/timeformat", so you might just want to copy the content.

25 October 2006

Bloglines Integration

For v1.1.8 I added experimental Bloglines feed list synchronization support in SVN trunk. Additional to the already existing OPML feed list source type you can now add a Bloglines source to your feed list:

Note that current implementation will only synchronize the feed list with Bloglines. It won't allow you to edit it (because Bloglines doesn't support a subscription management interface). It also won't synchronize the item states with Bloglines (although this could be implemented in the future). The feed handling is the normal Liferea feed handling with the caching and updating options as defined in the preferences.

State Handling

When using either OPML or Bloglines sources in the feed list please keep in mind that feeds that are dropped from the source feed list will be unconditionally dropped by Liferea. There is no warning they will just vanish along with any flagged items!!! So copying important items to a news bin might be a good idea when using those feed list sources.

Security Considerations

Again a warning about the security implications when adding Bloglines source. Liferea will ask for username and password of your Bloglines account and will store it in plain text in ~/.liferea_1.1/feedlist.opml (with file permissions 0600). Also the feed list access at Bloglines is unencrypted HTTP.

21 October 2006

Define additional Social Bookmarking Sites

Here is a hint for everyone that is unhappy with the social bookmarking site selection that is available in Liferea v1.1.x. If you run a installation with LUA support enabled you can add a script that registers additional social bookmarking sites. To do so open up the script manager from the "Program" menu and select the startup hook. Create a new script and insert something like given in the following examples:

-- Registers an additional social bookmarking site

-- Example with URL posting only

-- Example with URL and title posting (title passed at second position)

-- Example with URL and title posting (title passed at first position)

The URL format is your choice as long as it contains the correct number of %s occurences. The exact meaning of the parameters should be intuitive but can be found in social.h.

The described solution is now avaibable with SVN trunk and will be released with v1.1.8.

Customizing Liferea HTML Rendering

Liferea displays feed items using a HTML. To format this output it uses CSS stylesheets that can be found in /share/liferea/css or a similar path. Now if you don't like the default styles you can overrule the default definitions with your own stylesheets.

User defined CSS with v1.0.x

v1.0.x uses two stylesheets for the two supported viewing modes. To display single items (in three pane mode) it uses "/share/css/liferea.css". To display multiple items (in two pane mode) it uses "/share/liferea/css/liferea2.css". To redefine the styles create the files "~/.liferea/liferea.css" and "~/.liferea/liferea2.css". Liferea will then load them additionally to the default style sheets.

User defined CSS with v1.2.x

v1.2.x uses only one default stylesheet "/share/css/liferea.css" for all three layout modes. Like v1.0.x it will additionally try to load a user defined CSS stylesheet from "~/.liferea_1.2/liferea.css".

To find out more about the used styles you can have a look at the default stylesheets or with v1.2.x which uses XSLT stylesheets for XHTML rendering you can look at the stylesheets which can be found in "/share/xslt/".

Note: to ensure using the GTK theme colors do use the GTK-THEME-* placeholders when defining colors as described in the header of the default stylesheet.

19 October 2006

Solving Font Problems

Depending on your system configuration and the HTML renderer used you might have problems with font quality in Liferea. For starters: Liferea supports two HTML renderers GtkHTML2 and Gecko (Mozilla/Firefox/XulRunner). The idea is to be as portable as possible and alternatively load either the GtkHTML2 or Gecko plugin to do the rendering. Now both renderers support different font engines and might have access to different sets of fonts.

How Liferea supplies font settings

The only easy and reliable way for Liferea to set a font for both supported renderers is to set it via a style definition in the generated HTML. Now the question remains which font definition is used. Liferea as a GTK, but GNOME-related, program reuses the GNOME document font setting. So if you are a GNOME user you can configure the Liferea font settings in the GNOME font preferences.

When you do not use GNOME and never set the GNOME preference you have the following alternatives:
  • Rely on the default font choice of the renderer.
  • Use gconf-editor to manually edit the GNOME document font preference /desktop/gnome/interface/font_name.
  • Provide a user defined CSS stylesheet with a default font.
Font Naming Conventions

When manually configuring fonts using gconf-editor you must follow the GTK naming scheme for fonts: <font name>,<font size in pt>, for example "Sans,11". When defining fonts using a user defined stylesheet you have to use the default HTML font family class names.

Not using the GNOME font

If you do not want to change the GNOME document font setting, but also want another font for Liferea you can manually set the GConf key /apps/liferea/browser-font. This setting will overrule the GNOME setting.

Anti-Aliasing Problems

As long as you use GtkHTML2 you can be sure that the GNOME anti-aliasing settings will be used in Liferea. But with Gecko you might get blurred or grainy rendering. It's hard to tell what is the exact reason in such a case. And there is no general hint how to workaround it. But you could try to disable/uninstall bitmap fonts so that Gecko won't have the chance to use them or you could try to find a better setting by experimenting with a user defined stylesheet.

12 October 2006

Firefox 2.0 Integration

The new version of Firefox 2.0 introduces a new and simple way to integrate Firefox with aggregators. While you needed an extra extension to add subscriptions from Firefox 1.5 to Liferea, now you can add Liferea support without any extra software.

You can now tell Firefox 2.0 to use the "liferea-add-feed" script to add new subscriptions to Liferea. You can change the feed handling either by going to the Preferences dialog or by clicking on the feed symbol. In both cases you will be presented with a menu where you can select "Choose Feed Reader". After clicking a file selection should popup. Select "/usr/bin/liferea-add-feed" and you are done!

Note: If you were using FeedBag with Firefox 1.5 it should have been disabled automatically and you can safely remove the extension.

05 October 2006

Unhappy with the icons?

Well, Liferea as a GTK application only uses the GTK stock icons and some self-made icons. If you want it to look more like the Tango icon set this GNOME-Look.org icon package for v1.0 built by Phrodo.00 could be what you want!

Update: Thanks to a patch from Eric Anderson SVN trunk now uses icons from the GTK icon theme for the folder, vfolder, enclosure and flag icon. To be released with v1.1.7

04 October 2006

Wide Screen View

One feature missing in Liferea until now: a wide screen mode, which presents feed list, item list and HTML view in three vertical panes instead of the classic email client interface. This feature which for example Akregator already had for some time will be released with v1.1.7 and should be very useful for 16:9 screens or users running Liferea in full screen.

The new feature caused some other changes. First I had to remove the toggle button that until now allowed switching between normal view and the so called condensed view. And then after looking at the naming of the viewing modes in Akregator I decided that the old naming was a bad one, which I attribute to my not so good English. Therefore I renamed the viewing mode names to the names used by Akregator: normal view, wide view and combined view. I think these are better labels.

02 October 2006

Flagging support in combined view

Today I added flagging support for the combined view in SVN trunk. A flagged item and its menu now look like this:

So for all flagged items the title will be of a red shade. Clicking the flag item menu option will toggle this state. After clicking the combined view will be updated. The current disadvantage is that the scrolling position will not be kept. I'm not sure yet how to solve this problem...

01 October 2006

Handling items in combined view

Judging from many postings in different weblogs the last days Google relaunch of the Google Reader has significantly cannabilized at the desktop feed reader userbases.

Well all of you still staying in the desktop aggregator world here is a new Liferea improvement to be released with 1.1.6. Basically it is a HTML menu bar to do useful things to items in the combined view. Currently there is no other user interaction besides scrolling and clicking links. The plan is to also expose the social bookmarking interface, the flagging feature and a not-yet-implemented tagging feature.

The screenshot shows how it will look like. First thing: the menu won't be visible initially. This way it doesn't take vertical space and if you don't need it, well then you don't see it. Also the menu will only be visible for one item at a time. To activate it you move the mouse over the item title and after a 1-2 second timeout the menu will appear. I think this is somewhat intuitive and expect new users to accidentily discover the feature.

24 September 2006

News Bins

Version 1.1.6 will introduce "news bin" support. A feature that can be found in many of the advanced commercial aggregators, which is a good reason to have it too :-)

If you don't know what a "news bin" is about: well it's like a container which you can use to collect items from the feeds you read. It is similar to the flagging feature (items with set flag are never deleted). It will also allow you to permanently keep items, but additionally you can create multiple news bins for different item categories. Also in difference to flagged items: items in news bin are not deleted when you delete the original feed.

22 September 2006

Choosing the right scripting language

First thanks to everyone who gave feedback and suggestions on the scripting post!

I think most of the "advanced" users (hey, I didn't say geeks!) agree that it would be nice to have such a feature. The killer argument of course is the NetNewsWire has it too. The real problem is which scripting language to choose.

There are several soliticing candidates:
  • Python: because it's widely used in GNOME and Liferea is often used in a GNOME environment.
  • Perl: because it can be found on almost every serious Unix installation
  • LUA: because it never crashed my favourite Angband variant while I was fighting evil mass summoners on level 97 after running three days and several million turns.
  • Javascript: because Liferea uses Gecko/XPCOM anyway
But there are contra arguments:
  • Python: 15% of the users won't have it installed, another 35% will hate programs forcing them to install it
  • Perl: 5% of the users won't have it installed, maybe 15% will hate programs forcing them to install it
  • Python+Perl: many unnecessary language features and function modules
  • LUA: pretty unknown, it's is rarely installed per default
  • Javascript: doesn't work with the GtkHTML2 rendering module, and XPCOM might scare you
How to decide?

Of course the percentages given above are just some guessed numbers. But I think they illustrate the problem that using a standalone interpreter language, no matter how sophisticated and object oriented, will leave some users without scripting support. The advantage on LUA and Javascript is that as a compile time library dependency each will be available when the program itself is usable. If it is not then it is a problem of the package maintainer who needs to ensure the correct dependencies.

Scripting Support Plugins

In the end there is no really obvious candidate. I think for a GNOME-related program either Python or a very simple embedded-only scripting language are most suited. And therefore I'll stay with LUA. But I realized it as a scripting support plugin and it should be really simple (patches are welcome) to write an alternative Python support plugin. The advantage of having plugins is also that maintainers can provide optional scripting support packages with the correct dependencies.

11 September 2006

Experimenting with Scripting Support

This weekend I added LUA scripting support to SVN trunk. I'm not sure wether this is a good and very useful idea but I just wanted to try and see how things work out.

The current code allows to open the "Script Manager" window (screenshot) from the "Program" menu. When opening for the first time there should be no scripts registered. Everything should be empty.

The idea is that you select a scripting hook (the option menu at the top) and add one or more scripts that are to be called when the hook is triggered. Currently supported hooks are:
  • Startup
  • Feed updated
  • Feed selected
  • Item selected
  • Feed unselect
  • Item unselect
A script registered for one of these hooks will probably always modify one or more of the currently selected item(s) or feed(s). The currently possible actions are limited by the generated LUA binding. Which is created using SWIG. Currently there are bindings for item.h, node.h, itemlist.h and feedlist.h which should allow to execute all item, feed and feedlist modifications from within LUA.

A simple and useful example is shown in the screenshot. It addresses a feature I was asked for several times, but which was never implemented as an seperate preference. The feature is to mark all items of a feed as read once it is unselected.

To do this a script for the "feed unselect" hook is added. It uses the "liferea" LUA module which maps all functions from the includes mentioned above. So it simply calls feedlist_get_selected() to determine the node that is to be unselected and calls node_mark_all_read() for this node.

What do you think about scripting support? Would you use it? Ideas for other use cases?

07 September 2006

Integrating Liferea with Firefox

Want to easily add subscriptions from within Firefox? You don't really need the live bookmarks feature of Firefox? Then FeedBag is the solution.

FeedBag is a very simple Firefox 1.5+ extension that changes the live bookmark subscription icon in the URL entry to add subscriptions to Liferea instead of creating a new live bookmark subscription.

To do this FeedBag relies on DBUS to send subscription requests to Liferea. So if it stops working please check that both Firefox and Liferea are started from within a DBUS enabled environment.

You can find FeedBag on addons.mozilla.org but you can also find the XPI on the SF project page or in the source tarball.

06 September 2006

Social Bookmarking with Liferea

Version 1.1.2 introduced social bookmarking support! Now you can configure Liferea to post links to one of 43 social bookmarking sites. The default setting is to use del.icio.us. To configure another site open the preferences select the "Headlines" tab and change the option under "Web Integration".

To post a bookmark new menu options were added to the item list and HTML view context menues. You can either bookmark an item by right clicking it in the item list and selecting "Bookmark Item" or you can bookmark any link in the HTML view by right clicking the link and selecting "Bookmark Link".

Depending on the social bookmarking site and its URL posting interface the item title will be passed as link description. But not all sites support this. When bookmarking links no title will be supplied.

Finally one might ask why the bookmarking sites are launched in the external browser only. There are two reasons:
  1. Some of the sites use HTTPS and Liferea doesn't set up the security manager for Gecko, so secure connections won't work with the internal browser.
  2. And launching in the external browser, assuming it is the browser used for normal web surfing, ensures correct auto-login to the bookmarking side.
Well this is how it is implemented. I hope it will be useful for a lot of users.

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