[PATCH] RFC: ReadActivity fullscreen, paging changes

[david at lang.hm]

On Sun, 27 Jan 2008, Klaus Weidner wrote:

> 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.

the subject was 'pdf reader not really user friendly' within the last 
day or so.

Chas pushed for the same change you are (page up/down moves to the top of 
the next page)

> 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.

at least for some document types (pdf for example)
O=page up
X=page down
[]=top
check=bottom

these mappings have worked for me since I received the g1g1 machines.

>> 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.

I would argue that this means the 'zoom to fit' isn't quite right. if it 
was it should match.

>> 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.

the problem is that in many cases the reader software doesn't know if the 
text is in columns or not, it's just rendering ink on the page (pdf for 
example)

> 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)

as noted above, this is not true for some document types, what document 
types are you useing where they didn't do anything before?

> - 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.

Ok, I can see the desire for this mode, but I'm not sure it's worth the 
complication (especially given the other simplifications done to sugar)

>>> 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.

I would agree with this proposal. if an application chooses to disable 
auto-rotation they should be able to re-map all 9 of the game keys. it 
would be nice to have this done in a way that would be able to be scripted 
(for use in the terminal window for example)

note that the rotation could still take place when other applications are 
active, so the application still needs to be able to respond to resize 
events (which should be standard for apps that live in a GUI environment 
anyway, even if they are text apps that run in an xterm)

while I understand the desire to avoid modal operation and also to not 
have the e-book mode operate by moving a pointer around, I think that the 
ability to switch to a mode where you can toggle between the existing 
functions of the gamepad keys and a mode where the arrows move the mouse 
pointer and X and O mimic the mouse buttons (with matching lables) would 
be extremely useful for applications that have not been converted yet.

in fact, how's this for an idea?

in e-book mode (screen rotated and flat against the keyboard) the rotate 
button doesn't rotate the screen, instead it toggles between existing 
behavior and pointer mode. you could change the shape of the exit icon 
when in pointer mode to indicate what mode you are in.

David Lang