Re: KDNSSD

[Kevin Ottens]

Hello,

On Friday 07 March 2014 00:54:59 Alex Merry wrote:
> On 07/03/14 00:52, Alex Merry wrote:
> > OK, so it looks like the immediate plan with KDNSSD is to rename
> > "kdnssd" to "zeroconf-ioslave" and "kdnssd-framework" to "kdnssd".  I
> > guess this involves filing sysadmin tickets.
> > 
> > What else do we (I) need to deal with, given that kdnssd, which will be
> > renamed to zeroconf-ioslave, is part of the KDE SC 4 releases?

As for impacting KDE SC 4, you'll have to inform and coordinate with release-
team but that's pretty much it.

Well, also need to give a head up on kde-core-devel and kde-devel, people will 
be impacted by the rename so likely some remotes to change and scripts to 
adjust on their side.

> Oh, and who else needs to approve this?  The kdenetwork maintainer (not
> sure who that is)?  kdnssd has Jeremy Whiting and Urs Wolfer listed as
> project managers on https://projects.kde.org/projects/kde/kdenetwork/kdnssd

Check with Jeremy Whiting and Urs Wolfer indeed. I'm not sure how active they 
are though, so if you didn't hear from them by next friday assume they don't 
mind the change.

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: KDNSSD

[Alex Merry]

On 07/03/14 00:52, Alex Merry wrote:
> OK, so it looks like the immediate plan with KDNSSD is to rename
> "kdnssd" to "zeroconf-ioslave" and "kdnssd-framework" to "kdnssd".  I
> guess this involves filing sysadmin tickets.
> 
> What else do we (I) need to deal with, given that kdnssd, which will be
> renamed to zeroconf-ioslave, is part of the KDE SC 4 releases?

Oh, and who else needs to approve this?  The kdenetwork maintainer (not
sure who that is)?  kdnssd has Jeremy Whiting and Urs Wolfer listed as
project managers on https://projects.kde.org/projects/kde/kdenetwork/kdnssd

Alex

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

KDNSSD

[Alex Merry]

OK, so it looks like the immediate plan with KDNSSD is to rename
"kdnssd" to "zeroconf-ioslave" and "kdnssd-framework" to "kdnssd".  I
guess this involves filing sysadmin tickets.

What else do we (I) need to deal with, given that kdnssd, which will be
renamed to zeroconf-ioslave, is part of the KDE SC 4 releases?

Alex
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Review Request 116646: Improve FindWayland.cmake

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116646/
---

Review request for Build System, Extra Cmake Modules and KDE Frameworks.


Repository: extra-cmake-modules


Description
---

Improve FindWayland.cmake

- Use Wayland_VERSION instead of Wayland_VERSION_STRING
- Put pkg-config calls within the helper macro
- Extract the version from wayland-version.h if necessary
- Add the dependency of wayland-egl on wayland-client
- Improve documentation


Diffs
-

  find-modules/FindWayland.cmake a121de9f8adda1e035b0f8e8401be26a45b61af4 

Diff: https://git.reviewboard.kde.org/r/116646/diff/


Testing
---

Created a test CMakeLists.txt to call this, and played with various arguments 
to COMPONENTS and OPTIONAL_COMPONENTS, including when include files for certain 
components were removed from the system (so those components would not be 
found).  Everything worked as expected.


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

[KDE CI System]

See 

___
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

[Stephen Kelly]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116025/#review52316
---


Looks like a good manual.

- Stephen Kelly


On March 6, 2014, 10:56 p.m., Alex Merry wrote:
> 
> ---
> 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.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Add documentation about writing find modules
> 
> 
> Diffs
> -
> 
>   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

Re: Review Request 116025: Add documentation about writing find modules

[Alex Merry]

---
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

Re: Review Request 116639: Do not read LOCATION property of desktoptojson

[Alex Merry]

---
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 116604: Allow directories with . as output for meinproc

[Luigi Toscano]

> On March 5, 2014, 3:36 p.m., Burkhard Lück wrote:
> > src/meinproc.cpp, lines 170-179
> > 
> >
> > 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_cast(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_cast(sender());
> > 
> > About the issue with dot in Path see also
> > http://lists.kde.org/?l=kde-doc-english&m=127421104303628&w=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: KSpeech

[Christoph Feck]

On Thursday 06 March 2014 17:13:19 Jeremy Whiting wrote:
> On Thu, Mar 6, 2014 at 6:43 AM, Frederik Gladhorn  
wrote:
> > Onsdag 5. mars 2014 23.04.12 skrev Jeremy Whiting:
> >> 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.

Let me refer to http://www.w3.org/TR/2011/WD-css3-speech-20110419/
which defines attributes a web page can use to influence speech. Would 
be nice if we had API supporting web speech.

Regarding voice selection, it would be very useful to allow the 
application to specify female/male/child voice via API (in addition to 
the ability to let the user reconfigure actual voices). Similar to 
letting the application request Sans, Sans Serif, and Monospaced font.

For example, when generating different voices while reading out e-book 
stories.

Christoph Feck (kdepepo)
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: qt5 polkit-qt-1 and kdesrc-build

[Martin Briza]

On Sat, 01 Mar 2014 16:42:31 +0100, David Faure  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 116461: KConfigSkeleton: avoid calling reparseConfiguration() immediately after creation.

[Matthew Dawson]

> 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 the

Re: Review Request 116610: Use flag types in NETRootInfo

[Martin Gräßlin]

> 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 116610: Use flag types in NETRootInfo

[Aurélien Gâteau]

---
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: KSpeech

[Jeremy Whiting]

On Thu, Mar 6, 2014 at 6:43 AM, Frederik Gladhorn  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 " 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 wo

Re: Review Request 116568: Fixes to PIC image format handler

[Aurélien Gâteau]

---
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: Review Request 116591: Use dedicated NET::Properties and NET::Properties2 in NETWinInfo

[Aurélien Gâteau]

---
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

Review Request 116639: Do not read LOCATION property of desktoptojson

[Aurélien Gâteau]

---
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 116090: Use $ instead of get_target_property(... LOCATION)

[Aurélien Gâteau]

> 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 
> > "$", 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 $ 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

Re: Review Request 116628: Avoid multiple warnings caused by CMake Policy 0026

[Aurélien Gâteau]

---
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: KSpeech

[Frederik Gladhorn]

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 " 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  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 

Re: Review Request 116628: Avoid multiple warnings caused by CMake Policy 0026

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116628/#review52246
---

Ship it!


Ship It!

- Alex Merry


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 116090: Use $ instead of get_target_property(... LOCATION)

[Aurélien Gâteau]

> 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 
> > "$", 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 ).

