Blogs

Liferea synching to Feedly, AOL Reader and Digg Reader?

After Digg going live recently there are now three major free news aggregators available. With two of them you can register.

Today I migrated my old Google subscriptions to both Feedly and Digg Reader to have test accounts in case they open up their APIs. In the case of Feedly I did submit the developer registration, let's see if they find the Liferea user base large enough to respond. If you want to continue using a web-based aggregator you should migrate now to either Feedly or Digg Reader. Personally Digg feels a bit more like honest community than Feedly. But this probably doesn't mean much.

State of Feedly

http://feedly.com

Being the first to deliver the live migration Feedly gives you instant access, but no API. I guess they want to work only with some large aggregators.

State of Digg

http://digg.com/reader

Sadly Digg has post-poned the publication of their API for now. Meanwhile th import and the aggregator itself works fine. So let's hope.

State of AOL Reader

http://reader.aol.com

AOL Reader has an API, but I still don't have an account or I'd have started trying to port it. It seems they do not want or cannot scale as fast as intended.

Possibility of AOL Reader Support

Yesterday I took a look at the newly announced AOL Reader http://reader.aol.com/ and of course its API. The API is similar to Google Reader, is actually somewhat simpler. So you for example can't do GET requests, everything needs to be JSON POSTs.

This is not really a problem, I believe the API can easily be implement by building on the Google Reader code and taking the existing JSON handling from our TinyTinyRSS API client.

At the moment I cannot do it, as I did not get an account for AOL Reader yet. The have a queue. Yesterday they gave out only 200k accounts. Let's see when they open up further.

If you want to lend an account for testing, feel free to drop a mail!

Liferea 1.8.15 Released

This is a maintenance release fixing some bugs. It also introduces a backport of the Google Reader migration feature introduced in 1.10. This allows you to convert you Google Reader subscription to local Liferea subscription keeping all items downloaded so far.

Note: This migration will also work after Google Reader shutting down, as Liferea keeps a local cache of the Google Reader items.

Please upgrade to this release if you are/were using Google Reader and click "Convert to Local Subscriptions" from the context menu of the subscription list to migrate your Google data. Read more in this recent blog post.

Changes:

* Added an option to convert Google Reader subscriptions
  to local feeds (Lars Windolf)
* Fixes SF #1080: segfault opening attachment due to incorrect g_free()
  (reported by Adam Nielsen)
* Fixes SF #1075: GLib warnings of "string != NULL" assertion failure
  (reported by Simon Kågedal Reimer)
* Fixes search folders including comment items
  (reported by David Willmore)

Download the newest code from the project homepage!

Detecting a Dark Theme in GTK

When implementing an improved unread news counter rendering for Liferea if found it necessary to detect wether there is a light or dark GTK theme active. The reason for this was that I didn't want to use the foreground and background colors which are often black and something very bright. So instead from the GtkStyle struct which looks like this

