Bug 417189

Can someone please take a look at this issue? Perhaps it isn't a big deal.

Sorry for the delayed response I am currently the only major contributor for kdiff3 and was focused on other things. This issue appears to be resolved as of 1.8.3. Are you able to verify this?

Hi,

no changes, the bug is still there. Fedoras latest is kdiff3-1.8.3-1.fc32.x86_64.

Created attachment 130168 [details]
attachment-15546-0.html

Tell your distro to upgrade  you are still using 1.8.1 not 1.8.3.

On Thu, Jul 16, 2020, 2:55 AM Attila <bugzilla_noreply@kde.org> wrote:

> https://bugs.kde.org/show_bug.cgi?id=417189
>
> --- Comment #3 from Attila <bugs.kde.attila@online.de> ---
> Hi,
>
> no changes, the bug is still there. Fedoras latest is
> kdiff3-1.8.3-1.fc32.x86_64.
>
> --
> You are receiving this mail because:
> You are the assignee for the bug.

Don't get me wrong, but can you please take a look at the attached screenshot?
I see version 1.8.3.

Created attachment 130170 [details]
Version 1.8.3

Sorry for some reason I thought I saw 1.8.1. Anyway I'll have a closer
look when I get home.

This doesn't reproduce on my test machine. Going to try and setup a Fedora VM and see if it shows there.

Git commit 669b12bfae1305b9aa3618cc4c3a7387767d713f by Michael Reeves.
Committed on 24/07/2020 at 19:27.
Pushed by mreeves into branch '1.8'.

Accept drag and drop in Open Dialog

acceptDrops is some how set on my machine. However,
Qt docs indicate it is false by default.
Make sure it always gets set.
FIXED-IN:1.8.4

M  +4    -0    src/smalldialogs.cpp

https://invent.kde.org/sdk/kdiff3/commit/669b12bfae1305b9aa3618cc4c3a7387767d713f

Git commit 315f8439fbc0940e7df33d011f45f5320997545d by Michael Reeves.
Committed on 24/07/2020 at 19:30.
Pushed by mreeves into branch 'master'.

Accept drag and drop in Open Dialog

acceptDrops is some how set on my machine. However,
Qt docs indicate it is false by default.
Make sure it always gets set.
FIXED-IN:1.8.4

M  +12   -0    src/opendialog.ui

https://invent.kde.org/sdk/kdiff3/commit/315f8439fbc0940e7df33d011f45f5320997545d

Hi,

thank you for the fix. I can't wait to test it.
Still one question. Did you make a "pull request" to the Fedora packagers (maintainers) to update KDiff3?
There is no "rpm" in "testing" at the moment.

You'll have to speak with your distro regarding their process for getting the fix into testing. I don't handle that end of things. It will be included in the upcoming 1.8.4 release. Typically distos wait for the official release before updating their packaging.

Hi,

KDiff3 version 1.8.4-1 is out for Fedora.
Unfortunately the bug is still there. Cant't drop files to the fields "A", "B" or "C".

Can you please do me a favor and turn on your VM to check again KDiff3 on Fedora?
Please change the status to "REOPENED".

Thank you again.

Setting status according to comment 13.

What extactly is happening when you try to drag and drop?

For the record I have determined that kdiff3 fails to clear the existing path on drag and drop. Thus if done a first launch it should work fine. However, after this the new path is appended to the previous one. Does drag and drop work when the file path the target field is cleared?

(In reply to michael from comment #15)
> What extactly is happening when you try to drag and drop?

Nothing happens when I drop a file from Dolphin to the target field A, B or C. The mouse cursor turns from "default" to "copy" symbol. That was it. The target field is still empty.

(In reply to michael from comment #16)
> For the record I have determined that kdiff3 fails to clear the existing
> path on drag and drop. Thus if done a first launch it should work fine.
> However, after this the new path is appended to the previous one. Does drag
> and drop work when the file path the target field is cleared?

Drag and drop never works when I start KDiff3. The "file open dialog" appears. All target fields are empty. I drop a file from Dolphin to the target field A, B or C. It doesn't work. The target field is stil empty.
There is no difference in behavior from version 1.8.3 to 1.8.4 from my point of view. For the record in the main window drag and drop works fine.

Git commit f2fb78e46d6ec0fe4fc3e0b4b55f4c32962b282c by Michael Reeves.
Committed on 18/10/2020 at 17:56.
Pushed by mreeves into branch '1.8'.

Fix drag and drop handing

Don't use QUrl::toString this will not serve our needs.
Manually handle drop events for QCombox widgets, The default behavoir
is not what we are looking for.

M  +5    -1    src/FileNameLineEdit.cpp
M  +6    -2    src/smalldialogs.cpp

https://invent.kde.org/sdk/kdiff3/commit/f2fb78e46d6ec0fe4fc3e0b4b55f4c32962b282c

Git commit dc789e1caed18da7f6f73c87ec44442a03cc15dc by Michael Reeves.
Committed on 22/10/2020 at 02:45.
Pushed by mreeves into branch 'master'.

Fix drag and drop handing

Don't use QUrl::toString this will not serve our needs.
Manually handle drop events for QCombox widgets, The default behavoir
is not what we are looking for.

M  +6    -1    src/FileNameLineEdit.cpp
M  +17   -38   src/smalldialogs.cpp
M  +0    -2    src/smalldialogs.h

https://invent.kde.org/sdk/kdiff3/commit/dc789e1caed18da7f6f73c87ec44442a03cc15dc

Michael can you please confirm the commit fixes this issue, thanks

As far as I can tell from my end it should. The drag and drop handling is now the same in "Open file" as the main window. I cann't reproduce the specific issue of being totally non-fuctional. However, QCombox has no documentation as to whether or how drop events are handled. It is likely that it doesn't in some configurations.

Use the following to test the latest nightly on flatpak

flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo
flatpak install kdeapps org.kde.kdiff3

I will be releasing 1.8.5 by the end of the month with this fix. The flatpak build is not extensively tested so it is not recommended as a long term solution.