Thanks for the very speedy replies! Some responses:

4.) If this doesn’t already work for you then there is a bug. We have implemented it to follow the GNOME2 menu settings. It works for me.

After changing the Desktop Preferences => Menus & Toolbars setting and restarting Liferea, it has taken effect. My mistake! However, the toolbar display style changes don’t apply in real-time as they do to Epiphany. Is this also a quirk of my installation or just a difference in how the two applications are programmed?

7.) This means depending on a GNOME application. Also how many users use the simple clock applet…

While I understand the desire not to depend on GNOME, I think it is safe to assume that most users will be using Liferea while running GNOME, which displays the menu bar clock by default.

19.) a) It’s right all non-HTTP[s] Links should be forwarded to the configured external browser. (-> todolist)

As for the display format I already added a tooltip that says that you can use the strftime() format codes.

The tooltip is helpful, but I think a bit of text is better since it does not require first the selection of that option, and then mouse focus on the input box.

19.) b) Hmm… I think interface isn’t good. What is an interface? Even a parking slot is an interface of some type. And personally I expect people who use Liferea to know what a GUI is.

I agree that Interface isn’t ideal – how about View Settings? More descriptive, but it would take up a bit more space.

“And I believe you that NNW shows you titles. Probably they use the start of the article as title.”

On closer inspection, I see that you are correct; NNW does just use the first few words of the post as a title.

“Maybe Liferea should extract some of the description in case of empty title. But this of course is not easy because the text can be arbitrary HTML.”

I wish all feed authors would provide (non-empty!) post titles, but given the number that don’t bother to, it is worthwhile for Liferea to provide a workaround.

<item>
<title></title>
<link>http://www.gusmueller.com/blog/archives/2004/8/11.html#1122</link>
<description&gtToday is Kirsin’s 26th birthday, Happy Birthday Kirstin!

For me the headline does *explicitly* specify an empty title. The question is what is the meaning of the RSS 2.0 specification when it allows to omit a title when the item is completly contained in the description. Means omitting the title omitting the tag or just a value?

Maybe Liferea should extract some of the description in case of empty title. But this of course is not easy because the text can be arbitrary HTML.

2.) I understand this. But one cannot totally get rid of the term “feed”. When you talk about invalid XML you have to refer to the feed and not the subscription. With the current release (0.5.2c) the menues/dialogs should always use the term “subscription” and only error messages concerning the handling of the real data source – the feed – should talk about “feeds”. Maybe several of these message could substitute “feed” with “subscription”. I’ll add checking this to the todo list for 1.0.

3.) I understand why this could be good but I think this won’t be implemented. It’s just to complicated. But we plan to add multiple selections for the item list.

4.) If this doesn’t already work for you then there is a bug. We have implemented it to follow the GNOME2 menu settings. It works for me.

5.) Hmmm… There are so many personal preferences :-)

6.) Good idea for 1.1

7.) This means depending on a GNOME application. Also how many users use the simple clock applet…

8.) I think this could be changed. I’ll add it to the todo list.

9.) I don’t think it’s necessary to bind hotkeys for seldom used commands as long as GTK2 allows you the user to bind personal keys.

10.) The tray icon is very simply implemented. It is intended to be a flag which shows you if new headlines arrived and that is worth to uniconify the program again. As soon as it notices that you do something with the application (reading, feed selection…) it resets the icon. I don’t think this is unlogical.

11.) Good idea. -> todolist

12.) Complex to implement. Is it worth to do it? How many users will use it? I don’t think many.

13.) -> todolist

14.) I don’t think we need another menu entry. But with 0.5.3 I already added a feedvalidator.org link to the error message displayed in the feed description when the parsing fails. Of course this could even be improved some more by passing the URL to feedvalidator.

15.) I’ll check this…

16.) Already in the todolist

17.) -> todolist

18.) This is for debugging purposes because a lot of bug reports miss the version number. If the version wouldn’t be displayed so offensive I fear a lot more reports would miss the information. I promise this will be removed with 1.0.

19.) a) It’s right all non-http[s] Links should be forwarded to the configured external browser. (-> todolist)

As for the display format I already added a tooltip that says that you can use the strftime() format codes.

19.) b) Hmm… I think interface isn’t good. What is an interface? Even a parking slot is an interface of some type. And personally I expect people who use Liferea to know what a GUI is.

Thanks for this intensive reviewing of the program! I try to realize all things added to the todolist in the next time. Some of your suggestions are to complex to implement so I don’t think they’ll be implemented. But it’s open source, so anybody is free to do it! I’ll be happy to merge any good patches.