Scroll up and down with shortcut

I want to use an okular because I can annotate, makes notes in it. But I don’t like that I’m not able scroll as in zathura up and down with a keyboard shortcut. I tried to bind keys to scroll up and down, but it’s not the behavior I have in zathura, instead it continuously scrolls even when I’m not pressing any key.

I only get continuous scrolling when I explicitly choose to activate that.

With my key bindings (which might even be default?) single key strokes only scroll once, I need to hold Shift while pressing a scroll key to make it continuous.

1 Like

With “Scroll Down” action?
It works as expected with arrow keys, but there isn’t any action to bind to get the same result.

1 Like

In most cases I scroll with mouse wheel or touch pad gesture but if I use shortcuts I am using cursor up/down for scrolling in smaller steps and page up/down for scrolling in larger steps.

Or Shift + cursor up/down for continuous scrolling.
Although I never really use that as it is supper annoying to have content constantly moving regardless of your current reading speed.

I want to avoid using mouse/touchpad/trackpoint if it is possible to do it with hotkeys. But in okular I wasn’t able to do it

If I focus the document view and press the arrow keys, PageUp/PageDown keys, or spacebar/Shift+spacebar, I can scroll through the document using only the keyboard. Are you saying this isn’t working for you?

I don’t want to use arrow keys for scrolling up and down, instead I want to use haei, aka hjkl in vim (haei because I type on alternative keyboard layout).

This works for me:

1 Like

I don’t want to scroll the page up/down, but rather line by line.
I set up global pgup/pgdown keybinds and don’t need to set it up in the application’s settings. But I miss the feature of scrolling lines up/down just like in zathura using vim keys.

Ah, so the issue is that the actions bound to cursor up/down are not re-assignable.

My guess is that these aren’t actions (yet) but built-in behavior of the scroll view.

I wonder if changing the global “next/previous element” shortcuts could affect that

I have something like in zathurarc:

map h scroll left
map a scroll down
map e scroll up
map i scroll right

Can I bind same actions for okular?

The “Scroll up” and “scroll down” actions are re-bindable/assignable in Okular, but the issue is that these actions seem to scroll up or down by one pixel, not a larger and more useful amount. This might have been an unintentional result of the change several years ago to implement pixel-by-pixel and animated scrolling.

At this point it’s seeming like a legitimate bug.

Not a respond to your specific question about Okular but on a more general level I can advice you to look at keyd ( https://github.com/rvaiya/keyd ).

It is a keyboard remapper (very simple, with simple config file in /etc) give you the possibility to have layer for navigation for exemple, including mapping mouse movement and mouse scroll to key/layer. (like QMK/ZMK programmable keyboard if you know that, but cheaper :wink: ) As it work at low level it works consistently everywhere (including console).

I already use one called kanata which is written in Rust and cross-platform, for almost a year now.
Why can’t I include links in my posts?

Well, I began using for application-aware remapping.

I didn’t know about kanata (there is also kmonad for linux). It seems complete, but I use only linux and keyd is more integrated. It works at the udev level (creating a virtual keyboard between kernel and the system) so basicaly everywhere (include the linux console) very reliable not dependant of for example flatpaks, electon app etc.
I have seen the per-app feature, I have no use for it yet but it is a nice thing to have. I have a rather simple config (but powerful) with customa alpha layer and a navigation one with commands . There is also possibility to have a config that work with unicode (using compose) but I find it limited.

Unfortunately, it doesn’t work when I’m prompted to unencrypt the luks drive. Xkeyboard-config keymap should be created for this purpose, and there’s already an open merge request on freedesktop’s gitlab with the type of keyboard layout called graphite.

Yes It still need to have the system start. I live with the fact that I have to use another layout at this point.
Graphite seems interesting but I have a personal layout that i may publish. It is a more international one.