SUMMARY Drag and drop does not always work as expected under Windows 10. Single files rise an error but work. File links (*.lnk) worked in version 5.3.1 but not anymore in 5.3.2 . Dropping in the editor area is not supported. STEPS TO REPRODUCE 1. Drag and drop multipple text files into the area of the editor tabs. It works. 2. Drag and drop a single text file into the same area. An error is rised, but after that the file is opened. The error needs to be handled by the user an is annoying (message back translated from German: "No activated module supports repository URL: file:///Z:/mydir/myfile.txt", in German "Kein aktiviertes Modul unterstützt diese Repository-URL: file:///Z:/mydir/myfile.txt"). 3. Drag and drop one or more Windows file links (*.lnk files, symbolic links) into the same area. This was handled in the previous version but is not supported anymore. I loved this feature since I can collect often used files as symbolic links on the desktop or in project directories. 4. Drag and drop files into the editor area. This is handled by MSVC (MS Visual Studio) in all version but not in kdevelop. MSVC has a bad handler for CSS files. The result is not opening the file but inserting the URL of the file into the CSS text. But for all other tested file type it opens the file in a new editor tab. OBSERVED RESULT As described above. EXPECTED RESULT Just open the file[1] or files or symbolic link(s)[3] without annoying error message [2], even on drop onto the editor area [4]. SOFTWARE/OS VERSIONS Windows: Window 10 MacOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: bundled in kdevelop ADDITIONAL INFORMATION
Correction: Drag and drop of Windows shortcuts [3] (*.lnk-Files, actually no symbolic links, but share some properties) works now. My observation seemed to be wrong. Nevertheless the same error is rised as for other single files dropped outside the editor area.
Detailed observation: It is irritating which GUI elements are sensitive for the drop event and which are not. The application frame, the main menu and nearly all other GUI elements accept the drop event. But the tool area and the editor are do not accept it. Despite the fact, the editor area has a hover effect for the lines, so it seemed to be planned to react on drop events there. And the cursor changed all over the kdevelop application are to "+ Kopieren" (in the German version, in English it would be "+ Copy"), and this is wrong. It should be "Open file" in most situations. If there is a reason to reserve other reactions for some GUI elements like for tool buttons or the edit area, the cursor feedback should show this. It is not the users job to find out by trial and error what GUI elements will accept which drop action. Proposal: It would be nice, to provide for all GUI elements and especially for the editor area the *possibility* to handle drag and drop its own way. That might be very nice. But the user should be able to configure this and switch it off. The default should be 'accept drop file for open file action'. The cursor should always reflect the behavior and only change to 'Open file' if the GUI element is really providing this action.