Bug 448258 - HOME and END key shortcuts are inconsistent
Summary: HOME and END key shortcuts are inconsistent
Status: RESOLVED DUPLICATE of bug 114267
Alias: None
Product: okular
Classification: Applications
Component: general (show other bugs)
Version: 21.12.0
Platform: Manjaro Linux
: NOR minor
Target Milestone: ---
Assignee: Okular developers
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2022-01-11 14:16 UTC by Andreas Korb
Modified: 2022-01-14 09:45 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Korb 2022-01-11 14:16:55 UTC
SUMMARY
The shortcuts for "Go to start" and "Go to end" with the HOME/Pos1 and END keys are inconsistent.

OBSERVED RESULT (not exhaustive list)
Okular & Kate:
Go to start: Ctrl + HOME
Go to end: Ctrl + END

Konsole:
Go to start: Shift + HOME
Go to end: Shift + END

Dolphin/Gwenview/Ark/KSysGuard:
Go to start: HOME
Go to end: END

EXPECTED RESULT
For Konsole and Kate it makes sense because HOME goes to the beginning of the line (vice versa for END), which is the more intuitive functionality in these cases. But still, it should be decided for Ctrl or Shift consistently as an auxiliary key if plain Home and End are used otherwise. For Okular I don't see a reason why an auxiliary key is necessary.

Otherwise, I'd expect plain HOME and END as the default (usually), and then, if pressed together with an auxiliary key (like Shift or Ctrl), I'd expect some special behavior. As an example for Okular, the proposed functionality from this ticket would feel natural for me with Ctrl + Home/End: https://bugs.kde.org/show_bug.cgi?id=114267
Comment 1 Nate Graham 2022-01-11 16:30:04 UTC
Kate is perfectly consistent within its text editing view; home and end go to the beginning of the current *line* not the whole document. This is the way multi-line text areas work everywhere.

Konsole requires the use of the Shift modifier to avoid overriding keys that terminal apps use. It's this way for everything. You have to add Shift onto the beginning of any other shortcut you want to use that affects the view.

Seen that way, Okular might be the inconsistent one here. I assume requiring Ctrl was done because losing your place by hitting Home or End accidentally was annoying.
Comment 2 Laura David Hurka 2022-01-14 00:44:41 UTC
> This is the way multi-line text areas work everywhere.

This matches my observation.

> I assume requiring Ctrl was done because losing your place by hitting Home or End accidentally was annoying.

Makes sense. Some laptops have those keys directly next to the usual arrow keys.

So you think Home and End should go to top/bottom of the current page, like in Bug 114267?
Comment 3 Nate Graham 2022-01-14 00:49:30 UTC
That seems reasonable to me. It would still be inconsistent, but at least the unmodified PageUp/PageDown keys would be doing something potentially useful, rather than doing nothing.
Comment 4 Nate Graham 2022-01-14 00:49:42 UTC

*** This bug has been marked as a duplicate of bug 114267 ***
Comment 5 Andreas Korb 2022-01-14 09:45:05 UTC
I'd prefer that Home and End are set as default for whole document scrolling. It's also the default for: evince, firefox, chromium

Even though not everywhere, for example xpdf does it exactly in the way as you suggest
with ctrl (document scrolling), without ctrl (page scrolling)

In my opinion, the default key shortcuts should not surprise the user for a good user experience. And me, for example, was quite surprised about the default shortcut. Even if an accidental press of Home or End happens, the user can still reason about it and act accordingly (by changing the default shortcut bindings or taking more care about what key to press).

In summary, I'm not sure if breaking consistency over all KDE applications only for Okular for a (maybe not so common) use-case is a good idea, as the defaults can be changed.