Re: Review Request 117131: Implement KUser::faceIconPath on Windows.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117131/ --- (Updated April 5, 2014, 1:32 a.m.) Status -- This change has been ma

Re: Review Request 117131: Implement KUser::faceIconPath on Windows.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117131/#review55008 --- This review has been submitted with commit c35ece00babf9a2ee0

Review Request 117376: fix kded build on Windows

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117376/ --- Review request for KDE Frameworks and kdewin. Repository: kded Descript

Re: Review Request 117078: Allow compiling kio on windows

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/ --- (Updated April 4, 2014, 9:20 p.m.) Review request for KDE Frameworks. C

Re: Review Request 117078: Allow compiling kio on windows

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117078/ --- (Updated April 4, 2014, 9:01 p.m.) Review request for KDE Frameworks. R

Re: Re: Where to put kglobalacceld?

2014-04-04 11:10 GMT-03:00 Martin Gräßlin : > On Friday 04 April 2014 16:06:32 Aleix Pol wrote: >> On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin wrote: >> > Hi, >> > >> > similar as to what we already have with DrKonqi moving kglobalacceld from >> > kde- >> > runtime into the globalaccel framewor

Re: Where to put kglobalacceld?

Hello, On Friday 04 April 2014 16:10:23 Martin Gräßlin wrote: > > In that case, I'd suggest moving it to plasma-workspace, but then we'll > > have to make sure to make it explicit that KGlobalAccel is not a portable > > framework, rendering components depending on it not portable (with > > emphasi

Re: Review Request 117131: Implement KUser::faceIconPath on Windows.

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117131/#review54998 --- Ship it! Ship It! src/lib/util/kuser_win.cpp

Re: Re: Where to put kglobalacceld?

On Friday 04 April 2014 16:06:32 Aleix Pol wrote: > On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin wrote: > > Hi, > > > > similar as to what we already have with DrKonqi moving kglobalacceld from > > kde- > > runtime into the globalaccel framework would significantly raise the tier > > and > > de

Re: Where to put kglobalacceld?

On Fri, Apr 4, 2014 at 3:41 PM, Martin Gräßlin wrote: > Hi, > > similar as to what we already have with DrKonqi moving kglobalacceld from > kde- > runtime into the globalaccel framework would significantly raise the tier > and > dependencies. At the moment KGlobalAccel is a tier1 framework. > > T

Where to put kglobalacceld?

Hi, similar as to what we already have with DrKonqi moving kglobalacceld from kde- runtime into the globalaccel framework would significantly raise the tier and dependencies. At the moment KGlobalAccel is a tier1 framework. The runtime component though depends on: * KF5::GlobalAccel * KF5::KCMUt

Re: libmm-qt/libnm-qt as KF5

And what is the problem depending on e-c-m? It's the base package, which will be available everywhere and being a part of KDE frameworks will make our libraries more visible and connected to KDE. We should be definitely part of frameworks, like Solid. Well, libnm-qt/libmm-qt are basically Solid