[PATCH] RFC: ReadActivity fullscreen, paging changes

[Klaus Weidner]

On Sun, Jan 27, 2008 at 09:02:17AM +0000, david at lang.hm wrote:
> On Sun, 27 Jan 2008, Klaus Weidner wrote:
> >For the scroll/paging changes, my main motivation was that I think it's
> >important to be able to scroll page by page, especially if using "zoom to fit"
> >mode, instead of having to manually (and slowly) align the top of the
> >page with the top of the screen with the arrow keys.
> 
> instead you are forcing people who are not useing 'zoom to fit' to scroll 
> manually and slowly to read everything
> 
> as I stated in the other thread I think this is a bad idea.

I had missed the earlier thread, I'll go look for it.

I think you misunderstood what I changed - the arrow/rocker buttons
continue to work exactly like they used to. I only added the
PageUp/PageDown mappings to the 'X' and 'O' game keys and to Fn-Up/Fn-Down,
these keys previously did nothing at all. So I don't see how this could
be worse for anyone.

> one thing I have seen programs do (which I found slightly annoying, but 
> tolorable) is to page a screen at a time but go to the top of the page 
> when crossing a page boundry

I'd prefer the behavior you describe, but this should be a user choice
since obviously preferences are different.

> besides, when using 'zoom to fit' moving a page at a time should be 
> exactly the same thing as moving a screen at a time.

I agree - but currently you don't always get that in "continuous pages"
mode since the gap between the pages starts drifting across the screen.

> if you zoom to fit width and then page down through a document you should 
> see everything in that document, not just the tops of the pages.

I agree that the current behavior is subobtimal.

I think there should be dedicated keys for moving backwards/forward in
natural reading order - these would jump in screen-sized chunks, and
ideally for a 2-column document it would jump to the next column instead
of the next page at the bottom of the page. This could replace the
start/end of document keys which I think aren't useful enough (and
actually somewhat annoying if hit accidentally) to justify being mapped
to the face buttons.

My suggested layout would be:

- arrow keys move in small steps (unchanged)

- Page up/down (X/O) move by pages (added by my patch, previously did nothing)

- Square/Check move by screens in reading order (not changed yet,
  currently do start/end of document)

> >- add "continuous pages" and "single pages" to the "zoom to width" menu
> > (this should probably be a toggle instead).
> 
> please explain more about how things would operate in these two different 
> modes?

The "continuous pages" mode is what had previously been the only mode.
You can see the bottom of one page and the top of the next page on the
screen simultaneously. In "single pages" mode, you never see more than
one page at a time. 

This is a matter of taste and the more useful one also depends on the
document, which is why I think it should be switchable.

> >Also, I'm not sure if this should be done on a per-application basis, or
> >if a lower level should always rotate the rocker switch to match the
> >screen rotation automatically. That may mess up apps that expect the
> >current behavior though - are there any? Should the game buttons stay
> >static even when rotating?
> 
> I believe that there needs to be a better way for an application to define 
> how these keys work for it (ideally including the rotate key)

How about the following:

- by default, the rotate key rotates both the screen and the rocker
  switch, so that pressing the rocker towards the (logical) top of the
  screen always generates an "Up" arrow keystroke. The game keys don't
  rotate.

- applications can choose to get notified of rotation events and the new
  orientation in case they want to add actions to the default ones, such
  as optimizing the screen layout for the new orientation.

- applications can disable auto-rotation, making the rotate button
  available for the application as a normal input. The rocker switch
  doesn't get auto-modified and stays under app control.

I think it would be important to have something sane happen by default,
and that would let non-rotation-aware apps have basic functionality.

-Klaus