| Age | Commit message (Collapse) | Author |
|---|
|
More semantically (and visually) appropriate icon
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
even if directory of the file to be created is not the top-most opened in
TreeView
BUG: 440663
|
|
|
|
|
|
|
|
Since d3839617193e92463806580699caa595c892b8a6 in details view mode
clicking anywhere within the row is considered a click on the item.
That commit also changed it so that dropping files anywhere inside
a row would make it so the files are received by the folder of that
row.
This commit reverts the drop behaviour to be identical to the old
one.
I am having trouble explaining why this is better because one can
look at it in different ways. Bottom line is that one doesn't
really feel like one is dropping files inside a folder unless the
mouse cursor is actually directly above a folder's icon or name.
Another argument is that it is normal behaviour to just throw files
onto an application and the files then being opened by it.
Having potentially large parts of the view area covered by the rows
of folders means that there has to be more of a conscious effort to
not drop the files inside one of the folders by accident while with
this commit one has to aim precisely onto a folder to do it
intentionally.
CCBUG: 453700
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
|
|
This way we get a build time warning if the var isn't defined at all, e.g.
a missing check_include_files() CMake call.
|
|
|
|
If tooltips are enabled and you hover over item
while immediately closing Dolphin sometimes it would crash
because native parent might have been destroyed before
DolphinView
|
|
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
|
|
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
|
|
uninitialised value"
KItemListView::setAlternateBackgrounds(bool) (kitemlistview.cpp:489)
In C++, a data member of an object is not automatically initialized to "zero".
In this case a bool had random values such as the integer 255.
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
(cherry picked from commit d0fc5bcd3d5c66611ec706c810103920e47c6038)
|
|
(cherry picked from commit 716d814019b077246fd60c59630e4dfd1c9e1f89)
|
|
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
|
|
|
|
|
|
|
|
In Qt5 it takes an int, in Qt6 it takes a QFont::Weight.
|
|
Apparently KPluginMetaData was implicitly included by something else.
|
|
|
|
GIT_SILENT
|
|
|
|
GIT_SILENT
|
|
- Fix kio_version.h include
- Explicitly create a QSet for QCOMPARE
|
|
Copying QEvent in Qt6 isn't allowed, instead use clone().
|
|
|
|
Configurability of individual preview plugins has been deprecated since KIO
5.87.
|
|
|
|
Instead of having 3 separate config keys, use the KConfig QFont
de/serilaization.
|
|
We had all sorts of weird behavior when sorting by access time.
The comparison was simply missing in sortRoleCompare.
|
|
|
|
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"
|
|
|
|
If one was fast to open the right-click context menu on the row of
an item in details view mode, the hover highlight would persist
while the context menu for the view was open.
This one-liner makes it so the highlight on the row is always
removed before the right-click context menu for the view is opened
so it is as clear as possible that the newly opened context menu
has no relation to the fileItem.
|
|
Before this change, right-clicking the row of an unselected item
in details view mode would be in a weird state:
- It didn't really count as a click on the item because the item
didn't get selected by this click before opening the context
menu.
- It didn't really count as a click on the view background either
because the actions that showed up depended on the item in
that row.
This commit fixes this by considering a right-click in the same row
as an unselected item as a click on the view background.
The behaviour of right-clicking the icon or name of a file directly
is unchanged.
This fixes the following bugs:
- The Paste action that shows up when right-clicking in the
unselected row of a folder now works (instead of doing
nothing). It now pastes the clipboard contents onto the view
background.
- When right-clicking the unselected row of a file (not a folder)
a Paste action once again shows up.
|
