Re: [kdesrc-build] /: Use kde-runtime/frameworks instead of kde-runtime/master
On Wednesday 05 March 2014 17:04:10 Àlex Fiestas wrote: Git commit ae5798e3ce2368c0561424537f77ad34d56eb61a by Àlex Fiestas. Committed on 05/03/2014 at 17:00. Pushed by afiestas into branch 'master'. Use kde-runtime/frameworks instead of kde-runtime/master M +7-1kf5-workspace-build-include http://commits.kde.org/kdesrc-build/ae5798e3ce2368c0561424537f77ad34d56eb61a diff --git a/kf5-workspace-build-include b/kf5-workspace-build-include index d3ed2e5..3228939 100644 --- a/kf5-workspace-build-include +++ b/kf5-workspace-build-include @@ -19,7 +19,13 @@ module-set kf5-workspace-modules repository kde-projects # Required for branch-group # kde-runtime is temporary (parts of it depend on plasma, so it's here) -use-modules kde-runtime kde-workspace plasmate kwin-compositing-kcm + use-modules kde-workspace plasmate kwin-compositing-kcm +end module-set + +module-set kf5-runtime +repository kde-projects +use-modules kde-runtime +branch frameworks end module-set This is unecessary. If you update kdesrc-build and kde-build-metadata (although the latter is automatic anyway), your kde-runtime will be from the frameworks branch. Ah, the problem is probably this: you need to ensure your global section in kdesrc-buildrc says branch-group kf5-qt5 (I updated the template in the wiki, but of course older configs lack this) Please revert ;) -- 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
Review Request 116628: Avoid multiple warnings caused by CMake Policy 0026
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116628/ --- Review request for Build System and KDE Frameworks. Repository: kde4support Description --- I don't think there is a way to make this code CMP0026-compliant. Since it is supposed to not be used in the long run, disable the policy temporarily should be OK. Diffs - cmake/modules/KDE4Macros.cmake 192094b Diff: https://git.reviewboard.kde.org/r/116628/diff/ Testing --- Rebuilt kde-workspace with the change. CMake output is easier to read now. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116628: Avoid multiple warnings caused by CMake Policy 0026
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116628/#review52236 --- Ship it! - Aleix Pol Gonzalez On March 6, 2014, 10:11 a.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116628/ --- (Updated March 6, 2014, 10:11 a.m.) Review request for Build System and KDE Frameworks. Repository: kde4support Description --- I don't think there is a way to make this code CMP0026-compliant. Since it is supposed to not be used in the long run, disable the policy temporarily should be OK. Diffs - cmake/modules/KDE4Macros.cmake 192094b Diff: https://git.reviewboard.kde.org/r/116628/diff/ Testing --- Rebuilt kde-workspace with the change. CMake output is easier to read now. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116616: Remove unused find-modules back to the attic
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116616/#review52241 --- This review has been submitted with commit 8c3773f920185fe49d913f71fb58d19936a8d868 by Alex Merry to branch master. - Commit Hook On March 5, 2014, 2:31 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116616/ --- (Updated March 5, 2014, 2:31 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Repository: extra-cmake-modules Description --- Remove unused find-modules back to the attic Diffs - find-modules/FindBlueZ.cmake find-modules/FindLibUSB1.cmake Diff: https://git.reviewboard.kde.org/r/116616/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 116616: Remove unused find-modules back to the attic
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116616/ --- (Updated March 6, 2014, 11:50 a.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 --- Remove unused find-modules back to the attic Diffs - find-modules/FindBlueZ.cmake find-modules/FindLibUSB1.cmake Diff: https://git.reviewboard.kde.org/r/116616/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: kitemmodels_master_qt5 #25
See http://build.kde.org/job/kitemmodels_master_qt5/25/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KSpeech
Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting: Took a quick read through that just now and it looks pretty promising from what I saw. I guess I don't know my way around gerrit very well because I couldn't see a place to comment on the code like reviewboard. Really the only difference between jovie and that class are the following: 1. jovie has some old code and ui to control jobs at a fine grain that spd doesn't expose really well, so I left it out when I ported ktts to spd. I would like to expose voices and languages in a sensible fashion. This is tricky to get right cross-platform. I started with something on Linux but decided to implement other backends first before attempting to implement voice selection. For language/locale I think qtspeech should default to the system locale and let the user select a different one. 2. user defined filters with some sane/useful defaults (if we were to use QtSpeech for kde notifications, set konvi to speak all messages, there's not a way to let the user say change jpwhiting fregl: you rock into jpwhiting says fregl you rock) Maybe. I'd rather keep qtspeech very simple. My goals where to make it a tiny library that is lean, fast and async by using signals and slots. I want it to be good enough to be used in apps that use voice navigation, but also when writing a screen reader. Some level of configuration is required in any case. Let's come up with a good api that makes sense across platforms, then I'm in. 3. user configurability (As a user I can't set up which voice I would like all speech-using applications to use) As with other Qt libs, this is more for the platform to set up. Currently qtspeech uses whatever voice is selected system wide (aka the default). I think that is the right approach - follow what we get from the platform. For KDE I'd thus suggest creating a configuration module which lets the user choose the platform defaults. 4. dbus, though this isn't as important if each application that uses speech links to the library and speech-dispatcher or the system apis do the async for us already anyway as you said. I don't see a point in adding dbus into the mix indeed. One thing that is interesting though is what kind of effect you get when opening the speech backend from two apps at the same time. Items 1 and 4 will be irrelevant in a KF5 world but I'm wondering how 2 and 3 could be added either to qtspeech itself or as a kspeech library that wraps qtspeech for kde applications to use. Any thoughts on that? I would be pretty interested in helping with qtspeech if it greatly simplifies or even deprecates jovie as it looks like it could do possibly. I'd be more than happy to get contributions of course. I cannot promise much from my side, of course I'd like to continue working on this project as time permits (so far it really is a spare time thing). Greetings, Frederik Jeremy On Wed, Mar 5, 2014 at 12:29 PM, Frederik Gladhorn gladh...@kde.org wrote: On Tuesday 4. March 2014 16.43.10 Jeremy Whiting wrote: Hello all, I've realized a bit ago that kspeech was not included in the kdelibs split (probably because it was in staging at the time and didn't conform to the other framework policies yet). I've cleaned it up a bit and put it in my scratch space, but have some architectural questions about it before I make it a proper framework. 1. The KSpeech dbus interface is old and showing its age. Many of the methods are no longer implemented in the application itself since it was ported to speech-dispatcher. One thing I would definitely like to do is clean up/remove methods that aren't implemented currently (and possibly re add some later on if speech-dispatcher gets better/more support for job control, etc.) So the question about this is is KF5 time a good time to drop/clean up the dbus interface? 2. The KSpeech interface that was in kdelibs/interfaces is just that a dbus interface only. I would like to make it a proper library/framework with a QObject based class for talking to Jovie (the application that implements the KSpeech dbus interface) and wonder if other things such as what's currently in jovie/libkttsd should be in the kspeech library also. If I move code from jovie into libkspeech (or merge kspeech interface into libkttsd and make libkttsd a framework likely renamed to libkspeech since libkttsd isn't a public library anyway and has the old ktts name) what's the best way to preserve the history of both the kspeech interface and libkttsd sources. Didn't the plasma or kde-workspaces split do something fancy with git where old history pointed to the old git repo somehow? Along with this, if libkspeech is defining the kspeech dbus interface and has a class to talk to that interface, does the interface still need to be in servicetypes like the
Re: Review Request 116628: Avoid multiple warnings caused by CMake Policy 0026
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116628/ --- (Updated March 6, 2014, 4:30 p.m.) Status -- This change has been discarded. Review request for Build System and KDE Frameworks. Repository: kde4support Description --- I don't think there is a way to make this code CMP0026-compliant. Since it is supposed to not be used in the long run, disable the policy temporarily should be OK. Diffs - cmake/modules/KDE4Macros.cmake 192094b Diff: https://git.reviewboard.kde.org/r/116628/diff/ Testing --- Rebuilt kde-workspace with the change. CMake output is easier to read now. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116090: Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
On Feb. 27, 2014, 10:54 a.m., Alex Merry wrote:
The problem with doing this in support code is that it is not strictly
source compatible. An example this would break is if you want to embed the
value of QT_QMAKE_EXECUTABLE into a C++ executable using something like
add_definitions(-DQMAKE=\${QT_QMAKE_EXECUTABLE}\)
Any use of QMAKE in the program would then expand to
$TARGET_FILE:Qt5::qmake, which is obviously not what was wanted.
Alexander Richardson wrote:
Ah, didn't know that, should I drop this request?
Alex Merry wrote:
Yeah, I don't think it's worth risking breakage for kde4support.
Aleix Pol Gonzalez wrote:
Setting the policy instead would probably help though.
This warning is very verbose and not very useful to the developer either.
Alex Merry wrote:
Yeah, that seems reasonable. The best approach is to use
cmake_policy(PUSH) and cmake_policy(POP) in the relevant files, so it doesn't
affect any of the developer's own code (see
http://www.cmake.org/cmake/help/v2.8.12/cmake.html#command:cmake_policy ).
Aurélien Gâteau wrote:
I just did that here: https://git.reviewboard.kde.org/r/116628/
Actually my code was not as complete as this one, and not as good.
The parts which affect internal variables (such as those in KDE4Macros.cmake)
can go in. The parts which affect public variables should be changed to instead
wrap the location getters in cmake policy changes as Alex suggested (ie:
cmake_policy(PUSH) ; cmake_policy(SET CMP0026 OLD) ; ...get some locations... ;
cmake_policy(POP))
- Aurélien
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116090/#review51010
---
On Feb. 26, 2014, 6:03 p.m., Alexander Richardson wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116090/
---
(Updated Feb. 26, 2014, 6:03 p.m.)
Review request for KDE Frameworks.
Repository: kde4support
Description
---
Use $TARGET_FILE:... instead of get_target_property(... LOCATION)
This means CMake no longer warns about Policy CMP0026 is not set when
building projects that need kde4support
Diffs
-
cmake/modules/ECMQt4To5Porting.cmake
4204fa541790aa38c74b9d6f0b2111af2157b2bc
cmake/modules/KDE4Macros.cmake 192094b1c5c6877cd9dfa18dc27338c491d753f3
src/CMakeLists.txt 6bda0996c118ce212860e02d0505fd3bdc026833
src/KDEUIMacros.cmake 1570df340a672a597a0b7480885c340faca0069d
Diff: https://git.reviewboard.kde.org/r/116090/diff/
Testing
---
kde4support compiles, kde-workspace compiles
Thanks,
Alexander Richardson
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 116639: Do not read LOCATION property of desktoptojson
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116639/ --- Review request for Build System and KDE Frameworks. Repository: kservice Description --- This makes the code CMP0026 compliant. Surprisingly I never saw the CMake warning about this policy. Don't know why. Diffs - KF5ServiceMacros.cmake f70a185 Diff: https://git.reviewboard.kde.org/r/116639/diff/ Testing --- Tested with kservice/tests/kservicetojsontest, using both the old and the new syntax. Rebuilt kde-workspace. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116591: Use dedicated NET::Properties and NET::Properties2 in NETWinInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116591/#review52274 --- Ship it! Looks good to me. - Aurélien Gâteau On March 4, 2014, 10:50 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116591/ --- (Updated March 4, 2014, 10:50 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Use dedicated NET::Properties and NET::Properties2 in NETWinInfo This replaces the usage of the unsinged long[] array with NET::Properties as first element and optional NET::Properties2 as second element by a dedecated variable for each of them. This includes the following changes: * NETWinInfo::event(xcb_generic_event_t*) return NET::Properties * new overload added for NETWinInfo::event taking NET::Properties* and NET::Properties2* as arguments * existing overload for NETWinInfo::event taking unsigned long* as argument is deprecated and forwards to the new added overload * NETWinInfo::passedProperties returns NET::Properties and a new NETWinInfo::passedProperties2 is added which returns the NET::Properties2. This is a SC-break, but it's only used internally in KWindowInfo * ctor taking unsigned long* is changed to taking NET::Properties and NET::Properties2. This is also a SC-break, but the ctor broke already caused by the change from Display* to xcb_connection_t* * other ctor is deprecated as the difference is no longer relevant Diffs - autotests/netwininfotestclient.cpp 030881cf47ddc38b89e49a59dfd5deff309a0038 autotests/netwininfotestwm.cpp 5a6697c56462d52777cc9eec0a3eb5b3d03b7693 src/kwindowinfo_x11.cpp 358bcfedc6c5c75c104fbb4ec3666bd8578bff7d src/netwm.h a5ad46fa1f0255ca6719224079bdea4598b48c51 src/netwm.cpp 288a34348f464e1158640afa1d931d9d05690cc4 src/netwm_p.h 1c26d47257a4f3ce71c360c394cc5be16f32b18c Diff: https://git.reviewboard.kde.org/r/116591/diff/ Testing --- unit tests still succeed; further testing: KWin and Plasma are still working Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116568: Fixes to PIC image format handler
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116568/#review52275 --- A few methods have mismatched params in their header comments. - Aurélien Gâteau On March 3, 2014, 2:15 p.m., Alex Merry wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116568/ --- (Updated March 3, 2014, 2:15 p.m.) Review request for KDE Frameworks and Alex Merry. Repository: kimageformats Description --- Fixes to PIC image format handler Better error handling (returns false on error in read() and write()) and use the correct format if there is no alpha channel. Diffs - src/imageformats/CMakeLists.txt 44f07dd7bfb7daa1be21ececdfb5061a262e0fc8 src/imageformats/pic.cpp 9d8a7ede31c5c03a699d6a76c88aeb5e3d37ac4a src/imageformats/pic_read.cpp 484c63426723e04e5c7e96ae5355ccceccab03f4 src/imageformats/pic_rw.h 2cc958927403de57049bbd7cb3200f0b7489da3c src/imageformats/pic_write.cpp 0632eebd507e58e480856b53e71c24afc543de26 Diff: https://git.reviewboard.kde.org/r/116568/diff/ Testing --- Builds and tests pass, both with and without https://git.reviewboard.kde.org/r/116567/ applied. Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: KSpeech
On Thu, Mar 6, 2014 at 6:43 AM, Frederik Gladhorn gladh...@kde.org wrote:
Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting:
Took a quick read through that just now and it looks pretty promising
from what I saw. I guess I don't know my way around gerrit very well
because I couldn't see a place to comment on the code like
reviewboard.
Really the only difference between jovie and that class are the following:
1. jovie has some old code and ui to control jobs at a fine grain that
spd doesn't expose really well, so I left it out when I ported ktts to
spd.
I would like to expose voices and languages in a sensible fashion. This is
tricky to get right cross-platform. I started with something on Linux but
decided to implement other backends first before attempting to implement voice
selection.
For language/locale I think qtspeech should default to the system locale and
let the user select a different one.
Using the system locale as default makes sense. What do you mean by
voices you mean something like spd's voice type (male1, male2,
female1, etc.)
Ktts had a complex system of specifying a voice with xml with
language, voice type, speed, pitch, etc. attributes and if an
attribute was empty it meant any voice with the other attributes was
acceptable. I think that's a bit too fine-grained for most cases
though, most uses I can think of just want to choose the voice type,
or even just the gender, and let the user/defaults choose the rest.
If more complex specification is wanted applications could always use
ssml to change the voice as part of the text they send to qtspeech.
2. user defined filters with some sane/useful defaults (if we were to
use QtSpeech for kde notifications, set konvi to speak all messages,
there's not a way to let the user say change jpwhiting fregl: you
rock into jpwhiting says fregl you rock)
Maybe. I'd rather keep qtspeech very simple. My goals where to make it a tiny
library that is lean, fast and async by using signals and slots.
I want it to be good enough to be used in apps that use voice navigation, but
also when writing a screen reader. Some level of configuration is required in
any case. Let's come up with a good api that makes sense across platforms,
then I'm in.
Right, simple is definitely good. I'm just wondering if it could
accept plugins that implement some filtering method to filter the
text. Then filters could be as simple as a regex to convert
xml/html/etc. text into something that makes sense audibly like that
example from irc, or a complex filter plugin to change the voice could
inject ssml into the text. Maybe something like
QAbstractSpeechFilter {
public:
virtual QString filterText(QString text)
};
Then a simple filtermanager (or even part of the existing class) loads
the plugins and when say() is called it passes the text through all
the plugins filterText() methods.
Is there some other Qt library or class that takes plugins for
specific functionality we could use as inspiration for making this
work and look clean also?
3. user configurability (As a user I can't set up which voice I would
like all speech-using applications to use)
As with other Qt libs, this is more for the platform to set up. Currently
qtspeech uses whatever voice is selected system wide (aka the default). I
think that is the right approach - follow what we get from the platform.
For KDE I'd thus suggest creating a configuration module which lets the user
choose the platform defaults.
Yeah, each platform could have its own configuration of the defaults
sure, the only part missing is a real-time configuration change. For
example if Jovie is reduced to a kcm to configure speech-dispatcher's
default voice and I start listening to a pdf from okular or something
and decide I need the pitch to be lower, changing the default voice
wont change the voice that speech-dispatcher is already using to read
the pdf. Maybe that could be fixed with a patch to speech-dispatcher
to accept immediate default changes though, I'll have to think about
that.
4. dbus, though this isn't as important if each application that uses
speech links to the library and speech-dispatcher or the system apis
do the async for us already anyway as you said.
I don't see a point in adding dbus into the mix indeed. One thing that is
interesting though is what kind of effect you get when opening the speech
backend from two apps at the same time.
Items 1 and 4 will be irrelevant in a KF5 world but I'm wondering how
2 and 3 could be added either to qtspeech itself or as a kspeech
library that wraps qtspeech for kde applications to use.
Any thoughts on that? I would be pretty interested in helping with
qtspeech if it greatly simplifies or even deprecates jovie as it looks
like it could do possibly.
I'd be more than happy to get contributions of course. I cannot promise much
from my side, of course I'd like to continue working on this project as time
permits (so far it really is a
Re: Review Request 116610: Use flag types in NETRootInfo
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116610/#review52277 --- Ship it! Looks good. One question though, wasn't it possible to merge properties or properties2? I lack extensive knowledge of this domain, but it looks odd from an API point of view. - Aurélien Gâteau On March 5, 2014, 10:50 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116610/ --- (Updated March 5, 2014, 10:50 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Use flag types in NETRootInfo This replaces the usage of the unsigned long[] array with NET::Properties, NET::Properties2, NET::WindowTypes, NET::States and NET::Actions mixed in - for the fun even in different order depending on the ctor to use. This includes the following changes: * NETRootInfo::event(xcb_generic_event_t*) returns NET::Properties * new overload added to NETRootInfo::event taking NET::Properties* and NET::Properties2* as arguments * existing overload for NETRootInfo::event taking usinged long* as argument is deprecated and forwards to the new added overload * NETRootInfo::passedProperties returns NET::Properties and new methods for Properties2, WindowTypes, States and Actions are added. This is a SC-break, but there is according to lxr no usage except in the unit tests * NETRootInfo::supportedProperties returns NET::Properties and new methods for Properties2, WindowTypes, States and Actions are added. This is a SC-break, but there is according to lxr no usage except in the unit tests * ctors taking unsigned long* is changed to taking the flags as arguments. This in an SC-break, but the ctor broke already caused by the change from Display* to xcb_connection_t*. The ctor for window manager should only be used by KWin. Other ctor is also mainly only used in kde-workspace. Diffs - src/netwm_p.h 1c26d47257a4f3ce71c360c394cc5be16f32b18c src/netwm.h a5ad46fa1f0255ca6719224079bdea4598b48c51 src/netwm.cpp 288a34348f464e1158640afa1d931d9d05690cc4 src/kwindowsystem_x11.cpp 95c396b65ae0a24db6a276b9b72f4175bb7c14cc autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 Diff: https://git.reviewboard.kde.org/r/116610/diff/ Testing --- tests succeed with 116609 applied. KWin and kde-workspace will get adjusted to test. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116610: Use flag types in NETRootInfo
On March 6, 2014, 5:22 p.m., Aurélien Gâteau wrote: Looks good. One question though, wasn't it possible to merge properties or properties2? I lack extensive knowledge of this domain, but it looks odd from an API point of view. that would be a large SC break which might not be worth the effort even if it is possible. The reason why it is split is AFAIU that NET::Properties consists of 32 flags, thus hitting the bounds of the underlying int back in the days. Given that QFlags still uses either int or unsigned int I guess this border is still valid. - Martin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116610/#review52277 --- On March 5, 2014, 10:50 a.m., Martin Gräßlin wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116610/ --- (Updated March 5, 2014, 10:50 a.m.) Review request for KDE Frameworks. Repository: kwindowsystem Description --- Use flag types in NETRootInfo This replaces the usage of the unsigned long[] array with NET::Properties, NET::Properties2, NET::WindowTypes, NET::States and NET::Actions mixed in - for the fun even in different order depending on the ctor to use. This includes the following changes: * NETRootInfo::event(xcb_generic_event_t*) returns NET::Properties * new overload added to NETRootInfo::event taking NET::Properties* and NET::Properties2* as arguments * existing overload for NETRootInfo::event taking usinged long* as argument is deprecated and forwards to the new added overload * NETRootInfo::passedProperties returns NET::Properties and new methods for Properties2, WindowTypes, States and Actions are added. This is a SC-break, but there is according to lxr no usage except in the unit tests * NETRootInfo::supportedProperties returns NET::Properties and new methods for Properties2, WindowTypes, States and Actions are added. This is a SC-break, but there is according to lxr no usage except in the unit tests * ctors taking unsigned long* is changed to taking the flags as arguments. This in an SC-break, but the ctor broke already caused by the change from Display* to xcb_connection_t*. The ctor for window manager should only be used by KWin. Other ctor is also mainly only used in kde-workspace. Diffs - src/netwm_p.h 1c26d47257a4f3ce71c360c394cc5be16f32b18c src/netwm.h a5ad46fa1f0255ca6719224079bdea4598b48c51 src/netwm.cpp 288a34348f464e1158640afa1d931d9d05690cc4 src/kwindowsystem_x11.cpp 95c396b65ae0a24db6a276b9b72f4175bb7c14cc autotests/netrootinfotestwm.cpp 120fbee92d0b22862d8ce746b3b30891ecd9f056 Diff: https://git.reviewboard.kde.org/r/116610/diff/ Testing --- tests succeed with 116609 applied. KWin and kde-workspace will get adjusted to test. Thanks, Martin Gräßlin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.
On Feb. 28, 2014, 3:41 p.m., Matthew Dawson wrote: While I'm fine with the idea behind this optimization, I worry that this implementation could create situations were a configuration change is not picked up by the system. For instance, what happens if the user doesn't immediately call readConfig? This could create some subtle bugs in downstream code. I had two ideas for how this optimization could be implemented: 1) Lazy load the KConfig object the first time it is used. Then, in readConfig, the call to be reparseConfiguration could be avoided if the KConfig is created due to its call. This would retain the current behaviour, while ensuring readConfig reads in the most configuration. Other uses of the KConfig will have to ensure the KConfig object has already been created, and if the user calls one of those functions before readConfig, they will still double read the configuration. But since this is just status quo, I'm not too worried. 2) Alternately, create a set of construction functions, like make_shared, that imitate the creation of a KConfigSkeleton subclass, and then reading the configuration through readConfig. Internally, it can use a private readConfig function to ensure the configuration is no re-read. This would require changes to applications to avoid the extra configuration call, unfortunately. I saw RR #115964, and I assume that some of the reductions to the readings of oxygenrc are caused by the sharing the KConfig between some KConfigSkeleton's? If so, I'd suggest implementing solution 1 for the general case, and then making a special construction function to handle shared KConfig's. I don't want to avoid calling reparseConfiguration without some warning around this, as it may again cause some surprises. A new appropriately named function shouldn't be too bad though, as opposed to changing the behaviour of the constructor. David Faure wrote: I've been thinking about this too, but what good is a KConfigSkeleton if you don't call readSettings() on it? You can't read any settings from it then, so all you can do is a) keep it around for later or b) use it purely for writing out a new config file. Use case b) is no problem, so I think we're talking about use case a). Yes in theory an app could see a behavior change in that the config file is loaded from disk at the time of creating the skeleton rather than at the time of calling readConfig the first time. But this is why I'm making this change in 5.0 and not in 4.13. I think it's an acceptable behavior (matching KConfig's behavior more closely - it parses in the ctor, not in readEntry) and I doubt it affects many apps, since all I see everywhere is singletons - i.e. the KConfigSkeleton is created on demand at the time where it's first needed, therefore the ctor is immediately followed by readConfig. My alternative idea (let's call it 3 to complete your list) was to pass a flag to the KConfig constructor to tell it don't parse now, and setting that flag from the KConfigSkeleton constructor. Then readConfig can keep always calling reparseConfiguration(). This would work, right? Your suggestion 1 is somewhat equivalent, but since one of the ctors for KCoreConfigSkeleton takes a KSharedConfig::Ptr as input, it's not applicable, we can't delay the creation of the kconfig within KCoreConfigSkeleton since it's created beforehand by the application. Your suggestion 2 requires changing all the apps, which lowers the benefits of the optimization. Matthew Dawson wrote: I agree, it is a weird use case, and the software should probably be adjusted. However, if an app does rely on that, it is very hard for the author of the software to notice the change, even with the port to 5. If I just looked at the functions names, I'd expect readConfig to read the file all the time. Following the principle of least surprise, I'd like to avoid readConfig ever not reading the file. I'm fine with your alternate idea. I prefer that over my first idea, as it effectively does the same thing while being less invasive. For my second suggestion, I realize its downsides. I just like following the principle of least surprise. If your alternate idea is implemented, I believe that would cover most cases. Suggestion 2 can then be implemented, and its related constructor could be marked deprecated. This would allow for existing programs to continue working, while allowing developers to change their code to take advantage of the optimization. As I stated earlier, I'm not sure about who KDE wants to handle source compatibility with kdelibs. I also wouldn't mind just removing the second constructor, forcing all users to upgrade their code. Since the function is a drop in replacement, it wouldn't be that hard for developers to upgrade.
Re: qt5 polkit-qt-1 and kdesrc-build
On Sat, 01 Mar 2014 16:42:31 +0100, David Faure fa...@kde.org wrote: On Wednesday 26 February 2014 22:25:01 Milian Wolff wrote: module-set repository kde-projects branch qt5 use-modules polkit-qt-1 cmake-options -DCMAKE_BUILD_TYPE:STRING=debug end module-set Considering that all other people should hit the same issue - how did you resolve this? Can we get the above into the default configuration somehow please? It's an optional dependency, so we've been building all of KF5 without it. I don't mind adding it - but what about releasing? Is anyone taking care of releasing polkit-qt-? Or should we make it a framework so I release it with the rest of the stuff ? Cc'ing some polkit-qt contributors. Hello According to the last discussion regarding this on #kde-devel, somebody mentioned that Dario intended to name the library something along the lines of polkit-qt-qt5 or polkit-qt-5, not sure what the exact form was. If the concensus on this will be reached, I can do the needed changes, no problem, I just kind of don't feel like making decisions that big. :) In case you'd want to discuss this on IRC, Dario and I are hanging out on #polkit-kde specifically for these two projects but any other is fine (as we're the only ones there). Martin ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116604: Allow directories with . as output for meinproc
On March 5, 2014, 3:36 p.m., Burkhard Lück wrote: src/meinproc.cpp, lines 170-179 https://git.reviewboard.kde.org/r/116604/diff/1/?file=252003#file252003line170 How does this affect this code in KHelpcenter: kde-runtime/khelpcenter/glossary.cpp:149:KProcess *meinproc = new KProcess; kde-runtime/khelpcenter/glossary.cpp:153:*meinproc KStandardDirs::locate( exe, QLatin1String( meinproc4 ) ); kde-runtime/khelpcenter/glossary.cpp:154:*meinproc QLatin1String( --output ) m_cacheFile; kde-runtime/khelpcenter/glossary.cpp:155:*meinproc QLatin1String( --stylesheet ) kde-runtime/khelpcenter/glossary.cpp:157:*meinproc m_sourceFile; kde-runtime/khelpcenter/glossary.cpp:176:KProcess *meinproc = static_castKProcess *(sender()); kde-runtime/khelpcenter/toc.cpp:148:KProcess *meinproc = new KProcess; kde-runtime/khelpcenter/toc.cpp:152:*meinproc KStandardDirs::locate(exe, meinproc4); kde-runtime/khelpcenter/toc.cpp:153:*meinproc --stylesheet KStandardDirs::locate( data, khelpcenter/table-of-contents.xslt ); kde-runtime/khelpcenter/toc.cpp:154:*meinproc --output m_cacheFile; kde-runtime/khelpcenter/toc.cpp:155:*meinproc m_sourceFile; kde-runtime/khelpcenter/toc.cpp:172:KProcess *meinproc = static_castKProcess *(sender()); About the issue with dot in Path see also http://lists.kde.org/?l=kde-doc-englishm=127421104303628w=2 Yes, the bug is the one reported in that email. It has been filed as bug https://bugs.kde.org/show_bug.cgi?id=246755 (I set it in this RR). The problem was that the value was passed without quotes as parameter to the the function in libxslt. But on the other side it is not used, because the output of the stylesheet is stored in a string and then written in a file (see transform function in xslt.cpp), so it's pointless to pass it. - Luigi --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116604/#review52091 --- On March 5, 2014, 1:06 a.m., Luigi Toscano wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116604/ --- (Updated March 5, 2014, 1:06 a.m.) Review request for Documentation, KDE Frameworks, kdelibs, and Aleix Pol Gonzalez. Bugs: 246755 https://bugs.kde.org/show_bug.cgi?id=246755 Repository: kdoctools Description --- The outputFile parameter is not used by the stylesheets, so don't pass it. If a directory starts with ., it is interpreted in a wrong way by libxslt with an error like: --- XPath error : Invalid expression /home/kde-devel/.cache5/khelpcenter/help/__home__kde- devel__kde__share__doc__HTML__en__kioslave__file__index.docbook ^ runtime error Evaluating user parameter outputFile failed --- This is an old issue, it was solved on windows by not compiling that code, but I suspect that the issue has been in UNIX systems too for a long time. Another way to solve the bug is quoting the value of the parameter with '...', replacing: params.append(qstrdup(parser.value(QStringLiteral(output)).toLocal8Bit().constData())); with something like QString quotedOutput = ' + parser.value(QStringLiteral(output)) + '; params.append(qstrdup(quotedOutput.toLocal8Bit().constData())); but anyway in this case the name of output file is not used, or I can't find any occurrence in the stylesheets. The stylesheet is applied and the name of the file is used only after to write the generated XML (see tranform() function). A similar patch can be applied to kdelibs/kdoctools too (same codepath). Diffs - src/meinproc.cpp 95adcea Diff: https://git.reviewboard.kde.org/r/116604/diff/ Testing --- Run meinproc5 (and 4) with -o /something/with/a/.dotdir/myfile.txt (the directory must exist), no error anymore and the file 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 116639: Do not read LOCATION property of desktoptojson
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116639/#review52312 --- Ship it! Ship It! - Alex Merry On March 6, 2014, 3:42 p.m., Aurélien Gâteau wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116639/ --- (Updated March 6, 2014, 3:42 p.m.) Review request for Build System and KDE Frameworks. Repository: kservice Description --- This makes the code CMP0026 compliant. Surprisingly I never saw the CMake warning about this policy. Don't know why. Diffs - KF5ServiceMacros.cmake f70a185 Diff: https://git.reviewboard.kde.org/r/116639/diff/ Testing --- Tested with kservice/tests/kservicetojsontest, using both the old and the new syntax. Rebuilt kde-workspace. Thanks, Aurélien Gâteau ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 116025: Add documentation about writing find modules
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/116025/ --- (Updated March 6, 2014, 10:56 p.m.) Review request for Build System, Extra Cmake Modules and KDE Frameworks. Changes --- Update docs to add the note suggested by Stephen, as well as addressing some problems with the suggested pkg-config setup spotted by Aurëlien. Repository: extra-cmake-modules Description --- Add documentation about writing find modules Diffs (updated) - README.md 85b97b7fa003282e1eeb1113c4668a9b73e3f731 docs/writing-find-modules.md PRE-CREATION Diff: https://git.reviewboard.kde.org/r/116025/diff/ Testing --- Thanks, Alex Merry ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Jenkins build became unstable: ktexteditor_master_qt5 #236
See http://build.kde.org/job/ktexteditor_master_qt5/236/changes ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
