Re: Let's get in release mode!

Hi Kévin, On Saturday, December 14, 2013 20:30:14 Kevin Ottens wrote: > Once the technology preview is tagged, then all attention will be needed on > the remaining tasks to get a final release. This list looks suspiciously > short to me (although some tasks are in fact rather large), so either we

Let's get in release mode!

Hello everyone, Now we're really getting there! Epics and review board are clean, thanks to everyone who helped to get there. Now it's the time to go for the last push. For that I opened what will be the last epic for the 5.0 release: http://community.kde.org/Frameworks/Epics/KF5.0_Release_Prepa

Jenkins build is back to stable : kdelibs_frameworks_qt5 #1851

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

Re: KPageDialog - What happened to source compatibility?

On Saturday 14 December 2013 16:30:04 Martin Graesslin wrote: > On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: > > I think to remember one of the goals was that the KF5 would be as source > > compatible as possible. > > > > Now i see that KPageDialog is not a KDialog anymore and th

Re: Tracking bugs in Frameworks

Hi, 2013/12/14 David Edmundson: > As we gear Frameworks up for release we need a way to track bugs that > exist in the new Frameworks. > > We have two options; either we copy all the bugs in kdelibs, triaging, > testing and moving to the right new component or we start fresh. > > There are approxi

Re: KPageDialog - What happened to source compatibility?

On Saturday 14 December 2013 16:40:23 Albert Astals Cid wrote: > El Dissabte, 14 de desembre de 2013, a les 16:30:04, Martin Graesslin va > > escriure: > > On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: > > > I think to remember one of the goals was that the KF5 would be as source

Update extra-cmake-modules when updating kdelibs frameworks

Hi, due to the split in KDECompilerSettings and KDEFrameworkCompilerSettings that just happened you'll need to update extra-cmake-modules if you update kdelibs frameworks branch. Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-dev

Re: Review Request 114447: Split Frameworks only definitions to a new file

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/ --- (Updated Dec. 14, 2013, 3:58 p.m.) Status -- This change has been mar

Re: KPageDialog - What happened to source compatibility?

El Dissabte, 14 de desembre de 2013, a les 16:30:04, Martin Graesslin va escriure: > On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: > > I think to remember one of the goals was that the KF5 would be as source > > compatible as possible. > > > > Now i see that KPageDialog is not a

Re: Review Request 114447: Split Frameworks only definitions to a new file

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/#review45683 --- Ship it! Ship It! - Aleix Pol Gonzalez On Dec. 14, 2013, 3:

Re: Review Request 114447: Split Frameworks only definitions to a new file

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/ --- (Updated Dec. 14, 2013, 3:29 p.m.) Review request for KDE Frameworks and A

Review Request 114447: Split Frameworks only definitions to a new file

--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/114447/ --- Review request for KDE Frameworks and Aleix Pol Gonzalez. Repository: extr

Re: KPageDialog - What happened to source compatibility?

On Saturday 14 December 2013 16:18:44 Albert Astals Cid wrote: > I think to remember one of the goals was that the KF5 would be as source > compatible as possible. > > Now i see that KPageDialog is not a KDialog anymore and thus setButtons, > setDefaultButton, setButtonGuiItem, etc are not availab

KPageDialog - What happened to source compatibility?

I think to remember one of the goals was that the KF5 would be as source compatible as possible. Now i see that KPageDialog is not a KDialog anymore and thus setButtons, setDefaultButton, setButtonGuiItem, etc are not available in it anymore. Now, i *do* understand that for the tierization some

Re: Forcing Q_SLOTS on non frameworks code

On Sat, Dec 14, 2013 at 3:58 PM, Albert Astals Cid wrote: > El Dissabte, 14 de desembre de 2013, a les 14:30:14, Kevin Ottens va > escriure: > > On Saturday 14 December 2013 13:55:50 Albert Astals Cid wrote: > > > Hi there, so here I am at the KF5 porting sprint at Barcelona trying to > > > port

Re: Forcing Q_SLOTS on non frameworks code

On 14/12/13 15:04, Albert Astals Cid wrote: > Easy peasy. > > extra-cmake-modules/kde-modules/KDECompilerSettings.cmake does > > add_definitions(-DQT_NO_CAST_TO_ASCII > -DQT_NO_CAST_FROM_ASCII > -DQT_STRICT_ITERATORS > -DQT_NO_URL_CAST_FROM_STRING >

Re: Forcing Q_SLOTS on non frameworks code

El Dissabte, 14 de desembre de 2013, a les 15:58:49, Albert Astals Cid va escriure: > El Dissabte, 14 de desembre de 2013, a les 14:30:14, Kevin Ottens va escriure: > > On Saturday 14 December 2013 13:55:50 Albert Astals Cid wrote: > > > Hi there, so here I am at the KF5 porting sprint at Barcelo

Re: Forcing Q_SLOTS on non frameworks code

El Dissabte, 14 de desembre de 2013, a les 14:30:14, Kevin Ottens va escriure: > On Saturday 14 December 2013 13:55:50 Albert Astals Cid wrote: > > Hi there, so here I am at the KF5 porting sprint at Barcelona trying to > > port libkdegames and I am realizing that I can not use code like > > > >

Re: Forcing Q_SLOTS on non frameworks code

On Saturday 14 December 2013 13:55:50 Albert Astals Cid wrote: > Hi there, so here I am at the KF5 porting sprint at Barcelona trying to port > libkdegames and I am realizing that I can not use code like > > private slots: > > anymore. > > I understand that for frameworks libraries it is inter

Forcing Q_SLOTS on non frameworks code

Hi there, so here I am at the KF5 porting sprint at Barcelona trying to port libkdegames and I am realizing that I can not use code like private slots: anymore. I understand that for frameworks libraries it is interesting to have -DQT_NO_SIGNALS_SLOTS_KEYWORDS defined so we end up with code t

Tracking bugs in Frameworks

As we gear Frameworks up for release we need a way to track bugs that exist in the new Frameworks. We have two options; either we copy all the bugs in kdelibs, triaging, testing and moving to the right new component or we start fresh. There are approximate 1400 open bugs marked against in kdelibs