'n' sometimes doesn't step to next

Jaimie

I've only seen this since 0.64.8 this afternoon, but I've seen it four times now.
Sometimes 'n' doesn't do anything on a post, tapping several times doesn't help. So far 'space' always does the jump but I've only been using it for paging so it's had fewer chances to go wrong. I've got both set to jump to 'next unread'.
If I click away from the message and go back to it, 'n' will work so it doesn't seem to be tied to a post. The next unread can be same thread or different thread, I've seen both.

Andre

Could it be that you selected or clicked a component other than the subscriptions pane or top right pane?
Keyboard events are normally sent to the components that are 'focussed'. As far as I know I've changed this for all components, but I might have forgot one.

Snit

I thought I was seeing this as well. Seems to jump to next thread even though there were unread posts in that thread. If I see again and can replicate will let you know.

Jaimie

You're right about focus - if I click on the message body pane, 'n' does nothing - so that's one to fix 🙂 Spacebar does work in that situation too.
I'm pretty sure I wasn't clicking into the body yesterday though, since I wasn't hand-on-mouse. I'll keep an eye out for other cases, focus or otherwise.

Andre

It seems it doesn't work always as it should be.
I'll fix this later.

Andre

I see that 'n' and 'p' stop at then end of the thread, accept when the next/previous thread is a single messages.
I'll fix that and let it walk through the whole subscription.

Andre

I just noticed that my above message is not always the case. Weird.

Andre

Is this solved now?

Jaimie

I'm afraid not (0.66.4) - you can replicate by being in a post with a later unread post(s), clicking in the body of the current post (forcing focus to the body pane), and hitting 'n'. Nothing happens. Space still jumps to next (unread). (next vs next-unread choice doesn't matter, fails either way)

Andre

I'm working on a better solution which will solve the keyboard shortcut issues.

Andre

Update 0.67 is released and this whole part is rewritten.
Please let me know if this is now fixed.

Snit

Andre Update 0.57 is released

I assume this is a typo and you meant 0.67...

Just looked at it... it might be far enough along for me to use it as my main Usenet client. Exciting!

Andre

Snit I assume this is a typo and you meant 0.67...

Correct. I'll change it.

Andre

Snit Just looked at it... it might be far enough along for me to use it as my main Usenet client. Exciting!

The composer (editor) has still some weird behaviours, but that will be fixed soon.

Jaimie

In 0.67 - Still not getting anything from 'n' if I click to focus on the message body pane 🙁 So no change in behaviour as far as I can see. Space still works. Anything I can demonstrate to you for working this out?

Andre

Ah, that is correct. If the message view is focussed it eats all the keyboard events, expect the ones that are hardcoded elsewhere like the tab and spacebar.

I thought you had this issue without having selected anything, but I must have misunderstood you.

What I'll do is move away the other key events from message view so it doesn't respond to the ones with other functions.

Jaimie

Oh. What's the rationale behind removing possible actions when the message body pane is selected? I would have thought having those keys available under all conditions except typing would be most useful.

Andre

Most components handle their own key events.
So if the textview is selected then it holds most of the key events for itself and no other components are aware of these events. Only some special key events are sent to the main window.

What I must do is intercept some key events inside these components and sent them to the main window.
Like the "tab" "n" "t" "p".

Andre

Fixed in v0.67.1.
Can you confirm that please.

Jaimie

Woohoo! Looks good! I misinterpreted what you meant, obviously 🙂
Late night coding is best coding. It's just the truth.