Read must focus in the view if XO is post in ebook position

[godiard]

When you rotate the screen and put the XO in the ebook position, only can navigate with the dpad. If any widget in the toolbar is focused, you can't navigate.

[godiard]

The patch is a proof of concept :) Is generated over sucrose-0.84 branch.

I don't understand why the message in the dbus signal don't provide the state information and I need to read the file. I can't find de source rpm of olpc-powerd-dbus.

[pgf]

powerd source is here: http://dev.laptop.org/git/users/pgf/powerd/tree

olpc-powerd-dbus doesn't currently send any dbus events -- it receives just one dbus message for backwards compatibility with ohmd.

ebook mode changes are available by reading the ebook input device. perhaps they can be made available from dbus.

[godiard]

who is sending the dbus events? i can read them when the lid switch or the ebook switch are activated. But are only the notification.

I am reading the state from '/proc/acpi/olpc-switch/ebook/EBK/state'

It's the wright procedure?

[pgf]

oh, i see. i thought you were wondering why you weren't getting those events. if you're getting them, then i guess they must be coming from hal -- i didn't realize that was happening.

[erikos]

OT: We should probably change the owners of the trac components to reflect the current situation. Who has admin-trac access or can grant me privileges so I can change the sugar components owners?

[erikos]

When you start Read (in all cases, not just in ebook mode), the toolbar has the focus. So you can not start scrolling directly. I think the view should always have the focus. You can do that by listening to the 'focus-in' event and do the grab_focus() on the view then (there is already some code that listens on this event for other reasons).

What do others think, it is right to assume that if you start read focus should be on the scrolling availability?

[Quozl]

Replying to erikos:

OT: We should probably change the owners of the trac components to reflect the current situation. Who has admin-trac access or can grant me privileges so I can change the sugar components owners?

Just ask me. This ticket however is marked read-activity, so not sure what you mean about the sugar component.

[Quozl]

Replying to erikos:

What do others think, it is right to assume that if you start read focus should be on the scrolling availability?

I don't think focus should have anything to do with it. Focus is a complex concept for the target audience. I think scrolling activation with the dpad should work independently of GTK+ focus. I'd prefer the ticket summary to be "read must scroll in response to dpad keys regardless of focus or ebook position".

[erikos]

Replying to Quozl:

Replying to erikos:

OT: We should probably change the owners of the trac components to reflect the current situation. Who has admin-trac access or can grant me privileges so I can change the sugar components owners?

Just ask me. This ticket however is marked read-activity, so not sure what you mean about the sugar component.

Components, the 's' is important :) The default maintainer for sugar, sugar-artwork, sugar-base, sugar-toolkit, sugar-datastore and presence-service should be me.

read-activity I think Gonzalo should own, Sayamindu is only around as a volunteer those days and Morgan (who is the current listed maintainer) is gone for years.

About the other activities, where there is no clear upstream maintainer I guess Gonzalo should being assigned. But let's ask him first if he agrees.

Thanks in advance!

[erikos]

Replying to Quozl:

Replying to erikos:

What do others think, it is right to assume that if you start read focus should be on the scrolling availability?

I don't think focus should have anything to do with it. Focus is a complex concept for the target audience. I think scrolling activation with the dpad should work independently of GTK+ focus. I'd prefer the ticket summary to be "read must scroll in response to dpad keys regardless of focus or ebook position".

Well, there are not only the dpad keys. In general you like to have the arrow keys allowing you to scroll. And the dpad keys are XO specific. So I think using focus is not a bad idea here.

[Quozl]

Replying to erikos:

So I think using focus is not a bad idea here.

I still think it is a bad idea. Focus lets you use certain keys for multiple purposes; e.g. the "a" key can be used for typing into the activity name field, or into the body of a document in Write. What other uses are there for the arrow keys in Read? Left and right arrow keys may be useful for editing the document name, or moving focus through the tabs, but up and down arrow are better used for up and down scrolling of the document. Anyway, surely this is a design issue for Sugar and it should be escalated there?

[erikos]

Replying to Quozl:

Replying to erikos:

So I think using focus is not a bad idea here.

I still think it is a bad idea. Focus lets you use certain keys for multiple purposes; e.g. the "a" key can be used for typing into the activity name field, or into the body of a document in Write. What other uses are there for the arrow keys in Read? Left and right arrow keys may be useful for editing the document name, or moving focus through the tabs, but up and down arrow are better used for up and down scrolling of the document. Anyway, surely this is a design issue for Sugar and it should be escalated there?

Hmm, but when you use the arrow keys in the text for navigation you click in the text first. As another example, when you open a new tab in Firefox the scrollbar will work directly as well by using the arrow keys.

But yes, I will take it to sugar-devel for feedback.

[erikos]

http://lists.sugarlabs.org/archive/sugar-devel/2010-October/027757.html

