Well, for whatever reason keyboard navigation is working fine today. I'll
keep in eye on this.
In any case, it seems I am using mozilla rendering. This is under ubuntu
8.04, with liferea installed from the latest getdeb.net package.
ari@...:~$ liferea --debug-plugins
libnm_glib_nm_state_cb: dbus returned an error.
(org.freedesktop.DBus.Error.ServiceUnknown) The name
org.freedesktop.NetworkManager was not provided by any .service files
PLUGINS: Scanning for plugins (/usr/lib/liferea):
PLUGINS: -> libnotify notification (liblinotiflibnotify.so, type=3)
PLUGINS: -> LUA Scripting Support Plugin (libliscrlua.so, type=4)
PLUGINS: -> Mozilla Rendering Plugin (liblihtmlm.so, type=0)
PLUGINS: using "Mozilla" for HTML rendering...
Obtaining the module object from Python failed.
Traceback (most recent call last):
cant import cStringIO
<type 'exceptions.ImportError'>: /usr/lib/python2.5/lib-dynload/time.so:
undefined symbol: PyExc_ValueError
PLUGINS: using "libnotify" for notification type 0
PLUGINS: using "LUA Scripting Support Plugin" for scripting...
Lars Lindner-2 wrote:
>
> On Sat, Sep 27, 2008 at 5:38 AM, Ari El <ari.reads@...> wrote:
>>
>> In many feeds (typically Planets, e.g. Gnome Planet) I use Combined View.
>>
>> In previous Liferea versions, when reading a feed in Combined View, after
>> clicking the feed "content" section in liferea's window, I could use the
>> keyboard to navigate through the posts in the feed. The arrow keys,
>> page-down, space bar, all helped read the content while in combined view.
>>
>> Well, no longer in 1.4.19. I think the problem surfaced in 1.4.18
>> actually,
>> although I don't have a copy to verify.
>>
>> Can this be a problem in my particular setup? anyone else running into
>> this
>> issue?
>
> Just retested with 1.4.19 + WebKit rendering and it still works.
>
> I also didn't hear of any other users having the problem.
>
> Which rendering support module do you use? (If you don't know please
> post the output of a run with "--debug-plugins")
>
> Best Regards,
> Lars Lindner
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the
> world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Liferea-devel mailing list
> Liferea-devel@...
> https://lists.sourceforge.net/lists/listinfo/liferea-devel
>
>
--
View this message in context: http://www.nabble.com/Keyboard-navigation-no-longer-working-in-1.4.19-Combined-View-tp19699383p19715482.html
Sent from the liferea-devel mailing list archive at Nabble.com.

On Sun, Sep 28, 2008 at 1:04 AM, Lars Lindner <lars.lindner@...> wrote:
> On Mon, Sep 22, 2008 at 5:33 PM, Maik Zumstrull <maik@...> wrote:
>> I made a backup of liferea.db and removed the irrelevant views by hand.
>> So, to answer some of my original questions:
>>
>>> - Are these views slowing things down, because they are still
>>> regularly updated?
>>
>> Apparently, yes.
>
> Argh... That's really nasty. Thanks for pointing this out!
>
>>> - Is it safe to remove these views, that is, all views that are not
>>> referenced as a vfolder from feedlist.opml?
>>
>> Apparently, yes.
>>
>> Liferea is still working and seems to process updates much faster.
>
> I'll implement a "old" view cleanup on startup and think about a good way
> to remove search result views after the are not used anymore.
>
> I hope to create and release a solution asap...
I have released a new version 1.4.20 that does the following things:
1.) On startup checks the list of views in sqlite_master (the sqlite
object index)
against the views listed in the feed list. All not listed are dropped.
2.) I fixed the view dropping code to also remove triggers. So all views cleaned
up during startup and on search folder removal will not leave their
triggers anymore.
There are still the following drawbacks:
1.) Views generated for searches are still not removed. Though they will
be dropped on the next startup.
2.) Old unused triggers are not removed. When you removed search folders
in the past their triggers would not be removed. Those are not covered by
the cleanup on startup.
I hope to address issue 1.) in the search handling code. But I see no easy
solution for the second problem, maybe I need to experiment a bit more with
the sqlite SQL syntax to find a way to match all triggers that do not have
views anymore.
Nonetheless I hope the auto-cleanup now solves the performance
problems you expierenced. I also hope that leftover triggers without
corresponding views won't cause any significant overhead in sqlite.
Thanks again for analyzing this! Please retest!
Best Regards,
Lars

