This splits the enum IconView::Flow into two enums
- IconView::Layout { Rows, Columns }
- IconView::Alignment { Left, Right }
Note that Qt::Alignment is not used to emphasize the fact that
these two properties are orthogonal (layoutDirection() is used
e.g. to place the scrollbar at the correct side of the screen,
whereas IconView::Alignment is about the side of the screen
the user want their icons to stick to.
This patch greatly improves the readability of the IconView
layouting code, as well as the user-friendliness of the
applet's Display configuration page, with a distinct separation
of the two layout-related factors.
Corresponding context menu actions have been added. They update
the configuration dialog combos when selected if the dialog is
open at that moment.
CCBUG:306537
Conflicts:
plasma/applets/folderview/folderview.cpp
CCMAIL: ignat.semenov@blue-systems.com
@Ignat: We've been following a merge-based approach in kde-baseapps
for quite some time now, see
http://lists.kde.org/?t=134744909400005&r=1&w=1
It would be nice if you could merge KDE/4.10 into master after any
non-trivial changes in folderview to prevent that others have to
figure out how to resolve the merge conflicts. Thanks!
These actions do not work correctly because renaming is considered
finished as soon as the line edit loses focus, which happens when the
"Replace" dialog pops up.
BUG: 317772
FIXED-IN: 4.10.3
I'm not sure yet if there is a problem somewhere else in the code. For
the time being, I think it's better to replace the assert by a TODO
comment to prevent that users find out the hard way that there is
something that we're not quite sure about.
BUG: 317827
FIXED-IN: 4.10.3
When entering a folder, KFileItemModelRolesUpdater has not yet been
informed about the visible index range by the view when it tries to
determine icons synchronously. This resulted in the problem that it
tried to determine icons for all items in random order, and some visible
icons were somtimes still unknown after the "synchronous icon loading"
timeout of 200 ms.
This commit tries to improve the situation by loading icons starting
with the first item in increasing order. This should make it less likely
that some visible items still have unknown icons after 200 ms.
BUG: 316129
FIXED-IN: 4.10.3
REVIEW: 109843
The configChanged() implementation could unnecessarily schedule a
reload due to a bug in a has-this-config-element-changed comparison,
which would result in icon position losses in scenarios such as
changing the wallpaper or the workspace theme, without having touched
any sorting-related options. Further, OK'ing the config dialog could
undo the unsorted state entered by moving an icon while the dialog
was open; this is now handled by updating the sorting mode combo box
in the dialog after the icon is dropped.
The later relies on a preceding fix in kde-workspace.git to make
Applet::isUserConfiguring() work for containments if Folder View is
used as desktop containment.
