| Age | Commit message (Collapse) | Author |
|---|
|
BUG: 321577
FIXED-IN: 4.12.0
REVIEW: 111805
|
|
This feature might have been useful in some cases, but it's most likely
not useful enough to justify that we accept the bugs that it causes.
Even though some of these bugs are not Dolphin's fault at all, they
cause serious problems for users in some cases.
I'm pushing this commit to master only because I prefer to not push such
behavior changes to 4.11 at this point of the release cycle.
BUG: 288629
CCBUG: 322299
CCBUG: 322812
FIXED-IN: 4.12.0
REVIEW: 111692
|
|
|
|
Thanks to Emmanuel for pointing out a problem with my first patch.
BUG: 322965
FIXED-IN: 4.11.0
REVIEW: 111722
|
|
So that filenames that look like HTML don't get fancy-formatted when
we show info about them (i.e. on hover)
This patch fixes the same issue in two places:
- dolphin, by setting Qt::PlainText on the status bar's label
- konqueror, by escaping setStatusBarText strings emitted by
DolphinPart
BUG: 321778
FIXED-IN: 4.11.0
REVIEW: 111746
|
|
This small change saves a lot of CPU cycles when the items are resorted.
REVIEW: 111700
|
|
open these urls in the default browser instead.
BUG: 283475
BUG: 318217
FIXED-IN: 4.11.0
REVIEW: 111674
|
|
|
|
The problem was that the view heigt minus the header height was
subtracted from maximumScrollOffset() to determine the maximum value
of the scroll offset of the top of the view.
However, the top of the view is the part that is hiden behind the
header. Therefore, the full view height must be subtracted from
maximumScrollOffset.
The remaining bits of bug 319951 were fixed by other recent commits.
Thanks to Emmanuel Pescosta for helping to track down the problem!
BUG: 319951
FIXED-IN: 4.11.0
REVIEW: 111486
|
|
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
|
|
|
|
|
|
The problem was that DolphinItemListView overrides the virtual function
onItemLayoutChanged() without calling the base class implementation.
Therefore, KStandardItemListView::updateLayoutOfVisibleItems(), which
calls initializeItemListWidget(), is never called.
This patch refactors the "change item layout"/"supports item expanding"
code a bit to make it more robust and fix the problem that the view
looks "messed up" when switching from Details View without expandable
folders to Icons View.
I'm only pushing this patch to master (going to be KDE 4.12).
The patch is a bit too intrusive for the KDE/4.11 branch for my taste
at this point of the release cycle, and the bug is not a real
showstopper. If it works well in master, one could consider backporting
it to a 4.11.x bug fix release.
Thanks to Emmanuel Pescosta for helping to analyze this issue.
BUG: 302703
REVIEW: 111632
FIXED-IN: 4.12.0
|
|
KItemListSmoothScroller::scrollTo(qreal position) did not check if
'position' is a valid value. Even if the view is scrolled to the bottom
already, it tried to scroll further and activated "smooth scrolling"
when the mouse wheel is used. Because it never got out of the "smooth
scrolling" state then, it got confused when changing the directory, and
restoring the correct scroll offset could fail.
BUG: 322212
FIXED-IN: 4.11.0
REVIEW: 111557
|
|
The code for painting the "empty header" was inconsistent with the
headers of the other columns, which is probably the reason why the other
styles got confused
a) No QStyleOptionHeader is used
b) Even if an empty header must be drawn, the last column is drawn with
the option QStyleOptionHeader::End.
According to Christoph, it still doesn't work with the Skulpture style,
but it seems that the patch does at least not make things worse.
BUG: 301800
FIXED-IN: 4.11.0
REVIEW: 111608
|
|
We really have to make nepomuk-core and nepomuk-widgets a hard
dependency in the framworks era.
|
|
because the nepomuk roles provider doesn't overwrite it when the property
value list is empty.
BUG: 322348
REVIEW: 111505
FIXED-IN: 4.11.0
|
|
Rather than loading many icons (without full mime type determination)
in advance, we make sure that an item has an icon just before it is
shown in the view. This makes sure that no "unknown" icons are shown
unnecessarily, and saves some resources.
REVIEW: 111396
|
|
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
|
|
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
|
|
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
|
|
The problem was that the files were copied/moved inside the nested event
loop of the drag, which caused problems if the "File exists" dialog was
shown.
The solution is to make the copy/move operation delayed, such that it is
executed in the main event loop.
Note that dropping files on these menus does apparently not work at the
moment when using the Oxygen style (see bug 310016).
BUG: 192139
BUG: 256338
BUG: 293220
BUG: 309076
FIXED-IN: 4.11.0
REVIEW: 111273
|
|
FIXED-IN: 4.11.0
REVIEW: 111324
|
|
In Icons/Details (Compact) View, no layouting is necessary if the view
height (width) changes.
REVIEW: 111322
|
|
If the elements are larger than a pointer, QList does not store the
elements themselves, but pointers to them in a contiguous block of
memory. This wastes quite a bit of memory. This can be prevented easily
by using QVector instead.
REVIEW: 111304
|
|
Instead of the KFileMetaDataConfigurationWidget
REVIEW: 111294
|
|
Since m_pendingItemsToInsert is a list of pointers now (and not a list
of KFileItems, as in the 4.10 branch), we have to delete all pointers
when clearing or destroying the model.
I think that no review request is necessary for this small and obvious
change.
CCMAIL: [email protected]
|
|
icon in Compact View and Details View mode.
BUG: 320899
FIXED-IN: 4.11.0
REVIEW: 111244
|
|
Added a hash table for target url to url mapping. So when the dir lister
sends us the target url as directory url, we can use the url mapping table
to get the right "Dolphin internal" directory url, which is the non-target url.
BUG: 306219
FIXED-IN: 4.11.0
REVIEW: 111252
|
|
recently been brought up and that have been caused by review 107351 / commit
fd65a97b0787b23246c9392fdc34173fb604c9ca
CCBUG: 233335
FIXED-IN: 4.11.0
REVIEW: 111254
|
|
|
|
This has some advantages:
(a) The version actually changes for every bug fix release, making it
easier to find out which version a bug reporter has used.
(b) No changes in Dolphin's source code are required to keep the version
always up to date.
(c) It is more transparent for users because there are not two different
versions any more.
|
|
When using Details View, only insert all pending items immediately if
new items are inserted which might be children of a pending item. Fixes
the problem that inserting the items in multiple bunches slows down the
folder loading.
Note that the cause of the slowness when inserting in multiple bunches
is that KItemListSizeHintResolver needs O(N^2) time in the worst case
for inserting N items into a model with N existing ones.
REVIEW: 111226
|
|
Use object-(un)locked icon and make it flat.
REVIEW: 111233
|
|
QDate's api is not that intuitive and the addDays functions return a
QDate with those amount of days. They do not modify the original QDate.
BUG: 321198
|
|
BUG: 261762
REVIEW: 111206
FIXED-IN: 4.11
|
|
|
|
KFileItemModel::createMimeData.
BUG: 307336
FIXED-IN: 4.10.5
REVIEW: 111209
|
|
If each directory can have its own view properties, and loadting the
.directory file fails in a directory, we have to load the global view
properties. However, if we try to do this by changing the "global view
properties setting" and loading the view properties for the same
directory again, we might get an infinite recursion if changing the
setting fails.
We now force a loading of the global view properties by constructing a
new ViewProperties object with an empty URL.
Thanks to Kurt Hindenburg for helping to debug this issue (which was
only reproducible on MacOS).
BUG: 316209
FIXED-IN: 4.10.5
REVIEW: 111182
|
|
It is common for music files to have more than one artist
BUG: 321359
|
|
It is no longer required. In fact it hasn't been required since
nepomuk-core was introdcued.
|
|
enabled state in the context menu for read only files/folders (also
archives).
BUG: 294013
FIXED-IN: 4.11
REVIEW: 111160
|
|
This commit ensures that changing the view mode works even if the
.directory file in the user's KDE folder is not writable.
BUG: 318534
FIXED-IN: 4.11.0
REVIEW: 111120
|
|
The problem was that the KonqOperations object did not have the right
parent.
BUG: 299646
FIXED-IN: 4.11.0
REVIEW: 111111
|
|
Each time one uses any of the Nepomuk classes, an attempt is made to
connect to the database. This slows down the application since
connecting to Nepomuk is not so cheap.
BUG: 321299
|
|
This reverts commit b1aebb44d6863951841d857b84253a782d4138dc.
As agreed with Frank on k-c-d.
|
|
|
|
Normally, we only allow renaming multiple files if the new file name
contains a contiguous sequence of '#' placeholders, which are then
replaced by numbers.
However, if all extensions are different, we can also rename the files
without such a placeholder because the original extension is preserved
when renaming.
This had been possible some time ago already. That this "accidental
feature" was lost was a side effect of the fix for bug 318942.
BUG: 321234
FIXED-IN: 4.10.5
REVIEW: 111079
|
|
The problem was that pressing the Shift key would reset the keyboard
search.
BUG: 321286
FIXED-IN: 4.11.0
REVIEW: 111102
|
|
This fixes the problem that the drop indicator might still be shown
after the drag&drop operation in the Places Panel is finished.
REVIEW: 111037
|
