1. 12 Aug, 2019 1 commit
  2. 09 Aug, 2019 1 commit
  3. 08 Aug, 2019 1 commit
  4. 05 Aug, 2019 1 commit
  5. 04 Aug, 2019 1 commit
  6. 31 Jul, 2019 1 commit
  7. 29 Jul, 2019 1 commit
  8. 22 Jul, 2019 1 commit
  9. 21 Jul, 2019 1 commit
  10. 19 Jul, 2019 1 commit
  11. 18 Jul, 2019 1 commit
  12. 16 Jul, 2019 2 commits
  13. 15 Jul, 2019 2 commits
    • Albert Astals Cid's avatar
    • Christoph Cullmann's avatar
      Enlarge the find and replace add-on combo boxes · bf86ce05
      Christoph Cullmann authored
      Summary:
      When the find and replace toolview is in the left or right sidebars, move the combo boxes on their own rows so they have more space.
      This patch changes the position of the combo boxes when the toolview width is smaller than its height.
      The goal is to be able to see a large string in the find and/or replace combo boxes within a moderately narrow toolview.
      
      Test Plan:
      Original suggestion, widgets are not grouped:
      {F6930229}
      {F6930232}
      
      2nd suggestion, buttons are small:
      {F6931264}
      {F6931265}
      
      3rd suggestion:
      {F6933433}
      
      toolview height Vs combobox width:
      
      before, 22 result lines, the combobox needs to be expanded
      {F7021390}
      
      after, 20 result lines, the combobox is large
      {F7021407}
      
      Reviewers: #kate, sars, #vdg, ngraham
      
      Reviewed By: #kate, sars, #vdg, ngraham
      
      Subscribers: cullmann, ngraham, kwrite-devel
      
      Tags: #kate, #vdg
      
      Differential Revision: https://phabricator.kde.org/D22059
      bf86ce05
  14. 14 Jul, 2019 12 commits
  15. 13 Jul, 2019 7 commits
  16. 11 Jul, 2019 2 commits
  17. 10 Jul, 2019 4 commits
    • Christoph Cullmann's avatar
      [PATCH] Quick Open: fix LRU listing regression · 2fdd8c14
      Christoph Cullmann authored
      The quick open list used to be sorted by order of access (the old code
      called it LRU order). Commit d6e38c0c broke this.
      
      The first sort() call is changed to stable_sort() in order to preserve
      the "bold" field and the new "sort_id" field. A comment warns about this
      subtle and easy to break requirement. This change was needed to sort the
      file list by LRU (files not in the sortedViews list have no sort_id set,
      and thus are sorted below all LRU sorted entries).
      
      stable_sort() should be slower than sort(), although the C++ standard
      promises the same algorithmic complexity. On the other hand, this change
      also lets us get rid of the openedUrls string list and the associated
      linear search.
      
      The second sort must always be a stable_sort(). This is a bug in the
      previous code. It sorted only on the "bold" field, which means
      everything else can be reordered as sort() likes. Even if it "worked",
      it was buggy.
      
      To completely restore the old behavior, select the second entry by
      default in the quick open list. This is so that you can quickly switch
      between the two last recently accessed files. The old code actually
      selected the first entry if the sortedViews list contained less than 2
      elements - keep that behavior too.
      
      Author: Vincent Lang
      
      BUG: 407103
      2fdd8c14
    • Mark Nauwelaerts's avatar
      24bd4c50
    • Mark Nauwelaerts's avatar
    • Mark Nauwelaerts's avatar
      3f71d62e