[Quozl]

Replying to erikos:

The default maintainer for sugar, sugar-artwork, sugar-base, sugar-toolkit, sugar-datastore and presence-service should be me.

Changed.

read-activity I think Gonzalo should own, [...]

Changed.

[martin.langhoff]

To keep in mind: if we mess with focus, we may be screwing up accessibility based on keyboard navigation. In that light, I prefer the approach described in this bug report rather than locking the dpad to one function.

[pgf]

this ticket was starting to confuse me, so i just looked at and tried Read to see how it works.

Read already has some key actions that it performs regardless of focus -- it will zoom in or out if you use the "check" or "square" gamepad keys. the latter actions (presumably -- i'm no python expert) happen because the KP_Home and KP_End keynames are handled in ReadActivity._key_press_event_cb(), and cause zoom_in/_out() routines to be called.

it seems to me that the d-pad keys could be similarly bound in a focus independent way by having the same routine look for KP_Up, KP_Down, KP_Left, and KP_Right. this will catch just the d-pad keys, and not the "regular" arrow keys, and of course they should somehow be bound to scrolling operations.

my assumption is that there is no reason that the d-pad keys should ever be used for field or tab selection -- i.e., the regular arrow keys would probably be used for that. so it's okay for the d-pad keys to always scroll, no matter what the focus, and, more importantly for this ticket, no matter whether the laptop is in ebook mode or not.

(disclaimer: i'm looking at the code for Read-86)

[erikos]

Replying to Quozl:

Replying to erikos:

The default maintainer for sugar, sugar-artwork, sugar-base, sugar-toolkit, sugar-datastore and presence-service should be me.

Changed.

Works as expected, thanks.

[mtd]

Replying to godiard:

I am reading the state from '/proc/acpi/olpc-switch/ebook/EBK/state' It's the wright procedure?

Last time I tried was a while ago but just reading the dbus object's button.state.value worked fine. See the ebookswitch.py file in http://dev.laptop.org/attachment/ticket/2954/0001-Hide-cursor-and-toolbox-in-handheld-mode.-Fixes.patch

But I think pgf's solution (always act on d-pad keys) from #comment:17 is better.

[erikos]

Replying to pgf:

this ticket was starting to confuse me, so i just looked at and tried Read to see how it works. Read already has some key actions that it performs regardless of focus -- it will zoom in or out if you use the "check" or "square" gamepad keys. the latter actions (presumably -- i'm no python expert) happen because the KP_Home and KP_End keynames are handled in ReadActivity._key_press_event_cb(), and cause zoom_in/_out() routines to be called. it seems to me that the d-pad keys could be similarly bound in a focus independent way by having the same routine look for KP_Up, KP_Down, KP_Left, and KP_Right. this will catch just the d-pad keys, and not the "regular" arrow keys, and of course they should somehow be bound to scrolling operations.

Actually, there is a difference for the ebub code and the pdf one. The epub code (is a bit hidden unless you look on the XO) does listen for the KP_* events, so for epubs scrolling work.

   def _view_keypress_event_cb(self, view, event):
        name = gtk.gdk.keyval_name(event.keyval)
        if name == 'KP_Page_Down':
            self.scroll(gtk.SCROLL_PAGE_FORWARD, False)
            return True
        elif name == 'KP_Page_Up':
            self.scroll(gtk.SCROLL_PAGE_BACKWARD, False)
            return True
        elif name == 'KP_Down':
            self.scroll(gtk.SCROLL_STEP_FORWARD, False)
            return True
        elif name == 'KP_Up':
             self.scroll(gtk.SCROLL_STEP_BACKWARD, False)
             return True
        elif name == 'Page_Down' or name == 'Down': 
            self.__going_back = False
            self.__going_fwd = True
            self._do_page_transition()
        elif name == 'Page_Up' or name == 'Up':
            self.__going_back = True
            self.__going_fwd = False
            self._do_page_transition()

I will have a look how we can make that work best for pdfs as well.

Btw, for epubs the scrolling in rotation mode is inverse despite that code (for olpc-kbdshim 14 and 15).

[erikos]

Map the dpad up/down keys, the O and X "power buttons" and the arrow up down keys for scrolling

[godiard]

Tested and reviewed by gonzalo@…

[erikos]

Version 87.1 will be in 353.

"Map the dpad up/down keys and the arrow up down keys for scrolling. Using fn+arrow keys (Page up/down) will move forward/backward by bigger chunks. This is the same behavior as in the epub back end."

Please verify that scrolling in pdfs works as described in the commit message.

[greenfeld]

The dpad up/down buttons now always move the screen, regardless of if we are in ebook position or not. The arrow keys move a little bit while page/up down move a lot.

Tested on an XO-1 with os356 and a XO-1.5 with os355.