Liferea

infernux: Sorry, that the people working on Liferea failed to create the
perfect feed reader just for you. Do you think these "Ok. I have enough.
Now I switch!" threats do have any desirable effect? But be assured that
this will decrease my open source contributions.

To correctly document this bug report: from my perspective there are
currently two distinct features in Liferea allowing to quickly skip through
unread articles. I'm not aware of known reproducable problems in these two
features (as of 1.4.8).

Fine, this is enough for me. If quickly skipping through unread articles
is not a desired feature for lifera, than it was surely not made for my use
case. Time to use another of those 234435 newsreaders...

jmason: I'm sorry if I misunderstood you. But please try to see that what
I explained below *IS* the intended behaviour of *ALL* previous releases.
Any previous release that did behave differently was broken. If it works
now as I described then everything is ok. Judging from the small number of
bug reports I got on this issue I assume only a few people were affected by
any previous bug in this feature. From this I conclude that a) the current
implementation works as planned and b) that for most people it always
worked this way, so there is no good reason to change it. In the opposite
it is a bad idea to change it because it would break the feature for most
people.

Just because a previous release accidentily broke the <Space> feature is
no reason to change it to this behaviour.

Please correct me if you think I'm wrong on this.

hi Lars --

I think you misunderstand me -- I agree that maintaining compatibility
with the behaviour of previous releases of liferea is what's most
important. In fact I'm advising that it would be better to do that, than
to conform to the GTK guidelines on this point -- IMO it would be better to
support <Space>'s behaviour from earlier releases.

jmason: I understand your wish to make it more consistent. But please
consider that Liferea already exists 3.5 years now and changing key
bindings for consistency and thereby forcing users to relearn the bindings
they could use until now is not a good idea. From my pov, as a developer
doing this for the users, I just *CAN'T* change it. I value the consistency
gain much much lower than the disturbance of let's say 100 users that
cannot use "their hotkey" anymore.

kirilov-georgi: If you want to try to improve the space handling please
try! But be warned over time with different Gecko releases I and other
people already spent weeks on it without any better result. But maybe this
motivates you :-)

I'm closing the bug report again. Please reopen if you disagree!

'jmason: In my understanding this is not a regression. The functionality
works as implemented. This is more of a discussion if it should behave
like
it is implemented.'

ok, regression is a bit harsh. 'change in behaviour from prior versions'
then ;)

Regarding the behaviour of <Space> -- it seems inconsistent to me that
<Ctrl+Space> (for example) works with any pane focussed, but <Space> only
with the HTML view pane. I would suggest that this is one case where the
GTK guidelines can be ignored, for consistency...

Hi,
Now I see that I have misunderstood the whole thing. What I thought was a
bug, was really intended, yes. Well, actually I don't care much about the
skimming key, because I don't use much of it.
What made me write here was that <Space> in text entries in htmlview does
not insert space, but scrolls down. I find this annoying and other browsers
don't behave like this, so I guess that was not intended. Unfortunately I
haven't found solution for this yet but I'm on my way.
This may be more approriate to separate bugreport, though.
Best Regards!

jmason: In my understanding this is not a regression. The functionality
works as implemented. This is more of a discussion if it should behave like
it is implemented.

all: I still disagree. Sure it would be possible to have a global <Space>
key binding. But it would make no sense. GTK explicitely does implement
<Space> as a key binding for several of it's widgets. Rebinding <Space>
means to break the default behaviour for such widgets (tree views, buttons,
input fields). Redirecting <Space> only for the HTML view is already hard
enough because it must not be done when input fields (HTML forms or Liferea
UI input fields) do have focus. In each of the browsers I use <Space> only
pages down when the HTML view is focussed and does other things or nothing
at all in the other GUI parts (e.g. side bars, dialogs, toolbars...). And
that Sylpheed is an exception from this standard behaviour might be an
indication for non-standard usability handling. Liferea as a web-browsing
application should behave like any other web browser and like every other
GNOME/GTK application as much as possible. This means that the browser view
paging key binding, which per-default is implemented by and for the HTML
view widget-*ONLY*, should also stay HTML view widget-only when it is
extended by Liferea to be a browser view skimming key binding.

And for all other use cases there is a main menu option for the
Next-Unread feature which is functionally equivalent where you can bind any
keybinding you want. Except for <Space> because GTK disallows it
*EXPLICITELY*.

I understand that you would like to use the easiest key binding you can
think of, which is <Space>. But technically this is a bad idea and cannot
be extended on the whole GUI. The limitation for using <Space> is, and will
stay that way unless someone can give me a better reason, that the HTML
view pane *MUST HAVE* focus.

adding another +1 for kirilov-georgi's proposal, it makes good sense and
fixes this regression (this was not an issue in 1.0.x or earlier)

+1 for kirilov-georgi's proposal!

Having <shift> work differently form <ctrl+shift> because <shift> also has
another meaning in other views is just not a nice idea. And having to click
into the html view every time is not usable. Also, launching in webbrowser
doesn't seem to me as if it was a very commonly used feature, moving this
to <return> really makes sense.