typedef struct {
  GdkColor fg[5];
  GdkColor bg[5];
  GdkColor light[5];
  GdkColor dark[5];
  GdkColor mid[5];
  GdkColor text[5];
  GdkColor base[5];
  GdkColor text_aa[5];          /* Halfway between text/base */
[...]

I decided to use the "dark" and "bg" colors with "dark" for background and "bg" for the number text. For a light standard theme this results mostly to a white number on some shaded background. This is how it looks (e.g. the number "4" behind the feed "Boing Boing"):

Inverse Colors For Dark Theme Are Hard!

The problem is when you use for example the "High Contrast Inverse" dark theme. Then "dark" suddenly is undistinguishable from "bg" which makes sense of course. So we need to choose different colors with dark themes. Actually the implementation uses "bg" as foreground and "light" for background.

How to Detect Dark Themes

To do the color switching I first googled for a official GTK solution but found none. If you know of one please let me know! For the meantime I implemented the following simple logic:

	gint		textAvg, bgAvg;

	textAvg = style->text[GTK_STATE_NORMAL].red / 256 +
	        style->text[GTK_STATE_NORMAL].green / 256 +
	        style->text[GTK_STATE_NORMAL].blue / 256;

	bgAvg = style->bg[GTK_STATE_NORMAL].red / 256 +
	        style->bg[GTK_STATE_NORMAL].green / 256 +
	        style->bg[GTK_STATE_NORMAL].blue / 256;

	if (textAvg > bgAvg)
		darkTheme = TRUE;

As "text" color and "background" color should always be contrasting colors the comparison of the sum of their RGB components should produce a useful result. If the theme is a colorful one (e.g. a very saturated red theme) it might sometimes cause the opposite result than intended, but still background and foreground will be contrasting enough that the results stays readable, only the number background will not contrast well to the widget background.

For light or dark themes the comparison should always work well and produce optimal contrast. Now it is up to the Liferea users to decide wether they like it or not.

Most Important Redis Commands for Sysadmins

When you encounter a Redis instance and you quickly want to learn about the setup you just need a few simple commands to peak into the setup. Of course it doesn't hurt to look at the official full command documentation, but below is a listing just for sysadmins.

Accessing Redis

First thing to know is that you can use "telnet" (usually on default port 6397)

telnet localhost 6397

or the Redis CLI client

redis-cli

to connect to Redis. The advantage of redis-cli is that you have a help interface and command line history.

Scripting Redis Commands

For scripting just pass commands to "redis-cli". For example:

$ redis-cli INFO | grep connected
connected_clients:2
connected_slaves:0
$

Server Statistics

The statistics command is "INFO" and will give you an output as following:

$ redis-cli INFO
redis_version:2.2.12
redis_git_sha1:00000000
redis_git_dirty:0
arch_bits:64
multiplexing_api:epoll
process_id:8353
uptime_in_seconds:2592232
uptime_in_days:30
lru_clock:809325
used_cpu_sys:199.20
used_cpu_user:309.26
used_cpu_sys_children:12.04
used_cpu_user_children:1.47
connected_clients:2
connected_slaves:0
client_longest_output_list:0
client_biggest_input_buf:0
blocked_clients:0
used_memory:6596112
used_memory_human:6.29M
used_memory_rss:17571840
mem_fragmentation_ratio:2.66
use_tcmalloc:0
loading:0
aof_enabled:0
changes_since_last_save:0
bgsave_in_progress:0
last_save_time:1371241671
bgrewriteaof_in_progress:0
total_connections_received:118
total_commands_processed:1091
expired_keys:441
evicted_keys:0
keyspace_hits:6
keyspace_misses:1070
hash_max_zipmap_entries:512
hash_max_zipmap_value:64
pubsub_channels:0
pubsub_patterns:0
vm_enabled:0
role:master
db0:keys=91,expires=88

Changing Runtime Configuration

The command

CONFIG GET *

gives you a list of all active configuration variables you can change. The output might look like this:

redis 127.0.0.1:6379> CONFIG GET *
 1) "dir"
 2) "/var/lib/redis"
 3) "dbfilename"
 4) "dump.rdb"
 5) "requirepass"
 6) (nil)
 7) "masterauth"
 8) (nil)
 9) "maxmemory"
10) "0"
11) "maxmemory-policy"
12) "volatile-lru"
13) "maxmemory-samples"
14) "3"
15) "timeout"
16) "300"
17) "appendonly"
18) "no"
19) "no-appendfsync-on-rewrite"
20) "no"
21) "appendfsync"
22) "everysec"
23) "save"
24) "900 1 300 10 60 10000"
25) "slave-serve-stale-data"
26) "yes"
27) "hash-max-zipmap-entries"
28) "512"
29) "hash-max-zipmap-value"
30) "64"
31) "list-max-ziplist-entries"
32) "512"
33) "list-max-ziplist-value"
34) "64"
35) "set-max-intset-entries"
36) "512"
37) "slowlog-log-slower-than"
38) "10000"
39) "slowlog-max-len"
40) "64"

Note that keys and values are alternating and you can change each key by issuing a "CONFIG SET" command like:

CONFIG SET timeout 900

Such a change will be effective instantly. When changing values consider also updating the redis configuration file.

Multiple Databases

Redis has a concept of separated namespaces called "databases". You can select the database number you want to use with "SELECT". By default the database with index 0 is used. So issuing

redis 127.0.0.1:6379> SELECT 1
OK
redis 127.0.0.1:6379[1]>

switches to the second database. Note how the prompt changed and now has a "[1]" to indicate the database selection.

To find out how many databases there are you might want to run redis-cli from the shell:

$ redis-cli INFO | grep ^db
db0:keys=91,expires=88
db1:keys=1,expires=0

Dropping Databases

To drop the currently selected database run

FLUSHDB

to drop all databases at once run

FLUSHALL

Checking for Replication

To see if the instance is a replication slave or master issue

redis 127.0.0.1:6379> INFO
[...]
role:master

and watch for the "role" line which shows either "master" or "slave".

Starting with version 2.8 the "INFO" command also gives you per slave replication status looking like this

slave0:ip=127.0.0.1,port=6380,state=online,offset=281,lag=0

Enabling Replication

If you quickly need to set up replication just issue

SLAVEOF <IP> <port>

