[Differential] [Updated] D3883: Generate gperf output at build time

ltoscano added a dependency: D3830: Add a new FindGperf module. REPOSITORY R270 KCodecs REVISION DETAIL https://phabricator.kde.org/D3883 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: pino, #frameworks

[Differential] [Updated] D3830: Add a new FindGperf module

ltoscano added a dependent revision: D3883: Generate gperf output at build time. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3830 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: pino, #frameworks, #buildsystem, #windo

[Differential] [Request, 862 lines] D3883: Generate gperf output at build time

pino created this revision. pino added a reviewer: Frameworks. Restricted Application added a project: Frameworks. REVISION SUMMARY Look for gperf, and use it to generate the hash-based lookup for the entities; this replaces the static generated file in the sources, adding a build time only

Re: Review Request 129709: Fix checking for valid date entered

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129709/ --- (Updated Dec. 31, 2016, 12:13 a.m.) Status -- This change has been m

Review Request 129730: [WIP] : kbuildsyscoca should skip /Applications on Mac

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129730/ --- Review request for KDE Software on Mac OS X and KDE Frameworks. Repositor

Review Request 129729: [OS X] : don't risk deleting /Applications (!)

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129729/ --- Review request for KDE Software on Mac OS X and KDE Frameworks. Repositor

Re: Review Request 129709: Fix checking for valid date entered

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129709/#review101674 --- Ship it! Ship It! - Christoph Feck On Dec. 30, 2016, 8

Re: Review Request 129709: Fix checking for valid date entered

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129709/ --- (Updated Dec. 30, 2016, 7:10 p.m.) Review request for KDE Frameworks and

Re: Mac: kbuildsycoca5 and kded5 deadloop *somewhere* after upgrading to Qt 5.7.1

For the sake of completeness, here are the QSP locations returned (with "XDG-compliant" writable locations), for 5.6.2 and 5.7.1 . R. DesktopLocation: "Desktop" = */Users/bertin/Desktop* DocumentsLocation: "Documents" = */Users/bertin/Documents* FontsLocation: "Fonts" = */Users/bertin/Librar

Re: Mac: kbuildsycoca5 and kded5 deadloop *somewhere* after upgrading to Qt 5.7.1

On Friday December 30 2016 18:49:46 David Faure wrote: > > Edit: it doesn't. > > What's it and what is it that it doesn't? Sorry, yes. > Can you reproduce the problem on Linux or not? No. kbuildsycoca5 finishes without issues there. It may run a bit slower but that could just as well be my im

Re: Mac: kbuildsycoca5 and kded5 deadloop *somewhere* after upgrading to Qt 5.7.1

On vendredi 30 décembre 2016 18:19:17 CET René J.V. Bertin wrote: > On Friday December 30 2016 18:08:11 René J.V. Bertin wrote: > > My analoguous Linux build isn't finished yet so I cannot say whether this > > is Mac-specific or something that may have to do with the way I install > > things. > > E

[Differential] [Commented On] D3830: Add a new FindGperf module

pino added a comment. In https://phabricator.kde.org/D3830#72502, @rjvbb wrote: > You're still determining the location from the path with this new revision, right? For the input file? Yes. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3830

Re: Mac: kbuildsycoca5 and kded5 deadloop *somewhere* after upgrading to Qt 5.7.1

On Friday December 30 2016 18:08:11 René J.V. Bertin wrote: > My analoguous Linux build isn't finished yet so I cannot say whether this is > Mac-specific or something that may have to do with the way I install things. Edit: it doesn't. And FWIW, I did rebuild KService and KDEd against the new

[Differential] [Commented On] D3830: Add a new FindGperf module

rjvbb added a comment. You're still determining the location from the path with this new revision, right? REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D3830 EMAIL PREFERENCES https://phabricator.kde.org/settings/panel/emailpreferences/ To: pino, #fr

Mac: kbuildsycoca5 and kded5 deadloop *somewhere* after upgrading to Qt 5.7.1

Hi, I am in the process of upgrading to Qt 5.7.1 . While porting my Qt5 patches and building was largely a no-brainer and most applications seem to work without issues, there are (at least) 2 annoying exceptions among basic KF5 apps: - kded5 deadloops somewhere - kbuildsysoca5 idem. In additio

Re: Review Request 129709: Fix checking for valid date entered

