Jenkins-kde-ci: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 87 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/87/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 06 Jun 2016 06:51:04 +
Build duration: 7.2 sec

CHANGE SET
Revision d990727eed15577c86d52dc7cdf8c4e28717b2a3 by scripty: (Upgrade KF5 
version to 5.23.0.)
  change: edit CMakeLists.txt
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Jenkins-kde-ci: attica master kf5-qt5 » Linux,gcc - Build # 27 - Failure!

[no-reply]

GENERAL INFO

BUILD FAILURE
Build URL: 
https://build.kde.org/job/attica%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/27/
Project: PLATFORM=Linux,compiler=gcc
Date of build: Mon, 06 Jun 2016 06:51:04 +
Build duration: 6.7 sec

CHANGE SET
Revision 29788e69edcf3e084d61b9c09c825506afb03ed8 by scripty: (Upgrade KF5 
version to 5.23.0.)
  change: edit CMakeLists.txt
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Where to put kwayland integration plugins

[Martin Graesslin]

Hi framework-developers,

in Plasma we have a repository called kwayland-integration. It provides a 
plugin for:
* KWindowSystem
* KIdleTime

using the KWayland client API. Thus it makes these frameworks functional on 
windowing system Wayland.

I want to move the plugins into frameworks and are wondering how to do that 
and where to move them to.

I see the following options:
1. Integrate directly into kwindowsystem and kidletime
2. Merge them into frameworks-integration
3. Create a new framework kwayland-integration
4. create a new framework "kwindowsystem-wayland" and "kidletime-wayland"

Option 1 is I think an absolute no-no as it would turn kwindowsystem and 
kidletime from tier 1 to tier 2 and that would affect a huge amount of other 
frameworks. For everything which is not in tier 1, I think it's the way to go.

Option 2 is something I don't want to do as that would combine windowing 
system integration code with random other stuff and would result in weird 
dependencies. (To use KIdleTime on Wayland one needs X11 and Phonon?)

The same actually also applies to Option 3, though it is just two frameworks 
and all dependencies would be tier 1.

So personally I think option 3 or option 4 are the way to go.

What do you think? Better ideas?

Cheers
Martin

signature.asc
Description: This is a digitally signed message part.
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel

Re: Review Request 128088: Load KFileItemAction plugins with json metadata

[Elvis Angelaccio]

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

(Updated June 5, 2016, 6:14 p.m.)


Review request for Dolphin and KDE Frameworks.


Changes
---

Ark's patch has been merged on master.


Repository: dolphin


Description
---

Dolphin currently doesn't support JSON-only KFileItemAction plugins (without a 
.desktop file).
This patch adds support for them both in the context menu and in the settings 
dialog (Services pane).

Since a plugin can have both a .desktop file and JSON metadata (as is the the 
case for `kactivitymanagerd_fileitem_linking_plugin`), we need to be sure to 
not add twice the plugin in the context menu. A QSet is used to prevent this 
issue.

Open question: do we want to install these json-only plugins in a specific 
subdirectory of `$QT_PLUGIN_PATH`? Like `$QT_PLUGIN_PATH/kf5/kio` or something 
else? This way we could tell Dolphin to only look for plugins within that 
subfolder (instead of checking every plugin in `$QT_PLUGIN_PATH`).


Diffs
-

  src/dolphincontextmenu.cpp dfec76144dafd9210aa8b6f45458ded98e27ab53 
  src/settings/services/servicessettingspage.cpp 
4cfa2327c9fa77a6124b4d90040a9784cc8180c5 

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


Testing (updated)
---

* Build Ark master after commit c369264d6c
* Make sure that the Compress and Extract service menus are shown
* Make sure that the menus above can be enabled/disabled in the Services pane 
in the settings
* Make sure that `kactivitymanagerd_fileitem_linking_plugin` is not shown twice 
in the context menu


Thanks,

Elvis Angelaccio

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

Re: Review Request 127765: RFC: Cache global config files

[Anthony Fieroni]

> On Април 28, 2016, 2:01 след обяд, Anthony Fieroni wrote:
> > src/core/kconfig.cpp, line 688
> > 
> >
> > So, when make it static you can get concurrent call

Ping! Add mutex and ship.


- Anthony


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


On Април 27, 2016, 7:14 след обяд, Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127765/
> ---
> 
> (Updated Април 27, 2016, 7:14 след обяд)
> 
> 
> Review request for KDE Frameworks and Matthew Dawson.
> 
> 
> Repository: kconfig
> 
> 
> Description
> ---
> 
> A next step for my little quest is improving KConfig impact upon start.
> 
> In callgrind terms, 20% of dolphin's startup time is KConfig and 15% is 
> parsing global files, which is essentially loading kdeglobals 70 times. This 
> of course also means that kdeglobals is scattered 70 times in each 
> application's memory space.
> 
> To improve such situation, here's an attempt to cache these. I'm not an 
> expert in KConfig, so feedback is really appreciated 
> [[1]](http://i1.kym-cdn.com/photos/images/facebook/000/234/765/b7e.jpg)
> 
> 
> Diffs
> -
> 
>   src/core/kconfig.cpp ad52da9 
> 
> Diff: https://git.reviewboard.kde.org/r/127765/diff/
> 
> 
> Testing
> ---
> 
> Tests pass, KConfig becomes 6% of dolphin at load.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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

Review Request 128106: kcatalog: Fix building with musl libc.

[Kylie McClain]

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

Review request for KDE Frameworks and Chusslove Illich.


Repository: ki18n


Description
---

musl libc's gettext implementation doesn't have an _nl_msg_cat_cntr
function, so it fails at linking with an undefined reference.
Since musl doesn't provide a macro for checking if it's a non-libintl
implentation of gettext, or even if the libc is musl, instead we just
check if _nl_msg_cat_cntr is defined.


Diffs
-

  src/kcatalog.cpp 6682d62341dee03f5fc4906c2a88c6cda82fbedb 

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


Testing
---


Thanks,

Kylie McClain

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

Re: Review Request 127850: Let Plasma::Corona load the layout on all cases.

[Anthony Fieroni]

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



Ping?

- Anthony Fieroni


On Май 12, 2016, 2:20 преди обяд, Aleix Pol Gonzalez wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/127850/
> ---
> 
> (Updated Май 12, 2016, 2:20 преди обяд)
> 
> 
> Review request for KDE Frameworks, Plasma and David Rosca.
> 
> 
> Bugs: 60777
> http://bugs.kde.org/show_bug.cgi?id=60777
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> Iteration of: https://git.reviewboard.kde.org/r/127848/
> 
> We either load the existing layout or we load a default one.
> 
> With this, it could be removed from ShellCorona.
> 
> 
> Diffs
> -
> 
>   src/plasma/corona.h d8f829a 
>   src/plasma/corona.cpp 1784516 
> 
> Diff: https://git.reviewboard.kde.org/r/127850/diff/
> 
> 
> Testing
> ---
> 
> Tests pass.
> PlasmaShell prints completed once both with and without configuration.
> 
> 
> Thanks,
> 
> Aleix Pol Gonzalez
> 
>

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