Re: Framework Categories
On Wednesday 04 February 2015 09:33:00 Jeremy Whiting wrote: Ok, I've changed knewstuff to a solution type. Should all frameworks that depend on kio be also changed to solution type ? Sounds right. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122360: Make FTP error messages prettier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122360/#review75588 --- Ship it! Ship It! - David Faure On Feb. 1, 2015, 12:11 p.m., Kai Uwe Broulik wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122360/ --- (Updated Feb. 1, 2015, 12:11 p.m.) Review request for KDE Frameworks. Bugs: 318079 https://bugs.kde.org/show_bug.cgi?id=318079 Repository: kio Description --- This is the patch from Review 110084 rebased on frameworks and using remoteEncoding Diffs - src/ioslaves/ftp/ftp.cpp b060c95 Diff: https://git.reviewboard.kde.org/r/122360/diff/ Testing --- Works. Thanks, Kai Uwe Broulik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122360: Make FTP error messages prettier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122360/ --- (Updated Feb. 8, 2015, 1:19 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Bugs: 318079 https://bugs.kde.org/show_bug.cgi?id=318079 Repository: kio Description --- This is the patch from Review 110084 rebased on frameworks and using remoteEncoding Diffs - src/ioslaves/ftp/ftp.cpp b060c95 Diff: https://git.reviewboard.kde.org/r/122360/diff/ Testing --- Works. Thanks, Kai Uwe Broulik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kross: src/core/metafunction.h:89 char* to QByteArrayData*
On Wednesday 04 February 2015 19:54:36 Maximiliano Curia wrote: Hi, As part of the packaging efforts in Debian we are testing the installed headers to check that they compile correctly and have all their dependencies installed. Nice :-) Testing kross we found this: // static metaobject staticMetaObject.d.superdata = QObject::staticMetaObject; staticMetaObject.d.stringdata = m_stringData.data(); staticMetaObject.d.data = m_data; staticMetaObject.d.extradata = 0; That seems to be the qt4 way, as stringdata is a const QByteArrayData* in qt5 (now reported in: https://bugs.kde.org/show_bug.cgi?id=343779). Adding a reinterpret_castconst QByteArrayData * fixes the issue, or even better using: staticMetaObject.d.stringdata = m_stringData.data_ptr(); That compiled but failed at runtime, because the string data has to be static, not dynamic. I wrote a unittest and upgraded the whole dynamic meta object generation in metafunction.h to revision 7, as required by Qt 5. The unittest works, I committed, this will be in 5.7. Thanks for the report ! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122478: KConfigWidgets: Remove leftover uses of tr() for translation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122478/#review75600 --- Ship it! Ship It! - David Edmundson On Feb. 8, 2015, 1:11 p.m., Lasse Liehu wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122478/ --- (Updated Feb. 8, 2015, 1:11 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Remove leftover uses of tr() for translation KConfigWidgets uses KI18n and these strings were not even extracted. Just noticed this randomly today. Two tr() calls still remain in ktipdialog.cpp. Those translate the tips themselves. There is a bug report at https://bugs.kde.org/show_bug.cgi?id=343936. Diffs - src/kconfigdialog.cpp 6214348 src/ktipdialog.cpp bd3cbd3 Diff: https://git.reviewboard.kde.org/r/122478/diff/ Testing --- Strings still show up correctly in UI. Thanks, Lasse Liehu ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kross_master_qt5 #86
See http://build.kde.org/job/kross_master_qt5/86/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122478: KConfigWidgets: Remove leftover uses of tr() for translation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122478/ --- Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Remove leftover uses of tr() for translation KConfigWidgets uses KI18n and these strings were not even extracted. Just noticed this randomly today. Two tr() calls still remain in ktipdialog.cpp. Those translate the tips themselves. There is a bug report at https://bugs.kde.org/show_bug.cgi?id=343936. Diffs - src/kconfigdialog.cpp 6214348 src/ktipdialog.cpp bd3cbd3 Diff: https://git.reviewboard.kde.org/r/122478/diff/ Testing --- Strings still show up correctly in UI. Thanks, Lasse Liehu ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122445: an if-statement at KDesktopFile::locateLocal is not build correctly
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122445/#review75594
---
src/core/kdesktopfile.cpp
https://git.reviewboard.kde.org/r/122445/#comment52286
a QChar would be enough
src/core/kdesktopfile.cpp
https://git.reviewboard.kde.org/r/122445/#comment52284
in C++, better declare vars as close as possible to where they are used;
this looks like C.
src/core/kdesktopfile.cpp
https://git.reviewboard.kde.org/r/122445/#comment52285
path.startsWith(dir + plus) would be better (the temporary could be moved
rather than copied, with C++11)
- David Faure
On Feb. 5, 2015, 6:36 p.m., Guy Maurel wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122445/
---
(Updated Feb. 5, 2015, 6:36 p.m.)
Review request for KDE Frameworks, Cornelius Schumacher, Nicolás Alvarez, and
Thiago Macieira.
Repository: kconfig
Description
---
The if statements at lines 84, 91
if (path.startsWith(dir) + '/') {
cannot be correct. The value of (path.startsWith(dir) + '/') is always 47.
I propose to use:
QString plus = QLatin1String(/);
QString dirPlus;
...
Q_FOREACH (...) {
dirPlus = dir;
dirPlus.append(plus);
if (path.startsWith(dirPlus)) {
Diffs
-
src/core/kdesktopfile.cpp 6381cb30ba9382de492e2d8d4cf1f9e342f1c509
Diff: https://git.reviewboard.kde.org/r/122445/diff/
Testing
---
Thanks,
Guy Maurel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122459: sync the bookmarkmanager with the shared one only if change was from this process
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122459/#review75596 --- Ship it! I don't know this code very well, but the reasoning seems to make sense - it's slow and pointless to have all processes write the change to the xbel file. This breaks the theoretical case where kfileplaces/bookmarks.xml is modified by some other app (or code) without modifying user-places.xbel, but I guess that never happens. It's just funny that the secondary export file (for sharing with other desktops) ends up being used as the trigger for changes in our main file (kfileplaces/bookmarks.xml). But why not. src/filewidgets/kfileplacessharedbookmarks.cpp https://git.reviewboard.kde.org/r/122459/#comment52287 probably don't want to leave that enabled - David Faure On Feb. 6, 2015, 5:53 p.m., Marco Martin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122459/ --- (Updated Feb. 6, 2015, 5:53 p.m.) Review request for KDE Frameworks. Bugs: 343735 https://bugs.kde.org/show_bug.cgi?id=343735 Repository: kio Description --- This is an attempt to fix a bug that seems quite difficult to reproduce, but definitely happens It seems there is a weird race condition linked to the sync of the two files .local/share/user-places.xbel .local/share/kfileplaces/bookmarks.xml causing the bug https://bugs.kde.org/show_bug.cgi?id=343735 all processes that are listening for changes in the bookmark manager will try to sync their bookmarks with the shared ones (user-places.xbel) and depending what process arrives first, some bookmarks may be lost if this is ok, it will have to go in kdelibs4 (since distributions will support kde4 apps for a long time still) as well as (ouch) dolphin both 4 and 5, since it forks KFilePlacesModel Diffs - src/filewidgets/kfileplacesmodel.cpp d8da868 src/filewidgets/kfileplacessharedbookmarks.cpp fbd6b53 src/filewidgets/kfileplacessharedbookmarks_p.h 4c9f6a4 Diff: https://git.reviewboard.kde.org/r/122459/diff/ Testing --- Thanks, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122482: Restore KCModule::setAuthAction
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122482/ --- Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Sometimes we need our save action in our kconfig module to refer to a polkit action which is not in the format org.kde.kcontrol.name.save. For example I am making the clock KCM module call timedated directly without needing our helper. Setting the right polkit action is needed for systemsettings to display the correct message of whether root priveldges will be needed. This method is referred to in the documentation already so I assume this used to exist? Diffs - src/kcmodule.h 4fb5e0d src/kcmodule.cpp 3c43649 Diff: https://git.reviewboard.kde.org/r/122482/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
On Sunday 08 February 2015 18:18:48 Aleix Pol wrote: On Sun, Feb 8, 2015 at 5:55 PM, Jeremy Whiting jpwhit...@kde.org wrote: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? The policy so far has been, AFAIK, that it needs to work on Qt supported platforms: http://doc.qt.io/qt-5/supported-platforms.html Officially, our requirements are documented at: https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 However, I seem to remember an email about moving to require MSVC 2012, so it's not necessarily entirely up-to-date. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
That page was the result of the first discussion we had on C++11. More recently, there was a discussion on raising MSVC requirement. And, I'd say it was agreed to raise it to MSVC11 (VS12). At least, it was green-lighted by Kevin, Milian (I don't recall who else). I guess I should have updated the wiki afterwards... The strange thing here is that we don't usually mention clang (and stdlib versions) since it is considered 'good enough'. Cheerio, Ivan On 8 February 2015 at 18:25, Alex Merry alex.me...@kde.org wrote: On Sunday 08 February 2015 18:18:48 Aleix Pol wrote: On Sun, Feb 8, 2015 at 5:55 PM, Jeremy Whiting jpwhit...@kde.org wrote: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? The policy so far has been, AFAIK, that it needs to work on Qt supported platforms: http://doc.qt.io/qt-5/supported-platforms.html Officially, our requirements are documented at: https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 However, I seem to remember an email about moving to require MSVC 2012, so it's not necessarily entirely up-to-date. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122481: Fix use of environ for OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- Review request for KDE Software on Mac OS X, KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122481: Fix use of environ for OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/#review75613 --- src/widgets/kurlcompletion.cpp https://git.reviewboard.kde.org/r/122481/#comment52289 Qt5 has Q_OS_OSX to target OS X rather than a Mac OS (which according to Qt includes iOS). For code that will never run on iOS it might be better to use Q_OS_OSX from the onset. - René J.V. Bertin On Feb. 8, 2015, 5:07 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- (Updated Feb. 8, 2015, 5:07 p.m.) Review request for KDE Software on Mac OS X, KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
C++11 policy in frameworks?
Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122482: Restore KCModule::setAuthAction
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122482/#review75617 --- src/kcmodule.cpp https://git.reviewboard.kde.org/r/122482/#comment52293 else qWarning() invalid authorization ? Or something? - Aleix Pol Gonzalez On Feb. 8, 2015, 5:25 p.m., David Edmundson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122482/ --- (Updated Feb. 8, 2015, 5:25 p.m.) Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Sometimes we need our save action in our kconfig module to refer to a polkit action which is not in the format org.kde.kcontrol.name.save. For example I am making the clock KCM module call timedated directly without needing our helper. Setting the right polkit action is needed for systemsettings to display the correct message of whether root priveldges will be needed. This method is referred to in the documentation already so I assume this used to exist? Diffs - src/kcmodule.h 4fb5e0d src/kcmodule.cpp 3c43649 Diff: https://git.reviewboard.kde.org/r/122482/diff/ Testing --- Thanks, David Edmundson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
On Sun, Feb 8, 2015 at 5:55 PM, Jeremy Whiting jpwhit...@kde.org wrote: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? The policy so far has been, AFAIK, that it needs to work on Qt supported platforms: http://doc.qt.io/qt-5/supported-platforms.html Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121263: Prevent API abuse of calling setters on temporary objects.
On Nov. 27, 2014, 7:29 a.m., Christoph Cullmann wrote: I actually would prefer no such hack in the public headers. If that is just to make porting easier, you can use that locally as a patch until the kdevplatform code is cleaned up. Milian Wolff wrote: I still don't get why you think this is a hack, or why it would be bad to have it in public headers. Any consumer of your API could shoot yourself in the foot... Christoph Cullmann wrote: I must rephrase: I think, without any guard define, this is not even source compatible (even if the use might be in most cases an error). And with a guard define, this is a hack, as you need to turn it on, which most people won't do at all. It might have been a good idea to add to the API in KF 5.0, but as we missed that, its now too late, or? Dominik Haumann wrote: @Milian: is it correct, that this is/was only an issue in KDevelop? As said, as that change is SIC and only on per define, which nobody will find anyway on their first try, I don't like to include that in the official headers. If I am mistaken and this is source and binary compatible, please reopen. - Christoph --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/#review70996 --- On Feb. 8, 2015, 2:42 p.m., Milian Wolff wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/ --- (Updated Feb. 8, 2015, 2:42 p.m.) Review request for KDE Frameworks, Christoph Cullmann, Dominik Haumann, and Kevin Funk. Repository: ktexteditor Description --- In KDevelop we currently hit this often since our old class previously returned a reference for the start/end getters of range and cursor. With the help of C++11 ref qualifiers, we can detect that and let the compiler give the user an error message: error: cannot initialize object parameter of type 'KTextEditor::Cursor' with an expression of type 'KTextEditor::Cursor' documentRange().start().setColumn(42); ^~~ Yes, the error message is pretty bad. But better than nothing? We could also mark the overloads of these functions as explictily deleted, which would slightly improve the error message... Diffs - src/include/CMakeLists.txt 94b8e79e2f2b273ec344a963ba6ac81ec5a481c6 src/include/ktexteditor/cursor.h 4ebe38fc1bffb2dad02150884fd225fe3ca9e193 src/include/ktexteditor/global.h PRE-CREATION src/include/ktexteditor/range.h 1a2fc5b200c70364c3d99223e43a2ad6179055de Diff: https://git.reviewboard.kde.org/r/121263/diff/ Testing --- with the fixes to kdev's codebase, all of ktexteditor, kate and kdev* builds fine. Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 121263: Prevent API abuse of calling setters on temporary objects.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/121263/ --- (Updated Feb. 8, 2015, 2:42 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks, Christoph Cullmann, Dominik Haumann, and Kevin Funk. Repository: ktexteditor Description --- In KDevelop we currently hit this often since our old class previously returned a reference for the start/end getters of range and cursor. With the help of C++11 ref qualifiers, we can detect that and let the compiler give the user an error message: error: cannot initialize object parameter of type 'KTextEditor::Cursor' with an expression of type 'KTextEditor::Cursor' documentRange().start().setColumn(42); ^~~ Yes, the error message is pretty bad. But better than nothing? We could also mark the overloads of these functions as explictily deleted, which would slightly improve the error message... Diffs - src/include/CMakeLists.txt 94b8e79e2f2b273ec344a963ba6ac81ec5a481c6 src/include/ktexteditor/cursor.h 4ebe38fc1bffb2dad02150884fd225fe3ca9e193 src/include/ktexteditor/global.h PRE-CREATION src/include/ktexteditor/range.h 1a2fc5b200c70364c3d99223e43a2ad6179055de Diff: https://git.reviewboard.kde.org/r/121263/diff/ Testing --- with the fixes to kdev's codebase, all of ktexteditor, kate and kdev* builds fine. Thanks, Milian Wolff ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kross_master_qt5 #87
See http://build.kde.org/job/kross_master_qt5/87/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 120442: Fix comments in Haskell highlighting
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/120442/
---
(Updated Feb. 8, 2015, 2:55 p.m.)
Status
--
This change has been marked as submitted.
Review request for KDE Frameworks and Christoph Cullmann.
Repository: ktexteditor
Description
---
A comment like {--} resultet in staying in the Comments section until
reaching the next -}
Diffs
-
src/syntax/data/haskell.xml f0e7f8f955ea9cd56795add8de03c6627313301a
Diff: https://git.reviewboard.kde.org/r/120442/diff/
Testing
---
Manual testing with several Haskell files in my day-time job.
Thanks,
Bastian Holst
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122484: KCodecs: Fix i18n of character set names
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122484/ --- Review request for KDE Frameworks. Repository: kcodecs Description --- Fix i18n of character set names Now the translate calls match what is extracted into catalogs. For these translate calls to work with qm files generated by ecm_process_po_files_as_qm, the following Qt bug needs to be fixed: https://bugreports.qt.io/browse/QTBUG-44362 Diffs - src/kcharsets.cpp 83a461b Diff: https://git.reviewboard.kde.org/r/122484/diff/ Testing --- Manual testing with KWrite and Konversation that use these functions, using qm files generated with lrelease without -compress option. Thanks, Lasse Liehu ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
Yeah it's using the newest xcode for is x 10.7 so the libc++ is probably older, Qt supports 10.7 though so maybe we shouldn't be using these newer c++11 methods in frameworks just yet right? On Feb 8, 2015 2:04 PM, Ivan Čukić ivan.cu...@kde.org wrote: thought this was clang 3.7 maybe I'm confused though This is (should not) be a problem with the compiler version - this is a library function. Which version of libc++ is it using? (it might be using the old system's one instead of the latest release or something) Cheerio, Ivan On 8 February 2015 at 21:59, Jeremy Whiting jpwhit...@kde.org wrote: https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122481: Fix use of environ for OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- (Updated Feb. 8, 2015, 3:06 p.m.) Review request for KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Changes --- Changed to use Q_OS_OSX macro. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs (updated) - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122487: Reorder member variables to reduce memory usage.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122487/#review75629
---
Ship it!
Which magic tool did you come up with this time, to detect such things? :-)
- David Faure
On Feb. 8, 2015, 8:28 p.m., Volker Krause wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122487/
---
(Updated Feb. 8, 2015, 8:28 p.m.)
Review request for KDE Frameworks.
Repository: kcoreaddons
Description
---
The KJobPrivate one saves 24 bytes per instance, the others 8 bytes (on a 64
bit system).
Diffs
-
src/lib/io/kdirwatch_p.h f8cc2bcd5b9a8c65b409873ac78455fbb7db2405
src/lib/jobs/kjob.cpp de3b8d7c8985dcc21ef9f52fba47361e9675f192
src/lib/jobs/kjob_p.h 8bacefecc4dc8d2679a48b224837e0c01516d601
src/lib/plugin/kpluginloader.cpp 64d7f0cec37ef51a76a3a60637822810cab398e6
Diff: https://git.reviewboard.kde.org/r/122487/diff/
Testing
---
```
Struct Entry (DW_TAG_class_type, offset 393887) is sub-optimally packed:
74/88 bytes, 592/704 bits, optimal size is: 80 bytes
class KDirWatchPrivate::Entry // location:
/k/kde5/src/kcoreaddons/src/lib/io/kdirwatch_p.h:83
{
time_t m_ctime; // member offset: 0, size: 8, alignment: 8
int m_nlink; // member offset: 8, size: 4, alignment: 4
// 4 byte(s) padding
ino_t m_ino; // member offset: 16, size: 8, alignment: 8
entryStatus m_status; // member offset: 24, size: 4, alignment: 4
entryMode m_mode; // member offset: 28, size: 4, alignment: 4
bool isDir; // member offset: 32, size: 1, alignment: 1
// 7 byte(s) padding
QListKDirWatchPrivate::Client* m_clients; // member offset: 40, size:
8, alignment: 8
QListKDirWatchPrivate::Entry* m_entries; // member offset: 48, size: 8,
alignment: 8
QString path; // member offset: 56, size: 8, alignment: 8
int msecLeft; // member offset: 64, size: 4, alignment: 4
int freq; // member offset: 68, size: 4, alignment: 4
bool dirty; // member offset: 72, size: 1, alignment: 1
// 3 byte(s) padding
int wd; // member offset: 76, size: 4, alignment: 4
QListQString m_pendingFileChanges; // member offset: 80, size: 8,
alignment: 8
}; // size: 88, alignment: 8
Struct KJobPrivate (DW_TAG_class_type, offset 1112242) is sub-optimally
packed: 95/120 bytes, 760/960 bits, optimal size is: 96 bytes
class KJobPrivate // location:
/k/kde5/src/kcoreaddons/src/lib/jobs/kjob_p.h:36
{
__vtbl_ptr_type* _vptr.KJobPrivate; // member offset: 0, size: 8,
alignment: 8
KJob* q_ptr; // member offset: 8, size: 8, alignment: 8
KJobUiDelegate* uiDelegate; // member offset: 16, size: 8, alignment: 8
int error; // member offset: 24, size: 4, alignment: 4
// 4 byte(s) padding
QString errorText; // member offset: 32, size: 8, alignment: 8
Unit progressUnit; // member offset: 40, size: 4, alignment: 4
// 4 byte(s) padding
QMapKJob::Unit, long long unsigned int processedAmount; // member
offset: 48, size: 8, alignment: 8
QMapKJob::Unit, long long unsigned int totalAmount; // member offset:
56, size: 8, alignment: 8
long unsigned int percentage; // member offset: 64, size: 8, alignment: 8
bool suspended; // member offset: 72, size: 1, alignment: 1
// 3 byte(s) padding
Capabilities capabilities; // member offset: 76, size: 4, alignment: 4
QTimer* speedTimer; // member offset: 80, size: 8, alignment: 8
bool isAutoDelete; // member offset: 88, size: 1, alignment: 1
// 7 byte(s) padding
QEventLoop* eventLoop; // member offset: 96, size: 8, alignment: 8
QEventLoopLocker eventLoopLocker; // member offset: 104, size: 8,
alignment: 8
bool isFinished; // member offset: 112, size: 1, alignment: 1
// 7 byte(s) padding
}; // size: 120, alignment: 8
Struct KPluginLoaderPrivate (DW_TAG_class_type, offset 1584914) is
sub-optimally packed: 37/48 bytes, 296/384 bits, optimal size is: 40 bytes
class KPluginLoaderPrivate // location:
/k/kde5/src/kcoreaddons/src/lib/plugin/kpluginloader.cpp:37
{
KPluginLoader* q_ptr; // member offset: 0, size: 8, alignment: 8
QString const name; // member offset: 8, size: 8, alignment: 8
quint32 pluginVersion; // member offset: 16, size: 4, alignment: 4
// 4 byte(s) padding
QString errorString; // member offset: 24, size: 8, alignment: 8
bool pluginVersionResolved; // member offset: 32, size: 1, alignment: 1
// 7 byte(s) padding
QPluginLoader* loader; // member offset: 40, size: 8, alignment: 8
}; // size: 48, alignment: 8
```
Thanks,
Volker Krause
___
Kde-frameworks-devel
Re: C++11 policy in frameworks?
https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
thought this was clang 3.7 maybe I'm confused though This is (should not) be a problem with the compiler version - this is a library function. Which version of libc++ is it using? (it might be using the old system's one instead of the latest release or something) Cheerio, Ivan On 8 February 2015 at 21:59, Jeremy Whiting jpwhit...@kde.org wrote: https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122487: Reorder member variables to reduce memory usage.
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122487/
---
Review request for KDE Frameworks.
Repository: kcoreaddons
Description
---
The KJobPrivate one saves 24 bytes per instance, the others 8 bytes (on a 64
bit system).
Diffs
-
src/lib/io/kdirwatch_p.h f8cc2bcd5b9a8c65b409873ac78455fbb7db2405
src/lib/jobs/kjob.cpp de3b8d7c8985dcc21ef9f52fba47361e9675f192
src/lib/jobs/kjob_p.h 8bacefecc4dc8d2679a48b224837e0c01516d601
src/lib/plugin/kpluginloader.cpp 64d7f0cec37ef51a76a3a60637822810cab398e6
Diff: https://git.reviewboard.kde.org/r/122487/diff/
Testing
---
```
Struct Entry (DW_TAG_class_type, offset 393887) is sub-optimally packed:
74/88 bytes, 592/704 bits, optimal size is: 80 bytes
class KDirWatchPrivate::Entry // location:
/k/kde5/src/kcoreaddons/src/lib/io/kdirwatch_p.h:83
{
time_t m_ctime; // member offset: 0, size: 8, alignment: 8
int m_nlink; // member offset: 8, size: 4, alignment: 4
// 4 byte(s) padding
ino_t m_ino; // member offset: 16, size: 8, alignment: 8
entryStatus m_status; // member offset: 24, size: 4, alignment: 4
entryMode m_mode; // member offset: 28, size: 4, alignment: 4
bool isDir; // member offset: 32, size: 1, alignment: 1
// 7 byte(s) padding
QListKDirWatchPrivate::Client* m_clients; // member offset: 40, size: 8,
alignment: 8
QListKDirWatchPrivate::Entry* m_entries; // member offset: 48, size: 8,
alignment: 8
QString path; // member offset: 56, size: 8, alignment: 8
int msecLeft; // member offset: 64, size: 4, alignment: 4
int freq; // member offset: 68, size: 4, alignment: 4
bool dirty; // member offset: 72, size: 1, alignment: 1
// 3 byte(s) padding
int wd; // member offset: 76, size: 4, alignment: 4
QListQString m_pendingFileChanges; // member offset: 80, size: 8,
alignment: 8
}; // size: 88, alignment: 8
Struct KJobPrivate (DW_TAG_class_type, offset 1112242) is sub-optimally
packed: 95/120 bytes, 760/960 bits, optimal size is: 96 bytes
class KJobPrivate // location: /k/kde5/src/kcoreaddons/src/lib/jobs/kjob_p.h:36
{
__vtbl_ptr_type* _vptr.KJobPrivate; // member offset: 0, size: 8,
alignment: 8
KJob* q_ptr; // member offset: 8, size: 8, alignment: 8
KJobUiDelegate* uiDelegate; // member offset: 16, size: 8, alignment: 8
int error; // member offset: 24, size: 4, alignment: 4
// 4 byte(s) padding
QString errorText; // member offset: 32, size: 8, alignment: 8
Unit progressUnit; // member offset: 40, size: 4, alignment: 4
// 4 byte(s) padding
QMapKJob::Unit, long long unsigned int processedAmount; // member offset:
48, size: 8, alignment: 8
QMapKJob::Unit, long long unsigned int totalAmount; // member offset: 56,
size: 8, alignment: 8
long unsigned int percentage; // member offset: 64, size: 8, alignment: 8
bool suspended; // member offset: 72, size: 1, alignment: 1
// 3 byte(s) padding
Capabilities capabilities; // member offset: 76, size: 4, alignment: 4
QTimer* speedTimer; // member offset: 80, size: 8, alignment: 8
bool isAutoDelete; // member offset: 88, size: 1, alignment: 1
// 7 byte(s) padding
QEventLoop* eventLoop; // member offset: 96, size: 8, alignment: 8
QEventLoopLocker eventLoopLocker; // member offset: 104, size: 8,
alignment: 8
bool isFinished; // member offset: 112, size: 1, alignment: 1
// 7 byte(s) padding
}; // size: 120, alignment: 8
Struct KPluginLoaderPrivate (DW_TAG_class_type, offset 1584914) is
sub-optimally packed: 37/48 bytes, 296/384 bits, optimal size is: 40 bytes
class KPluginLoaderPrivate // location:
/k/kde5/src/kcoreaddons/src/lib/plugin/kpluginloader.cpp:37
{
KPluginLoader* q_ptr; // member offset: 0, size: 8, alignment: 8
QString const name; // member offset: 8, size: 8, alignment: 8
quint32 pluginVersion; // member offset: 16, size: 4, alignment: 4
// 4 byte(s) padding
QString errorString; // member offset: 24, size: 8, alignment: 8
bool pluginVersionResolved; // member offset: 32, size: 1, alignment: 1
// 7 byte(s) padding
QPluginLoader* loader; // member offset: 40, size: 8, alignment: 8
}; // size: 48, alignment: 8
```
Thanks,
Volker Krause
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C++11 policy in frameworks?
Qt supports 10.7 though so maybe we shouldn't be using these newer c++11 methods in frameworks just yet right? As seen on the 'policies' page, we are not tied to all the platforms that are supported by Qt. This was decided in the thread named Supported Compilers / C++11 Support in KF5, started by Volker on 21/07/2013. I'd say that, by specifying the compiler versions, we have implicitly stated that the requirements are also their respective standard library implementations. That is, if gcc 4.5 is a requirement, one should not try to compile with gcc 4.5 and a version of libstdc++ that was released a few years before gcc 4.5 went gold. The same goes for clang and msvcc. Cheers, Ivan Cheerio, Ivan On 8 February 2015 at 22:45, Jeremy Whiting jpwhit...@kde.org wrote: Yeah it's using the newest xcode for is x 10.7 so the libc++ is probably older, Qt supports 10.7 though so maybe we shouldn't be using these newer c++11 methods in frameworks just yet right? On Feb 8, 2015 2:04 PM, Ivan Čukić ivan.cu...@kde.org wrote: thought this was clang 3.7 maybe I'm confused though This is (should not) be a problem with the compiler version - this is a library function. Which version of libc++ is it using? (it might be using the old system's one instead of the latest release or something) Cheerio, Ivan On 8 February 2015 at 21:59, Jeremy Whiting jpwhit...@kde.org wrote: https://trac.macports.org/browser/trunk/dports/lang/llvm-3.7/Portfile I thought this was clang 3.7 maybe I'm confused though On Feb 8, 2015 1:39 PM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 8 de febrer de 2015, a les 09:55:05, Jeremy Whiting va escriure: Hey all, In trying to get kf5 built on an older machine with clang 3.7 I've hit an isuse with kdeclarative. clang 2.7 or 3.7? 3.7 is still unreleased, no? Cheers, Albert A few days ago some code was checked into it that uses std::lround which isn't available on clang's stdlib implementation yet. Should this change to floor or ciel, or is there an #ifdef we can put around it depending if C++11 support is available when building? Or is C++11 not allowed in frameworks yet (just applications) so it should be changed to use some other method to round the values (floor(value + 0.5) or something similar)? thanks, Jeremy ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Cheerio, Ivan -- While you were hanging yourself on someone else's words Dying to believe in what you heard I was staring straight into the shining sun ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122481: Fix use of environ for OS X
On Feb. 8, 2015, 5:44 p.m., René J.V. Bertin wrote: src/widgets/kurlcompletion.cpp, line 836 https://git.reviewboard.kde.org/r/122481/diff/1/?file=347903#file347903line836 Qt5 has Q_OS_OSX to target OS X rather than a Mac OS (which according to Qt includes iOS). For code that will never run on iOS it might be better to use Q_OS_OSX from the onset. I'd say Ship It, but that would be a little presumptuous for someone who's been shying away from so much as trying to build a single KF5 something :) - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/#review75613 --- On Feb. 8, 2015, 11:06 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- (Updated Feb. 8, 2015, 11:06 p.m.) Review request for KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122462: [KCompletion] Fix typos in documentation
On feb. 7, 2015, 7:14 p.m., Dominik Haumann wrote: Using two spaces is called sentence spacing and most probably done by intention, see http://en.wikipedia.org/wiki/Sentence_spacing So this is a matter of taste, and should not be changed especially in the licensing headers. KDE typically use the license headers from the GNU homepage, and there the two spaces are also used. (In fact, there are git hooks that make sure you add a license to your code if you add a file in git. Changing unnecessarily the header might even break such commit hooks.) In this patch, I think changing re-implemented to reimplemented is what can be committed, but please update the review request for that first :-) You can have a look at the generated doxygen output at e.g. http://api.kde.org/frameworks-api/frameworks5-apidocs/kcompletion/html/classKComboBox.html#ae14aa07f44ab4ef1767586afe592155c As you can see, the two spaces are folded into just one space by doxygen. If you fix doxygen comments, please do it based on the resulting output on api.kde.org :-) Hi! Using two spaces is called sentence spacing and most probably done by intention, see http://en.wikipedia.org/wiki/Sentence_spacing; I know what's sentence spacing. I spent five years at University studying Translation (German, English, Catalan and Spanish, and I speak Dutch and learned some Basque). At the time, languages were my life. Now I prefer computers. In this patch, I think changing re-implemented to reimplemented is what can be committed, Only that? What about the other changes? You can have a look at the generated doxygen output at e.g. http://api.kde.org/frameworks-api/frameworks5-apidocs/kcompletion/html/classKComboBox.html#ae14aa07f44ab4ef1767586afe592155c As you can see, the two spaces are folded into just one space by doxygen. If you fix doxygen comments, please do it based on the resulting output on api.kde.org :-) You say that as if only output mattered and doxygen comments weren't read and couldn't be changed. I read doxygen comments far more often than the output in api.kde.org. On feb. 7, 2015, 7:14 p.m., Dominik Haumann wrote: src/kcombobox.h, line 13 https://git.reviewboard.kde.org/r/122462/diff/1/?file=347378#file347378line13 Please do not change the two spaces to a single one, especially not in the license (we might have scripts parsing the headers for licenses, and we should not change the license from what you can find on the gnu homepage). I agree on this one, but more for a technical reason than a linguistic one. On feb. 7, 2015, 7:14 p.m., Dominik Haumann wrote: src/kcombobox.h, line 60 https://git.reviewboard.kde.org/r/122462/diff/1/?file=347378#file347378line60 Doxygen is fine with these two spaces as well... (everywhere). Let's see, that doxygen converts the two spaces into one makes me think that it's ok to have one also in doxygen comments. Moreover, if it was a matter of taste (which I kind of doubt) then it would be great, because I'm the maintainer of the framework and I hate double spacing. If it was a matter of taste, again, then I have a powerful reason to kill the double spacing. There's a second thing we translators hate most (first one is typos and bad grammar) and it is when texts are not coherent. If you read all the doxygen comments in KCompletion, you'll find double spacing mixed with single spacing, and that's awful. Finally, I'm more on the double-spacing-is-not-needed-anymore side :-) : http://www.slate.com/articles/technology/technology/2011/01/space_invaders.html - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122462/#review75573 --- On feb. 6, 2015, 11:03 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122462/ --- (Updated feb. 6, 2015, 11:03 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Fix typos in documentation - Substitute double space after period for single space - emition -- emission - Re-implemented -- Reimplemented Diffs - src/kcombobox.h 075d42f src/kcompletion.h a6ed372 src/kcompletion_p.h 138c228 src/kcompletionbase.h 6111f9a src/kcompletionbox.h 1759eba src/kcompletionmatches.h 517f111 src/khistorycombobox.h 182ba0a src/klineedit.h 460a2ae src/klineedit_p.h 0be32ba src/kpixmapprovider.h 67917f2 src/ksortablelist.h 8b1b155 src/kzoneallocator_p.h 2d75a83 Diff: https://git.reviewboard.kde.org/r/122462/diff/ Testing --- None needed Thanks, David Gil Oliva
Re: Review Request 122462: [KCompletion] Fix typos in documentation
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122462/ --- (Updated feb. 8, 2015, 10:46 p.m.) Review request for KDE Frameworks. Changes --- Undo the changes in license headers. Repository: kcompletion Description --- Fix typos in documentation - Substitute double space after period for single space - emition -- emission - Re-implemented -- Reimplemented Diffs (updated) - src/kcombobox.h 075d42f src/kcompletion.h a6ed372 src/kcompletion_p.h 138c228 src/kcompletionbase.h 6111f9a src/kcompletionbox.h 1759eba src/klineedit.h 460a2ae src/kzoneallocator_p.h 2d75a83 Diff: https://git.reviewboard.kde.org/r/122462/diff/ Testing --- None needed Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122493: Use math.h round rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122481: Fix use of environ for OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/#review75645 --- Why not port to `http://doc.qt.io/qt-5/qprocessenvironment.html#systemEnvironment` instead? Looks like you could get rid off the string conversion/parsing here. - Kevin Funk On Feb. 8, 2015, 10:06 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- (Updated Feb. 8, 2015, 10:06 p.m.) Review request for KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75648 --- -1 You use C-Style casts. Oke, the frameworks coding style doesn't seem to explicitly forbid it (casts are not mentioned), but if i recall correctly we use the Qt style + some of our own which means we should obey the Qt style [1] which does mention casts and forbids the C-Sytle cast. Secondly, you seem to be trying to get this working on a compiler that isn't supported [2]. If one of those compilers have issues with std::lround (which i seriously doubt) then we should perhaps look into replacing it with qRound. However, Qt is also moving away from it's own algorithms in favor of the stl ones so we should stick to the std:: versions. Cheers [1] http://qt-project.org/wiki/Qt_Coding_Style [2] https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 - Mark Gaiser On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122481: Fix use of environ for OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/#review75661 --- Ship it! Nice! - David Faure On Feb. 9, 2015, 3:24 a.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- (Updated Feb. 9, 2015, 3:24 a.m.) Review request for KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 122495: CMake nitpicking on KDiagram
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122495/ --- Review request for KDE Frameworks and Friedrich W. H. Kossebau. Repository: kdiagram Description --- Mark Qt5::Widgets public for both KCharts and KGantt. Remove SHARED from add_library, let cmake use the default (which is SHARED, but the user can configure). Fix some indentation. Remove redundant dependencies: if we depend on Qt5::Widgets, we're already pulling Qt5::Gui. Diffs - src/KChart/CMakeLists.txt 06f3846 src/KGantt/CMakeLists.txt 25d198f CMakeLists.txt 76a7c50 Diff: https://git.reviewboard.kde.org/r/122495/diff/ Testing --- Still builds. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122493: Use math.h round rather than C++11 std::lround.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/#review75646 --- `qRound`? - Kevin Funk On Feb. 8, 2015, 11:12 p.m., Jeremy Whiting wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122493/ --- (Updated Feb. 8, 2015, 11:12 p.m.) Review request for KDE Frameworks and Marco Martin. Repository: kdeclarative Description --- Use math.h round rather than C++11 std::lround. Removes dependency on C++11. Diffs - src/qmlcontrols/kquickcontrolsaddons/plotter.cpp 67ce63a943234b167165b0f3986f974bba5ff0cf Diff: https://git.reviewboard.kde.org/r/122493/diff/ Testing --- kdeclarative is able to build on OS X 10.7 with the built in XCode compiler and standard library. Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 122487: Reorder member variables to reduce memory usage.
On Feb. 8, 2015, 9:45 p.m., David Faure wrote:
Which magic tool did you come up with this time, to detect such things? :-)
+1 :D I too want to know!
- Aleix
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122487/#review75629
---
On Feb. 8, 2015, 9:28 p.m., Volker Krause wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/122487/
---
(Updated Feb. 8, 2015, 9:28 p.m.)
Review request for KDE Frameworks.
Repository: kcoreaddons
Description
---
The KJobPrivate one saves 24 bytes per instance, the others 8 bytes (on a 64
bit system).
Diffs
-
src/lib/io/kdirwatch_p.h f8cc2bcd5b9a8c65b409873ac78455fbb7db2405
src/lib/jobs/kjob.cpp de3b8d7c8985dcc21ef9f52fba47361e9675f192
src/lib/jobs/kjob_p.h 8bacefecc4dc8d2679a48b224837e0c01516d601
src/lib/plugin/kpluginloader.cpp 64d7f0cec37ef51a76a3a60637822810cab398e6
Diff: https://git.reviewboard.kde.org/r/122487/diff/
Testing
---
```
Struct Entry (DW_TAG_class_type, offset 393887) is sub-optimally packed:
74/88 bytes, 592/704 bits, optimal size is: 80 bytes
class KDirWatchPrivate::Entry // location:
/k/kde5/src/kcoreaddons/src/lib/io/kdirwatch_p.h:83
{
time_t m_ctime; // member offset: 0, size: 8, alignment: 8
int m_nlink; // member offset: 8, size: 4, alignment: 4
// 4 byte(s) padding
ino_t m_ino; // member offset: 16, size: 8, alignment: 8
entryStatus m_status; // member offset: 24, size: 4, alignment: 4
entryMode m_mode; // member offset: 28, size: 4, alignment: 4
bool isDir; // member offset: 32, size: 1, alignment: 1
// 7 byte(s) padding
QListKDirWatchPrivate::Client* m_clients; // member offset: 40, size:
8, alignment: 8
QListKDirWatchPrivate::Entry* m_entries; // member offset: 48, size: 8,
alignment: 8
QString path; // member offset: 56, size: 8, alignment: 8
int msecLeft; // member offset: 64, size: 4, alignment: 4
int freq; // member offset: 68, size: 4, alignment: 4
bool dirty; // member offset: 72, size: 1, alignment: 1
// 3 byte(s) padding
int wd; // member offset: 76, size: 4, alignment: 4
QListQString m_pendingFileChanges; // member offset: 80, size: 8,
alignment: 8
}; // size: 88, alignment: 8
Struct KJobPrivate (DW_TAG_class_type, offset 1112242) is sub-optimally
packed: 95/120 bytes, 760/960 bits, optimal size is: 96 bytes
class KJobPrivate // location:
/k/kde5/src/kcoreaddons/src/lib/jobs/kjob_p.h:36
{
__vtbl_ptr_type* _vptr.KJobPrivate; // member offset: 0, size: 8,
alignment: 8
KJob* q_ptr; // member offset: 8, size: 8, alignment: 8
KJobUiDelegate* uiDelegate; // member offset: 16, size: 8, alignment: 8
int error; // member offset: 24, size: 4, alignment: 4
// 4 byte(s) padding
QString errorText; // member offset: 32, size: 8, alignment: 8
Unit progressUnit; // member offset: 40, size: 4, alignment: 4
// 4 byte(s) padding
QMapKJob::Unit, long long unsigned int processedAmount; // member
offset: 48, size: 8, alignment: 8
QMapKJob::Unit, long long unsigned int totalAmount; // member offset:
56, size: 8, alignment: 8
long unsigned int percentage; // member offset: 64, size: 8, alignment: 8
bool suspended; // member offset: 72, size: 1, alignment: 1
// 3 byte(s) padding
Capabilities capabilities; // member offset: 76, size: 4, alignment: 4
QTimer* speedTimer; // member offset: 80, size: 8, alignment: 8
bool isAutoDelete; // member offset: 88, size: 1, alignment: 1
// 7 byte(s) padding
QEventLoop* eventLoop; // member offset: 96, size: 8, alignment: 8
QEventLoopLocker eventLoopLocker; // member offset: 104, size: 8,
alignment: 8
bool isFinished; // member offset: 112, size: 1, alignment: 1
// 7 byte(s) padding
}; // size: 120, alignment: 8
Struct KPluginLoaderPrivate (DW_TAG_class_type, offset 1584914) is
sub-optimally packed: 37/48 bytes, 296/384 bits, optimal size is: 40 bytes
class KPluginLoaderPrivate // location:
/k/kde5/src/kcoreaddons/src/lib/plugin/kpluginloader.cpp:37
{
KPluginLoader* q_ptr; // member offset: 0, size: 8, alignment: 8
QString const name; // member offset: 8, size: 8, alignment: 8
quint32 pluginVersion; // member offset: 16, size: 4, alignment: 4
// 4 byte(s) padding
QString errorString; // member offset: 24, size: 8, alignment: 8
bool pluginVersionResolved; // member offset: 32, size: 1, alignment: 1
// 7 byte(s) padding
QPluginLoader* loader; // member offset: 40, size: 8, alignment: 8
}; // size: 48, alignment: 8
```
Thanks,
Volker Krause
Re: Review Request 122481: Fix use of environ for OS X
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/122481/ --- (Updated Feb. 8, 2015, 8:24 p.m.) Review request for KDE Frameworks, David Faure, Marko Käning, and René J.V. Bertin. Changes --- Thanks for the idea, changed to use QProcessEnvironment. Repository: kio Description --- On OS X 10.7 environ needs to be #defined as _NSGetEnviron() from crt_externs.h according to man environ. This is also required for kio to build on OS X 10.7 Diffs (updated) - src/widgets/kurlcompletion.cpp 1871c49a936e2ca322286e23ad6fe976ae2c7044 Diff: https://git.reviewboard.kde.org/r/122481/diff/ Testing --- kio builds with this patch on OS X 10.7 and 10.10 Thanks, Jeremy Whiting ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: strange problem with KConfig
On February 5, 2015 08:49:16 PM Marco Martin wrote:
Hi all,
I was investigating this bug..
https://bugs.kde.org/show_bug.cgi?id43583
but after digging and digging, it looks like more and more an issue in
KConfig..
basically if there is a config file in a system-wide location (to give
default configs that would then be overridden by whatever other value in
~/.config)
I've investigated this further, and it does appear to be a bug in KConfig. I
did some reductions on the look and feel kcm, to find what code responsible.
It appears the foreach loop in krdb.cpp on line 683 triggers the funny writes.
As that loop doesn't do anything odd, KConfig is definitely responsible.
Hopefully this can be reduced down to a test case and then fixed.
However, I think the bug can be worked around in the short term for the kcm by
having the KSharedConfigs in question use only the file they are pointed at.
I think that is actually the correct behaviour, as those files are not
supposed to use the global or system configuration files. I've attached a
(relatively untested) sample patch. It fixes the bug, but I'm not sure if it
allows the kcm to continue functioning as expected.
--
Matthewdiff --git a/kcms/krdb/krdb.cpp b/kcms/krdb/krdb.cpp
index 6838b21..5d92019 100644
--- a/kcms/krdb/krdb.cpp
+++ b/kcms/krdb/krdb.cpp
@@ -634,7 +634,7 @@ void runRdb( uint flags )
return;
}
- KConfig kde4config(configFilePath);
+ KConfig kde4config(configFilePath, KConfig::SimpleConfig);
KConfigGroup kde4generalGroup(kde4config, General);
kde4generalGroup.writeEntry(ColorScheme, colorSchemeName);
@@ -677,7 +677,7 @@ void runRdb( uint flags )
kde4IconGroup.sync();
//copy all the groups in the color scheme in kdeglobals
- KSharedConfigPtr kde4ColorConfig = KSharedConfig::openConfig(src);
+ KSharedConfigPtr kde4ColorConfig = KSharedConfig::openConfig(src, KConfig::SimpleConfig);
foreach (const QString grp, kde4ColorConfig-groupList()) {
KConfigGroup cg(kde4ColorConfig, grp);
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