I just did that here: https://git.reviewboard.kde.org/r/116628/


- 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 $ 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

Jenkins build became unstable: kitemmodels_master_qt5 #25

[KDE CI System]

See 

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 116096: Re-enable autotests

[Alex Merry]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116096/
---

(Updated March 6, 2014, 11:53 a.m.)


Status
--

This change has been marked as submitted.


Review request for KDE Frameworks.


Repository: kitemmodels


Description
---

Re-enable autotests

modeltest.(cpp|h) are taken from Qt 5.3.  The license header has been
trimmed to clarify which license we are using it under, and to reflect
the fact we use a COPYING.LIB file instead of LICENSE.LGPL.


Diffs
-

  autotests/proxymodeltestsuite/modeltest.cpp 
51ad27f3fef5cf0d62e92eb149e4cf9149b45e95 
  autotests/proxymodeltestsuite/modeltest.h 
20d5c36e32e69bb69fffad86ccc02e44bfade425 
  autotests/proxymodeltestsuite/modelselector.h 
c1163084170d4409112949057562abbfa909dc14 
  autotests/proxymodeltestsuite/eventloggerregister.cpp 
6be780108c71db6c32cfbb2c88524366435ea301 
  autotests/proxymodeltestsuite/CMakeLists.txt 
972226b7dd3477b7d064ececb307609e67d81670 
  autotests/kselectionproxymodeltestsuite.h 
6204b7733f995614c43930af03d12d13e0cb2a3f 
  autotests/klinkitemselectionmodeltest.cpp 
e1a47e4cf58e85d690c58fb1b40bfdd8cfb81431 
  autotests/bihash/CMakeLists.txt 44c965c7597ac48c81bba70f07979b51bf8547aa 
  CMakeLists.txt d153ba3d658ba70a0dca2b9e04b6cdd1e17d9db3 

Diff: https://git.reviewboard.kde.org/r/116096/diff/


Testing
---

Tests build.  3 out of 4 pass.


Thanks,

Alex Merry

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 116096: Re-enable autotests

[Commit Hook]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/116096/#review52242
---


This review has been submitted with commit 
e9d5da5d908cf768886c109b67b5d3db0c2fe21f by Alex Merry to branch master.

- Commit Hook


On March 5, 2014, 12:08 p.m., Alex Merry wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/116096/
> ---
> 
> (Updated March 5, 2014, 12:08 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kitemmodels
> 
> 
> Description
> ---
> 
> Re-enable autotests
> 
> modeltest.(cpp|h) are taken from Qt 5.3.  The license header has been
> trimmed to clarify which license we are using it under, and to reflect
> the fact we use a COPYING.LIB file instead of LICENSE.LGPL.
> 
> 
> Diffs
> -
> 
>   autotests/proxymodeltestsuite/modeltest.cpp 
> 51ad27f3fef5cf0d62e92eb149e4cf9149b45e95 
>   autotests/proxymodeltestsuite/modeltest.h 
> 20d5c36e32e69bb69fffad86ccc02e44bfade425 
>   autotests/proxymodeltestsuite/modelselector.h 
> c1163084170d4409112949057562abbfa909dc14 
>   autotests/proxymodeltestsuite/eventloggerregister.cpp 
> 6be780108c71db6c32cfbb2c88524366435ea301 
>   autotests/proxymodeltestsuite/CMakeLists.txt 
> 972226b7dd3477b7d064ececb307609e67d81670 
>   autotests/kselectionproxymodeltestsuite.h 
> 6204b7733f995614c43930af03d12d13e0cb2a3f 
>   autotests/klinkitemselectionmodeltest.cpp 
> e1a47e4cf58e85d690c58fb1b40bfdd8cfb81431 
>   autotests/bihash/CMakeLists.txt 44c965c7597ac48c81bba70f07979b51bf8547aa 
>   CMakeLists.txt d153ba3d658ba70a0dca2b9e04b6cdd1e17d9db3 
> 
> Diff: https://git.reviewboard.kde.org/r/116096/diff/
> 
> 
> Testing
> ---
> 
> Tests build.  3 out of 4 pass.
> 
> 
> Thanks,
> 
> Alex Merry
> 
>

___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 116616: Remove unused find-modules back to the attic

[Alex Merry]

---
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

Re: Review Request 116616: Remove unused find-modules back to the attic

[Commit Hook]

---
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 116628: Avoid multiple warnings caused by CMake Policy 0026

[Aleix Pol Gonzalez]

---
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

Review Request 116628: Avoid multiple warnings caused by CMake Policy 0026

[Aurélien Gâteau]

---
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: [kdesrc-build] /: Use kde-runtime/frameworks instead of kde-runtime/master

[David Faure]

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