Bug 460583

Summary: Respect the platform's standard behaviour with the ctrl key
Product: [Applications] ghostwriter Reporter: Riccardo Robecchi <sephiroth_pk>
Component: generalAssignee: megan.conkle
Status: CLOSED UPSTREAM    
Severity: minor CC: miniopl
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Neon   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Riccardo Robecchi 2022-10-17 11:25:30 UTC
SUMMARY
On Linux, when you use the ctrl key to navigate through text, the standard behaviour is that the ctrl key takes you to the end of the word. Currently Ghostwriter does not respect this standard as it adopts the one used by Windows, which is to take you to the beginning of the following word. This feels therefore unnatural to Linux users. It would be great if Ghostwriter could follow the Linux standard behaviour.

STEPS TO REPRODUCE
1. Use the ctrl key to navigate through text

OBSERVED RESULT
The cursor is placed at the beginning of the following word.

EXPECTED RESULT
The cursor is placed at the end of the current word.

SOFTWARE/OS VERSIONS
Linux: KDE neon
KDE Plasma Version: 5.26.0
KDE Frameworks Version: 5.98.0
Qt Version: 5.15.6
Ghostwriter version: 2.2.0

ADDITIONAL INFORMATION
Comment 1 Mirek Długosz 2022-11-06 15:36:33 UTC
I'm curious about "Linux standard behavior". I tried Ghostwriter, Kwrite and LibreOffice Writer - in all cases, pressing Ctrl + left or right arrow will move the cursor to beginning of previous / next word. In Firefox, Ctrl + left moves to beginning of previous word, Ctrl + right moves to end of next word.

Can you share some examples of apps that behave as you expect?


For the record, I'm an user, just like you.
Comment 2 Riccardo Robecchi 2022-11-07 09:25:49 UTC
I realise that my explanation was... lacking. Here is how I expect things to work:
- ctrl+→ moves to the end of the word (the current one if the cursor is in the middle of it, the next one otherwise);
- ctrl+← moves to the beginning of the word (again, the current one if the cursor is in the middle of it, the previous one otherwise).
Using ctrl keys on Linux you can basically jump between the beginning and the end of the current word.
In Ghostwriter the behaviour of ctrl+← is as expected, whereas ctrl+→ behaves like on Windows (i.e. the cursor is placed at the beginning of the next word, instead of at the end of the current one). 
You made me realise that most KDE applications actually have the same behaviour as Ghostwriter. Non-KDE applications behave as I expect them to, though (Firefox, Thunderbird, all GNOME apps, VSCodium, Slack, Skype, Teams...).
I wonder if this is related to Qt or if it was chosen at some point by KDE developers.

As for LibreOffice, IIRC there was a heated debate on their bug tracker about this, and they said that they wanted to provide consistency across platforms at the expense of not offering a native feeling on Linux. Their standard platform is Windows, so they base their user experience on UX conventions found there, including this one.
Comment 3 megan.conkle 2022-12-12 18:10:52 UTC
(In reply to Riccardo Robecchi from comment #2)
> I realise that my explanation was... lacking. Here is how I expect things to
> work:
> - ctrl+→ moves to the end of the word (the current one if the cursor is in
> the middle of it, the next one otherwise);
> - ctrl+← moves to the beginning of the word (again, the current one if the
> cursor is in the middle of it, the previous one otherwise).
> Using ctrl keys on Linux you can basically jump between the beginning and
> the end of the current word.
> In Ghostwriter the behaviour of ctrl+← is as expected, whereas ctrl+→
> behaves like on Windows (i.e. the cursor is placed at the beginning of the
> next word, instead of at the end of the current one). 
> You made me realise that most KDE applications actually have the same
> behaviour as Ghostwriter. Non-KDE applications behave as I expect them to,
> though (Firefox, Thunderbird, all GNOME apps, VSCodium, Slack, Skype,
> Teams...).
> I wonder if this is related to Qt or if it was chosen at some point by KDE
> developers.
> 
> As for LibreOffice, IIRC there was a heated debate on their bug tracker
> about this, and they said that they wanted to provide consistency across
> platforms at the expense of not offering a native feeling on Linux. Their
> standard platform is Windows, so they base their user experience on UX
> conventions found there, including this one.

This is a Qt issue.  All Qt applications using QPlainTextEdit will behave in the same manner.  The Qt bug tracker is located at bugs.qt.io, if you wish to report it there.  Thanks!