LXR
On Thursday 20 March 2014 00:28:44 Alex Merry wrote: LXR says the only users are a couple of projects that haven't even made it onto projects.kde.org. Talking about LXR... I just finished setting up http://lxrnew.kde.org/ident Can you use it for your upcoming searches, to beta-test it? If nothing major came up, we'll switch lxr.kde.org to that new site. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: LXR
Hello, On Thu, Mar 20, 2014 at 1:43 PM, David Faure fa...@kde.org wrote: Talking about LXR... I just finished setting up http://lxrnew.kde.org/ident Can you use it for your upcoming searches, to beta-test it? If nothing major came up, we'll switch lxr.kde.org to that new site. Oops! Google Chrome could not find lxrnew.kde.org Did you mean: kde.org :( Thanks! -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: LXR
On Thursday 20 March 2014 13:47:33 Bhushan Shah wrote: Hello, On Thu, Mar 20, 2014 at 1:43 PM, David Faure fa...@kde.org wrote: Talking about LXR... I just finished setting up http://lxrnew.kde.org/ident Can you use it for your upcoming searches, to beta-test it? If nothing major came up, we'll switch lxr.kde.org to that new site. Oops! Google Chrome could not find lxrnew.kde.org Did you mean: kde.org :( Ah, ok, not in DNS yet. Add this line to /etc/hosts for now: 144.76.180.189 lxrnew.kde.org -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116912: Remove KSocks and KSocksSocketDevice
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116912/#review53501 --- This review has been submitted with commit f022e70fb37aa6828f0c99c36e0fa3d610fe4ef4 by Alex Merry to branch master. - Commit Hook On March 20, 2014, 12:33 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116912/ --- (Updated March 20, 2014, 12:33 a.m.) Review request for KDE Frameworks. Repository: kde4support Description --- Remove KSocks and KSocksSocketDevice LXR says these are entirely unused, they have been deprecated since 4.0 and k3socks.cpp makes use of the long-deprecated KLibrary::factory() method. Diffs - src/includes/CMakeLists.txt 048d474583a1ce9e5f142ad3ffb4d4ccb7f3 src/CMakeLists.txt 362855d1a3143a3efd74bee6a850eb11434eb517 src/includes/KNetwork/KSocksSocketDevice f2b7cea900c73545d751f8b03fdcd0e46e51c659 src/includes/KSocks bf29d0350fe1241820efffbdb39f72f353123a15 src/kdecore/k3socketdevice.cpp da772b0196f35870ee1d87b43e4941519bcb661b src/kdecore/k3socks.h 51f8a4f2443b510b530c2afaa192271b6a6f00aa src/kdecore/k3socks.cpp 920340b14899b56b300607326e5da6fc810095b8 src/kdecore/k3sockssocketdevice.h 2197ce63f2d96415da5949bdaff83a4f694eef53 src/kdecore/k3sockssocketdevice.cpp dae2f75fbafbd4f1d91fb8503669220f6bf7475e Diff: https://git.reviewboard.kde.org/r/116912/diff/ Testing --- Built, installed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116913: Remove KParts::ComponentFactory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116913/#review53502 --- This review has been submitted with commit 1d0f9c844339ab02b80759e38a93ccfd1aba by Alex Merry to branch master. - Commit Hook On March 20, 2014, 12:28 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116913/ --- (Updated March 20, 2014, 12:28 a.m.) Review request for KDE Frameworks. Repository: kde4support Description --- Remove KParts::ComponentFactory All the methods in this namespace have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says the only users are a couple of projects that haven't even made it onto projects.kde.org. Diffs - src/CMakeLists.txt 362855d1a3143a3efd74bee6a850eb11434eb517 src/includes/CMakeLists.txt 048d474583a1ce9e5f142ad3ffb4d4ccb7f3 src/includes/KParts/ComponentFactory 5d7c2f1f9a2ba02e19517c727f06ce3e7bf057b0 src/kparts/componentfactory.h 8fba1c667144e47f6645c7830c459a1dbb0a926e Diff: https://git.reviewboard.kde.org/r/116913/diff/ Testing --- Built and installed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116913: Remove KParts::ComponentFactory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116913/ --- (Updated March 20, 2014, 10:45 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kde4support Description --- Remove KParts::ComponentFactory All the methods in this namespace have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says the only users are a couple of projects that haven't even made it onto projects.kde.org. Diffs - src/CMakeLists.txt 362855d1a3143a3efd74bee6a850eb11434eb517 src/includes/CMakeLists.txt 048d474583a1ce9e5f142ad3ffb4d4ccb7f3 src/includes/KParts/ComponentFactory 5d7c2f1f9a2ba02e19517c727f06ce3e7bf057b0 src/kparts/componentfactory.h 8fba1c667144e47f6645c7830c459a1dbb0a926e Diff: https://git.reviewboard.kde.org/r/116913/diff/ Testing --- Built and installed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116920: Move the autostart and wrapper docs into a docs/ subdirectory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116920/ --- Review request for KDE Frameworks. Repository: kinit Description --- Move the autostart and wrapper docs into a docs/ subdirectory Diffs - README.autostart README.wrapper Diff: https://git.reviewboard.kde.org/r/116920/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Query: Possible code contribution
Hi, On Wednesday, 2014-03-19, 23:36:27, Harsh Kumar wrote: On 3/16/14, Kevin Krammer kram...@kde.org wrote: One other thing that came to my mind is development of examples for Frameworks 5, see [1] and [2]. Only a couple of the frameworks seem to have an examples subdirectory. I think it would be both a valuable and self-contain contribution to make sure that as many frameworks as possible have good example programs. Maybe even having tutorials on techbase.kde.org explaining the steps that were necessary to create the examples. I can write some examples as I have some time want to contribute. However, I will need some guidance. I found a examples directory in karchive. Is that what is required? Yes, that is what I had in mind. Can someone please suggest a framework which is simple with which I can start creating examples? Good question. All the Tier 1 in this list [1] should be a good start since they do not depend on anything other than Qt itself. I am not sure how simple they are or if they have examples already. Maybe Sonnet or Solid would be interesting to work with? Cheers, Kevin [1] http://community.kde.org/Frameworks/List -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring 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: Review Request 116920: Move the autostart and wrapper docs into a docs/ subdirectory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116920/#review53513 --- Ship it! Ship It! - Aleix Pol Gonzalez On March 20, 2014, 11:17 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116920/ --- (Updated March 20, 2014, 11:17 a.m.) Review request for KDE Frameworks. Repository: kinit Description --- Move the autostart and wrapper docs into a docs/ subdirectory Diffs - README.autostart README.wrapper Diff: https://git.reviewboard.kde.org/r/116920/diff/ Testing --- 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 9:49, Aurélien Gâteau wrote:
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.
Some feedback on this: using Q_COREAPP_STARTUP_FUNCTION works as
expected. I think I have something usable now. Adapting a Qt-translated
framework requires the following changes (using kbookmarks as example
again):
1. Create src/Messages.sh with the following content:
rm -f $podir/tmp.ts
lupdate -silent -recursive . -ts $podir/tmp.ts
lconvert $podir/tmp.ts --sort-contexts --output-format pot -o
Re: Review Request 116920: Move the autostart and wrapper docs into a docs/ subdirectory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116920/#review53515 --- This review has been submitted with commit 70eb21cefded2359295478c1d034c4366f5d0808 by Alex Merry to branch master. - Commit Hook On March 20, 2014, 11:17 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116920/ --- (Updated March 20, 2014, 11:17 a.m.) Review request for KDE Frameworks. Repository: kinit Description --- Move the autostart and wrapper docs into a docs/ subdirectory Diffs - README.autostart README.wrapper Diff: https://git.reviewboard.kde.org/r/116920/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116920: Move the autostart and wrapper docs into a docs/ subdirectory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116920/ --- (Updated March 20, 2014, 2:24 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kinit Description --- Move the autostart and wrapper docs into a docs/ subdirectory Diffs - README.autostart README.wrapper Diff: https://git.reviewboard.kde.org/r/116920/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116927: Fix kdeinit module lookup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/ --- Review request for KDE Frameworks. Repository: kinit Description --- Fix kdeinit module lookup KLibrary's lookup magic is not so magic these days - is just uses QCoreApplication::libraryPaths, which is not what we want. Instead, we let dlopen() do the searching for us, plus hack in a check in the library installation directory for kinit (since dlopen() called from Qt does not respect kdeinit5's RUNPATH). This should cover most common cases (module installed to standard location, module installed to same location as the kinit framework, mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to the normal executable. Rename kinit_library_path() to generate_socket_name() This reflects what the function actually does. Also got rid of the (mostly) ifdef'd-out code that gave the function its original name. Add comment about fragility of lookup based on installation vars Diffs - src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116927/diff/ Testing --- Built and installed. Ran kdeinit5, which reported that it was launching libkdeinit5_klauncher, rather than /home/kf5-devel/kf5/bin/klauncher as it did previously. klauncher process then has [kdeinit] in its process title in `ps xu`. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116928: Default to not launching kded
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/ --- Review request for KDE Frameworks. Repository: kinit Description --- Default to not launching kded It can be autolaunched as required. Plasma sessions can use the --kded argument to always start it. Allow both --no-fork and --nofork arguments to kdeinit Different platforms have had different versions of this argument, and KUniqueApplication used --nofork. The help text standardises on --no-fork, as that matches the other arguments, but both versions are accepted. Diffs - src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116928/diff/ Testing --- Builds, installs. `kdeinit5` does not launch kded5, while `kdeinit5 --kded` does. Thanks, Alex Merry ___ 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
Just as information: now the QML imports: * draganddrop * kquickcontrols * qtextracomponents are no more in plasma-framework, but in the kdeclarative repo the dirmodel import wasn't used and is now gone (is somebody was planning to use it please speak now): it will hopefully be replaced with a more complete one that is being developed in folderview -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116930: Fix device not open warning messages at build time
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116930/
---
Review request for KDE Frameworks.
Repository: kservice
Description
---
The device not open message appears when one registers a factory without a
.json file.
The K_PLUGIN_FACTORY_WITH_BASEFACTORY macro expands to:
class MyPlugin : public KPluginFactory
{
Q_OBJECT
Q_PLUGIN_METADATA(IID KPluginFactory_iid FILE )
When moc parses such code, it tries to read a json file named and rightfully
complains.
Diffs
-
src/plugin/kpluginfactory.h 3880d29
Diff: https://git.reviewboard.kde.org/r/116930/diff/
Testing
---
Rebuilt kde-workspace from scratch. No more message.
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 116928: Default to not launching kded
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/#review53526 --- Can you make sure that kded is launched in Plasma sessions? Just removing it and going it can be started is not good enough, we need it, we know that, and we don't want to introduce regressions in the workspace. - Sebastian Kügler On March 20, 2014, 3:04 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/ --- (Updated March 20, 2014, 3:04 p.m.) Review request for KDE Frameworks. Repository: kinit Description --- Default to not launching kded It can be autolaunched as required. Plasma sessions can use the --kded argument to always start it. Allow both --no-fork and --nofork arguments to kdeinit Different platforms have had different versions of this argument, and KUniqueApplication used --nofork. The help text standardises on --no-fork, as that matches the other arguments, but both versions are accepted. Diffs - src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116928/diff/ Testing --- Builds, installs. `kdeinit5` does not launch kded5, while `kdeinit5 --kded` does. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116928: Default to not launching kded
On March 20, 2014, 3:25 p.m., Sebastian Kügler wrote: Can you make sure that kded is launched in Plasma sessions? Just removing it and going it can be started is not good enough, we need it, we know that, and we don't want to introduce regressions in the workspace. https://git.reviewboard.kde.org/r/116931/ ought to do it. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/#review53526 --- On March 20, 2014, 3:04 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/ --- (Updated March 20, 2014, 3:04 p.m.) Review request for KDE Frameworks. Repository: kinit Description --- Default to not launching kded It can be autolaunched as required. Plasma sessions can use the --kded argument to always start it. Allow both --no-fork and --nofork arguments to kdeinit Different platforms have had different versions of this argument, and KUniqueApplication used --nofork. The help text standardises on --no-fork, as that matches the other arguments, but both versions are accepted. Diffs - src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116928/diff/ Testing --- Builds, installs. `kdeinit5` does not launch kded5, while `kdeinit5 --kded` does. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is still unstable: plasma-framework_master_qt5 » All,LINBUILDER #165
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is still unstable: plasma-framework_master_qt5 » All,LINBUILDER #166
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116928: Default to not launching kded
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/ --- (Updated March 20, 2014, 6:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Default to not launching kded It can be autolaunched as required. Plasma sessions can use the --kded argument to always start it. Allow both --no-fork and --nofork arguments to kdeinit Different platforms have had different versions of this argument, and KUniqueApplication used --nofork. The help text standardises on --no-fork, as that matches the other arguments, but both versions are accepted. Diffs - src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116928/diff/ Testing --- Builds, installs. `kdeinit5` does not launch kded5, while `kdeinit5 --kded` does. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is still unstable: plasma-framework_master_qt5 » All,LINBUILDER #167
See http://build.kde.org/job/plasma-framework_master_qt5/Variation=All,label=LINBUILDER/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116927: Fix kdeinit module lookup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/ --- (Updated March 20, 2014, 6:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Fix kdeinit module lookup KLibrary's lookup magic is not so magic these days - is just uses QCoreApplication::libraryPaths, which is not what we want. Instead, we let dlopen() do the searching for us, plus hack in a check in the library installation directory for kinit (since dlopen() called from Qt does not respect kdeinit5's RUNPATH). This should cover most common cases (module installed to standard location, module installed to same location as the kinit framework, mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to the normal executable. Rename kinit_library_path() to generate_socket_name() This reflects what the function actually does. Also got rid of the (mostly) ifdef'd-out code that gave the function its original name. Add comment about fragility of lookup based on installation vars Diffs - src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116927/diff/ Testing --- Built and installed. Ran kdeinit5, which reported that it was launching libkdeinit5_klauncher, rather than /home/kf5-devel/kf5/bin/klauncher as it did previously. klauncher process then has [kdeinit] in its process title in `ps xu`. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116914: Remove KLibLoader::createInstance methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116914/ --- (Updated March 20, 2014, 6:31 p.m.) Review request for KDE Frameworks and David Faure. Repository: kde4support Description --- Remove KLibLoader::createInstance methods These have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says there is a single user: jovie (in kdeaccessibility). Depends on 116913, because KParts::ComponentFactory methods make use of KLibLoader error codes. Diffs - autotests/klibloadertest.h 7307fea0ef69b302eb64aa121e4af54e034c24ab autotests/klibloadertest.cpp a6aebd278ea8e7121ccbb91422d08964d8dcf07a src/kdecore/klibloader.h 07d0c1c4bd4747b394745d9b7af0765874c4d6e3 src/kdecore/klibloader.cpp b9d0625025445f7c200608be06433bd19ec6ead0 Diff: https://git.reviewboard.kde.org/r/116914/diff/ Testing --- Builds, compiles, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116928: Default to not launching kded
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/ --- (Updated March 20, 2014, 7:35 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Default to not launching kded It can be autolaunched as required. Plasma sessions can use the --kded argument to always start it. Allow both --no-fork and --nofork arguments to kdeinit Different platforms have had different versions of this argument, and KUniqueApplication used --nofork. The help text standardises on --no-fork, as that matches the other arguments, but both versions are accepted. Diffs - src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116928/diff/ Testing --- Builds, installs. `kdeinit5` does not launch kded5, while `kdeinit5 --kded` does. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116928: Default to not launching kded
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/#review53601 --- This review has been submitted with commit 4cced1676cdef43ce5b55b61b76329a4741489ee by Alex Merry to branch master. - Commit Hook On March 20, 2014, 6:30 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/ --- (Updated March 20, 2014, 6:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Default to not launching kded It can be autolaunched as required. Plasma sessions can use the --kded argument to always start it. Allow both --no-fork and --nofork arguments to kdeinit Different platforms have had different versions of this argument, and KUniqueApplication used --nofork. The help text standardises on --no-fork, as that matches the other arguments, but both versions are accepted. Diffs - src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116928/diff/ Testing --- Builds, installs. `kdeinit5` does not launch kded5, while `kdeinit5 --kded` does. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116928: Default to not launching kded
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/#review53602 --- This review has been submitted with commit e7488c7852057c96b0ddf457b1c51785be5476d7 by Alex Merry to branch master. - Commit Hook On March 20, 2014, 6:30 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116928/ --- (Updated March 20, 2014, 6:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Default to not launching kded It can be autolaunched as required. Plasma sessions can use the --kded argument to always start it. Allow both --no-fork and --nofork arguments to kdeinit Different platforms have had different versions of this argument, and KUniqueApplication used --nofork. The help text standardises on --no-fork, as that matches the other arguments, but both versions are accepted. Diffs - src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116928/diff/ Testing --- Builds, installs. `kdeinit5` does not launch kded5, while `kdeinit5 --kded` does. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116914: Remove KLibLoader::createInstance methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116914/#review53603 --- Ship it! bye old code - David Faure On March 20, 2014, 6:31 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116914/ --- (Updated March 20, 2014, 6:31 p.m.) Review request for KDE Frameworks and David Faure. Repository: kde4support Description --- Remove KLibLoader::createInstance methods These have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says there is a single user: jovie (in kdeaccessibility). Depends on 116913, because KParts::ComponentFactory methods make use of KLibLoader error codes. Diffs - autotests/klibloadertest.h 7307fea0ef69b302eb64aa121e4af54e034c24ab autotests/klibloadertest.cpp a6aebd278ea8e7121ccbb91422d08964d8dcf07a src/kdecore/klibloader.h 07d0c1c4bd4747b394745d9b7af0765874c4d6e3 src/kdecore/klibloader.cpp b9d0625025445f7c200608be06433bd19ec6ead0 Diff: https://git.reviewboard.kde.org/r/116914/diff/ Testing --- Builds, compiles, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116914: Remove KLibLoader::createInstance methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116914/ --- (Updated March 20, 2014, 7:41 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kde4support Description --- Remove KLibLoader::createInstance methods These have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says there is a single user: jovie (in kdeaccessibility). Depends on 116913, because KParts::ComponentFactory methods make use of KLibLoader error codes. Diffs - autotests/klibloadertest.h 7307fea0ef69b302eb64aa121e4af54e034c24ab autotests/klibloadertest.cpp a6aebd278ea8e7121ccbb91422d08964d8dcf07a src/kdecore/klibloader.h 07d0c1c4bd4747b394745d9b7af0765874c4d6e3 src/kdecore/klibloader.cpp b9d0625025445f7c200608be06433bd19ec6ead0 Diff: https://git.reviewboard.kde.org/r/116914/diff/ Testing --- Builds, compiles, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116914: Remove KLibLoader::createInstance methods
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116914/#review53604 --- This review has been submitted with commit 706214df096b0fcf11de7d1ff3331d009e38acb3 by Alex Merry to branch master. - Commit Hook On March 20, 2014, 6:31 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116914/ --- (Updated March 20, 2014, 6:31 p.m.) Review request for KDE Frameworks and David Faure. Repository: kde4support Description --- Remove KLibLoader::createInstance methods These have been deprecated since 4.0, and use the long-deprecated KLibrary::factory() method. LXR says there is a single user: jovie (in kdeaccessibility). Depends on 116913, because KParts::ComponentFactory methods make use of KLibLoader error codes. Diffs - autotests/klibloadertest.h 7307fea0ef69b302eb64aa121e4af54e034c24ab autotests/klibloadertest.cpp a6aebd278ea8e7121ccbb91422d08964d8dcf07a src/kdecore/klibloader.h 07d0c1c4bd4747b394745d9b7af0765874c4d6e3 src/kdecore/klibloader.cpp b9d0625025445f7c200608be06433bd19ec6ead0 Diff: https://git.reviewboard.kde.org/r/116914/diff/ Testing --- Builds, compiles, tests pass. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116934: Use KPluginLoader to find kioslaves
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116934/ --- Review request for KDE Frameworks. Repository: kio Description --- Use KPluginLoader to find kioslaves KIO slaves are typically installed in PLUGIN_INSTALL_DIR, rather than QT_PLUGIN_INSTALL_DIR, so we should use KPluginLoader instead of QPluginLoader to locate them. Diffs - src/kioslave/CMakeLists.txt 64bf7e0f36a1a407dd162e2c0461dedb2f57a13e src/kioslave/kioslave.cpp 50413d04be29361638ba581383354d79881e844e Diff: https://git.reviewboard.kde.org/r/116934/diff/ Testing --- In combination with https://git.reviewboard.kde.org/r/116935/ Ran KDE_SLAVE_VALGRIND=file kdeinit5 and use the kioslavetest app to copy a file; the copy was successful, and the terminal running kdeinit5 output kdeinit5: preparing to launch '/usr/bin/valgrind' ==20134== Memcheck, a memory error detector ==20134== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==20134== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==20134== Command: /home/kf5-devel/kf5/lib64/kde5/libexec/kioslave kio_file file local:/tmp/runtime-kf5-devel/klauncherJ19850.slave-socket local:/tmp/runtime-kf5-devel/kioslavetestJ20122.slave-socket ==20134== (20134)/(default) [31m[34mmain[0m: trying to load kio_file from /home/kf5-devel/kf5/lib64/plugins/kf5/kio_file.so ==20134== ==20134== HEAP SUMMARY: ==20134== in use at exit: 5,846 bytes in 42 blocks ==20134== total heap usage: 998 allocs, 956 frees, 672,987 bytes allocated ==20134== ==20134== LEAK SUMMARY: ==20134==definitely lost: 0 bytes in 0 blocks ==20134==indirectly lost: 0 bytes in 0 blocks ==20134== possibly lost: 0 bytes in 0 blocks ==20134==still reachable: 5,846 bytes in 42 blocks ==20134== suppressed: 0 bytes in 0 blocks ==20134== Rerun with --leak-check=full to see details of leaked memory ==20134== ==20134== For counts of detected and suppressed errors, rerun with: -v ==20134== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116935: Remove use of KLibrary in KLauncher
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116935/ --- Review request for KDE Frameworks. Repository: kinit Description --- Remove use of KLibrary in KLauncher All the non-valgrind code paths that invoke kioslave let it do the lookup of the module, so the valgrind path can as well. Also adjusted the USE_KPROCESS_FOR_KIOSLAVES code path so that the kioslave executable is actually included in the arguments to valgrind. Diffs - src/klauncher/klauncher.cpp a8630854af4bd3094b9688c3f9a40d10516d2056 Diff: https://git.reviewboard.kde.org/r/116935/diff/ Testing --- In combination with https://git.reviewboard.kde.org/r/116934/ Ran KDE_SLAVE_VALGRIND=file kdeinit5 and use the kioslavetest app to copy a file; the copy was successful, and the terminal running kdeinit5 output kdeinit5: preparing to launch '/usr/bin/valgrind' ==20134== Memcheck, a memory error detector ==20134== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==20134== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==20134== Command: /home/kf5-devel/kf5/lib64/kde5/libexec/kioslave kio_file file local:/tmp/runtime-kf5-devel/klauncherJ19850.slave-socket local:/tmp/runtime-kf5-devel/kioslavetestJ20122.slave-socket ==20134== (20134)/(default) [31m[34mmain[0m: trying to load kio_file from /home/kf5-devel/kf5/lib64/plugins/kf5/kio_file.so ==20134== ==20134== HEAP SUMMARY: ==20134== in use at exit: 5,846 bytes in 42 blocks ==20134== total heap usage: 998 allocs, 956 frees, 672,987 bytes allocated ==20134== ==20134== LEAK SUMMARY: ==20134==definitely lost: 0 bytes in 0 blocks ==20134==indirectly lost: 0 bytes in 0 blocks ==20134== possibly lost: 0 bytes in 0 blocks ==20134==still reachable: 5,846 bytes in 42 blocks ==20134== suppressed: 0 bytes in 0 blocks ==20134== Rerun with --leak-check=full to see details of leaked memory ==20134== ==20134== For counts of detected and suppressed errors, rerun with: -v ==20134== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) 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
El Dijous, 20 de març de 2014, a les 07:06:58, Aurélien Gâteau va escriure:
On Tue, Mar 18, 2014, at 9:49, Aurélien Gâteau wrote:
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.
Some feedback on this: using Q_COREAPP_STARTUP_FUNCTION works as
expected. I think I have something usable now. Adapting a Qt-translated
Re: Review Request 116934: Use KPluginLoader to find kioslaves
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116934/ --- (Updated March 20, 2014, 8:34 p.m.) Review request for KDE Frameworks. Changes --- src/core/slave.cpp also does the same lookup Repository: kio Description --- Use KPluginLoader to find kioslaves KIO slaves are typically installed in PLUGIN_INSTALL_DIR, rather than QT_PLUGIN_INSTALL_DIR, so we should use KPluginLoader instead of QPluginLoader to locate them. Diffs (updated) - src/core/slave.cpp ee84066f96675caaf1fa5ba612c8242eac160c4a src/kioslave/CMakeLists.txt 64bf7e0f36a1a407dd162e2c0461dedb2f57a13e src/kioslave/kioslave.cpp 50413d04be29361638ba581383354d79881e844e Diff: https://git.reviewboard.kde.org/r/116934/diff/ Testing (updated) --- In combination with https://git.reviewboard.kde.org/r/116935/ Ran KDE_SLAVE_VALGRIND=file kdeinit5 and use the kioslavetest app to copy a file; the copy was successful, and the terminal running kdeinit5 output kdeinit5: preparing to launch '/usr/bin/valgrind' ==20134== Memcheck, a memory error detector ==20134== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==20134== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ==20134== Command: /home/kf5-devel/kf5/lib64/kde5/libexec/kioslave kio_file file local:/tmp/runtime-kf5-devel/klauncherJ19850.slave-socket local:/tmp/runtime-kf5-devel/kioslavetestJ20122.slave-socket ==20134== (20134)/(default) [31m[34mmain[0m: trying to load kio_file from /home/kf5-devel/kf5/lib64/plugins/kf5/kio_file.so ==20134== ==20134== HEAP SUMMARY: ==20134== in use at exit: 5,846 bytes in 42 blocks ==20134== total heap usage: 998 allocs, 956 frees, 672,987 bytes allocated ==20134== ==20134== LEAK SUMMARY: ==20134==definitely lost: 0 bytes in 0 blocks ==20134==indirectly lost: 0 bytes in 0 blocks ==20134== possibly lost: 0 bytes in 0 blocks ==20134==still reachable: 5,846 bytes in 42 blocks ==20134== suppressed: 0 bytes in 0 blocks ==20134== Rerun with --leak-check=full to see details of leaked memory ==20134== ==20134== For counts of detected and suppressed errors, rerun with: -v ==20134== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 1 from 1) For the change to src/core/slave.cpp, ran KDE_FORK_SLAVES=1 ./kioslavetest and did the same test; uncommented the debug line in that method so it printed kioslave , /home/kf5-devel/kf5/lib64/plugins/kf5/kio_file.so , file , , QUrl( local:/tmp/runtime-kf5-devel/kioslavetestJ32621.slave-socket ) and the copy was successful. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116936: Use QLibrary instead of KLibrary
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116936/ --- Review request for KDE Frameworks and Martin Tobias Holmedahl Sandsmark. Repository: khtml Description --- Use QLibrary instead of KLibrary This code wants to load normal libraries, rather than ones in plugin directories, and so does not need or want KLibrary's odd lookup routines. Diffs - src/html/kopenssl.cpp 43125ae90cb4e375cb93a011acbf584adc334f0a src/rendering/break_lines.cpp bc4542c7ea1031d75531b6028f3044fe15672009 Diff: https://git.reviewboard.kde.org/r/116936/diff/ Testing --- ./tests/testkhtml 'https://git.reviewboard.kde.org' Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116937: Use QLibrary instead of KLibrary in KOpenSSL
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116937/ --- Review request for KDE Frameworks. Repository: kde4support Description --- Use QLibrary instead of KLibrary in KOpenSSL Diffs - src/kssl/kopenssl.cpp 43125ae90cb4e375cb93a011acbf584adc334f0a Diff: https://git.reviewboard.kde.org/r/116937/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116927: Fix kdeinit module lookup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/#review53619 --- Ship it! Ship It! - David Faure On March 20, 2014, 6:30 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/ --- (Updated March 20, 2014, 6:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Fix kdeinit module lookup KLibrary's lookup magic is not so magic these days - is just uses QCoreApplication::libraryPaths, which is not what we want. Instead, we let dlopen() do the searching for us, plus hack in a check in the library installation directory for kinit (since dlopen() called from Qt does not respect kdeinit5's RUNPATH). This should cover most common cases (module installed to standard location, module installed to same location as the kinit framework, mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to the normal executable. Rename kinit_library_path() to generate_socket_name() This reflects what the function actually does. Also got rid of the (mostly) ifdef'd-out code that gave the function its original name. Add comment about fragility of lookup based on installation vars Diffs - src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116927/diff/ Testing --- Built and installed. Ran kdeinit5, which reported that it was launching libkdeinit5_klauncher, rather than /home/kf5-devel/kf5/bin/klauncher as it did previously. klauncher process then has [kdeinit] in its process title in `ps xu`. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116899: Remove unused QtWidgets dependency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116899/#review53620 --- Ship it! klauncher uses KIOWidgets, but yeah no direct use of QWidget - David Faure On March 19, 2014, 1 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116899/ --- (Updated March 19, 2014, 1 p.m.) Review request for KDE Frameworks. Repository: kinit Description --- It looks to be unused currently, so remove it. Diffs - CMakeLists.txt b5ec044da270bda4536d31e021d11f2a89c838d9 Diff: https://git.reviewboard.kde.org/r/116899/diff/ Testing --- Inspected source. A build test is difficult since some of kinit's dependencies have QtWidgets as a public dependency. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116927: Fix kdeinit module lookup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/ --- (Updated March 20, 2014, 10:18 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Fix kdeinit module lookup KLibrary's lookup magic is not so magic these days - is just uses QCoreApplication::libraryPaths, which is not what we want. Instead, we let dlopen() do the searching for us, plus hack in a check in the library installation directory for kinit (since dlopen() called from Qt does not respect kdeinit5's RUNPATH). This should cover most common cases (module installed to standard location, module installed to same location as the kinit framework, mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to the normal executable. Rename kinit_library_path() to generate_socket_name() This reflects what the function actually does. Also got rid of the (mostly) ifdef'd-out code that gave the function its original name. Add comment about fragility of lookup based on installation vars Diffs - src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116927/diff/ Testing --- Built and installed. Ran kdeinit5, which reported that it was launching libkdeinit5_klauncher, rather than /home/kf5-devel/kf5/bin/klauncher as it did previously. klauncher process then has [kdeinit] in its process title in `ps xu`. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116927: Fix kdeinit module lookup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/#review53621 --- This review has been submitted with commit 9895f310118a91f9681b60c25974418ec7b2bbdc by Alex Merry to branch master. - Commit Hook On March 20, 2014, 6:30 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/ --- (Updated March 20, 2014, 6:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Fix kdeinit module lookup KLibrary's lookup magic is not so magic these days - is just uses QCoreApplication::libraryPaths, which is not what we want. Instead, we let dlopen() do the searching for us, plus hack in a check in the library installation directory for kinit (since dlopen() called from Qt does not respect kdeinit5's RUNPATH). This should cover most common cases (module installed to standard location, module installed to same location as the kinit framework, mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to the normal executable. Rename kinit_library_path() to generate_socket_name() This reflects what the function actually does. Also got rid of the (mostly) ifdef'd-out code that gave the function its original name. Add comment about fragility of lookup based on installation vars Diffs - src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116927/diff/ Testing --- Built and installed. Ran kdeinit5, which reported that it was launching libkdeinit5_klauncher, rather than /home/kf5-devel/kf5/bin/klauncher as it did previously. klauncher process then has [kdeinit] in its process title in `ps xu`. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116927: Fix kdeinit module lookup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/#review53623 --- This review has been submitted with commit 8a91d176018e14bb4c9bd848c3764110feab4150 by Alex Merry to branch master. - Commit Hook On March 20, 2014, 10:18 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/ --- (Updated March 20, 2014, 10:18 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Fix kdeinit module lookup KLibrary's lookup magic is not so magic these days - is just uses QCoreApplication::libraryPaths, which is not what we want. Instead, we let dlopen() do the searching for us, plus hack in a check in the library installation directory for kinit (since dlopen() called from Qt does not respect kdeinit5's RUNPATH). This should cover most common cases (module installed to standard location, module installed to same location as the kinit framework, mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to the normal executable. Rename kinit_library_path() to generate_socket_name() This reflects what the function actually does. Also got rid of the (mostly) ifdef'd-out code that gave the function its original name. Add comment about fragility of lookup based on installation vars Diffs - src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116927/diff/ Testing --- Built and installed. Ran kdeinit5, which reported that it was launching libkdeinit5_klauncher, rather than /home/kf5-devel/kf5/bin/klauncher as it did previously. klauncher process then has [kdeinit] in its process title in `ps xu`. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116927: Fix kdeinit module lookup
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/#review53622 --- This review has been submitted with commit ef1375f25f7b3f3fba25e1e9374d6c4c0e093c50 by Alex Merry to branch master. - Commit Hook On March 20, 2014, 6:30 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116927/ --- (Updated March 20, 2014, 6:30 p.m.) Review request for KDE Frameworks and David Faure. Repository: kinit Description --- Fix kdeinit module lookup KLibrary's lookup magic is not so magic these days - is just uses QCoreApplication::libraryPaths, which is not what we want. Instead, we let dlopen() do the searching for us, plus hack in a check in the library installation directory for kinit (since dlopen() called from Qt does not respect kdeinit5's RUNPATH). This should cover most common cases (module installed to standard location, module installed to same location as the kinit framework, mdoule in LD_LIBRARY_PATH), and if it still fails we just fall back to the normal executable. Rename kinit_library_path() to generate_socket_name() This reflects what the function actually does. Also got rid of the (mostly) ifdef'd-out code that gave the function its original name. Add comment about fragility of lookup based on installation vars Diffs - src/kdeinit/CMakeLists.txt c4e3c49ea28d4e96be9ee1fa02f801052945d01e src/kdeinit/kinit.cpp 82d570c4453cf083e525125edd448b97d8d11bd3 Diff: https://git.reviewboard.kde.org/r/116927/diff/ Testing --- Built and installed. Ran kdeinit5, which reported that it was launching libkdeinit5_klauncher, rather than /home/kf5-devel/kf5/bin/klauncher as it did previously. klauncher process then has [kdeinit] in its process title in `ps xu`. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 alpha2
On Wednesday 19 March 2014 20:25:35 Christoph Cullmann wrote: I would appreciate any hint on what is needed more to have ktexteditor in the KF 5.0 release as I think it would give applications like Kate/KDevelop/Kile/... the possibility to have KF 5.0 ports available. Kate/KWrite itself is really KF 5 ready ;) Yep, makes a lot of sense. I added it to the list of modules for the next KF5 release. You should move the epic up on http://community.kde.org/Frameworks/Epics You should also double-check the checklist at http://community.kde.org/Frameworks/CreationGuidelines just to make sure nothing got forgotten. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kwallet_master_qt5 #67
See http://build.kde.org/job/kwallet_master_qt5/67/changes Changes: [faure] Merge the changes from kde-runtime master, mostly gcrypt support. -- [...truncated 173 lines...] Automatic moc for target kwallettestlib Automatic moc for target testbf [ 12%] [ 12%] [ 12%] Built target backendtest_automoc Built target testsha_automoc [ 12%] Built target testbf_automoc Built target kwalletbackend5_automoc Scanning dependencies of target kwalletboth_automoc [ 14%] Scanning dependencies of target kwalletsync_automoc Scanning dependencies of target kwalletmany_automoc Scanning dependencies of target kwalletpath_automoc [ 15%] Automatic moc for target kwalletboth [ 16%] Automatic moc for target kwalletsync [ 18%] Automatic moc for target kwalletpath Automatic moc for target kwalletmany Generating kwallettest.moc http://build.kde.org/job/kwallet_master_qt5/ws/tests/kwalletd/kwallettest.cpp:0: Note: No relevant classes found. No output generated. Generating moc_kwallet.cpp [ 18%] Built target KF5Wallet_automoc Scanning dependencies of target kwalletwizardtest_automoc Generating kbetterthankdialog.moc http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/kbetterthankdialog.cpp:0: Note: No relevant classes found. No output generated. [ 19%] Generating moc_kwallettest.cpp [ 19%] Generating moc_kwalletmany.cpp Built target kwallettestlib_automoc Automatic moc for target kwalletwizardtest [ 19%] Built target kwalletmany_automoc [ 21%] Generating kwallet_interface.cpp, kwallet_interface.h Generating moc_kwalletasync.cpp Generating ktimeout.moc http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/ktimeout.cpp:0: Note: No relevant classes found. No output generated. [ 21%] Built target kwalletasync_automoc Generating moc_kwallettest.cpp [ 21%] Built target kwallettest_automoc Generating moc_kwalletpath.cpp Generating moc_kwalletsync.cpp Generating moc_kwalletboth.cpp [ 21%] [ 21%] [ 21%] Built target kwalletpath_automoc Built target kwalletsync_automoc Built target kwalletboth_automoc Scanning dependencies of target kwalletbackend5 [ 22%] [ 23%] [ 25%] [ 26%] [ 28%] [ 29%] [ 30%] Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/blowfish.cc.o Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/blockcipher.cc.o Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/sha1.cc.o Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/cbc.cc.o Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/kwalletentry.cc.o Generating kwallet_interface.moc Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/kwalletbackend.cc.o Generating kwalletwizard.moc http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/kwalletwizard.cpp:0: Note: No relevant classes found. No output generated. [ 32%] Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/backendpersisthandler.cpp.o http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/sha1.cc:102:5: warning: Q_BYTE_ORDER is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/sha1.cc:102:21: warning: Q_BIG_ENDIAN is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/sha1.cc:317:5: warning: Q_BYTE_ORDER is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/sha1.cc:317:21: warning: Q_BIG_ENDIAN is not defined [-Wundef] [ 33%] Building CXX object src/runtime/kwalletd/backend/CMakeFiles/kwalletbackend5.dir/kwalletbackend5_automoc.cpp.o http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:139:5: warning: Q_BYTE_ORDER is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:139:21: warning: Q_BIG_ENDIAN is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:157:5: warning: Q_BYTE_ORDER is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:157:21: warning: Q_BIG_ENDIAN is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:162:5: warning: Q_BYTE_ORDER is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:162:21: warning: Q_BIG_ENDIAN is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:181:5: warning: Q_BYTE_ORDER is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:181:21: warning: Q_BIG_ENDIAN is not defined [-Wundef] http://build.kde.org/job/kwallet_master_qt5/ws/src/runtime/kwalletd/backend/blowfish.cc:186:5: warning:
Build failed in Jenkins: kinit_master_qt5 #41
See http://build.kde.org/job/kinit_master_qt5/41/changes Changes: [alex.merry] Add comment about fragility of lookup based on installation vars [alex.merry] Rename kinit_library_path() to generate_socket_name() [alex.merry] Fix kdeinit module lookup -- Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace http://build.kde.org/job/kinit_master_qt5/ws/ Running Prebuild steps [kinit_master_qt5] $ /bin/sh -xe /tmp/hudson5153225768335144028.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/kinit 70eb21c..8a91d17 master - origin/master Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 70eb21c Move the autostart and wrapper docs into a docs/ subdirectory Removing build/ Removing dotdata/ Removing install/ Success build forhudson.tasks.Shell@6f5810de Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/kinit Checking out Revision 8a91d176018e14bb4c9bd848c3764110feab4150 (refs/heads/jenkins) Run condition [File exists] enabling prebuild for step [Publish JUnit test result report] Run condition [File exists] enabling prebuild for step [Publish Cppcheck results] [kinit_master_qt5] $ /bin/sh -xe /tmp/hudson3427934406032443360.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: kinit - Branch master == Build Dependencies: kxmlgui - Branch master kconfigwidgets - Branch master solid - Branch master kauth - Branch master extra-cmake-modules - Branch master kiconthemes - Branch master kjobwidgets - Branch master kcrash - Branch master knotifications - Branch master kdbusaddons - Branch master kcodecs - Branch master cmake - Branch master ktextwidgets - Branch master phonon - Branch master karchive - Branch master kio - Branch master kservice - Branch master sonnet - Branch master kwindowsystem - Branch master ki18n - Branch master kdoctools - Branch master kitemviews - Branch master polkit-qt-1 - Branch qt5 kglobalaccel - Branch master kguiaddons - Branch master kbookmarks - Branch master kcompletion - Branch master qt5 - Branch stable kwidgetsaddons - Branch master kcoreaddons - Branch master kconfig - Branch master == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for __progname -- Looking for __progname - found -- Looking for __progname_full -- Looking for __progname_full - found -- Looking for include file sys/pstat.h -- Looking for include file sys/pstat.h - not found -- Looking for include file sys/types.h -- Looking for include file sys/types.h - found -- Looking for include file unistd.h -- Looking for include file unistd.h - found -- Looking for include file sys/select.h -- Looking for include file sys/select.h - found -- Looking for include file sys/exec.h -- Looking for include file sys/exec.h - not found -- Looking for pstat -- Looking for pstat - not found -- Looking for setproctitle -- Looking for setproctitle - not found -- Looking for connect in socket -- Looking for connect in socket - not found -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Found X11: /usr/lib64/libX11.so -- Using setuid root kdeinit wrapper in order to protect it from bad Linux OOM-killer -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: KDE4_BUILD_TESTS LIB_SUFFIX SIP_DEFAULT_SIP_DIR -- Build files have been written to: http://build.kde.org/job/kinit_master_qt5/ws/build == Commencing the Build Scanning dependencies of target kdeinit5_wrapper_automoc Scanning dependencies of target kdeinit5_automoc Scanning dependencies of target kdeinit5_shutdown_automoc
Review Request 116939: Add deprecation info to kcombobox, kcompletionbase and klineedit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116939/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- See summary Diffs - src/kcombobox.h eea930d src/kcompletionbase.h 8022214 src/klineedit.h 76a1f01 Diff: https://git.reviewboard.kde.org/r/116939/diff/ Testing --- Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdesrc-build] /: kf5: Port rc files to use branch-groups consistently.
On Wednesday 05 March 2014 10:44:24 Kevin Ottens wrote: Hello, On Tuesday 04 March 2014 22:54:42 David Faure wrote: On Tuesday 04 March 2014 01:32:14 Michael Pyne wrote: It wasn't that transparent at all - a number of modules have been re- downloaded in a different location in my local source directory: * plasma-frameworks moved under playground/libs Maybe time to get this one moved to frameworks. I don't think playground/libs still makes sense for it. I agree. Aaron, any objections? Ben, can you make the change? I'm not sure what has to be done exactly to move a project in the p.k.o hierarchy (is that documented anywhere?) * kactivities moved under kde/kdelibs/kactivities (a very odd location in the frameworks world, but kde_projects.xml is global, not branch-dependent) Ideally should be under frameworks at some point. I'd rather have it odd in the kde4 world now. :-) Me too... I guess most people compiling all of KDE SC are starting to look at frameworks by now indeed, let's move both. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116894: Clean up comments that reference kde4
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116894/#review53624 --- Ship it! Ship It! - David Faure On March 19, 2014, 11:26 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116894/ --- (Updated March 19, 2014, 11:26 a.m.) Review request for KDE Frameworks. Repository: kservice Description --- Clean up comments about removed syscoca type numbers Remove explanation of why the desktoptojson target is exported The explanation was wrong, and it doesn't really need any justification anyway. Remove comment about test finding kmailservice from KDE4 It won't find the wrong kmailservice, because the desktop file is now called kmailservice5. Diffs - autotests/kservicetest.cpp 711fb9b649e580ad474b0cdecd26dcdbfdc302a2 src/desktoptojson/CMakeLists.txt f106d254e015fc4eccf12fb4437ec221fb64ba1b src/sycoca/ksycocatype.h 54276a6bc04d8a48be8c4022250453e4c9993279 Diff: https://git.reviewboard.kde.org/r/116894/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116939: Add deprecation info to kcombobox, kcompletionbase and klineedit
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116939/#review53625 --- Ship it! Ship It! - Aleix Pol Gonzalez On March 20, 2014, 11:16 p.m., David Gil Oliva wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116939/ --- (Updated March 20, 2014, 11:16 p.m.) Review request for KDE Frameworks. Repository: kcompletion Description --- See summary Diffs - src/kcombobox.h eea930d src/kcompletionbase.h 8022214 src/klineedit.h 76a1f01 Diff: https://git.reviewboard.kde.org/r/116939/diff/ Testing --- 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 113830: Allow unique apps to access command-line arguments of later invocations
On Friday 22 November 2013 11:32:45 David Faure wrote: Which reminds me that we don't have a replacement for KCmdLineArgs::url(i) instead, i.e. a method that resolves an absolute filename, a relative filename (given a CWD), or a URL into a QUrl, for convenience. Many (kio- based) apps need that. It doesn't have to be part of QCommandLineParser though... maybe a QUrl::fromUserInput(string, cwd) [...] Implemented now - https://codereview.qt-project.org/81471 -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116899: Remove unused QtWidgets dependency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116899/#review53627 --- This review has been submitted with commit adf0ec5df14b3000858f37f2e054e16b96f33c74 by Michael Palimaka to branch master. - Commit Hook On March 19, 2014, 1 p.m., Michael Palimaka wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116899/ --- (Updated March 19, 2014, 1 p.m.) Review request for KDE Frameworks. Repository: kinit Description --- It looks to be unused currently, so remove it. Diffs - CMakeLists.txt b5ec044da270bda4536d31e021d11f2a89c838d9 Diff: https://git.reviewboard.kde.org/r/116899/diff/ Testing --- Inspected source. A build test is difficult since some of kinit's dependencies have QtWidgets as a public dependency. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Build failed in Jenkins: kinit_master_qt5 #42
See http://build.kde.org/job/kinit_master_qt5/42/changes Changes: [kensington] Remove unused dependency. -- Started by remote host 127.0.0.1 with note: Triggered by commit Building remotely on LinuxSlave - 4 (PACKAGER LINBUILDER) in workspace http://build.kde.org/job/kinit_master_qt5/ws/ Running Prebuild steps [kinit_master_qt5] $ /bin/sh -xe /tmp/hudson3658516356599509685.sh + /home/jenkins/scripts/setup-env.sh Preparing to perform KDE Continuous Integration build == Setting Up Sources From git://anongit.kde.org/kinit 8a91d17..adf0ec5 master - origin/master Branch jenkins set up to track remote branch master from origin. == Cleaning Source Tree HEAD is now at 8a91d17 Fix kdeinit module lookup Removing build/ Success build forhudson.tasks.Shell@6f5810de Fetching changes from the remote Git repository Fetching upstream changes from git://anongit.kde.org/kinit Checking out Revision adf0ec5df14b3000858f37f2e054e16b96f33c74 (refs/heads/jenkins) Run condition [File exists] enabling prebuild for step [Publish JUnit test result report] Run condition [File exists] enabling prebuild for step [Publish Cppcheck results] [kinit_master_qt5] $ /bin/sh -xe /tmp/hudson9099749821043316280.sh + /home/jenkins/scripts/execute-job.sh KDE Continuous Integration Build == Building Project: kinit - Branch master == Build Dependencies: extra-cmake-modules - Branch master solid - Branch master kauth - Branch master kconfigwidgets - Branch master ki18n - Branch master kjobwidgets - Branch master kcrash - Branch master knotifications - Branch master kguiaddons - Branch master kdbusaddons - Branch master kcodecs - Branch master kcoreaddons - Branch master ktextwidgets - Branch master phonon - Branch master karchive - Branch master kio - Branch master kservice - Branch master sonnet - Branch master kwindowsystem - Branch master kiconthemes - Branch master kdoctools - Branch master kitemviews - Branch master polkit-qt-1 - Branch qt5 kglobalaccel - Branch master kxmlgui - Branch master kbookmarks - Branch master kcompletion - Branch master qt5 - Branch stable kwidgetsaddons - Branch master cmake - Branch master kconfig - Branch master == Applying Patches === No patches to apply == Syncing Dependencies from Master Server == Configuring Build -- The C compiler identification is GNU 4.7.2 -- The CXX compiler identification is GNU 4.7.2 -- Check for working C compiler: /home/jenkins/bin/cc -- Check for working C compiler: /home/jenkins/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /home/jenkins/bin/c++ -- Check for working CXX compiler: /home/jenkins/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done -- Looking for __progname -- Looking for __progname - found -- Looking for __progname_full -- Looking for __progname_full - found -- Looking for include file sys/pstat.h -- Looking for include file sys/pstat.h - not found -- Looking for include file sys/types.h -- Looking for include file sys/types.h - found -- Looking for include file unistd.h -- Looking for include file unistd.h - found -- Looking for include file sys/select.h -- Looking for include file sys/select.h - found -- Looking for include file sys/exec.h -- Looking for include file sys/exec.h - not found -- Looking for pstat -- Looking for pstat - not found -- Looking for setproctitle -- Looking for setproctitle - not found -- Looking for connect in socket -- Looking for connect in socket - not found -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so -- Looking for XOpenDisplay in /usr/lib64/libX11.so;/usr/lib64/libXext.so - found -- Looking for gethostbyname -- Looking for gethostbyname - found -- Looking for connect -- Looking for connect - found -- Looking for remove -- Looking for remove - found -- Looking for shmat -- Looking for shmat - found -- Looking for IceConnectionNumber in ICE -- Looking for IceConnectionNumber in ICE - found -- Found X11: /usr/lib64/libX11.so -- Using setuid root kdeinit wrapper in order to protect it from bad Linux OOM-killer -- Configuring done -- Generating done CMake Warning: Manually-specified variables were not used by the project: KDE4_BUILD_TESTS LIB_SUFFIX SIP_DEFAULT_SIP_DIR -- Build files have been written to: http://build.kde.org/job/kinit_master_qt5/ws/build == Commencing the Build Scanning dependencies of target kdeinit5_automoc Scanning dependencies of target kdeinit5_shutdown_automoc Scanning dependencies of target kwrapper5_automoc Scanning dependencies of target kdeinit5_wrapper_automoc Scanning dependencies of target kdeinit_klauncher_automoc [ 5%] [ 5%] [ 8%] [ 10%] Scanning dependencies of target start_kdeinit_automoc [ 13%] Scanning dependencies of
Re: Review Request 116899: Remove unused QtWidgets dependency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116899/ --- (Updated March 21, 2014, 2 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kinit Description --- It looks to be unused currently, so remove it. Diffs - CMakeLists.txt b5ec044da270bda4536d31e021d11f2a89c838d9 Diff: https://git.reviewboard.kde.org/r/116899/diff/ Testing --- Inspected source. A build test is difficult since some of kinit's dependencies have QtWidgets as a public dependency. Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
