D28273: Fix building breeze-icons
mardelle closed this revision. mardelle added a comment. Fixed in commit https://commits.kde.org/breeze-icons/7a7cbad866bbab362b4b27e2e283c1ff94458927 REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D28273 To: mardelle, nicolasfella, ngraham Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, bruns
D28273: Fix building breeze-icons
mardelle created this revision. mardelle added a reviewer: nicolasfella. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. mardelle requested review of this revision. REVISION SUMMARY Trying to build breeze icons fails on the 24px icons generations with following message: status/22/install.svg does not have the size defined in a parse-able way After looking at it, install.svg is linked from actions/16, but it should be linked from actions/22 Patch fixes compilation REPOSITORY R266 Breeze Icons REVISION DETAIL https://phabricator.kde.org/D28273 AFFECTED FILES icons-dark/status/22/install.svg icons/status/22/install.svg To: mardelle, nicolasfella Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
Re: D24489: KAutosaveFile not respecting maximum filename length
Ouch sorry about that! Won't be able to work on it before tomorrow afternoon at best. Feel free to revert if you think it's best and I can work on an updated version... On Dec 13, 2019, 21:49, at 21:49, David Faure wrote: >dfaure added a comment. > > > It *also* broke Windows compilation: > >C:\CI\workspace\Frameworks\kcoreaddons\kf5-qt5 >WindowsMSVCQt5.13\src\lib\io\kautosavefile.cpp(79): error C2065: >'NAME_MAX': undeclared identifier > >https://build.kde.org/job/Frameworks/view/Everything%20-%20kf5-qt5/job/kcoreaddons/job/kf5-qt5%20WindowsMSVCQt5.13/ > >REPOSITORY > R244 KCoreAddons > >REVISION DETAIL > https://phabricator.kde.org/D24489 > >To: mardelle, #frameworks, dfaure, mpyne >Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, GB_2, michaelh, >ngraham, bruns
D24489: KAutosaveFile not respecting maximum filename length
mardelle added a comment. Oh sorry about that. Won't be able to work on it before sunday.. feel free to revert if you think it's best - no computer access now... and I can work on an updated patch... REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D24489 To: mardelle, #frameworks, dfaure, mpyne Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D25767: KAutoSaveFile: add a unit test to check max. filename length
mardelle added a comment. I have now committed https://phabricator.kde.org/D24489 REPOSITORY R244 KCoreAddons BRANCH l-kautosave-unittest (branched from master) REVISION DETAIL https://phabricator.kde.org/D25767 To: ahmadsamir, #frameworks, mpyne, dfaure Cc: mardelle, dhaumann, dfaure, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D24489: KAutosaveFile not respecting maximum filename length
mardelle marked 3 inline comments as done. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D24489 To: mardelle, #frameworks, dfaure, mpyne Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D24489: KAutosaveFile not respecting maximum filename length
mardelle updated this revision to Diff 71081. mardelle added a comment. Update patch according to discussion. extractManagedFilePath will be broken in case of long truncated path but that has always been the case... REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24489?vs=67489=71081 REVISION DETAIL https://phabricator.kde.org/D24489 AFFECTED FILES src/lib/io/kautosavefile.cpp To: mardelle, #frameworks, dfaure, mpyne Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D24489: KAutosaveFile not respecting maximum filename length
mardelle added a comment. Oh no don't misunderstand me. I am very glad that someone else stepped up! I have more than enough work on my plate with Kdenlive so please help :) Hopefully David can give us some hints about the best way to move on! REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D24489 To: mardelle, #frameworks, dfaure, mpyne Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D24489: KAutosaveFile not respecting maximum filename length
mardelle added a comment.
The unittest is in another diff because it's a different author I guess. I
can process the comments but looking closer I found 2 other important issues in
this class:
1. When using KAutoSaveFile::staleFiles(filename) to check if there is an
existing stale file for a document, we use the function
KAutoSaveFile::extractManagedFilePath
This function compares the orginal document path one reconstructed from the
lock file name. However this logic seems flawed since the lock file name uses a
trimmed path in some cases it is impossible to rebuild the original document's
path from it.
Instead I would propose to replace extractManagedFilePath with a new
function, comparing filename, then paths like:
bool staleMatchesManaged(const QString& staleFileName, const QString
managedFile)
{
const QStringRef sep = staleFileName.rightRef(3);
int sepPos = staleFileName.indexOf(sep);
if (QFileInfo(managedFile).fileName() !=
staleFileName.leftRef(sepPos).toString()) {
// File names don't match
return false;
}
int pathPos = staleFileName.indexOf(QChar::fromLatin1('_'), sepPos);
const QByteArray encodedPath = staleFileName.midRef(pathPos+1,
staleFileName.length()-pathPos-1-KAutoSaveFilePrivate::NamePadding).toLatin1();
const QString sourcePathStart = QUrl::fromPercentEncoding(encodedPath);
return
QFileInfo(managedFile).absolutePath().startsWith(sourcePathStart);
}
2. The QLockFile class used in KAutoSaveFile creates a temporary file to
manage locking:
> QLockFile rmlock(d->fileName + QLatin1String(".rmlock"));
https://github.com/qt/qtbase/blob/dev/src/corelib/io/qlockfile.cpp#L259
This means that in our situation where we have a filename that already has
the maximum length, trying to lock will always fail, preventing usage of the
autosave file.
Easier solution is probably to make maximum filename in KAutoSave
File::tempFileName() a bit shorter.
Thoughts? Should I prepare separate patches ? But changing the fileName
encoding as suggested:
> Simpler than toPercentEncoding: use QUrl::fileName(QUrl::FullyEncoded).
Might break more the path recovery method extractManagedFilePath..
REPOSITORY
R244 KCoreAddons
REVISION DETAIL
https://phabricator.kde.org/D24489
To: mardelle, #frameworks, dfaure, mpyne
Cc: ahmadsamir, kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D24489: KAutosaveFile not respecting maximum filename length
mardelle added a reviewer: dfaure. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D24489 To: mardelle, #frameworks, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D24489: KAutosaveFile not respecting maximum filename length
mardelle created this revision. mardelle added a reviewer: Frameworks. mardelle added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. mardelle requested review of this revision. REVISION SUMMARY There are 2 different issues in current code regarding maximum filename length: 1- We use FILENAME_MAX which is defined as 4096, while most filesystems have a max length of 256. Replacing FILENAME_MAX with NAME_MAX fixes this first problem (could not test on Windows if it works) 2- We are calculating the maximum length on the UTF-8 string, then encoding to percent encoding. This can result in longer strings since single characters will be replaced by a percent string. So in some situations, we end up with a string longer than allowed. Doing the percent encoding before length calculation fixes the problem. This fixes the follwing bug: https://bugs.kde.org/show_bug.cgi?id=412519 TEST PLAN Bug is fixed with the changes REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D24489 AFFECTED FILES src/lib/io/kautosavefile.cpp To: mardelle, #frameworks Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns
D7954: Fix repaint loop in KToolBar
mardelle abandoned this revision. REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D7954 To: mardelle, #frameworks, ilic, dfaure Cc: michaelh
D8084: KAutoSaveFile breaks if source file name contains a space!
This revision was automatically updated to reflect the committed changes. Closed by commit R244:8ed107304694: Fix KAutoSave bug on file with white space in it (authored by mardelle). REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8084?vs=21868=21898 REVISION DETAIL https://phabricator.kde.org/D8084 AFFECTED FILES autotests/kautosavefiletest.cpp src/lib/io/kautosavefile.cpp To: mardelle, #frameworks, shaforostoff, dfaure Cc: dfaure, ngraham, cfeck, ltoscano
D8084: KAutoSaveFile breaks if source file name contains a space!
mardelle marked 2 inline comments as done. REPOSITORY R244 KCoreAddons REVISION DETAIL https://phabricator.kde.org/D8084 To: mardelle, #frameworks, shaforostoff Cc: dfaure, ngraham, cfeck, ltoscano
D8084: KAutoSaveFile breaks if source file name contains a space!
mardelle updated this revision to Diff 21868. REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8084?vs=20216=21868 REVISION DETAIL https://phabricator.kde.org/D8084 AFFECTED FILES autotests/kautosavefiletest.cpp src/lib/io/kautosavefile.cpp To: mardelle, #frameworks, shaforostoff Cc: dfaure, ngraham, cfeck, ltoscano
D8060: allow to set a custom palette instead of colorSets
mardelle added a comment. Thanks I can confirm it is fixed with last commit. REPOSITORY R302 KIconThemes REVISION DETAIL https://phabricator.kde.org/D8060 To: mart, dfaure, #frameworks, rikmills, davidedmundson Cc: mardelle, davidedmundson, broulik, cfeck, #frameworks
D8060: allow to set a custom palette instead of colorSets
mardelle added a comment. Just to let you know, these last 2 commits to KIconThemes break the icon coloring in existing apps like Kdenlive and KDevelop. Previously, in a KXmlGuiWindow, doing: QPalette plt = KColorScheme::createApplicationPalette(config); setPalette(plt); qApp->setPalette(palette()); Made the icon theme adapt to the palette. The recent commits break this and it is now required to add : KIconLoader::global()->setCustomPalette(plt); To make icon color theming work in existing apps that allow color theme switch. Regression can be easily tested with KDevelop or Kdenlive using the "Color theme" menu from Settings REPOSITORY R302 KIconThemes REVISION DETAIL https://phabricator.kde.org/D8060 To: mart, dfaure, #frameworks, rikmills, davidedmundson Cc: mardelle, davidedmundson, broulik, cfeck, #frameworks
D7954: Fix repaint loop in KToolBar
mardelle added a comment. So did some more tests, and the loop is caused by the tb->settext() call. The QAbstractButton setText method checks if : d->text == text But d->text contains the & accel marker and not text, so we end up comparing 'ren' with 'render' on paint, thus the loop. I will review & update my patch tomorrow REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D7954 To: mardelle, #frameworks, ilic, dfaure
D8084: KAutoSaveFile breaks if source file name contains a space!
mardelle updated this revision to Diff 20216. mardelle added a comment. Added test to check stale file is correctly found REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D8084?vs=20180=20216 REVISION DETAIL https://phabricator.kde.org/D8084 AFFECTED FILES autotests/kautosavefiletest.cpp src/lib/io/kautosavefile.cpp To: mardelle, #frameworks, shaforostoff Cc: ltoscano
D8084: KAutoSaveFile breaks if source file name contains a space!
mardelle created this revision.
mardelle added reviewers: Frameworks, shaforostoff.
Restricted Application added a project: Frameworks.
REVISION SUMMARY
KAutoSaveFile does not correctly handle simple characters like spaces in file
names!!!
When creating a stale file (backup file) , to determine the file name it uses:
in tempFileName(), line 83:
return QString::fromLatin1(QUrl::toPercentEncoding(name).constData());
So the filename is encoded using percent encoding. But when checking for an
existing backup file, it does:
in extractManagedFilePath, line 180:
managedFileName.setPath(QUrl::fromPercentEncoding(encodedPath) +
QLatin1Char('/') + QFileInfo(staleFileName.left(sepPos)).fileName());
So the path part is correctly restored from percent encoding, but the
filename part is not decoded.
So we end up comparing "my file" with "my%20file" and the stale file is not
correctly identified!
TEST PLAN
Project files with space in their name in Kdenlive now have crash recovery
working
REPOSITORY
R244 KCoreAddons
REVISION DETAIL
https://phabricator.kde.org/D8084
AFFECTED FILES
src/lib/io/kautosavefile.cpp
To: mardelle, #frameworks, shaforostoff
D7964: KAcceleratorManager: set icon text on actions to remove CJK markers
mardelle added a comment. Not sure how to test this accelerator thing properly for a review but I would really love to get rid of the ktoolbar hack . Can we get this patch in time for frameworks 5.39 release, or should I commit my workaround https://phabricator.kde.org/D7954 as a temporary fix? Thanks REVISION DETAIL https://phabricator.kde.org/D7964 To: dfaure, mardelle, ilic, sandsmark Cc: #frameworks
D7954: Fix repaint loop in KToolBar
mardelle created this revision. mardelle added reviewers: Frameworks, ilic, dfaure. Restricted Application added a project: Frameworks. REVISION SUMMARY Patch is based on https://git.reviewboard.kde.org/r/128421/ This issue - endless repaint loop when a QToolButton is embedded in a KToolBar - causes major battery and performance drain. Just opening an application causes a 15-20% CPU doing nothing. With the patch, CPU usage goes down to 0%. Bugs: https://bugs.kde.org/show_bug.cgi?id=365050 https://bugs.kde.org/show_bug.cgi?id=377859 REPOSITORY R263 KXmlGui REVISION DETAIL https://phabricator.kde.org/D7954 AFFECTED FILES src/ktoolbar.cpp To: mardelle, #frameworks, ilic, dfaure
Re: Review Request 129986: KUrlRequester does not allow proper save filedialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129986/ --- (Updated March 5, 2017, 9:04 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Changes --- Submitted with commit 143fbd2cd9d5698420ec246f03a4aea24d9d33b3 by Jean-Baptiste Mardelle to branch master. Bugs: 371685 https://bugs.kde.org/show_bug.cgi?id=371685 Repository: kio Description --- Using a KUrlRequester to select a file to save is not currently working. The file dialog is always opening in "open" mode, never in "save" mode. My patch adds a method to call setAcceptMode on the file dialog. Some users reported that the current behavior completely breaks the functionnality on some platforms(Gnome), making it impossible to select a non existing file. Diffs - src/widgets/kurlrequester.h 51c1259 src/widgets/kurlrequester.cpp 62e1fea Diff: https://git.reviewboard.kde.org/r/129986/diff/ Testing --- Tested locally, the dialog opening from the KUrlRequester is now a proper "save" dialog Thanks, Jean-Baptiste Mardelle
Re: Review Request 129986: KUrlRequester does not allow proper save filedialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129986/ --- (Updated March 5, 2017, 8 p.m.) Review request for KDE Frameworks and David Faure. Changes --- Added @since 5.33, make applyFileMode static Bugs: 371685 https://bugs.kde.org/show_bug.cgi?id=371685 Repository: kio Description --- Using a KUrlRequester to select a file to save is not currently working. The file dialog is always opening in "open" mode, never in "save" mode. My patch adds a method to call setAcceptMode on the file dialog. Some users reported that the current behavior completely breaks the functionnality on some platforms(Gnome), making it impossible to select a non existing file. Diffs (updated) - src/widgets/kurlrequester.h 51c1259 src/widgets/kurlrequester.cpp 62e1fea Diff: https://git.reviewboard.kde.org/r/129986/diff/ Testing --- Tested locally, the dialog opening from the KUrlRequester is now a proper "save" dialog Thanks, Jean-Baptiste Mardelle
Review Request 129986: KUrlRequester does not allow proper save filedialog
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129986/ --- Review request for KDE Frameworks and David Faure. Bugs: 371685 https://bugs.kde.org/show_bug.cgi?id=371685 Repository: kio Description --- Using a KUrlRequester to select a file to save is not currently working. The file dialog is always opening in "open" mode, never in "save" mode. My patch adds a method to call setAcceptMode on the file dialog. Some users reported that the current behavior completely breaks the functionnality on some platforms(Gnome), making it impossible to select a non existing file. Diffs - src/widgets/kurlrequester.h 51c1259 src/widgets/kurlrequester.cpp 62e1fea Diff: https://git.reviewboard.kde.org/r/129986/diff/ Testing --- Tested locally, the dialog opening from the KUrlRequester is now a proper "save" dialog Thanks, Jean-Baptiste Mardelle
Re: Review Request 129607: Display Application version in About dialog header
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129607/ --- (Updated Dec. 9, 2016, 7:08 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, KDE Usability and Sebastian Kügler. Changes --- Submitted with commit 3d28036b0ed33ef077c7df6ba30a6d4ceac61884 by Jean-Baptiste Mardelle to branch master. Repository: kxmlgui Description --- Last year, a change in kaboutapplicationdialog (review 124133) moved the application version in a separate tab. However for applications, it is really annoying (several Kdenlive users complained and I fully agree) to not have this information clearly displayed as soon as the About dialog is displayed. I understand the interest of having a separate version tab displaying the various underlying libraries used, but I propose to display again the application version in the About dialog header (see screenshot). Diffs - src/kaboutapplicationdialog.cpp 156410e Diff: https://git.reviewboard.kde.org/r/129607/diff/ Testing --- Reverts a recent change, tested and works. File Attachments About dialog with version https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/c02f4767-2a74-4c25-8599-de410678867e__about.png Updated patch https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/ee13cb47-2162-4be7-8255-3dce7f470c2b__about2.png renamed to libraries https://git.reviewboard.kde.org/media/uploaded/files/2016/12/07/f01ed0c3-1391-48cf-a153-a177d9a7b54a__about3.png Thanks, Jean-Baptiste Mardelle
Re: Review Request 129607: Display Application version in About dialog header
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129607/ --- (Updated Dec. 7, 2016, 11:31 a.m.) Review request for KDE Frameworks, KDE Usability and Sebastian Kügler. Repository: kxmlgui Description --- Last year, a change in kaboutapplicationdialog (review 124133) moved the application version in a separate tab. However for applications, it is really annoying (several Kdenlive users complained and I fully agree) to not have this information clearly displayed as soon as the About dialog is displayed. I understand the interest of having a separate version tab displaying the various underlying libraries used, but I propose to display again the application version in the About dialog header (see screenshot). Diffs - src/kaboutapplicationdialog.cpp 156410e Diff: https://git.reviewboard.kde.org/r/129607/diff/ Testing --- Reverts a recent change, tested and works. File Attachments (updated) About dialog with version https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/c02f4767-2a74-4c25-8599-de410678867e__about.png Updated patch https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/ee13cb47-2162-4be7-8255-3dce7f470c2b__about2.png renamed to libraries https://git.reviewboard.kde.org/media/uploaded/files/2016/12/07/f01ed0c3-1391-48cf-a153-a177d9a7b54a__about3.png Thanks, Jean-Baptiste Mardelle
Re: Review Request 129607: Display Application version in About dialog header
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129607/ --- (Updated Dec. 7, 2016, 11:30 a.m.) Review request for KDE Frameworks, KDE Usability and Sebastian Kügler. Changes --- Renamed tab to "Libraries", removed "Using" in tab text Repository: kxmlgui Description --- Last year, a change in kaboutapplicationdialog (review 124133) moved the application version in a separate tab. However for applications, it is really annoying (several Kdenlive users complained and I fully agree) to not have this information clearly displayed as soon as the About dialog is displayed. I understand the interest of having a separate version tab displaying the various underlying libraries used, but I propose to display again the application version in the About dialog header (see screenshot). Diffs (updated) - src/kaboutapplicationdialog.cpp 156410e Diff: https://git.reviewboard.kde.org/r/129607/diff/ Testing --- Reverts a recent change, tested and works. File Attachments About dialog with version https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/c02f4767-2a74-4c25-8599-de410678867e__about.png Updated patch https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/ee13cb47-2162-4be7-8255-3dce7f470c2b__about2.png Thanks, Jean-Baptiste Mardelle
Re: Review Request 129607: Display Application version in About dialog header
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129607/ --- (Updated Dec. 3, 2016, 1:39 p.m.) Review request for KDE Frameworks, KDE Usability and Sebastian Kügler. Repository: kxmlgui Description --- Last year, a change in kaboutapplicationdialog (review 124133) moved the application version in a separate tab. However for applications, it is really annoying (several Kdenlive users complained and I fully agree) to not have this information clearly displayed as soon as the About dialog is displayed. I understand the interest of having a separate version tab displaying the various underlying libraries used, but I propose to display again the application version in the About dialog header (see screenshot). Diffs - src/kaboutapplicationdialog.cpp 156410e Diff: https://git.reviewboard.kde.org/r/129607/diff/ Testing --- Reverts a recent change, tested and works. File Attachments (updated) About dialog with version https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/c02f4767-2a74-4c25-8599-de410678867e__about.png Updated patch https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/ee13cb47-2162-4be7-8255-3dce7f470c2b__about2.png Thanks, Jean-Baptiste Mardelle
Re: Review Request 129607: Display Application version in About dialog header
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129607/ --- (Updated Dec. 3, 2016, 1:39 p.m.) Review request for KDE Frameworks, KDE Usability and Sebastian Kügler. Changes --- Rename Version tab to "Environment", remove application version from this tab Repository: kxmlgui Description --- Last year, a change in kaboutapplicationdialog (review 124133) moved the application version in a separate tab. However for applications, it is really annoying (several Kdenlive users complained and I fully agree) to not have this information clearly displayed as soon as the About dialog is displayed. I understand the interest of having a separate version tab displaying the various underlying libraries used, but I propose to display again the application version in the About dialog header (see screenshot). Diffs (updated) - src/kaboutapplicationdialog.cpp 156410e Diff: https://git.reviewboard.kde.org/r/129607/diff/ Testing --- Reverts a recent change, tested and works. File Attachments About dialog with version https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/c02f4767-2a74-4c25-8599-de410678867e__about.png Thanks, Jean-Baptiste Mardelle
Review Request 129607: Display Application version in About dialog header
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129607/ --- Review request for KDE Frameworks. Repository: kxmlgui Description --- Last year, a change in kaboutapplicationdialog (review 124133) moved the application version in a separate tab. However for applications, it is really annoying (several Kdenlive users complained and I fully agree) to not have this information clearly displayed as soon as the About dialog is displayed. I understand the interest of having a separate version tab displaying the various underlying libraries used, but I propose to display again the application version in the About dialog header (see screenshot). Diffs - src/kaboutapplicationdialog.cpp 156410e Diff: https://git.reviewboard.kde.org/r/129607/diff/ Testing --- Reverts a recent change, tested and works. File Attachments About dialog with version https://git.reviewboard.kde.org/media/uploaded/files/2016/12/03/c02f4767-2a74-4c25-8599-de410678867e__about.png Thanks, Jean-Baptiste Mardelle
Re: Review Request 126184: Editing toolbars in KXmlGuiWindow sometimes deletes all UI plugged actions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126184/ --- (Updated March 5, 2016, 8:25 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Bugs: 352882 https://bugs.kde.org/show_bug.cgi?id=352882 Repository: kxmlgui Description --- To Reproduce: in a KXmlGuiWindow, open the Configure Toolbars dialog. 1 - Change the main toolbar setting. 2 - Click Apply, the ui is rebuild, and the newToolBarConfig signal is emitted, allowing main app to re-plug its dynamic actions 3 - Click Ok, the ui is rebuild but the signal is not emitted, so app cannot re-plug actions, and they are lost. The problem only happens if you click "apply" and then "ok". This is due to the fact that when Ok is clicked, the ui is rebuild (m_widget->save triggers ui rebuild), but signal is not emitted. My solution is to rebuild ui only if something changed when clicking "ok". Diffs - src/kedittoolbar.cpp b6842f6 src/kedittoolbar_p.h 73152ef Diff: https://git.reviewboard.kde.org/r/126184/diff/ Testing --- Tested, fixes the reported problem. Thanks, Jean-Baptiste Mardelle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 126184: Editing toolbars in KXmlGuiWindow sometimes deletes all UI plugged actions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126184/ --- (Updated March 5, 2016, 8:01 p.m.) Review request for KDE Frameworks and David Faure. Bugs: 352882 https://bugs.kde.org/show_bug.cgi?id=352882 Repository: kxmlgui Description --- To Reproduce: in a KXmlGuiWindow, open the Configure Toolbars dialog. 1 - Change the main toolbar setting. 2 - Click Apply, the ui is rebuild, and the newToolBarConfig signal is emitted, allowing main app to re-plug its dynamic actions 3 - Click Ok, the ui is rebuild but the signal is not emitted, so app cannot re-plug actions, and they are lost. The problem only happens if you click "apply" and then "ok". This is due to the fact that when Ok is clicked, the ui is rebuild (m_widget->save triggers ui rebuild), but signal is not emitted. My solution is to rebuild ui only if something changed when clicking "ok". Diffs (updated) - src/kedittoolbar.cpp b6842f6 src/kedittoolbar_p.h 73152ef Diff: https://git.reviewboard.kde.org/r/126184/diff/ Testing --- Tested, fixes the reported problem. Thanks, Jean-Baptiste Mardelle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 126184: Editing toolbars in KXmlGuiWindow sometimes deletes all UI plugged actions
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/126184/ --- Review request for KDE Frameworks and David Faure. Bugs: 352882 https://bugs.kde.org/show_bug.cgi?id=352882 Repository: kxmlgui Description --- To Reproduce: in a KXmlGuiWindow, open the Configure Toolbars dialog. 1 - Change the main toolbar setting. 2 - Click Apply, the ui is rebuild, and the newToolBarConfig signal is emitted, allowing main app to re-plug its dynamic actions 3 - Click Ok, the ui is rebuild but the signal is not emitted, so app cannot re-plug actions, and they are lost. The problem only happens if you click "apply" and then "ok". This is due to the fact that when Ok is clicked, the ui is rebuild (m_widget->save triggers ui rebuild), but signal is not emitted. My solution is to rebuild ui only if something changed when clicking "ok". Diffs - src/kedittoolbar.cpp ba4ba0f Diff: https://git.reviewboard.kde.org/r/126184/diff/ Testing --- Tested, fixes the reported problem. Thanks, Jean-Baptiste Mardelle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125208: Fixes file dialog randomly not showing up with frameworkintegration
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125208/#review86148 --- I can confirm that I cannot reproduce the problem in Kdenlive with this patch. I would really like to have it included in KDE Frameworks 5.15 because having our apps randomly freeze is a really big problem. - Jean-Baptiste Mardelle On Sept. 13, 2015, 12:18 a.m., Xuetian Weng wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125208/ > --- > > (Updated Sept. 13, 2015, 12:18 a.m.) > > > Review request for KDE Frameworks, David Faure and Jean-Baptiste Mardelle. > > > Bugs: 350758 > https://bugs.kde.org/show_bug.cgi?id=350758 > > > Repository: frameworkintegration > > > Description > --- > > 1. The directly reason of 350758 is > https://bugreports.qt.io/browse/QTBUG-48248, which seems to be a Qt problem. > See the code example. One possible to avoid this is to remove the > m_dialog->hide(). > > 2. Why hide() is needed in the first place? > If one runs dialog.show() and dialog.exec(), it should works. So there is > something happened in between the calls to > KDEPlatformFileDialogHelper::show() and KDEPlatformFileDialogHelper::exec(). > > The real reason is the platform dialog helper doesn't expect that user may > use "Qt" dialog to implement it. > https://github.com/qtproject/qtbase/blob/5bfac9d653357c906946563b9494d7ae69cdad92/src/widgets/dialogs/qfiledialog.cpp#L845 > here it sets Qt::WA_DontShowOnScreen on the actual dialog. > > https://github.com/qtproject/qtbase/blob/5bfac9d653357c906946563b9494d7ae69cdad92/src/widgets/dialogs/qfiledialog.cpp#L868 > > and call QDialog::setVisible() here > > https://github.com/qtproject/qtbase/blob/17d6b2d1f02e5f679008d97036befd713025a0f2/src/widgets/dialogs/qdialog.cpp#L713 > > Thus it will by pass the check, and QDialog will actually show an invisible > qdialog. I assume https://git.reviewboard.kde.org/r/123335/ tries to solve > this issue by "steal" the focus from that invisible dialog by hide our dialog > and show it again. > > It makes some sense for Qt with "real" native dialog which is not controlled > by Qt, because this invisble dialog helps Qt to aware that there's a modal > dialog, but doesn't work for our case since our dialog is also a QDialog. > > 3. To avoid calling hide() in exec() > I'd rather to see that KDEPlatformFileDialogHelper::show() is not called in > QDialog::exec(), but that's not gonna happen anytime soon. So here I used a > trick with QTimer to delegate the call to show() to next event. > > I uses QTimer instead of QMetaObject::invoke here, because we can discard the > "m_dialog->show()" if hide() or exec() is called immediately. (Actually we > don't need to discard the one in exec(), but we can save a call to > m_dialog->show() if we discard it.) > > Before this change, the calling sequence is > > m_dialog->show(); > The dummy dialog setVisible(true); > m_dialog->hide(); > m_dialog->exec(); > > After this change, it becomes > The dummy dialog setVisible(true); > m_dialog->exec(); > > 4. Required changes to autotest > QTest::qWaitForWindowExposed(fw->window()) is added to some necessary places. > > > Diffs > - > > autotests/kfiledialog_unittest.cpp 0d4c816 > autotests/kfiledialogqml_unittest.cpp f805ef2 > src/platformtheme/kdeplatformfiledialogbase.cpp 8e696bd > src/platformtheme/kdeplatformfiledialogbase_p.h 5936dfb > src/platformtheme/kdeplatformfiledialoghelper.h dfbbed1 > src/platformtheme/kdeplatformfiledialoghelper.cpp 94f2059 > > Diff: https://git.reviewboard.kde.org/r/125208/diff/ > > > Testing > --- > > not able to reproduce the bug. > > > Thanks, > > Xuetian Weng > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125208: Workaround bug 350758
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125208/#review85297 --- I can confirm that this works, fantastic! I have not looked at the code but unless someone comes up quickly with a better fix, this workaround is really needed by our users who are very frustrated by invisible open/save dialog - Jean-Baptiste Mardelle On Sept. 12, 2015, 9:40 p.m., Xuetian Weng wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125208/ > --- > > (Updated Sept. 12, 2015, 9:40 p.m.) > > > Review request for KDE Frameworks, David Faure and Jean-Baptiste Mardelle. > > > Bugs: 350758 > https://bugs.kde.org/show_bug.cgi?id=350758 > > > Repository: frameworkintegration > > > Description > --- > > 1. The reason of 350758: https://bugreports.qt.io/browse/QTBUG-48248 , I just > tried to reproduce it with pure Qt code. If a dialog called against show, > hide, and exec one immediately after another, the dialog may not show up. > > 2. Why hide() is needed in the first place? > If one runs dialog.show() and dialog.exec(), it usually works. So there is > something happened in between KDEPlatformFileDialogHelper::show() and > KDEPlatformFileDialogHelper::exec(). > > The real reason is the platform dialog helper doesn't expect that user may > use "Qt" dialog to implement it. > https://github.com/qtproject/qtbase/blob/5bfac9d653357c906946563b9494d7ae69cdad92/src/widgets/dialogs/qfiledialog.cpp#L845 > here it sets Qt::WA_DontShowOnScreen on the actual dialog. > > https://github.com/qtproject/qtbase/blob/5bfac9d653357c906946563b9494d7ae69cdad92/src/widgets/dialogs/qfiledialog.cpp#L868 > > and call QDialog::setVisible() here > > https://github.com/qtproject/qtbase/blob/17d6b2d1f02e5f679008d97036befd713025a0f2/src/widgets/dialogs/qdialog.cpp#L713 > > Thus it will by pass the first check, and QDialog will actually show an > invisible qdialog with it. I assume https://git.reviewboard.kde.org/r/123335/ > tries to solve this issue by "steal" the focus from that invisible dialog by > hide it first. > > It makes some sense for Qt with "real" native dialog, because this invisble > dialog helps Qt to aware that there's a modal dialog, but doesn't work for > our case. > > 3. To avoid calling hide() in exec() > I'd rather to see that KDEPlatformFileDialogHelper::show() is not called in > QDialog::exec(), but that's not gonna happen. So here I used a trick with > QTimer to delegate the show to next event when calling to > KDEPlatformFileDialogHelper::show(). > > I uses QTimer instead of QMetaObject::invoke here, because we can discard the > "m_dialog->show()" if hide() or exec() is called immediately. (Actually we > don't need to discard the one in exec(), but we can save a call to > m_dialog->show() if we discard it.) > > Before this change, the calling sequence on m_dialog is > > m_dialog->show(); > The dummy dialog setVisible(true); > m_dialog->hide(); > m_dialog->exec(); > > After this change, it becomes > The dummy dialog setVisible(true); > m_dialog->exec(); > > 4. Required changes to autotest > QTest::qWaitForWindowExposed(fw->window()) is added to some necessary places. > > > Diffs > - > > autotests/kfiledialog_unittest.cpp 0d4c816 > autotests/kfiledialogqml_unittest.cpp f805ef2 > src/platformtheme/kdeplatformfiledialogbase.cpp 8e696bd > src/platformtheme/kdeplatformfiledialogbase_p.h 5936dfb > src/platformtheme/kdeplatformfiledialoghelper.h dfbbed1 > src/platformtheme/kdeplatformfiledialoghelper.cpp 94f2059 > > Diff: https://git.reviewboard.kde.org/r/125208/diff/ > > > Testing > --- > > not able to reproduce the bug. > > > Thanks, > > Xuetian Weng > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125154: Workaround 350758 with same hack in 494584ee43c20948044eb80012b69f65920b33f4
> On Sept. 11, 2015, 10:02 a.m., Luca Beltrame wrote: > > +1 > > Jean-Baptiste Mardelle wrote: > Kdenlive is also affected by this issue, as described in bug #346413 > Pressing "Esc" allows to dismiss the invisible file dialog and regain > control of the app. > However I tested the proposed patch and it does not solve the problem for > me... > > Xuetian Weng wrote: > Hi, you did remind me that I also hit this on kdenlive. But it seems that > this does fix for kdenlive. I tried ctrl+o dialog and was not able to > reproduce it. > > Can you confirm that you install your new frameworkintegration to the > correct path? Hi, Yes I made sure to install in the correct place, even added some debug output to make sure I was using that file. However I am using Kubuntu packages for all other frameworks (version 5.13) - don't know if therer are other parts of frameworks recent changes that might help.. However if you have Kdenlive, the most reliable way to reproduce is form the "Project" menu, select "Add Slideshow Clip". Then you get a dialog with a "Folder" KUrlRequester. Try clicking on the KUrlRequester toolbutton that should bring the file dialog. If it works, try clicking alternatively the "Mimetype" and "File Pattern" radio buttons, then click again on the KUrlRequester. That way, I always manage to trigger the bug... Thanks for looking into this by the way! - Jean-Baptiste --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125154/#review85165 --- On Sept. 11, 2015, 8:28 a.m., Xuetian Weng wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125154/ > --- > > (Updated Sept. 11, 2015, 8:28 a.m.) > > > Review request for KDE Frameworks and Lukáš Tinkl. > > > Bugs: 350758 > https://bugs.kde.org/show_bug.cgi?id=350758 > > > Repository: frameworkintegration > > > Description > --- > > In https://bugs.kde.org/show_bug.cgi?id=334963 Cjacker proposed a patch. > > Which seems makes some sense because same situation in exec() may also happen > to show(). > > > Diffs > - > > src/platformtheme/kdeplatformfiledialoghelper.cpp 94f2059 > > Diff: https://git.reviewboard.kde.org/r/125154/diff/ > > > Testing > --- > > So far I'm not able to reproduce 350758 for now. > I uses lokalize merge file window to test since it's the easiest one for me > to reproduce 350758. > > > Thanks, > > Xuetian Weng > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125154: Workaround 350758 with same hack in 494584ee43c20948044eb80012b69f65920b33f4
> On Sept. 11, 2015, 10:02 a.m., Luca Beltrame wrote: > > +1 Kdenlive is also affected by this issue, as described in bug #346413 Pressing "Esc" allows to dismiss the invisible file dialog and regain control of the app. However I tested the proposed patch and it does not solve the problem for me... - Jean-Baptiste --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125154/#review85165 --- On Sept. 11, 2015, 8:28 a.m., Xuetian Weng wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125154/ > --- > > (Updated Sept. 11, 2015, 8:28 a.m.) > > > Review request for KDE Frameworks and Lukáš Tinkl. > > > Bugs: 350758 > https://bugs.kde.org/show_bug.cgi?id=350758 > > > Repository: frameworkintegration > > > Description > --- > > In https://bugs.kde.org/show_bug.cgi?id=334963 Cjacker proposed a patch. > > Which seems makes some sense because same situation in exec() may also happen > to show(). > > > Diffs > - > > src/platformtheme/kdeplatformfiledialoghelper.cpp 94f2059 > > Diff: https://git.reviewboard.kde.org/r/125154/diff/ > > > Testing > --- > > So far I'm not able to reproduce 350758 for now. > I uses lokalize merge file window to test since it's the easiest one for me > to reproduce 350758. > > > Thanks, > > Xuetian Weng > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125051: KFileWidget: multiple files with ":" in filename recognized as directories
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125051/ --- (Updated Sept. 7, 2015, 7:48 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Changes --- Submitted with commit b684fa02ec7bd6b791682aaeb76398ce2cc87b03 by David Faure to branch master. Bugs: 350696 https://bugs.kde.org/show_bug.cgi?id=350696 Repository: kio Description --- QUrl::toDisplayString removes password info by default. When using local files with ":" inside, toDisplayString returns empty filename Diffs - src/filewidgets/kfilewidget.cpp dc3c1f4 Diff: https://git.reviewboard.kde.org/r/125051/diff/ Testing --- Patch fixes issue #350696, tested on my system, but maybe there is a better way to fix it ? Thanks, Jean-Baptiste Mardelle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125051: KFileWidget: multiple files with ":" in filename recognized as directories
> On Sept. 6, 2015, 9:55 p.m., David Faure wrote: > > It's not your fault, but I still don't like this code (with or without > > these changes). It makes no sense to me ;) > > > > What I can't figure out from reading it is: why would relativePathOrUrl > > ever return a URL in this code path? > > We're calling it with the topMostUrl as argument, so it should always > > return a relative path. Right? > > Unless of course the selected URLs don't have a common top most url, but I > > think this case is not handled and very very hard to come up with anyway > > (how would one multi-select a local file and a file over FTP? I guess > > that's not possible). > > > > So then assuming we're dealing with a local path, why are we putting that > > into a QUrl, to then later extract it again using > > url.toDisplayString(QUrl::PreferLocalFile)? > > Why not directly put the relative path into "stringlist"? > > Do you want to try something like that? > > http://www.davidfaure.fr/2015/filewidgets_untested.diff Hi David. I must admit I don't understand all the logic behind the original code. However, your patch proposal fixes my bug, so it's perfect for me if you want to commit it. - Jean-Baptiste --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125051/#review84914 --- On Sept. 4, 2015, 9:32 p.m., Jean-Baptiste Mardelle wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125051/ > --- > > (Updated Sept. 4, 2015, 9:32 p.m.) > > > Review request for KDE Frameworks and David Faure. > > > Bugs: 350696 > https://bugs.kde.org/show_bug.cgi?id=350696 > > > Repository: kio > > > Description > --- > > QUrl::toDisplayString removes password info by default. When using local > files with ":" inside, toDisplayString returns empty filename > > > Diffs > - > > src/filewidgets/kfilewidget.cpp dc3c1f4 > > Diff: https://git.reviewboard.kde.org/r/125051/diff/ > > > Testing > --- > > Patch fixes issue #350696, tested on my system, but maybe there is a better > way to fix it ? > > > Thanks, > > Jean-Baptiste Mardelle > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125051: KFileWidget: multiple files with ":" in filename recognized as directories
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125051/ --- (Updated Sept. 4, 2015, 8:29 p.m.) Review request for KDE Frameworks and David Faure. Bugs: 350696 https://bugs.kde.org/show_bug.cgi?id=350696 Repository: kio Description --- QUrl::toDisplayString removes password info by default. When using local files with ":" inside, toDisplayString returns empty filename Diffs (updated) - src/filewidgets/kfilewidget.cpp dc3c1f4 Diff: https://git.reviewboard.kde.org/r/125051/diff/ Testing --- Patch fixes issue #350696, tested on my system, but maybe there is a better way to fix it ? Thanks, Jean-Baptiste Mardelle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125051: KFileWidget: multiple files with ":" in filename recognized as directories
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125051/ --- (Updated Sept. 4, 2015, 9:32 p.m.) Review request for KDE Frameworks and David Faure. Changes --- Improved patch, do not use path() Bugs: 350696 https://bugs.kde.org/show_bug.cgi?id=350696 Repository: kio Description --- QUrl::toDisplayString removes password info by default. When using local files with ":" inside, toDisplayString returns empty filename Diffs (updated) - src/filewidgets/kfilewidget.cpp dc3c1f4 Diff: https://git.reviewboard.kde.org/r/125051/diff/ Testing --- Patch fixes issue #350696, tested on my system, but maybe there is a better way to fix it ? Thanks, Jean-Baptiste Mardelle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 125051: KFileWidget: multiple files with ":" in filename recognized as directories
> On Sept. 4, 2015, 8:59 p.m., David Faure wrote: > > path() is wrong for local files on Windows, it should be toLocalFile() > > instead. > > > > If the use of local paths should depend on the mode, like in your patch, > > then just use toLocalFile() instead of path(). > > If the use of local paths should depend on whether the URL is local or > > remote, use toDisplayString(QUrl::PreferLocalFile). Thanks for the quick review. In fact, the bug was a 2 parts issue, first problem was a few lines above by creating local urls with QUrl(String). Updated patch attached. - Jean-Baptiste --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125051/#review84856 --- On Sept. 4, 2015, 9:32 p.m., Jean-Baptiste Mardelle wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/125051/ > --- > > (Updated Sept. 4, 2015, 9:32 p.m.) > > > Review request for KDE Frameworks and David Faure. > > > Bugs: 350696 > https://bugs.kde.org/show_bug.cgi?id=350696 > > > Repository: kio > > > Description > --- > > QUrl::toDisplayString removes password info by default. When using local > files with ":" inside, toDisplayString returns empty filename > > > Diffs > - > > src/filewidgets/kfilewidget.cpp dc3c1f4 > > Diff: https://git.reviewboard.kde.org/r/125051/diff/ > > > Testing > --- > > Patch fixes issue #350696, tested on my system, but maybe there is a better > way to fix it ? > > > Thanks, > > Jean-Baptiste Mardelle > > ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 125051: KFileWidget: multiple files with ":" in filename recognized as directories
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/125051/ --- Review request for KDE Frameworks and David Faure. Bugs: 350696 https://bugs.kde.org/show_bug.cgi?id=350696 Repository: kio Description --- QUrl::toDisplayString removes password info by default. When using local files with ":" inside, toDisplayString returns empty filename Diffs - src/filewidgets/kfilewidget.cpp dc3c1f4 Diff: https://git.reviewboard.kde.org/r/125051/diff/ Testing --- Patch fixes issue #350696, tested on my system, but maybe there is a better way to fix it ? Thanks, Jean-Baptiste Mardelle ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