> On Dec. 30, 2016, 5:59 p.m., Christoph Feck wrote: > > src/kdatecombobox.cpp, line 58 > > > > > > Could you please add a short comment what this function does? A > > condition like > > > > !date.isVali

Re: Review Request 129709: Fix checking for valid date entered

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129709/#review101672 --- src/kdatecombobox.cpp (line 58)

[Differential] [Updated, 125 lines] D3830: Add a new FindGperf module

pino updated this revision to Diff 9502. pino added a comment. Typo fix in previous revision. REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D3830?vs=9499&id=9502 BRANCH pino-gperf REVISION DETAIL https://phabricator.kde.org/D3830 AFFECTED

Re: Review Request 129724: [frameworks] Enable -Wsuggest-override for g++ >= 5.0.0

> On Dec. 30, 2016, 6:39 a.m., Martin Gräßlin wrote: > > Is that enabled by default now? I hope not! This is a completely useless > > warning for all frameworks (as we are not allowed to use override) and even > > more for a legacy code bases. I don't want to have to adjust the cmake in > > al

[Differential] [Updated, 125 lines] D3830: Add a new FindGperf module

pino updated this revision to Diff 9499. pino added a comment. Restricted Application added projects: Frameworks, Buildsystem. Use a full path for the output location. REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D3830?vs=9408&id=9499 BRANCH

Re: To C++11 or not?

