[PATCH v2] RFC: ReadActivity fullscreen, paging changes
Klaus Weidner
kweidner at pobox.com
Sun Jan 27 06:49:12 EST 2008
On Sun, Jan 27, 2008 at 03:08:34AM -0800, david at lang.hm wrote:
> 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.
The X/O keys had been behaving inconsistently for me - sorry, I was wrong
to say that they did nothing. It seems that while testing I had sometimes
forgotten to move focus to the viewport, so the keystrokes went to the
menu bar and were ignored. (I blame lack of sleep.) The two problems I
can reproduce now after reverting my evince patch are:
- in "zoom to fit" mode, the X/O keys don't move cleanly by pages, the
gap shifts around and you see parts of two pages.
- the "single page" mode (continuous off) is broken, you can't move off
the current page. But that mode was introduced by my read activity
change so the evince bug wasn't visible in the original build.
The attached updated evince patch fixes both with (as far as I can tell)
no regressions. The page up/down keys move by screenfuls as you expect,
just more consistently. I've also fixed paging backwards in "single page"
mode so that it shows the bottom of new pages first, that appears to be
broken in the normal desktop evince also.
I've also attached the Read activity patch again which adds the fullscreen
button and continuous/single mode switching - this hasn't changed since
the last time.
> >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)
You could do some heuristics such as looking for a blank gutter on the
page. Or do it based on the user's behavior - if the current viewport
covers less than 2/3 of the page width and is on the bottom left, the
page down key moves the viewport to the top right of the page. But that
may annoy people used to the old behavior, and wouldn't work well for
supporting languages with different writing directions. So I'm not sure
if it's worth pursuing.
> >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)
I think the addition is not that complicated (could be a single toggle
button, two-half-pages-with-gap as the icon). The single page mode can
make reading documents much less confusing, especially in the case of
multi-column documents where you would otherwise need to be careful when
moving back to the next column to make sure you're on the right page.
This way you can clearly see where the page ends, and either move back up
manually or hit "home" to go back to the top of the page.
Actually, I think non-continuous mode would even make sense as the
default since it's simpler and more book-like than the continuous one,
which acts more like a scroll. And it should use less memory since it
never needs to render more than a page at a time.
-Klaus
-------------- next part --------------
diff --git a/shell/ev-view.c b/shell/ev-view.c
index b464c3f..3bfe7da 100644
--- a/shell/ev-view.c
+++ b/shell/ev-view.c
@@ -360,7 +360,7 @@ scroll_to_current_page (EvView *view, GtkOrientation orientation)
view_point.y + view->vadjustment->page_size);
} else {
gtk_adjustment_set_value (view->vadjustment,
- CLAMP (view_point.y,
+ CLAMP (view->vadjustment->value,
view->vadjustment->lower,
view->vadjustment->upper -
view->vadjustment->page_size));
@@ -372,7 +372,7 @@ scroll_to_current_page (EvView *view, GtkOrientation orientation)
view_point.x + view->hadjustment->page_size);
} else {
gtk_adjustment_set_value (view->hadjustment,
- CLAMP (view_point.x,
+ CLAMP (view->hadjustment->value,
view->hadjustment->lower,
view->hadjustment->upper -
view->hadjustment->page_size));
@@ -3996,6 +3996,8 @@ ev_view_class_init (EvViewClass *class)
binding_set = gtk_binding_set_by_class (class);
+ add_scroll_binding_keypad (binding_set, GDK_Page_Up, 0, EV_SCROLL_PAGE_BACKWARD, FALSE);
+ add_scroll_binding_keypad (binding_set, GDK_Page_Down, 0, EV_SCROLL_PAGE_FORWARD, FALSE);
add_scroll_binding_keypad (binding_set, GDK_Left, 0, EV_SCROLL_STEP_BACKWARD, TRUE);
add_scroll_binding_keypad (binding_set, GDK_Right, 0, EV_SCROLL_STEP_FORWARD, TRUE);
add_scroll_binding_keypad (binding_set, GDK_Left, GDK_MOD1_MASK, EV_SCROLL_STEP_DOWN, TRUE);
-------------- next part --------------
diff --git a/readactivity.py b/readactivity.py
index 956e3b0..99b9244 100644
--- a/readactivity.py
+++ b/readactivity.py
@@ -95,7 +95,7 @@ class ReadActivity(activity.Activity):
toolbox.add_toolbar(_('Read'), self._read_toolbar)
self._read_toolbar.show()
- self._view_toolbar = ViewToolbar(self._view)
+ self._view_toolbar = ViewToolbar(self._view, self)
self._view_toolbar.connect('needs-update-size',
self.__view_toolbar_needs_update_size_cb)
toolbox.add_toolbar(_('View'), self._view_toolbar)
diff --git a/readtoolbar.py b/readtoolbar.py
index 332e4fa..be475b2 100644
--- a/readtoolbar.py
+++ b/readtoolbar.py
@@ -258,9 +258,10 @@ class ViewToolbar(gtk.Toolbar):
([]))
}
- def __init__(self, evince_view):
+ def __init__(self, evince_view, activity):
gtk.Toolbar.__init__(self)
+ self._activity = activity
self._evince_view = evince_view
self._document = None
@@ -293,6 +294,16 @@ class ViewToolbar(gtk.Toolbar):
palette.menu.append(menu_item)
menu_item.show()
+ menu_item = MenuItem(_('Single pages'))
+ menu_item.connect('activate', self._continuous_false_menu_item_activate_cb)
+ palette.menu.append(menu_item)
+ menu_item.show()
+
+ menu_item = MenuItem(_('Continuous pages'))
+ menu_item.connect('activate', self._continuous_true_menu_item_activate_cb)
+ palette.menu.append(menu_item)
+ menu_item.show()
+
tool_item = gtk.ToolItem()
self.insert(tool_item, -1)
tool_item.show()
@@ -313,6 +324,14 @@ class ViewToolbar(gtk.Toolbar):
self.insert(tool_item_zoom_perc_label, -1)
tool_item_zoom_perc_label.show()
+ self._view_fullscreen = ToolButton('view-fullscreen')
+ self._view_fullscreen.set_tooltip(_('Fullscreen mode'))
+ self._view_fullscreen.connect('clicked', self._view_fullscreen_cb)
+ self.insert(self._view_fullscreen, -1)
+ self._view_fullscreen.show()
+
+ self._zoom_to_width.show()
+
self._view_notify_zoom_handler = self._evince_view.connect(
'notify::zoom', self._view_notify_zoom_cb)
@@ -364,3 +383,12 @@ class ViewToolbar(gtk.Toolbar):
self._evince_view.props.zoom = 1.0
self._update_zoom_buttons()
+ def _continuous_false_menu_item_activate_cb(self, menu_item):
+ self._evince_view.set_continuous(False)
+
+ def _continuous_true_menu_item_activate_cb(self, menu_item):
+ self._evince_view.set_continuous(True)
+
+ def _view_fullscreen_cb(self, button):
+ self._activity.fullscreen()
+
More information about the Devel
mailing list