I would like to ask you to try Sylpheed. It is a mail client with the same
3-pane window layout as liferea. It handles <Space> (and <BackSpace>) very
gracefully. If you have the time to try it, please tell me if the same
behaviour is acceptable for liferea.
Thanks.

> Again please note: the item list has a different <Space> key binding
than
> the HTML view! This is an intended behaviour.

I see now. From what I have just tried, it turned out that plain <Space>
was actually working, but ONLY if the focus was in the htmlview. With
feedlist focused it does nothing, and on the itemlist it activates the item
link, as you said. But is this optimal? Imagine this - I start liferea,
press <Space> and expect it to move on the first unread item. It doesn't
because the inital focus is not in the htmlview. Actually it does because
the initial focus is on the Next Unread Item toolbar button, but that's
another story.

What about <Space> always moving to the next unread item, no matter where
the focus is, and <Enter> in the itemlist for activating the item link.
This sounds good to me.

kirilov-georgi: I cannot reproduce this (XulRunner 1.8.1.9 here). When
HTML view has focus <Space> works as expected (triggering next-unread).
When the item list has focus <Space> works as expected too (triggering the
link activation) as the default GtkTreeView activation key binding.

So from my pov there is no functional problem.

Again please note: the item list has a different <Space> key binding than
the HTML view! This is an intended behaviour.

infernux: Ok. But please note that the Shift-/Ctrl-modifiers might mask
focussing problems. Also please note the scrolling feature of <Space>. The
HTML view first scrolls to bottom and then triggers next-unread. Please
ensure that you have are have scrolled down totally when testing. BTW I
personally do not test with FireFox, so there might be differences.

For the record: I used firefox2 (the one in ubuntu gusty) to build liferea
against, so no xulrunner or plain mozilla here.

Hi, I had the same problem with <Space> as skimming key
(liferea 1.4.7 with xulrunner-1.8.0.4).
More precisely, <Space> doesn't advance to the next unread item at all,
moreover if the focus is in the itemlist, it activates the item link in
htmlview.
Soon I'll send a patch which includes possible fix for this.
There was a check for the current html engine in the global keypress
handler.
In case it is mozilla or xulrunner, the handler returns FALSE and passes
the keypress ahead.
I deleted the check for xulrunner and <Space> began to work as I expected,
i.e. always advance to next unread item, and scrolls down the current
htmlview if nessessary.
May be the check was nessessary due to bug in xulrunner and recent
releases have this bug fixed, so we don't need special handling of space
anymore.

Sorry for not making myself clear. You said that my problem is most likely
related to another part of the application having focus. This is _not_ the
case. If I use the ctrl+shift binding it works, if I switch to space and do
exactly the same, it does not work.

Sorry, what do you mean with "can change the binding without focusing"? I
think this can be no functional problem when it works for a while and then
stops.

Without knowing the exact cause all I can do is guess...

I tested again now with the latest version and it still doesn't work for
me with just space. And I don't think it is a focus issue (I've thought
about that too, but I can change the binding without focusing another pane
and with ctrl-space it just works as I would expect, with space it doesn't
:(

Fix released with 1.4.2.

Thanks for your retest! Your description sounds more like focussing
issues. Please note that when the focus is in the HTML viewing pane <Space>
acts as the skimming hotkey. But when focus is in the item list <Space> is
the default key binding for activating list entries and activating and item
(e.g. by double clicking on it) is opening the item in the browser. So I
think it works for you.

This is not yet completely fixed I think. I was able to use space for a
while, but then space started to open the current article in the browser
again. I cannot reproduce the cause of this exactly but after a while you
get this behavior...

Fixed in SVN. To be released with 1.4.2.

The reason was a wrong code optimization due to missing documentation.

I forgot: it currently doesn't work regardless of the used browser plugin.

chris_conway: I agree this should work.

I also have to take back my previous answer that it didn't work with
previous Gecko-based releases. It did work. And it should work. Please give
me some time to investigate this!

I'm having the same problem. This might be a "usability" rather than a
"functional" problem, but it really ought to be fixed: the software doesn't
do what it says it will do. This is very confusing/frustrating.

Hmm <space> doesn't seem to work even with gtkhtml :/

Oh... well, time to change to gtkhtml2 then ;)

Would be nice to have this fact a bit more obvious, though... Or better
yet, have WebKit in a shape to have it being usable here ;)

This is a misunderstanding (and effectively a usability problem).
Depending on the used rendering backend (Gecko, GtkHtML2...) <Space> can be
used or not. Meaning there is no way to catch Space when using Gecko. I
assume you do use Gecko.

Now I could solve the usability problem by just dropping this option at
all, but this would rob GtkHTML2 users the possibility to use the really
convenient Space hotkey...

So I'd like to declare this as no functional issue but a workaround and as
such a usability issue that won't fix. What do you think?