On Mon, Sep 22, 2008 at 5:33 PM, Maik Zumstrull <maik@...> wrote:
> I made a backup of liferea.db and removed the irrelevant views by hand.
> So, to answer some of my original questions:
>
>> - Are these views slowing things down, because they are still
>> regularly updated?
>
> Apparently, yes.
Argh... That's really nasty. Thanks for pointing this out!
>> - Is it safe to remove these views, that is, all views that are not
>> referenced as a vfolder from feedlist.opml?
>
> Apparently, yes.
>
> Liferea is still working and seems to process updates much faster.
I'll implement a "old" view cleanup on startup and think about a good way
to remove search result views after the are not used anymore.
I hope to create and release a solution asap...
Best Regards,
Lars

On Wed, Sep 24, 2008 at 5:07 PM, George Sherwood <pilot@...> wrote:
> Recently liferea 1.4.18 refuses to start. I get this error:
> george@...:/~$ liferea
> **
> ERROR:plugin.c:163:plugin_mgmt_init: assertion failed: (NULL != plugins)
> Aborted
>
> Any ides where I should start to look?
Yes, run with "--debug-plugins". This is usually a linker problem.
The rendering support module cannot be loaded for some reason
which prevents Liferea from starting.
Best Regards,
Lars

On Sat, Sep 27, 2008 at 5:38 AM, Ari El <ari.reads@...> wrote:
>
> In many feeds (typically Planets, e.g. Gnome Planet) I use Combined View.
>
> In previous Liferea versions, when reading a feed in Combined View, after
> clicking the feed "content" section in liferea's window, I could use the
> keyboard to navigate through the posts in the feed. The arrow keys,
> page-down, space bar, all helped read the content while in combined view.
>
> Well, no longer in 1.4.19. I think the problem surfaced in 1.4.18 actually,
> although I don't have a copy to verify.
>
> Can this be a problem in my particular setup? anyone else running into this
> issue?
Just retested with 1.4.19 + WebKit rendering and it still works.
I also didn't hear of any other users having the problem.
Which rendering support module do you use? (If you don't know please
post the output of a run with "--debug-plugins")
Best Regards,
Lars Lindner

In many feeds (typically Planets, e.g. Gnome Planet) I use Combined View.
In previous Liferea versions, when reading a feed in Combined View, after
clicking the feed "content" section in liferea's window, I could use the
keyboard to navigate through the posts in the feed. The arrow keys,
page-down, space bar, all helped read the content while in combined view.
Well, no longer in 1.4.19. I think the problem surfaced in 1.4.18 actually,
although I don't have a copy to verify.
Can this be a problem in my particular setup? anyone else running into this
issue?
Thanks
--
View this message in context: http://www.nabble.com/Keyboard-navigation-no-longer-working-in-1.4.19-Combined-View-tp19699383p19699383.html
Sent from the liferea-devel mailing list archive at Nabble.com.

Recently liferea 1.4.18 refuses to start. I get this error:
george@...:/~$ liferea
**
ERROR:plugin.c:163:plugin_mgmt_init: assertion failed: (NULL != plugins)
Aborted
Any ides where I should start to look?
George Sherwood

I made a backup of liferea.db and removed the irrelevant views by hand.
So, to answer some of my original questions:
> - Are these views slowing things down, because they are still
> regularly updated?
Apparently, yes.
> - Is it safe to remove these views, that is, all views that are not
> referenced as a vfolder from feedlist.opml?
Apparently, yes.
Liferea is still working and seems to process updates much faster.

During my continuing investigation into why Liferea is so slow for me,
I noticed this:
% sqlite3 .liferea_1.4/liferea.db .schema | grep ^CREATE\ VIEW | wc -l
41
All these views have associated update triggers. The thing is, I don't
have 41 search folders. The only search folders I have are the "unread"
and "flagged" ones.
Looking at the WHERE-clauses of these views, most of these seem to be
views created for search queries I ran at some point in the past
without creating a search folder.
Questions:
- Why have these views not been removed?
- Are these views slowing things down, because they are still regularly
updated?
- Is it safe to remove these views, that is, all views that are not
referenced as a vfolder from feedlist.opml?
- Shouldn't Liferea run an automatic cleanup on startup to remove all
views that are not referenced from feedlist.opml?
In case it's relevant:
% liferea --version
liferea 1.4.18

Hi,
first of all, a big thank you for all the developers of this great piece of
software :-)
I have written a somewhat complex "filter" I dubbed Identiger, which
displays timelines of Laconi.ca installations (like identi.ca) in Liferea
in much the same way standalone microblogging clients display them.
It's now part of the Laconi.ca Tools project:
http://sourceforge.net/projects/laconicatools/
You can find a screenshot there, too.
I'm a programming newbie and this is the first piece of software I release,
so I'm much more excited about it than it deserves, I fear, though I
thought it might interest you anyway. :-)
Regards, Jens

