1. 27 Nov, 2020 1 commit
  2. 26 Nov, 2020 4 commits
  3. 25 Nov, 2020 6 commits
  4. 20 Nov, 2020 3 commits
    • Nate Graham's avatar
      Merge branch 'release/20.12' · 49a7caf6
      Nate Graham authored
    • David Hurka's avatar
      Fix QScroller crash on Qt < 5.14 and certain screen arrangements · c6a32751
      David Hurka authored
      QScrollerPrivate::setDpiFromWidget() before Qt 5.14 crashes
      when the target widget does not intersect a physical screen,
      because QDesktopWidget returns screen index `-1` in this case,
      which leads to an out-of-range read from QApplication::screens(),
      which leads to a segfault when reading from an invalid QScreen* pointer.
      This adds a workaround that checks for the `-1` situation,
      and then tries to resize PageView temporarily to intersect at least some screen.
      BUG: 425188
      FIXED-IN: 20.12
    • Alex Rosca's avatar
      Avoid unintentional accelerating flicks by reducing maximum flick time · 8ae95b29
      Alex Rosca authored and David Hurka's avatar David Hurka committed
      When making a flick using the mouse or the touchscreen and then slowly
      dragging the pages in the same direction with the flick, it unintentionally
      reenters the flicking state after a mouse button release and it's quite
      annoying. The commit reduces the maximum time before the next flick.
      Steps to reproduce:
      1) Flick in direction A.
      2) While the view is coasting, decide that you want to stop close to the current position.
      3) Grab the view (still coasting), and drag it slowly in direction A.
      4) When you reached the desired point, stop your movement, and release the view.
      5) QScroller interprets this release as “accelerating flick”,
         and makes the view coast faster in direction A.
      Upstream bug is QTBUG-88249; QScroller ignores MinimumVelocity for accelerating flicks.
  5. 18 Nov, 2020 3 commits
  6. 14 Nov, 2020 1 commit
    • Alexander Lohnau's avatar
      Remove dead code · 3c1fa441
      Alexander Lohnau authored
      A lot of this code has been commented out for over
      a decade and adds no value to the project.
      It is only annoying when you look over it ;).
      Same for the KNS2 support which was commented out.
      Also some of the debug statements didn't even build
      anymore, because the properties got removed/refactored.
  7. 11 Nov, 2020 2 commits
  8. 09 Nov, 2020 1 commit
    • Albert Astals Cid's avatar
      Remove kdocumentviewer · f9841b0f
      Albert Astals Cid authored
      It was causing problems (Windows build fails) now that we enabled  -Wweak-vtables (and
      probably before didn't work that much before, guessing that's why we had that if (doc)
      in openFile)
      This is the simplest solution, invokeMethod is not great but we already
      use it, so it's not too terrible
      The openDocument function was unused so remove it.
      The other two solutions are:
       * Make KDocumentViewer be part of okularcore and then link the
         okularcore to the okular binary, not nice
       * Make another dynamic library that just contains the KDocumentViewer
         class, but i'd rather not add yet another library we have to install
         and take care of
  9. 08 Nov, 2020 4 commits
  10. 03 Nov, 2020 1 commit
  11. 01 Nov, 2020 2 commits
    • Nicolás Alvarez's avatar
      gitlab-ci: use eatmydata in apt-get · d23422d0
      Nicolás Alvarez authored and Nicolás Alvarez's avatar Nicolás Alvarez committed
      apt-get uses several fsync() calls on each package it installs, and that's
      very slow, especially on non-SSD. eatmydata turns fsync into no-op, which
      makes package installation much faster (it can cause corruption if there's
      power loss or similar, but that doesn't matter in CI where we throw away
      the whole container anyway).
      Currently the build_ubuntu_20_04 job in GitLab CI takes 8-9 minutes to
      install dependencies. Using eatmydata it went down to 2 minutes.
    • David Hurka's avatar
      Do not disable flick if cursor has been wrapped · 08c4d4f7
      David Hurka authored
      BUG: 420556
      FIXED-IN: 1.11.3
  12. 31 Oct, 2020 2 commits
  13. 29 Oct, 2020 1 commit
  14. 28 Oct, 2020 4 commits
  15. 27 Oct, 2020 2 commits
    • Albert Astals Cid's avatar
      Set focus to the next current tab when closing the current tab · 91dbaa1f
      Albert Astals Cid authored
      And by that it means giving the focus to the pageview which is most of
      the fimes what we want. One could argue that if i had the focus on the
      searchbar we should restore the focus there, but that makes not much
      sense to me, since each tab is it's own world, at most one could say,
      let's remember where the focus was in that tab the last time it was
      focused and restore it there, but it seems a bit convoluted.
      To be able of setting the focus to the pageview from the shell we need
      to set up some focus proxies, so that part->widget (which is the sidebar)
      ends up giving the focus to the pageview, which is what makes sense if
      someone says "you part, set yourself the focus"
      BUGS: 428257
    • Albert Astals Cid's avatar
  16. 26 Oct, 2020 1 commit
  17. 25 Oct, 2020 1 commit
  18. 24 Oct, 2020 1 commit