on a machine that you want to become slave of the given IP. It will immediately get values from the master. Note that this instance will still be writable. If you want it to be read-only change the redis config file (only available in most recent version, e.g. not on Debian).

To revert the slave setting run

SLAVEOF NO ONE

Dump Database Backup

As Redis allows RDB database dumps in background, you can issue a dump at any time. Just run:

BGSAVE

When running this command Redis will fork and the new process will dump into the "dbfilename" configured in the Redis configuration without the original process being blocked. Of course the fork itself might cause an interruption.

Use "LASTSAVE" to check when the dump file was last updated. For a simple backup solution just backup the dump file.

If you need a synchronous save run "SAVE" instead of "BGSAVE".

Listing Connections

Starting with version 2.4 you can list connections with

CLIENT LIST

and you can terminate connections with

CLIENT KILL <IP>:<port>

Monitoring Traffic

The propably most useful command compared to memcached where you need to trace network traffic is the "MONITOR" command which will dump incoming commands in real time.

redis 127.0.0.1:6379> MONITOR
OK
1371241093.375324 "monitor"
1371241109.735725 "keys" "*"
1371241152.344504 "set" "testkey" "1"
1371241165.169184 "get" "testkey"

Checking for Keys

If you want to know if an instance has a key or keys matching some pattern use "KEYS" instead of "GET" to get an overview.

redis 127.0.0.1:6379> KEYS test*
1) "testkey2"
2) "testkey3"
3) "testkey"

On production servers use "KEYS" with care as you can limit it and it will cause a full scan of all keys!

Improved Unread Counters

For the 1.10 I decided to change the unread counters in the subscription list tree view. Until now the number of unread items was displayed in braces right behind the feed title in addition to the feed title displayed in bold font weight.

Before

Here is how it is looking in the releases so far:

Old Unread Counter Rendering

There is a serious disadvantage that you only notice if you do not have much screen space. Imagine a netbook for example. There the subscription titles will be truncated as you won't spend much space on the left pane. And the first victim of the ellipsizing is the unread counter. But out of the three visual elements: favicon, subscription title and unread counter, only two are important. The favicon allows you to easily find the feed, and the only real information is the unread counter.

After

So have a look at this screenshot, especially the "tagesschau" subscription:

New Unread Counter Rendering

Actually a lot of applications especially in the Mac world do this already and I think Liferea also benefits. I'm aware that the change is a bit visually disturbing and I hope most users will still like it. I'm looking forward to your feedback!

PS: Round borders on the number background is sadly not possible with GtkCellRendererText.

Liferea 1.10-RC4 Released

There is a new release candidate for 1.10 with several bug fix
contributions. It also introduces a feature to convert Google Reader
subscriptions to local feeds to allow everyone to keep their item history.

Read more about it in the previous blog post!

The Changes:

* Added an option to convert Google Reader subscriptions
  to local feeds (Lars Windolf)
* Fixes SF #1080: segfault opening attachment due to incorrect g_free()
  (reported by Adam Nielsen)
* Fixes SF #1075: GLib warnings of "string != NULL" assertion failure
  (reported by Simon Kågedal Reimer)
* Fixes missing shading in 2-pane mode rendering
  (reported by Zoho Vignochi)
* Fixes search folders including comment items
  (reported by David Willmore)

A corresponding maintenance release for 1.8 will follow!

Save Your Google Reader Data with Liferea!

If you were using Google Reader synchronization with Liferea do not delete your subscription! Instead convert it to local subscriptions and keep all your item history.

To do so choose the option "Convert To Local Subscriptions" from the feed list context menu:

Screenshot on converting Google Reader subscription

I hope this feature helps everyone who cares about the item history he has from his synchronized Google Reader subscriptions.

Two Important Notes

  1. This feature will be included starting with release 1.8.15 and 1.10-RC4. Don't worry you can migrate all data even after Google Reader shuts down as all data is kept locally in the Liferea sqlite database. Just do not delete the Google Reader subscription in the meantime.
  2. While the conversion is quite simple it is not perfect. There will be item duplication afterwards as the item id matching is not consistent. Google Reader item ids do not match the original item ids so Liferea will produce some duplicates right after converting. But only for those items overlapping at this moment. Please just mark them as read!

Liferea 1.8.14 and 1.10-RC3 Released

Following the previous releases this new stable and unstable release fix a problem with the TinyTinyRSS support which caused broken headline rendering.

Please upgrade if you use TinyTinyRSS!

Bug: Endless TinyTinyRSS Updates

If you experience not ending TinyTinyRSS feed updates or high load when using TinyTinyRSS subscriptions please upgrade to the newest releases 1.8.13 and 1.10-RC2 which solves this bug.

Syndicate content