The adjustment callbacks act as an interface between position data in
the document object, and the adjustments.
We remove the horizontal centering code, as now it is done by
position_set. Those callbacks should not change the position read from
the document object in any way.
Also, we split the adjustment_value_changed callback into a vertical and
an horizontal version. Previously a single callback was reused for both,
horizontal and vertical. That lead to a subtle problem when coming out
of index mode. What happened was the following:
1. horizontal adjustment bounds change coming out of index mode. This
triggers an hadjustment changed signal.
2. the hadjustment_changed callback handles it, and resets the
hadjustment value, as the bound may have changed. This triggers a
value_changed event.
3. the value_changed callback handles the event, and captures the
position for *BOTH*, horizontal and vertical adjustments, saving
them to the document object.
1..3 is repeated for the vertical adjustment.
Now, if in 3. the horizontal adjustment bounds were not yet updated
after the index mode, we got ourselves at the wrong vertical position.
This race condition is avoided now because both value_changed callbacks
*ONLY* handle their own direction, either vertical or horizontal, not
both.
Now we can trigger a gtk page refresh calling refresh_view. This
function triggers a custom signal refresh-view, whose handler copies the
position from the document object to the adjustments.
All of those callbacks are conceptually related (change the page
layout), and depend from one another.
Now the single callback page_layout_value_changed defers to
page_widget_set_mode to change whatever is needed in the GTK widgets.
The page widget shouldn't have to care what should be done with selected images
and text.
Signed-off-by: Sebastian Ramacher <sebastian+dev@ramacher.at>
Instead of guesstimating the values of the scrollbars adjustments after
a change in zoom level, connect callbacks to the "changed" GtkAdjustment
event (which is emitted when the bounds or page_size of the adjustment
change, e.g. when the zoom level changes), and compute the new values
from there.
The previous adjustment values are tracked in zathura->ui.hadjustment
and zathura->ui.vadjustment (and updated by signal handlers as well), so
that the view's position can be maintained while zooming.
cb_view_hadjustment_changed() centers the page horizontally if a
"best-fit" or "width" zoom is being performed, or if "zoom-center" is
true; otherwise, it keeps the view horizontally centered around the same
area of the page.
cb_view_vadjustment_changed() always keeps the view vertically centered
around the same area of the page.
Many thanks to Marwan Tanager for thoroughly reviewing the various
stages of this patch, and actually coming up with a working solution.
Signed-off-by: Sebastian Ramacher <sebastian+dev@ramacher.at>
This is useful when the text of the link doesn't match its target. The
default key is set to 'F'.
See issue 266 <http://bugs.pwmt.org/issue266>.
Reported-by: Iron <o380770@rtrtr.com>
Signed-off-by: Sebastian Ramacher <sebastian+dev@ramacher.at>
If option recolor-keephue is true, the recoloring algorithm
only adjusts the lightness of the original color, keeping the
rest of the properties close to the original.
When recolor-keephue is set to false, the recoloring is performed
as it was before, interpolating linearly between recolor-lightcolor
and recolor-darkcolor except for a different weighting for the
lightness which is closer to perception.
Signed-off-by: Sebastian Ramacher <sebastian+dev@ramacher.at>
