Re: Review Request 120627: Remove kdelibs4support.
On Oct. 19, 2014, 2:49 a.m., Hrvoje Senjan wrote: interfaces/kompareinterface.h, line 25 https://git.reviewboard.kde.org/r/120627/diff/6/?file=320653#file320653line25 this include is also provided by KDELibs4Support.. quick grep shows it was also left in interfaces/kompareinterfaceexport.h also, few files still have klocale, kurl and kcomponentdata header includes, and kompare_part.h has KUrl and KTemporaryFile classes - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120627/#review68684 --- On Oct. 19, 2014, 12:13 a.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120627/ --- (Updated Oct. 19, 2014, 12:13 a.m.) Review request for kdelibs and Kevin Kofler. Repository: kompare Description --- Change KUrl to QUrl. Use QLayout/QFrame instead of KVBox (seems broken though somehow) Use QFileDialog instead of KFileDialog. Diffs - main.cpp 4132c8442f8546ee7d365051dda0e32196249217 libdialogpages/pagebase.h 0cef46feaa2cc81deff12c2c5f739e6be6df1b49 libdialogpages/pagebase.cpp ba1574aed7124ede49e1c5908a8fe693cf7bc5d3 libdialogpages/viewpage.h b5b770d1441650564106e1cc7ef7e587f6ee142d libdialogpages/viewpage.cpp 07bdba5e1edf55a6dcd02e5deef58d30c07660c2 libdialogpages/viewsettings.h dbf6afe0d0c70e548e32dfc09391d67ef595cdba libdialogpages/viewsettings.cpp 5a69d0bd9a49f7a3881940c4ea8ad407be56adc1 komparepart/komparesaveoptionswidget.cpp 4c9acba6a7f9c6dda04130946faac37138422875 komparepart/komparesplitter.cpp 8d496bf279caa7cb9a305c2d15131f591c48818d kompareurldialog.h dc50c588e70835ad9292da1baf5222f58f512f67 kompareurldialog.cpp 7de050bc44770a79f8f7d789cabd95d6707a40f1 libdialogpages/CMakeLists.txt 769a1154c56e8eb8aa42f1bc6d84e0f9a4154fd0 libdialogpages/dialogpagesexport.h b2de57f6616739d353d4889ef4965ab07f1191aa libdialogpages/diffpage.h 37490b1ebb245e9648530429da63a9240010 libdialogpages/diffpage.cpp 7800b486e023cffe41e1fa3e9e60781250ea4199 libdialogpages/filespage.h 42afafcd0fc8bc0a01e32b79d414742937d791fb libdialogpages/filespage.cpp 6a87fe36abd57bdaa09b516de38969db6c6f2298 libdialogpages/filessettings.h dc3306e34fe1b4eb7cb6a9d2b598f91932bedda0 libdialogpages/filessettings.cpp 0e19dc00f22a2f6e9588bf2d110dbde682888472 komparepart/kompare_part.h 24475f1b0ccf7fbeda56860a9a69955cd0b82808 komparepart/kompare_part.cpp 4d40be0dedcfb91b77ee239de11188b328f8bc13 komparepart/komparelistview.cpp 35bbab849d8b7938cba518e97a00ed50cae35612 komparepart/kompareprefdlg.cpp 118485663390e9563a77741b490a9cdf8bf6d464 CMakeLists.txt 38167c2099d0ea1600bd5a6893982e809902fa3a doc/index.docbook 578d12a41d9a6afed441ffd38c39bff16c096ab2 interfaces/kompareinterface.h 53b19d944b2a4a65c14ea41b8f1c0997581933db kompare_shell.h 8549fcdc4d1536c58734f2bc3a78b9ebc42c6c5f kompare_shell.cpp dcc45513f3f9f5f94869046989b6b4f5b1c0995e komparenavtreepart/CMakeLists.txt 53e8e670e70629afac9197fc108d844733ec5c07 komparenavtreepart/komparenavtreepart.cpp 3faceff78fbbd2f083cd0a7837c74f50fe543474 komparepart/CMakeLists.txt 09b61e6ca0cdce391fc759be49a672a050cc16cd Diff: https://git.reviewboard.kde.org/r/120627/diff/ Testing --- It builds and runs. The compare dialog ui looks squished though and doesn't resize like it used to, must be something I did wrong when porting away from KVBox Thanks, Jeremy Whiting
Re: Review Request 120573: [OS X] make KDE's trash use the OS X trash
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120573/#review68687
---
kioslave/trash/CMakeLists.txt
https://git.reviewboard.kde.org/r/120573/#comment47875
ok with the variable to avoid duplication, but now kio+solid are duplicated
(and changed completely in KF5)
This would be better:
set (kio_trash_LIBS ...)
if (APPLE)
set(kio_trash_LIBS ${kio_trash_LIBS} -framework DiskArbitration)
endif()
kioslave/trash/kcmtrash.cpp
https://git.reviewboard.kde.org/r/120573/#comment47869
My point was that you forgot to change this one back :-)
kioslave/trash/tests/CMakeLists.txt
https://git.reviewboard.kde.org/r/120573/#comment47874
Don't duplicate the list of libs.
Just add a
if (APPLE)
target_link_libraries(testtrash -framework DiskArbitration)
endif()
target_link_libraries is cumulative, it doesn't have to be called only once.
kioslave/trash/trashimpl.h
https://git.reviewboard.kde.org/r/120573/#comment47870
spaces around '='.
And no, don't worry about the overhead. The QString() constructor does
very little (it uses an internal null-string instance).
No need for premature optimization at the expense of readability.
kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47871
!path.isEmpty() is more usual in Qt code than path.size().
kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47873
Should be const QString mountPoint, you're not modifying it.
Also, rename this method to idForMountPoint, it doesn't take a device
string as input, but a mountpoint string. This confused me greatly when looking
at the calling code :-)
kioslave/trash/trashimpl.cpp
https://git.reviewboard.kde.org/r/120573/#comment47872
You can't do that. I'm surprised it doesn't crash for you, actually.
encodeName returns a QByteArray. If you only store a char*, the bytearray goes
out of scope and you're looking at deleted memory.
Turn mp into a QByteArray, and remove the if(mp).
- David Faure
On Oct. 18, 2014, 6:08 p.m., René J.V. Bertin wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120573/
---
(Updated Oct. 18, 2014, 6:08 p.m.)
Review request for KDE Software on Mac OS X, KDE Runtime and David Faure.
Repository: kde-runtime
Description
---
KDE on OS X does not handle the desktop session (no Plasma) nor can it rely
on XDG to obtain the proper paths to use for something like the trash. As a
result, all applications that propose to move things they manage to the
wastebin (Dolphin, but also digiKam) will store those items in a place that
has no particular meaning on OS X, and that will thus tend to fill up.
OS X stores trash in one of several locations. Files trashed from the boot
volume (and/or the volume containing $HOME, I don't actually know that) end
up in `~/.Trash`. Files deleted from other volumes end up in
`/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless
whether it's an external or a remote drive; only mounted NFS shares are
handled differently) and uid the numerical user id. Permissions on `.Trashes`
are the same as those expected by KDE.
The kio_trash kioslave appears to support several actual trash directory
locations, just like OS X. `TrashImpl::init()` creates a standard trash in
`~/.local/share/Trash` (at least under OS X) but also
`TrashImpl::trashForMountPoint()` that is used in cases I have not yet
encountered.
On OS X, my modified `TrashImpl::init()` sets the standard trash directory to
`~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as
required, because they will of course be deleted when the user empties the OS
X trash. `TrashImpl::fileRemoved()` has been modified to call a new function,
`deleteEmptyTrashInfraStructure` to delete the KDE trash's internal
infrastructure when the wastebin is empty so that OS X also sees the trash as
emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature
actually works, as expected as far as I can tell).
Remains to be done:
- determine in what cases `trashForMountPoint()` is used, and finish the
modifications for it to use `/.Trashes/uid/KDE.trash`
Diffs
-
kioslave/trash/CMakeLists.txt 3604089
kioslave/trash/kcmtrash.cpp f4811fd
kioslave/trash/tests/CMakeLists.txt 9161fdf
kioslave/trash/trashimpl.h bc68723
kioslave/trash/trashimpl.cpp 30ee05b
Diff: https://git.reviewboard.kde.org/r/120573/diff/
Testing
---
On OS X 10.6.8 with
Re: Review Request 118313: [Konqlib] KUrl - QUrl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118313/#review68689 --- Obsoleted by https://git.reviewboard.kde.org/r/120650/ (and by changes made meanwhile in libkonq). Sorry about this - between the todos, the unittest failures, and the evolving underlying code base, this fell through. - David Faure On June 17, 2014, 4 p.m., Emmanuel Pescosta wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118313/ --- (Updated June 17, 2014, 4 p.m.) Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- Ported Konqlib from KUrl to QUrl (convert-kurl.pl) Still some ToDos left in the code (I'll mark it inline) Diffs - lib/konq/favicons/favicons.h 30f0272 lib/konq/favicons/favicons.cpp 4646fa5 lib/konq/konq_copytomenu.h 0958e20 lib/konq/konq_copytomenu.cpp 7ee5131 lib/konq/konq_copytomenu_p.h eb6649a lib/konq/konq_dndpopupmenuplugin.h 2417080 lib/konq/konq_historyentry.h 6b33b98 lib/konq/konq_historyentry.cpp bfc4a5d lib/konq/konq_historyprovider.h 91b5b87 lib/konq/konq_historyprovider.cpp 10a5e74 lib/konq/konq_nameandurlinputdialog.h 3a943f7 lib/konq/konq_nameandurlinputdialog.cpp 2fb06f9 lib/konq/konq_operations.h b51fa3f lib/konq/konq_operations.cpp 0cbff08 lib/konq/konq_popupmenu.h b5f5e39 lib/konq/konq_popupmenu.cpp caa37e7 lib/konq/konq_popupmenuinformation.h 1454073 lib/konq/konq_popupmenuinformation.cpp 6e1033b lib/konq/konq_sound.h 8063073 lib/konq/konq_sound.cc f8a80a9 lib/konq/konqmimedata.h a2640a2 lib/konq/konqmimedata.cpp 8f9ecf1 lib/konq/tests/favicontest.cpp d48b03d lib/konq/tests/konqmimedatatest.cpp 6a2be4f lib/konq/tests/konqpopupmenutest.cpp 46851c5 Diff: https://git.reviewboard.kde.org/r/118313/diff/ Testing --- Tests fail konqmimedatatest: (todos) FAIL! : KonqMimeDataTest::testPopulate() 'mimeData-hasUrls()' returned FALSE. FAIL! : KonqMimeDataTest::testCut() 'mimeData-hasUrls()' returned FALSE. konqpopupmenutest: (local setup problem maybe?!) QFATAL : KonqPopupMenuTest::testFile() ASSERT failure in KServiceTypeFactory::KServiceTypeFactory() favicontest: (local setup problem maybe?!) QFATAL : FavIconTest::testSetIconForURL() ASSERT failure in KServiceTypeFactory::KServiceTypeFactory() Thanks, Emmanuel Pescosta
Re: Review Request 119014: KUrlRequester: fixing handling of start directory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119014/#review68690 --- Ship it! Sorry for the delay -- too many review requests I'll commit this. - David Faure On Aug. 1, 2014, 7:39 p.m., Simon Bachmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119014/ --- (Updated Aug. 1, 2014, 7:39 p.m.) Review request for kdelibs. Bugs: 92237 http://bugs.kde.org/show_bug.cgi?id=92237 Repository: kdelibs Description --- The handling of the start directory in the KUrlRequester is only halfway implemented. More in detail: - m_startDir (the private field holding the start directory) is not initialised - the default value of startDir() is an empty URL instead of the current working dir. - when the start dir changes, it is not always passed to the KUrlCompletion object of the lineedit. The suggestions showed when entering a relative path into the LineEdit might be wrong as a consequence. - when selecting a file, the start directory does not change to the directory of the selected file - the API doc says it should. - when the user entered a relative path into the LineEdit, url() returns a relative path instead of an absolute one. This patch should fix these issues. Diffs - kio/kfile/kurlrequester.h 2083d4c kio/kfile/kurlrequester.cpp 661b428 Diff: https://git.reviewboard.kde.org/r/119014/diff/ Testing --- Thanks, Simon Bachmann
Re: Review Request 119014: KUrlRequester: fixing handling of start directory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119014/ --- (Updated Oct. 19, 2014, 9:18 a.m.) Status -- This change has been marked as submitted. Review request for kdelibs. Bugs: 92237 http://bugs.kde.org/show_bug.cgi?id=92237 Repository: kdelibs Description --- The handling of the start directory in the KUrlRequester is only halfway implemented. More in detail: - m_startDir (the private field holding the start directory) is not initialised - the default value of startDir() is an empty URL instead of the current working dir. - when the start dir changes, it is not always passed to the KUrlCompletion object of the lineedit. The suggestions showed when entering a relative path into the LineEdit might be wrong as a consequence. - when selecting a file, the start directory does not change to the directory of the selected file - the API doc says it should. - when the user entered a relative path into the LineEdit, url() returns a relative path instead of an absolute one. This patch should fix these issues. Diffs - kio/kfile/kurlrequester.h 2083d4c kio/kfile/kurlrequester.cpp 661b428 Diff: https://git.reviewboard.kde.org/r/119014/diff/ Testing --- Thanks, Simon Bachmann
Re: Review Request 119014: KUrlRequester: fixing handling of start directory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119014/#review68692 --- I think this misses the remember url as defaultStartDir and update startdir for autocompletion code path for the case of the directory-selection dialog (KUrlRequester::KUrlRequesterPrivate::_k_slotOpenDialog, see emit m_parent-urlSelected line, just like the other one where you added code - that code should be factorized) - David Faure On Oct. 19, 2014, 9:18 a.m., Simon Bachmann wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119014/ --- (Updated Oct. 19, 2014, 9:18 a.m.) Review request for kdelibs. Bugs: 92237 http://bugs.kde.org/show_bug.cgi?id=92237 Repository: kdelibs Description --- The handling of the start directory in the KUrlRequester is only halfway implemented. More in detail: - m_startDir (the private field holding the start directory) is not initialised - the default value of startDir() is an empty URL instead of the current working dir. - when the start dir changes, it is not always passed to the KUrlCompletion object of the lineedit. The suggestions showed when entering a relative path into the LineEdit might be wrong as a consequence. - when selecting a file, the start directory does not change to the directory of the selected file - the API doc says it should. - when the user entered a relative path into the LineEdit, url() returns a relative path instead of an absolute one. This patch should fix these issues. Diffs - kio/kfile/kurlrequester.h 2083d4c kio/kfile/kurlrequester.cpp 661b428 Diff: https://git.reviewboard.kde.org/r/119014/diff/ Testing --- Thanks, Simon Bachmann
Re: Review Request 118313: [Konqlib] KUrl - QUrl
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118313/ --- (Updated Oct. 19, 2014, 12:57 p.m.) Status -- This change has been discarded. Review request for KDE Base Apps and David Faure. Repository: kde-baseapps Description --- Ported Konqlib from KUrl to QUrl (convert-kurl.pl) Still some ToDos left in the code (I'll mark it inline) Diffs - lib/konq/favicons/favicons.h 30f0272 lib/konq/favicons/favicons.cpp 4646fa5 lib/konq/konq_copytomenu.h 0958e20 lib/konq/konq_copytomenu.cpp 7ee5131 lib/konq/konq_copytomenu_p.h eb6649a lib/konq/konq_dndpopupmenuplugin.h 2417080 lib/konq/konq_historyentry.h 6b33b98 lib/konq/konq_historyentry.cpp bfc4a5d lib/konq/konq_historyprovider.h 91b5b87 lib/konq/konq_historyprovider.cpp 10a5e74 lib/konq/konq_nameandurlinputdialog.h 3a943f7 lib/konq/konq_nameandurlinputdialog.cpp 2fb06f9 lib/konq/konq_operations.h b51fa3f lib/konq/konq_operations.cpp 0cbff08 lib/konq/konq_popupmenu.h b5f5e39 lib/konq/konq_popupmenu.cpp caa37e7 lib/konq/konq_popupmenuinformation.h 1454073 lib/konq/konq_popupmenuinformation.cpp 6e1033b lib/konq/konq_sound.h 8063073 lib/konq/konq_sound.cc f8a80a9 lib/konq/konqmimedata.h a2640a2 lib/konq/konqmimedata.cpp 8f9ecf1 lib/konq/tests/favicontest.cpp d48b03d lib/konq/tests/konqmimedatatest.cpp 6a2be4f lib/konq/tests/konqpopupmenutest.cpp 46851c5 Diff: https://git.reviewboard.kde.org/r/118313/diff/ Testing --- Tests fail konqmimedatatest: (todos) FAIL! : KonqMimeDataTest::testPopulate() 'mimeData-hasUrls()' returned FALSE. FAIL! : KonqMimeDataTest::testCut() 'mimeData-hasUrls()' returned FALSE. konqpopupmenutest: (local setup problem maybe?!) QFATAL : KonqPopupMenuTest::testFile() ASSERT failure in KServiceTypeFactory::KServiceTypeFactory() favicontest: (local setup problem maybe?!) QFATAL : FavIconTest::testSetIconForURL() ASSERT failure in KServiceTypeFactory::KServiceTypeFactory() Thanks, Emmanuel Pescosta
Re: Re: Detect window manager using KWindowSystem
On Saturday 18 October 2014 15:34:53 Thomas Lübking wrote: You MUST check the hinted support window anyway, because if the WM was killed -9 or -11 it will unlikely (in case of -9 no way) have withdrawn any root property and your findings based upon this data alone would be wrong. There's no convenience function for that in KWindowSystem, is there? (I don't see it) I just looked at the API as well and also cannot see a convenience function. Might be worth adding it: bool NETRootInfo::isCompliantWindowManagerRunning() const? Cheers Martin signature.asc Description: This is a digitally signed message part.
Re: Detect window manager using KWindowSystem
On Sonntag, 19. Oktober 2014 15:08:51 CEST, Martin Gräßlin wrote: Might be worth adding it: bool NETRootInfo::isCompliantWindowManagerRunning() const? It certainly won't harm, but the question is: who actually needs such? WM's operate on the WM selection - and right now, i cannot imagine why any client should check for that (optional client side window management? ;-) - @Paulo, why do you need to check for this? (And do you want a bashlet? ;-) Cheers, Thomas
Question about QSslCipher::protocolString
Both the protocol and protocolString methods in QSslCipher return a
different value than what is expected. For example, in Qt 4.8 if you set
the protocol in QSslSocket to QSsl::TlsV1 and connect to blog.mozilla.org
port 443, you get the following output from QSslCipher:
QSslSocket Information:
==
protocol: 5
QSslCipher Information:
=
name: DHE-RSA-AES128-SHA
authenticationmethod: RSA
encryptionMethod: AES(128)
keyExchangeMethod: DH
protocol: 0
protocolString: SSLv3
supportedBits: 128
usedBits: 128
However if one uses openssl directly, the following information is returned:
$ openssl s_client -connect blog.mozilla.org:443
certificate snipped
subject=/C=US/ST=CA/L=Mountain View/O=Mozilla Corporation/CN=
generic-san.mozilla.org
issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA
---
No client certificate CA names sent
---
SSL handshake has read 3845 bytes and written 522 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1.1
Cipher: DHE-RSA-AES128-SHA
Session-ID:
EA0ECB6221F00F22BF082CA189CA9587EDA0572CDB6340058C2FADC0FBCE6FCA
Session-ID-ctx:
Master-Key:
52A00273C65B278A2BD71153C2543BA4301569C84DC68878E574F0DF6B1115930E008A1B5D293DCBF9EB04F8F3FA1121
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1413727556
Timeout : 300 (sec)
Verify return code: 20 (unable to get local issuer certificate)
---
So the negotiated protocol when using openSSL directly is returned as
TLSv1.1 where as QSslCipher almost always returns SSLv3. My question is why
the negotiated protocol in QSslCipher is different from the one we get
through openssl directly? Is the socket protocol a different thing from the
cipher protocol? If so, then what KTcpSocket::negotiatedSslVersionName()
returns must be wrong as well.
Anyhow, I am asking this because of bug# 340047.
Since tcpslavebase.cpp calls KTcpSocket::negotiatedSslVersionName() which
in turn calls QSslCipher::protocolString() to obtain the SSL protocol used,
the SSL protocol information sent back to the clients is the one from
QSslCipher. Unfortunately that seems to almost always return SSLv3.
I have attached the program I used to print out the contents of QSslCipher.
#include QtCore/QCoreApplication
#include QtCore/QStringList
#include QtNetwork/QSslSocket
#include QtNetwork/QSslCipher
#include iostream
using namespace std;
static void printCipher(QSslSocket* socket)
{
const QSslCipher cipher (socket-sessionCipher());
cout QSslSocket Information: endl;
cout === endl;
cout protocol: socket-protocol() endl;
cout endl;
cout QSslCipher Information: endl;
cout === endl;
cout name: qPrintable(cipher.name()) endl;
cout authenticationmethod: qPrintable(cipher.authenticationMethod()) endl;
cout encryptionMethod: qPrintable(cipher.encryptionMethod()) endl;
cout keyExchangeMethod: qPrintable(cipher.keyExchangeMethod()) endl;
cout protocol: cipher.protocol() endl;
cout protocolString: qPrintable(cipher.protocolString()) endl;
cout supportedBits: cipher.supportedBits() endl;
cout usedBits: cipher.usedBits() endl;
}
int main(int argc, char** argv)
{
QCoreApplication app(argc, argv);
if (app.arguments().count() 2) {
qDebug() Usage: app.arguments().at(0).toUtf8().constData() server;
return -1;
}
QSslSocket *socket = new QSslSocket(app);
socket-connectToHostEncrypted(app.arguments().at(1), 443);
if (socket-waitForEncrypted()) {
printCipher(socket);
}
}
//Compare with: openssl s_client -connect hostname:443
//Qt4: g++ -o test_qsslcipher -I/usr/include/qt -lQtCore -lQtNetwork test_qsslcipher.cpp
//Qt5: g++ -fPIE -o test_qsslcipher -I/usr/include/qt -lQt5Core -lQt5Network test_qsslcipher.cpp
Re: Review Request 120652: Remove kdemacros.h and use generate_export_header for interfaces folder.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120652/#review68714 --- Ship it! Ship It! - Aleix Pol Gonzalez On Oct. 19, 2014, 2:05 a.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120652/ --- (Updated Oct. 19, 2014, 2:05 a.m.) Review request for kdelibs and Kevin Kofler. Repository: kompare Description --- Remove kdemacros.h and use generate_export_header for interfaces folder. Diffs - interfaces/CMakeLists.txt 032ae985ac7221a498afff186211fbcad68cba78 interfaces/kompareinterface.h 07a271d0844767a2fee5af3e985c1b05d3640f05 interfaces/kompareinterfaceexport.h eed5c85eb4e4c091df2f32e58d3183600ca3a8c0 Diff: https://git.reviewboard.kde.org/r/120652/diff/ Testing --- Still builds and runs as expected. Thanks, Jeremy Whiting
Re: Review Request 120652: Remove kdemacros.h and use generate_export_header for interfaces folder.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120652/ --- (Updated Oct. 19, 2014, 8:44 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs and Kevin Kofler. Repository: kompare Description --- Remove kdemacros.h and use generate_export_header for interfaces folder. Diffs - interfaces/CMakeLists.txt 032ae985ac7221a498afff186211fbcad68cba78 interfaces/kompareinterface.h 07a271d0844767a2fee5af3e985c1b05d3640f05 interfaces/kompareinterfaceexport.h eed5c85eb4e4c091df2f32e58d3183600ca3a8c0 Diff: https://git.reviewboard.kde.org/r/120652/diff/ Testing --- Still builds and runs as expected. Thanks, Jeremy Whiting
Re: Review Request 120630: Port from KTempDir to QTemporaryDir. Port from KUrl to QUrl.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120630/ --- (Updated Oct. 19, 2014, 8:45 p.m.) Status -- This change has been marked as submitted. Review request for kdelibs and Kevin Kofler. Repository: libkomparediff2 Description --- Port from KTempDir to QTemporaryDir. Diffs - kompare.h a8f3c5a71995c8416f9089f3c263f3691c9bfab5 kompare.cpp e44b8a3dcf59a43de426b28c39412d4331949412 Diff: https://git.reviewboard.kde.org/r/120630/diff/ Testing --- It builds and an updated kompare frameworks branch builds against it and runs. Thanks, Jeremy Whiting
Re: Question about QSslCipher::protocolString
On Sunday 19 October 2014 18:14:36 Thomas Lübking wrote: On Sonntag, 19. Oktober 2014 16:35:35 CEST, Dawit A wrote: protocolString: SSLv3 ... However if one uses openssl directly, the following information is returned: $ openssl s_client -connect blog.mozilla.org:443 New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA ... So the negotiated protocol when using openSSL directly is returned as TLSv1.1 where as QSslCipher almost always returns SSLv3. My question is why the negotiated protocol in QSslCipher is different from the one we get through openssl directly? I get SSLv3 from blog.mozilla.org, but TLSv1.2 from mail.google.com. Checking qDebug() QSslSocket::defaultCiphers();, QSslCipher(name=ECDHE-RSA-AES256-GCM-SHA384, bits=256, proto=TLSv1.2) is top of the list here and most SSLv3 variants on the very bottom. -- THERE IS NO TLSv1.1 IN THAT LIST, NOR IN ::supportedCiphers() However, I don't know why QSslSocket doesn't provide TLSv1.1 (here) This is looking like a Qt bug instead. Can you investigate QSslSocket instead? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
Re: Review Request 120460: [kio] Imported the filenamesearch ioslave from Dolphin
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120460/#review68733 --- OK this wasn't too long, I reviewed it directly. It's even better, I can complain about all the non-satisfactory code, whether it was just ported or it was that way already :-) filenamesearch/kio_filenamesearch.cpp https://git.reviewboard.kde.org/r/120460/#comment48005 item.text() would probably be better, for these special cases where text != name (name is internal, text is what the user sees in a directory listing) filenamesearch/kio_filenamesearch.cpp https://git.reviewboard.kde.org/r/120460/#comment47999 Can this url parameter be a local path? With its name I would expect a full URL - in which case QUrl(...) should be enough. filenamesearch/kio_filenamesearch.cpp https://git.reviewboard.kde.org/r/120460/#comment48003 No, this should be toLocalFile() (it makes a difference on Windows) filenamesearch/kio_filenamesearch.cpp https://git.reviewboard.kde.org/r/120460/#comment48001 Wow, won't this be really slow? which remote protocols is it typically used with? Any? Well, if it's an explicit request from the user I guess that's OK... filenamesearch/kio_filenamesearch.cpp https://git.reviewboard.kde.org/r/120460/#comment48002 This code is keeping the filename of a file that is about to be deleted (by the QTemporaryFile destructor). So the reading will fail for sure. Sounds like this wasn't properly tested :-) For small files, KIO::get would even be better (contents in memory). But OK, if the files can be huge, I guess a tempfile is better. One easy solution is to move the QTemporaryFile to the method scope, so it keeps existing until the end of the method. Given that the ctor doesn't do much (only assembling the tempfile template name) the performance penalty would probably be not too bad. Alternatively, move the QFile+QTextStream code to a helper function and call it in each of the two cases (local or remote) separately. Would be better for performance. - David Faure On Oct. 13, 2014, 1:35 p.m., Emmanuel Pescosta wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120460/ --- (Updated Oct. 13, 2014, 1:35 p.m.) Review request for kde-workspace and David Faure. Repository: kio-extras Description --- The filenamesearch ioslave lists all files/folders which match with the given search query. Made some small adjustments: * Ported the ioslave to Qt5/KF5 * Got rid of cleanup() and member variables * Use lambda function validators instead of some weird if + assert things in searchDirectory/contentContainsPattern * Immediately return when the search string is empty https://projects.kde.org/projects/kde/applications/kde-baseapps/repository/revisions/frameworks/show/dolphin/src/search Diffs - filenamesearch/kio_filenamesearch.h PRE-CREATION filenamesearch/kio_filenamesearch.cpp PRE-CREATION CMakeLists.txt 2036392 filenamesearch/CMakeLists.txt PRE-CREATION filenamesearch/filenamesearch.protocol PRE-CREATION Diff: https://git.reviewboard.kde.org/r/120460/diff/ Testing --- Compiles. Thanks, Emmanuel Pescosta
