KCompletion and KNotification
Hi, KCompletion now depends on KNotification, I'd suggest to remove that dependency (I can do it myself). At the moment it's generating quite a bit of DBus noise even though it's not being consumed anywhere I could find. It's used both in KHistoryBox and KCompletion. If you want to test it, you can play with KRunner. Additionally, this would make KCompletion tier2. Opinions? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdelibs/frameworks] staging/kdoctools: meinproc5.shell doesn't exist anymore since now it doesn't use kde4_add_executable
On Thu, Sep 5, 2013 at 6:09 PM, David Faure fa...@kde.org wrote: On Thursday 05 September 2013 16:40:48 Stephen Kelly wrote: Aleix Pol wrote: Git commit 25c6f2501ba077ef6f566dac3f12fc766ff5b4ab by Aleix Pol. Committed on 05/09/2013 at 14:36. Pushed by apol into branch 'frameworks'. meinproc5.shell doesn't exist anymore since now it doesn't use kde4_add_executable This reminds me of the KDE4_HANDLE_RPATH_FOR_EXECUTABLE macro in cmake/modules/KDE4Macros. Reading the macro code, I see no 'handling of RPATH' in it, so it looks like it's at least badly named. Instead, it is generating these .shell and .bat files. Does anyone know why? Do we need to keep generating those for any class of executable? I don't think we do anymore. The rpath handling done by ECM (not upstream cmake, unfortunately) makes it all work out of the box (before installation the rpath points to local libs, after installation it points to installed libs). -- 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 Yes, actually what should happen soon is the removal of the kde4_* macros in the KF5 codebase, eventually... No? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: docbook requirements
On Thu, Sep 5, 2013 at 11:32 PM, David Gil Oliva davidgilol...@gmail.comwrote: I answer myself (thanks to the info given by sebas through irc): If it happens to you, please delete the build dir (at least the e-c-m one) update e-c-m and rebuild. Cheers! David Gil 2013/9/5 David Gil Oliva davidgilol...@gmail.com Hi! Today I couldn't compile KF5 with the following message from cmake: -- CMake Warning at staging/kdoctools/src/CMakeLists.txt:27 (find_package): By not providing FindDocBookXML.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by DocBookXML, but CMake did not find one. Could not find a package configuration file provided by DocBookXML with any of the following names: DocBookXMLConfig.cmake docbookxml-config.cmake Add the installation prefix of DocBookXML to CMAKE_PREFIX_PATH or set DocBookXML_DIR to a directory containing one of the above files. If DocBookXML provides a separate development package or SDK, be sure it has been installed. CMake Warning at staging/kdoctools/src/CMakeLists.txt:35 (find_package): By not providing FindDocBookXSL.cmake in CMAKE_MODULE_PATH this project has asked CMake to find a package configuration file provided by DocBookXSL, but CMake did not find one. Could not find a package configuration file provided by DocBookXSL with any of the following names: DocBookXSLConfig.cmake docbookxsl-config.cmake Add the installation prefix of DocBookXSL to CMAKE_PREFIX_PATH or set DocBookXSL_DIR to a directory containing one of the above files. If DocBookXSL provides a separate development package or SDK, be sure it has been installed. And at the end: -- The following REQUIRED packages have not been found: * DocBookXML , DocBook XML , http://www.oasis-open.org/docbook/xml/4.2 Required by the KDE help system to process DocBook XML * DocBookXSL , DocBook XSL , http://docbook.sourceforge.net/release/xsl/current/ Required by the KDE help system to process DocBook XML CMake Error at /home/david/devel/kf5-development/share/cmake-2.8/Modules/FeatureSummary.cmake:430 (message): feature_summary() Error: REQUIRED package(s) are missing, aborting CMake run. Call Stack (most recent call first): CMakeLists.txt:260 (feature_summary) -- Configuring incomplete, errors occurred! See also /home/david/devel/kf5-development/build/kdelibs-frameworks/CMakeFiles/CMakeOutput.log. See also /home/david/devel/kf5-development/build/kdelibs-frameworks/CMakeFiles/CMakeError.log. make: *** [cmake_check_build_system] Error 1 --- I haven't uninstalled anything docbook. What should I do to get KF5 compiled? Thank you! David Gil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel cmake . or make rebuild_cache does the trick as well. cmake's file(GLOB) is not very smart, you need to trigger it again. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dependency specifications
On Tue, Sep 10, 2013 at 7:42 PM, Michael Palimaka kensing...@gentoo.orgwrote: Hi, Currently, the specification for Qt dependencies is not always consistent between tier1 frameworks. In particular, I notice dependencies being specified twice (eg. QtTest in both project root and in autotests), and test dependencies split (eg. QtTest in project root only, and QtXml in autotests only). What is the intended behaviour? All dependencies specified in the project root? Common dependencies specified in the project root, and specific dependencies in directories that require them? Something else? Best regards, Michael __**_ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/**listinfo/kde-frameworks-develhttps://mail.kde.org/mailman/listinfo/kde-frameworks-devel I'd say that all Qt dependencies in the module should be defined only once in the root CMakeLists.txt. Actually this should be the only file with find_package calls. We could try an be stricter, but in practice what is useful for distribution is the find_dependency call in the Config.cmake.in file... Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dependency specifications
On Fri, Sep 13, 2013 at 9:43 AM, David Faure fa...@kde.org wrote: On Thursday 12 September 2013 02:32:20 Aleix Pol wrote: I'd say that all Qt dependencies in the module should be defined only once in the root CMakeLists.txt. Actually this should be the only file with find_package calls. And I disagree. If you build the framework with unittests disabled (like distros will probably do) then there's no point in searching for QtTest. Modularity wins again, better do that inside the autotests subdir. Apart from QtTest, I agree, though. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Well, then let's make this a especial case for autotests/ and tests/. We shouldn't have any find_package() within src/, and that's the case in many places. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dependency specifications
On Fri, Sep 13, 2013 at 1:17 PM, David Faure fa...@kde.org wrote: On Friday 13 September 2013 13:03:29 Aleix Pol wrote: On Fri, Sep 13, 2013 at 9:43 AM, David Faure fa...@kde.org wrote: On Thursday 12 September 2013 02:32:20 Aleix Pol wrote: I'd say that all Qt dependencies in the module should be defined only once in the root CMakeLists.txt. Actually this should be the only file with find_package calls. And I disagree. If you build the framework with unittests disabled (like distros will probably do) then there's no point in searching for QtTest. Modularity wins again, better do that inside the autotests subdir. Apart from QtTest, I agree, though. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Well, then let's make this a especial case for autotests/ and tests/. We shouldn't have any find_package() within src/, and that's the case in many places. Not tests/. That's for manual tests, no qtestlib there. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Well, but in that case you'll maybe want to find QtGui, QtWidgets or KF5::AwesomeTests. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Dependency specifications
On Sat, Sep 14, 2013 at 7:42 PM, Stephen Kelly steve...@gmail.com wrote: Aleix Pol wrote: I'd say that all Qt dependencies in the module should be defined only once in the root CMakeLists.txt. Actually this should be the only file with find_package calls. Why? What is the problem with having a find_package in src? Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Well, it's good to have all the finders in the same place, to have a place where to look when we need to see what a module works on. That's of course debatable, but I'd like to push for this kind of uniformity. Make things as the user/developer would expect them to be. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: ki18n
On Tue, Sep 17, 2013 at 10:55 PM, Treeve Jelbert tre...@scarlet.be wrote: 1. ki18n exists in both tier2 and staging 2. kunitconversion (tier2) depends on ki18n(tier2) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel You were right, just fixed these two problems. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Build failed in Jenkins: kdelibs_frameworks_qt5 #1219
On Wed, Sep 18, 2013 at 5:03 PM, KDE CI System n...@kde.org wrote: See http://build.kde.org/job/kdelibs_frameworks_qt5/1219/changes Changes: [aleixpol] Reorganize KDocTools cmake code [aleixpol] Start adopting QCollator -- [...truncated 3600 lines...] [ 24%] [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/button.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/block.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/keyboard.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/pointingdevice.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/button.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/camera.cpp.o [ 24%] [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/keyboard.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/pointingdevice.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/camera.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/opticaldrive.cpp.o [ 24%] [ 24%] [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/device.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/opticaldrive.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/deviceinterface.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/device.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/deviceinterface.cpp.o [ 24%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/devicemanager.cpp.o [ 24%] [ 25%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/dvbinterface.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/devicemanager.cpp.o [ 25%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/genericinterface.cpp.o [ 26%] [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/networkinterface.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/dvbinterface.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/genericinterface.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/networkinterface.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/networkshare.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/serialinterface.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/opticaldisc.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/networkshare.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/serialinterface.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/opticaldisc.cpp.o [ 26%] [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/portablemediaplayer.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/portablemediaplayer.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/processor.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/processor.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/storagedrive.cpp.o [ 26%] [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/storagevolume.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/storageaccess.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/video.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storagedrive.cpp.o [ 26%] [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/smartcardreader.cpp.o Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storagevolume.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/storageaccess.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/video.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/smartcardreader.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid_static.dir/ifaces/internetgateway.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/ifaces/internetgateway.cpp.o [ 26%] Building CXX object tier1/solid/src/solid/CMakeFiles/Solid.dir/backends/fakehw/fakeacadapter.cpp.o [ 26%] Building CXX object
Re: kde4_add_plugin on KF5
On Thu, Sep 19, 2013 at 6:15 PM, Sebastian Kügler se...@kde.org wrote:
On Thursday, September 19, 2013 18:00:41 Aleix Pol wrote:
Hi,
We should decide what we do with the add_plugin macro. Should I install
it
as kf5_add_plugin from KCoreAddons? Do we want something different or
better?
This is what we're using in Plasma (PlasmaMacros.cmake):
# plasma_add_plugin(pluginname sources_SRC)
#
# Use instead of add_library. Replacement for kde4_add_plugin
# Basically does add_library and removes the prefix of the library
#
# @arg pluginname The name of the plugin,
# @arg sources_SRC The source files to be built
#
# Example:
# plasma_add_plugin(plasma_engine_statusnotifieritem
${statusnotifieritem_engine_SRCS})
#
macro(plasma_add_plugin plugin)
set(plugin_sources ${ARGN} )
add_library(${plugin} MODULE ${plugin_sources} )
set_target_properties(${plugin} PROPERTIES PREFIX )
endmacro()
I would not mind having that available somewhere else.
Cheers,
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Well, I thought of something like that, but I checked and there are
projects using the different arguments that kde4_add_plugin has.
I don't see the point of oversimplifying there.
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kde4_add_plugin on KF5
Hi, We should decide what we do with the add_plugin macro. Should I install it as kf5_add_plugin from KCoreAddons? Do we want something different or better? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Making KDocTools independent of KArchive
On Tue, Sep 24, 2013 at 2:09 PM, Kevin Ottens er...@kde.org wrote: On Tuesday 24 September 2013 13:48:55 Albert Astals Cid wrote: El Dimarts, 24 de setembre de 2013, a les 08:49:20, Kevin Ottens va escriure: On Monday 23 September 2013 13:09:05 Nicolás Alvarez wrote: Maybe we can use a third-party docbook-to-manpage conversion tool. On Linux it would be easy to install, and on Windows it wouldn't be needed (what's a manpage?). And still leave it optional everywhere... Thats a very good question. Maybe in that case kdoctools is indeed overkill. Someone would have to investigate if something else could be used though. That's really weird, we have a solution that works, and you want to use something else? What does that gives us? That stuff in kde now depends in two docbook-to-manpage conversion tools instead of one? Are you sure that's an improvement? Well, as highlighted we have a dependency issue there, so it's either: 1) no docbook in tier 1 and tier 2 frameworks; 2) we use a different docbook to manpage tool for tier 1 and tier 2 frameworks. Pick your poison. But we can't keep said dependency issue. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks 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 Maybe we can bundle the generated documentation? I think we're making it more of a problem than actually is... Maybe the problem here is considering kdoctools as a framework instead of a tool set. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Wed, Sep 25, 2013 at 6:52 PM, Nicolás Alvarez
nicolas.alva...@gmail.comwrote:
2013/9/25 Aurélien Gâteau agat...@kde.org:
The alternative syntax: ${KConfigCore_LIBRARIES} would work in both
cases, but
it is more error prone: any typo in the variable name causes the
variable to
be expanded to an empty string, making it more difficult to debug,
whereas
using target names provide more explicit error messages.
Have you tried using cmake --warn-uninitialized?
--
Nicolás
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
It's not really an alternative, it becomes far too verbose.
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: Reminder: use KF5::foo instead of ${foo_LIBRARIES} in CMakeLists
On Thu, Sep 26, 2013 at 5:10 AM, David Edmundson da...@davidedmundson.co.uk wrote: Is there anything preventing us from using the ALIAS target right now? It's in the git version. The build guide say to get cmake from git. kdesrc-build gets it from git, and build.kde.org uses git latest. I just set KWindowSystem to have an alias and tried building knotifications. It worked beautifully, http://paste.kde.org/pde423295 Both full kdelibs built as well as knotifiications standalone, which previously failed. It even helped me find a missing find_package(!) that would have otherwise gone unnoticed till we split, which would have a been a real nuisance. Doing this will allow us to make sure each tierN module actually builds standalone, and saves us having to set all the lib names twice if we are porting to KF5::LibName eventually. Downside is people using old cmake will need to sort themselves out and upgrade. (including project-neon-5) David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Well, it's a bit of a burden to depend on git versions of cmake, that's why it's not being used so far. Personally, my plan was to do all the splitting now and then think about building things separately once everything is split. I see that it's annoying for you to work like that, so I don't have a problem with using newer cmake versions and get rid of this problem once and for all. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
[Review Request] Modularizing KF5
Hi, Since ReviewBoard is not working for me, I decided to send this review as an e-mail. I know it's less practical, but also I think it's important to get it done and I'd rather go reasonably fast with it before we start getting too much conflicts. This patch removes all find_package usages in the root CMakeLists.txt file (not the includes, only find_package) and moves it to every different module or unsplitted folder. You can review the changes in the kf5_find_package branch in kdelibs. Thanks! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [Review Request] Modularizing KF5
On Wed, Oct 2, 2013 at 10:25 AM, Stephen Kelly steve...@gmail.com wrote:
Aurélien Gâteau wrote:
On Tuesday 01 October 2013 19:28:04 Aleix Pol wrote:
Hi,
Since ReviewBoard is not working for me, I decided to send this review
as
an e-mail. I know it's less practical, but also I think it's important
to
get it done and I'd rather go reasonably fast with it before we start
getting too much conflicts.
I for one a big reviewboard non-fan. I much prefer reviewing patches in
email or outside git remotes.
This patch removes all find_package usages in the root CMakeLists.txt
file (not the includes, only find_package) and moves it to every
different module or unsplitted folder.
ENOPATCH :)
He pushed a branch to the kdelibs.git repo, which is unfortunate. There's
so
many dead branches in there, you'd be forgiven for not noticing. I wish it
only was allowed to contain branches which contain releases and master. All
of these 'personal work branches' should be in other remotes.
Anyway, Aleix, it looks like a lot of the use of macro_bool_to_01 is
obsolete.
All configure_file uses of HAVE_X11 seem to already use #cmakedefine01.
git grep -e HAVE_X11 --and -e cmakedefine
Replace the use of macro_bool_to_01 with set() first in a separate patch.
set(HAVE_X11 ${X11_FOUND})
Why did you comment the HAVE_QSSLSOCKET check?
Thanks,
Steve.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
I pushed a couple of new commits that remove the usage of macro_bool_to_01
and the HAVE_QSSLSOCKET thing.
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Switch build.kde.org to Qt stable branch
On Wed, Oct 2, 2013 at 7:53 PM, Nicolás Alvarez nicolas.alva...@gmail.comwrote: As you may know, Qt is working to release 5.2. The dev branch has been merged to the stable branch, which means the stable branch is now 5.2, and dev is now 5.3. build.kde.org is compiling Qt from source, but it's using the dev branch. As far as I know, the plan is to release KF5 depending on Qt 5.2. I propose switching build.kde.org to the 'stable' Qt branch to ensure we don't accidentally depend on 5.3 features. -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Sounds like a good idea to me! +1 Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Reduce warnings noise when including wtf/Platform.h in KJS
On Tue, Oct 8, 2013 at 3:50 PM, Stephen Kelly steve...@gmail.com wrote: Stephen Kelly wrote: These are defined with 1 if acceptable and undefined if the feature is not present. This is the problem that should be fixed. It should be 0 if the feature is not present. Please fix that instead. Hmm, or maybe your fix is ok. I don't know where the values come from, but there seems to be a code smell somewhere... Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel If you take a look at the code, you'll see that it's what the original author meant. I thought about adding all the alternatives, but I don't think it would make sense, especially given they are meant to be checked through the macros. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kf5_add_kdeinit_executable broken?
On Tue, Oct 8, 2013 at 2:28 PM, Sebastian Kügler se...@kde.org wrote: Hi, in Kwin (kde-workspace) we're running into the following error: CMake Error: File /home/sebas/kf5/src/kde- workspace/kwin/kcmkwin/kwinrules/_KDE5INIT_DUMMY_FILEPATH-NOTFOUND does not exist. CMake Error at /home/sebas/kf5/install/lib64/cmake/KInit/KInitMacros.cmake:17 (configure_file): configure_file Problem configuring file Call Stack (most recent call first): kwin/kcmkwin/kwinrules/CMakeLists.txt:12 (kf5_add_kdeinit_executable) CMake Error at kwin/kcmkwin/kwinrules/CMakeLists.txt:32 (target_link_libraries): Cannot specify link libraries for target kdeinit_kwin_rules_dialog which is not built by this project. -- Configuring incomplete, errors occurred! This cropped up after KInit splitting. Any ideas? Thanks, -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I'm on it.. building kde-workspace Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: update your cmake!
On Fri, Oct 11, 2013 at 2:43 AM, Stephen Kelly steve...@gmail.com wrote: Aurélien Gâteau wrote: On Thursday 10 October 2013 15:17:12 Sebastian Kügler wrote: Hi, In order to build KF5 and Plasma2 code, you have to update your cmake to 2.8.12. Otherwise, you'll get build errors. Oh... this means we can now make use of ALIAS targets and build truly standalone frameworks \o/ I have a way to script that, but it can't be done yet. First decide if the feature-use which requires 2.8.12 is a mistake or not. If not, then update the version requirement in the code. Then I can run my script. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I think we already agreed on depending on 2.8.12. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: build.kde.org: Failing ktoolbar_unittest
On Fri, Oct 11, 2013 at 6:31 PM, Kevin Ottens er...@kde.org wrote: Hello, ktoolbar_unittest segfaults in the CI. I tried to reproduce the error here with no luck so far. If someone who manages to reproduce it or who has access to build.kde.org shell could look into it that would be nice. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks 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 Should be fixed now. It was a bit tricky to reproduce (here it happened randomly), it was easily spotted by using valgrind. Cheers! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Bring kdewin back?
On Mon, Oct 14, 2013 at 11:42 PM, Nicolás Alvarez nicolas.alva...@gmail.com wrote: Hi, While trying to get KDE Frameworks to build on Windows, I found the codebase of KDirWatch is full of Unixisms. I did a few improvements towards getting it to build on Windows, but I'm now getting several errors related to the lack of symbolic links (such as no lstat). It's clear this code couldn't have possibly worked on Windows directly, and the only way it ever worked is through the use of kdewin to provide Unix-like compatibility headers. Other libraries have similar problems. It seems to me that someone removed the dependency on kdewin without making the code actually work without it. Why was it removed? Where can I find the discussion about it, if there was any? If the intention is getting rid of the kdewin dependency, can we *temporarily* bring it back to get things to work again, and then remove it *progressively* as things get fixed? -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Nicolás, It's good to know that there's somebody out there taking care of kf5 on windows. I'm unsure of what to say, though. Maybe you can come up with a list of issues so that we can fix them? At least some output log could be useful... We'll be working on making the different frameworks compilable separately soon enough (actually this should already be the case, although I've seen problems coming up), maybe it will be easier then to try to compile them one by one and come up with something easier to digest. There are things in kdelibs/frameworks that are of no use on windows (thinking of frameworksintegration, for example). Hope this helps :) Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Porting away from KLocale
Hi, I was trying to port some application to Qt/KF5, then I realized that I didn't know how to port KLocale::formatByteSize. I don't see anything in QLocale for this, so I feel a bit stuck. Also I don't see any information in KDE5Porting.html Anybody has an idea of what's the solution? Thanks! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: CMake fails configuring KF5
On Thu, Oct 17, 2013 at 6:59 AM, David Gil Oliva davidgilol...@gmail.comwrote: Hi! I'm getting this error from CMake while building KF5: -- Found KF5: /home/david/devel/kf5-development/share/ECM/find-modules/FindKF5.cmake (found suitable version 5.0.0, minimum required is 5.0.0) found components: CMake Compiler InstallDirs CMake Error at /home/david/devel/kf5-development/qt5/qtbase/lib/cmake/Qt5/Qt5Config.cmake:26 (find_package): Could not find a package configuration file provided by Qt5X11Extras with any of the following names: Qt5X11ExtrasConfig.cmake qt5x11extras-config.cmake Add the installation prefix of Qt5X11Extras to CMAKE_PREFIX_PATH or set Qt5X11Extras_DIR to a directory containing one of the above files. If Qt5X11Extras provides a separate development package or SDK, be sure it has been installed. Call Stack (most recent call first): tier1/kidletime/CMakeLists.txt:15 (find_package) -- Configuring incomplete, errors occurred! Anyone can tell me why could this be happening? Maybe is Qt5 not well built or is something KF5-only related? :-/ Thanks in advance David Gil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Well, is Qt5X11Extras installed? :) Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Compile kdelibs-frameworks without tests
On Thu, Oct 17, 2013 at 8:23 AM, Bhushan Shah bhus...@gmail.com wrote: Hello! I want to compile kde library without building tests or auto tests. Reason behind this is I want to speed up compiling process.. Martin Gräßlin suggested me to use -DKDE4_BUILD_TESTS=FALSE -DBUILD_TESTING=FALSE cmake options but this options are not working, with this option cmake fails to run. Are they removed or changed in KF5? This options are working as expected with KDE/4.11 branch. But not with frameworks. Any reason or method to disable tests? Thanks! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, You want to have BUILD_TESTING disabled, it should be enough. Without more information I can't really tell. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Forward includes
Hi, I realized recently that we have a weird setup for those CamelCased includes that now we keep in kdelibs/includes, so I was guessing that probably we want to split them and move them into each directory. Also we should decide if we want to keep them in KDE/ or in a KModule/ directory and point to it from the Config.cmake files. What do you guys think? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kdelibs/frameworks] staging/kio/src/core: Add include/KDE to users of KIOCore.
On Mon, Oct 21, 2013 at 2:54 PM, Stephen Kelly steve...@gmail.com wrote:
Git commit 5e9404239fb974973e8a253444131884954ede77 by Stephen Kelly.
Committed on 21/10/2013 at 12:49.
Pushed by skelly into branch 'frameworks'.
Add include/KDE to users of KIOCore.
Note that this really only hides the problem. There are several problems
with the KF5 includes, and several patches in review which also don't
fully solve the problem.
What is needed is to figure out
* Where are headers installed to?
* How are users supposed to use them?
* What include paths do users need to use?
For example, if kfoo installs
include/kfoo/job.h
include/kfoo/kfoo_export.h
and users are supposed to use:
.#include kfoo/job.h
but job.h #includes kfoo_export.h
then users need both
include/
include/kfoo/
when compiling. That seems to be the case at some points in KDE
frameworks, and it is more-likely accidental than intentional.
That should be reviewed.
CCMAIL: kde-frameworks-devel@kde.org
M +1-0staging/kio/src/core/CMakeLists.txt
http://commits.kde.org/kdelibs/5e9404239fb974973e8a253444131884954ede77
diff --git a/staging/kio/src/core/CMakeLists.txt
b/staging/kio/src/core/CMakeLists.txt
index 273086f..03a892b 100644
--- a/staging/kio/src/core/CMakeLists.txt
+++ b/staging/kio/src/core/CMakeLists.txt
@@ -108,6 +108,7 @@ target_include_directories(KIOCore PUBLIC
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/.. # kio_version.h
$BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR}/kssl
$BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}/../include #
kio/global.h
+ $INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR}/KDE # KIO/Job
)
target_link_libraries(KIOCore
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
FWIW, KDE/ should be added to most modules then...
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forward includes
On Mon, Oct 21, 2013 at 11:39 AM, Kevin Ottens er...@kde.org wrote: Hello, On Friday 18 October 2013 20:24:00 Aleix Pol wrote: I realized recently that we have a weird setup for those CamelCased includes that now we keep in kdelibs/includes, so I was guessing that probably we want to split them and move them into each directory. I think we want those installed as is by kde4support, because they're here for existing code to still compile (we got KDE/foo includes in our codebase). Also we should decide if we want to keep them in KDE/ or in a KModule/ directory and point to it from the Config.cmake files. IIRC the last time this topic was discussed I think we were leaning toward a KF5/Module/ directory. And yes the Config.cmake files should point to it IMO. What do you guys think? The above is pretty much it on my side, but I'd like to add something: We should get those forwarding includes generated to not have to maintain them by hand anymore. Since we had to do some header generation in some of the frameworks to get them to comply with the standard directory layout, it looks like something we could get cmake to do. Regards. -- Kévin Ottens, http://ervin.ipsquad.net Sponsored by KDAB to work on KDE Frameworks 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 Ok, works for me, consider it as an assigned task. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forward includes
On Tue, Oct 22, 2013 at 11:06 AM, Ivan Čukić ivan.cu...@kde.org wrote: The above is pretty much it on my side, but I'd like to add something: We should get those forwarding includes generated to not have to maintain Lets bring this topic back from the dead. I don't have a real preference between include/Module, include/KDE/Module and include/KF5/Module. Main benefit of include/KF5/Module is the fact that the users will be able to have different non-ABI/API-compatible versions of KF installed at the same time, if this is needed at all. As for pointing the cmake configs to that path, it might be tricky to achieve in all libraries. Namely those that rely on namespaces instead of prefixing the names of classes with K or KSomething. For example, while #includeKJob can work without collisions, it can not for libraries like Solid (classes named Camera, Video, Button - needs to be #includeSolid/Camera etc.) or KActivities (Controller, Info - #includeKActivities/Info etc.) Cheers, Ivan -- The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana. -- Joe Armstrong ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I'll be sending a review soon, we can discuss it further over some code :). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting away from KLocale
On Tue, Oct 22, 2013 at 2:03 PM, David Faure fa...@kde.org wrote: On Thursday 17 October 2013 23:47:40 Aleix Pol wrote: Well maybe I could help with this, but I'd need to know what do you think it would be the most appropriate solution. I'd say, split it out into a separate function for KF5, and later on, if you feel like it, contribute it to Qt for 5.3. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 I created a task for it on the kdelibs cleanups [1] so anybody can pick it up. Aleix [1] http://community.kde.org/Frameworks/Epics/kdelibs_cleanups ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: List of Frameworks
On Sun, Nov 10, 2013 at 9:58 PM, Dominik Haumann dhaum...@kde.org wrote: Hi, currently, http://community.kde.org/Frameworks/Epics/Modularization shows a list of modules in the respective Tiers. It does not, however, show whether it's functional, integration or a solution. Imo if would be good to have this as column, too. Since then a quick look allows us (for instate for KTextEditor/Kate Part) to find where we will finally end, depending on what actions/decisions we make. Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel You can find it here, somewhat: http://community.kde.org/Frameworks/Epics/Splitting_kdelibs Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Fwd: RFC Rules for installation of header files
On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau agat...@kde.org wrote:
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in the
end two different things even though related.
I think, that for all the frameworks, headers should be installed in:
$PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers should
be installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are added
in the include path, thus supporting the #include kfoo.h and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to have
$PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for
#include FrameworkName/kfoo.h and #include FrameworkName/KFoo.
Do we want to support this as well? (I have no strong opinion on this
topic)
ecm_generate_headers will do it like that anyway
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they should
be installed in include/{lowercaseframework} and convenience headers
should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting the
#include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be the
first files you meet if you wander in $PREFIX/include/KF5 IMO.
They should probably be in frameworkname/frameworkname_export.h. Usually we
have 2 folders for includes, the camel case for camel case includes and the
lowercase one with the actual includes.
I think it departs quite a bit from your initial proposal, making it
slightly more complicated on the include path side, but it has pros
like:
* making it more homogeneous on the installation side;
* allows co-installability of major releases in the future.
Opinions?
Works for me, just tell me your preference on the two points I
mentionned above.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Fwd: RFC Rules for installation of header files
On 14.11.2013 18:31, Aleix Pol wrote:
On Thu, Nov 14, 2013 at 5:04 PM, Aurélien Gâteau agat...@kde.org
[3]
wrote:
On 10.11.2013 18:27, Kevin Ottens wrote:
Hello,
On Wednesday 06 November 2013 08:52:29 Aurélien Gâteau wrote:
Yesterday frameworks meeting spawned a discussion regarding
folders
in header files.
I think there's an aspect missing in your proposal. There's the
convention we want for #include and where we install. That's in the
end two different things even though related.
I think, that for all the frameworks, headers should be installed
in: $PREFIX/include/KF5/FrameworkName/
FrameworkName would then contain both the regular .h headers and
the
convenience camel case ones. If we go for that, we get something
consistent install wise and easy to deal with. Then the distinction
you make below is just about the include path we want when someone
pulls a framework in.
I think the consensus is there should be two different situations:
1. 'k' prefixed header files
If the header files of a framework are prefixed with a 'k', then
headers should be installed in include and convenience headers
should be installed in include/KDE.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then both
$PREFIX/include/KF5/ and $PREFIX/include/KF5/FrameworkName/ are
added in the include path, thus supporting the #include kfoo.h
and
#include KFoo styles.
To support #include kfoo.h and #include KFoo you only need to
have $PREFIX/include/KF5/FrameworkName/ in the include path. Adding
$PREFIX/include/KF5/ would add support for #include
FrameworkName/kfoo.h and #include FrameworkName/KFoo.
Do we want to support this as well? (I have no strong opinion on
this
topic)
ecm_generate_headers will do it like that anyway
Mmm, this is not about installation path, but about the include path.
Does ecm_generate_headers affects the include path?
2. Non-prefixed header files
If the header files of a framework are not prefixed, then they
should be installed in include/{lowercaseframework} and
convenience
headers should be installed in include/KDE/{CamelCaseFramework}.
I think in a case like that we still want the includes installed in
$PREFIX/include/KF5/FrameworkName/ (convenience or not). But when
someone pulls the framework as a dependency then only
$PREFIX/include/KF5/ is added in the include path, thus supporting
the #include FrameworkName/foo.h and #include FrameworkName/Foo
styles.
Some special files should still go in include:
{lowercaseframework}_export.h {lowercaseframework}_version.h
Make that $PREFIX/include/KF5/ instead of just include and I agree.
Wouldn't it be more self-contained to have those in
$PREFIX/include/KF5/FrameworkName as well?
After all, those includes are mostly internal, so they should not be
the first files you meet if you wander in $PREFIX/include/KF5 IMO.
They should probably be in frameworkname/frameworkname_export.h.
Usually we have 2 folders for includes, the camel case for camel case
includes and the lowercase one with the actual includes.
Unless I am confused, Kevin proposal is to have only one folder:
$PREFIX/include/KF5/$Framework. This folder would contain both lower
case and camel case header files.
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kdoctools
On Fri, Nov 15, 2013 at 10:12 AM, Treeve Jelbert tre...@scarlet.be wrote: I build all of kf5 as standalone modules kdoctools is now required when building kdewidgets, but the build fails FAILED: cd /usr/src/kdewidgets-5.x/build/docs/makekdewidgets /opt/qt5/bin/meinproc5 --stylesheet /opt/qt5/share/ksgmltools2/customization/kde-include-man.xsl --check /var/git/kde5libs/kdewidgets/docs/makekdewidgets/man-makekdewidgets.1.docbook man-makekdewidgets.1.docbook:5: warning: failed to load external entity dtd/kdex.dtd ] kdoctools installs files to /opt/qt5/share/ksgmltools2/customization whereas kdelibs4 uses /opt/qt4/share/apps/ksgmltools2/customization is the problem due to the extra apps directory? is it possible to make the dependency on kdoctools optional? ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I wouldn't make the dependency on KDocTools optional, the advantage would be that then things are less tested. Documentation needs some love too anyway. The problem you're having is because meinproc uses QStandardPaths, requiring you to have XDG_* variables defined, especially XDG_DATA_DIRS. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Wrapping up about KI18n and UIC
Hi, I have been going through the list looking for what we should we do when it comes to .ui file generation and i18n. I see that Stephen Kelly has been doing some work on Qt and cmake to make it possible to integrate these properly, but also those changes will get in cmake 3 and Qt 5.3 which are not among our dependencies. I'd suggest to revive jeremy's patch and adapting it to KF5 [1], I could help with that, but I'd like to know first if we agree that it's the best solution he have at the moment. When we get to all the features offered by Kelly's patches, we can just reduce the amount of code that it's calling and even deprecate it. Aleix [1] http://git.reviewboard.kde.org/r/112785/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: RFC Rules for installation of header files
On Fri, Nov 15, 2013 at 5:24 PM, Aurélien Gâteau agat...@kde.org wrote:
On Thu, 14 Nov 2013 17:55:42 +0100, Kevin Ottens wrote:
On Thursday 14 November 2013 18:40:04 Aurélien Gâteau wrote:
Looks like we have an agreement then. Let me recap:
# Installation dir
All header files are installed in $PREFIX/include/KF5/$Framework.
This includes 'k' prefixed headers like kfoo and KFoo,
I assume you meant kfoo.h here.
non-prefixed headers such as bar.h and Bar, as well as special headers
such as ${framework}_export.h and ${framework}_version.h.
# Include path
For 'k' prefixed headers, include path is
$PREFIX/include/KF5/$Framework.
For non-prefixed headers, include path is $PREFIX/include/KF5.
Is this correct?
Looks correct to me.
David pointed out on IRC this scheme would need a significant change for
frameworks like KIO or Solid: includes to kio/foo.h would need to be
changed to KIO/foo.h, same with solid/* includes. Are you fine with
this?
Aurélien
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
I think that we're making this too complex. I'd say that it should always
be prefixed, then the module can decide to export the module directory as
well.
Not mixing headers from different frameworks in a same directory sounds
like a good feature as well.
Also I'd say that clearly there's a differentiation between camelcase and
lowercase. IMHO:
good:
#include kio/job.h
#include Solid/Device
weird:
#include Solid/device.h
Aleix
PS: I would stop adding even more things to kde4support if it's not
extremely needed, it's crowded already.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Wrapping up about KI18n and UIC
On Mon, Nov 18, 2013 at 12:50 PM, Stephen Kelly steve...@gmail.com wrote: Kevin Ottens wrote: 10% chance? 50%? 80%? Basically what's the time frame for CMake 3. I'll be 90% surprised if it is not released in January, or maybe February. Thanks, Steve. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel So would it be that bad to have a macro of ours that ends up being just a wrapper to qt5_wrap_ui? Otherwise, this delays the possibility to help the ongoing porting process by extending a mandatory dependency on KDE4Support. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Wrapping up about KI18n and UIC
On Mon, Nov 18, 2013 at 4:17 PM, Kevin Ottens er...@kde.org wrote: On Monday 18 November 2013 13:27:19 Aleix Pol wrote: So would it be that bad to have a macro of ours that ends up being just a wrapper to qt5_wrap_ui? Otherwise, this delays the possibility to help the ongoing porting process by extending a mandatory dependency on KDE4Support. Right, we need to cater to that need too. Since that's tied to ki18n use, what about putting that wrapper macro in ki18n for the time being? Of course it should be removed when we get a proper fix via CMake 3 around. But in the meantime it'll do the trick and allow removing dependencies on KDE4Support just for that. Cheers. -- 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 +1 Then I suggest to let this go in: https://git.reviewboard.kde.org/r/112785/diff/#index_header Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Wrapping up about KI18n and UIC
On Mon, Nov 18, 2013 at 9:10 PM, Chusslove Illich caslav.i...@gmx.netwrote: [: Kevin Ottens :] Of course it should be removed when we get a proper fix via CMake 3 around. But in the meantime it'll do the trick and allow removing dependencies on KDE4Support just for that. [: Aleix Pol :] +1 Then I suggest to let this go in: https://git.reviewboard.kde.org/r/112785/diff/#index_header I don't see much point in that. To simply go on with the things, as I suggested, just replace every kde4_add_ui_files with qt5_wrap_ui. Later all these calls must be revisited anyway, to set translation domain and semantic markup flag. This holds either way; and with Stephen's solution, on revisiting only some new lines would be added, and qt5_wrap_ui calls left as they are. Alternatively, if one worries that with this things might be forgotten later (as Jeremy did originally), then just add KI18NMacros.cmake with a three- line ki18n_wrap_ui macro that passes the files to qt_wrap_ui. -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel That's not true. If you use qt5_wrap_ui nothing compiles because most of our code will expect KLocalizedString to be included. I don't think adding the includes is a good fix. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: error: KF5::KDBusAddons-NOTFOUND
On Tue, Nov 19, 2013 at 4:32 PM, Sebastian Kügler se...@kde.org wrote: On Tuesday, November 19, 2013 15:42:47 Sebastian Kügler wrote: On Tuesday, November 19, 2013 12:48:53 Stephen Kelly wrote: Try to construct a trivial testcase using one of the targets. If that fails, post it. If it passes, bisect the difference to kactivities. I've attached a bare example, that also fails here, with error from $subject. I've found the problem leading to this. When I run cmake / make / make install from the top-level kdelibs directory, the -relwithdebinfo.cmake Target files are not installed. When I re-run make install from, for example within tier2/ki18n, the KI18nTargets-relwithdebinfo.cmake gets installed, and is subsequently found. Same for KDBusAddons, and all other frameworks, as far as I can tell. When re-running make install, I get this file (for example) installed, which is what I seemed to be missing. /home/sebas/kf5/install/lib64/cmake/KI18n/KI18nTargets-relwithdebinfo.cmake Any idea how this can happen? -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Maybe you have different CMAKE_BUILD_TYPE in kdelibs and other build directories? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Using KCompressionDevice with QSaveFile
On Mon, Dec 2, 2013 at 10:31 PM, Dominik Haumann dhaum...@kde.org wrote:
Hi,
porting KSaveFile to QSaveFile, I stumbled into the following:
// This method has been made private so that it cannot be called,
// in order to prevent mistakes.
void QSaveFile::close()
{
qFatal(QSaveFile::close called);
}
In Kate, we use a QSaveFile saveFile(...); and then use
KCompressionDevice compDevice(saveFile, ...);
to write compressed data through compDevice into saveFile.
However, KCompressionDevice at some point always seems to call close(),
which
hits the qFatal().
Should I derive from QSaveFile and overwrite close() to call commit() ?
Am I missing something here?
Greetings,
Dominik
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Looks to me like it's either a bug on KCompressionDevice or QSaveFile.
Personally, I think it's rather odd that some public API call invariably
crashes (it's made private in QSaveFile, but it's still public on the
parent, so it's not very useful).
I'd say that this fix should go to Qt, but David will probably have a
better insight.
Mr Faure? :D
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Forcing Q_SLOTS on non frameworks code
On Sat, Dec 14, 2013 at 3:58 PM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 14 de desembre de 2013, a les 14:30:14, Kevin Ottens va escriure: On Saturday 14 December 2013 13:55:50 Albert Astals Cid wrote: Hi there, so here I am at the KF5 porting sprint at Barcelona trying to port libkdegames and I am realizing that I can not use code like private slots: anymore. I understand that for frameworks libraries it is interesting to have -DQT_NO_SIGNALS_SLOTS_KEYWORDS defined so we end up with code that is as widely includable from anywhere, but forcing that to the rest of the world is a bit too much if you ask me. I don't think that was intended. Can we somehow make it so that people using frameworks are not forced to add a remove_definitions so they get their code compiling? Definitely need to be fixed... we need to find what ends up activating it for everyone. I would guess you get the same thing for the implicit ascii casts? That would not be intended either. Yep, it's the same, I'll have a look to see where they come from. Cheers, Albert Regards. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel We should have a KDEFrameworkCompilerSettings.cmake file in extra-cmake-modules/kde-modules, that will have the settings we want for frameworks exclusively, then we'll have to include it from all frameworks. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where's kf5_add_ui_files ?
On Mon, Dec 16, 2013 at 10:35 PM, Chusslove Illich caslav.i...@gmx.netwrote: [: Albert Astals Cid :] This works. And it actually looks like things done in some other modules, so I committed it. Thanks for the checks. -- Chusslove Illich (Часлав Илић) ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel FWIW, how could this have worked before? :/ Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting 2013-w51 Reminder
On Tue, Dec 17, 2013 at 2:30 AM, Àlex Fiestas afies...@kde.org wrote: Hi there ! Since nobody said anything against it, let's have the last meeting of the year, as always it will happen on #kde-devel today (Tuesday) at 4pm Barcelona (CET / UTC+1) time. If you want me to do any announcement today in the meeting just when the meeting starts either send it as a reply here, or contact me in any way. See you there. Cheers ! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Look like Ben will have some announcement... ^^ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: migration KIcon to QIcon
On Mon, Dec 16, 2013 at 5:18 PM, Michal Humpula michal.hump...@seznam.czwrote: Hi there, have a small glitch with icon loading on frameworks. If I understand correctly, the migration path for KIcon is QIcon::fromTheme, right? Unfortunately this is giving me empty results, which might be caused by QIcon::themeName() giving me empty string. If I configure the theme manually, i.e. by calling QIcon::setThemeName(oxygen), everything works fine, icons are displayed again. The kcmshell5 icons is showing me the selected oxygen icons, though. Any idea what my be missing/misconfigured in my installation? frameworks: latest git Qt: v5.2 system: Debian unstable Cheers Michal ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Maybe you should make sure the correct QPA is called? If it is, we should probably do the setThemeName from the QPA You can find the code in tier4/frameworksintegration. Also, make sure all environment variables are set, especially KDE_FULL_SESSION=true. Cheers! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Macro naming
On Mon, Dec 23, 2013 at 1:17 AM, Alex Merry k...@randomguy3.me.uk wrote: Currently, we are not consistent about CMake macro naming in the frameworks. KAuth, for example, has kauth_install_actions, while kdesignerplugin has kf5designerplugin_add_widget_files. How do we want our macros prefixed? Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I would say that we want modulename_macroname. It's what we have in most places I'd say. I don't think it's a good idea using kf5* since it doesn't explain where it comes from. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Tue, Dec 24, 2013 at 12:14 PM, Alex Merry k...@randomguy3.me.uk wrote: On 24/12/13 07:38, Friedrich W. H. Kossebau wrote: Hi, what are the plans with offering CamelCase includes in KF5 (e.g. #include KLocale)? On a quick search could not find anything mentioned somewhere. If I saw correctly, then currently CamelCase includes (for existing classes) are only available by KF5::KDE4Support, due to being the module which has those files and also installs them. Also the KF5/KDE seems somehow (not yet found out how) only added to the include dirs by listing that module in target_link_libraries. Is that also the long-term plan? (I hope not, because I like the CamelCase includes, and other people who use Qt with CamelCase includes, as offered, and want to use some KF5 modules would welcome to have them, too). Would be willing to help out with this. There were plans to auto-generate them. I'm not sure what happened with that. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel We need to use ecm_generate_headers on every module. I'll try to take some time after the 26th to do it. If somebody wants to do it meanwhile, please do and I'll review it. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Forward includes
Hi, I've been going through the kde4support forward includes, since I wanted to start making the modules I decided we'd better make sure all of them are working properly. After some research, I found that I don't have these available, can somebody please tell me if I'm missing some dependency or if these are indeed not available [1]? If there's no problem with this, I'll proceed to change these for a warning that they're not available anymore (see attachment). Cheers! Aleix PS: Happy holidays! [1] KAuth/ActionWatcher KCalendarSystemFactory KConfigINIBackEnd KCrashBookmarkImporter KCrashBookmarkImporterImpl KDateTable KDateValidator KDBusServiceStarter KDNSSD/Configuration KFileSharePropsPlugin KFileTreeBranch KFileTreeView KIdentityProxyModel KIMProxy KIO/Connection KIO/SessionData KIO/Task KMimeTypeResolver KNS/Author KNS/Category KNS/Engine KNS/Installation KNS/KTranslatable KParts/DockMainWindow3 KPixmapRegionSelectorDialog KSMIMECrypto KSystemEventFilter KTimeZoneWidget KUnitTest/Runner KUnitTest/SlotTester KUnitTest/Tester KUnitTest/TestResults ThreadWeaver/JobCollection ThreadWeaver/JobSequence ThreadWeaver/WeaverObserver diff --git a/src/includes/KAuth/ActionWatcher b/src/includes/KAuth/ActionWatcher index 36a503d..e868dfc 100644 --- a/src/includes/KAuth/ActionWatcher +++ b/src/includes/KAuth/ActionWatcher @@ -1 +1 @@ -#include ../../kauthactionwatcher.h +#warning This file is not available anymore diff --git a/src/includes/KCalendarSystemFactory b/src/includes/KCalendarSystemFactory index 3ab6d1d..e868dfc 100644 --- a/src/includes/KCalendarSystemFactory +++ b/src/includes/KCalendarSystemFactory @@ -1 +1 @@ -#include ../kcalendarsystemfactory.h +#warning This file is not available anymore diff --git a/src/includes/KConfigINIBackEnd b/src/includes/KConfigINIBackEnd index 5e607af..e868dfc 100644 --- a/src/includes/KConfigINIBackEnd +++ b/src/includes/KConfigINIBackEnd @@ -1 +1 @@ -#include ../kconfigini.h +#warning This file is not available anymore diff --git a/src/includes/KCrashBookmarkImporter b/src/includes/KCrashBookmarkImporter index 1128400..e868dfc 100644 --- a/src/includes/KCrashBookmarkImporter +++ b/src/includes/KCrashBookmarkImporter @@ -1 +1 @@ -#include ../kbookmarkimporter_crash.h +#warning This file is not available anymore diff --git a/src/includes/KCrashBookmarkImporterImpl b/src/includes/KCrashBookmarkImporterImpl index 1128400..e868dfc 100644 --- a/src/includes/KCrashBookmarkImporterImpl +++ b/src/includes/KCrashBookmarkImporterImpl @@ -1 +1 @@ -#include ../kbookmarkimporter_crash.h +#warning This file is not available anymore diff --git a/src/includes/KDBusServiceStarter b/src/includes/KDBusServiceStarter index 7eb6fa6..e868dfc 100644 --- a/src/includes/KDBusServiceStarter +++ b/src/includes/KDBusServiceStarter @@ -1 +1 @@ -#include ../kdbusservicestarter.h +#warning This file is not available anymore diff --git a/src/includes/KDNSSD/Configuration b/src/includes/KDNSSD/Configuration index c568305..e868dfc 100644 --- a/src/includes/KDNSSD/Configuration +++ b/src/includes/KDNSSD/Configuration @@ -1 +1 @@ -#include ../../kdnssd/settings.h +#warning This file is not available anymore diff --git a/src/includes/KDateTable b/src/includes/KDateTable index 08c8315..e868dfc 100644 --- a/src/includes/KDateTable +++ b/src/includes/KDateTable @@ -1 +1 @@ -#include ../kdatetable.h +#warning This file is not available anymore diff --git a/src/includes/KDateValidator b/src/includes/KDateValidator index 08c8315..e868dfc 100644 --- a/src/includes/KDateValidator +++ b/src/includes/KDateValidator @@ -1 +1 @@ -#include ../kdatetable.h +#warning This file is not available anymore diff --git a/src/includes/KFileSharePropsPlugin b/src/includes/KFileSharePropsPlugin index aefd8d2..e868dfc 100644 --- a/src/includes/KFileSharePropsPlugin +++ b/src/includes/KFileSharePropsPlugin @@ -1 +1 @@ -#include ../kfilesharedialog.h +#warning This file is not available anymore diff --git a/src/includes/KFileTreeBranch b/src/includes/KFileTreeBranch index dda7372..e868dfc 100644 --- a/src/includes/KFileTreeBranch +++ b/src/includes/KFileTreeBranch @@ -1 +1 @@ -#include ../kfiletreebranch.h +#warning This file is not available anymore diff --git a/src/includes/KFileTreeView b/src/includes/KFileTreeView index a3bb394..e868dfc 100644 --- a/src/includes/KFileTreeView +++ b/src/includes/KFileTreeView @@ -1 +1 @@ -#include ../kfiletreeview.h +#warning This file is not available anymore diff --git a/src/includes/KIMProxy b/src/includes/KIMProxy index f092060..e868dfc 100644 --- a/src/includes/KIMProxy +++ b/src/includes/KIMProxy @@ -1 +1 @@ -#include ../kimproxy.h +#warning This file is not available anymore diff --git a/src/includes/KIO/Connection b/src/includes/KIO/Connection index 17de1fd..e868dfc 100644 --- a/src/includes/KIO/Connection +++ b/src/includes/KIO/Connection @@ -1 +1 @@ -#include ../../kio/connection.h +#warning This file is not available anymore diff --git a/src/includes/KIO/SessionData
KCoreAddons forward headers
Hi,
Here's a patch adding CamelCase headers to KCoreAddons (attached).
If we agree that it's the proper way of doing it, I'll proceed to do it on
the rest of modules.
Cheers!
Aleix
diff --git a/CMakeLists.txt b/CMakeLists.txt
index 389245c..ba6644a 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -9,6 +9,7 @@ set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR} ${CMAKE_CURRENT_S
include(FeatureSummary)
include(CMakePackageConfigHelpers)
include(ECMSetupVersion)
+include(ECMGenerateHeaders)
include(KDEInstallDirs)
include(KDEFrameworkCompilerSettings)
diff --git a/src/lib/CMakeLists.txt b/src/lib/CMakeLists.txt
index 0e18f42..d9501b3 100644
--- a/src/lib/CMakeLists.txt
+++ b/src/lib/CMakeLists.txt
@@ -96,40 +96,32 @@ else()
target_link_libraries(KF5CoreAddons PRIVATE netapi32)
endif()
-if(IS_ABSOLUTE ${INCLUDE_INSTALL_DIR})
- target_include_directories(KF5CoreAddons INTERFACE $INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR} )
-else()
- target_include_directories(KF5CoreAddons INTERFACE $INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/${INCLUDE_INSTALL_DIR} )
-endif()
+target_include_directories(KF5CoreAddons INTERFACE $INSTALL_INTERFACE:${INCLUDE_INSTALL_DIR}/kcoreaddons )
set_target_properties(KF5CoreAddons PROPERTIES VERSION ${KCOREADDONS_VERSION_STRING}
SOVERSION ${KCOREADDONS_SOVERSION}
EXPORT_NAME CoreAddons
)
+ecm_generate_headers(KAboutData REQUIRED_HEADERS KCoreAddons_HEADERS)
+ecm_generate_headers(KSharedDataCache REQUIRED_HEADERS KCoreAddons_HEADERS RELATIVE caching)
+ecm_generate_headers(KAutoSaveFile KDirWatch KMessage KProcess KBackup KUrlMimeData
+RELATIVE io REQUIRED_HEADERS KCoreAddons_HEADERS)
+ecm_generate_headers(KCompositeJob KJob KJobTrackerInterface KJobUiDelegate
+RELATIVE jobs REQUIRED_HEADERS KCoreAddons_HEADERS)
+ecm_generate_headers(KRandom KRandomSequence
+RELATIVE randomness REQUIRED_HEADERS KCoreAddons_HEADERS)
+ecm_generate_headers(KMacroExpander KStringHandler
+RELATIVE text REQUIRED_HEADERS KCoreAddons_HEADERS)
+ecm_generate_headers(KFormat KUser KShell
+RELATIVE util REQUIRED_HEADERS KCoreAddons_HEADERS)
+install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/KCoreAddons DESTINATION ${INCLUDE_INSTALL_DIR} COMPONENT Devel )
+
install(TARGETS KF5CoreAddons EXPORT KF5CoreAddonsTargets ${INSTALL_TARGETS_DEFAULT_ARGS})
install(FILES
-kaboutdata.h
-caching/kshareddatacache.h
-io/kautosavefile.h
-io/kdirwatch.h
-io/kmessage.h
-io/kprocess.h
-io/kbackup.h
-io/kurlmimedata.h
+${KCoreAddons_HEADERS}
io/kfilesystemtype_p.h #Needed for building kio, KFileSystemType
-jobs/kcompositejob.h
-jobs/kjob.h
-jobs/kjobtrackerinterface.h
-jobs/kjobuidelegate.h
-randomness/krandom.h
-randomness/krandomsequence.h
-text/kmacroexpander.h
-text/kstringhandler.h
-util/kformat.h
-util/kuser.h
-util/kshell.h
${CMAKE_CURRENT_BINARY_DIR}/kcoreaddons_export.h
-DESTINATION ${INCLUDE_INSTALL_DIR} COMPONENT Devel
+DESTINATION ${INCLUDE_INSTALL_DIR}/kcoreaddons COMPONENT Devel
)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: [kate/frameworks] part: port from KDialog to QDialog (KateGlobal::configDialog)
On Sun, Dec 29, 2013 at 4:12 PM, Michal Humpula michal.hump...@seznam.czwrote: On Sunday 29 of December 2013 14:44:59 David Faure wrote: On Thursday 19 December 2013 15:28:27 Dominik Haumann wrote: On Thursday, December 19, 2013 15:12:01 Michal Humpula wrote: On Thursday 19 of December 2013 14:57:33 Dominik Haumann wrote: On Wednesday, December 18, 2013 19:42:43 Michal Humpula wrote: Git commit 4e6c1c3d8cd6dbe4d826ce6720169fd94d8848f6 by Michal Humpula. Committed on 18/12/2013 at 19:42. Pushed by michalhumpula into branch 'frameworks'. port from KDialog to QDialog (KateGlobal::configDialog) M +1-4part/utils/kateglobal.cpp M +2-1part/view/kateview.cpp http://commits.kde.org/kate/4e6c1c3d8cd6dbe4d826ce6720169fd94d8848f6 diff --git a/part/utils/kateglobal.cpp b/part/utils/kateglobal.cpp index e576f12..94de177 100644 --- a/part/utils/kateglobal.cpp +++ b/part/utils/kateglobal.cpp @@ -310,10 +310,7 @@ void KateGlobal::configDialog(QWidget *parent) -#if 0 //FIXME KF5 - kd-setButtons( KDialog::Ok | KDialog::Cancel | KDialog::Apply | KDialog::Help ); - kd-setHelp( QString(), KGlobal::mainComponent().componentName() ); -#endif + kd-setStandardButtons(QDialogButtonBox::Ok | QDialogButtonBox::Cancel | QDialogButtonBox::Apply | QDialogButtonBox::Help ); If I'm not mistaken, we can use setStandardButtons() in a lot of other places as well instead of adding the respective buttons manually. Is that correct? If so, we really should do that, to always keep the correct button order (e.g. Cancel on the very right or similar). Greetings, Dominik The drawback is that currently the buttons are not styled the KDE way:( I'm guessing this will be fixed in the future in frameworks QPA? Hm, no idea. CCing frameworks-devel. [did you forget to CC Michal too?] What does styled mean here exactly? The icons on the buttons are missing? Yes, icons and tooltips. I'm guessing whatever the KStandardGuiItem setups too. So should the buttons created by setStandardButtons be restyled manually or should the platform take care of it? Attaching screenshot, how it looks for me. Buttons with icons are manually constructed. Sometimes the buttons have different text or icon then standard, so the need for creating buttons manually is still there, imho. That's fine: You can still get the respective button with: QPushButton * QDialogButtonBox::button(StandardButton which); And then change the icon or text. Yes. But this way, the order at least is kind of automatically set. I'm not sure though, whether this is of importance in all cases. Yes, that's the whole point of QDialogButtonBox. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel We definitely need QDialogButtonBox to look properly in KDE, so if that's not the case at the moment, we'll have to consider it a bug and investigate it. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KCoreAddons forward headers
On Sun, Dec 29, 2013 at 8:10 PM, David Faure fa...@kde.org wrote: On Sunday 29 December 2013 16:18:23 Christoph Cullmann wrote: On Friday 27 December 2013 19:36:57 Aleix Pol wrote: Hi, Here's a patch adding CamelCase headers to KCoreAddons (attached). If we agree that it's the proper way of doing it, I'll proceed to do it on the rest of modules. Looks good to me. I like the fact that we can't forget to add forwarding headers like before - if we do, the lowercase header isn't installed either, so we'll notice faster :) I mean, a single operation is needed to install a new header, instead of two, one of which I always forgot. Hmm, does it really install the normal headers, too? I use it now in kate.git/ktexteditor/include/CMakelists.txt and need still to install the normal headers manually. Well, Aleix's patch removes the installation of the lowercase headers, doesn't it? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5NES Power Glove ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel No, it creates a variable called KCoreAddons_HEADERS which is passed to the install() command. ECM_GENERATE_HEADERS doesn't install anything, we decided to do it like that to minimize the magic factor. Please take a look at the function documentation, in case it's not clear enough (it's at the top of the ECMGenerateHeaders.cmake file). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KCoreAddons forward headers
On Mon, Dec 30, 2013 at 11:42 AM, David Faure fa...@kde.org wrote:
On Monday 30 December 2013 01:26:52 Aleix Pol wrote:
On Sun, Dec 29, 2013 at 8:10 PM, David Faure fa...@kde.org wrote:
On Sunday 29 December 2013 16:18:23 Christoph Cullmann wrote:
On Friday 27 December 2013 19:36:57 Aleix Pol wrote:
Hi,
Here's a patch adding CamelCase headers to KCoreAddons
(attached).
If we agree that it's the proper way of doing it, I'll proceed
to do
it
on
the rest of modules.
Looks good to me. I like the fact that we can't forget to add
forwarding
headers like before - if we do, the lowercase header isn't
installed
either, so we'll notice faster :)
I mean, a single operation is needed to install a new header,
instead
of
two, one of which I always forgot.
Hmm, does it really install the normal headers, too?
I use it now in kate.git/ktexteditor/include/CMakelists.txt and need
still
to install the normal headers manually.
Well, Aleix's patch removes the installation of the lowercase headers,
doesn't
it?
No, it creates a variable called KCoreAddons_HEADERS which is passed to
the
install() command. ECM_GENERATE_HEADERS doesn't install anything, we
decided to do it like that to minimize the magic factor.
Haha, by remove I meant removes the explicit code that installed the
lowercase headers, because it is now done semi-automatically.
So if KCoreAddons_HEADERS contains both the lowercase and camelcase
headers,
then we fully agree :)
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
It only has the lowercase headers, uppercase headers are installed from
another command:
install(DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}/KCoreAddons DESTINATION
${INCLUDE_INSTALL_DIR} COMPONENT Devel )
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Tue, Dec 31, 2013 at 12:50 PM, David Faure fa...@kde.org wrote:
On Sunday 29 December 2013 23:23:44 Friedrich W. H. Kossebau wrote:
Am Sonntag, 29. Dezember 2013, 17:39:47 schrieb Kevin Ottens:
On Sunday 29 December 2013 17:11:36 Friedrich W. H. Kossebau wrote:
So possibly something more that needs to be decided on: where should
plain headers end up?
Consensus was: same place. The camel cased includes and the .h ones
were
planned to live in the same folder.
To have the same pattern like Qt5 uses, I guess? Makes also sense to me.
So by example of KI18n:
Instead of
include/KF5/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
there should be
include/KF5/KI18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
right?
No,
include/KF5/ki18n/klocalizedstring.h
include/KF5/KI18n/KLocalizedString
(lowercase ki18n in the first line).
See make install in kcoreaddons now:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
If the header files of a framework are not prefixed, then they should
be installed in include/{lowercaseframework} and convenience headers
should be installed in include/KDE/{CamelCaseFramework}.
Aleix, is there a final version of that RFC in a wiki page maybe, so we can
all make sure we refer to the same spec for this?
Ok, maybe I should be changing the ones we have now CamelCased to KF5/KDE/.
Having a KDE namespace doesn't make much sense though, if the idea is not
to break source compatibility, we can just tell people to either depend on
KDE4Support or to move from KDE - {ModuleName}.
I don't know about any page on the wiki about headers structure. We really
need this.
(kuitmarkup.h possibly was not renamed to kuitsetup.h for backward
support)
And KF5I18nTargets.cmake should have both:
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5
INTERFACE_INCLUDE_DIRECTORIES ${_IMPORT_PREFIX}/include/KF5/KI18n
Yes, see the KCoreAddonsTargets file ;)
Now, what to expect for frameworks not using the K* prefix for their
classes (and generally using namespaces), by example of KParts:
include/KF5/KParts/KParts/StatusBarExtension
include/KF5/KParts/KParts/ListingExtension
include/KF5/KParts/kparts/statusbarextension.h
include/KF5/KParts/kparts/browseropenorsavequestion.h
I think this is what we should have, but the RFC thread isn't really clear
to
me, hence my request for a final spec.
The RFC thread is more about whether include/.../KCoreAddons
and include/.../kcoreaddons should be by default in the include paths or
not.
More questions:
Q: Really hardcode KF5/ prefix to include path?
The KF5/ part of the include path, does it make sense in all deployments
given that all headers are already contained in subdirs? IMHO that should
be left to be defined by the packager/installer. For what reason would we
want to enforce that?
For co-installability in /usr/include.
I have another pro. This way you never include files without wanting to.
With the new headers structure you have to explicitly link against a module
to be able to find the headers of a framework. That's good, because it's
easier to diagnose a missing dependency from missing includes than weird
linker errors.
Will there be any files outside of the $MODULENAME/ subdirs?
I don't think so.
Q: Add a convenience Module/Module file?
What about adding a convenience include-all file Module/Module, e.g.
include/KF5/KI18n/KI18n, like there usually is one with each Qt module?
I don't like them very much. They make compilation slower, and allow
people to
be lazy instead of doing the right thing
In quick test programs they are fine, but they are quickly abused in real
code...
Well, I won't veto them (consistency is good), but I certainly won't spend
time on them.
AFAIK, it hasn't been discussed. Personally I've never been happy when
using those. I hear they're good when using precompiled headers, but I've
never experienced that myself.
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
ThreadWeaver and CamelCase headers
Hi, I've been looking into adding forward headers in ThreadWeaver and realized that it has slightly weird headers. This module, in contrast to the rest of modules, uses CamelCase.h headers. This makes me wonder if the rules we have for KDE Frameworks apply for ThreadWeaver. Thoughts? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: ThreadWeaver and CamelCase headers
On Wed, Jan 1, 2014 at 8:54 PM, Aleix Pol aleix...@kde.org wrote: Hi, I've been looking into adding forward headers in ThreadWeaver and realized that it has slightly weird headers. This module, in contrast to the rest of modules, uses CamelCase.h headers. This makes me wonder if the rules we have for KDE Frameworks apply for ThreadWeaver. Thoughts? Aleix Sorry for the noise, I already wrote this e-mail yesterday when I didn't have internet connection, didn't realize David sent something similar already. My apologies. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: What are the plans with CamelCase includes?
On Thu, Jan 2, 2014 at 12:31 AM, David Faure fa...@kde.org wrote:
On Tuesday 31 December 2013 14:48:13 Aleix Pol wrote:
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/kcoreaddons/kaboutdata.h
-- Up-to-date:
/d/kde/inst/kde_frameworks/include/KF5/KCoreAddons/KAboutData
The email thread RFC Rules for installation of header files does say
If the header files of a framework are not prefixed, then they
should
be installed in include/{lowercaseframework} and convenience
headers
should be installed in include/KDE/{CamelCaseFramework}.
Actually, what's the reason for lowercaseframework there?
I used that in all the modules I converted (except KIO, I just realized),
and
I'm wondering what the point is.
Example:
include/KF5/KIOCore/KFileItem
include/KF5/KIOCore/kfileitem.h
works fine with KIOCore in the include path, apps just include KFileItem
or
kfileitem.h
If I fix it to
include/KF5/KIOCore/KFileItem
include/KF5/kiocore/kfileitem.h [all lowercase]
it will of course work too, with both dirs in the include path.
It's all transparent for the apps either way, since the cmake magic
encapsulates it for the them.
I'm just wondering what's the point in using two different dirs for
kfileitem.h and KFileItem?
--
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5
I did it like that because KParts works this way. Of course, it's not
required on other modules.
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes Almost 2014
On Tue, Dec 31, 2013 at 4:29 PM, David Faure fa...@kde.org wrote: On Tuesday 31 December 2013 16:17:20 Kevin Ottens wrote: Hello everyone, This is the minutes of the last meeting of 2013. As usual it has been held on #kde-devel at 4pm Paris time. Were present: apol and myself. Sorry, missed it by 30 minutes. Announcement: * TP1 is almost ready, forwarding headers work missing * apol has been working on the header generation for KCoreAddons, KGuiAddons and KWidgetsAddons; * he'll cover KArchive and ThreadWeaver next which are blocking TP1; Can we distribute the work, to get this done faster? I'll take KDBusAddons and KService, let's say. It would be good if someone with more knowledge of the consensus for installed headers would take care of kio and kparts, i.e. the prefixed cases. Aleix or Aurélien, can you maybe start with putting up the spec in the wiki? Or do we still have things to discuss? I didn't fully follow that discussion, so I'm not sure if it's all solved or not (see the questions from Friedrich Kossebau). -- 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 I'll try to write something on a wiki before next meeting. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KTextEditor Frameworks question
On Tue, Jan 7, 2014 at 3:03 AM, Kevin Funk k...@gmx.de wrote: Am Montag, 6. Januar 2014, 21:44:46 schrieb Christoph Cullmann: I see, yeah, thats KatePart it seems to me. Anyway, I am all for going to have a KF5 KTextEditor framework, will make it more approachable for other projects to use it. And unlike in 4.x, KTextEditor would always provide the implementation directly (KatePart merged in, internally) and some wrapper KParts for the people preferring to just load a simple part without any more tight integration. David showed me the kdeexamples/framework-template and the kdelibs-split script. Still, I have one question: Is it really enough to init a new repository and have that one initial commit + add (and then move the files around inside the new git) to have history via grafting available? There is no other trick behind I just don't see ATM? I would try to convert to framework style git in some personal repo on git.kde.org and post that here for review if I do it right ;) Greetings Christoph I tried my luck with splitting/grafting/kdeexamples template. Could somebody take a look what ended up in the master branch of g...@git.kde.org:scratch/cullmann/ktexteditor.git Any feedback welcome, if I screwed it up a lot ;) That git shall contain a KTextEditor framework, I hope, with grafting able history, at least I was able to graft against kate.git using the howto. The structure should fit a framework, only the tests dir is missing as empty atm. Greetings Christoph Hey, Just tried to build kdevplatform against the ktexteditor framework -- Didn't work because CMake didn't find KF5TextEditorConfig.cmake. The problem is that all your .cmake files are missing the KF5 prefix which other frameworks apparently have set. CMake cannot find the framework via find_package(KF5 ... COMPONENTS TextEditor), then, I suppose. Makes sense? -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Yes, it makes sense. When I created those we didn't do it like that in KF5 yet, this changed over time. Feel free to change it :). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: New doxygen script
On Fri, Jan 10, 2014 at 4:30 AM, Alex Merry k...@randomguy3.me.uk wrote: Hey Aurélien, I wrote a new script to generate apidocs. It's in Python rather than shell script (because (a) yay for proper programming languages and (b) cross-platformness). If you run it on a framework like KCoreAddons, you'll get actual bona fide apidocs (unlike if you try to run doxygen.sh on it). It even pulls in README.md as the main page text. It can be found in kde:clones/kapidox/alexmerry/kapidox on the frameworks branch. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Nice initiative! Looking forward to understanding API documentation generation. :) Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QStringLiteral and QTimer in KCompletion tests
On Tue, Jan 21, 2014 at 12:26 AM, David Gil Oliva
davidgilol...@gmail.comwrote:
Hi!
*kcompletionuitest.cpp*
In kcompletionuitest.cpp I have found many uses of QStringLiteral that
perhaps aren't necessary, but I'm not sure:
Form1::Form1(QWidget *parent)
: QWidget(parent)
{
setAttribute(Qt::WA_DeleteOnClose);
*setObjectName(QStringLiteral(Form1));*
resize(559, 465);
*setWindowTitle(QStringLiteral(Form1));*
Form1Layout = new QVBoxLayout(this);
GroupBox1 = new QGroupBox(this);
GroupBox1-setLayout(new QVBoxLayout());
*GroupBox1-setTitle(QStringLiteral(Completion Test));*
Can't it be just GroupBox1-setTitle(Completion Test); for example?
*kcomboboxtest.cpp*
Another thing: the test kcomboboxtest has a Enable/Disable button that
uses a QTimer, so, when pressed, it takes 5 endless seconds to
enable/disable the combo boxes and change the text of the button. May I
take off that QTimer or is it useful in some unknown way? :-/
Thanks!
David Gil
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
You'll see you'll get errors if you pass the char* right away to the
QString. This is because we don't let frameworks use the QString(char*)
constructor as it's not the fastest way to construct a QString. For
applications we don't enforce it, though.
For more information, see the Qt documentation or
http://woboq.com/blog/qstringliteral.html
Regarding the QTimer, I'd assume that it's the thing that does the actual
testing. Maybe you want to reduce the timeout?
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QFileDialog not usable with frameworkintegration
On Thu, Jan 23, 2014 at 11:49 AM, codeminis...@publicstatic.de wrote: Hi, as described in https://git.reviewboard.kde.org/r/115238/ there is a bug QFileDialog frameworkintegration. As opposed to written in the review request the dialog is not usable at the moment if someone wants to select a non-existing file because it crashes. 1. $ ./qfiledialogtest --acceptMode save --selectFile /tmp/moo.png 2. (Note that the selectFile has no effect) 3. Manually select a file 4. Edit the Name text box and write some non-existing name 5. Press ok 6. qfiledialogtest(4329)/(default) QFileInfo::absolutePath: QFileInfo::absolutePath: Constructed with empty filename qfiledialogtest(4329)/(default) qt_assert: ASSERT: d in file ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h, line 120 Aborted Best regards Gregor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I'm looking into this. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: QFileDialog not usable with frameworkintegration
On Thu, Jan 23, 2014 at 5:16 PM, Aleix Pol aleix...@kde.org wrote: On Thu, Jan 23, 2014 at 11:49 AM, codeminis...@publicstatic.de wrote: Hi, as described in https://git.reviewboard.kde.org/r/115238/ there is a bug QFileDialog frameworkintegration. As opposed to written in the review request the dialog is not usable at the moment if someone wants to select a non-existing file because it crashes. 1. $ ./qfiledialogtest --acceptMode save --selectFile /tmp/moo.png 2. (Note that the selectFile has no effect) 3. Manually select a file 4. Edit the Name text box and write some non-existing name 5. Press ok 6. qfiledialogtest(4329)/(default) QFileInfo::absolutePath: QFileInfo::absolutePath: Constructed with empty filename qfiledialogtest(4329)/(default) qt_assert: ASSERT: d in file ../../include/QtCore/../../src/corelib/tools/qscopedpointer.h, line 120 Aborted Best regards Gregor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I'm looking into this. Aleix The described issues should be fixed with this and following commits: http://commits.kde.org/frameworkintegration/cfa3cada6aec542711080f1fa40ba21287587d42 Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Build failed in Jenkins: kde4support_master_qt5 #32
On Fri, Jan 24, 2014 at 3:20 AM, Ben Cooksley bcooks...@kde.org wrote: On Fri, Jan 24, 2014 at 1:28 PM, šumski hrvoje.sen...@gmail.com wrote: On Friday 24 of January 2014 09:53:00 Ben Cooksley wrote: There has been no changes in regards to the compiler, etc. on build.kde.org in the past few weeks. The only thing that could have changed would be the version of CMake - as we follow the 'next' branch, so this could be a CMake regression. Hi Ben, Christoph, actually, this seems like a regression within one of frameworks, or e-c-m. Last build of kde4support went fine on openSUSE's OBS[1] few hours ago, however, after updating and rebuilding all frameworks in their dependency chain - build fails. Used CMake version there is 2.8.12.1. Just for the record, the CI system uses cmake version 2.8.12.20140118-g3117b6 at the moment. Cheers, Hrvoje Regards, Ben [1] https://build.opensuse.org/package/show/KDE:Unstable:Frameworks/kde4support ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I recreated my build directories and now I'm hitting it too. I guess it a matter of time that it spreads to the rest of who are building kde4support... I tried with cmake 2.8.12.1 and today's master. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Schedule
On Mon, Jan 27, 2014 at 1:28 AM, Alex Merry k...@randomguy3.me.uk wrote: Speaking of alphas and releases... Is there a schedule anywhere? I think I wasn't the only one taken by surprise by Kévin's announcement about the alpha last week. http://community.kde.org/Frameworks should either host the schedule or contain a link to it. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel +1, it can be useful to prepare the KF5 presentation for FOSDEM. So far, my plan was to say that we're planning to release by June and an alpha ASAP. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Tue, Jan 28, 2014 at 12:58 PM, David Edmundson da...@davidedmundson.co.uk wrote: For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. Original thread on plasma-devel here: http://mail.kde.org/pipermail/plasma-devel/2014-January/028162.html Discuss. David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Well, there are many different needs, so we'll probably want to have different solutions for them. Bindings to interact with each framework, I'd say they should be installed by the framework itself, but that's only one case. I think we probably want a KQuickAddons as well, to put the components we create to extend Qt. (for example, this component you created for bindings). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Splitting kde-workspace and kde-runtime proposal
On Tue, Jan 28, 2014 at 6:34 PM, Aleix Pol aleix...@kde.org wrote: On Mon, Jan 27, 2014 at 3:21 PM, David Edmundson da...@davidedmundson.co.uk wrote: There is an existing page about slitting runtime here: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization linked to from http://community.kde.org/Frameworks/Epics Alex's wiki page looks far more populated. We should make sure we avoid wiki duplication. David ___ Plasma-devel mailing list plasma-de...@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel I merged all the notes about kde-runtime from last Plasma sprint into the old page: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization I'd suggest to remove the notes from the sprint and keep the old one as the official one to keep track of the state. Aleix Since nobody said anything, I decided to remove the new one, removing the duplication. I'll start working on that splitting this week, hopefully. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Re: HAVE_X11 usage in KIO/core
On Fri, Feb 7, 2014 at 9:51 AM, Martin Gräßlin mgraess...@kde.org wrote:
On Friday 07 February 2014 09:38:41 Kevin Krammer wrote:
On Friday, 2014-02-07, 08:53:54, Martin Gräßlin wrote:
Hi,
I found some HAVE_X11 not defined warnings in KIO and had a look at
them.
One of them is in core/kprotocolmanager.cpp in the following snippet.
// This is not the OS, but the windowing system, e.g. X11 on
Unix/Linux.
static QString platform()
{
#if HAVE_X11
return QL1S(X11);
#elif defined(Q_OS_MAC)
return QL1S(Macintosh);
#elif defined(Q_OS_WIN)
return QL1S(Windows);
#else
return QL1S(Unknown);
#endif
}
I'm wondering what to do about it. The best would be to use
QGuiApplication::platformName, but it's a core app. Also finding X11 in
CMakeLists to get the HAVE_X11 defined looks very wrong to me and not
future safe (Wayland).
My guess is that platform() in this context means operating system, not
windowing/display system.
See the comment I pasted, it's explicitly saying it's the windowing system
and
not the OS...
Cheers
Martin
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Sounds to me like we want to use QGuiApplication::platformName() there, the
only problem is that the strings differ.
Maybe we should just deprecate this function and advise users to use
::platformName().
Aleix
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: let's get ready for Google Summer of Code 2014
On Sun, Feb 9, 2014 at 8:57 PM, Mark Gaiser mark...@gmail.com wrote: On Sun, Feb 9, 2014 at 1:37 PM, Lydia Pintscher ly...@kde.org wrote: On Tue, Feb 4, 2014 at 9:24 AM, Lydia Pintscher ly...@kde.org wrote: Hey everyone :) It is time to get ready for GSoC 2014. It's another great chance to get some large projects done this year and welcome new enthusiastic people to KDE. I am working on our application. I have started our ideas page at http://community.kde.org/GSoC/2014/Ideas Please go and add projects proposals that you think would be awesome to have a student work on them. Please only add proposals where either you or someone you know are willing to mentor them. If you have ideas but don't have a mentor for them please find a mentor first on the appropriate mailinglist. The ideas page needs to be in good shape by 14 February at 19:00 UTC. Go go go go! ;-) http://community.kde.org/GSoC/2014/Ideas In case of questions please ask on #kde-soc or kde-soc-men...@kde.org. Hey folks :) *poke* about this. The ideas page is still looking rather empty and the application deadline is getting closer. Please help with filling up the ideas page. If you have questions or are unsure about a project please ping me to discuss it. Cheers Lydia (only leaving kde-soc-mentor in cc) I do have an idea for KIO in the next GSoC. Revive the KioFuse code to todays KIO version and update it. The start is there [1] and it's even working on kdelibs 4.0 (don't know it's current state). But it would be very wonderful if that could be working and then integrated in Dolphin (and obviously in my Accretion ^_^) Having this would resolve the issue that opening a network file from Dolphin in (for example) mplayer downloads the entire file to your hdd/ssd before opening it in mplayer. The code is here, the opportunity (due to GSoC) is here. All we need now is a student willing to take on this massive task and someone to mentor the student. [1] http://techbase.kde.org/Projects/KioFuse ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Mark, Feel free to add the proposal yourself. :) It's a wiki. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
New framework: KRunner
Hi, During the last sprint, it was decided to split KRunner out of the plasma framework, since it seems like we want to use it but then there are a couple of alternatives. To that end, I created a new repository (kde:krunner) that contains the relevant code and I'll remove it from plasma and add a dependency on krunner from kde-workspace. I'll do it by tomorrow, so it doesn't come up as a surprise. For the moment, I marked it as a tier3, arguably it should be tier4 since there's the possibility of ending up deprecating it, but we're still not there. Cheers! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Allocating kde-runtime/platforms/win
Hi! I am going through the list of things where we're moving kde-runtime components to [1] and I see that there's a platform/win directory. Do you agree that having it in a separate repository would be the best? Could anybody with a working KF5 + windows system (if that exists) work on it? Thanks Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Figuring out kde-runtime: localization
Hi, Going through the information we have in kde-runtime [1] we found there are two subdirectories related to localization (localization and l10n) that we couldn't find a correct place to move to. Can anybody give us a hand and help us figure those out? - localization: has plenty of information regarding different currencies. - l10n: has information about different countries. Should these go to KI18n? Qt? Anybody has plans for those? Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Mac OS X Frameworks Frameworks
On Sun, Feb 23, 2014 at 8:15 PM, Harald Fernengel har...@gmx.com wrote: Hi, TL;DR Do we want to do build KDE Frameworks as Mac OS X Frameworks? Long Story: on Mac OS X, libraries are typically deployed as Frameworks (e.g. a directory containing the shared library, headers, resources and meta data). A framework can be simply draggeddropped to Xcode projects and it's also easier from command line: clang++ -framework KF5Archive -framework QtCore main.cpp (Assuming that Qt and KF5Archive are in a standard Framework path, otherwise, add -F /path/to/framework). I tried to create an OS X Framework out of KArchive and ended up with attached patch (see also https://git.reviewboard.kde.org/r/115977/) What needs to happen on KF5 side? 1) All public headers must be added as source files (e.g. to add_library()) and set as PUBLIC_HEADER property on the target. Instead of a manual install rule, we need to set PUBLIC_HEADER DESTINATION to the install TARGETS rule. 2) Public (installed) headers must use #include myOtherHeader // (double quotes) to include headers belonging to the same framework 3) Public headers must use #include KF5Whatever/foo.h to include headers belonging to other frameworks Is that worth the hassle? If yes, I can try to convert some of our libs to OS X frameworks, hoping not to break things for other platforms ;) Harald ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, I would say that we should follow however it's done in Qt. So far we've been trying to provide as much of a similar experience as if it was another Qt module. Doing so here as well could be interesting too. The changes you propose make sense too, even on a linux system (although I'm unaware of how this PUBLIC_HEADER property works), so I wouldn't have a big problem to adopt them. What scares me the most is that things will break over time from people only testing on Linux, though. This could become frustrating, but also a huge step forward for the project. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Junior jobs on framework runtime
On Fri, Feb 28, 2014 at 1:02 PM, Nicolas Lécureuil k...@nicolaslecureuil.frwrote: Hello, i would like to know if there is junior jobs for framework runtime, as i am a beginer and would like to help. Thanks. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi Nicolas! I'm happy to see you interested in kde-runtime, it definitely needs work. Here's a list of tasks todo [1]. I suggest you to take up any of the tasks (many have a name but most of them forgot about the task, so you can poke them too, if there's anything you're interested in). For the moment, we should make everything compile (preferably without KDE4Support, and taking into account that some things are to be removed) and start moving The goal is to deprecate the module altogether, in favor of a couple of new ones and some things moved into different frameworks. Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ 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 Fri, Mar 14, 2014 at 11:48 AM, Aurélien Gâteau agat...@kde.org wrote: 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? It's fine with me, no file should work too. For the record, here is the list of frameworks without any translatable strings (found out after creating Messages.sh for them and getting no .pot generated when testing it) - attica - karchive - kcrash - kdeclarative - kded - kdesu - kdewebkit - kemoticons - kf5umbrella - kguiaddons - kidletime - kimageformats - kitemmodels - kjs - kmediaplayer - kplotting - threadweaver Aurélien ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Thanks a lot Aurélien for taking care of this. BTW, is there everything in place for non-KI18n modules to be translated? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Default emoticons theme
On Sat, Mar 15, 2014 at 3:14 PM, Kevin Ottens er...@kde.org wrote: Hello, On Saturday 15 March 2014 11:30:22 Alex Merry wrote: - it moves to kemoticons (where it will be guaranteed to be installed), retains its current name, and kemoticons selects kf5 by default. It has my preference, so that you don't need an obscure (from 3rd party devs POV) dependency to have a usable framework by default. Or it could be kemoticons-default or something (as a side-note, there doesn't appear to be a way of specifying a friendly name for the theme - the name is just the name of the directory). Right, renaming it to something more friendly probably makes sense too. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, 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. Either way, I would appreciate if you could document whatever you decide in the wiki [1]. Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Releasing Deprecated modules and Tier 4 Definition
On Sat, Mar 15, 2014 at 4:59 PM, Kevin Ottens er...@kde.org wrote: Hello all, This week, Aaron brought to my attention (thx!) that we would be releasing 5.0 with modules which would be immediately deprecated. Indeed that's a potential maintenance and messaging problem. Also, to make things worse, it looks like it makes the definition of Tier 4 harder. I know David and I often end up arguing about it. As a way out I'm putting on the table several options in order to gather feedback about them and see which cocktail we'll apply going forward. Note that we probably want to figure that out soon in order to not make the release of beta 1 more difficult than necessary. Here are the different options, they're clearly not mutually exclusive. 1) Split Tier 4 in a Tier 4 and a Tier Deprecated :) Currently we can consider Tier 4 as badly defined. It contains both parts with no API (apidox, frameworkintegration, kfileaudiopreview) mainly for integration between frameworks and parts with deprecated APIs (kde4support and khtml ATM). It is maybe a good reason to split that in two parts: * Tier 4 containing no API, meant for runtime integration between the other frameworks and tooling (it would contain apidox, frameworkintegration and kfileaudiopreview); * Tier Deprecated containing deprecated APIs meant as a temporary porting aid from kdelibs times (it would contain kde4support and khtml). 2) Release the deprecated content as a separate product This one kind of depend on (1). If we redefine Tier 4 and have a separate group of deprecated APIs, maybe we shouldn't make the deprecated content official part of KDE Frameworks. In which case we'd release two products: KDE Frameworks for everyone and KDE Porting Aids (in lack of a better name) containing the deprecated APIs. Clearly they are not of interest to the same audience and that could warrant having two products. 3) Roll all the deprecated modules into KDE4Support Instead of having several modules containing deprecated APIs as porting aids, and since we have already a module labelled as a porting aid, why not merge everything into a single module? That module obviously would be kde4support. I admit I'm not sure how practical it would be to merge such a large beast like khtml in there, it seems doable though. 4) Announce the deprecated modules will only be released three times Probably easier if we also apply it with (2). But since they are a porting aid, it might not make sense to keep the release burden throughout the whole KDE Frameworks 5 lifetime, to finally stop releasing them in the distant future of KDE Frameworks 6. That's especially true because of the limited manpower, and it's not exactly easy on the morale to actively maintain and release something that everyone is running from. So, what about being honest with ourselves and limit the number of releases the deprecated modules would have? If we go that route, I propose only three releases (5.0, 5.1 and 5.2) and then we stop, that should give plenty of time for people to port away, especially since it would probably keep working longer (KDE Porting Aids 5.2 would likely work on top of KDE Frameworks 5.4 for instance), it's just that we won't make any special effort anymore to keep it working. That's it for the four ideas to deal with the deprecated modules, now let's find a working cocktail. Feedback and opinions are of course welcome. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Hi, First of all, I agree that the definition of Tier 4 is gray at the moment, escentially it's mostly things we don't want people to depend on. 1) Tier Deprecated would probably contain KRunner too, especially if sprinters ends up joining the frameworks party, which I'm unsure. Personally I think 1 and 2 would work just fine. It's mostly making sure that people doing the promotion will promote what we actually want people to rely on. Option 4 would work too, but we probably want to decide that once we have more applications ported and see what's the status. Aleix ___ 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
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: 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 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: Frameworksintegration of QFileDialog::getExistingDirectory (was: add test for QFileDialog::getExistingDirectory / bug?)
n Tue, Mar 18, 2014 at 9:11 PM, Dominik Haumann dhaum...@kde.org wrote: 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 Hi Dominik, I've been looking though it and it seems like in this case we should be showing KDirSelectDialog instead of a QDialog+KFileWidget, depending on the result of options()-testOption(QFileDialogOptions::ShowDirsOnly). I don't really have the time of doing it this week, but I'd certainly would like to have it. If you want to work on it I can review and give you a hand, if you can't this will have to be done before frameworksintegration is released. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Allocating kde-runtime/platforms/win
On Thu, Feb 20, 2014 at 6:46 PM, Aleix Pol aleix...@kde.org wrote: Hi! I am going through the list of things where we're moving kde-runtime components to [1] and I see that there's a platform/win directory. Do you agree that having it in a separate repository would be the best? Could anybody with a working KF5 + windows system (if that exists) work on it? Thanks Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization So if nobody disagrees, we'll split it out into a KWindowsAddons repository and hope somebody will find a use for it some day. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Jenkins build became unstable: kio_master_qt5 #119
On Wed, Mar 26, 2014 at 5:14 PM, KDE CI System n...@kde.org wrote: See http://build.kde.org/job/kio_master_qt5/119/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel This test is saying that kded5 is either not running or it couldn't be set to testing mode, right? Is it a problem on the testing system? Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Final kde-runtime splitting plan
On Wed, Mar 26, 2014 at 10:02 PM, Albert Astals Cid aa...@kde.org wrote: El Dimecres, 26 de març de 2014, a les 11:42:01, Àlex Fiestas va escriure: On Tuesday 25 March 2014 20:00:51 Albert Astals Cid wrote: Can you give a rationale of why we're removing the following things? kfile4 kfile4 is only useful to test a library that is right now on kde4support. Maybe we can move it there if you want. Wouldn't hurt. What do others think? Personally I think that in its state it's not an end-user tool but more of a tool to test Nepomuk. I would rather see new tooling coming from Baloo and the new tools rather than doing acrobatics to keep it alive. If somebody has a non-abstract reason, I would be fine with moving it to kde4support. kio_cgi Who needs to execute a cgi script without a web server? If you do then we can move it its own repo, I really don't want to see distributions shipping this kio in a package such of kioslaves-extras since it really doesn't offer anything useful for most of our user base. Well you can't know it offers anything useful, and at the end it's a few lines of code that doesn't seem to need lots of maintainance, so why kill them? kio settings Browsing the settings in the file browser does not seem like a really convenient thing to have, and of course it adds more code to maintain. If you want to keep it that's fine but then please become maintainer and tell us where to move it (maybe kioslave-extra?). Same as kio_cgi, I don't see why you want to kill something that works and that you have no objective way to know if people are using or not. I would move those two to kioslave-extra. Shouldn't be much work anyway. Cheers, Albert Cheers! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Final kde-runtime splitting plan
On Wed, Mar 26, 2014 at 12:37 PM, Carlos De Maine car...@demaine.orgwrote: On Wed, 26 Mar 2014 11:28:24 AM Àlex Fiestas wrote: On Wednesday 26 March 2014 09:52:08 Carlos De Maine wrote: On Tue, 25 Mar 2014 04:18:22 PM Àlex Fiestas wrote: Hi there Today Aleix and I are starting to split kde-runtime so we have gone through all the components again making sure that everything has a suitable destination. The result is this [1] wiki. Please, check that you are ok with the destination of each component and also check the things that have been targeted as **REMOVE** should be really removed (we believe so). Kio-network works on 4.13 for me. http://wstaw.org/w/2ADU/[1] Does have a weird issue that it has to be refreshed twice to show any content for the first time, but works perfectly after that. Would be a pity to remove the only network browser. You can't actually execute anything from it can you? It is basically a browser that lets you list things but little more which is quite useless imho. I'm good on moving it elsewhere but what I would like to avoid is shipping this not finished kio as part of the official release which servers only a use (browser and discovery) that most people do not need by itself. It opens fish/sftp, smb, afc kioslaves in dolphin, launches krdc for rfb and vnc, opens konsole (at password entry stage) for ssh. In the past when the upnp kioslave was still compiling i was able to access my upnp shares around the network as well. I agree its not fully functional but in it's present state it is still incredibly useful in the file dialog for accessing the network transparency of kde's kioslaves. With a bit of polish (such as linking ktp to *.presence, fish kioslave for *.udisks-ssh) it would be perfect. Cheers Cheers. It is a pity indeed. I just tried it myself on KDE4 and it seems like it wants to work but it doesn't quite. I wouldn't want this to prolongue, this project couldn't go through kdereview at the moment successfully, so there's little reason for it to stay in. Instead of removing, we can put it differently and move it to a little farm where kioslaves go die, but if somebody doesn't commit to it, it has to go. Also there's many other kioslaves in need for love: ** Adopt your kioslave ** Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Location of docbooks in frameworks repos
On Wed, Mar 26, 2014 at 11:22 PM, Burkhard Lück lu...@hube-lueck.de wrote: Hi, a) In kde4 docbooks usually were located in a top level folder named doc in each repo, in frameworks this folder is named docs with an additional *s* , where as the other repos with a frameworks branch seem to use the name doc (kate, kde-workspace as of now before the split etc.). That is possibly a bit confusing and error-prone editing documentation_paths? b) In kde4 we had a doc folder structure in each repo like: doc/app1/*docbook doc/app2/*docbook ... doc/kcontrol/kcm1/*docbook doc/kcontrol/kcm2/*docbook ... doc/kioslave/kio1/*docbook doc/kioslave/kio2/*docbook etc. Several scripts in l10n-kde4/script (docmessage extraction naming scheme, autogen.sh to generate all CMakeLists.txt for installation of language docbooks, update-xml to generate language docbooks) and the scripts on the kde documentation server docs.kde.org are based on such a consistent doc folder structure. I think we need a similar *consistent* scheme for docbook location in frameworks repos. -- Burkhard Lück ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel For the moment, what I've been doing is to follow this. I've moved the documentation into what will become the new repositories. I think it's a good way to work since it lets us to be consistent, but if somebody has a better idea then let's hear it. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Finding libexec files / relocation
On Mon, Mar 24, 2014 at 5:29 PM, Alex Merry alex.me...@kde.org wrote: Currently, paths to libexec files are hardcoded (or not... see https://git.reviewboard.kde.org/r/117023/). This works find unless you want to relocate anything. I know that relocating is something that has come up with KDE on Windows stuff. Is it something we want to support? If so, how would we do it? I think most of the rest of our stuff (including CMake code) supports relocation, even if you have to set some environment variables to support it (like LD_LIBRARY_PATH on Linux). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I just saw that Qt itself is already installing things in prefix/libexec (e.g. libexec/QtWebProcess). We probably want to do the same. Also it would be interesting to see how they are finding the executables and maybe mimic it ourselves. Personally, I think that it doesn't make sense that we're hardcoding paths while everything is abstracted and magic. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Fri, Mar 28, 2014 at 12:32 PM, Àlex Fiestas afies...@kde.org wrote: On Friday 28 March 2014 11:30:25 Alex Merry wrote: In principle, I agree. In practice, a lot of our frameworks have a runtime dependency of some sort on it.[0] Alex [0]: http://lxr.kde.org/search?v=kf5-qt5_filestring=_string=kded5 I can't talk for other frameworks but in the case of Solid it is a mistake since it makes code that is cross-platform not cross-platform anymore. During the next week I will either remove that or make it platform specific (kde integration). Well yes, actually we should (re-)consider whether frameworks that depend on QtDBus in general if they're cross-platform or not. [1] Aleix [1] http://www.proli.net/2014/03/19/kde-sdk-next-how-will-we-develop-in-a-year/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Move KDED out of frameworks?
On Fri, Mar 28, 2014 at 9:14 PM, Kevin Krammer kram...@kde.org wrote: On Friday, 2014-03-28, 20:55:02, Boudewijn Rempt wrote: On Fri, 28 Mar 2014, Kevin Krammer wrote: The D-Bus session/user daemon is also something that needs to be treated in a platform specific way as a dependency. E.g. on Windows there could be a D-Bus installer that applications bundle and run if necessary, very much like Games bunlding an DirectX installer. Oh no, I never would do that... It would still cost me many hours of my life dealing with it, and it would still give my users no advantage at all. There just isn't any reason an application like Krita would need an ipc solution -- and any library that insists on coming with one is just not going to make the cut. I thought I was obvious that I was addressing the Aleix's concern about portability of frameworks requiring D-Bus, but I must have failed at that. I'll try to make it more clear: a framework that can be built on a platform, run on that platform and provide its functionality on that platform can be considered supported on that platform. And, additionally, the whole point of having different frameworks is the ability to choose which ones to use, which at least for me implied not having to use a framework that does not provide any features an application needs. Cheers, Kevin Well, I think that what Boudewijn means is that even though we can use DBus on Windows, we might not really want to. Not only for deployment constraints but also because then you need to take care of having it running and management. It can be more of a promo statement more than actual technical advice, but I prefer happy users of few frameworks than slightly frustrated users of many frameworks... In other words, I don't think it's enough to be able to build and run. I think that it's fundamental also to be able to deploy it and provide an seamless and integrated experience to the user. Being cross-platform I think it also means that the user doesn't feel like in a KDE/Linux bubble within his Windows/Mac/Android system. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Regarding entry.desktop files
On Fri, Mar 28, 2014 at 10:08 PM, Chusslove Illich caslav.i...@gmx.netwrote: There are now several review requests, in which there is some confusion about what to do/not to do with entry.desktop files in KF5. There are two kinds of these files. One set of entry.desktop files are those in kde-runtime. They are per country, and contain locale information for the KLocale, which is being replaced with QLocale. These files have nothing to do with translations, per se. What to do with them depends on the state of conversion to QLocale. Further comments here welcome. The other set of entry.desktop files are those installed by kde-l10n-* language packages. These are per language, and have nothing to do with locale, per se. What to do with them depends on how the language configuration is going to be done in KF5. There is the thread Translations KCM on kde-frameworks-devel/kde-i18n-doc about this, the matter is not trivial. Until that is settled, language entry.desktop files at the moment have no purpose. In any case, Ki18n (KLocalizedString) itself will not deal with the issue of available languages; it will expect something else to have properly set the Gettext-relevant environment variables (LANG, LC_ALL, LC_MESSAGES, LANGUAGE). -- Chusslove Illich (Часлав Илић) So do you suggest that I move the ones in kde-runtime/l10n to kde4support? For context, in here [1] somebody suggested to move to kde4support _and_ to take a look into the said thread that suggests to figure out some remaining (wrong?) usages of the entry.desktop files. Aleix [1] http://community.kde.org/Frameworks/Epics/New_Runtime_Organization ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported
On Sun, Mar 30, 2014 at 12:02 PM, Gregor Mi codeminis...@publicstatic.dewrote: On 30/03/14 11:29, Gregor Mi wrote: Hi, has anyone recently build qt5 from scratch as described here [1]? When doing $ ./init-repository the following error occurs: --- + git clone git://anongit.kde.org/qt/qtenginio.git qtenginio Cloning into 'qtenginio'... fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. git clone git://anongit.kde.org/qt/qtenginio.git qtenginio exited with status 32768 at ./init-repository line 305. --- The other repos are working fine. Best regards Gregor [1] http://community.kde.org/Frameworks/Building, section QT5 When building QT5 as described in [1] the stable branch of Qt is now 5.3 (and not 5.2). Is this correct? AFAIK, the building dependency is 5.2 and that probably is outdated, as stable is a moving target. Either way, I'd suggest you to use stable too. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: build qt5 stable (changed subject from: qt5 stable: qengineio: fatal: remote error: access denied or repository not exported)
On Sun, Mar 30, 2014 at 6:38 PM, Gregor Mi codeminis...@publicstatic.dewrote: On 30/03/14 12:41, Aleix Pol wrote: On Sun, Mar 30, 2014 at 12:02 PM, Gregor Mi codeminis...@publicstatic.de mailto:codeminis...@publicstatic.de wrote: On 30/03/14 11:29, Gregor Mi wrote: Hi, has anyone recently build qt5 from scratch as described here [1]? When doing $ ./init-repository the following error occurs: --- + git clone git://anongit.kde.org/qt/qtenginio.git http://anongit.kde.org/qt/qtenginio.git qtenginio Cloning into 'qtenginio'... fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. git clone git://anongit.kde.org/qt/qtenginio.git http://anongit.kde.org/qt/qtenginio.git qtenginio exited with status 32768 at ./init-repository line 305. --- The other repos are working fine. Best regards Gregor [1] http://community.kde.org/Frameworks/Building, section QT5 When building QT5 as described in [1] the stable branch of Qt is now 5.3 (and not 5.2). Is this correct? AFAIK, the building dependency is 5.2 and that probably is outdated, as stable is a moving target. Either way, I'd suggest you to use stable too. Aleix Ok. Any idea about the qtenginio Could not read from remote repository problem? Do I need special access rights? Or is it possible that the qtenginio repo is offline? Gregor No idea, I never had this problem. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Lots of duplicated catalogs
On Mon, Mar 31, 2014 at 12:15 AM, Albert Astals Cid aa...@kde.org wrote: $ find -name kdecalendarsystems.pot ./frameworks/kdecalendarsystems.pot ./kdelibs/kdecalendarsystems.pot $ find -name kdelibs_colors4.pot ./frameworks/kdelibs_colors4.pot ./kdelibs/kdelibs_colors4.pot $ find -name kdesud.pot ./frameworks/kdesud.pot ./kde-runtime/kdesud.pot $ find -name kio_help4.pot ./frameworks/kio_help4.pot ./kdelibs/kio_help4.pot $ find -name kpasswdserver.pot ./frameworks/kpasswdserver.pot ./kde-runtime/kpasswdserver.pot $ find -name solid_qt.pot ./frameworks/solid_qt.pot ./kdelibs/solid_qt.pot $ find -name timezones4.pot ./frameworks/timezones4.pot ./kdelibs/timezones4.pot $ find -name xml_mimetypes.pot ./frameworks/xml_mimetypes.pot ./kdelibs/xml_mimetypes.pot Please fix. Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel We can wait a week until the splitting is done, can't we? Where should it be deleted from? Note that kdelibs shouldn't be translated anymore and soon kde-workspace and kde-runtime should be the same. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Lots of duplicated catalogs
On Mon, Mar 31, 2014 at 12:30 AM, Luigi Toscano luigi.tosc...@tiscali.itwrote: Aleix Pol ha scritto: On Mon, Mar 31, 2014 at 12:15 AM, Albert Astals Cid aa...@kde.org mailto:aa...@kde.org wrote: $ find -name kdecalendarsystems.pot ./frameworks/kdecalendarsystems.pot ./kdelibs/kdecalendarsystems.pot $ find -name kdelibs_colors4.pot ./frameworks/kdelibs_colors4.pot ./kdelibs/kdelibs_colors4.pot $ find -name kdesud.pot ./frameworks/kdesud.pot ./kde-runtime/kdesud.pot $ find -name kio_help4.pot ./frameworks/kio_help4.pot ./kdelibs/kio_help4.pot $ find -name kpasswdserver.pot ./frameworks/kpasswdserver.pot ./kde-runtime/kpasswdserver.pot $ find -name solid_qt.pot ./frameworks/solid_qt.pot ./kdelibs/solid_qt.pot $ find -name timezones4.pot ./frameworks/timezones4.pot ./kdelibs/timezones4.pot $ find -name xml_mimetypes.pot ./frameworks/xml_mimetypes.pot ./kdelibs/xml_mimetypes.pot Please fix. Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org mailto:Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel We can wait a week until the splitting is done, can't we? Where should it be deleted from? Note that kdelibs shouldn't be translated anymore and soon kde-workspace and kde-runtime should be the same. What? As soon as kdelibs still receives fixes, we need to keep the translations. Also, this is not about removing them. As Albert kindly explained to me, this is about renaming in order to install both files at the same time (which will be the case for a long time). So for example change the timezones4.pot - timezones5.pot and so on. Ciao -- Luigi ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Ah ok, I clearly misunderstood. Thanks Luigi! Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: I broke kwin
On Tue, Apr 1, 2014 at 3:04 PM, Martin Klapetek martin.klape...@gmail.comwrote: On Tue, Apr 1, 2014 at 3:01 PM, David Faure fa...@kde.org wrote: but I can't fix it? ;) I removed a very old obsolete method from kwindowsystem, then I noticed kwin was still using it, but I can't push the fix? Kwin was splitted into its own new repository, kde:kwin, the fix should be pushed there, kde-workspace was frozen for master commits (I think). Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Yes, that's exactly what happens. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117274: Fix i18n in kross
On Tue, Apr 1, 2014 at 6:02 PM, Alex Merry alex.me...@kde.org wrote: This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117274/ This change has been marked as submitted. Review request for KDE Frameworks. By Alex Merry. *Updated April 1, 2014, 4:02 p.m.* *Repository: * kross Description Resurrect the KAboutData for the kross console Use i18n() instead of QCoreApplication::translate() in console app This was probably from copy-pasted command-line parsing code; everything else in this framework uses KI18n. Use the correct translation catalog in the console application Testing Ran kf5kross --help. Not investigated how to test the translation stuff. Diffs - src/console/CMakeLists.txt (aadc8f57eea53fdd0a51464045b0c12d5dcdb4d2) - CMakeLists.txt (5b28a3c210232d9682af43afec9401416b858ca0) - src/console/main.cpp (f81672e1c15681719943f64698ada19eeebc0bef) View Diff https://git.reviewboard.kde.org/r/117274/diff/ FWIW, I've seen that the context being used in drkonqi is: i18nc(@info:shell, ...). Maybe we want to use that, it looks standard. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
DrKonqi placement
Hi, I know I'm changing what I say about drkonqi every now and then, but every step I take, I realize that the project is bigger and bigger. What I wanted to do originally was to move it to KCrash, KCrash without drkonqi is much less useful. Today I stripped out KDE4Support from it and realized the amount of dependencies is quite considerable: - without bugzilla integration: KF5::I18n KF5::IconThemes KF5::WindowSystem KF5::Crash - with bugzilla integration (additionally to the previous ones): KF5::XmlRpcClient KF5::Wallet KF5::WebKit KF5::ConfigWidgets KF5::WidgetsAddons KF5::JobWidgets KF5::Completion KF5::Wallet Qt5::DBus Because of that fact, I considered turning the bugzilla integration into a plugin, but then it's very tied to the rest of the code in drkonqi, so it would mean quite some work splitting it and making sense out of the abstraction. Does anybody want to give a hand so I can concentrate on the rest of kde-runtime? Otherwise, we can also put it in a separate repository, or we can move KCrash to tier 3. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: DrKonqi placement
On Wed, Apr 2, 2014 at 7:07 PM, Kevin Ottens er...@kde.org wrote: On Wednesday 02 April 2014 18:48:24 Aleix Pol wrote: Hi, I know I'm changing what I say about drkonqi every now and then, but every step I take, I realize that the project is bigger and bigger. What I wanted to do originally was to move it to KCrash, KCrash without drkonqi is much less useful. Today I stripped out KDE4Support from it and realized the amount of dependencies is quite considerable: - without bugzilla integration: KF5::I18n Can be stripped using tr()? KF5::IconThemes Huh? I wonder what it's using there... I'd be surprised if it needs something fancier than QIcon::fromTheme(). KF5::WindowSystem That's only for KStartupInfo right? KF5::Crash To be expected. :-) - with bugzilla integration (additionally to the previous ones): KF5::XmlRpcClient KF5::Wallet KF5::WebKit KF5::ConfigWidgets KF5::WidgetsAddons KF5::JobWidgets KF5::Completion KF5::Wallet Qt5::DBus Woh! Because of that fact, I considered turning the bugzilla integration into a plugin, but then it's very tied to the rest of the code in drkonqi, so it would mean quite some work splitting it and making sense out of the abstraction. Does anybody want to give a hand so I can concentrate on the rest of kde-runtime? Otherwise, we can also put it in a separate repository, or we can move KCrash to tier 3. Or we keep drkonqi out and have it provided by the workspace. If not available then kcrash could provide a default very basic one. Sounds like something for 5.1 though. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel I confirm that KIconThemes wasn't needed, I guess I dropped the dependency while porting, on the other hand I just realized that I was wrong at the non-bugzilla dependencies, this is the correct list: KF5::I18n KF5::WindowSystem KF5::CoreAddons KF5::Service KF5::ConfigWidgets KF5::JobWidgets KF5::KIOCore KF5::Crash And yes, we can try to trim it down, but I'm unsure how useful that would be. So I agree that we can not move it to KCrash and consider it a task for 5.0+. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KUnitConversion Review
On Thu, Feb 27, 2014 at 5:15 PM, John Layt jl...@kde.org wrote: Hi, I've been reviewing KUnitConversion (KUC for short) and doing some small clean-ups, and I'm slowly coming to the conclusion I'm not a fan of the api. However it is used in a few places, so rather than try rewrite the api in the time remaining, I'll finish up the clean-ups and we can release it as is and look to replace it later on. The main clean-ups are: * Remove use of KCurrencyCode. Currently it's only used to get the currency name of the 50 currencies KUC supports and it seems overkill to keep all 207 data files and the api in KUC just for that purpose. Instead I'd move it to kde4support with the rest of KLocale (we also need to move the config files from kde-runtime). This would also remove the dependency on KConfigCore. * Try port away from ki18n to tr(). KUC makes extensive use of ki18nc() and ki18ncp(), but I need to check with Chusselove if all the plural translations can be handled with Qt or if any are scripted. * If we remove those two dependencies then KUC becomes Tier 1, but Tier 2 is fine either way. * Convert more classes to QSharedData * Some small API changes * Lots of docs clean-ups, code style, etc are needed but can be done later. I've done the first step, and I just need a volunteer to do the git magic required to: * Move kcurrencycode.h and kcurrencycode.cpp including history from kunitconversion/src to kde4support/src/kdecore * Move kde-runtime/localization and everything in it including history to kde4support/src/localization or kde4support/runtime/localization or wherever deemed appropriate * Move kde-runtime/l10n and everything in it including history into the same localization folder as above but folder renamed from l10n to localization/country (i.e. at same level as currency folder) * Make sure the data files are built and installed, but need to think about parallel installs with KDE4 data files The data file moves are part of the kde-runtime clean-up, but it makes sense to do them alongside the code moves. Longer term, I've started work on a new Tier 1 library tentatively called KStandards to support the different ISO code standards, and measurement standards and conversions. I've already converted KCurrencyCode to a new KCurrency class using json files, and KCountry and KUnits should follow in due course to provide a future migration path for apps that need them. Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Can we get an update on what's the status of this? Is KCurrency going to kde4support? Maybe it's not needed to deprecate it yet? It can get deprecated at some point in the future within KUnitConversion and then we can add new classes when the ISO alternatives are available. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put kglobalacceld?
On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin mgraess...@kde.org wrote: Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUtils * KF5::I18n * KF5::XmlGui * KF5::WindowSystem * KF5::DBusAddons * KF5::Notifications * KF5::KIOWidgets * KF5::Crash Even if we consider that some are probably not needed it would at least become tier2. Given that kglobalaccel is only intended for the kde-workspaces anyway my suggestion is to move it into plasma-workspace repository instead of merging with the framework. Please note that with Wayland it will be extremely difficult to provide a generic globalaccel anyway (no global keylogger like in X11 possible) and my plan is to implement the interface in KWin. Opinions? Cheers Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel In that case, I'd suggest moving it to plasma-workspace, but then we'll have to make sure to make it explicit that KGlobalAccel is not a portable framework, rendering components depending on it not portable (with emphasis on KXmlGui) to platforms not supported by Plasma (or KWin). Not having a functional KGlobalAccel on Gnome sounds quite a regression to me though... Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
