Bug 199509

There seem to be shortcuts for PreviousPage and NextPage now.  And they even work -- except that they only scroll up -- they don't move the cursor.  So if I want to return to the previous page for editing, I have to push PageUp and then click to resume editing.  

It would be preferable if PageUp could actually move the text cursor up one page.  Then I wouldn't have to take my hands off the keyboard, which would improve typing efficiency.

Still, this is much better than what we had before.  Thanks!

*** Bug 240152 has been marked as a duplicate of this bug. ***

Hi.
I'm went this jr job for start the study of koffice code.
Anyone can give-me a help abou what file/class implement document edit. I'm browsing the code and finding only the document view structure implementation.

Hello cochise,

I think the best to get help from the developers is to send a mail to the mailing list koffice-devel@kde.org or to choin the #koffice channel on freenode IRC in case you have not gotten any help up to now.

Thorsten

If I remember right, Thomas, you had written something about why this isn't as straightforward as it sounds -- and how it would have to be implemented, but I can't find it anywhere...

The behavior pageup/down has in my dream is one essentially similar to what this old document describes;
http://developer.kde.org/documentation/standards/kde/style/keys/cursorKeys.html

The tricky part in using pageup/down is that a text-shape doesn't take the full page height. There are 'blank' spots where the text shape isn't present.
Imagine having a page with 3 columns and each column is occupying 80% of the visual space.  If I press 'pagedown' I expect the caret to effectively move to the next column but not down.
The tricky part is thus taking the fact that going down one viewport is going to far as the caret jumps over the area where there is no text-shape.

If this is still confusing then put the caret at the end of a page and move it down until the caret moves to another page. There is a big jump where one press 'down' moves the caret a lot of pixels. This should be compensated for in usage of pagedown/up so there is no similar jumping when using that.

Using ctrl-pagedown I expect the caret to jump to the first shape on the next page using the same vertical offset from the top of the page.
Or in our example; it should jump through all 3 columns at ones.

At the end of the day the solution doesn't have to be perfect, even while I can be dreaming of the perfect solution a good solution is absolutely better than no solution. :-)

I see.  This doesn't address that problem, but I'd always pictured the behavior slightly differently:

A.  For PageDown, if the cursor is not already on the last line of a page (or column), the cursor would jump to the last line.  

B.  If the cursor is on the last line, it jumps to the first line of the next page or to the top of the next column.

Page up would work analogously.

I think the behavior you describe makes a lot of sense, I'm all for it :)

Thank you for your bug report or feature suggestion.

The "KOffice" application suite is no longer maintained, and all tickets are now closed.

We recommend to switch to the "Calligra" application suite, which has replacements for all unmaintained KOffice applications:

- KWord was replaced with Calligra Words
- KPlato was replaced with Calligra Plan

For more information, see http://en.wikipedia.org/wiki/Calligra_Suite

(This is an automatic message from the KDE bug triaging team)