Re: Review Request 115504: Only perform tests for plugins that are built
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/#review50563 --- Ship it! Ship It! - David Faure On Feb. 20, 2014, 1:04 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/ --- (Updated Feb. 20, 2014, 1:04 p.m.) Review request for KDE Frameworks and Alex Merry. Repository: kimageformats Description --- Only perform tests for plugins that are built This both excludes the autotests and tests subdirs if the user sets BUILD_TESTING off, and makes sure we do not run tests for formats that were not built due to dependencies not being found. Diffs - CMakeLists.txt 8a24fd3600ef18a4e9992660c8637af6ed8f9ddc autotests/CMakeLists.txt 14db235bcea9bb6882539803e715a6e051ea6c18 src/imageformats/CMakeLists.txt e2242a6bc84c9fef10f7a06200daeac5e990e6c6 Diff: https://git.reviewboard.kde.org/r/115504/diff/ Testing --- Builds and tests pass. Builds with BUILD_TESTING off (and tests are not build, and make test does nothing). Commented out the optional find_package calls; still built and tests still passed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: X11 usage in kdeinit/kinit.cpp
On Monday 17 February 2014 16:36:45 Martin Gräßlin wrote: No that doesn't work as I expect that at least during the next decade we will have both WAYLAND_DISPLAY and DISPLAY being set (DISPLAY for legacy applications which won't have a Wayland port any time soon - e.g. Qt4). Then I don't see the problem with keeping the fact that the kdeinit socket contains $DISPLAY in its name (to avoid clashes between sessions). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115739: Make UDSEntry a Q_MOVABLE type, and add some benchmarks and tests
On Feb. 15, 2014, 8:28 p.m., David Faure wrote: Yeah the description is wrong. Making something Q_MOVABLE means that inserting into the list, or the copying that happens when reallocating for more space, will be able to memmove() instead of copy-constructing items. This doesn't change the actual memory layout (which only depends on the size of the items). Basically, as long as UDSEntry doesn't have a q pointer in its private class (which it doesn't), it's movable. So marking it as movable is correct, but not with this commit message. As to a difference in performance, I would be surprised if it was measurable. The copy ctor for UDSEntry plays with a refcount. Frank Reininghaus wrote: Yeah the description is wrong. Making something Q_MOVABLE means that inserting into the list, or the copying that happens when reallocating for more space, will be able to memmove() instead of copy-constructing items. This doesn't change the actual memory layout (which only depends on the size of the items) I am afraid this is wrong. A QListT is essentially a small wrapper around a QListvoid*, which *always* uses memmove() to move around its items. If sizeof(T) = sizeof(void*), and it's known that using memmove() is safe for T (e.g. because it's POD or Qt itself declares it as Q_MOVABLE), then QList just reinterprets each void* as an item of type T. If that is not the case, then QListT will effectively become a QListT*, and allocate memory for each item individually on the heap. So yes, making something Q_MOVABLE definitely changes the actual memory layout. Anyone who does not believe me is encouraged to have a quick look at these excellent posts by Marc Mutz: http://marcmutz.wordpress.com/2010/07/29/sneak-preview-qlist-considered-harmful/ http://marcmutz.wordpress.com/effective-qt/containers/ or look at the source, http://code.woboq.org/qt5/qtbase/src/corelib/tools/qlist.h.html Note that void QListT::append(const T t) calls the function void QListT::node_construct(Node *n, const T t) which does n-v = new T(t) if QTypeInfoT::isLarge (which means that T is larger than a void*) or QTypeInfoT::isStatic (which means that T has not been declared as Q_MOVABLE). This is all explained in Marc's second post. As to a difference in performance, I would be surprised if it was measurable. The copy ctor for UDSEntry plays with a refcount. My point is *not* that this change saves us the refcount updates when items are moved around. What is saves is that a small block (including the overhead that the memory allocator adds to each allocatin, usually 32 bytes) of memory is allocated/deallocated every time an item is added to/removed from the list. This might still not affect the performance noticeably in many cases, but allocating memory is a lot more expensive than just increasing a refcount. You are right. Sorry, I was confusing with QVector. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115739/#review49873 --- On Feb. 13, 2014, 8:23 p.m., Frank Reininghaus wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115739/ --- (Updated Feb. 13, 2014, 8:23 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- I'm continuing my efforts to make UDSEntry more efficient, which were started in https://git.reviewboard.kde.org/r/113591/. This is the second step, and I'll probably do more in the future, for which I will split https://git.reviewboard.kde.org/r/113355/ into independent parts. This patch contains the following changes (which are separate commits): 1. Make UDSEntry a Q_MOVABLE type. This has the effect that a QListUDSEntry a.k.a. UDSEntryList will store the actual entries in a single allocated block of memory, and not pointers to UDSEntries which are allocated individually on the heap (this means that this change is binary incompatible). This reduces the memory usage by 32 bytes per UDSEntry in a QList because each memory allocation uses at least 32 bytes on a 64-bit system. This idea is similar to what I proposed for KFileItem in https://git.reviewboard.kde.org/r/111789/. That one had to be reverted later though because it turned out that KDirLister does rely on QListKFileItem storing only pointers to the KFileItems. I'm confident that no such trouble will happen for UDSEntry - all KIO unit tests still pass. One could argue that we
Re: Review Request 115739: Make UDSEntry a Q_MOVABLE type, and add some benchmarks and tests
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115739/#review50566
---
Ship it!
Thanks!
tests/listjobtest.cpp
https://git.reviewboard.kde.org/r/115739/#comment35566
qDebug inserts spaces already, so these spaces should be removed.
- David Faure
On Feb. 13, 2014, 8:23 p.m., Frank Reininghaus wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115739/
---
(Updated Feb. 13, 2014, 8:23 p.m.)
Review request for KDE Frameworks and David Faure.
Repository: kio
Description
---
I'm continuing my efforts to make UDSEntry more efficient, which were started
in https://git.reviewboard.kde.org/r/113591/. This is the second step, and
I'll probably do more in the future, for which I will split
https://git.reviewboard.kde.org/r/113355/ into independent parts.
This patch contains the following changes (which are separate commits):
1. Make UDSEntry a Q_MOVABLE type. This has the effect that a QListUDSEntry
a.k.a. UDSEntryList will store the actual entries in a single allocated block
of memory, and not pointers to UDSEntries which are allocated individually on
the heap (this means that this change is binary incompatible). This reduces
the memory usage by 32 bytes per UDSEntry in a QList because each memory
allocation uses at least 32 bytes on a 64-bit system.
This idea is similar to what I proposed for KFileItem in
https://git.reviewboard.kde.org/r/111789/. That one had to be reverted later
though because it turned out that KDirLister does rely on QListKFileItem
storing only pointers to the KFileItems. I'm confident that no such trouble
will happen for UDSEntry - all KIO unit tests still pass.
One could argue that we could simply use a UDSEntryVector instead of a
UDSEntyList to achieve the same memory savings, but considering that the list
is used quite frequently ( http://lxr.kde.org/ident?i=UDSEntryList ), this
might require a lot of porting work and cause other unexpected problems.
Note that I could not make the Q_DECLARE_TYPEINFO declaration work if it was
inside the KIO namespace, but I still preferred to do it immediately after
the class declaration, so I had to interrupt the namespace briefly.
2. Add some benchmarks to measure how long typical UDSEntry operations take:
add fields to an entry, read fields from an entry, store a UDSEntryList in a
QByteArray, and read it back from the QByteArray.
All measurements are done both for UDSEntries with 8 fields (this is a rather
typical use case because kio_file usually creates 8 fields), and for entries
with the maximum number of fields.
3. Add a simple manual test ('listjobtest') that runs a KIO::ListJob for a
given URL. This can be used to easily measure the memory usage of the
UDSEntryList that contains an entry for each file at that URL.
Diffs
-
src/core/udsentry.h 9550a7e
tests/CMakeLists.txt dbca6a5
tests/listjobtest.cpp PRE-CREATION
tests/udsentrybenchmark.cpp PRE-CREATION
Diff: https://git.reviewboard.kde.org/r/115739/diff/
Testing
---
1. KIO unit tests still pass.
2. I've confirmed with the new 'listjobtest' and KSysGuard that the memory
usage is really lowered by 32 bytes per item in a UDSEntryList.
3. The benchmark results do not change significantly. I only tested it with a
debug build (i.e., with optimizations disabled) though, and I'm afraid I
might be lacking the resources to set up an additional build of Qt5 and all
of KF5 in release mode. However, since UDSEntry essentially only depends on
qtbase, I might be able to just do a release build of qtbase and build a
stand-alone version of UDSEntry+benchmarks on top of that. I'll look into
this option for getting reliable benchmark results when I work on further
improvements in the future.
Thanks,
Frank Reininghaus
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting feedback: Hiding the Help button in KConfigDialog
On Monday 17 February 2014 16:00:08 Eike Hein wrote: Hi, in the KDialog-based KConfigDialog of yesteryear, it was fairly easy to hide the Help button: dialog-button(KDialog::Help)-hide(); This is useful for apps that don't (yet) ship a handbook, since it avoids mounting user frustration when a click on Help actually re- sults in a nasty error message (though it's actually looking less nasty these days). In Frameworks, this isn't possible any longer since the buttons reside in a private QDialogButtonBox. Might be nice to get it back tho ... Kévin? (this is your port). Should we add an accessor for the QDialogButtonBox in KConfigDialog? On one hand this could interfer with some of the internal handling (enabling/disabling Defaults, Apply, Restore...) but on the other hand this was possible before too (using KDialog members), and it gives most flexibility to the apps (e.g. adding another button, even). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Issues porting KGeography to KF5
On Thursday 02 January 2014 19:55:42 Kevin Ottens wrote: On Thursday 02 January 2014 19:51:17 Albert Astals Cid wrote: El Dijous, 2 de gener de 2014, a les 19:48:46, Kevin Ottens va escriure: On Thursday 02 January 2014 19:45:36 Albert Astals Cid wrote: El Dijous, 2 de gener de 2014, a les 17:36:41, Kevin Ottens va escriure: On Tuesday 31 December 2013 10:39:08 David Faure wrote: On Tuesday 31 December 2013 00:52:59 David Gil Oliva wrote: Hi! I'm porting KGeography to KF5, and I found some issues. *KConfigDialog::setHelp()* KConfigDialog* dialog = new KConfigDialog(this, settings, kgeographySettings::self()); dialog-setHelp(configuration, kgeography); It gives me the following error: /home/david/devel/kgeography/src/kgeography.cpp:170:13: error: ‘class KConfigDialog’ has no member named ‘setHelp’ make[2]: *** [src/CMakeFiles/kgeography.dir/kgeography.cpp.o] Error 1 make[1]: *** [src/CMakeFiles/kgeography.dir/all] Error 2 make: *** [all] Error 2 What should I subtitute it for? Or should I drop it? Kévin? Is the help button missing in your port of KPageDialog to QDialogButtonBox? The problem is setHelp from KConfigDialog, not KPageDialog AFAICT. Not the help button itself. setHelp is indeed gone as it was in KDialog. Moving to QDialog was likely the most disruptive source incompatible change we had to go through. It's supposed to be replaced by showHelp() which is virtual (and by default invokes openUrl with help:/ which should do the right thing in most cases assuming the framework integration is active) I'd say showHelp does the wrong thing everytime setHelp was called since setHelp is used to specify which help page you wanted the help button to open, and if you're doing it is most probably because you don't want the default, so don't see how the default showHelp is going to work at all. Sure, by most cases I meant that in most cases setHelp isn't called anyway. For those who called setHelp the replacement are either reimplementing showHelp or connecting to the help button. Can we have that documented with proper information of what the code reimplementation of showHelp should do? It should be some variation of the openUrl call but with a more convoluted URL. I didn't make the latest implementation of the integration for that one... Aleix might know the scheme used IIRC. Hmmm... in fact it makes me realize that we could put back a setHelp with a different implementation which would change the URL used by showHelp... Then it'd be source compatible again for the KConfigDialog users. Anybody feels like looking into that? This requires moving KHelpClient to KConfigWidgets, I'll do that now. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting feedback: Hiding the Help button in KConfigDialog
On Sunday 23 February 2014 10:08:13 David Faure wrote: On Monday 17 February 2014 16:00:08 Eike Hein wrote: Hi, in the KDialog-based KConfigDialog of yesteryear, it was fairly easy to hide the Help button: dialog-button(KDialog::Help)-hide(); This is useful for apps that don't (yet) ship a handbook, since it avoids mounting user frustration when a click on Help actually re- sults in a nasty error message (though it's actually looking less nasty these days). In Frameworks, this isn't possible any longer since the buttons reside in a private QDialogButtonBox. Might be nice to get it back tho ... Kévin? (this is your port). Hmmm yes, I was sure I replied in this thread though... apparently not. :-) Should we add an accessor for the QDialogButtonBox in KConfigDialog? On one hand this could interfer with some of the internal handling (enabling/disabling Defaults, Apply, Restore...) but on the other hand this was possible before too (using KDialog members), and it gives most flexibility to the apps (e.g. adding another button, even). Yep, was my thought as well in the imaginary email I sent. :-) The more secure alternative would be hideButton() and addButton() which would take respectively a button code and a pointer to a button. That'd avoid breaking the encapsulation. I don't think I have a preference between the two. One breaks encapsulation badly, the other one carries the risk of API explosion later on (if we want to provide more control than just hiding). Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115959/ --- Review request for KDE Frameworks. Repository: kconfigwidgets Description --- Resurrect KConfigDialog::setHelp (used to come from KDialog). It controls the default behavior of showHelp(), which is implemented using KHelpClient. Move KHelpClient down from kxmlgui, for use in KConfigDialog. Diffs - src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36 src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280 src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405 src/khelpclient.h PRE-CREATION src/khelpclient.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115959/diff/ Testing --- Compiled all of KF5. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115959/ --- (Updated Feb. 23, 2014, 9:56 a.m.) Review request for KDE Frameworks and Albert Astals Cid. Repository: kconfigwidgets Description --- Resurrect KConfigDialog::setHelp (used to come from KDialog). It controls the default behavior of showHelp(), which is implemented using KHelpClient. Move KHelpClient down from kxmlgui, for use in KConfigDialog. Diffs - src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36 src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280 src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405 src/khelpclient.h PRE-CREATION src/khelpclient.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115959/diff/ Testing --- Compiled all of KF5. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
CMake error compiling kde-runtime
Hi! I've removed the build and install folders of KF5. When running kdesrc-build, I get the following error in kde-runtime: # kdesrc-build running: 'cmake' '/home/david/devel/kf5-development/kde-runtime' '-DCMAKE_CXX_FLAGS:STRING=-pipe -DQT_STRICT_ITERATORS -DQURL_NO_CAST_FROM_STRING -DQT_NO_HTTP -DQT_NO_FTP -Wformat -Werror=format-security -Werror=return-type -Wno-variadic-macros -Wlogical-op ' '-DCMAKE_INSTALL_PREFIX=/home/david/KF5' # from directory: /home/david/devel/kf5-development/build/kde-runtime -- The C compiler identification is GNU 4.7.3 -- The CXX compiler identification is GNU 4.7.3 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Check for working CXX compiler: /usr/bin/c++ -- Check for working CXX compiler: /usr/bin/c++ -- works -- Detecting CXX compiler ABI info -- Detecting CXX compiler ABI info - done CMake Error at /home/david/KF5/share/cmake-3.0/Modules/CMakeFindDependencyMacro.cmake:52 (find_package): Could not find a configuration file for package KF5DesignerPlugin that is compatible with requested version 5.2. The following configuration files were considered but not accepted: /home/david/KF5/lib/i386-linux-gnu/cmake/KF5DesignerPlugin/KF5DesignerPluginConfig.cmake, version: 4.96.0 Call Stack (most recent call first): /home/david/KF5/lib/i386-linux-gnu/cmake/KF5KDE4Support/KF5KDE4SupportConfig.cmake:62 (find_dependency) CMakeLists.txt:56 (find_package) -- Configuring incomplete, errors occurred! See also /home/david/devel/kf5-development/build/kde-runtime/CMakeFiles/CMakeOutput.log. This is only to let you know, because I don't need kde-runtime to continue developing. I'd like to have a completely built KF5 and (just perhaps) this needs some fixing somewhere. Thank you David Gil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: CMake error compiling kde-runtime
On Sunday 23 February 2014 11:05:16 David Gil Oliva wrote: CMake Error at /home/david/KF5/share/cmake-3.0/Modules/CMakeFindDependencyMacro.cmake:52 (find_package): Could not find a configuration file for package KF5DesignerPlugin that is compatible with requested version 5.2. I just analyzed and reported this error on kde-buildsystem. For now, git checkout v2.8.12.2 in your cmake git repo, or apply this diff --git a/kf5-frameworks-build-include b/kf5-frameworks-build-include index df4498a..c1cf637 100644 --- a/kf5-frameworks-build-include +++ b/kf5-frameworks-build-include @@ -13,6 +13,8 @@ module cmake-git repository git://cmake.org/cmake.git +# Workaround for broken find_dependency in cmake master right now +tag v2.8.12.2 end module module libdbusmenu-qt -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: configuration file found with version 4.96.0 but version 5.2 is required by the KF5 buld
On Saturday 22 February 2014 15:31:36 Alex Merry wrote: On 21/02/14 16:01, Shivam Makkar wrote: Hi ! I was trying to build Kde-Framework 5 and got following CMake error while executing ./kdesrc-build. the error produces every time, for Kde-workspace and kde-rumtime, regarding config file found but with older version. /CMake Error at /home/amourphious/kf5/inst/share/cmake-3.0/Modules/CMakeFindDependencyMacr o.cmake:52 (find_package):/ / Could not find a configuration file for package KF5Pty that is compatible/ / with requested version 5.2./ This is a bug in CMake. I've posted a patch to the cmake-developers list. You can wait for that to be applied, apply it yourself (attached), or use an older version of CMake (anything from the 2.8.12 series is fine). Ah! Well done. You were faster and more thorough than I was :) (and I hadn't seen this, with the amount of traffic on this list) Thanks! -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kstartupconfig5
On Thursday 20 February 2014 11:22:54 Alex Merry wrote: On 19/02/14 18:07, Jaime wrote: I've looked in the bin directory and there is no kstartupconfig5. I've done a grep in the source and it is included in kde-workspace, but aparently, it is only for BSD. if(LIBBSD_FOUND) ecm_optional_add_subdirectory( kstartupconfig) else() message(STATUS LibBSD was not found, kstartupconfig will not be built) endif() Note that glibc provides a libbsd, which is its BSD compatibility library. In fact, the reason kstartupconfig5 links against appears to be its use of strlcpy and strlcat. So this is not aimed at BSD-ish systems (I don't even know whether BSD-ish systems have a libbsd...). Urgh, this is some strange evolution we're seeing there. 1) kstartupconfig is supposed to be built for everyone, this if() is wrong. 2) in the kdelibs4 world, strlcpy and strlcat were provided by kdefakes - header installed by kdecore, symbols in kdecore itself, on platforms where the functionality didn't exist. 3) in KF5 we cleaned up kdefakes and ported KF5 away from it, but maybe we omitted the fact that things like kstartupconfig might need to use it too. == I would suggest doing like in KCrash, which inherited the strlcpy fake from kdefake, since we thought it was the only user of it. Copy config-strlcpy.h.cmake and strlcpy-fake.c and the configure check. And remove the LIBBSD stuff, it makes no sense at all. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115959: Resurrect KConfigDialog::setHelp (used to come from KDialog). Move KHelpClient down from kxmlgui, for use in KConfigDialog.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115959/#review50567 --- src/khelpclient.h https://git.reviewboard.kde.org/r/115959/#comment35567 There is no such parameter? - Kai Uwe Broulik On Feb. 23, 2014, 9:56 a.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115959/ --- (Updated Feb. 23, 2014, 9:56 a.m.) Review request for KDE Frameworks and Albert Astals Cid. Repository: kconfigwidgets Description --- Resurrect KConfigDialog::setHelp (used to come from KDialog). It controls the default behavior of showHelp(), which is implemented using KHelpClient. Move KHelpClient down from kxmlgui, for use in KConfigDialog. Diffs - src/CMakeLists.txt 7da7fba0c15153d6dee381c2b8f282e9837eae36 src/kconfigdialog.h b06efc588c772ed655d581a0e021d92af5e0e280 src/kconfigdialog.cpp 8db48e23f614530cef11a23a182b50d905327405 src/khelpclient.h PRE-CREATION src/khelpclient.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115959/diff/ Testing --- Compiled all of KF5. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: frameworkintegration_master_qt5 #42
See http://build.kde.org/job/frameworkintegration_master_qt5/42/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115960: Add sharedConfig() accessor, to avoid manipulating a raw KConfig * as returned by config().
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115960/ --- Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- Add sharedConfig() accessor, to avoid manipulating a raw KConfig * as returned by config(). This is useful when using kconfigxt and some other code to read from the same config file (e.g. KColorScheme::contrastF(config)) - no need to call KSharedConfig::openConfig twice, just grab the KSharedConfig from the generated class. Diffs - src/core/kcoreconfigskeleton.h 9cd079941fa6f870a19bdbdb945aafe858b4c51a src/core/kcoreconfigskeleton.cpp 98d9cdccec3cf3925bb68e2d0cff1b5a1276c56a Diff: https://git.reviewboard.kde.org/r/115960/diff/ Testing --- About to use it in kde-workspace. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : frameworkintegration_master_qt5 #43
See http://build.kde.org/job/frameworkintegration_master_qt5/43/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115956: More generic (renamed) KDocBookXML4.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115956/#review50573 --- Generally looks good. Just a couple of things to fix. CMakeLists.txt https://git.reviewboard.kde.org/r/115956/#comment35569 DESCRIPTION and URL should go in the FindDocBookXML4.cmake file cmake/FindDocBookXML4.cmake https://git.reviewboard.kde.org/r/115956/#comment35570 Add something about how the version handling works - ie: pass a version to find_package(), and it will find that DTD version, otherwise it will find 4.2. - Alex Merry On Feb. 22, 2014, 6:19 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115956/ --- (Updated Feb. 22, 2014, 6:19 p.m.) Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- This is the combination of two RR, now that FindDocBookXML.cmake/FindDocBookXSL.cmake have been moved to kdoctools: - https://git.reviewboard.kde.org/r/115876/ - https://git.reviewboard.kde.org/r/115879/ Combination of three commits: 1) More generic structure for FindDocBookXML - allows modules to request a generic version of DocBook XML - keep compatibility variables for now (originally from 115876) --- 2) Rename as FindDocBookXML4, it will be used only for DocBook 4.x The rename reflects the fact that it is used for DocBookXML4 only; a future DocBookXML5 could be added if needed. (originally from 115876) Use the new module name in CMake files. (originally from 115879) 3) New DocBookXML4_* variables, explicitly require the DocBookXML4 version (originally from 115879) Diffs - CMakeLists.txt 5ad7099 cmake/FindDocBookXML.cmake b6d623e cmake/FindDocBookXML4.cmake PRE-CREATION config-kdoctools.h.cmake f2fe22c src/CMakeLists.txt 71a7d2e src/customization/dtd/kdex.dtd.cmake c643d9b Diff: https://git.reviewboard.kde.org/r/115956/diff/ Testing --- Compiles, documentation is generated. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115897: Remove FindDocBook*.cmake
On Feb. 22, 2014, 6:29 p.m., Luigi Toscano wrote: As this was already committed, can this RR be closed? Actually, I never committed this one, since I never got a ship it. I added the files to kdoctools, but never removed them from e-c-m. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/#review50553 --- On Feb. 19, 2014, 11:45 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/ --- (Updated Feb. 19, 2014, 11:45 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, David Faure, Kevin Ottens, and Luigi Toscano. Repository: extra-cmake-modules Description --- Remove FindDocBook*.cmake These are only really useful to kdoctools, so they may as well live there. (NB: after looking at how kdoctools uses the information from these files, I suspect they won't even be needed for the compatibility macros that are intended to end up in kde4support). Diffs - find-modules/FindDocBookXML.cmake b6d623e4e5ca40cdda4c895a19a0dc273831703a find-modules/FindDocBookXSL.cmake a7320aed66b72c92f0286658e38b7fc32266790c Diff: https://git.reviewboard.kde.org/r/115897/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115028: Inline deprecated KUser::fullName() method
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115028/#review50577 --- This review has been submitted with commit 88a0d9828aa5b7e108ac259e1d60f38061c93027 by Alex Merry to branch master. - Commit Hook On Feb. 22, 2014, 5:28 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115028/ --- (Updated Feb. 22, 2014, 5:28 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Inline deprecated KUser::fullName() method Use KCOREADDONS_NO_DEPRECATED instead of KDE_NO_DEPRECATED KCOREADDONS_NO_DEPRECATED is the macro controlled by generate_export_header; KDE_NO_DEPRECATED is left over from kdelibs. Diffs - src/lib/util/kuser.h 2b6e6ed92bc1465945f36f2fde821f36fa51585f src/lib/util/kuser_unix.cpp 8a3a39d379ca863b4906bb01228c5e01a5b955b0 src/lib/util/kuser_win.cpp 6a6cbb1751bd569d8684f8e11add1ef304c0a94d Diff: https://git.reviewboard.kde.org/r/115028/diff/ Testing --- configures, compiles, tests pass (well, except KDirWatch-FAM, which has never passed for me). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115028: Inline deprecated KUser::fullName() method
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115028/#review50576 --- This review has been submitted with commit fa5a6e77b6f0d70fc7dbe781c9d15a377d35e786 by Alex Merry to branch master. - Commit Hook On Feb. 22, 2014, 5:28 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115028/ --- (Updated Feb. 22, 2014, 5:28 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Inline deprecated KUser::fullName() method Use KCOREADDONS_NO_DEPRECATED instead of KDE_NO_DEPRECATED KCOREADDONS_NO_DEPRECATED is the macro controlled by generate_export_header; KDE_NO_DEPRECATED is left over from kdelibs. Diffs - src/lib/util/kuser.h 2b6e6ed92bc1465945f36f2fde821f36fa51585f src/lib/util/kuser_unix.cpp 8a3a39d379ca863b4906bb01228c5e01a5b955b0 src/lib/util/kuser_win.cpp 6a6cbb1751bd569d8684f8e11add1ef304c0a94d Diff: https://git.reviewboard.kde.org/r/115028/diff/ Testing --- configures, compiles, tests pass (well, except KDirWatch-FAM, which has never passed for me). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115028: Inline deprecated KUser::fullName() method
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115028/ --- (Updated Feb. 23, 2014, 11:53 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcoreaddons Description --- Inline deprecated KUser::fullName() method Use KCOREADDONS_NO_DEPRECATED instead of KDE_NO_DEPRECATED KCOREADDONS_NO_DEPRECATED is the macro controlled by generate_export_header; KDE_NO_DEPRECATED is left over from kdelibs. Diffs - src/lib/util/kuser.h 2b6e6ed92bc1465945f36f2fde821f36fa51585f src/lib/util/kuser_unix.cpp 8a3a39d379ca863b4906bb01228c5e01a5b955b0 src/lib/util/kuser_win.cpp 6a6cbb1751bd569d8684f8e11add1ef304c0a94d Diff: https://git.reviewboard.kde.org/r/115028/diff/ Testing --- configures, compiles, tests pass (well, except KDirWatch-FAM, which has never passed for me). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115963: KSharedConfig: Fix interference from kdeplatformtheme into unittests
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115963/ --- Review request for KDE Frameworks and Matthew John Dawson. Repository: kconfig Description --- Fix interference from kdeplatformtheme into unittests kdeplatformtheme would load kdeglobals and the app config file, in order to load settings, before the unittests get a chance to call QStandardPaths::setTestModeEnabled(true). As a result, the test would keep getting references to wrong shared config objects, pointing to the real user's locations rather than the test directories. This fixes e.g. kconfigdialog_unittest from kconfigwidgets for me (it only passes on build.kde.org because it doesn't install frameworkintegration for testing this framework) Diffs - src/core/ksharedconfig.cpp 4f0e8d698f60fd05c25e4796be12a35facb8cd38 Diff: https://git.reviewboard.kde.org/r/115963/diff/ Testing --- kconfigdialog_unittest now passes with frameworkintegration installed. The tests in frameworkintegration still pass. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115504: Only perform tests for plugins that are built
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/#review50579 --- This review has been submitted with commit 6272954cc53fa39e73524cbd2a42a90018544ee5 by Alex Merry to branch master. - Commit Hook On Feb. 20, 2014, 1:04 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/ --- (Updated Feb. 20, 2014, 1:04 p.m.) Review request for KDE Frameworks and Alex Merry. Repository: kimageformats Description --- Only perform tests for plugins that are built This both excludes the autotests and tests subdirs if the user sets BUILD_TESTING off, and makes sure we do not run tests for formats that were not built due to dependencies not being found. Diffs - CMakeLists.txt 8a24fd3600ef18a4e9992660c8637af6ed8f9ddc autotests/CMakeLists.txt 14db235bcea9bb6882539803e715a6e051ea6c18 src/imageformats/CMakeLists.txt e2242a6bc84c9fef10f7a06200daeac5e990e6c6 Diff: https://git.reviewboard.kde.org/r/115504/diff/ Testing --- Builds and tests pass. Builds with BUILD_TESTING off (and tests are not build, and make test does nothing). Commented out the optional find_package calls; still built and tests still passed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115504: Only perform tests for plugins that are built
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115504/ --- (Updated Feb. 23, 2014, 11:55 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Alex Merry. Repository: kimageformats Description --- Only perform tests for plugins that are built This both excludes the autotests and tests subdirs if the user sets BUILD_TESTING off, and makes sure we do not run tests for formats that were not built due to dependencies not being found. Diffs - CMakeLists.txt 8a24fd3600ef18a4e9992660c8637af6ed8f9ddc autotests/CMakeLists.txt 14db235bcea9bb6882539803e715a6e051ea6c18 src/imageformats/CMakeLists.txt e2242a6bc84c9fef10f7a06200daeac5e990e6c6 Diff: https://git.reviewboard.kde.org/r/115504/diff/ Testing --- Builds and tests pass. Builds with BUILD_TESTING off (and tests are not build, and make test does nothing). Commented out the optional find_package calls; still built and tests still passed. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build is back to stable : kimageformats_master_qt5 #29
See http://build.kde.org/job/kimageformats_master_qt5/29/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: GSoC: KioFuse
On Sat, Feb 22, 2014 at 11:22 PM, Lydia Pintscher ly...@kde.org wrote: On Wed, Feb 19, 2014 at 4:13 PM, Pali Rohár pali.ro...@gmail.com wrote: Hello KDE developers! I looked at KDE GSoC wiki page [1] and there is for me interesting project KioFuse. Did I understand it correctly, that KioFuse can be usefull for non KIO/KDE applications which want to open file from KIO (e.g network smb/nfs/http file)? Can you describe more details about this GSoC project? Hi Pali :) It seems we do not really have a mentor for this project after all :( Is there anything else on the page that interests you? Mark: Please remove the idea from the wiki. Done. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting feedback: Hiding the Help button in KConfigDialog
On Sunday, 2014-02-23, 10:54:01, Kevin Ottens wrote: On Sunday 23 February 2014 10:08:13 David Faure wrote: On Monday 17 February 2014 16:00:08 Eike Hein wrote: Hi, in the KDialog-based KConfigDialog of yesteryear, it was fairly easy to hide the Help button: dialog-button(KDialog::Help)-hide(); This is useful for apps that don't (yet) ship a handbook, since it avoids mounting user frustration when a click on Help actually re- sults in a nasty error message (though it's actually looking less nasty these days). In Frameworks, this isn't possible any longer since the buttons reside in a private QDialogButtonBox. Might be nice to get it back tho ... Kévin? (this is your port). Hmmm yes, I was sure I replied in this thread though... apparently not. :-) Should we add an accessor for the QDialogButtonBox in KConfigDialog? On one hand this could interfer with some of the internal handling (enabling/disabling Defaults, Apply, Restore...) but on the other hand this was possible before too (using KDialog members), and it gives most flexibility to the apps (e.g. adding another button, even). Yep, was my thought as well in the imaginary email I sent. :-) The more secure alternative would be hideButton() and addButton() which would take respectively a button code and a pointer to a button. That'd avoid breaking the encapsulation. I don't think I have a preference between the two. One breaks encapsulation badly, the other one carries the risk of API explosion later on (if we want to provide more control than just hiding). My initial thought was to suggest doing the same as in the Qt4 version, i.e. having a button() method to allows access to be buttons. That would make it less implementation specific, i.e. would still work if QDialogButtonBox is replaced with something else in the future. But usage of the button box already leaks, there are two protected accessors to it. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115875: kconfigtest: write everything into a subdirectory
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/#review50580 --- autotests/kconfigtest.cpp https://git.reviewboard.kde.org/r/115875/#comment35571 This is a global setting, not toggled on/off, nor does it only apply to the next line. Why not leave it as the first statement of initTestCase()? It would reassure me that everything uses that mode, rather than risking that some other call ends up with the user's dir before testConfigDir() is called. autotests/kconfigtest.cpp https://git.reviewboard.kde.org/r/115875/#comment35572 There's a lot of testConfigDir() + ../kdeglobals in many places. Maybe make an inline method for that, in case we change our mind again about where it should reside? - David Faure On Feb. 18, 2014, 9:52 p.m., Alexander Richardson wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115875/ --- (Updated Feb. 18, 2014, 9:52 p.m.) Review request for KDE Frameworks. Repository: kconfig Description --- kconfigtest: write everything into a subdirectory This test keeps deleting the whole ~/.qttest directory. By moving all data into a subdirectory it is now possible to run multiple tests that use kconfig in parallel. Diffs - autotests/kconfigtest.cpp 1c0dc1cf63539e29236ab57e1e848930b468053a Diff: https://git.reviewboard.kde.org/r/115875/diff/ Testing --- Test still passes. No files (except kdeglobals) are created in ~/.qttest Thanks, Alexander Richardson ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: WebP image plugin
On Saturday 22 February 2014 10:33:44 Alex Merry wrote: On 22/02/14 09:11, David Faure wrote: On Friday 21 February 2014 16:33:29 Hrvoje Senjan wrote: On Feb. 20, 2014, 12:56 p.m., Commit Hook wrote: This review has been submitted with commit 4fbbc75429597dc545ae8af24e870d9bac5f2f2a by Alex Merry to branch master. Seems Qt 5.3 will have it's own webp plugin (commit 4522b350e53471c2ebc6d4692736ee4708445b66 in stable branch)... Hmm, interesting. Do we need to have our own then? Does it do anything better? Our plugin does a little extra work in that it doesn't include an alpha channel in the QImage if there isn't one in the WebP data when reading, and vice versa when writing. OTOH, our plugin's writing appears to be broken. It also doesn't set the lossless option ever, while Qt's plugin does. Other than that, they're identical (unsurprising, since they both use the reference libwebp). So I would say that it's not worth keeping our own once we depend on Qt 5.3. The question is: do we want it for Qt 5.2 systems, or do we just say if you want WebP, upgrade to Qt 5.3? Keeping ours sounds to me like extra trouble for not much gain (at some point both will be available, until we remove it), but I'm happy with any solution you guys decide upon. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115956: More generic (renamed) KDocBookXML4.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115956/ --- (Updated Feb. 23, 2014, 2:34 p.m.) Review request for Documentation and KDE Frameworks. Changes --- Fixed the issues: - moved DESCRIPTION and URL into FindDocBookXML4.cmake and FindDocBookXSL.cmake - describe the parameter with the variable in FindDocBookXML4.cmake Repository: kdoctools Description (updated) --- This is the combination of two RR, now that FindDocBookXML.cmake/FindDocBookXSL.cmake have been moved to kdoctools: - https://git.reviewboard.kde.org/r/115876/ - https://git.reviewboard.kde.org/r/115879/ Combination of few commits: 1) More generic structure for FindDocBookXML - allows modules to request a generic version of DocBook XML - keep compatibility variables for now (originally from 115876) --- 2) Rename as FindDocBookXML4, it will be used only for DocBook 4.x The rename reflects the fact that it is used for DocBookXML4 only; a future DocBookXML5 could be added if needed. (originally from 115876) Use the new module name in CMake files. (originally from 115879) 3) New DocBookXML4_* variables, explicitly require the DocBookXML4 version (originally from 115879) 4) Move DocBookXML4 DESCRIPTION and URL into the cmake file 5) Move DocBookXSL DESCRIPTION and URL into the cmake file Diffs (updated) - CMakeLists.txt 5ad7099 cmake/FindDocBookXML.cmake b6d623e cmake/FindDocBookXML4.cmake PRE-CREATION cmake/FindDocBookXSL.cmake a7320ae config-kdoctools.h.cmake f2fe22c src/CMakeLists.txt 71a7d2e src/customization/dtd/kdex.dtd.cmake c643d9b Diff: https://git.reviewboard.kde.org/r/115956/diff/ Testing --- Compiles, documentation is generated. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115897: Remove FindDocBook*.cmake
On Feb. 22, 2014, 6:29 p.m., Luigi Toscano wrote: As this was already committed, can this RR be closed? Alex Merry wrote: Actually, I never committed this one, since I never got a ship it. I added the files to kdoctools, but never removed them from e-c-m. Is a shipit really needed, given https://git.reviewboard.kde.org/r/115896/ ? - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/#review50553 --- On Feb. 19, 2014, 11:45 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/ --- (Updated Feb. 19, 2014, 11:45 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, David Faure, Kevin Ottens, and Luigi Toscano. Repository: extra-cmake-modules Description --- Remove FindDocBook*.cmake These are only really useful to kdoctools, so they may as well live there. (NB: after looking at how kdoctools uses the information from these files, I suspect they won't even be needed for the compatibility macros that are intended to end up in kde4support). Diffs - find-modules/FindDocBookXML.cmake b6d623e4e5ca40cdda4c895a19a0dc273831703a find-modules/FindDocBookXSL.cmake a7320aed66b72c92f0286658e38b7fc32266790c Diff: https://git.reviewboard.kde.org/r/115897/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115956: More generic (renamed) KDocBookXML4.cmake
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115956/#review50592 --- cmake/FindDocBookXML4.cmake https://git.reviewboard.kde.org/r/115956/#comment35589 You'll need to include the FeatureSummary module for this. cmake/FindDocBookXSL.cmake https://git.reviewboard.kde.org/r/115956/#comment35590 Likewise, FeatureSummary is needed - Alex Merry On Feb. 23, 2014, 2:34 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115956/ --- (Updated Feb. 23, 2014, 2:34 p.m.) Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- This is the combination of two RR, now that FindDocBookXML.cmake/FindDocBookXSL.cmake have been moved to kdoctools: - https://git.reviewboard.kde.org/r/115876/ - https://git.reviewboard.kde.org/r/115879/ Combination of few commits: 1) More generic structure for FindDocBookXML - allows modules to request a generic version of DocBook XML - keep compatibility variables for now (originally from 115876) --- 2) Rename as FindDocBookXML4, it will be used only for DocBook 4.x The rename reflects the fact that it is used for DocBookXML4 only; a future DocBookXML5 could be added if needed. (originally from 115876) Use the new module name in CMake files. (originally from 115879) 3) New DocBookXML4_* variables, explicitly require the DocBookXML4 version (originally from 115879) 4) Move DocBookXML4 DESCRIPTION and URL into the cmake file 5) Move DocBookXSL DESCRIPTION and URL into the cmake file Diffs - CMakeLists.txt 5ad7099 cmake/FindDocBookXML.cmake b6d623e cmake/FindDocBookXML4.cmake PRE-CREATION cmake/FindDocBookXSL.cmake a7320ae config-kdoctools.h.cmake f2fe22c src/CMakeLists.txt 71a7d2e src/customization/dtd/kdex.dtd.cmake c643d9b Diff: https://git.reviewboard.kde.org/r/115956/diff/ Testing --- Compiles, documentation is generated. Thanks, Luigi Toscano ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115897: Remove FindDocBook*.cmake
On Feb. 22, 2014, 6:29 p.m., Luigi Toscano wrote: As this was already committed, can this RR be closed? Alex Merry wrote: Actually, I never committed this one, since I never got a ship it. I added the files to kdoctools, but never removed them from e-c-m. Luigi Toscano wrote: Is a shipit really needed, given https://git.reviewboard.kde.org/r/115896/ ? I tend to err on the side of caution. If you're of the view that this should get shipped, you could always give it the shipit :-) - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/#review50553 --- On Feb. 19, 2014, 11:45 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115897/ --- (Updated Feb. 19, 2014, 11:45 p.m.) Review request for Build System, Extra Cmake Modules, KDE Frameworks, David Faure, Kevin Ottens, and Luigi Toscano. Repository: extra-cmake-modules Description --- Remove FindDocBook*.cmake These are only really useful to kdoctools, so they may as well live there. (NB: after looking at how kdoctools uses the information from these files, I suspect they won't even be needed for the compatibility macros that are intended to end up in kde4support). Diffs - find-modules/FindDocBookXML.cmake b6d623e4e5ca40cdda4c895a19a0dc273831703a find-modules/FindDocBookXSL.cmake a7320aed66b72c92f0286658e38b7fc32266790c Diff: https://git.reviewboard.kde.org/r/115897/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115956: More generic (renamed) DocBookXML4.cmake, few fixes
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115956/
---
(Updated Feb. 23, 2014, 3:02 p.m.)
Review request for Documentation and KDE Frameworks.
Changes
---
Add missing include(FeatureSummary) yo FindDocBook{XML,XSL}.cmake
Summary (updated)
-
More generic (renamed) DocBookXML4.cmake, few fixes
Repository: kdoctools
Description
---
This is the combination of two RR, now that
FindDocBookXML.cmake/FindDocBookXSL.cmake have been moved to kdoctools:
- https://git.reviewboard.kde.org/r/115876/
- https://git.reviewboard.kde.org/r/115879/
Combination of few commits:
1) More generic structure for FindDocBookXML
- allows modules to request a generic version of DocBook XML
- keep compatibility variables for now
(originally from 115876)
---
2) Rename as FindDocBookXML4, it will be used only for DocBook 4.x
The rename reflects the fact that it is used for DocBookXML4 only;
a future DocBookXML5 could be added if needed.
(originally from 115876)
Use the new module name in CMake files.
(originally from 115879)
3) New DocBookXML4_* variables, explicitly require the DocBookXML4 version
(originally from 115879)
4) Move DocBookXML4 DESCRIPTION and URL into the cmake file
5) Move DocBookXSL DESCRIPTION and URL into the cmake file
Diffs (updated)
-
CMakeLists.txt 5ad7099
cmake/FindDocBookXML.cmake b6d623e
cmake/FindDocBookXML4.cmake PRE-CREATION
cmake/FindDocBookXSL.cmake a7320ae
config-kdoctools.h.cmake f2fe22c
src/CMakeLists.txt 71a7d2e
src/customization/dtd/kdex.dtd.cmake c643d9b
Diff: https://git.reviewboard.kde.org/r/115956/diff/
Testing
---
Compiles, documentation is generated.
Thanks,
Luigi Toscano
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115956: More generic (renamed) DocBookXML4.cmake, few fixes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115956/#review50594 --- Ship it! Ship It! - Alex Merry On Feb. 23, 2014, 3:02 p.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115956/ --- (Updated Feb. 23, 2014, 3:02 p.m.) Review request for Documentation and KDE Frameworks. Repository: kdoctools Description --- This is the combination of two RR, now that FindDocBookXML.cmake/FindDocBookXSL.cmake have been moved to kdoctools: - https://git.reviewboard.kde.org/r/115876/ - https://git.reviewboard.kde.org/r/115879/ Combination of few commits: 1) More generic structure for FindDocBookXML - allows modules to request a generic version of DocBook XML - keep compatibility variables for now (originally from 115876) --- 2) Rename as FindDocBookXML4, it will be used only for DocBook 4.x The rename reflects the fact that it is used for DocBookXML4 only; a future DocBookXML5 could be added if needed. (originally from 115876) Use the new module name in CMake files. (originally from 115879) 3) New DocBookXML4_* variables, explicitly require the DocBookXML4 version (originally from 115879) 4) Move DocBookXML4 DESCRIPTION and URL into the cmake file 5) Move DocBookXSL DESCRIPTION and URL into the cmake file Diffs - CMakeLists.txt 5ad7099 cmake/FindDocBookXML.cmake b6d623e cmake/FindDocBookXML4.cmake PRE-CREATION cmake/FindDocBookXSL.cmake a7320ae config-kdoctools.h.cmake f2fe22c src/CMakeLists.txt 71a7d2e src/customization/dtd/kdex.dtd.cmake c643d9b Diff: https://git.reviewboard.kde.org/r/115956/diff/ Testing --- Compiles, documentation is generated. Thanks, Luigi Toscano ___ 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
2014-02-21 1:17 GMT+01:00 Andrius da Costa Ribas andrius...@gmail.com: Afaik only Alexander Richardson is currently working on KF5 on Windows, but I think this kcm module is more related to plasma-workspace destination, given the settings it provides (see attached image) Em 20/02/2014 14:47, Aleix Pol aleix...@kde.org escreveu: 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 Hi, I won't try to get this working, my only goal with the Windows effort is to be able to run Kate and Okteta on Windows so I can use them at work. This seems to be more about platform integration which I'm not interested in. Hopefully someone from the kde-windows team can pick this up. Developing on Windows is such a pain, I don't want to spend more time than necessary there. Once I have managed to get all frameworks (except kdesupport, since that has so many compile errors that I won't even try) to compile and pass the tests I will be back to Linux-only work. I will still run the tests every few days/weeks to make sure no regressions are introduced, but I don't feel like doing any more Windows work. Regards Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: CMake error compiling kde-runtime
On Sun, Feb 23, 2014 at 3:58 PM, David Faure fa...@kde.org wrote:
On Sunday 23 February 2014 11:05:16 David Gil Oliva wrote:
CMake Error at
/home/david/KF5/share/cmake-3.0/Modules/CMakeFindDependencyMacro.cmake:52
(find_package):
Could not find a configuration file for package KF5DesignerPlugin
that
is
compatible with requested version 5.2.
I just analyzed and reported this error on kde-buildsystem.
For now, git checkout v2.8.12.2 in your cmake git repo, or apply this
diff --git a/kf5-frameworks-build-include b/kf5-frameworks-build-include
index df4498a..c1cf637 100644
--- a/kf5-frameworks-build-include
+++ b/kf5-frameworks-build-include
@@ -13,6 +13,8 @@
module cmake-git
repository git://cmake.org/cmake.git
+# Workaround for broken find_dependency in cmake master right now
+tag v2.8.12.2
end module
module libdbusmenu-qt
or you can apply the attached patch ( thank to alex )
I ran into the same problem
--
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
--
Regards
Shivam Makkar
amourphious.appspot.com
From d9da7a712d331e647d94fc12162e2c4df29ca7eb Mon Sep 17 00:00:00 2001
From: Alex Merry k...@randomguy3.me.uk
Date: Sat, 22 Feb 2014 13:35:14 +
Subject: [PATCH] Fix settings of the version variable of find_dependency macro
It should be reset before use, as this is a macro, and the test should
be against ARGV1, not its value.
---
Modules/CMakeFindDependencyMacro.cmake | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Modules/CMakeFindDependencyMacro.cmake b/Modules/CMakeFindDependencyMacro.cmake
index 0f1f56d..6f7dbe8 100644
--- a/Modules/CMakeFindDependencyMacro.cmake
+++ b/Modules/CMakeFindDependencyMacro.cmake
@@ -29,7 +29,8 @@
macro(find_dependency dep)
if (NOT ${dep}_FOUND)
-if (${ARGV1})
+set(version)
+if (ARGV1)
set(version ${ARGV1})
endif()
set(exact_arg)
--
1.9.0
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: configuration file found with version 4.96.0 but version 5.2 is required by the KF5 buld
On Sat, Feb 22, 2014 at 9:01 PM, Alex Merry k...@randomguy3.me.uk wrote: On 21/02/14 16:01, Shivam Makkar wrote: Hi ! I was trying to build Kde-Framework 5 and got following CMake error while executing ./kdesrc-build. the error produces every time, for Kde-workspace and kde-rumtime, regarding config file found but with older version. /CMake Error at /home/amourphious/kf5/inst/share/cmake-3.0/Modules/CMakeFindDependencyMacro.cmake:52 (find_package):/ / Could not find a configuration file for package KF5Pty that is compatible/ / with requested version 5.2./ This is a bug in CMake. I've posted a patch to the cmake-developers list. You can wait for that to be applied, apply it yourself (attached), or use an older version of CMake (anything from the 2.8.12 series is fine). *Thanks Alex :)* [image: Inline image 1] Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel -- Regards Shivam Makkar amourphious.appspot.com inline: Give-that-Man-uq82wc.jpg___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: DocBookXML 4.5, the plan
El Dissabte, 22 de febrer de 2014, a les 16:52:38, Luigi Toscano va escriure: Hi all, these are the steps of plan for bumping the default DocBook XML version to 4.5 while keeping the compatibility on the old 4.2-based when kde4support is used: 1) commit rename/changes of FindDocBookXML (RR 115876 and 115879); 2) kde4support: copy files FindDocBookXML, catalog.xml, kdex.dtd to kde4support (with history, help or script from Alex Merry needed :) from kdoctools, remove the old compatibility variables, do not install kdex.dtd and catalog.xml for now, rename catalog.xml as catalog4.xml and remove the old content (leave only the definition of 4.2-based DTD). 3a) kdoctools: change the default DTD by renaming kdex.dtd and bumping DocBookXML version number to 4.5; 3b) kde4support: install catalog4.xml and kdex.dtd from kde4support 3c) other modules: fix the documentation of all ported modules to use the new DTD (4.5-based) (temporary breakages in Jenkins are possible). My question is: given the strict time before alpha2, do I need to sent out a RR for every step above (especially 3c), or can I just go and do the changes if you think the plan is fine? I'm not a huge part of the frameworks team, so feel free to ignore me, but sometimes i feel we're overdoing the review thing, i've seen changes that seem trivial to me and that seem to originate from the person that knows most of the code posted to reviewboard. And that's fine if there's people reivewing it in a timely manner but for some not so well known/reviewed places it can stall the flow a bit so personally I wouldn't mind if some things just are commited directly. But as said, that's just my kind of outside opinion :) Cheers, Albert Ciao ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Figuring out kde-runtime: localization
El Divendres, 21 de febrer de 2014, a les 13:17:58, Aleix Pol va escriure: 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. Who is we? Why are you asking the documentation list about this? Can anybody give us a hand and help us figure those out? - localization: has plenty of information regarding different currencies. Yes, used in kcurrencycode.cpp at least (which by the way says see KLocale, which is weird in the kunitconversion framework), I guess you could move it to the kunitconversion framework - l10n: has information about different countries. Yes, the existance of those entry.desktop files is checked by ./kio/src/core/global.cpp ./kconfigwidgets/src/klanguagebutton.cpp ./kxmlgui/src/khelpmenu.cpp ./kde4support/src/kdecore/klocale_kde.cpp If you want to deprecate those files you'll have to fix kio, kconfigwidgets and kxmlgui to use whatever localization system KF5 is planning to use and then move these files to kde4support. Should these go to KI18n? What do those files have to do with translations of strings? Qt? Anybody has plans for those? Cheers, Albert 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
kguiaddons uses qpa headers?
Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.cpp:26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? Cheers! John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Figuring out kde-runtime: localization
On 21 February 2014 13:17, Aleix Pol aleix...@kde.org wrote: 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 The l10n directory holds the locale config files for each country. These files get used by KLocale. The localization directory holds the currency config files used by KLocale and KCurrencyCode, as they couldn't go into l10n/ without messing up existing code, and the long-term plan was to move l10n/ into localization/ as a country/ sub-directory. In KF5 both KLocale and KCurrencyCode are in kde4support and have mostly been replaced by using QLocale. As such both l10n and localization are only required if kde4support is installed and used. I assume the files must now be moved into kde4support? Will we also need to think about what happens with parallel installs with KDE4? As Albert points out, there looks to be a couple of other places the files are used in KF5 code that will need porting to QLocale instead, or if they are only appropriate with KLocale then moving to kde4support. I'll try have a look later today. I have a separate email about locale configuration in Plasma Next that I'll post on the Plasma list a bit later. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Figuring out kde-runtime: localization
El Diumenge, 23 de febrer de 2014, a les 17:26:23, John Layt va escriure: On 21 February 2014 13:17, Aleix Pol aleix...@kde.org wrote: 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 The l10n directory holds the locale config files for each country. These files get used by KLocale. The localization directory holds the currency config files used by KLocale and KCurrencyCode, as they couldn't go into l10n/ without messing up existing code, and the long-term plan was to move l10n/ into localization/ as a country/ sub-directory. In KF5 both KLocale and KCurrencyCode are in kde4support KCurrencyCode is in kunitconversion. Cheers, Albert and have mostly been replaced by using QLocale. As such both l10n and localization are only required if kde4support is installed and used. I assume the files must now be moved into kde4support? Will we also need to think about what happens with parallel installs with KDE4? As Albert points out, there looks to be a couple of other places the files are used in KF5 code that will need porting to QLocale instead, or if they are only appropriate with KLocale then moving to kde4support. I'll try have a look later today. I have a separate email about locale configuration in Plasma Next that I'll post on the Plasma list a bit later. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Building frameworks: docbook problems
On 7 February 2014 10:01, David Faure fa...@kde.org wrote: On Monday 03 February 2014 22:08:20 Andriy Rysin wrote: I am trying to build frameworks using http://community.kde.org/Frameworks/Building on Fedora 20 and it failes in several modules due to some docbook problem, e.g. in kconfigwidgets: Scanning dependencies of target kstandardactiontest_automoc man-preparetips5.1.docbook:5: warning: failed to load external entity dtd/kdex.dtd ] ^ man-preparetips5.1.docbook:7: parser error : Entity 'language' not defined refentry lang=language; Did you set XDG_DATA_DIRS to contain yourkf5installprefix/share ? Just hit this myself using kdesrc-build, shouldn't it take care of it for me? Seems a little user unfriendly that it's the one envvar I have to set when kdesrc-build takes care of the rest for me? John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kguiaddons uses qpa headers?
On Sunday 23 February 2014 17:02:55 John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.cpp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? For kguiaddons there's an alternative, linking to QX11Extras (breaking the rules about the dependencies for an addon). This is starting to make me wonder if we couldn't change Qt to set a property on qApp with the values of Display* and/or xcb connection. But personally I would just link to QX11Extras. *However* note that another framework, called frameworkintegration, *does* require the private qpa headers, since it provides a platform theme plugin. No way around that there. You need to install the package with the Qt private headers. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Figuring out kde-runtime: localization
On 23 February 2014 17:31, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 23 de febrer de 2014, a les 17:26:23, John Layt va escriure: In KF5 both KLocale and KCurrencyCode are in kde4support KCurrencyCode is in kunitconversion. Ah, so it is, had missed that :-) So I guess the maintainer for kunitconversion needs to move the data files there? Now, who would that be... :-) I need to see how KCurrencyCode is being used there, and decide whether to keep it public or not. So, looking at the other users of the l10n files. kio/src/core/global.cpp - Uses them to find the default BinaryUnitDialect for the current locale, but all config files have the same default, so get rid of lookup and use same default until Qt adds support. kconfigwidgets/src/klanguagebutton.cpp - loadAllLanguages() loads the list of available languages from the config files, should probably just load the list of Qt languages? Or does it really mean the list of KDE translation languages? Perhaps we need load functions for both options, depending on the use its needed for? - Will we need a K4LanguageButton that has the old behaviour? kxmlgui/src/khelpmenu.cpp - Weird one, if there are any config files installed, then enables the Help/Switch Language menu item, but if you trigger the item it launches KSwitchLanguageDialog which looks for the installed translation languages for the app, which is a completely different thing. - KSwitchLanguageDialogPrivate::applicationLanguageList() needs to be made a KSwitchLanguageDialog static method that KHelpMenu can call to see if more than 1 language is available, and use that in place of the existing check. Once those changes are made, then the l10n files can go to kde4support. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting feedback: Hiding the Help button in KConfigDialog
On Sunday 23 February 2014 14:17:29 Kevin Krammer wrote: But usage of the button box already leaks, there are two protected accessors to it. In which class? You lost me. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115485: Porting KTranscript from KJS to QtScript
On Feb. 22, 2014, 3:24 p.m., Michael Palimaka wrote: If this is tier 1 now, please don't forget to update the wiki and the yaml file. Also find_dependency(KF5JS @KF5_VERSION@) can go away =) - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/#review50535 --- On Feb. 22, 2014, 2:15 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115485/ --- (Updated Feb. 22, 2014, 2:15 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Attempt at replacing the KJS dependency with a QtScript, i.e. making ki18n a tier1 framework. Needs more testing and likely fixing Diffs - autotests/CMakeLists.txt c4d6b9b src/CMakeLists.txt 9e3ce9f src/ktranscript.cpp b9e0551 CMakeLists.txt 06fb696 Diff: https://git.reviewboard.kde.org/r/115485/diff/ Testing --- Unittest runs, but the test script is very minimal and would need to be extendedb by someone who understands the scripting requirements. There is also a weird crash at test shutdown, in QThreadStorage. As far as I can tell I did not change anything related to threads though. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kguiaddons uses qpa headers?
On Sunday 23 February 2014 17:47:48 David Faure wrote: On Sunday 23 February 2014 17:02:55 John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.c pp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? For kguiaddons there's an alternative, linking to QX11Extras (breaking the rules about the dependencies for an addon). Well I wanted to use QX11Extras but was told to not use it for that reason ;-) This is starting to make me wonder if we couldn't change Qt to set a property on qApp with the values of Display* and/or xcb connection. I doubt that's a real solution as there are more things available in the native interface which might really be needed if one uses low level X11 code. But of course there's QX11Extras for that. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Runtime conflict with KF5Plasma and KDE 4 in same prefix
Hi, I have run into a strange issue when KDE 4 and KF5Plasma are installed into the same prefix (I can reliably reproduce the issue by installing/uninstalling KF5Plasma and restarting KDE). Simply, the vertical bar key | does not work - it prints nothing. If I run xev from konsole it detects the keypress, but in any other application it is as if I never pressed the key at all. Any ideas? Best regards, Michael ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Runtime conflict with KF5Plasma and KDE 4 in same prefix
On Monday 24 February 2014 05:33:37 Michael Palimaka wrote: Hi, I have run into a strange issue when KDE 4 and KF5Plasma are installed into the same prefix (I can reliably reproduce the issue by installing/uninstalling KF5Plasma and restarting KDE). Simply, the vertical bar key | does not work - it prints nothing. If I run xev from konsole it detects the keypress, but in any other application it is as if I never pressed the key at all. Any ideas? we hit this problem last week and figured out that it seems to be kglobalacceld. Try killing the 5 variant and see whether it fixes it. Cheers Martin signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kprintutils - next steps
Hi, I've just merged my clean-ups for kprintutils to remove everything not needed due to the changes in Qt5. Basically what is now left is so minimal that I see no benefit in keeping it as a framework and propose we move it to kde4support instead. There are two parts to kprintutils: 1) The KdePrint::createPrintDialog() static methods. These used to add standard KDE add-on tabs to the dialog to implement missing CUPS features. With these features moved to Qt, this code is nothing more than syntactic sugar for an app adding its own tabs. We could keep kprintutils in case we add new features in the future, such as poster printing like KPrinter4 does, but I'd rather put the effort into finding a nice way to do that in Qt itself. 2) KPrintPreview. This uses KParts to preview the document as a pdf in the Okular part, however it lacks many features found in QPrintPreview which wasn't available when 4.0 was released. Many apps have already voted with their feet (Kate, Calligra, etc) and I'd rather put the effort into QPrintPreview if any changes are needed. I believe the steps required are: 1) Port existing apps that are already ported to KF5 away from KdePrint::createPrintDialog(): - Okteta - kfontinst - ktexteditor - None use KPrintPreview 2) Copy code from kprintutils to kde4support - Do we bother to keep the history? - Where do we put it? 3) Update porting guide 4) Update dependencies/kdesrc-build, etc? 5) Delete kprintutils repo 6) Find me something else to maintain... Thoughts? John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Porting feedback: Hiding the Help button in KConfigDialog
On Sunday, 2014-02-23, 18:41:38, David Faure wrote: On Sunday 23 February 2014 14:17:29 Kevin Krammer wrote: But usage of the button box already leaks, there are two protected accessors to it. In which class? You lost me. KPageDialog, base class of KConfigDialog according to the API docs http://api.kde.org/frameworks-api/frameworks5-apidocs/kwidgetsaddons/html/classKPageDialog.html Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115977: RFC: Install KArchive as Mac OS X Framework
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115977/ --- Review request for KDE Frameworks. Repository: karchive Description --- Change CMakeLists.txt to create Mac OS X frameworks Diffs - CMakeLists.txt f5dc644fdba13e29c94940c77d628e92e0759787 src/CMakeLists.txt 53e97284cab199f5eb75aa276adfadc18d677682 src/karchive.h d4209cf334190dda735fcb4687fa102a4e7a73cd src/karchivedirectory.h 60225d0be9fc2e28ff2b998dcc8fb28512c6e3cd src/karchiveentry.h aad6840ee0dc22e5760ddda99ce975a1d9a9dc92 src/karchivefile.h c7d2e0e0735f75a8e490082aa8598fd08206a998 src/ktar.h 4bca89884e646ffae90aa1a9e15a985e998e843f Diff: https://git.reviewboard.kde.org/r/115977/diff/ Testing --- 'make install' on Mac OS X Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kguiaddons uses qpa headers?
On Sunday, 2014-02-23, 17:02:55, John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.cpp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? I am not sure it is wise to consider the QPA headers as private, most of them are not. QPlatformInterface, for example, is clearly an exposed type, there is an accessor in QGuiApplication that returns a pointer to it. Obviously the returned object and its functionality is platform specific, but afterall its very purpose is to enable platform integration that goes beyond the things that can be wrapped in an abstraction across multiple platforms. Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Mac OS X Frameworks Frameworks
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
diff --git a/CMakeLists.txt b/CMakeLists.txt
index f5dc644..0c59012 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -53,6 +53,8 @@ ecm_setup_version(${KF5_VERSION}
PACKAGE_VERSION_FILE
${CMAKE_CURRENT_BINARY_DIR}/KF5ArchiveConfigVersion.cmake
)
+list(APPEND KArchive_GENERATED_HEADERS
${CMAKE_CURRENT_BINARY_DIR}/karchive_version.h)
+
add_subdirectory(src)
add_subdirectory(autotests)
add_subdirectory(tests)
@@ -69,10 +71,6 @@ ecm_configure_package_config_file(
INSTALL_DESTINATION ${CMAKECONFIG_INSTALL_DIR}
)
-install(FILES ${CMAKE_CURRENT_BINARY_DIR}/karchive_version.h
-DESTINATION ${INCLUDE_INSTALL_DIR}
-COMPONENT Devel)
-
install(FILES
${CMAKE_CURRENT_BINARY_DIR}/KF5ArchiveConfig.cmake
${CMAKE_CURRENT_BINARY_DIR}/KF5ArchiveConfigVersion.cmake
diff --git a/src/CMakeLists.txt b/src/CMakeLists.txt
index 53e9728..2eaa05f 100644
--- a/src/CMakeLists.txt
+++ b/src/CMakeLists.txt
@@ -34,7 +34,27 @@ set(karchive_SRCS
kzip.cpp
)
-add_library(KF5Archive ${karchive_SRCS} ${karchive_OPTIONAL_SRCS})
+ecm_generate_headers(KArchive_HEADERS
+HEADER_NAMES
+KArchive
+KArchiveEntry
+KArchiveFile
+KArchiveDirectory
+KAr
+KCompressionDevice
+KFilterBase
+KFilterDev
+KTar
+KZip
+KZipFileEntry
+
+REQUIRED_HEADERS KArchive_HEADERS
+)
+
+list(APPEND KArchive_GENERATED_HEADERS
${CMAKE_CURRENT_BINARY_DIR}/karchive_export.h)
+
+add_library(KF5Archive ${karchive_SRCS} ${karchive_OPTIONAL_SRCS}
${KArchive_HEADERS} ${KArchive_GENERATED_HEADERS})
+set_target_properties(KF5Archive PROPERTIES FRAMEWORK TRUE)
generate_export_header(KF5Archive BASE_NAME KArchive)
add_library(KF5::Archive ALIAS KF5Archive)
@@ -56,25 +76,12 @@ set_target_properties(KF5Archive PROPERTIES
EXPORT_NAME Archive
)
-ecm_generate_headers(KArchive_HEADERS
-HEADER_NAMES
-KArchive
-KArchiveEntry
-KArchiveFile
-KArchiveDirectory
-KAr
-KCompressionDevice
-KFilterBase
-KFilterDev
-KTar
-KZip
-KZipFileEntry
-
-REQUIRED_HEADERS KArchive_HEADERS
-)
+set_target_properties(KF5Archive PROPERTIES PUBLIC_HEADER
${KArchive_HEADERS};${KArchive_GENERATED_HEADERS})
install(TARGETS KF5Archive
EXPORT KF5ArchiveTargets
+FRAMEWORK DESTINATION ${LIB_INSTALL_DIR}
+PUBLIC_HEADER DESTINATION ${INCLUDE_INSTALL_DIR}/KArchive
${INSTALL_TARGETS_DEFAULT_ARGS})
if(LIBLZMA_FOUND)
@@ -85,12 +92,6 @@ if(LIBLZMA_FOUND)
)
endif()
-install(FILES
-${CMAKE_CURRENT_BINARY_DIR}/karchive_export.h
-${KArchive_HEADERS}
-DESTINATION ${INCLUDE_INSTALL_DIR}/KArchive
-COMPONENT Devel)
-
include(ECMGeneratePriFile)
ecm_generate_pri_file(
BASE_NAME KArchive
diff --git a/src/karchive.h b/src/karchive.h
index d4209cf..a75d240 100644
--- a/src/karchive.h
+++ b/src/karchive.h
@@ -29,7 +29,7 @@
#include QtCore/QStringList
#include QtCore/QHash
-#include karchive_export.h
+#include karchive_export.h
#ifdef Q_OS_WIN
#include qplatformdefs.h // mode_t
diff --git a/src/karchivedirectory.h b/src/karchivedirectory.h
index 60225d0..d234fc8 100644
--- a/src/karchivedirectory.h
+++ b/src/karchivedirectory.h
@@ -28,7 +28,7 @@
#include QtCore/QString
#include QtCore/QStringList
-#include karchiveentry.h
+#include karchiveentry.h
class KArchiveDirectoryPrivate;
/**
diff --git a/src/karchiveentry.h b/src/karchiveentry.h
index aad6840..d5c68a9 100644
--- a/src/karchiveentry.h
+++ b/src/karchiveentry.h
@@ -24,7 +24,7 @@
#include sys/stat.h
#include sys/types.h
-#include karchive_export.h
+#include karchive_export.h
#ifdef Q_OS_WIN
#include qplatformdefs.h //
Review Request 115979: Cleanup after QtScript port
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/ --- Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Update framework tier. Remove unused enum. Remove no longer applicable search for KJS. Consistent block braces for if statements. Diffs - KF5I18nConfig.cmake.in 7225bf5 ki18n.yaml 9b601d5 src/ktranscript.cpp 4cdae75 Diff: https://git.reviewboard.kde.org/r/115979/diff/ Testing --- Everything still builds and tests succeed. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115982: Add a tool that creates a Mac OS X icns (icon) file from a svg file
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115982/ --- Review request for KDE Frameworks and Christoph Feck. Repository: kiconthemes Description --- This is a small tool that generates Mac OS X icon files from (oxygen) svg[z] files. Diffs - src/CMakeLists.txt 76932ca87c7de2dc25398e1fca8916426ce7e566 src/tools/ksvg2icns/CMakeLists.txt PRE-CREATION src/tools/ksvg2icns/ksvg2icns.cpp PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115982/diff/ Testing --- Builds on Mac OS X Thanks, Harald Fernengel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115979: Cleanup after QtScript port
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/#review50612 --- Ship it! Ship It! - Chusslove Illich On Feb. 23, 2014, 8:58 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/ --- (Updated Feb. 23, 2014, 8:58 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Update framework tier. Remove unused enum. Remove no longer applicable search for KJS. Consistent block braces for if statements. Diffs - KF5I18nConfig.cmake.in 7225bf5 ki18n.yaml 9b601d5 src/ktranscript.cpp 4cdae75 Diff: https://git.reviewboard.kde.org/r/115979/diff/ Testing --- Everything still builds and tests succeed. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Building frameworks: docbook problems
On Sun, February 23, 2014 17:45:01 John Layt wrote: On 7 February 2014 10:01, David Faure fa...@kde.org wrote: On Monday 03 February 2014 22:08:20 Andriy Rysin wrote: I am trying to build frameworks using http://community.kde.org/Frameworks/Building on Fedora 20 and it failes in several modules due to some docbook problem, e.g. in kconfigwidgets: Scanning dependencies of target kstandardactiontest_automoc man-preparetips5.1.docbook:5: warning: failed to load external entity dtd/kdex.dtd ] ^ man-preparetips5.1.docbook:7: parser error : Entity 'language' not defined refentry lang=language; Did you set XDG_DATA_DIRS to contain yourkf5installprefix/share ? Just hit this myself using kdesrc-build, shouldn't it take care of it for me? Seems a little user unfriendly that it's the one envvar I have to set when kdesrc-build takes care of the rest for me? Yes, it should take care of it for you. And as of now, it does. Regards, - Michael Pyne ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115979: Cleanup after QtScript port
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/ --- (Updated Feb. 23, 2014, 9:25 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Update framework tier. Remove unused enum. Remove no longer applicable search for KJS. Consistent block braces for if statements. Diffs - KF5I18nConfig.cmake.in 7225bf5 ki18n.yaml 9b601d5 src/ktranscript.cpp 4cdae75 Diff: https://git.reviewboard.kde.org/r/115979/diff/ Testing --- Everything still builds and tests succeed. Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115979: Cleanup after QtScript port
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/#review50613 --- This review has been submitted with commit 463f76bc765e9fc9279a19ab29da9e1024f927f9 by Kevin Krammer to branch master. - Commit Hook On Feb. 23, 2014, 7:58 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115979/ --- (Updated Feb. 23, 2014, 7:58 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Update framework tier. Remove unused enum. Remove no longer applicable search for KJS. Consistent block braces for if statements. Diffs - KF5I18nConfig.cmake.in 7225bf5 ki18n.yaml 9b601d5 src/ktranscript.cpp 4cdae75 Diff: https://git.reviewboard.kde.org/r/115979/diff/ Testing --- Everything still builds and tests succeed. Thanks, Kevin Krammer ___ 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 23 February 2014 20:15, Harald Fernengel har...@gmx.com wrote: TL;DR Do we want to do build KDE Frameworks as Mac OS X Frameworks? I think so, at least for the ones we want to be viewed as proper Qt Add-ons, it would enlarge our possible user-base. From experience in Qt the hard part is keeping the includes conforming, the rules would have to be well advertised and put in the coding standards. We really need a CI machine testing the build on OSX to make sure people don't keep breaking it. John. ___ 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 23 February 2014 20:15, Harald Fernengel har...@gmx.com wrote: Hi, TL;DR Do we want to do build KDE Frameworks as Mac OS X Frameworks? I think so, at least for the ones we want to be viewed as proper Qt Add-ons, it would enlarge our possible user-base. From experience in Qt the hard part is keeping the includes conforming, the rules would have to be well advertised and put in the coding standards. We really need a CI machine testing the build on OSX to make sure people don't keep breaking it. John. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/#review50614 --- It is obviously not really a leak since the KTranscriptImp object is never deleted during runtime. So this just cleans up before process exit - Kevin Krammer On Feb. 23, 2014, 9:52 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- (Updated Feb. 23, 2014, 9:52 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/#review50615 --- It is obviously not really a leak since the KTranscriptImp object is never deleted during runtime. So this just cleans up before process exit - Kevin Krammer On Feb. 23, 2014, 9:52 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- (Updated Feb. 23, 2014, 9:52 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/#review50616 --- Ship it! Ship It! - Chusslove Illich On Feb. 23, 2014, 10:52 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- (Updated Feb. 23, 2014, 10:52 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- (Updated Feb. 23, 2014, 10:14 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115983: Reduce memory leaks
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/#review50617 --- This review has been submitted with commit b0a60d0feb2dcac7af5f921be830bc4d9b9d3d18 by Kevin Krammer to branch master. - Commit Hook On Feb. 23, 2014, 9:52 p.m., Kevin Krammer wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115983/ --- (Updated Feb. 23, 2014, 9:52 p.m.) Review request for KDE Frameworks and Chusslove Illich. Repository: ki18n Description --- Create the script engine as a QObject child of the interface and delete all interfaces in KTranscriptImp's destructor. valgrind --tool=memcheck ./ktranscripttest before: ==10664== HEAP SUMMARY: ==10664== in use at exit: 445,913 bytes in 2,753 blocks ==10664== total heap usage: 27,995 allocs, 25,242 frees, 6,059,328 bytes allocated ==10664== ==10664== LEAK SUMMARY: ==10664==definitely lost: 0 bytes in 0 blocks ==10664==indirectly lost: 0 bytes in 0 blocks ==10664== possibly lost: 1,488 bytes in 3 blocks ==10664==still reachable: 444,425 bytes in 2,750 blocks ==10664== suppressed: 0 bytes in 0 blocks after: ==11788== HEAP SUMMARY: ==11788== in use at exit: 13,778 bytes in 66 blocks ==11788== total heap usage: 28,003 allocs, 27,937 frees, 6,064,040 bytes allocated ==11788== ==11788== LEAK SUMMARY: ==11788==definitely lost: 0 bytes in 0 blocks ==11788==indirectly lost: 0 bytes in 0 blocks ==11788== possibly lost: 1,488 bytes in 3 blocks ==11788==still reachable: 12,290 bytes in 63 blocks ==11788== suppressed: 0 bytes in 0 blocks Diffs - src/ktranscript.cpp 1ce0d1a Diff: https://git.reviewboard.kde.org/r/115983/diff/ Testing --- All tests still run successfully Thanks, Kevin Krammer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
On Feb. 15, 2014, 7:38 p.m., David Faure wrote:
src/khistorycombobox.cpp, line 508
https://git.reviewboard.kde.org/r/115710/diff/1/?file=243810#file243810line508
infinite recursion!
Sounds like a unittest for reset() should be added.
There are two reset() methods, the private slot and the public method, which
only calls the private slot. My error was not calling the d-pointer method:
void KHistoryComboBox::reset()
{
Q_D(KHistoryComboBox);
d-reset();
}
Maybe the private slot could be substituted by the public method (making it a
public slot)?
By the way, I would need a hint about the unittest that you think that should
be added.
- David
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115710/#review49866
---
On Feb. 12, 2014, 11:28 p.m., David Gil Oliva wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115710/
---
(Updated Feb. 12, 2014, 11:28 p.m.)
Review request for KDE Frameworks.
Repository: kcompletion
Description
---
Hide private methods and slots behind the d-pointer in KHistoryComboBox
Also:
-Remove header not used
Diffs
-
src/khistorycombobox.h 3667eb4
src/khistorycombobox.cpp 6f81dda
Diff: https://git.reviewboard.kde.org/r/115710/diff/
Testing
---
It builds. Tests pass.
Thanks,
David Gil Oliva
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115710: Hide private methods and slots behind the d-pointer in KHistoryComboBox
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115710/ --- (Updated Feb. 23, 2014, 11:23 p.m.) Review request for KDE Frameworks. Changes --- Address David Faure's comments. Repository: kcompletion Description --- Hide private methods and slots behind the d-pointer in KHistoryComboBox Also: -Remove header not used Diffs (updated) - src/khistorycombobox.h 3667eb4 src/khistorycombobox.cpp 6f81dda Diff: https://git.reviewboard.kde.org/r/115710/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115984: Implement the d-pointer in KCompletionBase as in the other classes
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115984/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Implement the d-pointer in KCompletionBase as in the other classes Add two methods: setEmitSignals(bool) and setKeybindingsMap(KeyBindingMap) to be called from setDelegate(). Otherwise, it doesn't seem plausible to reach the private member variables like this (the compiler complains): delegate-d-emitsRotationSignals = d-emitsRotationSignals; Now that has become: delegate-setEmitSignals(d-emitsRotationSignals); For coherence, implement the QScopedPointer and the init() method. Diffs - src/kcompletionbase.h 105a6d0 src/kcompletionbase.cpp 66f9398 Diff: https://git.reviewboard.kde.org/r/115984/diff/ Testing --- It builds. Tests pass. Thanks, David Gil Oliva ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: 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: kguiaddons uses qpa headers?
On Sunday 23 February 2014 17:47:48 David Faure wrote: On Sunday 23 February 2014 17:02:55 John Layt wrote: Hi, I'm building all of Frameworks from scratch for the first time, using the openSUSE packages for Qt 5.2, and qguiaddons fails with: [ 24%] Building CXX object src/CMakeFiles/KF5GuiAddons.dir/util/kmodifierkeyinfoprovider_x11.cpp.o /media/build/kdesrc- build/src/k5/frameworks/kguiaddons/src/util/kmodifierkeyinfoprovider_x11.c pp :26:42: fatal error: qpa/qplatformnativeinterface.h: No such file or directory This is because qpa headers are considered private and are packaged separately by openSUSE. I'm not sure depending on private/qpa headers is such a good thing? Or is there no other option here? For kguiaddons there's an alternative, linking to QX11Extras (breaking the rules about the dependencies for an addon). This is starting to make me wonder if we couldn't change Qt to set a property on qApp with the values of Display* and/or xcb connection. But personally I would just link to QX11Extras. Still you were the one with the very strict view on the *addons ones. :-) Let's go for QX11Extras, but it has to be an optional dependency. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Mac OS X Frameworks Frameworks
Hello, On Monday 24 February 2014 02:49:45 Aleix Pol wrote: 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. I agree with all the above. 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. Not a good reason to not do it though. At the end of the day we'll need the CI to provide windows and mac builds somehow... until then yes it'll be more painful than necessary on those platforms. Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is a digitally signed message part. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
