Transparent Tray Icon

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

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

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

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

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

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

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