On vendredi 30 décembre 2016 16:26:53 CET David Faure wrote: > On vendredi 30 décembre 2016 16:02:17 CET Kevin Funk wrote: > > I agree it would be perfect to have GCC 4.6 for KF5 in place (or some > > other > > mechanism to make sure 'override' is not used). > > One solution is > add_definitions(-

Re: To C++11 or not?

On vendredi 30 décembre 2016 16:02:17 CET Kevin Funk wrote: > I agree it would be perfect to have GCC 4.6 for KF5 in place (or some other > mechanism to make sure 'override' is not used). One solution is add_definitions(-Doverride=ERROR) ;-) (like qtbase does with a number of things, for its ow

Re: To C++11 or not?

Hi, >> Our min requirement is Qt 5.5 which according to >> http://doc.qt.io/qt-5/supported-platforms-and-configurations.html >> compiles with GCC 4.6 (Qt 5.6 has the same supported GCC it seems) > > Then that's a no-brainer, we can require gcc 4.6 too. > > Qt 5.9 (currently "git dev branch") use

Re: To C++11 or not?

On Friday, 30 December 2016 15:32:24 CET Martin Gräßlin wrote: > Am 2016-12-30 15:25, schrieb David Faure: > > On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > >> El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi > >> Toscano va > >> > >> escriure: > >> > Il 30 di

Re: All Frameworks modules are now available as repositories on Phabricator

On Tuesday, December 27, 2016 8:56:00 PM UTC Luigi Toscano wrote: > Elvis Angelaccio ha scritto: > > On Mon, Dec 26, 2016 at 1:19 AM, Luigi Toscano wrote: > >> ... so that it's easier to use Differential for reviews. Much appreciated, thanks! > > Thanks! > > What about tasks? Should we create a

Re: To C++11 or not?

Am 2016-12-30 15:25, schrieb David Faure: On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va escriure: > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk ha scritto: > >Following-up on this thread, since I

Re: To C++11 or not?

On Friday, 30 December 2016 15:25:56 CET David Faure wrote: > On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > > El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va > > > > escriure: > > > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk ha scritto: > > > >F

Re: To C++11 or not?

On vendredi 30 décembre 2016 12:56:09 CET Albert Astals Cid wrote: > El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va > > escriure: > > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk ha scritto: > > >Following-up on this thread, since I saw some more discussion about > > >

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

GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/360/ Project: PLATFORM=Linux,compiler=gcc Date of build: Fri, 30 Dec 2016 12:10:46 + Build duration: 1 min 1 sec CHANGE SET Revision 4793e54b757ecdefe79f2ef013

Jenkins-kde-ci: frameworkintegration master stable-kf5-qt5 » Linux,gcc - Build # 359 - Still Unstable!

GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/frameworkintegration%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/359/ Project: PLATFORM=Linux,compiler=gcc Date of build: Fri, 30 Dec 2016 12:10:46 + Build duration: 58 sec CHANGE SET Revision 4793e54b757ecdefe79f2ef

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

GENERAL INFO BUILD SUCCESS Build URL: https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/360/ Project: PLATFORM=Linux,compiler=gcc Date of build: Fri, 30 Dec 2016 12:10:46 + Build duration: 1 min 1 sec CHANGE SET Revision 4793e54b757ecdefe79f2ef013

Re: Review Request 129261: Hide the "Show Menu Bar" action if all the menubars are native

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129261/ --- (Updated Dec. 30, 2016, 11:57 a.m.) Status -- This change has been m

Re: To C++11 or not?

El divendres, 30 de desembre de 2016, a les 12:24:38 CET, Luigi Toscano va escriure: > Il 30 dicembre 2016 10:30:22 CET, Kevin Funk ha scritto: > >Following-up on this thread, since I saw some more discussion about > >C++11 > > > >usage in this RR: > > https://git.reviewboard.kde.org/r/129724/ >

Re: To C++11 or not?

Il 30 dicembre 2016 10:30:22 CET, Kevin Funk ha scritto: >Following-up on this thread, since I saw some more discussion about >C++11 >usage in this RR: > https://git.reviewboard.kde.org/r/129724/ > >Let's put this into some concrete actions, finally. I think we all >agree >nullptr & override

Re: Minimum required cmake version

On 2016-12-27, Aleix Pol wrote: > Now everything makes sense, thanks! > > I confirm Q_GADGET is mentioned in cmake 3.0.0 codebase while it isn't > in 2.8.11. > +1 on changing to 3.0. As a datapoint, Debian stable has cmake 3.0 /Sune

Re: Review Request 129648: New widget: tooltip that contains another widget

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129648/ --- (Updated Dec. 30, 2016, 10:27 a.m.) Review request for KDE Frameworks, Be

Re: Review Request 129648: New widget: tooltip that contains another widget

> On Dec. 29, 2016, 4:01 p.m., Martin Gräßlin wrote: > > src/ktooltipwidget.cpp, line 101 > > > > > > this won't work on Wayland, there is no global cursor pos. > > Elvis Angelaccio wrote: > hmm, not sure w

Re: To C++11 or not?

On Monday, 14 November 2016 10:45:07 CET Martin Gräßlin wrote: > Hi framework devs, > > recently we started to see the first patches for frameworks to silence > warnings for not used features of C++11. In particular to add override > to methods of inheriting classes. > > Now I find this weird fro

Jenkins-kde-ci: frameworkintegration master kf5-qt5 » Linux,gcc - Build # 359 - Still Unstable!

GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/frameworkintegration%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/359/ Project: PLATFORM=Linux,compiler=gcc Date of build: Fri, 30 Dec 2016 09:11:57 + Build duration: 5 min 45 sec CHANGE SET No changes JUNIT RESULTS

Jenkins-kde-ci: frameworkintegration master stable-kf5-qt5 » Linux,gcc - Build # 358 - Still Unstable!

GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/frameworkintegration%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/358/ Project: PLATFORM=Linux,compiler=gcc Date of build: Fri, 30 Dec 2016 09:08:31 + Build duration: 58 sec CHANGE SET No changes JUNIT RESULTS

Re: Review Request 129261: Hide the "Show Menu Bar" action if all the menubars are native

--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/129261/#review101667 --- Fix it, then Ship it! Looks good now. Indeed this is onl

Jenkins-kde-ci: kservice master stable-kf5-qt5 » Linux,gcc - Build # 167 - Unstable!

GENERAL INFO BUILD UNSTABLE Build URL: https://build.kde.org/job/kservice%20master%20stable-kf5-qt5/PLATFORM=Linux,compiler=gcc/167/ Project: PLATFORM=Linux,compiler=gcc Date of build: Fri, 30 Dec 2016 08:00:44 + Build duration: 5 min 16 sec CHANGE SET No changes JUNIT RESULTS Na

[Differential] [Commented On] D3850: Pass -fno-operator-names when supported

kfunk added a comment. In https://phabricator.kde.org/D3850#72308, @rakuco wrote: > Isn't it better to use `check_cxx_compiler_flag` to see if the flag is supported and enable it in case it is? -fno-operator-names is an ancient compiler flag, supported by GCC since at least 2000

Re: Review Request 129724: [frameworks] Enable -Wsuggest-override for g++ >= 5.0.0

> On Dez. 30, 2016, 7:39 vorm., Martin Gräßlin wrote: > > Is that enabled by default now? I hope not! This is a completely useless > > warning for all frameworks (as we are not allowed to use override) and even > > more for a legacy code bases. I don't want to have to adjust the cmake in > > a