If you use Ctrl+C and Ctrl+V the dialog appears as expected, in front of all windows. But if you use the mouse drag and context menu on drop the dialog will not appear topmost. This shouldn't have to be a bug report, it should have been caught during simple common-sense development testing. I'll say it again, there is something bigger than just the code being wrong.
Thanks for filing this bug report. Unfortunately there isn't enough information for us to try to figure out what's happening. I'm not able to reproduce what has been described with Dolphin 24.08.2 or git-master. The steps I used: Drag a file from one Dolphin window to another window with a different folder that has a file with the same name In the right click menu, choose Copy I see the "File Already Exists" dialog come up on top of the Dolphin window. Please add information about your system as outlined in the bug report template. Linux/KDE Plasma: (available in About System - use the Copy Details button and paste here) - Specific steps to reproduce the problem. Walk us through what you're doing, what you expected to happen and what actually happened. 1. 2. 3.
Overwriting the file doesn't cause the issue, it's copy and pasting a file that causes it. I thought that it only happened in the drag and drop context menu, but it also happens with the shortcut keys. First of all you must disable the notifications in the system settings. This will switch from the notifications (in the bottom right hand corner) to the actual copy dialog. System Settings -> Notifications (Application progress) Show in notification: Disabled 1. Open a few Dolphin windows 2. Make sure the windows cover the center of the screen (where the copy dialog should appear) 3. Start copy/pasting large files around the windows (do not overwrite) Actual result: Copy dialog appears behind the windows Expected result: Once the copying starts, the copy dialog must be topmost and active above all other windows Dolphin version: 24.08.1 Operating System: KDE neon 6.2 KDE Plasma Version: 6.2.0 KDE Frameworks Version: 6.6.0 Qt Version: 6.7.2 Kernel Version: 6.8.0-47-generic (64-bit) Graphics Platform: X11 P.S. Also test this with all options in the drag and drop context menu. Make sure you use large files so that the copy dialog is open for long enough that you can see the issue.
Thanks for the additional details. I re-tested with KDE Neon, with the steps you provided and confirmed the issue.
.
JFYI This wasn't caught because it's an esoteric off-by-default setting, and those often don't get much testing.
I'm glad that the esoteric option exists, as I've never liked notifications. I guess it's just a modern design choice but notifications are more limited than dialogs. They can't be moved around like a dialog. If you have multiple copy operations then the notifications stack vertically and take up space, whereas you can move multiple dialogs out of the way onto a separate monitor and have them cascade. Testing ought to be thorough, with both notifications and without. If the option to switch notifications off while testing is rarely remembered then the maintainer or the person in charge of pull requests should make a note of it and remind developers when attempting a merge.