Re: Review Request 115932: Add declarative plugin for KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Changes --- I couldn't reasonably tell what would be useful and what not, so I added Q_INVOKABLE to about everything. Plus the example. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs (updated) - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116087: KCrash: remove usage of strlcpy
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/#review51008 --- Ship it! The QByteArray clearly has the same lifetime as the argv array itself, so should be fine. - Alex Merry On Feb. 26, 2014, 5 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116087/ --- (Updated Feb. 26, 2014, 5 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- remove usage of strlcpy That copy was actually unnecessary, incrementing the refcount on QByteArray and then calling constData() is enough Diffs - src/kcrash.cpp 6c41022206130f186d52ddbb77afd58c429f368f src/strlcpy-fake.c 9b2dc68c466908d11370ba0c4bbe8d315962da5d src/CMakeLists.txt d19b97f98e057d5537cf0eb6a8e1997d2a24cb1e src/config-strlcpy.h.cmake 5d9163d7a60d89b9792afcdf498af6425a9038a8 Diff: https://git.reviewboard.kde.org/r/116087/diff/ Testing --- Compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116090: Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116090/#review51010
---
The problem with doing this in support code is that it is not strictly source
compatible. An example this would break is if you want to embed the value of
QT_QMAKE_EXECUTABLE into a C++ executable using something like
add_definitions(-DQMAKE=\${QT_QMAKE_EXECUTABLE}\)
Any use of QMAKE in the program would then expand to
$TARGET_FILE:Qt5::qmake, which is obviously not what was wanted.
- Alex Merry
On Feb. 26, 2014, 5:03 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116090/
---
(Updated Feb. 26, 2014, 5:03 p.m.)
Review request for KDE Frameworks.
Repository: kde4support
Description
---
Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
This means CMake no longer warns about Policy CMP0026 is not set when
building projects that need kde4support
Diffs
-
cmake/modules/ECMQt4To5Porting.cmake
4204fa541790aa38c74b9d6f0b2111af2157b2bc
cmake/modules/KDE4Macros.cmake 192094b1c5c6877cd9dfa18dc27338c491d753f3
src/CMakeLists.txt 6bda0996c118ce212860e02d0505fd3bdc026833
src/KDEUIMacros.cmake 1570df340a672a597a0b7480885c340faca0069d
Diff: https://git.reviewboard.kde.org/r/116090/diff/
Testing
---
kde4support compiles, kde-workspace compiles
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. - Martin Gräßlin On Feb. 27, 2014, 10:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116098: Use KDEInstallDirs
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/#review51012 --- This is largely a policy decision for the maintainers: KDEInstallDirs is really just one more file layout policy, like GNUInstallDirs. I think KDEInstallDirs makes more sense than GNUInstallDirs for Qt-based code in general, though. If you're going to use it, though, I suggest using it consistently (eg: for include files as well). - Alex Merry On Feb. 26, 2014, 7:17 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116098/ --- (Updated Feb. 26, 2014, 7:17 p.m.) Review request for KDE Frameworks. Repository: libnm-qt Description --- When I build libnm-qt on my openSuSE 64bit system libnm-qt ends up installing into $prefix/lib instead of $prefix/lib64. I know this can be fixed using -DLIB_SUFFIX=64, but KDEInstallDirs already handles this so why not use it. E-C-M is already required, so that is no problem. Not sure however whether it is okay to use one of the KDE modules for libnm-qt. If not I will update this request to use GNUInstallDirs which also handles the openSuSE case. Not sure who is responsible for the qt5 branch, so I just added kdeframeworks as reviewers. Diffs - CMakeLists.txt 9918278 NetworkManagerQt.pc.cmake 2c3ab07 Diff: https://git.reviewboard.kde.org/r/116098/diff/ Testing --- Installed into the right directories after applying the patch. grep -irn LIB_SUFFIX * returns nothing Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 9:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. - Ivan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 9:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 9:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 9:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Ivan Čukić wrote: My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. What do you guys think about a data model for windows, filterable against screen, desktop, activity containing things like title, icon, position/size, ... that would be a properly behaving model? That way, it would be awesomely trivial to connect it to window thumbnail items and so on. Yes, I am volunteering :) - Ivan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 9:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 9:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-doc-english] Core documentation repository
On 26/02/14 23:45, T.C. Hollingsworth wrote: So, perhaps we need a kde-core-docs.git or something like that to house them in? And advise distros to make sure and add runtime Requires on it from kdoctools or whereever the help: kioslave is shipped? (Alternatively we could just include them in kdoctools.git, but there might be a bit of a chicken and egg problem keeping docbooks there?) Technically there is already some documentation in kdoctools, exactly as we had it kdelibs, so it could be included here. Oh yeah, d'oh! :-) In that case I'm fine with just keeping it in kdoctools if that works for everyone else. KDocTools seems like the obvious location to me... Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KActivities frameworks soon to become master
Hi all, Now that the 4.13 has been branched out, KActivities will stop using the frameworks branch, and master will become the 'new black'. There is only a question of how to proceed. - Is it wiser just to ask the admins to move rename the branches (removing the old master) and blacklist the frameworks branch? - Should anything apart from the relevant file in kdesrc-build be changed? - Who are interested parties that this should be communicated to? 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 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 10:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Ivan Čukić wrote: My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. Ivan Čukić wrote: What do you guys think about a data model for windows, filterable against screen, desktop, activity containing things like title, icon, position/size, ... that would be a properly behaving model? That way, it would be awesomely trivial to connect it to window thumbnail items and so on. Yes, I am volunteering :) What do you guys think about a data model for windows we have that in KWin, feel free to take it as a base (kwin/scripting/scripting_model.(hcpp)). As I'm the only copyright holder I allow the relicense to the frameworks license. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 10:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 10:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Ivan Čukić wrote: My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. Ivan Čukić wrote: What do you guys think about a data model for windows, filterable against screen, desktop, activity containing things like title, icon, position/size, ... that would be a properly behaving model? That way, it would be awesomely trivial to connect it to window thumbnail items and so on. Yes, I am volunteering :) Martin Gräßlin wrote: What do you guys think about a data model for windows we have that in KWin, feel free to take it as a base (kwin/scripting/scripting_model.(hcpp)). As I'm the only copyright holder I allow the relicense to the frameworks license. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Yeah, can do that. I think the example app needs to be more complete Well it's an example app, showing how to use the declarative plugin...does it really need to go over all the methods? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 10:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 10:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Ivan Čukić wrote: My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. Ivan Čukić wrote: What do you guys think about a data model for windows, filterable against screen, desktop, activity containing things like title, icon, position/size, ... that would be a properly behaving model? That way, it would be awesomely trivial to connect it to window thumbnail items and so on. Yes, I am volunteering :) Martin Gräßlin wrote: What do you guys think about a data model for windows we have that in KWin, feel free to take it as a base (kwin/scripting/scripting_model.(hcpp)). As I'm the only copyright holder I allow the relicense to the frameworks license. Martin Klapetek wrote: Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Yeah, can do that. I think the example app needs to be more complete Well it's an example app, showing how to use the declarative plugin...does it really need to go over all the methods? does it really need to go over all the methods? how do you make sure that the methods actually work without ever writing a test QML script? As said I don't think those methods with enums will work in QML. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 10:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 10:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Ivan Čukić wrote: My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. Ivan Čukić wrote: What do you guys think about a data model for windows, filterable against screen, desktop, activity containing things like title, icon, position/size, ... that would be a properly behaving model? That way, it would be awesomely trivial to connect it to window thumbnail items and so on. Yes, I am volunteering :) Martin Gräßlin wrote: What do you guys think about a data model for windows we have that in KWin, feel free to take it as a base (kwin/scripting/scripting_model.(hcpp)). As I'm the only copyright holder I allow the relicense to the frameworks license. Martin Klapetek wrote: Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Yeah, can do that. I think the example app needs to be more complete Well it's an example app, showing how to use the declarative plugin...does it really need to go over all the methods? Martin Gräßlin wrote: does it really need to go over all the methods? how do you make sure that the methods actually work without ever writing a test QML script? As said I don't think those methods with enums will work in QML. QML also doesn't like WId...can it be safely transformed back and forth to long? - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 10:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 10:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Ivan Čukić wrote: My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. Ivan Čukić wrote: What do you guys think about a data model for windows, filterable against screen, desktop, activity containing things like title, icon, position/size, ... that would be a properly behaving model? That way, it would be awesomely trivial to connect it to window thumbnail items and so on. Yes, I am volunteering :) Martin Gräßlin wrote: What do you guys think about a data model for windows we have that in KWin, feel free to take it as a base (kwin/scripting/scripting_model.(hcpp)). As I'm the only copyright holder I allow the relicense to the frameworks license. Martin Klapetek wrote: Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Yeah, can do that. I think the example app needs to be more complete Well it's an example app, showing how to use the declarative plugin...does it really need to go over all the methods? Martin Gräßlin wrote: does it really need to go over all the methods? how do you make sure that the methods actually work without ever writing a test QML script? As said I don't think those methods with enums will work in QML. Martin Klapetek wrote: QML also doesn't like WId...can it be safely transformed back and forth to long? the API needs to stay as WId. I don't know how one could transform it to make QML happy. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 10:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kprintutils - next steps
On 23 February 2014 20:02, John Layt jl...@kde.org wrote: I believe the steps required are: 1) Port existing apps that are already ported to KF5 away from KdePrint::createPrintDialog(): - Okteta - kfontinst - ktexteditor - None use KPrintPreview This has been done, all frameworks code as built by kdesrc-build has had the dependency removed. 2) Copy code from kprintutils to kde4support - Do we bother to keep the history? - Where do we put it? Alex, if you have that git magic I'd appreciate your doing it, I have no clue what to do :-) I'm not sure whether we should put it back into kde4support/src/kdeui where it originally came from or kde4support/src/kprintutils? 3) Update porting guide I've updated http://community.kde.org/Frameworks/Porting_Notes#KDEUI_Changes Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115932: Add declarative plugin for KWindowSystem
On Feb. 27, 2014, 10:54 a.m., Martin Gräßlin wrote: I think the example app needs to be more complete as I doubt that everything here would just work (e.g. the States). If you are unsure about how that should work I can schedule some time for it. Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Ivan Čukić wrote: My thoughts exactly. One thing I was thinking about is to create a qml api that is not mirroring the actual c++ api. It is not really object/property oriented. Ivan Čukić wrote: What do you guys think about a data model for windows, filterable against screen, desktop, activity containing things like title, icon, position/size, ... that would be a properly behaving model? That way, it would be awesomely trivial to connect it to window thumbnail items and so on. Yes, I am volunteering :) Martin Gräßlin wrote: What do you guys think about a data model for windows we have that in KWin, feel free to take it as a base (kwin/scripting/scripting_model.(hcpp)). As I'm the only copyright holder I allow the relicense to the frameworks license. Martin Klapetek wrote: Would it be possible to add some Q_PROPRERTIES to the class? E.g. numberOfDesktops or currentDesktop might make more sense with a property instead INVOKABLE. Yeah, can do that. I think the example app needs to be more complete Well it's an example app, showing how to use the declarative plugin...does it really need to go over all the methods? Martin Gräßlin wrote: does it really need to go over all the methods? how do you make sure that the methods actually work without ever writing a test QML script? As said I don't think those methods with enums will work in QML. Martin Klapetek wrote: QML also doesn't like WId...can it be safely transformed back and forth to long? Martin Gräßlin wrote: the API needs to stay as WId. I don't know how one could transform it to make QML happy. ivan|home mck182: don't do anything - we are going to replace it :) mck182 well I imagine these would be complementary? ivan|home i don't know - I'd rather go first for the model, and then see what is missing from the api ivan|home instead of having it duplicated ivan|home the approach I took for kactivities is - model, and then add mothods like setCurrentActivity and stuff to it ...so I'm stopping the work on this for now. Truth is I don't need it anymore and I was just going to finish what I started. So I'll wait what Ivan will come up with and then continue or discard this. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/#review51011 --- On Feb. 27, 2014, 10:23 a.m., Martin Klapetek wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115932/ --- (Updated Feb. 27, 2014, 10:23 a.m.) Review request for KDE Frameworks and Martin Gräßlin. Repository: kwindowsystem Description --- Adds a declarative plugin usable from QML. Usage is as easy as KWindowSystem.workArea(0) in QML. So far only the workArea is accessible, not sure which other methods should be. All of them? I've made the import version to match the framework version, so you'd do import org.kde.kwindowsystem 5.0 Diffs - declarative/kwindowsystemplugin.h PRE-CREATION CMakeLists.txt cbae838 declarative/CMakeLists.txt PRE-CREATION declarative/kwindowsystemplugin.cpp PRE-CREATION declarative/qmldir PRE-CREATION src/kwindowsystem.h e10f7c1 tests/test.qml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115932/diff/ Testing --- Works Thanks, Martin Klapetek ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116116: Fix build with Qt 5.3
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116116/ --- Review request for KDE Frameworks. Repository: solid Description --- Rename QByteArrayList to ByteArrayList and, while I was at it, QVariantMapMap to VariantMapMap. Diffs - src/solid/backends/udisks2/dbus/manager.h 50481fa src/solid/backends/udisks2/udisks2.h ba8974a src/solid/backends/udisks2/udisksdevice.cpp 5208ece src/solid/backends/udisks2/udisksdevicebackend.h 691b5c6 src/solid/backends/udisks2/udisksdevicebackend.cpp 3bbe787 src/solid/backends/udisks2/udisksmanager.h 7382a1f src/solid/backends/udisks2/udisksmanager.cpp b6f3322 src/solid/backends/udisks2/udisksstorageaccess.cpp edd7de8 Diff: https://git.reviewboard.kde.org/r/116116/diff/ Testing --- Builds, tests pass. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115953: Clean up kdesu CMake files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115953/#review51040 --- Ship it! Ship It! - Aurélien Gâteau On Feb. 22, 2014, 6:43 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115953/ --- (Updated Feb. 22, 2014, 6:43 p.m.) Review request for KDE Frameworks. Repository: kdesu Description --- Remove KF5Service dependency from config file KF5Service is a PRIVATE link, and so should not be a dependency in the config file. Remove leftover code from kdelibs from CMakeLists.txt Diffs - CMakeLists.txt 15b01a0745206cbc761fd3572393ec56753ff2b6 KF5SuConfig.cmake.in 9c2f96e3712490c56fd697b862c5d6a39755402d Diff: https://git.reviewboard.kde.org/r/115953/diff/ Testing --- Configures, compiles, installs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116116: Fix build with Qt 5.3
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116116/#review51042 --- Looks good to me, but someone else must approve. Thanks for taking care of this! - Dominik Haumann On Feb. 27, 2014, 12:25 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116116/ --- (Updated Feb. 27, 2014, 12:25 p.m.) Review request for KDE Frameworks. Repository: solid Description --- Rename QByteArrayList to ByteArrayList and, while I was at it, QVariantMapMap to VariantMapMap. Diffs - src/solid/backends/udisks2/dbus/manager.h 50481fa src/solid/backends/udisks2/udisks2.h ba8974a src/solid/backends/udisks2/udisksdevice.cpp 5208ece src/solid/backends/udisks2/udisksdevicebackend.h 691b5c6 src/solid/backends/udisks2/udisksdevicebackend.cpp 3bbe787 src/solid/backends/udisks2/udisksmanager.h 7382a1f src/solid/backends/udisks2/udisksmanager.cpp b6f3322 src/solid/backends/udisks2/udisksstorageaccess.cpp edd7de8 Diff: https://git.reviewboard.kde.org/r/116116/diff/ Testing --- Builds, tests pass. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115918: Fix kservice_desktop_to_json for Visual Studio
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115918/#review51043 --- While this fix would certainly work, I think it would be good to file a bug on CMake bug tracker for that issue (and add the bug id as a comment there). Maybe also ping Stephen Kelly about it, since he wrote the code in CMake which makes it possible to define a command to run before moc. - Aurélien Gâteau On Feb. 20, 2014, 5:58 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115918/ --- (Updated Feb. 20, 2014, 5:58 p.m.) Review request for KDE Frameworks. Repository: kservice Description --- Fix kservice_desktop_to_json for Visual Studio The CMake generator for Visual Studio cannot handle the new build-time kservice_desktop_to_json macro - fall back to configure-time generation Diffs - KF5ServiceMacros.cmake f70a185f4cd48293cb9f1e2ca4cf13defaf2aec3 Diff: https://git.reviewboard.kde.org/r/115918/diff/ Testing --- ktexteditor fails to build before this patch (because moc can't find the .json file), with the patch it compiles Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kprintutils - next steps
On 27/02/14 11:21, John Layt wrote: On 23 February 2014 20:02, John Layt jl...@kde.org wrote: 2) Copy code from kprintutils to kde4support - Do we bother to keep the history? - Where do we put it? Alex, if you have that git magic I'd appreciate your doing it, I have no clue what to do :-) I'm not sure whether we should put it back into kde4support/src/kdeui where it originally came from or kde4support/src/kprintutils? Can you check that g...@git.kde.org:clones/kde4support/alexmerry/kprintutils-merge seems right? It builds and the tests pass. The printpreview test also runs, but can't find a preview part (since Okular isn't around). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115953: Clean up kdesu CMake files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115953/#review51045 --- This review has been submitted with commit d5dc6cd3b45bdd5f13316a7689d2f3caed5d0050 by Alex Merry to branch master. - Commit Hook On Feb. 22, 2014, 5:43 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115953/ --- (Updated Feb. 22, 2014, 5:43 p.m.) Review request for KDE Frameworks. Repository: kdesu Description --- Remove KF5Service dependency from config file KF5Service is a PRIVATE link, and so should not be a dependency in the config file. Remove leftover code from kdelibs from CMakeLists.txt Diffs - CMakeLists.txt 15b01a0745206cbc761fd3572393ec56753ff2b6 KF5SuConfig.cmake.in 9c2f96e3712490c56fd697b862c5d6a39755402d Diff: https://git.reviewboard.kde.org/r/115953/diff/ Testing --- Configures, compiles, installs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115953: Clean up kdesu CMake files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115953/#review51044 --- This review has been submitted with commit b1d275bd2246f2b937114918d60c523461b1b09d by Alex Merry to branch master. - Commit Hook On Feb. 22, 2014, 5:43 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115953/ --- (Updated Feb. 22, 2014, 5:43 p.m.) Review request for KDE Frameworks. Repository: kdesu Description --- Remove KF5Service dependency from config file KF5Service is a PRIVATE link, and so should not be a dependency in the config file. Remove leftover code from kdelibs from CMakeLists.txt Diffs - CMakeLists.txt 15b01a0745206cbc761fd3572393ec56753ff2b6 KF5SuConfig.cmake.in 9c2f96e3712490c56fd697b862c5d6a39755402d Diff: https://git.reviewboard.kde.org/r/115953/diff/ Testing --- Configures, compiles, installs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115953: Clean up kdesu CMake files
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115953/ --- (Updated Feb. 27, 2014, 1:04 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kdesu Description --- Remove KF5Service dependency from config file KF5Service is a PRIVATE link, and so should not be a dependency in the config file. Remove leftover code from kdelibs from CMakeLists.txt Diffs - CMakeLists.txt 15b01a0745206cbc761fd3572393ec56753ff2b6 KF5SuConfig.cmake.in 9c2f96e3712490c56fd697b862c5d6a39755402d Diff: https://git.reviewboard.kde.org/r/115953/diff/ Testing --- Configures, compiles, installs. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116012: Inline deprecated methods, and silence false positives in tests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/#review51046 --- Ship it! Ship It! - Aurélien Gâteau On Feb. 24, 2014, 1:12 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/ --- (Updated Feb. 24, 2014, 1:12 p.m.) Review request for KDE Frameworks. Repository: karchive Description --- Four commits (in git log order): Simplify autotests CMakeLists.txt Separate out tests of deprecated functions to their own file This allows us to disable deprecation warnings just for that file. Inline deprecated methods This both documents how to replace them in the headers and ensures that enabling or disabling deprecated functions does not affect the ABI. Use KARCHIVE_NO_DEPRECATED instead of KDE_NO_DEPRECATED Diffs - autotests/CMakeLists.txt 1da853fe49ec6fca40ccf417db788340124b41e5 autotests/deprecatedtest.cpp PRE-CREATION autotests/karchivetest.cpp 6d6b5848ce9add84736968dd13f529711f895493 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchive.cpp a25b85e41618d1f7ae62e7e41966afe1a8aaef8e src/kfilterdev.h 4a35879a15992d19378c7e9baa9b206e187713fd src/kfilterdev.cpp 60660a0c08922ee0f4ddaf4ad4d1adf0e7f1c5a3 Diff: https://git.reviewboard.kde.org/r/116012/diff/ Testing --- Builds, tests pass. No deprecation warnings (before there were two in the tests). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116050: Adjust kpty tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116050/#review51047 --- Ship it! Ship It! - Aurélien Gâteau On Feb. 25, 2014, 6:20 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116050/ --- (Updated Feb. 25, 2014, 6:20 p.m.) Review request for KDE Frameworks. Repository: kpty Description --- ki18n changed from tier 2 to tier 1. kpty only depends on tier 1 now, becomes tier 2 Diffs - kpty.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116050/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116049: Adjust kjsembed tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116049/#review51048 --- Ship it! Ship It! - Aurélien Gâteau On Feb. 25, 2014, 6:25 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116049/ --- (Updated Feb. 25, 2014, 6:25 p.m.) Review request for KDE Frameworks and Bernd Buschinski. Repository: kjsembed Description --- ki18n changed from tier 2 to tier 1. kjsembed only depends on tier 1 now, becomes tier 2 Diffs - kjsembed.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116049/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
On Feb. 26, 2014, 10:57 p.m., Albert Astals Cid wrote:
have you tried removing the include?
Albert Astals Cid wrote:
Ignore me, there's i18n calls in there :D
Alex Merry wrote:
However, I wonder if those calls should really be in the header. I have
no idea what catalogue they will use at runtime; I suspect it will depend on
whether code that includes the header defined TRANSLATION_DOMAIN and where,
exactly, they do so.
A better solution (SC but not BC) is probably to create overloaded
methods and put those calls in the cpp file.
May I suggest this instead:
diff --git a/src/core/slavebase.cpp b/src/core/slavebase.cpp
index 1236ad5..2002cdf 100644
--- a/src/core/slavebase.cpp
+++ b/src/core/slavebase.cpp
@@ -968,9 +968,11 @@ int SlaveBase::messageBox(MessageBoxType type, const
QString text, const QStrin
}
int SlaveBase::messageBox(const QString text, MessageBoxType type, const
QString caption,
- const QString buttonYes, const QString buttonNo,
+ const QString _buttonYes, const QString _buttonNo,
const QString dontAskAgainName)
{
+QString buttonYes = _buttonYes.isEmpty() ? i18n(Yes) : _buttonYes;
+QString buttonNo = _buttonNo.isEmpty() ? i18n(No) : _buttonNo;
//qDebug() messageBox type text - caption
buttonYes buttonNo;
KIO_DATA (qint32)type text caption buttonYes buttonNo
dontAskAgainName;
send(INF_MESSAGEBOX, data);
diff --git a/src/core/slavebase.h b/src/core/slavebase.h
index 86f1506..0922893 100644
--- a/src/core/slavebase.h
+++ b/src/core/slavebase.h
@@ -24,7 +24,6 @@
#include kio/udsentry.h
#include kio/authinfo.h
#include job_base.h // for KIO::JobFlags
-#include klocalizedstring.h
#include QtCore/QByteArray
#include QtNetwork/QHostInfo
@@ -277,8 +276,8 @@ public:
*/
int messageBox(MessageBoxType type, const QString text,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No));
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString());
/**
* Call this to show a message box from the slave
@@ -297,8 +296,8 @@ public:
*/
int messageBox(const QString text, MessageBoxType type,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No),
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString(),
const QString dontAskAgainName = QString());
/**
- Aurélien
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/#review50988
---
On Feb. 26, 2014, 10:44 p.m., Matthieu Gallien wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/
---
(Updated Feb. 26, 2014, 10:44 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is
publically installed.
Diffs
-
KF5KIOConfig.cmake.in 3a947b7
src/core/CMakeLists.txt d897e37
Diff: https://git.reviewboard.kde.org/r/116103/diff/
Testing
---
Thanks,
Matthieu Gallien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116050: Adjust kpty tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116050/ --- (Updated Feb. 27, 2014, 2:03 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kpty Description --- ki18n changed from tier 2 to tier 1. kpty only depends on tier 1 now, becomes tier 2 Diffs - kpty.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116050/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116049: Adjust kjsembed tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116049/#review51051 --- This review has been submitted with commit 3064544f814813e4f528e7902f567e5ec4a30ffd by Kevin Krammer to branch master. - Commit Hook On Feb. 25, 2014, 5:25 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116049/ --- (Updated Feb. 25, 2014, 5:25 p.m.) Review request for KDE Frameworks and Bernd Buschinski. Repository: kjsembed Description --- ki18n changed from tier 2 to tier 1. kjsembed only depends on tier 1 now, becomes tier 2 Diffs - kjsembed.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116049/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116050: Adjust kpty tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116050/#review51050 --- This review has been submitted with commit 96030f5fae2c7e04931ba5ecd68c2e3447635aa6 by Kevin Krammer to branch master. - Commit Hook On Feb. 25, 2014, 5:20 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116050/ --- (Updated Feb. 25, 2014, 5:20 p.m.) Review request for KDE Frameworks. Repository: kpty Description --- ki18n changed from tier 2 to tier 1. kpty only depends on tier 1 now, becomes tier 2 Diffs - kpty.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116050/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116049: Adjust kjsembed tier for changed ki18n tier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116049/ --- (Updated Feb. 27, 2014, 2:04 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Bernd Buschinski. Repository: kjsembed Description --- ki18n changed from tier 2 to tier 1. kjsembed only depends on tier 1 now, becomes tier 2 Diffs - kjsembed.yaml 78c0a75 Diff: https://git.reviewboard.kde.org/r/116049/diff/ Testing --- Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kpty_master_qt5 #18
See http://build.kde.org/job/kpty_master_qt5/18/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdesrc-build: stop after failure? --truly-verbose?
Am Mittwoch, 26. Februar 2014, 23:27:08 schrieb Michael Pyne:
On Wed, February 26, 2014 22:30:48 Milian Wolff wrote:
Hey,
not sure this is the right list. I noticed that kdesrc-build happily
continues building even when a module failed to build. Is this desired?
Yes, it's on purpose. The idea is that most people are not building KDE for
the first time and don't need to have the whole compile aborted because
mpyne committed a fail-to-build bug in juk or something.
Couldn't instead the _full_ error log be cat'ed and the build stopped?
Now,
I have to hunt down the error log manually which is really cumbersome. If
others think this behavior is good, could I vote for an additional cli
argument to stop after any failure?
Yes, kdesrc-build can do (most) of this. I thought I documented it as a
command line option but it turns out that it was a kdesrc-buildrc option.
But you can still reach it via command line by passing --stop-on-failure=1
As far as the error log file, its location gets output at the end (which
will be very soon indeed if you pass --stop-on-failure), and I think dfaure
might still have an open bug about reporting the logfile location
immediately upon failure.
However, what I personally do is that I added a small bash function to my
.bashrc, errorLog, which does something like:
errorLog() {
$EDITOR ~/log-kdesrc-build/latest/$1/error.log
}
where ~/log-kdesrc-build should be wherever your log directory is (probably
$srcdir/log). kdesrc-build maintains symlinks throughout the log directory
to make it easy to find the last log set for a given module, and which log
contains the error if the module failed (i.e. if you see an error.log in a
specific log directory it means that module failed to build that run).
Also, while at it, could we get a truly verbose flag, which actually
outputs the output from whatever tool is currently running?
If you file a bug I'd probably implement it. --debug did this kind of thing
(it might even still do it, but it would be too annoying to use here). I say
file a bug only because it's guaranteed it'll drop off my plate
otherwise.
Yep, --debug still works as intended.
I use it a lot, but only if I build single packages or combined with --stop-
on-failure=1.
You should document that --debug flag, too, I'd say. I had to grep the code
for it as well when I first wondered how to make kdesrc-build print everything
to stdout.
For me as a
developer, its really annoying having to tail -f on some random log files
to get my hands on the make output... How are other developers handling
this?
I just watch the percentages in the kdesrc-build output personally. When I'm
doing development I don't use kdesrc-build at all; I still retain my 'cs'
and 'cb' shell macros to switch between individual source/build dirs as
needed and manually do my git-fu and make-n-shake so that I can see
compiler warnings.
I'm sorry if it's been annoying to use but I'm always open to improvements
(especially improvements with patches, but no one else seems to like Perl...
;)
In the meantime there are other, better-documented, command line options
which are useful. Documentation is available at
http://kdesrc-build.kde.org/documentation/, and if you build kdesrc-build
it should install a man page to $KDEDIR/share/man/man1 or thereabouts.
I've recently become a big fan of --resume-from (or -after), --stop-before
(or -after) and --ignore-modules options myself. And always --pretend.
Regards,
- Michael Pyne
Cheers
--
Kevin Funk
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Compile errors originating from libKF5XsltKde.a
Hey, I get the following compile errors when compiling anything that depends on libKF5XsltKde.a from kdoctools: When compiling kio: [ 53%] Built target kio_file /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with -fPIC Obviously, the reason is that -fPIC is missing for the static library target libKF5XsltKde.a. I thought that's added implicitly when doing target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)? That pulls in the link flags from Qt5Core, no? Ideas? Important note: My Qt5 here is configured with -no-reduce-relocations (that might be the issue?), adding -fPIC fixes the build for me. Greets -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Compile errors originating from libKF5XsltKde.a
Am Donnerstag, 27. Februar 2014, 13:06:38 schrieb Kevin Funk: Hey, I get the following compile errors when compiling anything that depends on libKF5XsltKde.a from kdoctools: When compiling kio: [ 53%] Built target kio_file /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with -fPIC Obviously, the reason is that -fPIC is missing for the static library target libKF5XsltKde.a. I thought that's added implicitly when doing target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)? That pulls in the link flags from Qt5Core, no? Ideas? Important note: My Qt5 here is configured with -no-reduce-relocations (that might be the issue?), adding -fPIC fixes the build for me. Greets Note: That happens with any static library it seems -- just got the same for libkatefiletree.a. So, any ideas how to solve this in a generic way? Cheers -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Frameworks sprint: Register now!
On Thu, Feb 27, 2014 at 7:44 AM, Kevin Ottens er...@kde.org wrote: Hello all, If you didn't yet, please register for the upcoming sprint: https://sprints.kde.org/sprint/224 Especially if you're not from Barcelona, it's necessary for budgeting the sprint, booking the accommodation, etc. The guys in Barcelona are kind enough to host us, so please let's be nice guests and make their job easier. :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I'm happy i can attend after all :) Added my info on the sprint page. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Compile errors originating from libKF5XsltKde.a
Am Donnerstag, 27. Februar 2014, 15:24:30 schrieb Kevin Funk: Am Donnerstag, 27. Februar 2014, 13:06:38 schrieb Kevin Funk: Hey, I get the following compile errors when compiling anything that depends on libKF5XsltKde.a from kdoctools: When compiling kio: [ 53%] Built target kio_file /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN7QStringpLE5QChar' which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_32 reloc which may overflow at runtime; recompile with -fPIC /home/krf/bin/ld: error: /home/krf/devel/install/kf5/lib/x86_64-linux- gnu/libKF5XsltKde.a(xslt.cpp.o): requires dynamic R_X86_64_PC32 reloc against '_ZN5QChar7unicodeEv' which may overflow at runtime; recompile with -fPIC Obviously, the reason is that -fPIC is missing for the static library target libKF5XsltKde.a. I thought that's added implicitly when doing target_link_libraries(KF5XsltKde Qt5::Core KF5::Archive)? That pulls in the link flags from Qt5Core, no? Ideas? Important note: My Qt5 here is configured with -no-reduce-relocations (that might be the issue?), adding -fPIC fixes the build for me. Greets Note: That happens with any static library it seems -- just got the same for libkatefiletree.a. So, any ideas how to solve this in a generic way? Cheers Just discussed this a bit with Stephen on IRC: We need to set the compile flags manually on each static library used in a shared library -- there's no way for CMake to figure out if a static library will be added to a shared one. So, we have to specify set_target_properties(MyStaticLib PROPERTIES POSITION_INDEPENDENT_CODE TRUE) manually for each of them Also see: http://cmake.3232098.n2.nabble.com/SHARED-library-containing-OBJECT-library-Missing-fPIC-tp7580514p7580571.html I'll file some patches Greets -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KItemModels, Solid KJS licenses
other files: Ivan Čukić. Touched by me (not enough for me to hold any copyright, though) @Shumski : to repeat my answer on IRC, you have my permission to change to LGPL On 26 February 2014 18:42, Alex Merry alex.me...@kde.org wrote: On 20/02/14 11:41, Alex Merry wrote: [1] https://build.opensuse.org/request/show/223061 KItemModels kcheckableproxymodel.(cpp|h) is Stephen Kelly (and, for safety, David Faure). Changed. modeltest.(cpp|h) were taken from Qt Concurrent, and subsequently modified by Stephen Kelly, and touched by David Faure and Aurélien Gâteau (but I don't think the latter two count as copyright holders, judging from the commit messages). So we can't just relicense this, because it is forked from a GPL-only file, and Digia have only public LGPL-licensed a later version of it. Just dropping in the new (LGPLv2.1) file seems to work, though. That, however, means that this code is LGPLv2, rather than LGPLv2+. David is on record as being happy with relicensing to LGPLv2+ (with or without the e.V. clause) - see relicensecheck.pl in kde:kde-dev-scripts. [1] https://build.opensuse.org/request/show/223093 KJS propertydescriptor.(cpp|h) is Bernd Buschinski. Possibly also David Faure (although, as already noted, David's code is not an issue). git log runs out early, though, so more investigation might be needed. Changed. [1] https://build.opensuse.org/request/show/223081 Solid predicate_parser.(c|h) are false positives (Bison-generated; the skeleton has a license exception). other files: Ivan Čukić. Touched by me (not enough for me to hold any copyright, though) and Volker Krause (arguably the same, but he's on record as being happy with LGPLv2+ anyway, although without the e.V. clause). Still waiting. 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 116124: Always compile static lib with -fPIC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116124/ --- Review request for KDE Frameworks. Repository: kdoctools Description --- Always compile static lib with -fPIC See http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/012375.html Diffs - src/CMakeLists.txt 0329bd383415b4fa265c1edd7f0f7d384fd17395 Diff: https://git.reviewboard.kde.org/r/116124/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KUnitConversion Review
Hi, I've been reviewing KUnitConversion (KUC for short) and doing some small clean-ups, and I'm slowly coming to the conclusion I'm not a fan of the api. However it is used in a few places, so rather than try rewrite the api in the time remaining, I'll finish up the clean-ups and we can release it as is and look to replace it later on. The main clean-ups are: * Remove use of KCurrencyCode. Currently it's only used to get the currency name of the 50 currencies KUC supports and it seems overkill to keep all 207 data files and the api in KUC just for that purpose. Instead I'd move it to kde4support with the rest of KLocale (we also need to move the config files from kde-runtime). This would also remove the dependency on KConfigCore. * Try port away from ki18n to tr(). KUC makes extensive use of ki18nc() and ki18ncp(), but I need to check with Chusselove if all the plural translations can be handled with Qt or if any are scripted. * If we remove those two dependencies then KUC becomes Tier 1, but Tier 2 is fine either way. * Convert more classes to QSharedData * Some small API changes * Lots of docs clean-ups, code style, etc are needed but can be done later. I've done the first step, and I just need a volunteer to do the git magic required to: * Move kcurrencycode.h and kcurrencycode.cpp including history from kunitconversion/src to kde4support/src/kdecore * Move kde-runtime/localization and everything in it including history to kde4support/src/localization or kde4support/runtime/localization or wherever deemed appropriate * Move kde-runtime/l10n and everything in it including history into the same localization folder as above but folder renamed from l10n to localization/country (i.e. at same level as currency folder) * Make sure the data files are built and installed, but need to think about parallel installs with KDE4 data files The data file moves are part of the kde-runtime clean-up, but it makes sense to do them alongside the code moves. Longer term, I've started work on a new Tier 1 library tentatively called KStandards to support the different ISO code standards, and measurement standards and conversions. I've already converted KCurrencyCode to a new KCurrency class using json files, and KCountry and KUnits should follow in due course to provide a future migration path for apps that need them. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
On Feb. 26, 2014, 10:57 p.m., Albert Astals Cid wrote:
have you tried removing the include?
Albert Astals Cid wrote:
Ignore me, there's i18n calls in there :D
Alex Merry wrote:
However, I wonder if those calls should really be in the header. I have
no idea what catalogue they will use at runtime; I suspect it will depend on
whether code that includes the header defined TRANSLATION_DOMAIN and where,
exactly, they do so.
A better solution (SC but not BC) is probably to create overloaded
methods and put those calls in the cpp file.
Aurélien Gâteau wrote:
May I suggest this instead:
diff --git a/src/core/slavebase.cpp b/src/core/slavebase.cpp
index 1236ad5..2002cdf 100644
--- a/src/core/slavebase.cpp
+++ b/src/core/slavebase.cpp
@@ -968,9 +968,11 @@ int SlaveBase::messageBox(MessageBoxType type, const
QString text, const QStrin
}
int SlaveBase::messageBox(const QString text, MessageBoxType type,
const QString caption,
- const QString buttonYes, const QString
buttonNo,
+ const QString _buttonYes, const QString
_buttonNo,
const QString dontAskAgainName)
{
+QString buttonYes = _buttonYes.isEmpty() ? i18n(Yes) : _buttonYes;
+QString buttonNo = _buttonNo.isEmpty() ? i18n(No) : _buttonNo;
//qDebug() messageBox type text -
caption buttonYes buttonNo;
KIO_DATA (qint32)type text caption buttonYes buttonNo
dontAskAgainName;
send(INF_MESSAGEBOX, data);
diff --git a/src/core/slavebase.h b/src/core/slavebase.h
index 86f1506..0922893 100644
--- a/src/core/slavebase.h
+++ b/src/core/slavebase.h
@@ -24,7 +24,6 @@
#include kio/udsentry.h
#include kio/authinfo.h
#include job_base.h // for KIO::JobFlags
-#include klocalizedstring.h
#include QtCore/QByteArray
#include QtNetwork/QHostInfo
@@ -277,8 +276,8 @@ public:
*/
int messageBox(MessageBoxType type, const QString text,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No));
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString());
/**
* Call this to show a message box from the slave
@@ -297,8 +296,8 @@ public:
*/
int messageBox(const QString text, MessageBoxType type,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No),
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString(),
const QString dontAskAgainName = QString());
/**
Aurélien, do you want me to update the review request or do you do it directly
yourself ?
- Matthieu
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/#review50988
---
On Feb. 26, 2014, 10:44 p.m., Matthieu Gallien wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/
---
(Updated Feb. 26, 2014, 10:44 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is
publically installed.
Diffs
-
KF5KIOConfig.cmake.in 3a947b7
src/core/CMakeLists.txt d897e37
Diff: https://git.reviewboard.kde.org/r/116103/diff/
Testing
---
Thanks,
Matthieu Gallien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115963: KSharedConfig: Fix interference from kdeplatformtheme into unittests
On Feb. 25, 2014, 3:55 p.m., Matthew John Dawson wrote: src/core/ksharedconfig.cpp, line 70 https://git.reviewboard.kde.org/r/115963/diff/1/?file=245616#file245616line70 Can you also please clear GlobalSharedConfigList::mainConfig please? It should be reset anyways if a config is opened, but I rather be safe then sorry. Good point indeed. Wasn't needed in my test, but better safe than sorry. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/#review50606 --- On Feb. 23, 2014, 11:54 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/ --- (Updated Feb. 23, 2014, 11:54 a.m.) Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- Fix interference from kdeplatformtheme into unittests kdeplatformtheme would load kdeglobals and the app config file, in order to load settings, before the unittests get a chance to call QStandardPaths::setTestModeEnabled(true). As a result, the test would keep getting references to wrong shared config objects, pointing to the real user's locations rather than the test directories. This fixes e.g. kconfigdialog_unittest from kconfigwidgets for me (it only passes on build.kde.org because it doesn't install frameworkintegration for testing this framework) Diffs - src/core/ksharedconfig.cpp 4f0e8d698f60fd05c25e4796be12a35facb8cd38 Diff: https://git.reviewboard.kde.org/r/115963/diff/ Testing --- kconfigdialog_unittest now passes with frameworkintegration installed. The tests in frameworkintegration still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115960: Add sharedConfig() accessor, to avoid manipulating a raw KConfig * as returned by config().
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115960/#review51123 --- This review has been submitted with commit eb604bc60bcc5cd94328de725ac357e728eae624 by David Faure to branch master. - Commit Hook On Feb. 23, 2014, 11:15 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115960/ --- (Updated Feb. 23, 2014, 11:15 a.m.) Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- Add sharedConfig() accessor, to avoid manipulating a raw KConfig * as returned by config(). This is useful when using kconfigxt and some other code to read from the same config file (e.g. KColorScheme::contrastF(config)) - no need to call KSharedConfig::openConfig twice, just grab the KSharedConfig from the generated class. Diffs - src/core/kcoreconfigskeleton.h 9cd079941fa6f870a19bdbdb945aafe858b4c51a src/core/kcoreconfigskeleton.cpp 98d9cdccec3cf3925bb68e2d0cff1b5a1276c56a Diff: https://git.reviewboard.kde.org/r/115960/diff/ Testing --- About to use it in kde-workspace. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115963: Fix interference from kdeplatformtheme into unittests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/ --- (Updated Feb. 27, 2014, 8:01 p.m.) Review request for KDE Frameworks and Matthew John Dawson. Changes --- clear mainConfig too Summary (updated) - Fix interference from kdeplatformtheme into unittests Repository: kconfig Description (updated) --- Fix interference from kdeplatformtheme into unittests kdeplatformtheme would load kdeglobals and the app config file, in order to load settings, before the unittests get a chance to call QStandardPaths::setTestModeEnabled(true). As a result, the test would keep getting references to wrong shared config objects, pointing to the real user's locations rather than the test directories. This fixes e.g. kconfigdialog_unittest from kconfigwidgets for me (it only passes on build.kde.org because it doesn't install frameworkintegration for testing this framework) REVIEW: 115963 Diffs (updated) - src/core/ksharedconfig.cpp 4f0e8d698f60fd05c25e4796be12a35facb8cd38 Diff: https://git.reviewboard.kde.org/r/115963/diff/ Testing --- kconfigdialog_unittest now passes with frameworkintegration installed. The tests in frameworkintegration still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/#review51125 --- Ship it! Tests pass == unittests? Did you also try playing with it interactively a bit? I see that both kcomboboxtest and kcompletionuitest instantiate a KHistoryComboBox. Sorry, it's just hard to review such patches for correctness, so a bit of testing wouldn't hurt. But after that (and the two minor issues below), yep, ship it. autotests/kcombobox_unittest.cpp https://git.reviewboard.kde.org/r/115710/#comment35844 I would add a comment like TODO: finish, because this is obviously a very limited test (does not crash, basically). Yes, it's what I asked for, but anyone reading this in the future might wonder what the heck this is really testing :-) src/khistorycombobox.cpp https://git.reviewboard.kde.org/r/115710/#comment35845 q-connect is a strange way to call a static method. QObject::connect would be usual (if a bit more verbose). - David Faure On Feb. 25, 2014, 10:50 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/ --- (Updated Feb. 25, 2014, 10:50 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private methods and slots behind the d-pointer in KHistoryComboBox Also: -Remove header not used Diffs - autotests/kcombobox_unittest.cpp 49ef721 src/khistorycombobox.h 3667eb4 src/khistorycombobox.cpp 6f81dda Diff: https://git.reviewboard.kde.org/r/115710/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115963: Fix interference from kdeplatformtheme into unittests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/#review51126 --- Ship it! Looks good, just one minor issue and it can go in. src/core/ksharedconfig.cpp https://git.reviewboard.kde.org/r/115963/#comment35846 Nitpick: please use Q_NULLPTR instead of 0 here. - Matthew John Dawson On Feb. 27, 2014, 3:01 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/ --- (Updated Feb. 27, 2014, 3:01 p.m.) Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- Fix interference from kdeplatformtheme into unittests kdeplatformtheme would load kdeglobals and the app config file, in order to load settings, before the unittests get a chance to call QStandardPaths::setTestModeEnabled(true). As a result, the test would keep getting references to wrong shared config objects, pointing to the real user's locations rather than the test directories. This fixes e.g. kconfigdialog_unittest from kconfigwidgets for me (it only passes on build.kde.org because it doesn't install frameworkintegration for testing this framework) REVIEW: 115963 Diffs - src/core/ksharedconfig.cpp 4f0e8d698f60fd05c25e4796be12a35facb8cd38 Diff: https://git.reviewboard.kde.org/r/115963/diff/ Testing --- kconfigdialog_unittest now passes with frameworkintegration installed. The tests in frameworkintegration still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115963: Fix interference from kdeplatformtheme into unittests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/#review51128 --- This review has been submitted with commit 3eb5f0433f79f0c0fda49e00898cd93d3bd73b67 by David Faure to branch master. - Commit Hook On Feb. 27, 2014, 8:01 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/ --- (Updated Feb. 27, 2014, 8:01 p.m.) Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- Fix interference from kdeplatformtheme into unittests kdeplatformtheme would load kdeglobals and the app config file, in order to load settings, before the unittests get a chance to call QStandardPaths::setTestModeEnabled(true). As a result, the test would keep getting references to wrong shared config objects, pointing to the real user's locations rather than the test directories. This fixes e.g. kconfigdialog_unittest from kconfigwidgets for me (it only passes on build.kde.org because it doesn't install frameworkintegration for testing this framework) REVIEW: 115963 Diffs - src/core/ksharedconfig.cpp 4f0e8d698f60fd05c25e4796be12a35facb8cd38 Diff: https://git.reviewboard.kde.org/r/115963/diff/ Testing --- kconfigdialog_unittest now passes with frameworkintegration installed. The tests in frameworkintegration still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115963: Fix interference from kdeplatformtheme into unittests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/ --- (Updated Feb. 27, 2014, 8:13 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- Fix interference from kdeplatformtheme into unittests kdeplatformtheme would load kdeglobals and the app config file, in order to load settings, before the unittests get a chance to call QStandardPaths::setTestModeEnabled(true). As a result, the test would keep getting references to wrong shared config objects, pointing to the real user's locations rather than the test directories. This fixes e.g. kconfigdialog_unittest from kconfigwidgets for me (it only passes on build.kde.org because it doesn't install frameworkintegration for testing this framework) REVIEW: 115963 Diffs - src/core/ksharedconfig.cpp 4f0e8d698f60fd05c25e4796be12a35facb8cd38 Diff: https://git.reviewboard.kde.org/r/115963/diff/ Testing --- kconfigdialog_unittest now passes with frameworkintegration installed. The tests in frameworkintegration still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116461/ --- Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation. KConfig already parses the config files from disk in the constructor, which is necessary for non-KConfigXT users. However when using KConfigXT the first thing one has to do after creation is to call readConfig(), which should therefore not call reparseConfiguration the first time. strace -e open kate | grep -v NOENT | grep oxygenrc | wc -l went from 4 to 1 -- bingo, goal reached! (and when looking for kdeglobals, from 10 to 7) Diffs - src/core/kcoreconfigskeleton.cpp 9c5fb4a80d500e81b483b749a137ad5f2c99a55f src/core/kcoreconfigskeleton_p.h 0b020ed3493186e699d872ddc7a9f9294d797a95 Diff: https://git.reviewboard.kde.org/r/116461/diff/ Testing --- (see commit log) + unittests in kconfig still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116037: change entities to reflect new branding
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116037/#review51163 --- Ship it! This review can go in :) - Luigi Toscano On Feb. 25, 2014, 1:02 a.m., T.C. Hollingsworth wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116037/ --- (Updated Feb. 25, 2014, 1:02 a.m.) Review request for Documentation, KDE Frameworks, Luigi Toscano, Burkhard Lück, and Yuri Chornoivan. Repository: kdoctools Description --- -kde; is no longer semantically identified as an acronym, but instead as an organization -new translatable entities for KDE Frameworks are added -new translatable entities for the KDE SC are added -new translatable entities for the various incarnations of Plasma are added with this I can finally kill the temporary entities that have been in kde-runtime.git/doc/fundamentals for over a year now. :-) Diffs - src/customization/en/user.entities 47bfe0d src/customization/entities/general.entities 183fbc9 Diff: https://git.reviewboard.kde.org/r/116037/diff/ Testing --- kdoctools still builds, kate docs still meinproc5 successfully Thanks, T.C. Hollingsworth ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116462: Keep KSharedConfigPtr(kdeglobals) around in KHintSettings.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116462/ --- Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: frameworkintegration Description --- Keep KSharedConfigPtr(kdeglobals) around in KHintSettings. This makes KFontSettingsData end up using the same instance, rather than each of these two classes parsing kdeglobals on startup, in turn. Had to fix the unittest again, it doesn't use QStandardPaths' testMode, so it must ensure to set its special environment before the platformtheme is created. strace -e open kate | grep -v NOENT | grep kdeglobals | wc -l went from 5 to 4. Diffs - src/platformtheme/khintssettings.cpp c4de4badc6187d841af36e29e083ffd2ca475d82 src/platformtheme/khintssettings.h 8f353837884590bc6a8409df7273435824273f49 src/platformtheme/kfontsettingsdata.cpp 62990ce45c1a175c3b57710c8a38268d08908733 autotests/kfontsettingsdata_unittest.cpp 4ee33fea72905128112226248667499489b1c692 Diff: https://git.reviewboard.kde.org/r/116462/diff/ Testing --- as described: unittests in frameworkintegration + running kate. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.
On Feb. 24, 2014, 9:22 p.m., Albert Astals Cid wrote:
src/khelpclient.cpp, line 35
https://git.reviewboard.kde.org/r/115959/diff/2/?file=245608#file245608line35
Just curious, who is doing this call setApplicationName() with the
name of the desktop file thing? I know KApplication did it but we're now
not recommending to use it. Or is this something every app developer has to
do? Is it documented somewhere?
I implemented in Qt 5.0 that applicationName() now defaults to the name of the
binary on disk. This takes care of 95% of the cases :-)
For the other cases, there's setApplicationName (as documented in the porting
doc when porting away from kapp, among other things), or very soon it will also
be done by KAboutData::setApplicationData(myAboutData) (there's a RR pending
for it).
On Feb. 24, 2014, 9:22 p.m., Albert Astals Cid wrote:
src/khelpclient.cpp, line 76
https://git.reviewboard.kde.org/r/115959/diff/2/?file=245608#file245608line76
url is always help:/ isn't it? Not sure i understand the comment
? Not sure I understand *your* comment :-)
QUrl url;
if (!docPath.isEmpty()) {
url =
QUrl(QLatin1String(help:/)).resolved(QUrl::fromUserInput(docPath));
} else {
url = QUrl(QString::fromLatin1(help:/%1/index.html).arg(appname));
}
if (!anchor.isEmpty()) {
QUrlQuery query(url);
query.addQueryItem(QString::fromLatin1(anchor), anchor);
url.setQuery(query);
}
How is this always help:/ ? There much stuff after that, in the path and
possibly in the query.
- David
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115959/#review50765
---
On Feb. 23, 2014, 11 a.m., David Faure wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115959/
---
(Updated Feb. 23, 2014, 11 a.m.)
Review request for KDE Frameworks and Albert Astals Cid.
Repository: kconfigwidgets
Description
---
3 commits:
Unittest: make errors readable
--
Resurrect KConfigDialog::setHelp (used to come from KDialog).
It controls the default behavior of showHelp(), which is implemented
using KHelpClient.
REVIEW: 115959
--
Move KHelpClient down from kxmlgui, for use in KConfigDialog.
Diffs
-
autotests/kconfigdialog_unittest.cpp
e5322c1782c2a68c15451777066e28a9b7afea23
src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36
src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280
src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405
src/khelpclient.h PRE-CREATION
src/khelpclient.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/115959/diff/
Testing
---
Compiled all of KF5.
Thanks,
David Faure
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
On Feb. 27, 2014, 8:09 p.m., David Faure wrote: src/khistorycombobox.cpp, line 123 https://git.reviewboard.kde.org/r/115710/diff/3/?file=246152#file246152line123 q-connect is a strange way to call a static method. QObject::connect would be usual (if a bit more verbose). IMHO, it isn't actually so strange: Instead of QObject::connect(sender, SIGNAL, receiver, SLOT); it becomes receiver-connect(sender, SIGNAL, SLOT); http://qt-project.org/doc/qt-5/qobject.html#connect-3 Am I right? - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/#review51125 --- On Feb. 25, 2014, 10:50 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/ --- (Updated Feb. 25, 2014, 10:50 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private methods and slots behind the d-pointer in KHistoryComboBox Also: -Remove header not used Diffs - autotests/kcombobox_unittest.cpp 49ef721 src/khistorycombobox.h 3667eb4 src/khistorycombobox.cpp 6f81dda Diff: https://git.reviewboard.kde.org/r/115710/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116068: Bump supported DocBookXML version to 4.5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116068/ --- (Updated Feb. 27, 2014, 10:40 p.m.) Review request for Documentation and KDE Frameworks. Changes --- - remove compatibility variables (never exported in kdelibs times, used only in kdoctools); PING: any feedback? I would like to push this into alpha2. Repository: kdoctools Description --- - rename the DTD file (the old one will be kept for for compatibility in kde4support) - adapt the existing documentation: - please note that these changes (usage of the new DTD) should be applied to all the documentation shipped with other Frameworks and with the documentation of modules that do not require KDE4Support (see next RR).-- The change should be mostly a matter of replacing the DTD, as DocBookXML 4.5 is backward compatible with 4.2 according the specifications. This RR comprises the steps 3a) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs (updated) - src/CMakeLists.txt 0329bd3 docs/meinproc5/man-meinproc5.8.docbook 77799b4 docs/qt5options/man-qt5options.7.docbook 7afbf07 docs/kf5options/man-kf5options.7.docbook cb7973d cmake/FindDocBookXML4.cmake eb4bfd8 docs/checkXML5/man-checkXML5.1.docbook 68509b9 src/customization/catalog.xml 229ae70 src/customization/dtd/kdedbx45.dtd.cmake PRE-CREATION src/customization/dtd/kdex.dtd.cmake c2f7b2c src/man-template.docbook bdc88c7 src/template.docbook 08762e5 Diff: https://git.reviewboard.kde.org/r/116068/diff/ Testing --- Compilation (including the other RR) Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116069: Compatibility support for DocBookXML 4.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116069/ --- (Updated Feb. 27, 2014, 10:43 p.m.) Review request for Documentation and KDE Frameworks. Changes --- - remove compatibility variables as in the parent RR PING: any feedback? I would like to push this into alpha2. Repository: kde4support Description --- - If this patch is applied, once kde4support is *installed* (no explicit dependency is needed), other modules can use the old DTD. Of course it's better to port them to the new one. - Please note that some files should be copied with complete history from the corresponding files in kdoctools before the changes of RR116068: cmake/FindDocBookXML4.cmake (copied and unchanged) src/customization/catalog4.xml (from catalog.xml, then modified) src/customization/dtd/kdex.dtd.cmake (copied and unchanged) - this patch includes also the commit which bumps the included documentation to 4.5 (needed in order to test this patch and RR116068). This RR comprises the steps 2), 3b) and (limited to the current module) 3c) of the plan described here: http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/011978.html Diffs (updated) - cmake/FindDocBookXML4.cmake PRE-CREATION docs/kf5-config/man-kf5-config.1.docbook ae567bf src/CMakeLists.txt 6bda099 src/customization/catalog4.xml PRE-CREATION src/customization/dtd/kdex.dtd.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116069/diff/ Testing --- Compilation of kde4support (with RR116068), then compilation of konsole. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
On Feb. 26, 2014, 9:57 p.m., Albert Astals Cid wrote:
have you tried removing the include?
Albert Astals Cid wrote:
Ignore me, there's i18n calls in there :D
Alex Merry wrote:
However, I wonder if those calls should really be in the header. I have
no idea what catalogue they will use at runtime; I suspect it will depend on
whether code that includes the header defined TRANSLATION_DOMAIN and where,
exactly, they do so.
A better solution (SC but not BC) is probably to create overloaded
methods and put those calls in the cpp file.
Aurélien Gâteau wrote:
May I suggest this instead:
diff --git a/src/core/slavebase.cpp b/src/core/slavebase.cpp
index 1236ad5..2002cdf 100644
--- a/src/core/slavebase.cpp
+++ b/src/core/slavebase.cpp
@@ -968,9 +968,11 @@ int SlaveBase::messageBox(MessageBoxType type, const
QString text, const QStrin
}
int SlaveBase::messageBox(const QString text, MessageBoxType type,
const QString caption,
- const QString buttonYes, const QString
buttonNo,
+ const QString _buttonYes, const QString
_buttonNo,
const QString dontAskAgainName)
{
+QString buttonYes = _buttonYes.isEmpty() ? i18n(Yes) : _buttonYes;
+QString buttonNo = _buttonNo.isEmpty() ? i18n(No) : _buttonNo;
//qDebug() messageBox type text -
caption buttonYes buttonNo;
KIO_DATA (qint32)type text caption buttonYes buttonNo
dontAskAgainName;
send(INF_MESSAGEBOX, data);
diff --git a/src/core/slavebase.h b/src/core/slavebase.h
index 86f1506..0922893 100644
--- a/src/core/slavebase.h
+++ b/src/core/slavebase.h
@@ -24,7 +24,6 @@
#include kio/udsentry.h
#include kio/authinfo.h
#include job_base.h // for KIO::JobFlags
-#include klocalizedstring.h
#include QtCore/QByteArray
#include QtNetwork/QHostInfo
@@ -277,8 +276,8 @@ public:
*/
int messageBox(MessageBoxType type, const QString text,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No));
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString());
/**
* Call this to show a message box from the slave
@@ -297,8 +296,8 @@ public:
*/
int messageBox(const QString text, MessageBoxType type,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No),
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString(),
const QString dontAskAgainName = QString());
/**
Matthieu Gallien wrote:
Aurélien, do you want me to update the review request or do you do it
directly yourself ?
If we go Aurélien's way i'd document that QString() means Yes/No and not an
empty string in there (which is actually be runtime incompatible with kde4.x
but i think that's fair and not much people would be passing there to get a
button with no text)
Moreover we could go with isNull instead of isEmpty so that actually passing
does give you an empty button and QString() gives you yes/no.
- Albert
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/#review50988
---
On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/
---
(Updated Feb. 26, 2014, 9:44 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is
publically installed.
Diffs
-
KF5KIOConfig.cmake.in 3a947b7
src/core/CMakeLists.txt d897e37
Diff: https://git.reviewboard.kde.org/r/116103/diff/
Testing
---
Thanks,
Matthieu Gallien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116124: Always compile static lib with -fPIC
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116124/#review51207 --- Ship it! I've seen the discussion in kde-frameworks-devel, my knowledge in this area is not so much but you convinced me, and we have some time for going back in case of issues. - Luigi Toscano On Feb. 27, 2014, 3:21 p.m., Kevin Funk wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116124/ --- (Updated Feb. 27, 2014, 3:21 p.m.) Review request for KDE Frameworks. Repository: kdoctools Description --- Always compile static lib with -fPIC See http://mail.kde.org/pipermail/kde-frameworks-devel/2014-February/012375.html Diffs - src/CMakeLists.txt 0329bd383415b4fa265c1edd7f0f7d384fd17395 Diff: https://git.reviewboard.kde.org/r/116124/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KActivities frameworks soon to become master
El Dijous, 27 de febrer de 2014, a les 11:23:59, Ivan Čukić va escriure: Hi all, Now that the 4.13 has been branched out, KActivities will stop using the frameworks branch, and master will become the 'new black'. There is only a question of how to proceed. - Is it wiser just to ask the admins to move rename the branches (removing the old master) and blacklist the frameworks branch? Personally i'd just merge framewoks to master and then blacklist framewoks - Should anything apart from the relevant file in kdesrc-build be changed? kde:kde-build-metadata probably needs some updating too - Who are interested parties that this should be communicated to? I'd go with kde-devel and release-team in addition to the current CC'ers. Cheers, Albert 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
[solid] src/imports: Relicense solid imports files to LGPLv2.1+
Git commit 5bebd4332ea137849f2060f12a684551dbc81dc6 by Alex Merry. Committed on 28/02/2014 at 00:41. Pushed by alexmerry into branch 'master'. Relicense solid imports files to LGPLv2.1+ Permission granted by Ivan Čukić. CCMAIL: ivan.cu...@kde.org CCMAIL: kde-licens...@kde.org CCMAIL: kde-frameworks-devel@kde.org CCMAIL: hrvoje.sen...@gmail.com M +9-11 src/imports/devices.cpp M +9-11 src/imports/devices.h M +9-11 src/imports/devices_p.h M +9-11 src/imports/solidextensionplugin.cpp M +9-11 src/imports/solidextensionplugin.h http://commits.kde.org/solid/5bebd4332ea137849f2060f12a684551dbc81dc6 diff --git a/src/imports/devices.cpp b/src/imports/devices.cpp index 004a195..a586728 100644 --- a/src/imports/devices.cpp +++ b/src/imports/devices.cpp @@ -1,20 +1,18 @@ /* * Copyright (C) 2013 Ivan Cukic ivan.cukic(at)kde.org * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2, - * or (at your option) any later version, as published by the Free - * Software Foundation + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. * - * This program is distributed in the hope that it will be useful, + * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. * - * You should have received a copy of the GNU General Public - * License along with this program; if not, write to the - * Free Software Foundation, Inc., - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see http://www.gnu.org/licenses/. */ #include devices.h diff --git a/src/imports/devices.h b/src/imports/devices.h index efdbd0e..e321c5c 100644 --- a/src/imports/devices.h +++ b/src/imports/devices.h @@ -1,20 +1,18 @@ /* * Copyright (C) 2013 Ivan Cukic ivan.cukic(at)kde.org * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2, - * or (at your option) any later version, as published by the Free - * Software Foundation + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. * - * This program is distributed in the hope that it will be useful, + * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU + * Lesser General Public License for more details. * - * You should have received a copy of the GNU General Public - * License along with this program; if not, write to the - * Free Software Foundation, Inc., - * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + * You should have received a copy of the GNU Lesser General Public + * License along with this library. If not, see http://www.gnu.org/licenses/. */ #ifndef SOLID_DECALARATIVE_DEVICES_H diff --git a/src/imports/devices_p.h b/src/imports/devices_p.h index ac26cb3..7d5a1f9 100644 --- a/src/imports/devices_p.h +++ b/src/imports/devices_p.h @@ -1,20 +1,18 @@ /* * Copyright (C) 2013 Ivan Cukic ivan.cukic(at)kde.org * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2, - * or (at your option) any later version, as published by the Free - * Software Foundation + * This library is free software; you can redistribute it and/or + * modify it under the terms of the GNU Lesser General Public + * License as published by the Free Software Foundation; either + * version 2.1 of the License, or (at your option) any later version. * - * This program is distributed in the hope that it will be useful, + * This library is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details + * MERCHANTABILITY
Re: Review Request 116012: Inline deprecated methods, and silence false positives in tests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/#review51276 --- This review has been submitted with commit a2104ae9f5ca4d85306d084a95814cd6fae9fa79 by Alex Merry to branch master. - Commit Hook On Feb. 24, 2014, 12:12 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/ --- (Updated Feb. 24, 2014, 12:12 p.m.) Review request for KDE Frameworks. Repository: karchive Description --- Four commits (in git log order): Simplify autotests CMakeLists.txt Separate out tests of deprecated functions to their own file This allows us to disable deprecation warnings just for that file. Inline deprecated methods This both documents how to replace them in the headers and ensures that enabling or disabling deprecated functions does not affect the ABI. Use KARCHIVE_NO_DEPRECATED instead of KDE_NO_DEPRECATED Diffs - autotests/CMakeLists.txt 1da853fe49ec6fca40ccf417db788340124b41e5 autotests/deprecatedtest.cpp PRE-CREATION autotests/karchivetest.cpp 6d6b5848ce9add84736968dd13f529711f895493 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchive.cpp a25b85e41618d1f7ae62e7e41966afe1a8aaef8e src/kfilterdev.h 4a35879a15992d19378c7e9baa9b206e187713fd src/kfilterdev.cpp 60660a0c08922ee0f4ddaf4ad4d1adf0e7f1c5a3 Diff: https://git.reviewboard.kde.org/r/116012/diff/ Testing --- Builds, tests pass. No deprecation warnings (before there were two in the tests). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116012: Inline deprecated methods, and silence false positives in tests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/ --- (Updated Feb. 28, 2014, 12:58 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: karchive Description --- Four commits (in git log order): Simplify autotests CMakeLists.txt Separate out tests of deprecated functions to their own file This allows us to disable deprecation warnings just for that file. Inline deprecated methods This both documents how to replace them in the headers and ensures that enabling or disabling deprecated functions does not affect the ABI. Use KARCHIVE_NO_DEPRECATED instead of KDE_NO_DEPRECATED Diffs - autotests/CMakeLists.txt 1da853fe49ec6fca40ccf417db788340124b41e5 autotests/deprecatedtest.cpp PRE-CREATION autotests/karchivetest.cpp 6d6b5848ce9add84736968dd13f529711f895493 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchive.cpp a25b85e41618d1f7ae62e7e41966afe1a8aaef8e src/kfilterdev.h 4a35879a15992d19378c7e9baa9b206e187713fd src/kfilterdev.cpp 60660a0c08922ee0f4ddaf4ad4d1adf0e7f1c5a3 Diff: https://git.reviewboard.kde.org/r/116012/diff/ Testing --- Builds, tests pass. No deprecation warnings (before there were two in the tests). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116012: Inline deprecated methods, and silence false positives in tests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/#review51273 --- This review has been submitted with commit 06ca03a9482fd069830b89267adb54c168590375 by Alex Merry to branch master. - Commit Hook On Feb. 24, 2014, 12:12 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/ --- (Updated Feb. 24, 2014, 12:12 p.m.) Review request for KDE Frameworks. Repository: karchive Description --- Four commits (in git log order): Simplify autotests CMakeLists.txt Separate out tests of deprecated functions to their own file This allows us to disable deprecation warnings just for that file. Inline deprecated methods This both documents how to replace them in the headers and ensures that enabling or disabling deprecated functions does not affect the ABI. Use KARCHIVE_NO_DEPRECATED instead of KDE_NO_DEPRECATED Diffs - autotests/CMakeLists.txt 1da853fe49ec6fca40ccf417db788340124b41e5 autotests/deprecatedtest.cpp PRE-CREATION autotests/karchivetest.cpp 6d6b5848ce9add84736968dd13f529711f895493 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchive.cpp a25b85e41618d1f7ae62e7e41966afe1a8aaef8e src/kfilterdev.h 4a35879a15992d19378c7e9baa9b206e187713fd src/kfilterdev.cpp 60660a0c08922ee0f4ddaf4ad4d1adf0e7f1c5a3 Diff: https://git.reviewboard.kde.org/r/116012/diff/ Testing --- Builds, tests pass. No deprecation warnings (before there were two in the tests). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116012: Inline deprecated methods, and silence false positives in tests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/#review51275 --- This review has been submitted with commit e6b97bf5b3820b90cdf2ef5663eb1b21aac85110 by Alex Merry to branch master. - Commit Hook On Feb. 24, 2014, 12:12 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/ --- (Updated Feb. 24, 2014, 12:12 p.m.) Review request for KDE Frameworks. Repository: karchive Description --- Four commits (in git log order): Simplify autotests CMakeLists.txt Separate out tests of deprecated functions to their own file This allows us to disable deprecation warnings just for that file. Inline deprecated methods This both documents how to replace them in the headers and ensures that enabling or disabling deprecated functions does not affect the ABI. Use KARCHIVE_NO_DEPRECATED instead of KDE_NO_DEPRECATED Diffs - autotests/CMakeLists.txt 1da853fe49ec6fca40ccf417db788340124b41e5 autotests/deprecatedtest.cpp PRE-CREATION autotests/karchivetest.cpp 6d6b5848ce9add84736968dd13f529711f895493 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchive.cpp a25b85e41618d1f7ae62e7e41966afe1a8aaef8e src/kfilterdev.h 4a35879a15992d19378c7e9baa9b206e187713fd src/kfilterdev.cpp 60660a0c08922ee0f4ddaf4ad4d1adf0e7f1c5a3 Diff: https://git.reviewboard.kde.org/r/116012/diff/ Testing --- Builds, tests pass. No deprecation warnings (before there were two in the tests). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116012: Inline deprecated methods, and silence false positives in tests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116012/ --- (Updated Feb. 28, 2014, 12:58 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: karchive Description --- Four commits (in git log order): Simplify autotests CMakeLists.txt Separate out tests of deprecated functions to their own file This allows us to disable deprecation warnings just for that file. Inline deprecated methods This both documents how to replace them in the headers and ensures that enabling or disabling deprecated functions does not affect the ABI. Use KARCHIVE_NO_DEPRECATED instead of KDE_NO_DEPRECATED Diffs - autotests/CMakeLists.txt 1da853fe49ec6fca40ccf417db788340124b41e5 autotests/deprecatedtest.cpp PRE-CREATION autotests/karchivetest.cpp 6d6b5848ce9add84736968dd13f529711f895493 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchive.cpp a25b85e41618d1f7ae62e7e41966afe1a8aaef8e src/kfilterdev.h 4a35879a15992d19378c7e9baa9b206e187713fd src/kfilterdev.cpp 60660a0c08922ee0f4ddaf4ad4d1adf0e7f1c5a3 Diff: https://git.reviewboard.kde.org/r/116012/diff/ Testing --- Builds, tests pass. No deprecation warnings (before there were two in the tests). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
On Feb. 26, 2014, 9:57 p.m., Albert Astals Cid wrote:
have you tried removing the include?
Albert Astals Cid wrote:
Ignore me, there's i18n calls in there :D
Alex Merry wrote:
However, I wonder if those calls should really be in the header. I have
no idea what catalogue they will use at runtime; I suspect it will depend on
whether code that includes the header defined TRANSLATION_DOMAIN and where,
exactly, they do so.
A better solution (SC but not BC) is probably to create overloaded
methods and put those calls in the cpp file.
Aurélien Gâteau wrote:
May I suggest this instead:
diff --git a/src/core/slavebase.cpp b/src/core/slavebase.cpp
index 1236ad5..2002cdf 100644
--- a/src/core/slavebase.cpp
+++ b/src/core/slavebase.cpp
@@ -968,9 +968,11 @@ int SlaveBase::messageBox(MessageBoxType type, const
QString text, const QStrin
}
int SlaveBase::messageBox(const QString text, MessageBoxType type,
const QString caption,
- const QString buttonYes, const QString
buttonNo,
+ const QString _buttonYes, const QString
_buttonNo,
const QString dontAskAgainName)
{
+QString buttonYes = _buttonYes.isEmpty() ? i18n(Yes) : _buttonYes;
+QString buttonNo = _buttonNo.isEmpty() ? i18n(No) : _buttonNo;
//qDebug() messageBox type text -
caption buttonYes buttonNo;
KIO_DATA (qint32)type text caption buttonYes buttonNo
dontAskAgainName;
send(INF_MESSAGEBOX, data);
diff --git a/src/core/slavebase.h b/src/core/slavebase.h
index 86f1506..0922893 100644
--- a/src/core/slavebase.h
+++ b/src/core/slavebase.h
@@ -24,7 +24,6 @@
#include kio/udsentry.h
#include kio/authinfo.h
#include job_base.h // for KIO::JobFlags
-#include klocalizedstring.h
#include QtCore/QByteArray
#include QtNetwork/QHostInfo
@@ -277,8 +276,8 @@ public:
*/
int messageBox(MessageBoxType type, const QString text,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No));
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString());
/**
* Call this to show a message box from the slave
@@ -297,8 +296,8 @@ public:
*/
int messageBox(const QString text, MessageBoxType type,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No),
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString(),
const QString dontAskAgainName = QString());
/**
Matthieu Gallien wrote:
Aurélien, do you want me to update the review request or do you do it
directly yourself ?
Albert Astals Cid wrote:
If we go Aurélien's way i'd document that QString() means Yes/No and not
an empty string in there (which is actually be runtime incompatible with
kde4.x but i think that's fair and not much people would be passing there
to get a button with no text)
Moreover we could go with isNull instead of isEmpty so that actually
passing does give you an empty button and QString() gives you yes/no.
Aurélien Gâteau wrote:
@Matthieu: Feel free to update the review request, that's less work.
@Albert: The doc for the methods actually already says it the default
values is i18n(Yes) and i18n(No).
Albert is right: the default value is not the same as an empty string.
You'll be changing the result of
messageBox(type, blah, some caption, , );
Not that this is a sensible call to make, but it should be documented.
I also agree with Albert that isNull() is a better check than isEmpty().
- Alex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/#review50988
---
On Feb. 26, 2014, 9:44 p.m., Matthieu Gallien wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/
---
(Updated Feb. 26, 2014, 9:44 p.m.)
Review request for KDE Frameworks.
Repository: kio
Description
---
include/KF5/KIOCore/kio/slavebase.h is including headers from KI18N and is
publically installed.
Diffs
-
KF5KIOConfig.cmake.in 3a947b7
src/core/CMakeLists.txt d897e37
Diff:
Re: Review Request 116037: change entities to reflect new branding
On Feb. 25, 2014, 10:46 a.m., Burkhard Lück wrote: I am fine with the new entities. But the entities *must* be in all replaceablelang/replaceable/user.entities (48) files as well. Without having the entities in all language user.entities the generation of language docbbooks using one of these new entities breaks. Hmm, should I just define them in English for now and put a call out to kde-i18n-doc for them to be translated after this gets committed? - T.C. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116037/#review50791 --- On Feb. 25, 2014, 1:02 a.m., T.C. Hollingsworth wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116037/ --- (Updated Feb. 25, 2014, 1:02 a.m.) Review request for Documentation, KDE Frameworks, Luigi Toscano, Burkhard Lück, and Yuri Chornoivan. Repository: kdoctools Description --- -kde; is no longer semantically identified as an acronym, but instead as an organization -new translatable entities for KDE Frameworks are added -new translatable entities for the KDE SC are added -new translatable entities for the various incarnations of Plasma are added with this I can finally kill the temporary entities that have been in kde-runtime.git/doc/fundamentals for over a year now. :-) Diffs - src/customization/en/user.entities 47bfe0d src/customization/entities/general.entities 183fbc9 Diff: https://git.reviewboard.kde.org/r/116037/diff/ Testing --- kdoctools still builds, kate docs still meinproc5 successfully Thanks, T.C. Hollingsworth ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdesrc-build: stop after failure? --truly-verbose?
On Thu, February 27, 2014 11:35:16 Kevin Funk wrote: Am Mittwoch, 26. Februar 2014, 23:27:08 schrieb Michael Pyne: On Wed, February 26, 2014 22:30:48 Milian Wolff wrote: Also, while at it, could we get a truly verbose flag, which actually outputs the output from whatever tool is currently running? If you file a bug I'd probably implement it. --debug did this kind of thing (it might even still do it, but it would be too annoying to use here). I say file a bug only because it's guaranteed it'll drop off my plate otherwise. Yep, --debug still works as intended. I use it a lot, but only if I build single packages or combined with --stop- on-failure=1. You should document that --debug flag, too, I'd say. I had to grep the code for it as well when I first wondered how to make kdesrc-build print everything to stdout. It's documented in both the man page and the DocBook/website documentation. Do you mean that the documentation is inadequate? It's also possible it wasn't documented when you looked but I've already fixed it. ;) Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/#review51292 --- src/khistorycombobox.cpp https://git.reviewboard.kde.org/r/115710/#comment36127 Ah sorry I hadn't seen that this was the 3-args overload rather than the 4-args overload. Objection withdrawn. - David Faure On Feb. 25, 2014, 10:50 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/ --- (Updated Feb. 25, 2014, 10:50 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Hide private methods and slots behind the d-pointer in KHistoryComboBox Also: -Remove header not used Diffs - autotests/kcombobox_unittest.cpp 49ef721 src/khistorycombobox.h 3667eb4 src/khistorycombobox.cpp 6f81dda Diff: https://git.reviewboard.kde.org/r/115710/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.
On Feb. 24, 2014, 9:22 p.m., Albert Astals Cid wrote:
src/khelpclient.cpp, line 76
https://git.reviewboard.kde.org/r/115959/diff/2/?file=245608#file245608line76
url is always help:/ isn't it? Not sure i understand the comment
David Faure wrote:
? Not sure I understand *your* comment :-)
QUrl url;
if (!docPath.isEmpty()) {
url =
QUrl(QLatin1String(help:/)).resolved(QUrl::fromUserInput(docPath));
} else {
url =
QUrl(QString::fromLatin1(help:/%1/index.html).arg(appname));
}
if (!anchor.isEmpty()) {
QUrlQuery query(url);
query.addQueryItem(QString::fromLatin1(anchor), anchor);
url.setQuery(query);
}
How is this always help:/ ? There much stuff after that, in the path
and possibly in the query.
Albert Astals Cid wrote:
I mean starts always with help:/, sorry. And if it always starts with
help, the comment
// launch khelpcenter, or a browser for URIs not handled by khelpcenter
is a bit weird, since it's always the same kind of URIs, no?
Ah, I see.
No, the docPath (from the .desktop file) can be an absolute URL, and something
like QUrl(help:/).resolved(http://www.kde.org;) gives http://www.kde.org;.
(the point of the call to resolved is to handle relative urls, but it also
handles absolute urls by just returning that).
- David
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115959/#review50765
---
On Feb. 23, 2014, 11 a.m., David Faure wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115959/
---
(Updated Feb. 23, 2014, 11 a.m.)
Review request for KDE Frameworks and Albert Astals Cid.
Repository: kconfigwidgets
Description
---
3 commits:
Unittest: make errors readable
--
Resurrect KConfigDialog::setHelp (used to come from KDialog).
It controls the default behavior of showHelp(), which is implemented
using KHelpClient.
REVIEW: 115959
--
Move KHelpClient down from kxmlgui, for use in KConfigDialog.
Diffs
-
autotests/kconfigdialog_unittest.cpp
e5322c1782c2a68c15451777066e28a9b7afea23
src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36
src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280
src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405
src/khelpclient.h PRE-CREATION
src/khelpclient.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/115959/diff/
Testing
---
Compiled all of KF5.
Thanks,
David Faure
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116103: Make KI18N a public dependency of KIO since public installed headers of KIO requires it
On Feb. 26, 2014, 10:57 p.m., Albert Astals Cid wrote:
have you tried removing the include?
Albert Astals Cid wrote:
Ignore me, there's i18n calls in there :D
Alex Merry wrote:
However, I wonder if those calls should really be in the header. I have
no idea what catalogue they will use at runtime; I suspect it will depend on
whether code that includes the header defined TRANSLATION_DOMAIN and where,
exactly, they do so.
A better solution (SC but not BC) is probably to create overloaded
methods and put those calls in the cpp file.
Aurélien Gâteau wrote:
May I suggest this instead:
diff --git a/src/core/slavebase.cpp b/src/core/slavebase.cpp
index 1236ad5..2002cdf 100644
--- a/src/core/slavebase.cpp
+++ b/src/core/slavebase.cpp
@@ -968,9 +968,11 @@ int SlaveBase::messageBox(MessageBoxType type, const
QString text, const QStrin
}
int SlaveBase::messageBox(const QString text, MessageBoxType type,
const QString caption,
- const QString buttonYes, const QString
buttonNo,
+ const QString _buttonYes, const QString
_buttonNo,
const QString dontAskAgainName)
{
+QString buttonYes = _buttonYes.isEmpty() ? i18n(Yes) : _buttonYes;
+QString buttonNo = _buttonNo.isEmpty() ? i18n(No) : _buttonNo;
//qDebug() messageBox type text -
caption buttonYes buttonNo;
KIO_DATA (qint32)type text caption buttonYes buttonNo
dontAskAgainName;
send(INF_MESSAGEBOX, data);
diff --git a/src/core/slavebase.h b/src/core/slavebase.h
index 86f1506..0922893 100644
--- a/src/core/slavebase.h
+++ b/src/core/slavebase.h
@@ -24,7 +24,6 @@
#include kio/udsentry.h
#include kio/authinfo.h
#include job_base.h // for KIO::JobFlags
-#include klocalizedstring.h
#include QtCore/QByteArray
#include QtNetwork/QHostInfo
@@ -277,8 +276,8 @@ public:
*/
int messageBox(MessageBoxType type, const QString text,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No));
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString());
/**
* Call this to show a message box from the slave
@@ -297,8 +296,8 @@ public:
*/
int messageBox(const QString text, MessageBoxType type,
const QString caption = QString(),
- const QString buttonYes = i18n(Yes),
- const QString buttonNo = i18n(No),
+ const QString buttonYes = QString(),
+ const QString buttonNo = QString(),
const QString dontAskAgainName = QString());
/**
Matthieu Gallien wrote:
Aurélien, do you want me to update the review request or do you do it
directly yourself ?
Albert Astals Cid wrote:
If we go Aurélien's way i'd document that QString() means Yes/No and not
an empty string in there (which is actually be runtime incompatible with
kde4.x but i think that's fair and not much people would be passing there
to get a button with no text)
Moreover we could go with isNull instead of isEmpty so that actually
passing does give you an empty button and QString() gives you yes/no.
Aurélien Gâteau wrote:
@Matthieu: Feel free to update the review request, that's less work.
@Albert: The doc for the methods actually already says it the default
values is i18n(Yes) and i18n(No).
Alex Merry wrote:
Albert is right: the default value is not the same as an empty
string. You'll be changing the result of
messageBox(type, blah, some caption, , );
Not that this is a sensible call to make, but it should be documented.
I also agree with Albert that isNull() is a better check than isEmpty().
I don't mind if the code uses isNull() instead of isEmpty(), but documenting
this sounds wrong.
Academically that make sense, but it really is not pragmatic. What would the
documentation look like? Something like this: If you want to create empty
buttons, pass to buttonYes and buttonNo.? The best API are the ones which
are impossible to use wrong. As such I strongly advice against documenting how
to achieve such a broken result, unless you can find a valid reason why one
would want to create empty buttons.
- Aurélien
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116103/#review50988
---
On Feb. 26, 2014, 10:44 p.m., Matthieu Gallien wrote:
Binary incompatible changes
Hi all, As there still seem to be remnants of the last BIC change to Frameworks around i've now commenced a force rebuild of all Frameworks on the CI system. Apologies in advance for any noise this creates - but it is necessary for this to be fixed to allow for other Frameworks dependent projects to use the CI system in a functional manner. I suggest that any further BC or SC changes be rolled out more carefully, with pushes being separated by sufficient time for the CI system to complete builds of earlier modules. Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
