1. 27 Jan, 2020 1 commit
    • George Vogiatzis's avatar
      Change drop indicator color · 178eb592
      George Vogiatzis authored and Nate Graham's avatar Nate Graham committed
      Summary:
      Change drop indicator color form highlight to text.
      This makes more visible, when indicator is adjacent to a highlight
      item, of a list.
      
      BUG: 415010
      
      Test Plan:
      Before vs After
      {F7974679}
      
      Reviewers: #dolphin, #vdg, elvisangelaccio, ngraham
      
      Reviewed By: #dolphin, #vdg, ngraham
      
      Subscribers: meven, kfm-devel
      
      Tags: #dolphin
      
      Differential Revision: https://phabricator.kde.org/D26936
      178eb592
  2. 21 Dec, 2019 1 commit
    • Nate Graham's avatar
      Improve scroll wheel speed by basing it on label height, not icon height · 403de19d
      Nate Graham authored
      Summary:
      Dolphin currently scrolls by the height of three items at a time per "step" when
      using a scroll wheel. Because item height is highly variable, this leads to scroll
      speed being inconsistent between views, and generally far too fast when using
      icon view with icons larger than 22px size.
      
      This patch makes the size of the scroll step based on the text label rather than the
      icon size just like D25683, ensuring that the scroll speed does not vary and become
      super fast when using large icons in particular.
      
      It also reverts 90beb4a5, which is no longer needed.
      
      BUG: 386379
      FIXED-IN: 19.12.1
      
      Test Plan:
      Use a mouse with a scroll wheel and scroll in Dolphin item views with list view,
      details view, icon view, etc, using different item sizes. Speed should be
      consistent in all views now, and also feel consistent with other KDE apps.
      
      Also try with multiple scale factors to make sure the behavior does not change.
      
      No change with high-resolution two-finger touchpad scrolling.
      
      Reviewers: #dolphin, elvisangelaccio
      
      Reviewed By: #dolphin, elvisangelaccio
      
      Subscribers: ahiemstra, lots0logs, anthonyfieroni, kfm-devel
      
      Tags: #dolphin
      
      Differential Revision: https://phabricator.kde.org/D19190
      403de19d
  3. 09 Nov, 2019 1 commit
  4. 10 Mar, 2019 1 commit
  5. 03 Dec, 2018 1 commit
    • Anton Kreuzkamp's avatar
      KItemListWidget: Use initStyleOption · 037d2c99
      Anton Kreuzkamp authored
      Instead of using QStyleOption::initFrom, let's use
      QGraphicsWidget::initStyleOption, which is made for exactly the purpose
      of KItemListWidget. This is especially important since, according to the
      docs of QGraphicsItem::paint "The widget argument is optional. [...]
      For cached painting, widget is always 0.". Even though currently no code
      in dolphin does cached painting, for the sake of modularity one should
      not rely on widget to be non-null. Using QStyleOption::initFrom does
      assume that, though.
      
      In fact, GammaRay asks the items to do cached painting when attaching it
      to the application, causing it to crash.
      037d2c99
  6. 04 Jul, 2018 1 commit
  7. 29 Mar, 2018 1 commit
  8. 04 Mar, 2018 1 commit
  9. 03 Mar, 2018 1 commit
  10. 29 Jan, 2018 1 commit
    • Marco Martin's avatar
      base scrolling on the smallest item · 0b130dd5
      Marco Martin authored
      Summary:
      CCBUG: 386379
      
      after recent highdpi patches on scrolling that delegated it
      completely to the scrollbar, based upon the scrollbar singleStep
      setted to the tallest of the items in the view.
      tough this makes scrolling way too fast, and on folders where just
      few filenames are longer than most we can get a single scrolling
      step almost double the number of lines configured in the
      mouse kcm.
      Using the shortest item instead of the tallest mitigates this problem
      making it a bit more usable
      
      Test Plan:
      tested on different folders in different view modes both with
      mouse and touchpad
      
      Reviewers: #dolphin, broulik, ngraham
      
      Reviewed By: #dolphin, ngraham
      
      Subscribers: ngraham, plasma-devel
      
      Tags: #plasma
      
      Differential Revision: https://phabricator.kde.org/D10102
      0b130dd5
  11. 21 Nov, 2017 1 commit
  12. 19 Nov, 2017 2 commits
    • Andreas Krutzler's avatar
      Fix scrolling during inline renaming causes rename of wrong file · af27d573
      Andreas Krutzler authored and Elvis Angelaccio's avatar Elvis Angelaccio committed
      Summary:
      Scrolling during inline renaming accepts the renaming now, like if one would hit Return for example. I chose this approach because it seems the easiest way to fix this.
      This also fixes the “possible” Ui glitch where the renaming KTextField doesn’t move along with the list item. Possible glitch, because I don’t know if this is intentional, but for me it looks broken.
      
      BUG: 378786
      Fixes T7443
      
      Test Plan:
      * Enable "Rename inline" in dolphin settings
      * Go to a folder where you have to scroll through items (many files, big zoom,…)
      * Start to rename a file (context menu, F2, …)
      * Scroll with mouse wheel
      * Rename  accepted -> file is renamed
      
      Reviewers: ngraham, rkflx, #dolphin, elvisangelaccio
      
      Reviewed By: ngraham, rkflx, #dolphin, elvisangelaccio
      
      Subscribers: anthonyfieroni, elvisangelaccio, #dolphin
      
      Maniphest Tasks: T7443
      
      Differential Revision: https://phabricator.kde.org/D8822
      af27d573
    • Andreas Krutzler's avatar
      Fix scrolling during inline renaming causes rename of wrong file · 5bee1889
      Andreas Krutzler authored and Nate Graham's avatar Nate Graham committed
      Summary:
      Scrolling during inline renaming accepts the renaming now, like if one would hit Return for example. I chose this approach because it seems the easiest way to fix this.
      This also fixes the “possible” Ui glitch where the renaming KTextField doesn’t move along with the list item. Possible glitch, because I don’t know if this is intentional, but for me it looks broken.
      
      BUG: 378786
      Fixes T7443
      
      Test Plan:
      * Enable "Rename inline" in dolphin settings
      * Go to a folder where you have to scroll through items (many files, big zoom,…)
      * Start to rename a file (context menu, F2, …)
      * Scroll with mouse wheel
      * Rename  accepted -> file is renamed
      
      Reviewers: ngraham, rkflx, #dolphin, elvisangelaccio
      
      Reviewed By: ngraham, rkflx, #dolphin, elvisangelaccio
      
      Subscribers: anthonyfieroni, elvisangelaccio, #dolphin
      
      Maniphest Tasks: T7443
      
      Differential Revision: https://phabricator.kde.org/D8822
      5bee1889
  13. 01 Nov, 2017 1 commit
  14. 27 Oct, 2017 1 commit
    • Andreas Krutzler's avatar
      Two clicks on file/folder to rename · 54542830
      Andreas Krutzler authored and Nate Graham's avatar Nate Graham committed
      Summary:
      Make renaming of files/folders faster by clicking a second time on the items text to start renaming.
      BUG: 205157
      
      Test Plan:
      This feature works as follows:
      
      1. select an item by single-click, or one is already selected
      2. wait the "double-click-interval"
      3. click on the items text
      4. none of the cancellations (see below) happens within the double-click-interval
      5. inline-renaming starts
      
      Cancellations:
      * open any file/folder
      * select different item(s)
      * start dragging items
      * Dolphin loses focus
      
      This feature is just enabled while "Double-click to open files and folders" in system-settings and "Rename inline" in Dolphin are enabled.
      
      Reviewers: #dolphin, #kde_applications, elvisangelaccio, emmanuelp, ngraham, markg, rkflx
      
      Reviewed By: #dolphin, #kde_applications, elvisangelaccio, ngraham, rkflx
      
      Subscribers: rkflx, markg, funkybomber, sars, elvisangelaccio, ngraham
      
      Differential Revision: https://phabricator.kde.org/D7647
      54542830
  15. 20 Nov, 2016 1 commit
    • Elvis Angelaccio's avatar
      Fix slow scrolling in dock panels · 90beb4a5
      Elvis Angelaccio authored
      Commit f688bcd1 fixed slow scrolling with xf86-input-libinput on DolphinView.
      
      However the commit also exposed a bug in the Dolphin scrolling
      algorithm, which was previously hidden. This resulted in slow
      scrolling in dock panels (Places and Folders), with both
      xf86-input-evdev and xf86-input-libinput drivers, as well as libinput on
      Wayland.
      
      KItemListContainer::updateScrollOffsetScrollBar() relied on the view's
      itemSize() method to compute the scrollbar's singleStep, but this QSize
      was invalid for the dock panels' views.
      
      We use a new itemSizeHint() method instead, which is always valid and
      also adapts to the current icon size set in the view.
      
      BUG: 365968
      FIXED-IN: 16.12.0
      REVIEW: 129409
      90beb4a5
  16. 19 Mar, 2015 1 commit
  17. 24 Feb, 2015 1 commit
  18. 27 Oct, 2014 1 commit
  19. 18 Oct, 2014 1 commit
  20. 10 Aug, 2014 1 commit
  21. 03 Jul, 2014 1 commit
    • Frank Reininghaus's avatar
      Remove current item highlighting in the Places Panel · 4d8f89f5
      Frank Reininghaus authored
      In the Places Panel, there is always exactly one selected item, which is
      equal to the current item. Since the selected item is highlighted by
      drawing its background in a different color, it is not really necessary
      to highlight additionally that it is the current item.
      
      This is achieved by removing the calls to
      KItemListWidget::setCurrent(true) from KItemListView. The "current"
      information in the widget is only used for deciding if the "current item
      highlighting", like an underline in Oxygen, should be drawn.
      
      The motivation for this change is that I have seem some complaints about
      the "current item" highlighting, which can be even more distracting with
      non-Oxygen styles.
      
      REVIEW: 119019
      4d8f89f5
  22. 29 Jun, 2014 1 commit
  23. 05 Jun, 2014 1 commit
    • Frank Reininghaus's avatar
      Separate width and height info in the layouting code · e07468c7
      Frank Reininghaus authored
      By separating the width and height info, we can save some unnecessary
      overhead in terms of memory and CPU cycles, and make the calculation of
      the height of a row (or the width of a column in Compact View) a bit
      simpler.
      
      To achieve this, this patch extends the concept of "logical rows"
      (which are actually columns in Compact View) to "logical width" and
      "logical height" (which is the actual height and width, respectively, in
       Compact View). The distinction between rows/columns and "logical"
      rows/columns may be a bit confusing, but the confusion is already in the
      current code, and I hope that it will be mitigated a bit by prefixing
      the corresponding variables with "logical".
      
      REVIEW: 118454
      e07468c7
  24. 29 May, 2014 1 commit
  25. 05 May, 2014 3 commits
    • Alex Richardson's avatar
      dolphin: convert kitemviews/ to qt5 signal slot syntax · bb642c92
      Alex Richardson authored
      This conversion was performed automatically using convert2qt5signalslot.
      The only manual changes required were changing the overloaded signal
      KDirLister::redirection and KDirLister::completed from KUrl to QUrl. All
      other cases were no problem since these signals are not overloaded and a
      static_cast for disambiguation is not necessary.
      
      Code inside HAVE_BALOO is not converted yet, will do that once I can build
      a version with Baloo.
      bb642c92
    • Alex Richardson's avatar
    • Alex Richardson's avatar
      Allow compiling Dolphin with KF5 · 2f045c60
      Alex Richardson authored
      This does not work properly yet, there are probably quite a few bad signal/
      slot connections due to KUrl -> QUrl. However dolphin starts without
      crashing.
      
      Accessibility is not ported since that changed quite a lot from Qt4 -> Qt5
      and I have no idea how it is supposed to be used.
      
      This is the first commit for review 117395
      2f045c60
  26. 24 Feb, 2014 2 commits
    • Frank Reininghaus's avatar
      Make the handling of the "maximum text lines" setting more robust · 342822e8
      Frank Reininghaus authored
      If the user sets a maximum number of text lines in the settings, this
      number was translated into a maximum height in pixels using
      QFontMetrics::lineSpacing() before this commit.
      
      In KStandardItemListWidgetInformant::itemSizeHint(), this maximum height
      limited the size that is reserved for the item.
      
      However, in KStandardItemListWidget::updateIconsLayoutTextCache(), the
      maximum height was translated back into a maximum number of lines,
      which limits the number of lines that are created using the QTextLayout.
      
      This approach could lead to problems if the real height of the layouted
      text is 1 pixel more or less than QFontMetrics::lineSpacing() times
      "number of lines".
      
      Now we do not store a "maximum height" inside the "maximum size"
      explicitly, but store a maximum number of lines and a maximum with (for
      Compact View) separately, and then use the number of lines also to
      calculate the required size in
      KStandardItemListWidgetInformant::itemSizeHint(). This should make sure
      that the correct height is reserved for each item.
      
      Thanks to Christoph Feck and Emmanuel Pescosta for helping to debug this
      problem and testing the patch.
      
      BUG: 323841
      FIXED-IN: 4.13
      REVIEW: 113871
      342822e8
    • Emmanuel Pescosta's avatar
      Handle font and palette changes in Dolphin list views. · 0d37038b
      Emmanuel Pescosta authored
      Also update the font of the meta data widget in InformationPanelContent (smallest readable font).
      
      BUG: 329186
      BUG: 315061
      FIXED-IN: 4.13
      REVIEW: 115958
      0d37038b
  27. 11 Feb, 2014 1 commit
    • Frank Reininghaus's avatar
      Ensure that KItemListViewLayouter always has a size hint resolver · 502016c1
      Frank Reininghaus authored
      KItemListViewLayouter uses a KItemListSizeHintResolver to find out how
      much space the items will need in the view.
      
      Before this commit, the size hint resolver object could be changed at
      runtime, and it could also be null. However, we never made use of these
      possibilities, so all the code that checks if m_sizeHintResolver is
      null is actually not needed at all.
      502016c1
  28. 12 Jan, 2014 1 commit
    • Emmanuel Pescosta's avatar
      Calculate all item size hints at once. · 3ff6e834
      Emmanuel Pescosta authored
      The speed up is really small, but theses changes are mostly straightforward and make the code a bit nicer - break
      the KStandardItemListWidgetInformant::itemSizeHint beast into three smaller functions.
      
      FIXED-IN: 4.13
      REVIEW: 112979
      3ff6e834
  29. 30 Oct, 2013 1 commit
    • Frank Reininghaus's avatar
      Store the selected items in a more efficient way · fc2ab478
      Frank Reininghaus authored
      Since Dolphin 2.0, we have stored the selected items in a QSet<int>,
      which is neither space-efficient nor particularly fast when inserting
      many items which are in a consecutive range.
      
      This commit replaces the QSet<int> by a new class "KItemSet", which
      stores the items in a sorted list of ranges. For each range, we only
      store the first index and the length of the range, so we need a lot
      less memory for most common selection patterns, and we also save quite
      a few CPU cycles in many situations, because adding an item to the
      KItemSet will in many cases not need a memory allocation at all, and
      it's particularly easy when inserting sorted items into the KItemSet in
      a row.
      
      KItemSet contains a minimal subset of QSet's API which makes it
      suitable as a drop-in replacement for our needs. It also has iterators,
      such that the items can be iterated through easily, also with foreach.
      One advantage of KItemSet compared to QSet<int> is that the items are
      always iterated through in ascending order.
      
      REVIEW: 113488
      fc2ab478
  30. 12 Sep, 2013 1 commit
  31. 14 Aug, 2013 1 commit
    • Frank Reininghaus's avatar
      Fix crash when disabling "Show in groups" · 7e5b7d56
      Frank Reininghaus authored
      The problem was that items are removed from m_visibleGroups while
      a QMutableHashIterator iterates over this hash, such that the iterator
      can become invalid. The solution is to use a QHashIterator instead,
      which takes a copy of the hash. Therefore, it is not affected if
      m_visibleGroups is modified in any way.
      
      BUG: 323248
      FIXED-IN: 4.11.1
      REVIEW: 111919
      7e5b7d56
  32. 04 Aug, 2013 1 commit
    • Frank Reininghaus's avatar
      Introduce a new signal "groupsChanged" · 6524bf70
      Frank Reininghaus authored
      Sometimes when items are renamed, the order of the items in the
      directory is not affected, but the groups still change (simple example:
      with files a, b, c, e, rename "c" to "d"). At the moment, we always emit
      the itemsMoved signal in such a case to make sure that the view is
      updated. However, it would be preferable if this signal was not emitted
      because it can trigger some quite expensive operations which are not
      needed at all.
      
      This commit introduces a new signal groupsChanged and modifies
      KFileItemModel and KItemListView such that these classes make use of it.
      Some unit tests for the new functionality are included as well.
      
      Thanks to Emmanuel Pescosta for finding a latent bug in the code which
      was triggered by this change and fixed in
      998954db.
      
      REVIEW: 111808
      6524bf70
  33. 25 Jul, 2013 1 commit
    • Frank Reininghaus's avatar
      Prevent that removing items can cause icons to overlap · 08c2f7f5
      Frank Reininghaus authored
      When items are removed, new items may become visible because of that.
      This includes
      
      (a) Items *behind* the removed range. KItemListView may try to create
          their widgets at their "imaginary" old positions and move them to
          the new position with an animation.
      
      (b) Items *before* the removed range, if the deletion causes the view
          to scroll up. In that case, the "imaginary" old position and the new
          position was equal, but KItemListView still tried to determine the
          "old" position by adding the number of removed items to the index.
          The result was that the widgets were created at completely wrong
          positions, and no animation was started to fix this.
      
      Thanks to Emmanuel for helping to find the cause of this bug!
      
      BUG: 302373
      FIXED-IN: 4.11.0
      REVIEW: 111630
      08c2f7f5
  34. 05 Jul, 2013 2 commits
    • Frank Reininghaus's avatar
      Fix O(N^2) complexity issue in KItemListView::slotItemsRemoved() · 6028bd7c
      Frank Reininghaus authored
      If many item ranges are removed, KItemListView::slotItemsRemoved()
      could take very long because it looped over all items after the first
      removed one for every removed range, even if most of these items are
      not visible at all.
      
      This commit improves this by just looping over the visible items (whose
      number is limited by the window size) for each range.
      
      Test case (for very large N):
      
      touch {1..N}.png
      touch {1..N}.jpg
      
      (wait until all files are shown in the view)
      
      rm *.jpg
      
      REVIEW: 111398
      6028bd7c
    • Frank Reininghaus's avatar
      Keep the "item size hints" of moved items · 837be343
      Frank Reininghaus authored
      It's quite expensive to re-calculate them, so we should better just move
      them to the correct position, rather than throwing them away.
      
      REVIEW: 111399
      837be343
  35. 04 Jul, 2013 1 commit
    • Frank Reininghaus's avatar
      Make sure that KItemListSizeHintResolver is always consistent · 786cea00
      Frank Reininghaus authored
      This was the root cause of bug 317827. The assert tried to make sure
      that we never access KItemListSizeHintResolver from
      KItemListViewLayouter inside the loop over the item ranges. This would
      be dangerous because it might be in an inconsistent state - the removed
      item ranges were removed step by step, so accessing the item size hints
      before the operation was finished could lead to wrong results.
      
      The solution is to insert/remove all item ranges immediately. A nice
      side effect is that there are no sources of O(N^2) complexity in
      KItemListSizeHintResolver any more if many item ranges are
      inserted/removed.
      
      BUG: 317827
      FIXED-IN: 4.11.0
      REVIEW: 111382
      786cea00