| Age | Commit message (Collapse) | Author |
|
Only connect the renamingFailed signal if there is no item with the new name in the model yet.
BUG: 328262
FIXED-IN: 4.11.5
REVIEW: 114228
|
|
|
|
Use KStringHandler and QTextLayout to wrap the text (file name)
into the maximum width of the label "name".
Make use of QFontMetrics to calculate a font size aware tooltip size.
BUG: 287983
FIXED-IN: 4.11.3
REVIEW: 113101
|
|
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
|
|
BUG: 323181
FIXED-IN: 4.12.0
REVIEW: 113234
|
|
|
|
BUG: 267171
FIXED-IN: 4.11.3
REVIEW: 112980
|
|
|
|
|
|
Removed all signal-slot-connections related to DolphinNewFileMenu->errorMessage(QString)
in DolphinMainWindow and DolphinContextMenu and replaced it by a better solution.
Now we make use of the already existing DolphinNewFileMenuObserver singleton class to achieve a better
error handling, because every newly created DolphinContextMenu instance registers himself by DolphinNewFileMenuObserver
and we use this to connect the errorMessage(QString) signal of every DolphinContextMenu instance to the errorMessage(QString)
signal of the DolphinNewFileMenuObserver singleton class.
So we need only one connection from DolphinNewFileMenuObserver to DolphinMainWindow (or to DolphinPart) to
collect all error messages thrown by every DolphinNewFileMenu instance.
REVIEW: 112178
|
|
The purpose of this change is to give the user a chance to see hover
file information if it doesn't fit in the status bar, by allowing to
click on the file and hover on the status bar.
As it's now possible to have status bar texts starting with "<qt>",
DolphinPart::updateStatusBar() must escape strings. Otherwise,
filenames such as "<qt>Tes<font color=red>t" would be rendered as HTML
data in konqueror's status bar when selected.
BUG: 260717
FIXED-IN: 4.12.0
REVIEW: 111934
|
|
BUG: 321577
FIXED-IN: 4.12.0
REVIEW: 111805
|
|
|
|
Thanks to Emmanuel for pointing out a problem with my first patch.
BUG: 322965
FIXED-IN: 4.11.0
REVIEW: 111722
|
|
open these urls in the default browser instead.
BUG: 283475
BUG: 318217
FIXED-IN: 4.11.0
REVIEW: 111674
|
|
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
|
|
recently been brought up and that have been caused by review 107351 / commit
fd65a97b0787b23246c9392fdc34173fb604c9ca
CCBUG: 233335
FIXED-IN: 4.11.0
REVIEW: 111254
|
|
|
|
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
|
|
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
|
|
|
|
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
|
|
We don't need the parameter at all, so let's just remove it.
|
|
|
|
This is the real fix now - note that the last commit
4de9a233642a62ee96bac6031340d3eea21f14f9 was actually the fix for bug
320823. Somehow, I have messed up the local branches in my git
respository clone - sorry for the confusion!
BUG: 319912
FIXED-IN: 4.10.5
REVIEW: 110908
|
|
Change the data in the model before the real renaming is done by KonqOperations::rename(),
but when the rename operation fails, revert the data changes in the model.
BUG: 319119
REVIEW: 110922
|
|
Thanks to Dawit Alemayehu for making this fix possible with commit
8e023ae9e5051cb7b81af86a178e37c1f2c5da94 !
BUG: 307254
FIXED-IN: 4.11.0
|
|
When user drag and drop to another splitted view, the view will be activated,
thus if user close the split view, the view will be closed, while this is
usually the case when user copy file to remote/removable media.
REVIEW: 110167
CCBUG: 312834
|
|
in a new tab
When 'browse through archives' is enabled, open archive files
like folders on middle clicking, context menu -> new tab action
and context menu -> new window action.
BUG: 196035
REVIEW: 110487
|
|
Conflicts:
CMakeLists.txt
|
|
BUG: 255819
FIXED-IN: 4.10.4
REVIEW: 109966
|
|
|
|
The "Rename" button in the dialog should be enabled if and only if the
"new name" pattern is valid. This is the case if the pattern contains
exactly one sequence of '#', which will be replaced by digits.
This patch fixes the problem that
(a) A pattern that contains a single '#' is not considered valid, and
(b) A pattern without any '#' at all is not recognized as invalid.
BUG: 318942
FIXED-IN: 4.10.3
REVIEW: 110223
|
|
If multiple files are pasted, scroll to the first pasted file.
BUG: 315722
REVIEW: 109950
FIXED-IN: 4.11.0
|
|
|
|
|
|
|
|
|
|
|
|
Showing this message in the KMessageWidget above the view, which means
that the view contents are moved down, can be extremely annoying
according to user feedback. Just showing the message in the status bar
is probably enough.
BUG: 313466
REVIEW: 108483
FIXED-IN: 4.10.0
|
|
|
|
|
|
necessary, as actions is only called from the main thread.
Also it wasn't checked consistently; if the lock could not be taken, the
plugin was accessed anyway.
|
|
UpdateItemStatesThread, because m_itemStates is only accessed by the
when the thread is done, and set before the thread starts.
Also combine the setData function with the constructor.
|
|
|
|
UpdateItemStatesThread finishing and the finished() signal being
delivered.
In this case, a new thread was not created, because the old thread
still existed. However, pendingItemStatesUpdate was not set, because the
thread was not running. Instead, the old thread was restarted.
This meant that the finished() signal from the first run could be delivered
while the thread was running for a second time, causing the thread to be
deleted while still running and thus a crash.
Solution: set pendingItemStatesUpdate if the thread is non-null,
even if it is not running, knowing that slotThreadFinished has not yet run,
and will call updateItemStates itself.
BUG: 302264
FIXED-IN: 4.10
REVIEW: 107656
|
|
|
|
FIXED-IN: 4.10
BUG: 262464
REVIEW: 108336
|