1. 15 Aug, 2013 1 commit
  2. 14 Aug, 2013 2 commits
    • Sebastian Ramacher's avatar
      Document that workaround · 033833c5
      Sebastian Ramacher authored
      And a remainder that we want to drop this once we don't support GTK+2 anymore.
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      033833c5
    • Marawan Tanager's avatar
      Don't hide the inputbar in case of incremental search · c5e593d3
      Marawan Tanager authored
      Hiding the inputbar immediately before jumping breaks incremental search, as
      Guillaume Duranceau stated in an earlier mail.
      
      This patch makes an exception for the case of incremental search, at the cost
      of a slight displacement when jumping back (^o) after ending the incremental
      search (pressing the ESC key). The rest of the jump cases are unaffected.
      
      This should makes things usable for now, until we move to GTK3 (link to it by
      default) which has a new widget that suits this problem nicely (GtkOverlay), as
      demonstrated by an earlier patch by Abdo Roig-Maranges which is now included on
      the develop branch in girara repo as commit
      70fd1cf354ee1300d4a9bdab9e939d5cc975979e, but is compiled only with GTK3.
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      c5e593d3
  3. 27 Jul, 2013 4 commits
  4. 26 Jul, 2013 3 commits
  5. 25 Jul, 2013 1 commit
  6. 07 Jul, 2013 5 commits
  7. 30 Jun, 2013 2 commits
  8. 29 Jun, 2013 4 commits
    • Sebastian Ramacher's avatar
    • Marwan Tanager's avatar
      Make the jumplist persistent on a per-file basis · 99b32ae1
      Marwan Tanager authored
      This patch implements two new ZathuraDatabaseInterface functions, save_jumplist
      and load_jumplist, for both the plain and sqlite backends (along with some
      cleanups).
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      99b32ae1
    • Marwan Tanager's avatar
      Hide the inputbar and completion menu before saving the adjustments ratios... · 87a7f231
      Marwan Tanager authored
      Hide the inputbar and completion menu before saving the adjustments ratios into a new jump structure
      
      Since we are now saving the adjustments ratios in the jump structures, we need
      to take care of the following scenario:
      
          - We do an action that results in a new jump structure being added to the
            jumplist while the inputbar is visible (e.g., search, jumping to a
            specific page, jumping to a bookmark, or following a link).
      
          - Since we are now storing the adjustments ratios in the jump structures,
            all of the above actions would result in the vertical adjustment ratio
            being saved while the inputbar and/or the completion menu is visible.
      
          - Now we are exactly on the target of the jump (note that the inputbar and
            completion menu now are hidden), so suppose that we want to go back using
            ^o (assuming that we didn't change the adjustments after jumping), then
            the check at sc_jumplist that compares the current adjustments ratios
            with that of the current jump (the jump that has just been added and
            which we are currently on it's position) would fail, because after the
            inputbar (with possibly the completion menu in case of bookmarks) is
            activated it is hidden, which results in the vertical adjustment upper
            bound to change, which in turn results in the vertical adjustment ratio
            returned by zathura_adjustment_get_ratio to become different from what is
            stored in the current jump structure, even though we haven't changed the
            adjustments at all after the jump.  This would always result in taking us
            back to the exact position of the jump (which would be slightly different
            from the current position) when we press ^o.  This can be annoying,
            because it would happen, for example, every time we need to go back
            quickly after jumping to a link target, a search result, or a bookmark.
      
      So, what this patch does is essentially to make the vertical adjustment ratio
      reflecting the current vertical adjustment after a jump, to always be the same
      as the one stored in the newly added jump structure, since both are calculated
      with zathura_adjustment_get_ratio while the inputbar is _not_ visible, so they
      should be the same.
      
      I've elaborated just to make things clear, in case the purpose of the patch
      isn't obvious.
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      87a7f231
    • Marwan Tanager's avatar
      Jumplist: record the adjustments ratios, rather than their values · 7465ad68
      Marwan Tanager authored
      This makes jumping works accurately, even if the document is scaled up or down.
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      7465ad68
  9. 21 Jun, 2013 7 commits
  10. 20 Jun, 2013 3 commits
  11. 19 Jun, 2013 1 commit
  12. 18 Jun, 2013 1 commit
  13. 10 Jun, 2013 5 commits
    • Marwan Tanager's avatar
      Use jumplist with marks · 092fe818
      Marwan Tanager authored
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      092fe818
    • Marwan Tanager's avatar
    • Marwan Tanager's avatar
      Enhancements/Cleanups for the jumplist mechansim · afd008f4
      Marwan Tanager authored
      	- Don't delete the elements on the right of the current one, when
      	  appending a new jump to the jumplist, because this makes no sense at
      	  all; the point of the jumplist in the first place is to remember
      	  previously jumped-to positions in the document, so there is no need
      	  to delete anythings except to trim the oldest entries from the
      	  beginning to maintain the maximum size. This also makes us compatible
      	  with the Vim way of doing things.
      
      	- Make the jumplist mechanism functional on the same page; if we
      	  followed a link to a target on the same page, remember the
      	  adjustments before and after following the link. The same holds for
      	  navigating search results on the same page.
      
      	- Implement position_set and use it instead of position_set_delayed
      	  when following links in order to give zathura_jumplist_save a chance
      	  to record the exact adjustments of the link target. Otherwise, it
      	  will always record the adjustments after going to the target page,
      	  but before going to the exact position within it.
      
      	- Don't consider movements with ^i and ^o as jumps :)
      
      	- Don't use page_set followed by setting the adjustments in
      	  sc_jumplist, because this is redundant and causes clutter when using
      	  ^i and ^o, as the adjustments is set twice this way (once in page_set
      	  and again in position_set_delayed).  It's enough to only update the
      	  page number on the statusbar and then set the adjustments.
      
      	- Hide implementation details (zathura_jumplist_save and
      	  zathura_jumplist_append), and make things more consistent by
      	  exporting and using only zathura_jumplist_add for adding new entries.
      
      The end result: A more slick jumping experience :-)
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      afd008f4
    • Marwan Tanager's avatar
    • Marwan Tanager's avatar
      More Vim-like search behavior · cc3b9aea
      Marwan Tanager authored
      This patch activates the last aborted search when pressing the search shortcuts
      ('n' or 'N').
      
      To avoid confusion, and to make things more predictable, I've chosen to always
      reactivate an aborted search starting from the beginning (or end, in case of
      'N' or '?') of the current page, as opposed to Vim which continues from the
      next search term each time the search is reactivated.
      
      Searching using '/' or '?' doesn't center the view at the current search term
      like when using 'n' or 'N', so we fix this here.
      
      Also, I managed to work around the issue of the thin rectangular margins that
      show around the previously-highlighted search terms after the search is aborted
      (either explicitly or as a result of following links), by redrawing the page
      widget (only if it's visible) instead of redrawing the rectangles covering the
      highlighted search terms.
      Signed-off-by: Sebastian Ramacher's avatarSebastian Ramacher <sebastian+dev@ramacher.at>
      cc3b9aea
  14. 02 Jun, 2013 1 commit