Re: Review Request 115347: Remove Qt5Xml dependency
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115347/ --- (Updated Jan. 28, 2014, 8:39 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcompletion Description --- Remove Qt5Xml dependency Not needed, no? Diffs - CMakeLists.txt 94afe9f5f414a437e519242026ebaf2a838ffc88 Diff: https://git.reviewboard.kde.org/r/115347/diff/ Testing --- Thanks, Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Splitting kde-workspace and kde-runtime proposal
On Monday 27 January 2014 15:21:05 David Edmundson wrote: There is an existing page about slitting runtime here: http://community.kde.org/Frameworks/Epics/New_Runtime_Organization linked to from http://community.kde.org/Frameworks/Epics Alex's wiki page looks far more populated. We should make sure we avoid wiki duplication. Yeah, Alex, can you look into merging the two tables? Then I'll go through and fill in info about the stuff I know about. -- 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: Splitting kde-workspace and kde-runtime proposal
On Thursday 23 January 2014 16:08:51 andrea diamantini wrote: I don't clearly understand why KUriFilter-Plugins should go to plasma- workspace. I noticed KUriFilter is defined in kio and its plugins are used e.g. in kparts (browserextension). Shouldn't these go to kio? Agreed. They are needed for kio-based webbrowsers in any workspace. -- 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 115207: Improve integration QCommandLineParser - KAboutData
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review48455 --- I agree with Kévin: this doesn't match what the function name says it does. Better make it a separate function. - David Faure On Jan. 21, 2014, 11:36 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Jan. 21, 2014, 11:36 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp f24006b Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ 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 : ktexteditor_master_qt5 #170
See http://build.kde.org/job/ktexteditor_master_qt5/170/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115345: Fix kimageformats build with MSVC
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115345/#review48461
---
Ship it!
Hmm, it now appears that PIC was already broken. But your patch at least makes
it broken in the same way as before... *adds to TODO list*
- Alex Merry
On Jan. 27, 2014, 11:40 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115345/
---
(Updated Jan. 27, 2014, 11:40 p.m.)
Review request for KDE Frameworks and Alex Merry.
Repository: kimageformats
Description
---
1) Use #pragma pack instead of __attribute__((packed))
This is available on all supported compilers, the attribute does not exist
for MSVC
--
2) Use q{To,From}BigEndian instead of hton* and ntoh*
These functions don't seem to be available as inline functions on win32
Diffs
-
src/imageformats/pcx.cpp e0af73b4cac30afcc158e094cd6554a6e4b59388
src/imageformats/pic_read.cpp 42432185c362497efd596a8ce4f1cdae283ed294
src/imageformats/pic_write.cpp 99cd6a1ccff04fdeee4a3b5c2b3d76d9fd89ca71
Diff: https://git.reviewboard.kde.org/r/115345/diff/
Testing
---
didn't compile before, does now
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 114997: Improve KAuth README.md
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/114997/ --- (Updated Jan. 28, 2014, 11:48 a.m.) Review request for KDE Frameworks and Dario Freddi. Repository: kauth Description --- Improve KAuth README.md Diffs (updated) - README.md a8a011a147d2dcc0fb5db39e263412005a86def4 Diff: https://git.reviewboard.kde.org/r/114997/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: Allow the building of deprecated code to be disabled
On Jan. 27, 2014, 2:14 a.m., Aleix Pol Gonzalez wrote:
Shouldn't we maybe just remove these? Especially considerign they already
are deprecated in kdelibs 4.
I don't really like disabling compilation of deprecated symbols, especially
in this case we're not winning that much.
Kevin Ottens wrote:
The better approach would be to make it inline so that it's not in the
cpp file at all:
#ifndef KDE_NO_DEPRECATED
QString fullName() const { return property(KUser::FullName); }
#endif
If we don't want the option of disabling compilation, why are we using the
#ifndef construction at all?
What about the other parts of this, like replacing KDE_NO_DEPRECATED with
KCOREADDONS_NO_DEPRECATED and supressing deprecation warnings while building
with the KCOREADDONS_DEPRECATED= definition?
- Alex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115028/#review48324
---
On Jan. 15, 2014, 1:56 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115028/
---
(Updated Jan. 15, 2014, 1:56 p.m.)
Review request for KDE Frameworks.
Repository: kcoreaddons
Description
---
This is mostly an example of how we could improve the deprecation handling.
There are two parts: preventing deprecation warnings when building the
library itself (see
http://build.kde.org/view/Frameworks/job/kwidgetsaddons_master_qt5/11/warnings17Result/NORMAL/package.-1402078525/
for examples) and allowing the framework to be built with no deprecated code.
We possibly want to export the fact that the framework was built without
deprecated code via the CMake config file, so that downstream stuff (like
kde4support) can check for it and complain if necessary.
Allow the building of deprecated code to be disabled
This adds a CMake option to enable or disable the building of deprected
code. It just changes the kcoreaddons_export.h file.
Part of this change is to use KCOREADDONS_NO_DEPRECATED instead of
KDE_NO_DEPRECATED.
Disable deprecation macro when building the library itself
This prevents spurious compiler warnings (particularly when slots are
deprecated).
Diffs
-
src/lib/CMakeLists.txt 8cc71f34e671962f2d7268b3db0d50e6750c26a2
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
---
Thanks,
Alex Merry
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Where to put QML Bindings for KDE frameworks?
For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. Original thread on plasma-devel here: http://mail.kde.org/pipermail/plasma-devel/2014-January/028162.html Discuss. David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Tue, Jan 28, 2014 at 12:58 PM, David Edmundson da...@davidedmundson.co.uk wrote: For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. My preference is each component providing it's own import if it has them. So KIO providing an import with KIO specific QML stuff (org.kde.kio?). But that's just the ideal scenario. ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115353: Rename dbus interface files for solid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115353/ --- Review request for KDE Frameworks. Repository: solid Description --- The dbus interface files installed by solid conflict with those installed by kdelib4. To allow co-installability of kde4 and kf5, rename the former by using the same approach adopted for kglobalaccess, kjobviewer, etc. Diffs - src/solid/CMakeLists.txt 84c254e Diff: https://git.reviewboard.kde.org/r/115353/diff/ Testing --- Builds and installs fine. I am not an expert of dbus interface files and cmake, so please check that this patch does not produce unwanted side-effects. Thanks, Stefano Avallone ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Tue, Jan 28, 2014 at 12:58 PM, David Edmundson da...@davidedmundson.co.uk wrote: For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. Original thread on plasma-devel here: http://mail.kde.org/pipermail/plasma-devel/2014-January/028162.html Discuss. David ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel Well, there are many different needs, so we'll probably want to have different solutions for them. Bindings to interact with each framework, I'd say they should be installed by the framework itself, but that's only one case. I think we probably want a KQuickAddons as well, to put the components we create to extend Qt. (for example, this component you created for bindings). Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115207: Improve integration QCommandLineParser - KAboutData
On Jan. 27, 2014, 7:45 a.m., Kevin Ottens wrote: src/lib/kaboutdata.cpp, line 941 https://git.reviewboard.kde.org/r/115207/diff/1/?file=235099#file235099line941 Not really my type of thing. It's acting on an object behind our back without knowing... what happens to code where setApplication* was called before? Information would be lost and it's not obvious to the user. Looks dangerous to me. If we want to factorize the qApp call, and I see the need for that indeed, then that block should be provided by a separate method (setupApplication(QCoreApplication *)?). I agree, I only did it this way to avoid the required set up. An alternative would be to make KAboutData to pass the information to Q*Application when it's initialized (and if it's an application KAboutData...). - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/#review48347 --- On Jan. 21, 2014, 11:36 p.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115207/ --- (Updated Jan. 21, 2014, 11:36 p.m.) Review request for KDE Frameworks. Repository: kcoreaddons Description --- Let the KAboutData set information to QApplication. This way we don't have to duplicate information by passing it to the KAboutData _and_ the QApplication. Diffs - src/lib/kaboutdata.h c9e src/lib/kaboutdata.cpp f24006b Diff: https://git.reviewboard.kde.org/r/115207/diff/ Testing --- Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: add test for QFileDialog::getExistingDirectory / bug?
Am Sonntag, 26. Januar 2014, 18:53:42 schrieb Gregor Mi: With another addition to qfiledialogtest in frameworks/frameworkintegration another potential bug can be exposed: Calling $ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h) --selectNameFilter h (*.h) Works for me. Using Qt 5.2.0, if that matters. does not select the second filter. Can this be confirmed or maybe I am using the API wrong? Gregor On 26/01/14 17:15, Gregor Mi wrote: Hi, with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for QFileDialog::getExistingDirectory. When I execute ./qfiledialogtest --staticFunction getExistingDirectory then a dialog opens that lets the user select files but not directories. This seems to be a bug. Greetings Gregor -- Kevin Funk ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115353: Rename dbus interface files for solid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115353/ --- (Updated Jan. 28, 2014, 2:12 p.m.) Review request for KDE Frameworks. Repository: solid Description (updated) --- The dbus interface files installed by solid conflict with those installed by kdelib4. To allow co-installability of kde4 and kf5, rename the former by using the same approach adopted for kglobalaccess, kjobviewer, etc. If this patch seems reasonable, I will submit the companion patch for kde-workspace. Diffs - src/solid/CMakeLists.txt 84c254e Diff: https://git.reviewboard.kde.org/r/115353/diff/ Testing --- Builds and installs fine. I am not an expert of dbus interface files and cmake, so please check that this patch does not produce unwanted side-effects. Thanks, Stefano Avallone ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115353: Rename dbus interface files for solid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115353/#review48476 --- What does this have that https://git.reviewboard.kde.org/r/114927/ doesn't? - Jonathan Riddell On Jan. 28, 2014, 2:12 p.m., Stefano Avallone wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115353/ --- (Updated Jan. 28, 2014, 2:12 p.m.) Review request for KDE Frameworks. Repository: solid Description --- The dbus interface files installed by solid conflict with those installed by kdelib4. To allow co-installability of kde4 and kf5, rename the former by using the same approach adopted for kglobalaccess, kjobviewer, etc. If this patch seems reasonable, I will submit the companion patch for kde-workspace. Diffs - src/solid/CMakeLists.txt 84c254e Diff: https://git.reviewboard.kde.org/r/115353/diff/ Testing --- Builds and installs fine. I am not an expert of dbus interface files and cmake, so please check that this patch does not produce unwanted side-effects. Thanks, Stefano Avallone ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115353: Rename dbus interface files for solid
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115353/ --- (Updated Jan. 28, 2014, 2:28 p.m.) Status -- This change has been discarded. Review request for KDE Frameworks. Repository: solid Description --- The dbus interface files installed by solid conflict with those installed by kdelib4. To allow co-installability of kde4 and kf5, rename the former by using the same approach adopted for kglobalaccess, kjobviewer, etc. If this patch seems reasonable, I will submit the companion patch for kde-workspace. Diffs - src/solid/CMakeLists.txt 84c254e Diff: https://git.reviewboard.kde.org/r/115353/diff/ Testing --- Builds and installs fine. I am not an expert of dbus interface files and cmake, so please check that this patch does not produce unwanted side-effects. Thanks, Stefano Avallone ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115353: Rename dbus interface files for solid
On Jan. 28, 2014, 2:25 p.m., Jonathan Riddell wrote: What does this have that https://git.reviewboard.kde.org/r/114927/ doesn't? Pardon me. I somehow missed that review request. - Stefano --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115353/#review48476 --- On Jan. 28, 2014, 2:28 p.m., Stefano Avallone wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115353/ --- (Updated Jan. 28, 2014, 2:28 p.m.) Review request for KDE Frameworks. Repository: solid Description --- The dbus interface files installed by solid conflict with those installed by kdelib4. To allow co-installability of kde4 and kf5, rename the former by using the same approach adopted for kglobalaccess, kjobviewer, etc. If this patch seems reasonable, I will submit the companion patch for kde-workspace. Diffs - src/solid/CMakeLists.txt 84c254e Diff: https://git.reviewboard.kde.org/r/115353/diff/ Testing --- Builds and installs fine. I am not an expert of dbus interface files and cmake, so please check that this patch does not produce unwanted side-effects. Thanks, Stefano Avallone ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115355: Import the WebP image I/O code from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/ --- (Updated Jan. 28, 2014, 2:57 p.m.) Review request for KDE Frameworks. Repository: kimageformats Description --- Import the WebP image I/O code from kde-runtime The plugin export mechanism has been patched up (including the addition of the JSON file), and the FindWebP.cmake file is new. Writing is currently disabled, as it produces broken images. Diffs - cmake/FindWebP.cmake PRE-CREATION src/imageformats/CMakeLists.txt 242753e0b2c493bbf1da9654967494415e8249d8 src/imageformats/webp.cpp PRE-CREATION src/imageformats/webp.desktop PRE-CREATION src/imageformats/webp.h PRE-CREATION src/imageformats/webp.json PRE-CREATION src/imageformats/webp.xml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115355/diff/ Testing --- Compiles; installs; the imageconverter test utility manages to convert from webp fine (PNG results checked in Gwenview from KDE4). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115355: Import the WebP image I/O code from kde-runtime
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115355/ --- Review request for KDE Frameworks and Alex Merry. Repository: kimageformats Description --- Import the WebP image I/O code from kde-runtime The plugin export mechanism has been patched up (including the addition of the JSON file), and the FindWebP.cmake file is new. Writing is currently disabled, as it produces broken images. Diffs - cmake/FindWebP.cmake PRE-CREATION src/imageformats/CMakeLists.txt 242753e0b2c493bbf1da9654967494415e8249d8 src/imageformats/webp.cpp PRE-CREATION src/imageformats/webp.desktop PRE-CREATION src/imageformats/webp.h PRE-CREATION src/imageformats/webp.json PRE-CREATION src/imageformats/webp.xml PRE-CREATION Diff: https://git.reviewboard.kde.org/r/115355/diff/ Testing --- Compiles; installs; the imageconverter test utility manages to convert from webp fine (PNG results checked in Gwenview from KDE4). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
On Tuesday 28 January 2014, Aleix Pol wrote: Well, there are many different needs, so we'll probably want to have different solutions for them. Bindings to interact with each framework, I'd say they should be installed by the framework itself, but that's only one case. I think we probably want a KQuickAddons as well, to put the components we create to extend Qt. (for example, this component you created for bindings). thats what qtextracomponets was created for. is just to see in what repository to put it -- Marco Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115358: Remove the --logfile-dir option, and instead always create a logfile
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115358/ --- Review request for KDE Frameworks, Aurélien Gâteau and Allen Winter. Repository: kapidox Description --- The options were getting a bit out of hand, and the warnings get lost in doxygen's output, so: Remove the --logfile-dir option, and instead always create a logfile Doxygen warnings will go into a file called doxygen-warnings.log in the apidocs directory. Diffs - src/kapidox/__init__.py c89e06fdc2385f07b074b14574c1e62900723cab src/kgenframeworksapidox d41f35fdb3c6a490c95e18898689206022d8b966 Diff: https://git.reviewboard.kde.org/r/115358/diff/ Testing --- kgenapidox tested with python2 and python3 (on karchive). kgenframeworksapidox tested with python2 and python3, at least for the first few modules. 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 115332: Add a --quiet option
On Jan. 27, 2014, 5:37 p.m., Aurélien Gâteau wrote: Looks good, but I would suggest using Python logging module instead of writing our own. Basic usage should be as simple as: # setup import logging ... parse args... if args.quiet: minlevel = logging.WARNING else: minlevel = logging.INFO logging.basicConfig(level=minlevel, format='%(asctime)s:%(levelname)s: %(message)s') # then use it like this logging.info(Foo) logging.error(Something went wrong!) Alex Merry wrote: Ah, I should probably have guessed that Python would have something like that built-in :-) Actually, I'm going to discard this; the main reason I did it was to make the warnings visible, but I think that putting them in a logfile is a better idea. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115332/#review48402 --- On Jan. 27, 2014, 4:25 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115332/ --- (Updated Jan. 27, 2014, 4:25 p.m.) Review request for KDE Frameworks and Aurélien Gâteau. Repository: kapidox Description --- Add a --quiet option Diffs - src/kgenapidox eadd3a77b42b92df882456fa25c20339d4394708 src/kapidox/__init__.py c89e06fdc2385f07b074b14574c1e62900723cab src/kgenframeworksapidox f565eb36fb0dc952643ff174001c5ee6f96cd394 Diff: https://git.reviewboard.kde.org/r/115332/diff/ Testing --- Built some dox (Python 2.7, I think). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115359: rename dbus interface files and .desktop files in kio
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115359/ --- Review request for KDE Frameworks and David Faure. Repository: kio Description --- rename dbus interface files and .desktop files in kio to prevent clashes with kdelibs4 equivalents. dbus interface itself remains the same. Diffs - src/core/CMakeLists.txt 75ba28d src/ioslaves/http/kcookiejar/CMakeLists.txt b22ded4 src/ioslaves/mailto/CMakeLists.txt acabf88 src/ioslaves/mailto/kmailservice.desktop 03838a5 src/ioslaves/mailto/kmailservice5.desktop PRE-CREATION src/ioslaves/telnet/CMakeLists.txt 70fea89 src/ioslaves/telnet/ktelnetservice.desktop 052a9d3 src/ioslaves/telnet/ktelnetservice5.desktop PRE-CREATION src/widgets/CMakeLists.txt 01b9483 Diff: https://git.reviewboard.kde.org/r/115359/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115359: rename dbus interface files and .desktop files in kio
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115359/#review48486 --- src/ioslaves/mailto/CMakeLists.txt https://git.reviewboard.kde.org/r/115359/#comment34285 Is renaming desktop file(s) really needed? If so, iirc one of tests in KService shall need adjusting. - Hrvoje Senjan On Jan. 28, 2014, 4:03 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115359/ --- (Updated Jan. 28, 2014, 4:03 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- rename dbus interface files and .desktop files in kio to prevent clashes with kdelibs4 equivalents. dbus interface itself remains the same. Diffs - src/core/CMakeLists.txt 75ba28d src/ioslaves/http/kcookiejar/CMakeLists.txt b22ded4 src/ioslaves/mailto/CMakeLists.txt acabf88 src/ioslaves/mailto/kmailservice.desktop 03838a5 src/ioslaves/mailto/kmailservice5.desktop PRE-CREATION src/ioslaves/telnet/CMakeLists.txt 70fea89 src/ioslaves/telnet/ktelnetservice.desktop 052a9d3 src/ioslaves/telnet/ktelnetservice5.desktop PRE-CREATION src/widgets/CMakeLists.txt 01b9483 Diff: https://git.reviewboard.kde.org/r/115359/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115359: rename dbus interface files and .desktop files in kio
On Jan. 28, 2014, 4:16 p.m., Hrvoje Senjan wrote: src/ioslaves/mailto/CMakeLists.txt, line 10 https://git.reviewboard.kde.org/r/115359/diff/1/?file=240861#file240861line10 Is renaming desktop file(s) really needed? If so, iirc one of tests in KService shall need adjusting. well spotted, patch at https://git.reviewboard.kde.org/r/115361/ the test does have a comment This could fail if it finds the kde4 kmailservice from /usr/share which suggests it is needed - Jonathan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115359/#review48486 --- On Jan. 28, 2014, 4:03 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115359/ --- (Updated Jan. 28, 2014, 4:03 p.m.) Review request for KDE Frameworks and David Faure. Repository: kio Description --- rename dbus interface files and .desktop files in kio to prevent clashes with kdelibs4 equivalents. dbus interface itself remains the same. Diffs - src/core/CMakeLists.txt 75ba28d src/ioslaves/http/kcookiejar/CMakeLists.txt b22ded4 src/ioslaves/mailto/CMakeLists.txt acabf88 src/ioslaves/mailto/kmailservice.desktop 03838a5 src/ioslaves/mailto/kmailservice5.desktop PRE-CREATION src/ioslaves/telnet/CMakeLists.txt 70fea89 src/ioslaves/telnet/ktelnetservice.desktop 052a9d3 src/ioslaves/telnet/ktelnetservice5.desktop PRE-CREATION src/widgets/CMakeLists.txt 01b9483 Diff: https://git.reviewboard.kde.org/r/115359/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115362: Do not explicitly link against libc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115362/ --- (Updated Jan. 28, 2014, 4:41 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Do not explicitly link against libc This is entirely unnecessary. Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115362/diff/ Testing (updated) --- KCoreAddons and KDE4Support still configure and compile (GCC 4.8.2 20131219; Linux with glibc 2.18). 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 115361: use renamed kmailservice5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115361/#review48489 --- Ship it! Ship It! - Aleix Pol Gonzalez On Jan. 28, 2014, 4:25 p.m., Jonathan Riddell wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115361/ --- (Updated Jan. 28, 2014, 4:25 p.m.) Review request for KDE Frameworks and Hrvoje Senjan. Repository: kservice Description --- fix test for renamed kmailservice5 proposed in https://git.reviewboard.kde.org/r/115359/ Diffs - autotests/kservicetest.cpp 89eb0ae Diff: https://git.reviewboard.kde.org/r/115361/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115363: Move and comment -fno-common setting
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115363/ --- Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Move and comment -fno-common setting Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115363/diff/ Testing --- KCoreAddons still configures and compiles (GCC 4.8.2 20131219; Linux with glibc 2.18). 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 115360: Remove the allocator and visibility check
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115360/ --- (Updated Jan. 28, 2014, 4:41 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Remove the allocator and visibility check I am reasonably sure the allocator check is out of date, given our minimum GCC version, and it was not used for anything interesting anyway. The visibility check will not be performed in practice, as this file will almost always be included before any check for Qt. Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115360/diff/ Testing (updated) --- KCoreAddons still configures and compiles (GCC 4.8.2 20131219; Linux with glibc 2.18). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115362: Do not explicitly link against libc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115362/ --- Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Do not explicitly link against libc This is entirely unnecessary. Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115362/diff/ Testing --- KCoreAddons and KDE4Support still configure and compile. 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 115362: Do not explicitly link against libc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115362/#review48490 --- Ship it! I tried it here, doesn't seem to break. Also it's really ugly to have -lc so +1 from me. - Aleix Pol Gonzalez On Jan. 28, 2014, 4:41 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115362/ --- (Updated Jan. 28, 2014, 4:41 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Do not explicitly link against libc This is entirely unnecessary. Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115362/diff/ Testing --- KCoreAddons and KDE4Support still configure and compile (GCC 4.8.2 20131219; Linux with glibc 2.18). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115361: use renamed kmailservice5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115361/ --- Review request for KDE Frameworks and Hrvoje Senjan. Repository: kservice Description --- fix test for renamed kmailservice5 proposed in https://git.reviewboard.kde.org/r/115359/ Diffs - autotests/kservicetest.cpp 89eb0ae Diff: https://git.reviewboard.kde.org/r/115361/diff/ Testing --- Thanks, Jonathan Riddell ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
C standard
Currently, KDECompilerSettings.cmake in ECM sets -std=iso9899:1990 for C code (C90). Question: do we want to change this to -std=c99? Bear in mind that our minimum GCC version (4.2) does not completely support this standard. In particular, the semantics for inline functions don't match C99's until GCC 4.3, and there are some corner cases for variable length arrays and complex numbers that are not fixed until GCC 4.5. Obviously, this won't affect that much code, since most of it is C++ (for which, incidentally, we set -std=c++0x, ie: C++11). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w5
On Tuesday, January 28, 2014 16:40:51 Kevin Ottens wrote: Hello everyone, [...] * sebas has been working on high dpi support; Where? In Plasma 2? QML stuff? Styles? Widgets? Can you elaborate? Greetings, Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115362: Do not explicitly link against libc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115362/#review48492 --- This review has been submitted with commit cd1bf67b24b751e176c2d53d0b0f449e2ee07872 by Alex Merry to branch master. - Commit Hook On Jan. 28, 2014, 4:41 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115362/ --- (Updated Jan. 28, 2014, 4:41 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Do not explicitly link against libc This is entirely unnecessary. Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115362/diff/ Testing --- KCoreAddons and KDE4Support still configure and compile (GCC 4.8.2 20131219; Linux with glibc 2.18). 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 115362: Do not explicitly link against libc
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115362/ --- (Updated Jan. 28, 2014, 5:13 p.m.) Status -- This change has been marked as submitted. Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Do not explicitly link against libc This is entirely unnecessary. Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115362/diff/ Testing --- KCoreAddons and KDE4Support still configure and compile (GCC 4.8.2 20131219; Linux with glibc 2.18). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C standard
On 28/01/14 17:19, Andrius da Costa Ribas wrote: MSVC (at least vc2010) is C89 for C code, changing it to C99 on GCC may lead to changes that break MSVC build (since almost everything is mostly tested on linux/gcc only). OK, that seems like a fair reason to keep it at the C89/C90 standard. I'll add a note to KDECompilerSettings.cmake. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115364: Update tier number
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115364/ --- Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- It was discussed on the mailing list that kwallet is moving to tier 3, so this needs updating in the yaml file too. Diffs - kwallet-framework.yaml 9b601d5a6408c76d0f56d875af1f4c179b271741 Diff: https://git.reviewboard.kde.org/r/115364/diff/ Testing --- Thanks, Michael Palimaka ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: C standard
MSVC (at least vc2010) is C89 for C code, changing it to C99 on GCC may lead to changes that break MSVC build (since almost everything is mostly tested on linux/gcc only). -- Andrius 2014-01-28 Alex Merry k...@randomguy3.me.uk Currently, KDECompilerSettings.cmake in ECM sets -std=iso9899:1990 for C code (C90). Question: do we want to change this to -std=c99? Bear in mind that our minimum GCC version (4.2) does not completely support this standard. In particular, the semantics for inline functions don't match C99's until GCC 4.3, and there are some corner cases for variable length arrays and complex numbers that are not fixed until GCC 4.5. Obviously, this won't affect that much code, since most of it is C++ (for which, incidentally, we set -std=c++0x, ie: C++11). Alex ___ 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: KF5 Update Meeting Minutes 2014-w5
On Tue, Jan 28, 2014 at 6:07 PM, Dominik Haumann dhaum...@kde.org wrote: On Tuesday, January 28, 2014 16:40:51 Kevin Ottens wrote: Hello everyone, [...] * sebas has been working on high dpi support; Where? In Plasma 2? QML stuff? Styles? Widgets? Can you elaborate? In Plasma, it concerns only Plasmoids atm. See http://mail.kde.org/pipermail/plasma-devel/2014-January/028173.html for details. Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Change the ML default reply-to address
Hey, would it be possible to change the default reply-to address for this list? It's quite annoying in less-advanced-than-kmail clients always pressing Reply and getting only the sender instead of the whole list. There's a switch for that in mailman, lots of lists have the reply-to set to the list address. Is there any reason why not for this list? And if not, can we please change it? :) Cheers -- Martin Klapetek | KDE Developer ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Change the ML default reply-to address
2014-01-28 Martin Klapetek martin.klape...@gmail.com: Hey, would it be possible to change the default reply-to address for this list? It's quite annoying in less-advanced-than-kmail clients always pressing Reply and getting only the sender instead of the whole list. There's a switch for that in mailman, lots of lists have the reply-to set to the list address. Is there any reason why not for this list? And if not, can we please change it? :) Whether or not to make reply-to point to the mailing list is a holy war as old as mailing lists themselves. See, for example: http://www.unicom.com/pw/reply-to-harmful.html -- Nicolás ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Where to put QML Bindings for KDE frameworks?
Hello, On Tuesday 28 January 2014 12:58:01 David Edmundson wrote: For a task in Plasma I've had to port KKeySequence to render on QtQuick, using QtQuickControls. I expect over time we will see more KDE widgets having QtQuick implementations as well. Same for a lot of our other frameworks, such as KIO. I can either add these components to KDeclarative, and create a new import. It is already in tier3, but I would need to add quite a few dependencies to this module. We could put these things in plasma, but I don't think that makes sense as it's not really related to Plasma at all. Alternatively we can make a new framework for all KDE bindings. Or we can make an imports directory inside each of the relevant framework. i.e so KIO provides QML bindings too. Advantages are we can then use the relevant private API of a library, but it has the disadvantage of increasing dependencies, and mixing old very stable API with brand new libraries. Original thread on plasma-devel here: http://mail.kde.org/pipermail/plasma-devel/2014-January/028162.html Discuss. I don't think we'll get a one size fit all type of solution, that will heavily depend on the nature of the framework. For instance something like KConfig should probably provide it's own imports, it is in the natural order of things as it already provides a core/gui split. KIO is in pretty much the same situation. But for some others it is less clear... For those ones we'll have to decide if we want to change them toward providing several payloads as well (sounds doable for most except the *addons ones), or if we want the import to be in one of the imports provided by KDeclarative. 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: KF5 Update Meeting Minutes 2014-w5
On Tuesday 28 January 2014 18:22:17 Martin Klapetek wrote: On Tue, Jan 28, 2014 at 6:07 PM, Dominik Haumann dhaum...@kde.org wrote: On Tuesday, January 28, 2014 16:40:51 Kevin Ottens wrote: Hello everyone, [...] * sebas has been working on high dpi support; Where? In Plasma 2? QML stuff? Styles? Widgets? Can you elaborate? In Plasma, it concerns only Plasmoids atm. See http://mail.kde.org/pipermail/plasma-devel/2014-January/028173.html for details. Ok, thanks for the link! Dominik ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115360: Remove the allocator and visibility check
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115360/ --- (Updated Jan. 28, 2014, 8:16 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Remove the allocator and visibility check I am reasonably sure the allocator check is out of date, given our minimum GCC version, and it was not used for anything interesting anyway. The visibility check will not be performed in practice, as this file will almost always be included before any check for Qt. Diffs - kde-modules/KDECompilerSettings.cmake 3419cb1266c63f9cdec0501ae340aabe7c0b6096 Diff: https://git.reviewboard.kde.org/r/115360/diff/ Testing (updated) --- Everything kdesrc-build knows about builds (GCC 4.8.2 20131219; Linux with glibc 2.18). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KF5 Update Meeting Minutes 2014-w5
On Tuesday, January 28, 2014 04:40:51 PM Kevin Ottens wrote: * teo is planning to help on the kwallet and secret service front; * he's waiting to hear back from valentin rusu; teo already contacted me, suggesting IRC meeting during working hours. Unfortunately, I won't be able to attend, as I'm also working during these hours, at my job where I don't have IRC (perhaps I should try IRC on my android?) I'm also being happy to see him tinkering KDE during working hours! * he's also looking into QtKeyChain; That would be great! -- Valentin Rusu irc: valir 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: Tier status of attica kwallet
On Thursday, January 23, 2014 11:18:02 PM Michael Palimaka wrote: On 01/23/2014 08:21 AM, Valentin Rusu wrote: On Thursday, January 23, 2014 04:24:37 AM Michael Palimaka wrote: Sure, the framework itself is still tier 2...but the repo also includes kwalletd which definitely is not tier 2, and there does not appear to be any option to control building them independently. It's now possible to do a build without kwalletd and the associated tests by defining KF5_KWALLET_NO_DAEMON when invoking cmake. -- Valentin Rusu irc: valir 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: Change the ML default reply-to address
El Dimarts, 28 de gener de 2014, a les 16:04:30, Nicolás Alvarez va escriure: 2014-01-28 Martin Klapetek martin.klape...@gmail.com: Hey, would it be possible to change the default reply-to address for this list? It's quite annoying in less-advanced-than-kmail clients always pressing Reply and getting only the sender instead of the whole list. There's a switch for that in mailman, lots of lists have the reply-to set to the list address. Is there any reason why not for this list? And if not, can we please change it? :) Whether or not to make reply-to point to the mailing list is a holy war as old as mailing lists themselves. See, for example: http://www.unicom.com/pw/reply-to-harmful.html To be honest I don't know anyone that likes reply-to-person over reply-to- mailinglist, it may had been a holy war 20 years ago, but nowadays? Cheers, Albert P.S: Please people that disagree with me, manifest yourselves! ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: add test for QFileDialog::getExistingDirectory / bug?
On 28/01/14 15:05, Kevin Funk wrote: Am Sonntag, 26. Januar 2014, 18:53:42 schrieb Gregor Mi: With another addition to qfiledialogtest in frameworks/frameworkintegration another potential bug can be exposed: Calling $ ./qfiledialogtest --nameFilter c (*.cpp) --nameFilter h (*.h) --selectNameFilter h (*.h) Works for me. Using Qt 5.2.0, if that matters. Hmm. I also use Qt 5.2.0 (the one that comes with kdesrcbuild). Does the other call (see below) also works for you? (Here is the console output for the first one: http://pastebin.kde.org/puwz8xzfc) does not select the second filter. Can this be confirmed or maybe I am using the API wrong? Gregor On 26/01/14 17:15, Gregor Mi wrote: Hi, with 2c1ee08a21a1f16f9c2523718224598de8fc0d4f I added a test for QFileDialog::getExistingDirectory. When I execute ./qfiledialogtest --staticFunction getExistingDirectory This one... then a dialog opens that lets the user select files but not directories. This seems to be a bug. Greetings Gregor ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115367: Add a cmake option controlling whether to build kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/ --- (Updated Jan. 28, 2014, 8:40 p.m.) Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Add a cmake option controlling whether to build kwalletd This is better than a random variable that needs defining: it is stored in the cache, and it gets a help text. It can now be set using `make edit_cache` or when building with ccmake. Diffs - src/runtime/CMakeLists.txt 7bfad97c55e80a9828564a6803074289a66ff04b Diff: https://git.reviewboard.kde.org/r/115367/diff/ Testing --- Builds whether the option is on or off; kwalletd is built only if the option is on. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115367: Add a cmake option controlling whether to build kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/ --- Review request for KDE Frameworks. Repository: kwallet-framework Description --- Add a cmake option controlling whether to build kwalletd This is better than a random variable that needs defining: it is stored in the cache, and it gets a help text. It can now be set using `make edit_cache` or when building with ccmake. Diffs - src/runtime/CMakeLists.txt 7bfad97c55e80a9828564a6803074289a66ff04b Diff: https://git.reviewboard.kde.org/r/115367/diff/ Testing --- Builds whether the option is on or off; kwalletd is built only if the option is on. 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 115367: Add a cmake option controlling whether to build kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/#review48499 --- src/runtime/CMakeLists.txt https://git.reviewboard.kde.org/r/115367/#comment34291 Please apply this option also in tests/CMakeLists.txt - Valentin Rusu On Jan. 28, 2014, 8:40 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/ --- (Updated Jan. 28, 2014, 8:40 p.m.) Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Add a cmake option controlling whether to build kwalletd This is better than a random variable that needs defining: it is stored in the cache, and it gets a help text. It can now be set using `make edit_cache` or when building with ccmake. Diffs - src/runtime/CMakeLists.txt 7bfad97c55e80a9828564a6803074289a66ff04b Diff: https://git.reviewboard.kde.org/r/115367/diff/ Testing --- Builds whether the option is on or off; kwalletd is built only if the option is on. 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 115367: Add a cmake option controlling whether to build kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/ --- (Updated Jan. 28, 2014, 10:28 p.m.) Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Add a cmake option controlling whether to build kwalletd This is better than a random variable that needs defining: it is stored in the cache, and it gets a help text. It can now be set using `make edit_cache` or when building with ccmake. Diffs (updated) - CMakeLists.txt d5e7c5e98b4ce84877e3a69dda0091059453985b README.md fdc05261f8af8f8285b35af78589cb43bab7f28d src/runtime/CMakeLists.txt 7bfad97c55e80a9828564a6803074289a66ff04b tests/CMakeLists.txt 41e09eec8bef54c7e28ff6c55629d2e6179abdc7 Diff: https://git.reviewboard.kde.org/r/115367/diff/ Testing --- Builds whether the option is on or off; kwalletd is built only if the option is on. 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 115367: Add a cmake option controlling whether to build kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/#review48500 --- Ship it! Ship It! - Valentin Rusu On Jan. 28, 2014, 10:28 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/ --- (Updated Jan. 28, 2014, 10:28 p.m.) Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Add a cmake option controlling whether to build kwalletd This is better than a random variable that needs defining: it is stored in the cache, and it gets a help text. It can now be set using `make edit_cache` or when building with ccmake. Diffs - CMakeLists.txt d5e7c5e98b4ce84877e3a69dda0091059453985b README.md fdc05261f8af8f8285b35af78589cb43bab7f28d src/runtime/CMakeLists.txt 7bfad97c55e80a9828564a6803074289a66ff04b tests/CMakeLists.txt 41e09eec8bef54c7e28ff6c55629d2e6179abdc7 Diff: https://git.reviewboard.kde.org/r/115367/diff/ Testing --- Builds whether the option is on or off; kwalletd is built only if the option is on. 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 115367: Add a cmake option controlling whether to build kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/#review48502 --- This review has been submitted with commit 459ac843aaf1abab5d0dc4756f9a9a7d44f8db49 by Alex Merry to branch master. - Commit Hook On Jan. 28, 2014, 10:28 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/ --- (Updated Jan. 28, 2014, 10:28 p.m.) Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Add a cmake option controlling whether to build kwalletd This is better than a random variable that needs defining: it is stored in the cache, and it gets a help text. It can now be set using `make edit_cache` or when building with ccmake. Diffs - CMakeLists.txt d5e7c5e98b4ce84877e3a69dda0091059453985b README.md fdc05261f8af8f8285b35af78589cb43bab7f28d src/runtime/CMakeLists.txt 7bfad97c55e80a9828564a6803074289a66ff04b tests/CMakeLists.txt 41e09eec8bef54c7e28ff6c55629d2e6179abdc7 Diff: https://git.reviewboard.kde.org/r/115367/diff/ Testing --- Builds whether the option is on or off; kwalletd is built only if the option is on. 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 115367: Add a cmake option controlling whether to build kwalletd
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115367/ --- (Updated Jan. 28, 2014, 10:40 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks and Valentin Rusu. Repository: kwallet-framework Description --- Add a cmake option controlling whether to build kwalletd This is better than a random variable that needs defining: it is stored in the cache, and it gets a help text. It can now be set using `make edit_cache` or when building with ccmake. Diffs - CMakeLists.txt d5e7c5e98b4ce84877e3a69dda0091059453985b README.md fdc05261f8af8f8285b35af78589cb43bab7f28d src/runtime/CMakeLists.txt 7bfad97c55e80a9828564a6803074289a66ff04b tests/CMakeLists.txt 41e09eec8bef54c7e28ff6c55629d2e6179abdc7 Diff: https://git.reviewboard.kde.org/r/115367/diff/ Testing --- Builds whether the option is on or off; kwalletd is built only if the option is on. 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 115360: Remove the allocator and visibility check
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115360/ --- (Updated Jan. 28, 2014, 10:43 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Changes --- Remove a stray set() call. Repository: extra-cmake-modules Description --- Remove the allocator and visibility check I am reasonably sure the allocator check is out of date, given our minimum GCC version, and it was not used for anything interesting anyway. The visibility check will not be performed in practice, as this file will almost always be included before any check for Qt. Diffs (updated) - kde-modules/KDECompilerSettings.cmake ba9b03f1c86061dd740960220b6411bbce541617 Diff: https://git.reviewboard.kde.org/r/115360/diff/ Testing --- Everything kdesrc-build knows about builds (GCC 4.8.2 20131219; Linux with glibc 2.18). Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 115370: Fix apidox, fix code style and delete useless includes in KComboBox (KCompletion)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115370/ --- Review request for KDE Frameworks. Repository: kcompletion Description --- Fix apidox, fix code style and delete useless includes. Diffs - src/kcombobox.h f34d259 src/kcombobox.cpp 2cfe6e7 Diff: https://git.reviewboard.kde.org/r/115370/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: Let's get in release mode!
El Dissabte, 14 de desembre de 2013, a les 20:30:14, Kevin Ottens va escriure: Hello everyone, Now we're really getting there! Epics and review board are clean, thanks to everyone who helped to get there. Now it's the time to go for the last push. For that I opened what will be the last epic for the 5.0 release: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation As discussed on IRC the other day I added a Make sure the Frameworks handle l10n correctly task that links to http://community.kde.org/Frameworks/Epics/KF5.0_Release_Preparation/l10n Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities master becomes Qt5/KF5-based
El Dilluns, 21 d'octubre de 2013, a les 19:14:23, Ivan Čukić va escriure: Well, to be honest, if you don't want a 4.13 release i'd prefer you actually use master for KF5. Otherwise people might random-commit fixes to master and then wonder why they never got into a release, so the two situations i think make sense are: People don't really contribute to kactivities, but I agree. A) wait until we branch KDE/4.12 and then use master for KF5, not release kactivities 4.13 and maybe release more 4.12.x of kactivities than the rest of the SC if there are fixes for it This is what I was thinking of - until we branch, the branch is called frameworks, and after that it will be moved to master. Am I making any sense? Perfect sense, as usual mate :) Ping, 4.13 is looming over. If you want to make it so there's no new releases of 4.12.x anymore and master is KF5 based, please discuss now. Personally I'd suggest against it since seems that even if we dicussed for that happening to kde-workspace people did not get the memo and got angry, so unless you have a huge itch to make it happen i'd just do with kactivities the same we do with kdelibs. Cheers, Albert Cheers, Ivan ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kactivities master becomes Qt5/KF5-based
Ping, 4.13 is looming over. If you want to make it so there's no new releases of 4.12.x anymore and master is KF5 based, please discuss now. Personally I'd suggest against it since seems that even if we dicussed for that happening to kde-workspace people did not get the memo and got angry, so unless you have a huge itch to make it happen i'd just do with kactivities the same we do with kdelibs. I've been procrastinating. We can't do the same thing as with kdelibs. Simply because those were split into separate repositories where masters are qt5/kf5-based. KActivities is already in a separate repository. If we decide to wait after 4.13, the next release of Plasma will have to use a non-master-based kactivities which I'm not sure is a good idea. Naturally, I am open to suggestions. Cheers, Ivan -- The problem with object-oriented languages is they’ve got all this implicit environment that they carry around with them. You wanted a banana but what you got was a gorilla holding the banana. -- Joe Armstrong ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 115372: Improve the compiler version checks (including requiring GCC 4.5)
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115372/#review48508 --- kde-modules/KDECompilerSettings.cmake https://git.reviewboard.kde.org/r/115372/#comment34292 3.1 is the minimum clang Version according to https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11 - Alexander Richardson On Jan. 29, 2014, 12:22 a.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115372/ --- (Updated Jan. 29, 2014, 12:22 a.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Improve the compiler version checks - Only warn if the compiler is not recent enough (it may still work...) - Bump up the GCC version to 4.5 (on Linux, at least) to match Qt - Add checks for Windows (both MSVC and MinGW) that match Qt Diffs - kde-modules/KDECompilerSettings.cmake a4683b04459a2dca1bc5daab0c69c06acbf33ce0 Diff: https://git.reviewboard.kde.org/r/115372/diff/ Testing --- Built KCoreAddons with gcc 4.8.2 on Linux. Got no warning. 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 115372: Improve the compiler version checks (including requiring GCC 4.5)
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115372/#review48510
---
kde-modules/KDECompilerSettings.cmake
https://git.reviewboard.kde.org/r/115372/#comment34293
It'd be nice to add an
else()
message(WARNING Unsupported compiler ${CMAKE_CXX_COMPILER_ID})
kde-modules/KDECompilerSettings.cmake
https://git.reviewboard.kde.org/r/115372/#comment34294
elseif() would fit better here.
kde-modules/KDECompilerSettings.cmake
https://git.reviewboard.kde.org/r/115372/#comment34295
else: warn about unsupported compiler
kde-modules/KDECompilerSettings.cmake
https://git.reviewboard.kde.org/r/115372/#comment34297
Unrelated, but for MSVC there are no additional flags. ICL supports the
same features as MSVC, there is /Qstd=c++11 but only for the features ICL
supports but MSVC doesn't.
So, this FIXME can be removed.
kde-modules/KDECompilerSettings.cmake
https://git.reviewboard.kde.org/r/115372/#comment34296
Unrelated, but I've check the MSDN examples for these warnings and icl
raises none of them for these, so these can be done for MSVC only.
- Andrius da Costa Ribas
On Jan. 28, 2014, 11:22 p.m., Alex Merry wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/115372/
---
(Updated Jan. 28, 2014, 11:22 p.m.)
Review request for Build System, Extra Cmake Modules and KDE Frameworks.
Repository: extra-cmake-modules
Description
---
Improve the compiler version checks
- Only warn if the compiler is not recent enough (it may still work...)
- Bump up the GCC version to 4.5 (on Linux, at least) to match Qt
- Add checks for Windows (both MSVC and MinGW) that match Qt
Diffs
-
kde-modules/KDECompilerSettings.cmake
a4683b04459a2dca1bc5daab0c69c06acbf33ce0
Diff: https://git.reviewboard.kde.org/r/115372/diff/
Testing
---
Built KCoreAddons with gcc 4.8.2 on Linux. Got no warning.
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 115225: Add runtime platform support to KWindowInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/115225/ --- (Updated Jan. 29, 2014, 8:02 a.m.) Review request for KDE Frameworks and kdewin. Changes --- Removed the default ctor which is just going to crash. Repository: kwindowsystem Description --- Add runtime platform support to KWindowInfo Main idea of this change is to only pick the X11 implementation in case that the application is running on the X11 platform. So far it was a compile time switch which meant that if compiled with X11 support but not running on the X11 platform it would have caused runtime errors. To make this possible a KWindowInfoPrivate class with a dummy implementation is provided. This is used as d-ptr for KWindowInfo. Thus there is one generic implementation and the implementation of KWindowInfo is no longer ifdefed for the supported platforms. The platform specific code can inherit from KWindowInfoPrivate and overwrite the dummy method implementation. KWindowInfoPrivate provides a factory method where the platform specific implementation can be hooked into. There we can have both compile time and runtime checking. If there is no platfom specific implementation available the dummy implementation is used. NOTE: THIS CHANGE BREAKS THE WINDOWS AND MAC BACKEND! Windows and Mac is excluded from build. At the moment they get the dummy implementation. Unfortunately I don't have the possibility to compile the changes and thus don't dare to touch the code. Fixes from the teams are highly appreciated. Diffs (updated) - src/CMakeLists.txt 39783988a292cb0dc62e3de91421e36930821fe2 src/kwindowinfo.h 171f441ff329a5356ccf560341272199e20c837a src/kwindowinfo.cpp PRE-CREATION src/kwindowinfo_p.h PRE-CREATION src/kwindowinfo_p_x11.h PRE-CREATION src/kwindowinfo_x11.cpp 865d8bed085e987f97f479ea8aa0e6de8567586f Diff: https://git.reviewboard.kde.org/r/115225/diff/ Testing --- Unit test from https://git.reviewboard.kde.org/r/115190/ is still working. Now you can guess why I wrote that test ;-) Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