Hi Bruno,
Am Mittwoch, den 10.09.2008, 05:02 +0100 schrieb Bruno Miguel:
> A few days ago I installed Liferea 1.4.19 with Webkit as backend and I
> noticed that the scroll bar in the feed entries sometimes didn't
> appear or appeared scrolled down, even though I was just opening that
> item.
> I then recompiled Liferea with Xulrunner and I haven't experienced
> this issue so far.
I've noticed this issue too. I hope I have time to fix it in the next
days.
cu, Lars

A few days ago I installed Liferea 1.4.19 with Webkit as backend and I noticed that the scroll bar in the feed entries sometimes didn't appear or appeared scrolled down, even though I was just opening that item.
I then recompiled Liferea with Xulrunner and I haven't experienced this issue so far.

* George Sherwood <pilot@...> [2008-09-09 20:30]:
> When I look at them in other newreaders, I see headlines, so I
> don't think that is correct.
It *is* correct. Just visit the feed in your browser and View
Source.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/&gt;

On Tue, 9 Sep 2008 21:06:31 +0200
"Lars Lindner" <lars.lindner@...> wrote:
>
> Those other news readers propably reuse the <description> for the
> title tag. While this is a way to workaround such a strange feed, I
> don't see any good reason. Also please note that in this case the
> feed provides explicitely empty <title> tags. If you get a document
> where the author added an empty tag, isn't this a clear indication
> that the author did want to provide an empty text? I think it is
> correct to render "no title", and mostly because there is no title...
>
> BTW aside from the specs I consider feeds without titles useless and
> broken.
>
That is probably what is happening. I am going to leave them a message
and find out why they aren't putting anything in the <title> tags.
Thanks,
George

On Tue, Sep 9, 2008 at 8:22 PM, George Sherwood <pilot@...> wrote:
> On Tue, 9 Sep 2008 19:56:26 +0200
> Aristotle Pagaltzis <pagaltzis@...> wrote:
>
>> * George Sherwood <pilot@...> [2008-09-09 19:50]:
>> > With this feed http://instapundit.com/index.xml I don't see any
>> > headlines, they all say ***No title***. Any idea on this one?
>>
>> How about "the items in the feed do not have any titles"? Not
>> much that Liferea can do about that one…
>>
>
> When I look at them in other newreaders, I see headlines, so I don't
> think that is correct.
Those other news readers propably reuse the <description> for the
title tag. While this is a way to workaround such a strange feed, I don't
see any good reason. Also please note that in this case the feed provides
explicitely empty <title> tags. If you get a document where the author
added an empty tag, isn't this a clear indication that the author did
want to provide an empty text? I think it is correct to render "no title",
and mostly because there is no title...
BTW aside from the specs I consider feeds without titles useless and broken.
Lars

On Tue, 9 Sep 2008 19:56:26 +0200
Aristotle Pagaltzis <pagaltzis@...> wrote:
> * George Sherwood <pilot@...> [2008-09-09 19:50]:
> > With this feed http://instapundit.com/index.xml I don't see any
> > headlines, they all say ***No title***. Any idea on this one?
>
> How about “the items in the feed do not have any titles”? Not
> much that Liferea can do about that one…
>
When I look at them in other newreaders, I see headlines, so I don't
think that is correct.
George

* George Sherwood <pilot@...> [2008-09-09 19:50]:
> With this feed http://instapundit.com/index.xml I don't see any
> headlines, they all say ***No title***. Any idea on this one?
How about “the items in the feed do not have any titles”? Not
much that Liferea can do about that one…
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/&gt;

On Tue, 9 Sep 2008 19:29:31 +0200
"Lars Lindner" <lars.lindner@...> wrote:
> On Tue, Sep 9, 2008 at 1:05 PM, Aristotle Pagaltzis
> <pagaltzis@...> wrote:
> > * r7 <r7@...> [2008-09-09 12:45]:
> >> using liferea 1.4.17, the following two feeds do not display as
> >> expected:
> >>
> >> http://www.hardballtimes.com/main/rss/tht_live_sum/
> >> http://www.hardballtimes.com/main/rss/tht_articles/
> >>
> >> reading the source, i expect to see the full content, but i get
> >> just the headline.
> >>
> >> are my expectations wrong?
> >
> > The feeds have both `content:encoded` and `description` elements.
> > In pretty much all other feeds on the web, when both of these
> > tags are present, then they are either identical or `description`
> > contains an excerpt stripped of markup, and the full-text is in
> > `content:encoded`. So Liferea quite justifiably prefers
> > `content:encoded` when it sees both.
> >
> > But in those feeds, the `content:encoded` are empty, while the
> > `description` has the full text. So Liferea ignores the full text
> > in and instead show you the nothingness.
> >
> > And I bet that Liferea is not the only reader that does this.
> >
> > Whoever wrote the code for that feed either made a mistake or
> > didn't know what they were doing. If they simply removed those
> > useless `content:encoded` then the feed would work much better.
>
> I'm pretty sure I've added some handling to unstable which drops
> smaller text as soon as it encounters better (larger) text. This
> should workaround this problem.
>
>
With this feed http://instapundit.com/index.xml I don't see any
headlines, they all say ***No title***. Any idea on this one?
Thanks,
George Sherwood

