When kompare is invoked without files as argument, the initial dialog is opened. When the Source and the Destination field are filled, either files or directories, the "Compare" button is still disabled. Kompare 4.1.3 from KDE Applications 17.12.1.
Luigi, it seems to work fine here. From looking at the code a KUrlRequester is used for each line edit and if either of them change they tell the ui to check if they are both not empty and enable that button. I tried here with the packaged version in debian buster and it worked ok, can you recreate this every time there?
Right: you don't have to type. If you type the file path, it works. If you click on the right buttons and browse and select the name from there, then the signal is not triggered.
I used the buttons to select files here which worked. That's not working there? I wonder if KURLRequester has a regression possibly. We are connecting to it's textChanged signal which seems to be working here with the kf5 packages I have from debian.
I can reproduce the issue here: kompare 4.1.3 from kompare-17.12.1-1.fc27.x86_64 kf5 5.42.0 from Fedora RPMs qt5-qtbase 5.9.2 from Fedora RPMs which is why I asked Luigi to file this issue here to begin with.
Yep, I can recreate with latest kompare and kf5 from git. Let's see if I can find the cause now :)
https://cgit.kde.org/kio.git/commit/?id=ffffa43aea3ebc697fad4be8be821b94c8374d08 is definitely the cause undoing the bits of that commit in kurlrequester.cpp fix the bug, but I'm not sure why yet. We are connecting to KURLRequester's textChanged signal in kompare, but we are changing the KURLRequester's KUrlComboBox itself with setUrl when those buttons are clicked. KUrlComboBox::setUrl turns off its own signals, so I don't see how that ever worked except that we were connected to the lineedit rather than the QComboBox I guess. A simple fix is in KUrlComboBox setUrl to emit textChanged after changing the url in setUrl, but I'm not sure if that makes the most sense or not.
Alternatively we could have the FilesPage emit a signal after it calls setUrl on the KUrlCombobox
*** Bug 391405 has been marked as a duplicate of this bug. ***
Just so the workaround is also clearly visible here, I am reposting https://bugs.kde.org/show_bug.cgi?id=391405#c2 here: Jeremy Whiting wrote: > As a temporary workaround after choosing files typing anything in either box > (even a space) activates the button. Working on the proper solution for the > bug in frameworks though.
This bug is still present with Kompare 18.08 and latest frameworks master
This is still present in the updated version of Kubuntu 18.04 (still 4.1.3).
This is still present in the last realize: Plasma 5.15.3 Frameworks 5.56(and 5.55) Qt 5.12.2 In dialog "select files" to diff, the "Compare" button is still disabled. In next dialog "Kompare" → "aplication for diff", select any valid aplications not effect. (Meld work fine, diff at console work fine) in console nothing errors.
... kompare-18.12.3 and git-version. Not usable.
Operating System: Arch Linux KDE Plasma Version: 5.16.0 KDE Frameworks Version: 5.59.0 Qt Version: 5.12.3 Kompare version: 4.1.3 (19.04.2-1) Still reproducible.
Just pushed a fix for this issue to master branch. It will be in the next release 19.08 I believe, Missed the tag for 19.08 beta, but will be in the RC and release.
Git commit 5f7444b061b6453aad2ede25a598cf175893eb89 by Luigi Toscano, on behalf of Jeremy Whiting. Committed on 22/07/2019 at 07:45. Pushed by ltoscano into branch 'Applications/19.08'. Fix browse for files/folders doesn't enable "Compare" button. Since KUrlComboBox::setUrl doesn't emit textChanged (by design according to it's documentation) we need to emit a signal from FilesPage when we set the url programatically so the kompareurldialog knows something changed and to enable the button if both boxes have content. (cherry picked from commit 006f36d3628bf4da18fe474f470694828904c197) M +2 -1 kompareurldialog.cpp M +1 -0 libdialogpages/filespage.cpp M +7 -0 libdialogpages/filespage.h https://commits.kde.org/kompare/5f7444b061b6453aad2ede25a598cf175893eb89
(In reply to Jeremy Whiting from comment #15) > Just pushed a fix for this issue to master branch. It will be in the next > release 19.08 I believe, Missed the tag for 19.08 beta, but will be in the > RC and release. Thanks Jeremy, but the Applications/19.08 has been already created, so the commit needs to be backported (I just did it), otherwise it will miss Applications 19.08 RC.
Ah right. Thanks for doing that Luigi.
good works! Thank's! All functions working now.
*** Bug 417156 has been marked as a duplicate of this bug. ***