Re: Review Request 116866: Use std::isnan on compilers that support it (fixes MinGW on Windows)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/#review53309 --- src/ConfigureChecks.cmake https://git.reviewboard.kde.org/r/116866/#comment37507 Either this line should be removed from here, or it should be added to kcolorutils.cpp (otherwise you're testing in one environment and using it in another). - Alex Merry On March 18, 2014, 3:18 a.m., Michael Hansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/ --- (Updated March 18, 2014, 3:18 a.m.) Review request for KDE Frameworks. Repository: kguiaddons Description --- Use std::isnan from cmath instead of isnan from math.h, as MinGW-32 on Windows does not include the latter. This keeps the _isnan hack for MSVC, since that compiler doesn't include either standard version :(. Diffs - src/CMakeLists.txt 624d2e109be5c26af9781101a005b4a163361a92 src/ConfigureChecks.cmake PRE-CREATION src/colors/kcolorutils.cpp 7df25b3d7acbb65b29513d2139d7b83de53ee4c2 src/kguiaddons_config.h.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116866/diff/ Testing --- Compiled with MSVC10 (32-bit), MinGW 4.8 (32-bit, Windows native), and GCC 4.8 (Arch x86_64). Thanks, Michael Hansen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116768: Make our css more future-proof
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116768/#review53310 --- This review has been submitted with commit eb06439d9e7e90017929f7b82b8268de2713d9c5 by Aurélien Gâteau to branch master. - Commit Hook On March 12, 2014, 3:49 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116768/ --- (Updated March 12, 2014, 3:49 p.m.) Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- - Remove outdated files - Extend the doxygen.css file provided by Doxygen instead of replacing it - Trim kde.css to contain only necessary lines Diffs - src/kapidox/data/htmlresource/print.css 16818ba src/kapidox/data/htmlresource/tabs.css a61552a src/kapidox/data/htmlresource/kde.css c6c2d86 src/kapidox/data/header.html 109045e src/kapidox/data/htmlresource/flat.css e1db552 src/kapidox/__init__.py 3127357 src/kapidox/data/doxygen.css a0f924e Diff: https://git.reviewboard.kde.org/r/116768/diff/ Testing --- Regenerated doc for all frameworks using kgenframeworksapidox. Browsed around. Did not spot regressions. 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 116768: Make our css more future-proof
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116768/ --- (Updated March 18, 2014, 10:32 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- - Remove outdated files - Extend the doxygen.css file provided by Doxygen instead of replacing it - Trim kde.css to contain only necessary lines Diffs - src/kapidox/data/htmlresource/print.css 16818ba src/kapidox/data/htmlresource/tabs.css a61552a src/kapidox/data/htmlresource/kde.css c6c2d86 src/kapidox/data/header.html 109045e src/kapidox/data/htmlresource/flat.css e1db552 src/kapidox/__init__.py 3127357 src/kapidox/data/doxygen.css a0f924e Diff: https://git.reviewboard.kde.org/r/116768/diff/ Testing --- Regenerated doc for all frameworks using kgenframeworksapidox. Browsed around. Did not spot regressions. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to normal : krunner_master_qt5 #36
See http://build.kde.org/job/krunner_master_qt5/36/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116798: Rewrite KUser/KUserGroup Widows implementation + introduce KUserId/KGroupId
On March 17, 2014, 4:28 p.m., Aurélien Gâteau wrote: src/lib/util/kuser.h, line 216 https://git.reviewboard.kde.org/r/116798/diff/4/?file=254169#file254169line216 I know the review has already been submitted, but shouldn't this be const KUserId uid instead of KUserId uid? Same for KUserGroup. It is just a uint16/uint32 on Linux, I don't see an advantage in passing that by const reference. On Windows it only increments the refcount once too much (assuming the compiler isn't clever enough) since it is stored in the Private class anyway. - Alexander --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/#review53177 --- On March 16, 2014, 10:55 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/ --- (Updated March 16, 2014, 10:55 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- This was all started in order to get KIO to compile on Windows (uses uid_t/gid_t, getpwent, getpwuid, getuid, etc.) This patchset introduces KUserId/KGroupId which is a no-overhead wrapper around uid_t/gid_t and implicitly shares a SID on Windows. Also introduced a maxCount paramter to all listing functions of KUser/KUserGroup so that the manual calls to getpwent() in KIO can be replaced Finally added a unit test for KUser, KUserGroup, KUserId, KGroupId to ensure that these changes are safe Windows only changes: - KUser::homeDirectory() works properly, before it always returned the home directory of the current user - KUser::faceIconPath() is now implemented on Windows - Use scoped pointers everywhere - no memory leaks (at least one was fixed) This is actually a series of commits, if you think that is easier to review I can push them somewhere. Diffs - autotests/CMakeLists.txt 30ac97822a77e4b12b0e81a4a5c93fe9a768d915 autotests/kusertest.cpp PRE-CREATION src/lib/util/kuser.h 42c81156831d0269c89435c76c3572dcf2e085b5 src/lib/util/kuser_unix.cpp aa2f9073015c7f9feb8f74e3646928d2fa2de007 src/lib/util/kuser_win.cpp 06759afa34ea7015a44cf9b38f541f944f8126d4 Diff: https://git.reviewboard.kde.org/r/116798/diff/ Testing --- Wrote new unit test, passes on Linux and Windows, KIO is closer to compiling on windows 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 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/#review53313 --- This review has been submitted with commit c1b5bb1298390a2e8a843f710212c193e0d25d50 by Alex Richardson to branch master. - Commit Hook On March 15, 2014, 3:37 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115918/ --- (Updated March 15, 2014, 3:37 p.m.) Review request for KDE Frameworks and Stephen Kelly. 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 55fba4288dd16a97bf388f77c5c923c6136fab81 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: 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/ --- (Updated March 18, 2014, 12:17 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Stephen Kelly. 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 55fba4288dd16a97bf388f77c5c923c6136fab81 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: Review Request 116699: No longer use pid_t or Q_PID
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116699/#review53314 --- This review has been submitted with commit d1b2b0de8bf138c486be1540cd054e30889215af by Alex Richardson to branch master. - Commit Hook On March 12, 2014, 7:36 a.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116699/ --- (Updated March 12, 2014, 7:36 a.m.) Review request for KDE Frameworks, David Faure and Oswald Buddenhagen. Repository: kio Description --- No longer use pid_t or Q_PID Instead use a new typedef KIO::ProcessId. This is needed for Windows where pid_t doesn't exist and Q_PID is actually a pointer to a structure Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 src/core/idleslave.h d3e7add4460d38212858666afa22deb3e5ef8687 src/core/idleslave.cpp 31d145e5d5e0c4205eb7deec6de7677061bb8a25 src/core/scheduler.h 593174e770d24c6ef813d91dfb6d6ed716bba4f9 src/core/scheduler.cpp 5a4ad310e34587249e0b50c67e011d516858e130 src/core/slave.h e4a443d191faefa535072d3821bb84cb6ab55909 src/core/slave.cpp 404a0c20f57e7c2badd7ac9c1294224d59960f7c src/core/slavebase.cpp a32c6b6ad2b803e24c1db75321aefb916678c03d src/core/slaveinterface.h 1ee7c1aebbf29271da605f33a5587974a4e71a5b src/core/slaveinterface.cpp f8d7d52864ab6dd11316a1252fbd1e372f7f9ee2 src/widgets/krun.cpp 34708cc5a4b4cf3627deb750020104dd3593ef92 src/widgets/krun_p.h cf44e327e6d5bac0fa69b989bd6036380fc5180c Diff: https://git.reviewboard.kde.org/r/116699/diff/ Testing --- tests still pass 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 116699: No longer use pid_t or Q_PID
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116699/ --- (Updated March 18, 2014, 12:19 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, David Faure and Oswald Buddenhagen. Repository: kio Description --- No longer use pid_t or Q_PID Instead use a new typedef KIO::ProcessId. This is needed for Windows where pid_t doesn't exist and Q_PID is actually a pointer to a structure Diffs - src/core/global.h 7814a52c9656719d301ebd012434a53491ffe159 src/core/idleslave.h d3e7add4460d38212858666afa22deb3e5ef8687 src/core/idleslave.cpp 31d145e5d5e0c4205eb7deec6de7677061bb8a25 src/core/scheduler.h 593174e770d24c6ef813d91dfb6d6ed716bba4f9 src/core/scheduler.cpp 5a4ad310e34587249e0b50c67e011d516858e130 src/core/slave.h e4a443d191faefa535072d3821bb84cb6ab55909 src/core/slave.cpp 404a0c20f57e7c2badd7ac9c1294224d59960f7c src/core/slavebase.cpp a32c6b6ad2b803e24c1db75321aefb916678c03d src/core/slaveinterface.h 1ee7c1aebbf29271da605f33a5587974a4e71a5b src/core/slaveinterface.cpp f8d7d52864ab6dd11316a1252fbd1e372f7f9ee2 src/widgets/krun.cpp 34708cc5a4b4cf3627deb750020104dd3593ef92 src/widgets/krun_p.h cf44e327e6d5bac0fa69b989bd6036380fc5180c Diff: https://git.reviewboard.kde.org/r/116699/diff/ Testing --- tests still pass 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 116798: Rewrite KUser/KUserGroup Widows implementation + introduce KUserId/KGroupId
On March 17, 2014, 4:28 p.m., Aurélien Gâteau wrote: src/lib/util/kuser.h, line 216 https://git.reviewboard.kde.org/r/116798/diff/4/?file=254169#file254169line216 I know the review has already been submitted, but shouldn't this be const KUserId uid instead of KUserId uid? Same for KUserGroup. Alexander Richardson wrote: It is just a uint16/uint32 on Linux, I don't see an advantage in passing that by const reference. On Windows it only increments the refcount once too much (assuming the compiler isn't clever enough) since it is stored in the Private class anyway. OK, never mind then. Thanks for the feedback. - Aurélien --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/#review53177 --- On March 16, 2014, 10:55 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116798/ --- (Updated March 16, 2014, 10:55 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- This was all started in order to get KIO to compile on Windows (uses uid_t/gid_t, getpwent, getpwuid, getuid, etc.) This patchset introduces KUserId/KGroupId which is a no-overhead wrapper around uid_t/gid_t and implicitly shares a SID on Windows. Also introduced a maxCount paramter to all listing functions of KUser/KUserGroup so that the manual calls to getpwent() in KIO can be replaced Finally added a unit test for KUser, KUserGroup, KUserId, KGroupId to ensure that these changes are safe Windows only changes: - KUser::homeDirectory() works properly, before it always returned the home directory of the current user - KUser::faceIconPath() is now implemented on Windows - Use scoped pointers everywhere - no memory leaks (at least one was fixed) This is actually a series of commits, if you think that is easier to review I can push them somewhere. Diffs - autotests/CMakeLists.txt 30ac97822a77e4b12b0e81a4a5c93fe9a768d915 autotests/kusertest.cpp PRE-CREATION src/lib/util/kuser.h 42c81156831d0269c89435c76c3572dcf2e085b5 src/lib/util/kuser_unix.cpp aa2f9073015c7f9feb8f74e3646928d2fa2de007 src/lib/util/kuser_win.cpp 06759afa34ea7015a44cf9b38f541f944f8126d4 Diff: https://git.reviewboard.kde.org/r/116798/diff/ Testing --- Wrote new unit test, passes on Linux and Windows, KIO is closer to compiling on windows Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC on framework localization
On Mon, Mar 17, 2014, at 15:09, Albert Astals Cid wrote: El Dilluns, 17 de març de 2014, a les 08:25:59, Aurélien Gâteau va escriure: On Sat, Mar 15, 2014, at 8:52, Albert Astals Cid wrote: El Divendres, 14 de març de 2014, a les 03:48:49, Aurélien Gâteau va escriure: Hi, I started working on ensuring frameworks can be correctly localized and have some questions. # Messages.sh place I noticed some frameworks already have Messages.sh files in there. Most of them are in src/. Some are in subdirs of src/ (kio, plasma-framework, solid, kwallet, kactivities, kde4support). Are we OK with src/ being the default place, but then its up to the framework maintainer to adjust based on the framework needs? I already updated the framework template in kde:kdeexamples to put a Messages.sh in src/. # No translations Some frameworks have no translatable strings. I think in this case there should not be any Messages.sh file. Is it OK for everybody? Do we want to to guarantee they will keep having no translatable strings in future releases? How do we do it? Or just add a Messages.sh if they have translatable strings in the future? You are right, it feels safer to add a Messages.sh by default. But if you do that you also need to add the code to load the catalog (for the non ki18n based ones since ki18n will do it automatically). Yes. I am currently working on a way to streamline catalog loading for Qt-based translations (going to post about it in a few minutes), but it would still need some manual work for the framework user. So I guess it's still an opened question. Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Tue, Mar 18, 2014 at 4:36 AM, Markus Slopianka kamika...@gmx.de wrote: On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). Um, isn't KDEWebKit missing? Digia already deprecated QtWebKit in favor of Chromium's Blink. Unless anybody is interested in maintaining QtWebKit the KDE bindings should be deprecated as well. Don't you think? ___ This message is from the kde-promo mailing list. Visit https://mail.kde.org/mailman/listinfo/kde-promo to unsubscribe, set digest on or temporarily stop your subscription. Maybe coming up with the list of modules now is not the most useful thing now. Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? A final list could be polished during the KF5 sprint [1]. Aleix [1] https://sprints.kde.org/sprint/224 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Handling of frameworks using Qt-based translations
Hi,
I started working on how to handle Qt based translations, and make it as
simple as possible to work with for framework maintainers as well as
framework users.
I picked KBookmarks as my guinea pig and got to the point where
kbookmarkdialogtest shows a translated dialog.
Here is how it currently works. All of this is liberally inspired from
the way Trojita works:
# String extraction
I created a src/Messages.sh which contains the following:
lupdate -silent -recursive . -ts $podir/tmp.ts
lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
$podir/kbookmarks5.pot
rm $podir/tmp.ts
# String compilation
I modified the toplevel CMakeLists.txt, adding these lines:
if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
qm_setup(kbookmarks5 po)
endif()
I created a QmSupport.cmake file, which exposes a qm_setup() function.
This function does three things:
1. Create a qm target which turns all .po into .qm files.
2. Call install(FILES...) on the generated qm files, installing them in
share/${name}/locale, where ${name} is the firt argument of qm_setup().
3. Generate a ${name}_translation.h which contain two inline functions
to make it easy to load the translations.
Using the translation is then just a matter of including
${name}_translation.h and calling ${name}_installTranslator(). If more
control is needed, ${name}_installTranslator() also accepts an optional
argument: the language. For even finer control, the .h also contains a
${name}_createTranslator() function, which returns a QTranslator loaded
with strings for the right language.
# Questions
Does this approach sounds sane to you?
I think QmSupport.cmake should go to extra-cmake-modules. Any
objections?
Right now qm_setup() is very inflexible: it installs files and creates
the _translation.h file based on the name argument, meaning in my
example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
include/kbookmarks5_translation.h, which contains the functions
kbookmarks5_createTranslator and kbookmarks5_installTranslator.
I think we want to be able to customize the install dir of the
_translation.h file because some frameworks install header files in a
subdir, others do not.
Should we also be able to customize the install data dir for qm files,
as well as the prefix of the function names from _translation.h? I am
tempted to default to ${PROJECT_NAME} for the prefix of the function
names, its lowercase version for the install data dir and add an
optional PROJECT_NAME argument to qm_setup(). Opinions?
I am attaching the diff of the current state. I do not intend to commit
it as is since po files are not supposed to be in the framework
repository, but it should make it easy for you to try it if you are
interested.
Aurélien
diff --git a/CMakeLists.txt b/CMakeLists.txt
index ecb6d87..86bec2e 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -40,6 +40,10 @@ endif()
add_subdirectory(src)
add_subdirectory(tests)
add_subdirectory(autotests)
+if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
+include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
+qm_setup(kbookmarks5 po)
+endif()
# create a Config.cmake and a ConfigVersion.cmake file and install them
set(CMAKECONFIG_INSTALL_DIR ${CMAKECONFIG_INSTALL_PREFIX}/KF5Bookmarks)
diff --git a/QmSupport.cmake b/QmSupport.cmake
new file mode 100644
index 000..7c63064
--- /dev/null
+++ b/QmSupport.cmake
@@ -0,0 +1,53 @@
+# This gives us Qt5::lrelease and Qt5::lupdate but unfortunately no Qt5::lconvert
+find_package(Qt5LinguistTools CONFIG REQUIRED)
+
+# Find lconvert
+get_target_property(lrelease_location Qt5::lrelease LOCATION)
+get_filename_component(lrelease_path ${lrelease_location} PATH)
+find_program(lconvert_executable
+NAMES lconvert-qt5 lconvert
+PATHS ${lrelease_path}
+)
+
+function(_qm_create_target name)
+foreach (it ${ARGN})
+get_filename_component(it ${it} ABSOLUTE)
+# PO files are foo-en_GB.po not foo_en_GB.po like Qt expects
+get_filename_component(fileWithDash ${it} NAME_WE)
+string(REPLACE - _ filenameBase ${fileWithDash})
+file(MAKE_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR})
+set(tsfile ${CMAKE_CURRENT_BINARY_DIR}/${filenameBase}.ts)
+set(qmfile ${CMAKE_CURRENT_BINARY_DIR}/${filenameBase}.qm)
+
+# lconvert from PO to TS and then run lupdate to generate the correct strings
+# finally run lrelease as used above
+add_custom_command(OUTPUT ${qmfile}
+COMMAND ${lconvert_executable}
+ARGS -i ${it} -o ${tsfile}
+COMMAND Qt5::lupdate
+ARGS ${CMAKE_SOURCE_DIR}/src -silent -noobsolete -ts ${tsfile}
+COMMAND Qt5::lrelease
+ARGS -compress -removeidentical -silent ${tsfile} -qm ${qmfile}
+DEPENDS ${it}
+)
+set(qmfiles ${qmfiles}
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Tue, Mar 18, 2014, at 5:37, Aleix Pol wrote: Maybe coming up with the list of modules now is not the most useful thing now. Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? +1 Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Handling of frameworks using Qt-based translations
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau agat...@kde.org wrote:
Hi,
I started working on how to handle Qt based translations, and make it as
simple as possible to work with for framework maintainers as well as
framework users.
I picked KBookmarks as my guinea pig and got to the point where
kbookmarkdialogtest shows a translated dialog.
Here is how it currently works. All of this is liberally inspired from
the way Trojita works:
# String extraction
I created a src/Messages.sh which contains the following:
lupdate -silent -recursive . -ts $podir/tmp.ts
lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
$podir/kbookmarks5.pot
rm $podir/tmp.ts
# String compilation
I modified the toplevel CMakeLists.txt, adding these lines:
if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
qm_setup(kbookmarks5 po)
endif()
I created a QmSupport.cmake file, which exposes a qm_setup() function.
This function does three things:
1. Create a qm target which turns all .po into .qm files.
2. Call install(FILES...) on the generated qm files, installing them in
share/${name}/locale, where ${name} is the firt argument of qm_setup().
3. Generate a ${name}_translation.h which contain two inline functions
to make it easy to load the translations.
Using the translation is then just a matter of including
${name}_translation.h and calling ${name}_installTranslator(). If more
control is needed, ${name}_installTranslator() also accepts an optional
argument: the language. For even finer control, the .h also contains a
${name}_createTranslator() function, which returns a QTranslator loaded
with strings for the right language.
# Questions
Does this approach sounds sane to you?
I think QmSupport.cmake should go to extra-cmake-modules. Any
objections?
Right now qm_setup() is very inflexible: it installs files and creates
the _translation.h file based on the name argument, meaning in my
example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
include/kbookmarks5_translation.h, which contains the functions
kbookmarks5_createTranslator and kbookmarks5_installTranslator.
I think we want to be able to customize the install dir of the
_translation.h file because some frameworks install header files in a
subdir, others do not.
Should we also be able to customize the install data dir for qm files,
as well as the prefix of the function names from _translation.h? I am
tempted to default to ${PROJECT_NAME} for the prefix of the function
names, its lowercase version for the install data dir and add an
optional PROJECT_NAME argument to qm_setup(). Opinions?
I am attaching the diff of the current state. I do not intend to commit
it as is since po files are not supposed to be in the framework
repository, but it should make it easy for you to try it if you are
interested.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Hi Aurélien,
Wouldn't it make sense that the library called the createTranslation
itself, instead of expecting the application to call it? I can easily see
applications forgetting it.
Maybe using Q_COREAPP_STARTUP_FUNCTION?
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: Handling of frameworks using Qt-based translations
On Tuesday 18 March 2014 14:20:53 Aleix Pol wrote:
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau agat...@kde.org wrote:
Hi,
I started working on how to handle Qt based translations, and make it as
simple as possible to work with for framework maintainers as well as
framework users.
I picked KBookmarks as my guinea pig and got to the point where
kbookmarkdialogtest shows a translated dialog.
Here is how it currently works. All of this is liberally inspired from
the way Trojita works:
# String extraction
I created a src/Messages.sh which contains the following:
lupdate -silent -recursive . -ts $podir/tmp.ts
lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
$podir/kbookmarks5.pot
rm $podir/tmp.ts
# String compilation
I modified the toplevel CMakeLists.txt, adding these lines:
if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
qm_setup(kbookmarks5 po)
endif()
I created a QmSupport.cmake file, which exposes a qm_setup() function.
This function does three things:
1. Create a qm target which turns all .po into .qm files.
2. Call install(FILES...) on the generated qm files, installing them in
share/${name}/locale, where ${name} is the firt argument of qm_setup().
3. Generate a ${name}_translation.h which contain two inline functions
to make it easy to load the translations.
Using the translation is then just a matter of including
${name}_translation.h and calling ${name}_installTranslator(). If more
control is needed, ${name}_installTranslator() also accepts an optional
argument: the language. For even finer control, the .h also contains a
${name}_createTranslator() function, which returns a QTranslator loaded
with strings for the right language.
# Questions
Does this approach sounds sane to you?
I think QmSupport.cmake should go to extra-cmake-modules. Any
objections?
Right now qm_setup() is very inflexible: it installs files and creates
the _translation.h file based on the name argument, meaning in my
example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
include/kbookmarks5_translation.h, which contains the functions
kbookmarks5_createTranslator and kbookmarks5_installTranslator.
I think we want to be able to customize the install dir of the
_translation.h file because some frameworks install header files in a
subdir, others do not.
Should we also be able to customize the install data dir for qm files,
as well as the prefix of the function names from _translation.h? I am
tempted to default to ${PROJECT_NAME} for the prefix of the function
names, its lowercase version for the install data dir and add an
optional PROJECT_NAME argument to qm_setup(). Opinions?
I am attaching the diff of the current state. I do not intend to commit
it as is since po files are not supposed to be in the framework
repository, but it should make it easy for you to try it if you are
interested.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Hi Aurélien,
Wouldn't it make sense that the library called the createTranslation
itself, instead of expecting the application to call it? I can easily see
applications forgetting it.
Being a developer who never got how the translation system works and considers
it as black magic: yes that would break if it has to be done by the
application.
Cheers
Martin
signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116873: Replace GPL proctitle code with BSD-licensed code from OpenSSH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116873/ --- Review request for KDE Frameworks. Repository: kinit Description --- Replace GPL proctitle code with BSD-licensed code from OpenSSH This also alters the calling sites so that we don't get kdeinit5 appearing multiple times in the process title. Diffs - src/kdeinit/proctitle.cpp a710e87dc12a40e9e679d2004980a86e77f39437 src/kdeinit/proctitle.h d0cadb289f93f15f2d9a885dc05911a49ab09877 src/config-kdeinit.h.cmake 2dd906019e44b0ba585817c87809d3ccff8bdce8 src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 ConfigureChecks.cmake c53e1defccaf0bcab33afde4342f2f9defb91335 Diff: https://git.reviewboard.kde.org/r/116873/diff/ Testing --- Tested on Linux only. I put a 20-second sleep in before the exec call, so that I could see the process title of the fork. Tested as-is, and with the prctl() call commented out. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Default emoticons theme
On Tue, Mar 18, 2014 at 3:13 PM, Alex Merry alex.me...@kde.org wrote: On 17/03/14 11:57, Alex Merry wrote: On 15/03/14 19:04, Aleix Pol wrote: I do agree that having an emoticons set together with kemoticons can be very helpful and simplify the usage of the module. Also, it doesn't really make sense to use kf5 or kde4. It's not something linked to the library version, so it can be a theme name. I like that plan. One problem: I suck at naming things. Anyone have any ideas? Possibly salient information: this was created by Everaldo Coelho in 2004 as the default icon theme for Kopete (named Default). It has that shiny look that was popular around then (similar to CrystalSVG). Note that kemoticons looks for themes in the generic $XDG_DATA_DIRS/emoticons directories, so I don't really want to call it Default. (As a side-note, this generic location is possibly a bit presumptuous without any xdg involvement, even if there is a draft spec [0]). I had an idea! Glass, since they look shiny. I tried searching for glass via GHNS in the emoticons kcm, and the only thing that came up was one called TheGlassy!. I'll go for this if no-one objects at the meeting this afternoon. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Works for me, I would say any name is fine. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Handling of frameworks using Qt-based translations
On Tue, Mar 18, 2014, at 6:20, Aleix Pol wrote:
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau [1]agat...@kde.org
wrote:
Hi,
I started working on how to handle Qt based translations, and make it
as
simple as possible to work with for framework maintainers as well as
framework users.
I picked KBookmarks as my guinea pig and got to the point where
kbookmarkdialogtest shows a translated dialog.
Here is how it currently works. All of this is liberally inspired from
the way Trojita works:
# String extraction
I created a src/Messages.sh which contains the following:
lupdate -silent -recursive . -ts $podir/tmp.ts
lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
$podir/kbookmarks5.pot
rm $podir/tmp.ts
# String compilation
I modified the toplevel CMakeLists.txt, adding these lines:
if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
qm_setup(kbookmarks5 po)
endif()
I created a QmSupport.cmake file, which exposes a qm_setup() function.
This function does three things:
1. Create a qm target which turns all .po into .qm files.
2. Call install(FILES...) on the generated qm files, installing them in
share/${name}/locale, where ${name} is the firt argument of qm_setup().
3. Generate a ${name}_translation.h which contain two inline
functions
to make it easy to load the translations.
Using the translation is then just a matter of including
${name}_translation.h and calling ${name}_installTranslator(). If more
control is needed, ${name}_installTranslator() also accepts an optional
argument: the language. For even finer control, the .h also contains a
${name}_createTranslator() function, which returns a QTranslator loaded
with strings for the right language.
# Questions
Does this approach sounds sane to you?
I think QmSupport.cmake should go to extra-cmake-modules. Any
objections?
Right now qm_setup() is very inflexible: it installs files and creates
the _translation.h file based on the name argument, meaning in my
example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
include/kbookmarks5_translation.h, which contains the functions
kbookmarks5_createTranslator and kbookmarks5_installTranslator.
I think we want to be able to customize the install dir of the
_translation.h file because some frameworks install header files in a
subdir, others do not.
Should we also be able to customize the install data dir for qm files,
as well as the prefix of the function names from _translation.h? I am
tempted to default to ${PROJECT_NAME} for the prefix of the function
names, its lowercase version for the install data dir and add an
optional PROJECT_NAME argument to qm_setup(). Opinions?
I am attaching the diff of the current state. I do not intend to commit
it as is since po files are not supposed to be in the framework
repository, but it should make it easy for you to try it if you are
interested.
Aurélien
___
Kde-frameworks-devel mailing list
[2]Kde-frameworks-devel@kde.org
[3]https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Hi Aurélien,
Wouldn't it make sense that the library called the createTranslation
itself, instead of expecting the application to call it? I can easily
see applications forgetting it.
Maybe using Q_COREAPP_STARTUP_FUNCTION?
That could work, but would remove the ability to change the language
later (Some Qt apps like to let the user use a different language than
the system one for some reason). Not sure we care about this. It
certainly sounds more foolproof. On the other hand, you already *must*
load translations yourself if you are using any Qt standard dialog,
otherwise it won't be translated either.
Aurélien
References
1. mailto:agat...@kde.org
2. mailto:Kde-frameworks-devel@kde.org
3. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
KF5 Update Meeting Minutes 2014-w12
Hello everyone, This is the minutes of the Week 12 KF5 meeting. As usual it has been held on #kde-devel at 4pm Paris time. Were present: afiestas, agateau, alexmerry, apol, dfaure, mck182, mgraesslin, notmart, PovAddict, Riddell, svuorela, tosky and myself. * afiestas reminds everybody to read the sprint emails he sent and update data; * alexmerry has been working on removing kde4 references in the code and it's going well; * he found a name for the default emoticons theme; * he also reimplemented the proctitle stuff in kinit for licensing reasons; * agateau started working on the l10n support in the frameworks; * he's in need of feedback for handling the tr() based frameworks; * he also did minor adjustments to kapidox; * apol is thinking about having libksysguard as a framework; * dfaure is working on updating lxr and moving it to a new server; * he's also working on KConfig API improvements and to regude the amount of file loading/parsing; * mck182 fixed a bug in QScreen/XCB so that availableGeometry() works properly; * notmart is looking into moving QML plugins into frameworks, email and reviews to come; * PovAddict figured out how to implement KUser::faceIcon on windows; * svuorela is trying to remove some hacks in ECM for windows support; * Riddell reports that 4.97.0 is all packaged for kubuntu; * tosky has finished the docbook 4.5 migration; * he also emailed kde-i18n-doc to organize kf5-based translations; * mgraesslin merged his outstanding kwindowsystem patches; * he also plans further cleanups; * ervin has been mostly reviewing; * he's also looking in how to deal with deprecated modules. If you got questions, feel free to ask. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116876: Add default emoticons theme to kemoticons
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116876/ --- Review request for KDE Frameworks. Repository: kemoticons Description --- Make the autotests work uninstalled This also makes them data-driven, separating out the different testcases in the output, and fixes the skipping behaviour (so QSKIP only skips one testcase and not all of them). Add a default theme This was originally the default theme from Kopete, and was called kde4 up until this point. To trace its history, start at: svn path=/trunk/KDE/kdebase/runtime/; revision=699615 which is also commit a9552cba75e67fb886921d1abc2cb2a09e6efbad of kde-runtime. I didn't copy the history from kde-runtime, because there was no history to copy - only the commit noted above actually made it out of svn. Diffs - themes/Glass/sleep.png PRE-CREATION themes/Glass/shade.png PRE-CREATION themes/Glass/rose.png PRE-CREATION themes/Glass/sad.png PRE-CREATION themes/Glass/present.png PRE-CREATION themes/Glass/phone.png PRE-CREATION themes/Glass/omg.png PRE-CREATION themes/Glass/note.png PRE-CREATION themes/Glass/oh.png PRE-CREATION themes/Glass/love.png PRE-CREATION CMakeLists.txt de080764f7d387871ebebf6bfa7541944b618036 autotests/CMakeLists.txt 98b8e43b2f5cbe08dc6b454e2736e809538a0251 autotests/kemoticontest.h ba31c0bd50b8bf6a75844fb9c41ffdedd6fc34d5 autotests/kemoticontest.cpp b7dc6f75fb722d63936fb666a51b969d37b84e31 src/core/kemoticons.cpp bc72e166586ef1271cac2291a9223c2472e1d8b8 tests/main.cpp 13f584a153fbd3612e8702d05368960d6e8e4e59 themes/CMakeLists.txt PRE-CREATION themes/Glass/angry.png PRE-CREATION themes/Glass/bat.png PRE-CREATION themes/Glass/beer.png PRE-CREATION themes/Glass/biggrin.png PRE-CREATION themes/Glass/cake.png PRE-CREATION themes/Glass/camera.png PRE-CREATION themes/Glass/cat.png PRE-CREATION themes/Glass/clock.png PRE-CREATION themes/Glass/cocktail.png PRE-CREATION themes/Glass/confused.png PRE-CREATION themes/Glass/cry.png PRE-CREATION themes/Glass/cup.png PRE-CREATION themes/Glass/dog.png PRE-CREATION themes/Glass/email.png PRE-CREATION themes/Glass/embarassed.png PRE-CREATION themes/Glass/emoticons.xml PRE-CREATION themes/Glass/film.png PRE-CREATION themes/Glass/foot_in_mouth.png PRE-CREATION themes/Glass/innocent.png PRE-CREATION themes/Glass/kiss.png PRE-CREATION themes/Glass/lightbulb.png PRE-CREATION themes/Glass/smile.png PRE-CREATION themes/Glass/star.png PRE-CREATION themes/Glass/teeth.png PRE-CREATION themes/Glass/thumbs_down.png PRE-CREATION themes/Glass/thumbs_up.png PRE-CREATION themes/Glass/tongue.png PRE-CREATION themes/Glass/undecided.png PRE-CREATION themes/Glass/unhappy.png PRE-CREATION themes/Glass/unlove.png PRE-CREATION themes/Glass/wilted_rose.png PRE-CREATION themes/Glass/wink.png PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116876/diff/ Testing --- Builds, installs, tests pass without skipping (both before and after installation). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Handling of frameworks using Qt-based translations
On Tue, Mar 18, 2014 at 4:12 PM, Aurélien Gâteau agat...@kde.org wrote:
On Tue, Mar 18, 2014, at 6:20, Aleix Pol wrote:
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau agat...@kde.org wrote:
Hi,
I started working on how to handle Qt based translations, and make it as
simple as possible to work with for framework maintainers as well as
framework users.
I picked KBookmarks as my guinea pig and got to the point where
kbookmarkdialogtest shows a translated dialog.
Here is how it currently works. All of this is liberally inspired from
the way Trojita works:
# String extraction
I created a src/Messages.sh which contains the following:
lupdate -silent -recursive . -ts $podir/tmp.ts
lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
$podir/kbookmarks5.pot
rm $podir/tmp.ts
# String compilation
I modified the toplevel CMakeLists.txt, adding these lines:
if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
qm_setup(kbookmarks5 po)
endif()
I created a QmSupport.cmake file, which exposes a qm_setup() function.
This function does three things:
1. Create a qm target which turns all .po into .qm files.
2. Call install(FILES...) on the generated qm files, installing them in
share/${name}/locale, where ${name} is the firt argument of qm_setup().
3. Generate a ${name}_translation.h which contain two inline functions
to make it easy to load the translations.
Using the translation is then just a matter of including
${name}_translation.h and calling ${name}_installTranslator(). If more
control is needed, ${name}_installTranslator() also accepts an optional
argument: the language. For even finer control, the .h also contains a
${name}_createTranslator() function, which returns a QTranslator loaded
with strings for the right language.
# Questions
Does this approach sounds sane to you?
I think QmSupport.cmake should go to extra-cmake-modules. Any
objections?
Right now qm_setup() is very inflexible: it installs files and creates
the _translation.h file based on the name argument, meaning in my
example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
include/kbookmarks5_translation.h, which contains the functions
kbookmarks5_createTranslator and kbookmarks5_installTranslator.
I think we want to be able to customize the install dir of the
_translation.h file because some frameworks install header files in a
subdir, others do not.
Should we also be able to customize the install data dir for qm files,
as well as the prefix of the function names from _translation.h? I am
tempted to default to ${PROJECT_NAME} for the prefix of the function
names, its lowercase version for the install data dir and add an
optional PROJECT_NAME argument to qm_setup(). Opinions?
I am attaching the diff of the current state. I do not intend to commit
it as is since po files are not supposed to be in the framework
repository, but it should make it easy for you to try it if you are
interested.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Hi Aurélien,
Wouldn't it make sense that the library called the createTranslation
itself, instead of expecting the application to call it? I can easily see
applications forgetting it.
Maybe using Q_COREAPP_STARTUP_FUNCTION?
That could work, but would remove the ability to change the language later
(Some Qt apps like to let the user use a different language than the system
one for some reason). Not sure we care about this. It certainly sounds more
foolproof. On the other hand, you already *must* load translations yourself
if you are using any Qt standard dialog, otherwise it won't be translated
either.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Well, for KI18n changing the language at run-time is not possible.
Maybe we can set it up magically for general use and still install the
createTranslation thing in case the application likes to do it specifically?
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Handling of frameworks using Qt-based translations
On Tue, Mar 18, 2014, at 9:07, Aleix Pol wrote:
On Tue, Mar 18, 2014 at 4:12 PM, Aurélien Gâteau [1]agat...@kde.org
wrote:
On Tue, Mar 18, 2014, at 6:20, Aleix Pol wrote:
On Tue, Mar 18, 2014 at 2:05 PM, Aurélien Gâteau [2]agat...@kde.org
wrote:
Hi,
I started working on how to handle Qt based translations, and make it
as
simple as possible to work with for framework maintainers as well as
framework users.
I picked KBookmarks as my guinea pig and got to the point where
kbookmarkdialogtest shows a translated dialog.
Here is how it currently works. All of this is liberally inspired from
the way Trojita works:
# String extraction
I created a src/Messages.sh which contains the following:
lupdate -silent -recursive . -ts $podir/tmp.ts
lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
$podir/kbookmarks5.pot
rm $podir/tmp.ts
# String compilation
I modified the toplevel CMakeLists.txt, adding these lines:
if (EXISTS ${CMAKE_CURRENT_SOURCE_DIR}/po)
include(${CMAKE_CURRENT_SOURCE_DIR}/QmSupport.cmake)
qm_setup(kbookmarks5 po)
endif()
I created a QmSupport.cmake file, which exposes a qm_setup() function.
This function does three things:
1. Create a qm target which turns all .po into .qm files.
2. Call install(FILES...) on the generated qm files, installing them in
share/${name}/locale, where ${name} is the firt argument of qm_setup().
3. Generate a ${name}_translation.h which contain two inline
functions
to make it easy to load the translations.
Using the translation is then just a matter of including
${name}_translation.h and calling ${name}_installTranslator(). If more
control is needed, ${name}_installTranslator() also accepts an optional
argument: the language. For even finer control, the .h also contains a
${name}_createTranslator() function, which returns a QTranslator loaded
with strings for the right language.
# Questions
Does this approach sounds sane to you?
I think QmSupport.cmake should go to extra-cmake-modules. Any
objections?
Right now qm_setup() is very inflexible: it installs files and creates
the _translation.h file based on the name argument, meaning in my
example it creates share/kbookmarks5/locale/kbookmarks5_*.qm and
include/kbookmarks5_translation.h, which contains the functions
kbookmarks5_createTranslator and kbookmarks5_installTranslator.
I think we want to be able to customize the install dir of the
_translation.h file because some frameworks install header files in a
subdir, others do not.
Should we also be able to customize the install data dir for qm files,
as well as the prefix of the function names from _translation.h? I am
tempted to default to ${PROJECT_NAME} for the prefix of the function
names, its lowercase version for the install data dir and add an
optional PROJECT_NAME argument to qm_setup(). Opinions?
I am attaching the diff of the current state. I do not intend to commit
it as is since po files are not supposed to be in the framework
repository, but it should make it easy for you to try it if you are
interested.
Aurélien
___
Kde-frameworks-devel mailing list
[3]Kde-frameworks-devel@kde.org
[4]https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Hi Aurélien,
Wouldn't it make sense that the library called the createTranslation
itself, instead of expecting the application to call it? I can easily
see applications forgetting it.
Maybe using Q_COREAPP_STARTUP_FUNCTION?
That could work, but would remove the ability to change the language
later (Some Qt apps like to let the user use a different language than
the system one for some reason). Not sure we care about this. It
certainly sounds more foolproof. On the other hand, you already *must*
load translations yourself if you are using any Qt standard dialog,
otherwise it won't be translated either.
Aurélien
___
Kde-frameworks-devel mailing list
[5]Kde-frameworks-devel@kde.org
[6]https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Well, for KI18n changing the language at run-time is not possible.
Maybe we can set it up magically for general use and still install the
createTranslation thing in case the application likes to do it
specifically?
That is right. Let's keep it simple then and not provide a feature
which is not supported by KI18n-powered frameworks.
This means we need to add a generated .cpp file in the framework
target(s). Going to look into it.
Aurélien
References
1. mailto:agat...@kde.org
2. mailto:agat...@kde.org
3. mailto:Kde-frameworks-devel@kde.org
4. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
5. mailto:Kde-frameworks-devel@kde.org
6. https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116786: Make error handling more consistent and fail earlier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116786/#review53343 --- This review has been submitted with commit b7b5dcb4b21c7d334c121800d6d24f928d51293d by Aurélien Gâteau to branch master. - Commit Hook On March 14, 2014, 11:54 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116786/ --- (Updated March 14, 2014, 11:54 a.m.) Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This should makes it easier to interpret future failures, for example by not running xmllint if catalogs are missing. Diffs - src/meinproc.cpp 22150ab Diff: https://git.reviewboard.kde.org/r/116786/diff/ Testing --- Clean-rebuilt all frameworks which depends on kdoctools, plus kde-runtime, kde-workspace, konsole, kate. 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 116786: Make error handling more consistent and fail earlier
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116786/ --- (Updated March 18, 2014, 4:56 p.m.) Status -- This change has been marked as submitted. Review request for Documentation, KDE Frameworks and Luigi Toscano. Repository: kdoctools Description --- This should makes it easier to interpret future failures, for example by not running xmllint if catalogs are missing. Diffs - src/meinproc.cpp 22150ab Diff: https://git.reviewboard.kde.org/r/116786/diff/ Testing --- Clean-rebuilt all frameworks which depends on kdoctools, plus kde-runtime, kde-workspace, konsole, kate. 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 116866: Use std::isnan on compilers that support it (fixes MinGW on Windows)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/ --- (Updated March 18, 2014, 10:25 a.m.) Review request for KDE Frameworks. Repository: kguiaddons Description --- Use std::isnan from cmath instead of isnan from math.h, as MinGW-32 on Windows does not include the latter. This keeps the _isnan hack for MSVC, since that compiler doesn't include either standard version :(. Diffs (updated) - src/CMakeLists.txt 624d2e109be5c26af9781101a005b4a163361a92 src/ConfigureChecks.cmake PRE-CREATION src/colors/kcolorutils.cpp 7df25b3d7acbb65b29513d2139d7b83de53ee4c2 src/kguiaddons_config.h.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116866/diff/ Testing --- Compiled with MSVC10 (32-bit), MinGW 4.8 (32-bit, Windows native), and GCC 4.8 (Arch x86_64). Thanks, Michael Hansen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116866: Use std::isnan on compilers that support it (fixes MinGW on Windows)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/#review53347 --- Ship it! Ship It! - Alex Merry On March 18, 2014, 5:25 p.m., Michael Hansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/ --- (Updated March 18, 2014, 5:25 p.m.) Review request for KDE Frameworks. Repository: kguiaddons Description --- Use std::isnan from cmath instead of isnan from math.h, as MinGW-32 on Windows does not include the latter. This keeps the _isnan hack for MSVC, since that compiler doesn't include either standard version :(. Diffs - src/CMakeLists.txt 624d2e109be5c26af9781101a005b4a163361a92 src/ConfigureChecks.cmake PRE-CREATION src/colors/kcolorutils.cpp 7df25b3d7acbb65b29513d2139d7b83de53ee4c2 src/kguiaddons_config.h.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116866/diff/ Testing --- Compiled with MSVC10 (32-bit), MinGW 4.8 (32-bit, Windows native), and GCC 4.8 (Arch x86_64). Thanks, Michael Hansen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116866: Use std::isnan on compilers that support it (fixes MinGW on Windows)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/#review53348 --- src/kguiaddons_config.h.cmake https://git.reviewboard.kde.org/r/116866/#comment37532 Do these copyright lines really apply to this new file? I think you should include just your own name (since you created this config file). - Nicolás Alvarez On March 18, 2014, 2:25 p.m., Michael Hansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/ --- (Updated March 18, 2014, 2:25 p.m.) Review request for KDE Frameworks. Repository: kguiaddons Description --- Use std::isnan from cmath instead of isnan from math.h, as MinGW-32 on Windows does not include the latter. This keeps the _isnan hack for MSVC, since that compiler doesn't include either standard version :(. Diffs - src/CMakeLists.txt 624d2e109be5c26af9781101a005b4a163361a92 src/ConfigureChecks.cmake PRE-CREATION src/colors/kcolorutils.cpp 7df25b3d7acbb65b29513d2139d7b83de53ee4c2 src/kguiaddons_config.h.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116866/diff/ Testing --- Compiled with MSVC10 (32-bit), MinGW 4.8 (32-bit, Windows native), and GCC 4.8 (Arch x86_64). Thanks, Michael Hansen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116866: Use std::isnan on compilers that support it (fixes MinGW on Windows)
On March 18, 2014, 10:47 a.m., Nicolás Alvarez wrote: src/kguiaddons_config.h.cmake, line 2 https://git.reviewboard.kde.org/r/116866/diff/3/?file=255187#file255187line2 Do these copyright lines really apply to this new file? I think you should include just your own name (since you created this config file). Oops, I just copied that header from another .h file... - Michael --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/#review53348 --- On March 18, 2014, 10:25 a.m., Michael Hansen wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/ --- (Updated March 18, 2014, 10:25 a.m.) Review request for KDE Frameworks. Repository: kguiaddons Description --- Use std::isnan from cmath instead of isnan from math.h, as MinGW-32 on Windows does not include the latter. This keeps the _isnan hack for MSVC, since that compiler doesn't include either standard version :(. Diffs - src/CMakeLists.txt 624d2e109be5c26af9781101a005b4a163361a92 src/ConfigureChecks.cmake PRE-CREATION src/colors/kcolorutils.cpp 7df25b3d7acbb65b29513d2139d7b83de53ee4c2 src/kguiaddons_config.h.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116866/diff/ Testing --- Compiled with MSVC10 (32-bit), MinGW 4.8 (32-bit, Windows native), and GCC 4.8 (Arch x86_64). Thanks, Michael Hansen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116866: Use std::isnan on compilers that support it (fixes MinGW on Windows)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116866/ --- (Updated March 18, 2014, 10:51 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kguiaddons Description --- Use std::isnan from cmath instead of isnan from math.h, as MinGW-32 on Windows does not include the latter. This keeps the _isnan hack for MSVC, since that compiler doesn't include either standard version :(. Diffs - src/CMakeLists.txt 624d2e109be5c26af9781101a005b4a163361a92 src/ConfigureChecks.cmake PRE-CREATION src/colors/kcolorutils.cpp 7df25b3d7acbb65b29513d2139d7b83de53ee4c2 src/kguiaddons_config.h.cmake PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116866/diff/ Testing --- Compiled with MSVC10 (32-bit), MinGW 4.8 (32-bit, Windows native), and GCC 4.8 (Arch x86_64). Thanks, Michael Hansen ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
Hello, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Monday 17 March 2014 20:14:24 John Layt wrote: On 17 March 2014 18:15, Kevin Ottens er...@kde.org wrote: I think that list makes sense. Is there anyone who couldn't sleep at night if those were in KDE Porting Aids? +1 to this strategy, although some bikeshedding on the portingaids name might be welcome :-) Hmmm, nope, I'm drawing a blank... I like the limit on kde4support, we only have to look to Qt3Support to know that if the aids are left in place people will avoid porting away from them until they absolutely have to. I'm not sure we need to call it a product though, perhaps just saying a special category of Frameworks providing transitional support for a limited period of time for apps migrating from kdelibs4 to KF5 would be enough. Hey, how about KDE Transitional Frameworks? :-) Better name indeed... I would be concerned about the proximity with KDE Frameworks name wise though. That being said, having a crappy name for the product containing the deprecated modules is not necessarily a bad thing, we want to avoid marketing it widely anyway (at least outside of KDE). :-) Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116879: Fix build of kuser_win.cpp with MSVC2010
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116879/ --- Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix build of kuser_win.cpp with MSVC2010: - Add missing cast. - Add return types to lambdas. In C++11, the return type is only deduced if the lambda consists only of a single return statement. This will change in C++14 (see C++ DR975), and MSVC2013 implements the new behavior, but MSVC2010 doesn't. Diffs - src/lib/util/kuser_win.cpp e7fb5b6 Diff: https://git.reviewboard.kde.org/r/116879/diff/ Testing --- Compiles on MSVC2010 and 2013. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
Hello, On Tuesday 18 March 2014 13:37:01 Aleix Pol wrote: On Tue, Mar 18, 2014 at 4:36 AM, Markus Slopianka kamika...@gmx.de wrote: On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). Um, isn't KDEWebKit missing? Digia already deprecated QtWebKit in favor of Chromium's Blink. Unless anybody is interested in maintaining QtWebKit the KDE bindings should be deprecated as well. Don't you think? Might make sense... Maybe coming up with the list of modules now is not the most useful thing now. ... but I agree with that. Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? Yes, feel free to add it. And then anything labeled deprecated will get moved out of KDE Frameworks and into KDE Porting Aids before release. A final list could be polished during the KF5 sprint [1]. Agreed. It's also probably when we'll act on the moves. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
QML Bindings for KDE frameworks, take 2
Hi all, as I mentioned in the last couple of tuesday meetings, in Plasma we have several QML plugins that don't depend from Plasma at all, but are bound just to either Qt or just one framework (should ideally become the way to use the framework from QML) what we currently have is: * dirmodel: is a binding to kdirmodel - KIO? (i would probably not release it yet but waiting to have folderview done so needed features are more clear) * draganddrop Qt only (QML2 has a partial replacement but with less features) * kquickcontrols: depends from several frameworks (in particular globalAccel and dependencies) to provide a shortcut editor widget - * QtExtracomponents: qt only except kiconthemes (i would go into making it less pretty and remove the kiconthemes dependency) the fact that except dirmodel they don't really have one framework they could go in.. At the moment I moved them in a scratch repository http://quickgit.kde.org/?p=scratch%2Fmart%2Fkquickcontrols.git right now most frameworks dependencies are optional, imports that need some dependency that is not found are not build, so they should still be usable by who doesn't want to depend from some of those frameworks. This seems still a meh solution, but i can't really think about better one. Opinions? comments? how i proceed? Cheers, Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Monday 17 March 2014 18:15:09 Kevin Ottens wrote: Now, the last point... What else do we want to move from KDE Frameworks to KDE Porting Aids? Aleix and Aaron proposed the following content for KDE Porting Aids: * kde4support (obvious); * khtml (planned for a long time); * kjs (because of khtml I gather); * kjsembed (ditto); * krunner (because of upcoming sprinter, and only one user anyway); * kmediaplayer (unused AFAIK). Um, isn't KDEWebKit missing? Digia already deprecated QtWebKit in favor of Chromium's Blink. Unless anybody is interested in maintaining QtWebKit the KDE bindings should be deprecated as well. Don't you think? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kde-promo] Releasing Deprecated modules and Tier 4 Definition
On Tuesday 18 March 2014 13:37:01 Aleix Pol wrote: Can we maybe agree that we want an extra value in the framework.yaml file indicating the maturity of the project? It's not about maturity, it's about security. QtWebKit is no longer maintained by Digia and I am not aware that anybody stepped up to maintain it. Therefore web security vulnerabilities stay unfixed. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QML Bindings for KDE frameworks, take 2
On Tuesday 18 March 2014 19:37:59 Marco Martin wrote: what we currently have is: * dirmodel: is a binding to kdirmodel - KIO? (i would probably not release it yet but waiting to have folderview done so needed features are more clear) Would make sense in a KIO import indeed. * draganddrop Qt only (QML2 has a partial replacement but with less features) Why the dependency on QtWidgets in there? Just for QApplication::startDragDistance()? It could be replaced with QGuiApplication::styleHints()-startDragDistance(). It would then have the same dependencies than QtExtraComponents (delta KIconThemes) and could be merged there. * kquickcontrols: depends from several frameworks (in particular globalAccel and dependencies) to provide a shortcut editor widget - Yeah... no natural place for that one... KDeclarative as last resort? There's already configuration related things in there. Bears the risk of making it a dumping ground though. * QtExtracomponents: qt only except kiconthemes (i would go into making it less pretty and remove the kiconthemes dependency) Yes, please make it independent of KIconThemes, and then could be renamed into KQuickControlsAddons? Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: how to write kded module in framework 5
On Tue, Mar 18, 2014 at 5:20 AM, Alex Merry alex.me...@kde.org wrote: On 17/03/14 19:35, Shivam Makkar wrote: also I want to know how can i start kded5 when I run command kded5 or kdeinit5 i get kded5(16341)/(default) QXcbSessionManager::QXcbSessionManager: Qt: Session management error: networkIdsList argument is NULL Hmm... you might want to try eval `dbus-launch` before running kded5 or kdeinit5, so that it doesn't interfere with your current session. I am using that command ! also is there any other module I need to build to see the changes I've made in keyboard module's daemon ? (keyboard daemon.cpp) -- Regards Shivam Makkar amourphious.appspot.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QML Bindings for KDE frameworks, take 2
On Tuesday 18 March 2014, Kevin Ottens wrote: It could be replaced with QGuiApplication::styleHints()-startDragDistance(). It would then have the same dependencies than QtExtraComponents (delta KIconThemes) and could be merged there. Removed qwidgets dependency. The problem i see in merging with QtExtraComponents is that besides will require porting in all the user (doable) is that it's mit licensed (it was a contribution by a company that requested that back then. mit/bsd in an import is fine, but just not mixed in the same so) * kquickcontrols: depends from several frameworks (in particular globalAccel and dependencies) to provide a shortcut editor widget - Yeah... no natural place for that one... KDeclarative as last resort? There's already configuration related things in there. Bears the risk of making it a dumping ground though. yeah, kdeclarative repo makes sense * QtExtracomponents: qt only except kiconthemes (i would go into making it less pretty and remove the kiconthemes dependency) Yes, please make it independent of KIconThemes, and then could be renamed into KQuickControlsAddons? removed kiconthemes dependency ;) About rename, there is a lot of stuff using it, but conversion should be portable with a script. (depends from less stuff than KDeclarative or KQuickControls tough, KQuickControlsAddons suggests it depends from more?) -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Frameworksintegration of QFileDialog::getExistingDirectory (was: add test for QFileDialog::getExistingDirectory / bug?)
Hi, getting an existing directory is still broken with current frameworks integration. A call of: QString dir = QFileDialog::getExistingDirectory(); results in this image: http://wstaw.org/m/2014/03/18/plasma-desktopdF1903.png Whereas what you actually want is this: http://wstaw.org/m/2014/03/18/plasma-desktopdI1903.png (This was obtained with the KF5 version of: kdialog --getexistingdirectory ~ Would be cool, if someone with more knowledge in frameworks integration could have a look here. Greetings, Dominik On Sunday 26 January 2014 17:15:08 Gregor Mi wrote: Hi, with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for QFileDialog::getExistingDirectory. When I execute ./qfiledialogtest --staticFunction getExistingDirectory then a dialog opens that lets the user select files but not directories. This seems to be a bug. Greetings Gregor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116881: Fix KUser::groups() and KUser::groupNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/ --- Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix KUser::groups() and KUser::groupNames() on UNIX If available we use getgrouplist() which returns all group IDs. Otherwise we fall back to using getgrent() and checking whether gr_mem contains the user. For some reason gr_mem doesn't usally contain the users primary gid, so we add the corresponding struct group for that gid as well. Diffs - src/lib/CMakeLists.txt 73f28a8a3acda8449a3aee3b025e2b165722b998 src/lib/util/config-getgrouplist.h.cmake PRE-CREATION src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116881/diff/ Testing --- Returns more groups now, should fix KUserTest::testKUser() on build.kde.org File Attachments Group list before https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/37d6d8ca-f33a-4345-873c-2e4be0daba00__grouplist_getgrent_old.txt New group list (with getgrouplist()) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/2cdf3e77-cd1e-4bfc-b49b-646947bf79c1__grouplist_getgrouplist.txt New Group list (with getgrent()) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/ecef5bf6-b8bd-4675-a6e2-838f23615037__grouplist_getgrent_new.txt old user-groups result (getgrent) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/86c5e986-8098-4c50-809c-bc3e7851447a__grouplist_getgrent_old.txt new user-groups result (getgrouplist) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/59f4ecda-5c1d-4bdc-a8ec-850de761e3a3__grouplist_getgrouplist.txt new user-groups result (getgrent + current gid) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/39d0172d-f6c8-400e-8af0-0c4aace8f7a1__grouplist_getgrent_new.txt 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 116881: Fix KUser::groups() and KUser::groupNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/ --- (Updated March 18, 2014, 9:14 p.m.) Review request for KDE Frameworks. Changes --- removed duplicate files (reviewboard showed they weren't there yet) Repository: kcoreaddons Description --- Fix KUser::groups() and KUser::groupNames() on UNIX If available we use getgrouplist() which returns all group IDs. Otherwise we fall back to using getgrent() and checking whether gr_mem contains the user. For some reason gr_mem doesn't usally contain the users primary gid, so we add the corresponding struct group for that gid as well. Diffs - src/lib/CMakeLists.txt 73f28a8a3acda8449a3aee3b025e2b165722b998 src/lib/util/config-getgrouplist.h.cmake PRE-CREATION src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116881/diff/ Testing --- Returns more groups now, should fix KUserTest::testKUser() on build.kde.org File Attachments (updated) old user-groups result (getgrent) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/86c5e986-8098-4c50-809c-bc3e7851447a__grouplist_getgrent_old.txt new user-groups result (getgrouplist) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/59f4ecda-5c1d-4bdc-a8ec-850de761e3a3__grouplist_getgrouplist.txt new user-groups result (getgrent + current gid) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/39d0172d-f6c8-400e-8af0-0c4aace8f7a1__grouplist_getgrent_new.txt Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116883: Fix KUserGroup::users() and KUserGroup::userNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/ --- Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix KUserGroup::users() and KUserGroup::userNames() on UNIX The gr_mem member of struct group does not contain the names of users where the primary group is equal to that group. In order to fix this we have to iterate over all users and check whether the primary gid matches the requested group. Unlike getgrouplist() there does not seem to be a function that performs this task for us. Diffs - src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116883/diff/ Testing --- Listed groups seem to be correct now. Should fix Jenkins together with https://git.reviewboard.kde.org/r/116881/ 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 116883: Fix KUserGroup::users() and KUserGroup::userNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/ --- (Updated March 18, 2014, 10:20 p.m.) Review request for KDE Frameworks. Changes --- added comparison before/after Repository: kcoreaddons Description --- Fix KUserGroup::users() and KUserGroup::userNames() on UNIX The gr_mem member of struct group does not contain the names of users where the primary group is equal to that group. In order to fix this we have to iterate over all users and check whether the primary gid matches the requested group. Unlike getgrouplist() there does not seem to be a function that performs this task for us. Diffs - src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116883/diff/ Testing --- Listed groups seem to be correct now. Should fix Jenkins together with https://git.reviewboard.kde.org/r/116881/ File Attachments (updated) Before https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/871c8bc5-4631-4759-8103-eb7ac817d698__groupmembers_before.txt After https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/4295e719-acb8-495f-907b-5a93d2d8b64f__groupmembers_after.txt 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 116879: Fix build of kuser_win.cpp with MSVC2010
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116879/#review53369 --- Ship it! Ship It! - Alexander Richardson On March 18, 2014, 7:28 p.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116879/ --- (Updated March 18, 2014, 7:28 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix build of kuser_win.cpp with MSVC2010: - Add missing cast. - Add return types to lambdas. In C++11, the return type is only deduced if the lambda consists only of a single return statement. This will change in C++14 (see C++ DR975), and MSVC2013 implements the new behavior, but MSVC2010 doesn't. Diffs - src/lib/util/kuser_win.cpp e7fb5b6 Diff: https://git.reviewboard.kde.org/r/116879/diff/ Testing --- Compiles on MSVC2010 and 2013. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116848: Add KWindowSystem::windowChanged(WId, NET::Properties, NET::Properties2) signal
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116848/#review53370 --- Prefixing the signal with QT_MOC_COMPAT should do the trick, at least that's what I found here: https://projects.kde.org/projects/kde/kdelibs/repository/revisions/abf90b0ca648c5f7f5c3d9040006e08817fc618d - Alexander Richardson On March 17, 2014, 10:46 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116848/ --- (Updated March 17, 2014, 10:46 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Add KWindowSystem::windowChanged(WId, NET::Properties, NET::Properties2) signal This signal replaces the existing signal carrying either just the NET::Properties as an uint or both as an const unsigned long*. Accordingly the previous signal gets deprecated, but is still emitted. Question: what's the correct way of deprecating signals, so that one gets a compile warning? Diffs - src/kwindowsystem.h e10f7c1cdd7b8c1fb1c6472c1f64a2ac71965534 src/kwindowsystem_x11.cpp 8a411008717b27ec8439f6ffebe0113fdad2fd45 Diff: https://git.reviewboard.kde.org/r/116848/diff/ Testing --- Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kde4support = kdelibs4support[Was: Re: Releasing Deprecated modules and Tier 4 Definition]
On Wed, Mar 19, 2014 at 7:15 AM, Kevin Ottens er...@kde.org wrote: Hello, Hi, On Monday 17 March 2014 22:53:25 Mario Fux KDE ML wrote: Am Montag, 17. März 2014, 18.15:09 schrieb Kevin Ottens: Porting Aids: * kde4support (obvious); Just that it doesn't get forgotten I'd like to second Aarons (or who it was) proposal to rename kde4support to kdelibs4support at this occasion if it's an easy rename! This might be the perfect opportunity. Makes it easier for us promo people to tell that there is no KDE4 as well. I personally don't mind. I leave the call to Ben though, as it'd mean yet another rename and they're painful on the sysadmin side. If we can, i'd like to batch all the renames together, it is less disruptive to do it all at once. Regards. Thanks, Ben -- 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
Re: Review Request 116747: Clean up KCompletionBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116747/#review53374 --- This review has been submitted with commit 6df2b486496ed500f5fbc02c4f3a58a0eb4f4b3f by David Gil to branch master. - Commit Hook On March 14, 2014, 8:46 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116747/ --- (Updated March 14, 2014, 8:46 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Clean up KCompletionBox -canceled() - cancelled (private method) -Deprecate sizeAndPosition() -- resizeAndReposition() -Remove old comments and commented-out code -Move some slots to be normal methods, since they don't seem to be able to work as slots. Diffs - src/kcompletionbox.h 09b7527 src/kcompletionbox.cpp 92e87b3 Diff: https://git.reviewboard.kde.org/r/116747/diff/ Testing --- It builds and 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 116747: Clean up KCompletionBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116747/ --- (Updated March 18, 2014, 10:25 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcompletion Description --- Clean up KCompletionBox -canceled() - cancelled (private method) -Deprecate sizeAndPosition() -- resizeAndReposition() -Remove old comments and commented-out code -Move some slots to be normal methods, since they don't seem to be able to work as slots. Diffs - src/kcompletionbox.h 09b7527 src/kcompletionbox.cpp 92e87b3 Diff: https://git.reviewboard.kde.org/r/116747/diff/ Testing --- It builds and 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 116792: Fix deprecation warning in KComboBox and fix all KDE_NO_DEPRECATED
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116792/ --- (Updated March 18, 2014, 10:28 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcompletion Description --- Fix deprecation warning in KComboBox and fix all KDE_NO_DEPRECATED There are other warnings related to the deprecated KComboBox::setUrlDropsEnabled, which calls KLineEdit::setUrlDropsEnabled (also deprecated). I tried to solve it by copying the KLineEdit::setUrlDropsEnabled contents into KComboBox::setUrlDropsEnabled, but it contains private variables which it cannot see. Any hint?? Diffs - autotests/klineedit_unittest.cpp b84e126 src/kcombobox.h 32dc3e9 src/kcombobox.cpp 7195b3e src/kcompletion.h 387a05e src/klineedit.h c7c46b5 src/klineedit.cpp ae15093 Diff: https://git.reviewboard.kde.org/r/116792/diff/ Testing --- It builds and 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 116792: Fix deprecation warning in KComboBox and fix all KDE_NO_DEPRECATED
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116792/#review53375 --- This review has been submitted with commit 6a37beb407d755d619ece5abafdef770db3b4b71 by David Gil to branch master. - Commit Hook On March 13, 2014, 10:58 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116792/ --- (Updated March 13, 2014, 10:58 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Fix deprecation warning in KComboBox and fix all KDE_NO_DEPRECATED There are other warnings related to the deprecated KComboBox::setUrlDropsEnabled, which calls KLineEdit::setUrlDropsEnabled (also deprecated). I tried to solve it by copying the KLineEdit::setUrlDropsEnabled contents into KComboBox::setUrlDropsEnabled, but it contains private variables which it cannot see. Any hint?? Diffs - autotests/klineedit_unittest.cpp b84e126 src/kcombobox.h 32dc3e9 src/kcombobox.cpp 7195b3e src/kcompletion.h 387a05e src/klineedit.h c7c46b5 src/klineedit.cpp ae15093 Diff: https://git.reviewboard.kde.org/r/116792/diff/ Testing --- It builds and 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 116684: Improve API in KCompletionBase
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116684/#review53376
---
This review has been submitted with commit
2c9bcacc830702b03437311883a005e46a221562 by David Gil to branch master.
- Commit Hook
On March 12, 2014, 11:06 p.m., David Gil Oliva wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116684/
---
(Updated March 12, 2014, 11:06 p.m.)
Review request for KDE Frameworks.
Repository: kcompletion
Description
---
Improve API in KCompletionBase
getKeyBindings - keyBindingMap
getKeyBinding - keyBinding
NOTICE: The following part is commented out because it gives me errors and I
need some help to find out what actually happens:
/**
* @deprecated since 5.0, use keyBindingMap instead
*/
#ifndef KDE_NO_DEPRECATED
KCOMPLETION_DEPRECATED KeyBindingMap getKeyBindings() const
{
return keyBindingMap();
}
#endif
Error:
In file included from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.cpp:21:0:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:
In member function ‘KCompletionBase::KeyBindingMap
KCompletionBase::getKeyBindings() const’:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:336:5:
error: return type ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’ is incomplete
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:337:30:
error: invalid use of incomplete type ‘KCompletionBase::KeyBindingMap {aka
class QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
In file included from
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qvarlengtharray.h:45:0,
from
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qmetatype.h:48,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qobject.h:56,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/QObject:1,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletion.h:25,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:23,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.cpp:21:
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qcontainerfwd.h:54:37: error:
declaration of ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
In file included from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.h:27:0,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.cpp:23:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:
In member function ‘KCompletionBase::KeyBindingMap
KCompletionBase::getKeyBindings() const’:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:336:5:
error: return type ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’ is incomplete
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:337:30:
error: invalid use of incomplete type ‘KCompletionBase::KeyBindingMap {aka
class QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
In file included from
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qvarlengtharray.h:45:0,
from
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qmetatype.h:48,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qobject.h:56,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/QObject:1,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletion.h:25,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.h:25,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.cpp:23:
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qcontainerfwd.h:54:37: error:
declaration of ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
make[2]: *** [src/CMakeFiles/KF5Completion.dir/kcompletionbase.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
Diffs
-
src/kcompletionbase.h 1dedd2d
src/kcompletionbase.cpp 1e251d1
src/klineedit.cpp ae15093
Diff: https://git.reviewboard.kde.org/r/116684/diff/
Testing
---
It compiles and (auto)tests pass without the conflicting part (to be
uncommented).
Thanks,
David Gil Oliva
Re: Review Request 116684: Improve API in KCompletionBase
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116684/
---
(Updated March 18, 2014, 10:32 p.m.)
Status
--
This change has been marked as submitted.
Review request for KDE Frameworks.
Repository: kcompletion
Description
---
Improve API in KCompletionBase
getKeyBindings - keyBindingMap
getKeyBinding - keyBinding
NOTICE: The following part is commented out because it gives me errors and I
need some help to find out what actually happens:
/**
* @deprecated since 5.0, use keyBindingMap instead
*/
#ifndef KDE_NO_DEPRECATED
KCOMPLETION_DEPRECATED KeyBindingMap getKeyBindings() const
{
return keyBindingMap();
}
#endif
Error:
In file included from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.cpp:21:0:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:
In member function ‘KCompletionBase::KeyBindingMap
KCompletionBase::getKeyBindings() const’:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:336:5:
error: return type ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’ is incomplete
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:337:30:
error: invalid use of incomplete type ‘KCompletionBase::KeyBindingMap {aka
class QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
In file included from
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qvarlengtharray.h:45:0,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qmetatype.h:48,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qobject.h:56,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/QObject:1,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletion.h:25,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:23,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.cpp:21:
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qcontainerfwd.h:54:37: error:
declaration of ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
In file included from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.h:27:0,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.cpp:23:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:
In member function ‘KCompletionBase::KeyBindingMap
KCompletionBase::getKeyBindings() const’:
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:336:5:
error: return type ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’ is incomplete
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletionbase.h:337:30:
error: invalid use of incomplete type ‘KCompletionBase::KeyBindingMap {aka
class QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
In file included from
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qvarlengtharray.h:45:0,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qmetatype.h:48,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qobject.h:56,
from /opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/QObject:1,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcompletion.h:25,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.h:25,
from
/home/david/devel/kf5-development/frameworks/kcompletion/src/kcombobox.cpp:23:
/opt/Qt5.2.0-KF5/5.2.0/gcc/include/QtCore/qcontainerfwd.h:54:37: error:
declaration of ‘KCompletionBase::KeyBindingMap {aka class
QMapKCompletionBase::KeyBindingType, QListQKeySequence }’
make[2]: *** [src/CMakeFiles/KF5Completion.dir/kcompletionbase.cpp.o] Error 1
make[2]: *** Waiting for unfinished jobs
Diffs
-
src/kcompletionbase.h 1dedd2d
src/kcompletionbase.cpp 1e251d1
src/klineedit.cpp ae15093
Diff: https://git.reviewboard.kde.org/r/116684/diff/
Testing
---
It compiles and (auto)tests pass without the conflicting part (to be
uncommented).
Thanks,
David Gil Oliva
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116886: Refactor private variables of KCompletion
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Refactor private variables of KCompletion Also: reorder variables declaration to avoid padding Diffs - src/kcompletion_p.h e3fad26 src/kcompletion.cpp 7396029 Diff: https://git.reviewboard.kde.org/r/116886/diff/ Testing --- It builds. Autotests 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 116886: Refactor private variables of KCompletion
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/ --- (Updated March 18, 2014, 11:01 p.m.) Review request for KDE Frameworks. Changes --- Forgot to commit fix. Repository: kcompletion Description --- Refactor private variables of KCompletion Also: reorder variables declaration to avoid padding Diffs (updated) - src/kcompletion_p.h e3fad26 src/kcompletion.cpp 7396029 Diff: https://git.reviewboard.kde.org/r/116886/diff/ Testing --- It builds. Autotests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116887: Undeprecate setUrlDropsEnabled(bool) in KComboBox and KLineEdit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116887/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Undeprecate setUrlDropsEnabled(bool) in KComboBox and KLineEdit Apidox say it to be deprecated and use installEventFilter with a LineEditUrlDropEventFilter instead. But that's precisely what setUrlDropsEnabled does, so I don't see the point of making the user do it when there's already a one-line method for that. Diffs - src/klineedit.h 76a1f01 src/kcombobox.h eea930d src/kcombobox.cpp 30edc1b Diff: https://git.reviewboard.kde.org/r/116887/diff/ Testing --- It builds. The compiler warnings about this deprecation disappear. 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 116886: Refactor private variables of KCompletion
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/#review53379 --- Ship it! Ship It! - Aleix Pol Gonzalez On March 18, 2014, 11:01 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116886/ --- (Updated March 18, 2014, 11:01 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- Refactor private variables of KCompletion Also: reorder variables declaration to avoid padding Diffs - src/kcompletion_p.h e3fad26 src/kcompletion.cpp 7396029 Diff: https://git.reviewboard.kde.org/r/116886/diff/ Testing --- It builds. Autotests 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 116879: Fix build of kuser_win.cpp with MSVC2010
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116879/ --- (Updated March 19, 2014, 1:47 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix build of kuser_win.cpp with MSVC2010: - Add missing cast. - Add return types to lambdas. In C++11, the return type is only deduced if the lambda consists only of a single return statement. This will change in C++14 (see C++ DR975), and MSVC2013 implements the new behavior, but MSVC2010 doesn't. Diffs - src/lib/util/kuser_win.cpp e7fb5b6 Diff: https://git.reviewboard.kde.org/r/116879/diff/ Testing --- Compiles on MSVC2010 and 2013. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116879: Fix build of kuser_win.cpp with MSVC2010
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116879/#review53380 --- This review has been submitted with commit 76422ffd11fb9d8e96af5cbc9a63abd598e223a0 by Nicolás Alvarez to branch master. - Commit Hook On March 18, 2014, 6:28 p.m., Nicolás Alvarez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116879/ --- (Updated March 18, 2014, 6:28 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix build of kuser_win.cpp with MSVC2010: - Add missing cast. - Add return types to lambdas. In C++11, the return type is only deduced if the lambda consists only of a single return statement. This will change in C++14 (see C++ DR975), and MSVC2013 implements the new behavior, but MSVC2010 doesn't. Diffs - src/lib/util/kuser_win.cpp e7fb5b6 Diff: https://git.reviewboard.kde.org/r/116879/diff/ Testing --- Compiles on MSVC2010 and 2013. Thanks, Nicolás Alvarez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116883: Fix KUserGroup::users() and KUserGroup::userNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/#review53382 --- A couple questions, one of which needs resolved, but looks good to go otherwise. src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116883/#comment37547 Does this need to be a template, or would std::function be sufficient? Templates have a poor reputation amongst some of our devs so I wouldn't make them the first answer unless they cleanly fit the problem. src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116883/#comment37546 A better name for callback would be something like handleNextGroupUser or some other descriptive way of describing what the callback is actually intended to do. - Michael Pyne On March 18, 2014, 9:20 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116883/ --- (Updated March 18, 2014, 9:20 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix KUserGroup::users() and KUserGroup::userNames() on UNIX The gr_mem member of struct group does not contain the names of users where the primary group is equal to that group. In order to fix this we have to iterate over all users and check whether the primary gid matches the requested group. Unlike getgrouplist() there does not seem to be a function that performs this task for us. Diffs - src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116883/diff/ Testing --- Listed groups seem to be correct now. Should fix Jenkins together with https://git.reviewboard.kde.org/r/116881/ File Attachments Before https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/871c8bc5-4631-4759-8103-eb7ac817d698__groupmembers_before.txt After https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/4295e719-acb8-495f-907b-5a93d2d8b64f__groupmembers_after.txt 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 116881: Fix KUser::groups() and KUser::groupNames() on UNIX
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/#review53383 --- I think I'd argue against bothering with getgrouplist at all if we have to maintain a backup to it either way, it just makes the code messier. But I'll leave that part up to you (maybe it's that much faster). Still a couple of other comments though. src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116881/#comment37549 Same comment about callback as from my other review. src/lib/util/kuser_unix.cpp https://git.reviewboard.kde.org/r/116881/#comment37548 Not sure what you mean with the comment here. Shouldn't gid_buffer[i] be just as safe (if not more) than obtaining the gid_t* and then dereferencing that as an array? - Michael Pyne On March 18, 2014, 8:14 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116881/ --- (Updated March 18, 2014, 8:14 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Fix KUser::groups() and KUser::groupNames() on UNIX If available we use getgrouplist() which returns all group IDs. Otherwise we fall back to using getgrent() and checking whether gr_mem contains the user. For some reason gr_mem doesn't usally contain the users primary gid, so we add the corresponding struct group for that gid as well. Diffs - src/lib/CMakeLists.txt 73f28a8a3acda8449a3aee3b025e2b165722b998 src/lib/util/config-getgrouplist.h.cmake PRE-CREATION src/lib/util/kuser_unix.cpp 0e0720dbb614015d6d568b39da3cab77cece76a8 Diff: https://git.reviewboard.kde.org/r/116881/diff/ Testing --- Returns more groups now, should fix KUserTest::testKUser() on build.kde.org File Attachments old user-groups result (getgrent) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/86c5e986-8098-4c50-809c-bc3e7851447a__grouplist_getgrent_old.txt new user-groups result (getgrouplist) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/59f4ecda-5c1d-4bdc-a8ec-850de761e3a3__grouplist_getgrouplist.txt new user-groups result (getgrent + current gid) https://git.reviewboard.kde.org/media/uploaded/files/2014/03/18/39d0172d-f6c8-400e-8af0-0c4aace8f7a1__grouplist_getgrent_new.txt Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