On Tue, Sep 9, 2008 at 1:05 PM, Aristotle Pagaltzis <pagaltzis@...> wrote:
> * r7 <r7@...> [2008-09-09 12:45]:
>> using liferea 1.4.17, the following two feeds do not display as
>> expected:
>>
>> http://www.hardballtimes.com/main/rss/tht_live_sum/
>> http://www.hardballtimes.com/main/rss/tht_articles/
>>
>> reading the source, i expect to see the full content, but i get
>> just the headline.
>>
>> are my expectations wrong?
>
> The feeds have both `content:encoded` and `description` elements.
> In pretty much all other feeds on the web, when both of these
> tags are present, then they are either identical or `description`
> contains an excerpt stripped of markup, and the full-text is in
> `content:encoded`. So Liferea quite justifiably prefers
> `content:encoded` when it sees both.
>
> But in those feeds, the `content:encoded` are empty, while the
> `description` has the full text. So Liferea ignores the full text
> in and instead show you the nothingness.
>
> And I bet that Liferea is not the only reader that does this.
>
> Whoever wrote the code for that feed either made a mistake or
> didn't know what they were doing. If they simply removed those
> useless `content:encoded` then the feed would work much better.
I'm pretty sure I've added some handling to unstable which drops
smaller text as soon as it encounters better (larger) text. This
should workaround this problem.
Lars

Aristotle wrote:
> The feeds have both `content:encoded` and `description` elements.
> In pretty much all other feeds on the web, when both of these
> tags are present, then they are either identical or `description`
> contains an excerpt stripped of markup, and the full-text is in
> `content:encoded`. So Liferea quite justifiably prefers
> `content:encoded` when it sees both.
>
> But in those feeds, the `content:encoded` are empty, while the
> `description` has the full text. So Liferea ignores the full text
> in and instead show you the nothingness.
>
> And I bet that Liferea is not the only reader that does this.
>
> Whoever wrote the code for that feed either made a mistake or
> didn’t know what they were doing. If they simply removed those
> useless `content:encoded` then the feed would work much better.
thanks for this, i have forwarded your comments to the owner of the website.
r7
--
r7 [at] aktivix [dot] org

* r7 <r7@...> [2008-09-09 12:45]:
> using liferea 1.4.17, the following two feeds do not display as
> expected:
>
> http://www.hardballtimes.com/main/rss/tht_live_sum/
> http://www.hardballtimes.com/main/rss/tht_articles/
>
> reading the source, i expect to see the full content, but i get
> just the headline.
>
> are my expectations wrong?
The feeds have both `content:encoded` and `description` elements.
In pretty much all other feeds on the web, when both of these
tags are present, then they are either identical or `description`
contains an excerpt stripped of markup, and the full-text is in
`content:encoded`. So Liferea quite justifiably prefers
`content:encoded` when it sees both.
But in those feeds, the `content:encoded` are empty, while the
`description` has the full text. So Liferea ignores the full text
in and instead show you the nothingness.
And I bet that Liferea is not the only reader that does this.
Whoever wrote the code for that feed either made a mistake or
didn’t know what they were doing. If they simply removed those
useless `content:encoded` then the feed would work much better.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/&gt;

On Mon, 08 Sep 2008 17:28:23 +0200
Lars Strojny <lars@...> wrote:
> Hi Bruno,
>
> Am Montag, den 08.09.2008, 14:43 +0100 schrieb Bruno Miguel:
> > tried to edit the style.css in the cache folder, but every time I
> > run Liferea, the content of that stylesheet returns to its previous
> > state; That happened also when I was using Xulrunner in Liferea's
> > previous versions.
>
> Just use ~/.liferea_1.4/liferea.css for custom stylesheets.
>
> cu, Lars
Lars,
Any luck finding out why webkitgtk is so slow with liferea?
George

Hi Bruno,
Am Montag, den 08.09.2008, 14:43 +0100 schrieb Bruno Miguel:
> tried to edit the style.css in the cache folder, but every time I run
> Liferea, the content of that stylesheet returns to its previous state;
> That happened also when I was using Xulrunner in Liferea's previous
> versions.
Just use ~/.liferea_1.4/liferea.css for custom stylesheets.
cu, Lars