Ticket #10396 (closed enhancement: fixed)

Opened 4 years ago

Last modified 3 years ago

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

Reported by: godiard Owned by: godiard
Priority: normal Milestone: 10.1.3
Component: read-activity Version: Development build as of this date
Keywords: Cc: erikos, mtd
Action Needed: no action Verified: no
Deployments affected: Blocked By:
Blocking: #8602

Description

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.

Attachments

0001-grab-focus-in-the-view-when-the-laptop-is-post-in-eb.patch (1.6 kB) - added by godiard 4 years ago.
assign_scrolling_keys_10396.patch (0.9 kB) - added by erikos 3 years ago.
Map the dpad up/down keys, the O and X "power buttons" and the arrow up down keys for scrolling

Change History

  Changed 4 years ago by godiard

  • keywords erikos added

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.

  Changed 4 years ago by 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.

follow-up: ↓ 20   Changed 4 years ago by 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?

  Changed 4 years ago by 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.

  Changed 4 years ago by erikos

  • cc erikos added
  • keywords erikos removed
  • version changed from not specified to Development build as of this date
  • milestone changed from Not Triaged to 10.1.3

follow-up: ↓ 8   Changed 4 years ago by erikos

  • owner changed from morgs to godiard

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?

follow-up: ↓ 9   Changed 4 years ago by 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?

in reply to: ↑ 6 ; follow-up: ↓ 10   Changed 4 years ago by 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.

in reply to: ↑ 7 ; follow-up: ↓ 11   Changed 4 years ago by 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".

in reply to: ↑ 8 ; follow-up: ↓ 15   Changed 4 years ago by 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!

in reply to: ↑ 9 ; follow-up: ↓ 12   Changed 4 years ago by 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.

in reply to: ↑ 11 ; follow-up: ↓ 13   Changed 4 years ago by 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?

in reply to: ↑ 12   Changed 4 years ago by 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.

in reply to: ↑ 10 ; follow-up: ↓ 18   Changed 4 years ago by 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.

  Changed 4 years ago by 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.

follow-up: ↓ 21   Changed 4 years ago by 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)

in reply to: ↑ 15   Changed 4 years ago by 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.

  Changed 4 years ago by mtd

  • blocking 8602 added

in reply to: ↑ 3   Changed 4 years ago by mtd

  • cc mtd added

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.

in reply to: ↑ 17   Changed 4 years ago by 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).

Changed 3 years ago by erikos

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

  Changed 3 years ago by godiard

  • next_action changed from review to add to build

Tested and reviewed by gonzalo@…

  Changed 3 years ago by erikos

  • next_action changed from add to build to test in build

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.

  Changed 3 years ago by greenfeld

  • next_action changed from test in build to no action

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.

  Changed 3 years ago by greenfeld

  • status changed from new to closed
  • resolution set to fixed
Note: See TracTickets for help on using tickets.