What are the plans with CamelCase includes?

Hi, what are the plans with offering CamelCase includes in KF5 (e.g. #include )? On a quick search could not find anything mentioned somewhere. If I saw correctly, then currently CamelCase includes (for existing classes) are only available by KF5::KDE4Support, due to being the module which has

Re: kde4support: kstandarddirs_unittest fix

On Tue, Dec 24, 2013 at 5:37 AM, David Faure wrote: > On Monday 23 December 2013 14:42:45 Alex Merry wrote: >> On 23/12/13 14:23, Alex Merry wrote: >> > On 23/12/13 12:52, David Faure wrote: >> >> On Monday 23 December 2013 11:43:39 Alex Merry wrote: >> >>> Either way, the tests will fail is KDEDI

RFC: Top level git repository for all 57 Frameworks repositories

On Tuesday, December 24, 2013 12:12:57 AM Alex Merry wrote: > On 23/12/13 13:16, nerdopolis wrote: > > Hi. > > In my opinion the Frameworks split into 57 repositories could make it > > harder to for users to create build scripts around KDE Frameworks 5. > > I can see why it had to be done, I heard

Re: RFC: Top level git repository for all 57 Frameworks repositories

On 23/12/13 13:16, nerdopolis wrote: > Hi. > In my opinion the Frameworks split into 57 repositories could make it harder > to for users to create build scripts around KDE Frameworks 5. > I can see why it had to be done, I heard it's so that they can be on separate > release cycles. > > > There

RFC: Top level git repository for all 57 Frameworks repositories

Hi. I create custom scripts as I need more control over what they do. For example, I use checkinstall in mine and other things. But the creation of build scripts was just an example, I guess... I can imagine that such a thing would make it easier for other people doing other things as well tho

Re: Framework licenses

On 23/12/13 19:48, Alex Merry wrote: > On 23/12/13 18:46, Aurélien Gâteau wrote: >> - kmediaplayer: all the code is X11. Should we license the whole framework >> under X11? > > Well, the source tarball can be distributed under the X11 license, but > any builds will link against LGPL code, and hen

Re: Refocusing the tech preview

Le lundi 23 décembre 2013 18:41:36 Alex Merry a écrit : > On 23/12/13 14:18, Aurélien Gâteau wrote: > > Missing COPYING.LIB files are more annoying, though. Right now they are > > missing in kf5umbrella, kmediaplayer and plasma-framework (but I assume > > plasma-framework is not part from the tp1?)

Re: Framework licenses

On 23/12/13 18:46, Aurélien Gâteau wrote: > - kmediaplayer: all the code is X11. Should we license the whole framework > under X11? Well, the source tarball can be distributed under the X11 license, but any builds will link against LGPL code, and hence must be distributed under that license. I w

Re: Framework licenses

On 23/12/13 18:46, Aurélien Gâteau wrote: > - plasma-framework: this framework uses multiple licenses, but majority is > LGPL (this is the case for many other frameworks). Should we use a LGPL 2.1 > COPYING.LIB file? A quick attack with git grep shows the majority of code to be LGPL 2 (+), with

Framework licenses (was: Refocusing the tech preview)

Le lundi 23 décembre 2013 18:30:11 Kevin Ottens a écrit : > > Missing COPYING.LIB files are more annoying, though. Right now they are > > missing in kf5umbrella, kmediaplayer and plasma-framework (but I assume > > plasma-framework is not part from the tp1?) I am going to add them this > > afternoon

Re: Refocusing the tech preview

On 23/12/13 14:18, Aurélien Gâteau wrote: > Missing COPYING.LIB files are more annoying, though. Right now they are > missing in kf5umbrella, kmediaplayer and plasma-framework (but I assume > plasma-framework is not part from the tp1?) I am going to add them this > afternoon. On the assumption

Re: Refocusing the tech preview

On Monday 23 December 2013 15:18:04 Aurélien Gâteau wrote: > Le samedi 21 décembre 2013 12:42:04 Kevin Ottens a écrit : > > Hello people, > > > > I see that new tasks appeared in the wiki, that's great, they were clearly > > missing. That said, they were all earmarked for the tech preview, so I >

Re: kde4support: kstandarddirs_unittest fix

On 23/12/13 16:37, David Faure wrote: > On Monday 23 December 2013 14:42:45 Alex Merry wrote: >> Ah, I should say that the reason setting it correctly is tricky is >> because it turns out it doesn't actually need to contain the >> installation directory. The important thing is that it contains the

Re: kde4support: kstandarddirs_unittest fix

On Monday 23 December 2013 14:42:45 Alex Merry wrote: > On 23/12/13 14:23, Alex Merry wrote: > > On 23/12/13 12:52, David Faure wrote: > >> On Monday 23 December 2013 11:43:39 Alex Merry wrote: > >>> Either way, the tests will fail is KDEDIRS is not set correctly; I think > >>> the right approach t

Re: kde4support: kstandarddirs_unittest fix

On 21/12/13 11:23, Alex Merry wrote: > KStandardDirs does not add directories that do not exist, UNLESS they > are the directory returned by installPrefix(). kde4support does not > install anything in share/applications, therefore if you install > kde4support in its own prefix, $PREFIX/share/appli

Re: kde4support: kstandarddirs_unittest fix

On 23/12/13 14:23, Alex Merry wrote: > On 23/12/13 12:52, David Faure wrote: >> On Monday 23 December 2013 11:43:39 Alex Merry wrote: >>> Either way, the tests will fail is KDEDIRS is not set correctly; I think >>> the right approach there is to do a bit of a sanity check in >>> initTestCase() and

[PATCH] Better checks for all the necessary libs to build the XSync-based poller

Harald found out some holes in our CMake checks for the XSync-based poller in KIdleTime: it did not fail if some of the libs necessary to build it was not there. Attached patch should fix this. Aurélien>From 14a2908747940669b71f24fc5f07651843bb4b8f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Aur=C3

Re: kde4support: kstandarddirs_unittest fix

On 23/12/13 12:52, David Faure wrote: > On Monday 23 December 2013 11:43:39 Alex Merry wrote: >> On 23/12/13 08:36, David Faure wrote: >>> Still, replacing tests that pass means introducing the risk that we're not >>> testing for the same thing anymore. But if you're fully convinced, go >>> ahead.

Re: Refocusing the tech preview

Le samedi 21 décembre 2013 12:42:04 Kevin Ottens a écrit : > Hello people, > > I see that new tasks appeared in the wiki, that's great, they were clearly > missing. That said, they were all earmarked for the tech preview, so I took > the liberty to move most of them to the list about the final rel

Re: RFC: Top level git repository for all 57 Frameworks repositories

El Dilluns, 23 de desembre de 2013, a les 08:16:59, nerdopolis va escriure: > Hi. > In my opinion the Frameworks split into 57 repositories could make it harder > to for users to create build scripts around KDE Frameworks 5. Why would anyone create a build script around KDE Frameworks 5 when ther

Re: KUrlRequester crashes

> > You either need to add /usr/share to XDG_DATA_DIRS, or to install > shared-mime- > info into /opt/KF5. Otherwise the code can't see any mimetypes > > > Thank you. Adding /usr/share to XDG_DATA_DIRS solves the issue. ___ Kde-frameworks-devel maili

RFC: Top level git repository for all 57 Frameworks repositories

Hi. In my opinion the Frameworks split into 57 repositories could make it harder to for users to create build scripts around KDE Frameworks 5. I can see why it had to be done, I heard it's so that they can be on separate release cycles. There is a way to unify these Frameworks while keeping the

Re: kdnssd is source incompatible with KDE4

On Monday 23 December 2013 10:37:44 Alex Merry wrote: > On 23/12/13 08:27, David Faure wrote: > > On Saturday 21 December 2013 18:19:13 Albert Astals Cid wrote: > >> P.S: Speaking of which, there's the porting file? > > > > kdelibs/KDE5PORTING.html in the frameworks branch. > > We need to find a n

Re: kde4support: kstandarddirs_unittest fix

On Monday 23 December 2013 11:43:39 Alex Merry wrote: > On 23/12/13 08:36, David Faure wrote: > > Still, replacing tests that pass means introducing the risk that we're not > > testing for the same thing anymore. But if you're fully convinced, go > > ahead. I wouldn't have rewritten these, but I do

Jenkins build is back to normal : plasma-framework_master_qt5 #998

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

Re: kde4support: kstandarddirs_unittest fix

On 23/12/13 08:36, David Faure wrote: > Still, replacing tests that pass means introducing the risk that we're not > testing for the same thing anymore. But if you're fully convinced, go ahead. > I wouldn't have rewritten these, but I don't want to veto the change. > > In fact my thinking when wr

Re: Macro naming

On Mon, Dec 23, 2013 at 12:28 PM, Martin Graesslin wrote: > On Monday 23 December 2013 10:36:22 Alex Merry wrote: > > Oh, and the versioning that we get from a kf5 prefix could prove to be > > useful when we transition to KF6. > or means additional porting effort (though that can be sed'ed) > We'

KF5 Update Meeting 2013-w52 Reminder

Hello all, Just a quick reminder: The next KF5 Update Meeting will happen on #kde-devel tomorrow at 4pm Paris time. See you for the last meeting of 2013! Regards. -- Kévin Ottens, http://ervin.ipsquad.net KDAB - proud supporter of KDE, http://www.kdab.com signature.asc Description: This is

Re: Macro naming

On Monday 23 December 2013 10:36:22 Alex Merry wrote: > On 23/12/13 01:42, Alex Merry wrote: > > On 23/12/13 01:27, Aleix Pol wrote: > >> On Mon, Dec 23, 2013 at 1:17 AM, Alex Merry >> > >> > wrote: > >> Currently, we are not consistent about CMake macro naming i

Re: KUrlRequester crashes

On Monday 23 December 2013 13:03:16 Antonis Tsiapaliokas wrote: > Hello, > > The output of the $XDG_DATA_DIRS is /opt/KF5/share, is it wrong? > Based on the wiki, this is correct. You either need to add /usr/share to XDG_DATA_DIRS, or to install shared-mime- info into /opt/KF5. Otherwise the code

Re: KUrlRequester crashes

Hello, The output of the $XDG_DATA_DIRS is /opt/KF5/share, is it wrong? Based on the wiki, this is correct. About the mimetypes, i have run kbuildsycoca5... Also i have attach my environmental variables. variables Description: Binary data ___ Kde-fra

Re: kdnssd is source incompatible with KDE4

On 23/12/13 08:27, David Faure wrote: > On Saturday 21 December 2013 18:19:13 Albert Astals Cid wrote: >> P.S: Speaking of which, there's the porting file? > > kdelibs/KDE5PORTING.html in the frameworks branch. > We need to find a new home for it, indeed. > Currently at http://community.kde.org/

Re: Macro naming

On 23/12/13 01:42, Alex Merry wrote: > On 23/12/13 01:27, Aleix Pol wrote: >> On Mon, Dec 23, 2013 at 1:17 AM, Alex Merry > > wrote: >> >> Currently, we are not consistent about CMake macro naming in the >> frameworks. KAuth, for example, has kauth_install_act

Re: kde4support: kstandarddirs_unittest fix

On Saturday 21 December 2013 11:23:01 Alex Merry wrote: > On 21/12/13 00:19, David Faure wrote: > > On Friday 20 December 2013 23:07:08 Alex Merry wrote: > >> In my continuing mission to make the frameworks green on Jenkins: > >> > >> This makes the tests work even when not installed, even when kd

Re: kdnssd is source incompatible with KDE4

On Saturday 21 December 2013 18:19:13 Albert Astals Cid wrote: > P.S: Speaking of which, there's the porting file? kdelibs/KDE5PORTING.html in the frameworks branch. We need to find a new home for it, indeed. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular K