[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: PageUp - PageDown behav in kword (was: kword gui...)
From:       John Califf <jcaliff () usit ! net>
Date:       2000-09-19 7:29:00
[Download RAW message or body]

Thomas wrote:
> 
> Auch. I should have known that...
> 
> Ok; conclusion:
>     PgDn: one viewport down
>     Ctrl-PgDn: next logical page.
>     Shift-PgDn: one viewport down and select.
>     Ctrl-Shift-PgDn: one page down and select.
> 
> Now as I said earlier we have the problem with scrolling below text-end.
> When you type PgDn when there is no more text, nothing happens. (because there
> is now way of putting the cursor there)
> Pressing PgDn I think this is the preferred behavior, pressing Ctrl-PgDn (with or
> without shift) does have to scroll to the next page. Even if this means not showing
> the cursor anymore.
> 
> >
> > PgDn: one viewport down
> > Ctrl-PgDn: next logical page.
> >
> > See also:
> > http://developer.kde.org/documentation/standards/kde/style/keys/cursorKeys.html
> 


Yes, I am in complete agreement with the above.  

I'm sorry for not responding earlier, but I have been off-line and then
making the changes I'd already made in a fresher cvs version on my box
instead of using snapshots and then doing a cvs diff as you suggested,
not realizing you had already committed my changes.  Your changes didn't
show up - I guess because the diff was against the date at which I
checked out koffice much earlier in the day. So I guess one should do a
cvs update first before doing the diff? Anyway, a learning experience
for me.

I think page scrolling by page numbers or paper size (so long as you
don't have to also automatically move the cursor into a frame) is much
easier than I thought.  It's just a two liner and doesn't even need
another method for kword_page.cc - can be placed right in the switch. 
Moving the cursor into the correct frame when scrolling by pages and/or
selecting the contents is doable but more complicated - find the
frameset and frame at the upper left corner based on the pixel offset
into the document and then move the cursor after scrolling a full page,
etc. There's some code used by mouse clicks on a location which gives me
a place to start - same principle.

Also, as long as page up and down is scrolling within frames, it should
follow the flow even when not holding down shift to also select text. 
This will mean on a two column page it will go to the bottom of the
first column and then switch to the top of the second and down the
second, then switch to the first column on the next page, et. But, for
example, on a page template with one large frame and a smaller nested
frame, it will not go into the nested one but keep moving up or down
within the main outer frame in the set (unless you explicitly click into
the inner frame). 

Right now it doesn't always follow flow, and tends to keep moving up or
down the view quickly. The flow conformancy can be added later (same
code used for selecting, but without marking and actually selecting.) 
This is not quite as fast for navigating but going with the flow is the
correct way, I feel. 

I will try to get all this done by the end of the week using cvs diffs
which look a lot better than my home made ones did. I notice that none
of the stuff on cvs has tabs. So I replaced my tabs with spaces also. 
Why no tabs? Probably tabs cause problems with the diff generation. 
Just curious.

You have no idea how thankful I am for your risktaking in committing
these changes. It will at least give people a chance to experiment with
scrolling and come up with more refinements.

John

[prev in list] [next in list] [prev in thread] [next in thread]