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

[ltoscano (Luigi Toscano)]

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 (Luigi Toscano)]

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, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

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

[pino (Pino Toscano)]

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 dependency on gperf.
  
  This uses the newly added FindGperf.cmake in ECM, see [1].
  
  [1] https://phabricator.kde.org/D3830

TEST PLAN
  Builds fine as before, and the gperf output in the build directory
  matches the removed generated source.

REPOSITORY
  R270 KCodecs

BRANCH
  master

REVISION DETAIL
  https://phabricator.kde.org/D3883

AFFECTED FILES
  CMakeLists.txt
  src/CMakeLists.txt
  src/kcharsets.cpp
  src/kentities.h

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks

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

[David Jarvie]

---
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 marked as submitted.


Review request for KDE Frameworks and John Layt.


Changes
---

Submitted with commit 1550b2c83f4842eb491b906ff7029fc11fd07d8a by David Jarvie 
to branch master.


Repository: kwidgetsaddons


Description
---

Checks to determine whether an entered date is valid are wrong or missing in 
various places in the code. This is due to:
- not testing if a minimum or maximum date is set before comparing a date to 
the minimum/maximum;
- always rejecting new minimum/maximum dates if the other maximum/minimum date 
is not set;
- not testing dates for validity when set by the date picker or menu.

This results in the following bugs currently:
- When an up/down arrow or page up/down key is pressed to change the date, and 
the minimum and maximum dates are not set, it is always considered invalid and 
the date is not changed.
- When the DateKeywords option is set, and the minimum and maximum dates are 
not set, the only date which is displayed in the menu is "No Date".
- setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
currently set.
- setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
currently set.
- resetDateRange() does nothing.

This patch fixes the above bugs.

Documentation comments in the header file are also improved.


Diffs
-

  autotests/kdatecomboboxtest.cpp c15525a 
  src/kdatecombobox.h d9a20ca 
  src/kdatecombobox.cpp ad1d085 

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


Testing
---

Updated autotests pass. GUI changes tested with KAlarm, including setting 
DateKeywords. The bugs described above are now fixed.


Thanks,

David Jarvie

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

[René J . V . Bertin]

---
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.


Repository: kservice


Description
---

After upgrading to Qt 5.7.1 I noticed that kbuildsycoca5 (and the "inline" 
version used by many applications) took long minutes to trawl a location where 
it's unlikely to find anything of interest among the probably huge number of 
files present: `/Applications`.

This patch avoids that by removing all occurrences of /Applications from the 
result of 
`QStandardPaths::standardLocations(QStandardPaths::ApplicationsLocation)` (and 
also removes any duplicates, which seems like a good idea just in case).

I've marked this "WIP" because I'm not sure how this implementation would work 
out for standalone app bundle builds. I *think* they should be fine even if 
installed somewhere under /Applications because `QStringList::removeAll()` 
should remove only entries matching "/Applications" exactly. Possibly the 
filter could be widened to catch all "*/Applications", meaning also 
$HOME/Applications. That should still leave, say, `$HOME/Applications/Kate.app`.


Diffs
-

  src/sycoca/kmimeassociations.cpp 25ce3fe 
  src/sycoca/vfolder_menu.cpp 5acbf8a 

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


Testing
---

On OS X 10.9.5 and and Linux with Qt 5.7.1 and KF5 5.29.0 installed in 
/opt/local


Thanks,

René J.V. Bertin

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

[René J . V . Bertin]

---
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.


Repository: kservice


Description
---

I noticed that kbuildsyscoca.cpp may delete 
`QStandardPaths::writableLocation(QStandardPaths::ApplicationsLocation)`, 
according to the comments if that location is empty, but in practice no check 
is made whether that's the case.

And that makes the tool very dangerous on Mac, where the native 
ApplicationsLocation is something very different.


Diffs
-

  src/sycoca/kbuildsycoca.cpp 5e63907 

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


Testing
---

Works as intended (though I haven't tried to get it to fail, for some curious 
reason :))


Thanks,

René J.V. Bertin

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

[Christoph Feck]

---
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:10 p.m., David Jarvie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129709/
> ---
> 
> (Updated Dec. 30, 2016, 8:10 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> Checks to determine whether an entered date is valid are wrong or missing in 
> various places in the code. This is due to:
> - not testing if a minimum or maximum date is set before comparing a date to 
> the minimum/maximum;
> - always rejecting new minimum/maximum dates if the other maximum/minimum 
> date is not set;
> - not testing dates for validity when set by the date picker or menu.
> 
> This results in the following bugs currently:
> - When an up/down arrow or page up/down key is pressed to change the date, 
> and the minimum and maximum dates are not set, it is always considered 
> invalid and the date is not changed.
> - When the DateKeywords option is set, and the minimum and maximum dates are 
> not set, the only date which is displayed in the menu is "No Date".
> - setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
> currently set.
> - setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
> currently set.
> - resetDateRange() does nothing.
> 
> This patch fixes the above bugs.
> 
> Documentation comments in the header file are also improved.
> 
> 
> Diffs
> -
> 
>   autotests/kdatecomboboxtest.cpp c15525a 
>   src/kdatecombobox.h d9a20ca 
>   src/kdatecombobox.cpp ad1d085 
> 
> Diff: https://git.reviewboard.kde.org/r/129709/diff/
> 
> 
> Testing
> ---
> 
> Updated autotests pass. GUI changes tested with KAlarm, including setting 
> DateKeywords. The bugs described above are now fixed.
> 
> 
> Thanks,
> 
> David Jarvie
> 
>

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

[David Jarvie]

---
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 John Layt.


Changes
---

Renamed isValid() to isInDateRange()


Repository: kwidgetsaddons


Description
---

Checks to determine whether an entered date is valid are wrong or missing in 
various places in the code. This is due to:
- not testing if a minimum or maximum date is set before comparing a date to 
the minimum/maximum;
- always rejecting new minimum/maximum dates if the other maximum/minimum date 
is not set;
- not testing dates for validity when set by the date picker or menu.

This results in the following bugs currently:
- When an up/down arrow or page up/down key is pressed to change the date, and 
the minimum and maximum dates are not set, it is always considered invalid and 
the date is not changed.
- When the DateKeywords option is set, and the minimum and maximum dates are 
not set, the only date which is displayed in the menu is "No Date".
- setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
currently set.
- setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
currently set.
- resetDateRange() does nothing.

This patch fixes the above bugs.

Documentation comments in the header file are also improved.


Diffs (updated)
-

  autotests/kdatecomboboxtest.cpp c15525a 
  src/kdatecombobox.h d9a20ca 
  src/kdatecombobox.cpp ad1d085 

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


Testing
---

Updated autotests pass. GUI changes tested with KAlarm, including setting 
DateKeywords. The bugs described above are now fixed.


Thanks,

David Jarvie

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

[René J . V . Bertin]

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/Library/Fonts* /Library/Fonts 
/System/Library/Fonts
  ApplicationsLocation: "Applications" = 
*/Users/bertin/.local/share/applications* /opt/local/share/applications
  MusicLocation: "Music" = */Users/bertin/Music*
  MoviesLocation: "Movies" = */Users/bertin/Movies*
  PicturesLocation: "Pictures" = */Users/bertin/Pictures*
  TempLocation: "TemporaryItems" = 
*/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T*
  HomeLocation: "Home" = */Users/bertin*
  DataLocation: "Application Support" = 
*/Users/bertin/.local/share/QtProject/qtdiag* /Library/Application 
Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag 
/opt/local/libexec/qt5/bin/
  AppLocalDataLocation: "Application Support" = 
*/Users/bertin/.local/share/QtProject/qtdiag* /Library/Application 
Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag 
/opt/local/libexec/qt5/bin/
  CacheLocation: "Caches" = */Users/bertin/.cache/QtProject/qtdiag* 
/Users/bertin/.cache /Library/Caches/QtProject/qtdiag
  GenericDataLocation: "Application Support" = */Users/bertin/.local/share* 
/opt/local/share /Library/Application Support
  RuntimeLocation: "Application Support" = 
*/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/runtime-bertin*
  ConfigLocation: "Preferences" = */Users/bertin/.config* /opt/local/etc/xdg
  DownloadLocation: "Downloads" = */Users/bertin/Downloads*
  GenericCacheLocation: "Caches" = */Users/bertin/.cache* /Users/bertin/.cache 
/Library/Caches
  GenericConfigLocation: "Preferences" = */Users/bertin/.config* 
/opt/local/etc/xdg
  AppDataLocation: "Application Support" = 
*/Users/bertin/.local/share/QtProject/qtdiag* /Library/Application 
Support/QtProject/qtdiag /opt/local/share/QtProject/qtdiag 
/opt/local/libexec/qt5/bin/
  AppConfigLocation: "Preferences" = 
*/Users/bertin/Library/Preferences/QtProject/qtdiag*
  DesktopLocation: "Desktop" = */Users/bertin/Desktop*
  DocumentsLocation: "Documents" = */Users/bertin/Documents*
  FontsLocation: "Fonts" = */Users/bertin/Library/Fonts* /Library/Fonts 
/System/Library/Fonts
  ApplicationsLocation: "Applications" = 
*/Users/bertin/.local/share/applications* /Users/bertin/Applications 
/opt/local/share/applications /Applications
  MusicLocation: "Music" = */Users/bertin/Music*
  MoviesLocation: "Movies" = */Users/bertin/Movies*
  PicturesLocation: "Pictures" = */Users/bertin/Pictures*
  TempLocation: "Temporary Items" = 
*/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T*
  HomeLocation: "Home" = */Users/bertin*
  DataLocation: "Application Support" = 
*/Users/bertin/.local/share/QtProject/qtdiag* /Users/bertin/Library/Application 
Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag 
/opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
  AppLocalDataLocation: "Application Support" = 
*/Users/bertin/.local/share/QtProject/qtdiag* /Users/bertin/Library/Application 
Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag 
/opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
  CacheLocation: "Caches" = */Users/bertin/.cache/QtProject/qtdiag* 
/Users/bertin/Library/Caches/QtProject/qtdiag /Users/bertin/.cache 
/Library/Caches/QtProject/qtdiag
  GenericDataLocation: "share" = */Users/bertin/.local/share* 
/Users/bertin/Library/Application Support /opt/local/share /Library/Application 
Support
  RuntimeLocation: "runtime-bertin" = 
*/var/folders/j1/1439ppj08xj8h6006s6drbq0gs/T/runtime-bertin* 
/Users/bertin/Library/Application Support
  ConfigLocation: ".config" = */Users/bertin/.config* 
/Users/bertin/Library/Preferences /opt/local/etc/xdg
  DownloadLocation: "Downloads" = */Users/bertin/Downloads*
  GenericCacheLocation: ".cache" = */Users/bertin/.cache* 
/Users/bertin/Library/Caches /Users/bertin/.cache /Library/Caches 
/System/Library/Caches
  GenericConfigLocation: ".config" = */Users/bertin/.config* 
/Users/bertin/Library/Preferences /opt/local/etc/xdg
  AppDataLocation: "Application Support" = 
*/Users/bertin/.local/share/QtProject/qtdiag* /Users/bertin/Library/Application 
Support/QtProject/qtdiag /Library/Application Support/QtProject/qtdiag 
/opt/local/share/QtProject/qtdiag /opt/local/libexec/qt5/bin/
  AppConfigLocation: "Preferences" = 
*/Users/bertin/Library/Preferences/QtProject/qtdiag*

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

[René J . V . Bertin]

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 imagination.

> Anyhow, please post backtraces. Anything else is just guessing.

OK, attaching lldb after letting kbuildsycoca5 --noincremental run for about 
15min. while I made a fresh cuppa:

* thread #1: tid = 0x21d12b0, 0x7fff8ca0c0aa 
libsystem_kernel.dylib`__getattrlist + 10, queue = 'com.apple.main-thread', 
stop reason = signal SIGSTOP
  * frame #0: 0x7fff8ca0c0aa libsystem_kernel.dylib`__getattrlist + 10
frame #1: 0x7fff8f949da7 
CoreServicesInternal`corePropertyProviderPrepareValues(__CFURL const*, 
__FileCache*, __CFString const* const*, void const**, long, void const*, 
__CFError**) + 484
frame #2: 0x7fff8f93ffbb 
CoreServicesInternal`prepareValuesForBitmap(__CFURL const*, __FileCache*, 
_FilePropertyBitmap*, __CFError**) + 227
frame #3: 0x7fff8f93dca7 
CoreServicesInternal`_FSURLCopyResourcePropertyForKeyInternal(__CFURL const*, 
__CFString const*, void*, void*, __CFError**, unsigned char) + 213
frame #4: 0x7fff8f93dbcd 
CoreServicesInternal`_FSURLCopyResourcePropertyForKey + 15
frame #5: 0x7fff866a02bb CoreFoundation`CFURLCopyResourcePropertyForKey 
+ 123
frame #6: 0x000106e5bf5c 
QtCore`hasResourcePropertyFlag(data=, entry=, 
key=) + 172 at qfilesystemengine_unix.cpp:86
frame #7: 0x000106e5a549 
QtCore`QFileSystemEngine::fillMetaData(entry=0x7f80a96ae078, 
data=0x7f80a96ae090, what=) + 649 at 
qfilesystemengine_unix.cpp:529
frame #8: 0x000106dff291 QtCore`QFileInfo::isHidden(this=) 
const + 81 at qfileinfo.cpp:970
frame #9: 0x000106df7343 
QtCore`QDirIteratorPrivate::matchesFilters(this=0x7f80a96ade70, 
fileName=, fi=0x7fff591e4ae0) const + 387 at 
qdiriterator.cpp:358
frame #10: 0x000106df6c45 
QtCore`QDirIteratorPrivate::advance(this=0x7f80a96ade70) + 1045 at 
qdiriterator.cpp:255
frame #11: 0x000106df61c6 
QtCore`QDirIteratorPrivate::QDirIteratorPrivate(this=, 
entry=, nameFilters=, resolveEngine=, 
filters=, flags=) + 1206 at qdiriterator.cpp:175
frame #12: 0x000106df7aa6 
QtCore`QDirIterator::QDirIterator(this=0x7fff591e4d28, path=, 
nameFilters=, filters=, flags=) + 86 at 
qdiriterator.cpp:465
frame #13: 0x000106ded253 
QtCore`QDir::entryInfoList(this=, nameFilters=, 
filters=, sort=) const + 275 at qdir.cpp:1371
frame #14: 0x000106ded12c 
QtCore`QDir::entryInfoList(this=, filters=, 
sort=) const + 28 at qdir.cpp:1294
frame #15: 0x000106a6f77a libKF5Service.5.dylib`bool 
KSycocaUtilsPrivate::visitResourceDirectoryHelper(QString const&, KBuildSycoca::build()::$_4) + 58 
at ksycocautils_p.h:39
frame #16: 0x000106a6f89c libKF5Service.5.dylib`bool 
KSycocaUtilsPrivate::visitResourceDirectoryHelper(QString const&, KBuildSycoca::build()::$_4) + 348 
at ksycocautils_p.h:47
frame #17: 0x000106a6f89c libKF5Service.5.dylib`bool 
KSycocaUtilsPrivate::visitResourceDirectoryHelper(QString const&, KBuildSycoca::build()::$_4) + 348 
at ksycocautils_p.h:47


https://paste.kde.org/ptnxccplk/upymg1/raw

Frame #7 gives me the file being handled: 
/Applications/Multimedia/Video/iDVD.app/Contents/Frameworks/DVDBase.framework/Versions/A/Frameworks/DVDBase.framework/Versions/A/Frameworks/DVDBase.framework/Versions/A/Frameworks/DVDBase.framework/Versions/A/Frameworks/DVDBase.framework/Versions/A/Framew...

Indeed, 
"/Applications/Multimedia/Video/iDVD.app/Contents/Frameworks/DVDBase.framework/Versions/A/Frameworks"
 was a symlink to "../../../". Not a circular link, but something like it (is 
there a name for this kind of situation?).

After removing that link the process terminated, eventually.

A subsequent regular run took "only" 2:13 minutes at 40% CPU. A few well-placed 
qDebug() statements confirm that most of that time is spent trawling through 
/Applications (including all of Xcode's 5+Gb).

I think we'll have to consider skipping known Mac locations that are highly 
unlikely to contain anything sycoca relevant. Or maybe any generic locations 
that aren't user-specific and are not under the install prefix. At least as a 
MacPorts-specific patch.
Do you have suggestions where and how to filter out at least /Applications?

R.

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

[David Faure]

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.
>
> Edit: it doesn't.

What's it and what is it that it doesn't?
Too many possible subjects in the previous sentence.
Can you reproduce the problem on Linux or not?
 
Anyhow, please post backtraces. Anything else is just guessing.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

[pino (Pino Toscano)]

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

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

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

[René J . V . Bertin]

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 Qt version.

R.

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

[René J.V. Bertin]

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, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

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

[René J . V . Bertin]

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 addition, my KDevelop 4.7 install that works fine when I have Qt 5.6.2 
active now crashes randomly because of an illegal operation *in a Mac SDK 
library*. That doesn't seem to make sense, yet it's reproducible.

On Mac we might be able to do without kded5, but I don't think we can do 
without kbuildsycoca5 .
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.

Does anyone have any suggestion where I might start looking? I already tried to 
run under lldb, interrupt once the deadloop was clearly installed and try to 
step out of functions to get an idea of that loop. Didn't really work; at some 
point lldb just stops co-operating ("error: Couldn't find thread plan to 
implement step type.").

There is a difference between 5.6.2 and 5.7.1 in the native QStandardPaths 
locations that are returned. I don't use those for writing, but if for instance 
kbuildsysoca5 parses everything under the GenericCacheLocation it will now have 
to wade through over 3.5Gb of crud, and that would of course take "a bit" more 
time.

Thanks...

R.

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

[Christoph Feck]

> 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.isValid() || isValid(date)
> > 
> > looks confusing without some explanation.

Maybe a different name would help, something mention 'range'. isInDateRange()?


- Christoph


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


On Dec. 28, 2016, 6:49 p.m., David Jarvie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129709/
> ---
> 
> (Updated Dec. 28, 2016, 6:49 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> Checks to determine whether an entered date is valid are wrong or missing in 
> various places in the code. This is due to:
> - not testing if a minimum or maximum date is set before comparing a date to 
> the minimum/maximum;
> - always rejecting new minimum/maximum dates if the other maximum/minimum 
> date is not set;
> - not testing dates for validity when set by the date picker or menu.
> 
> This results in the following bugs currently:
> - When an up/down arrow or page up/down key is pressed to change the date, 
> and the minimum and maximum dates are not set, it is always considered 
> invalid and the date is not changed.
> - When the DateKeywords option is set, and the minimum and maximum dates are 
> not set, the only date which is displayed in the menu is "No Date".
> - setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
> currently set.
> - setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
> currently set.
> - resetDateRange() does nothing.
> 
> This patch fixes the above bugs.
> 
> Documentation comments in the header file are also improved.
> 
> 
> Diffs
> -
> 
>   autotests/kdatecomboboxtest.cpp c15525a 
>   src/kdatecombobox.h d9a20ca 
>   src/kdatecombobox.cpp ad1d085 
> 
> Diff: https://git.reviewboard.kde.org/r/129709/diff/
> 
> 
> Testing
> ---
> 
> Updated autotests pass. GUI changes tested with KAlarm, including setting 
> DateKeywords. The bugs described above are now fixed.
> 
> 
> Thanks,
> 
> David Jarvie
> 
>

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

[Christoph Feck]

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




src/kdatecombobox.cpp (line 58)


Could you please add a short comment what this function does? A condition 
like

!date.isValid() || isValid(date)

looks confusing without some explanation.


- Christoph Feck


On Dec. 28, 2016, 6:49 p.m., David Jarvie wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129709/
> ---
> 
> (Updated Dec. 28, 2016, 6:49 p.m.)
> 
> 
> Review request for KDE Frameworks and John Layt.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> Checks to determine whether an entered date is valid are wrong or missing in 
> various places in the code. This is due to:
> - not testing if a minimum or maximum date is set before comparing a date to 
> the minimum/maximum;
> - always rejecting new minimum/maximum dates if the other maximum/minimum 
> date is not set;
> - not testing dates for validity when set by the date picker or menu.
> 
> This results in the following bugs currently:
> - When an up/down arrow or page up/down key is pressed to change the date, 
> and the minimum and maximum dates are not set, it is always considered 
> invalid and the date is not changed.
> - When the DateKeywords option is set, and the minimum and maximum dates are 
> not set, the only date which is displayed in the menu is "No Date".
> - setMinimumDate() and resetMinimumDate() do nothing if no maximum date is 
> currently set.
> - setMaximumDate() and resetMaximumDate() do nothing if no minimum date is 
> currently set.
> - resetDateRange() does nothing.
> 
> This patch fixes the above bugs.
> 
> Documentation comments in the header file are also improved.
> 
> 
> Diffs
> -
> 
>   autotests/kdatecomboboxtest.cpp c15525a 
>   src/kdatecombobox.h d9a20ca 
>   src/kdatecombobox.cpp ad1d085 
> 
> Diff: https://git.reviewboard.kde.org/r/129709/diff/
> 
> 
> Testing
> ---
> 
> Updated autotests pass. GUI changes tested with KAlarm, including setting 
> DateKeywords. The bugs described above are now fixed.
> 
> 
> Thanks,
> 
> David Jarvie
> 
>

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

[pino (Pino Toscano)]

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=9502

BRANCH
  pino-gperf

REVISION DETAIL
  https://phabricator.kde.org/D3830

AFFECTED FILES
  find-modules/FindGperf.cmake

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

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

[Michael Pyne]

> 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 
> > all projects I maintain to silence this warning again. And even less I want 
> > to spent days adding overrides to legacy code base.
> 
> Laurent Montel wrote:
> We can use Q_DECL_OVERRIDE which is replaced by override when your gcc 
> support it. So There is not a problem to use this flags no ?
> 
> Martin Gräßlin wrote:
> I commented on that aspect in the past. We cannot have both: enforce 
> C++11 and at the same time keep compatibility to no C++11.
> 
> 
> 
> We need to find a real line and not bullshit around with macros.
> 
> 
> 
> Either we say C++11 then enable all of it, or say no. But then no 
> earnings please.
> 
> 
> 
> I'm seriously annoyed by the stupid dance we are doing.

The Clang warning flag is not documented very well but everything I've been 
able to find seems to indicate it became a default warning when it was added in 
LLVM 3.6.  However some simple testcases I've run against a more recent LLVM 
(3.9) fail to trip the warning even after enabling optimization, ensuring C++11 
is enabled, using various combinations of override combinations, etc.  So it 
seems that at least in recent LLVM this may not be a source of much noise even 
though it's enabled by default.  But there are a lot of complaints online about 
this warning for LLVM 3.6 so it's going to be with us one way or another 
anyways.

I'm sympathetic to the point about either supporting C++11 or not instead of 
having to guess which of its subfeatures we can use, especially since our 
"supported compilers page" 
(https://community.kde.org/Frameworks/Policies#Frameworks_compiler_requirements_and_C.2B.2B11)
 that tells us what we can use appears to be resistant to being located from a 
search engine.  But that's the kind of thing that would need discussion on the 
mailing list and it seems to me like we've repainted that shed several times 
over already.


- Michael


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


On Dec. 29, 2016, 11:48 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129724/
> ---
> 
> (Updated Dec. 29, 2016, 11:48 p.m.)
> 
> 
> Review request for Build System and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Gives a nice warning about something that should be marked as override but 
> isn't
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 
> 
> Diff: https://git.reviewboard.kde.org/r/129724/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

[pino (Pino Toscano)]

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=9499

BRANCH
  pino-gperf

REVISION DETAIL
  https://phabricator.kde.org/D3830

AFFECTED FILES
  find-modules/FindGperf.cmake

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: pino, #frameworks, #buildsystem, #windows, kde-mac
Cc: kfunk, rjvbb, adridg

Re: To C++11 or not?

[David Faure]

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(-Doverride=ERROR)
>  ;-)
> 
> (like qtbase does with a number of things, for its own compilation)

Sorry that was nonsense, would break Q_DECL_OVERRIDE.

qtbase is doing
 -Dsignals=int \
 -Dslots=int \
 -Demit=public: \
 -Dforeach=public: \
 -Dforever=public:
but that's just its own macros.

Commit hook? :-)

Or I can just run a grep at release time.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: To C++11 or not?

[David Faure]

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 own compilation)

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

Re: To C++11 or not?

[Christoph Cullmann]

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") uses override rather than Q_DECL_OVERRIDE,
> but we're far from requiring 5.9.
> 
> This leads to a different proposal:
> - Raise min GCC version to 4.6
> - Allow to use nullptr unconditionally
> - Use Q_DECL_OVERRIDE.
> 
> I fully agree that "having 'override' is actually super useful for preventing
> programmer faults", but that also works if it's spelled out Q_DECL_OVERRIDE
> and only ineffective for people *using* frameworks on an older system with gcc
> 4.6. It's still effective for all of us who are working on frameworks, which
> is where the benefit of "override" is.
> 
> BTW just to get a taste of the real world, I'm working with a customer right
> now who is using Qt 5 and gcc 4.4 in order for their binaries to work on the
> largest possible number of Linux distros out there (glibc version). They are
> not using KDE Frameworks, obviously, but this is just to point out that there
> are companies using older gcc versions still, this is not just hypothetical.
> 
> Funny that I kept saying "MSVC is what's holding us back" when in fact it's
> GCC that is holding us back ;)
:=) Actually I wonder why somebody should do that given you get even from Red 
Hat (or CentOs)
GCC 4.8 or now even 4.9 for the 6.x series that will allow you to deploy on any 
system
that is really out there and able to run Qt 5 (For CentOS 5 you get similar new 
GCCs,
but that has other issues)

(and we do that for our customers since ever)

Greetings
Christoph

-- 
- Dr.-Ing. Christoph Cullmann -
AbsInt Angewandte Informatik GmbH  Email: cullm...@absint.com
Science Park 1 Tel:   +49-681-38360-22
66123 Saarbrücken  Fax:   +49-681-38360-20
GERMANYWWW:   http://www.AbsInt.com

Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234

Re: To C++11 or not?

[Kevin Funk]

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 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 are probably the most apparent issues (since
> >> > >compilers
> >> > >started to warn about both), and *having* 'override' is actually super
> >> > >useful
> >> > >for preventing programmer faults.
> >> > >
> >> > >Let's just speak about allowing nullptr & override, allowing the full
> >> > >set of C
> >> > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only
> >> > >available only
> >> > >in MSVC2015, so we'd just be able to support the latest VS. See [2].
> >> > >
> >> > >Looking at [1] I still see we list GCC 4.5 as minimum requirement.
> >> > >That's
> >> > >pretty ancient. 4.5.1 got released Jul 2010 [3]
> >> > >
> >> > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can
> >> > >use
> >> > >
> >> > >'nullptr' unconditionally. ktexteditor already did that in public
> >> > >headers for
> >> > >quite some time -- no-one complained.
> >> > >
> >> > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can
> >> > >use
> >> > >
> >> > >'override' unconditionally *.
> >> > >
> >> > >We already use MSVC2012 as min VS dep, this version has full nullptr &
> >> > >override support. I don't see anyone using MSVC2010 for compiling KF5
> >> > >to be
> >> > >honest...
> >> > >
> >> > >Proposal for [1]:
> >> > >- Raise min GCC version to 4.7
> >> > >- Allow to use override unconditionally
> >> > >- Allow to use nullptr unconditonally
> >> > >
> >> > >ACK?
> >> > >
> >> > >
> >> > >PS: I can do the work, I can script the refactoring with clang-tidy.
> >> > >
> >> > >Let's move forward please.
> >> > 
> >> > Hi, this is a really good analysis (also for future reference). In
> >> > order
> >> > to
> >> > complete it, given that the original idea was "follow Qt's
> >> > requirement",
> >> > and that we increased in time the required version of Qt, what is the
> >> > current status regarding compilers and Qt?
> >> 
> >> 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") uses override rather than
> > Q_DECL_OVERRIDE,
> > but we're far from requiring 5.9.
> > 
> > This leads to a different proposal:
> > - Raise min GCC version to 4.6
> > - Allow to use nullptr unconditionally
> > - Use Q_DECL_OVERRIDE.
> > 
> > I fully agree that "having 'override' is actually super useful for
> > preventing
> > programmer faults", but that also works if it's spelled out
> > Q_DECL_OVERRIDE
> > and only ineffective for people *using* frameworks on an older system
> > with gcc
> > 4.6. It's still effective for all of us who are working on frameworks,
> > which
> > is where the benefit of "override" is.
> 
> What's the plan to enforce that? How is build.kde.org checking that we
> don't use override instead of Q_DECL_OVERRIDE?

One instance that enforces this: code reviews.
 
> This is the point I disagree with. We define nice rules and have no
> means at all to ensure that they are enforced. That's something I have
> brought to the attention of this mailing list several times over the
> last years. Unfortunately nothing has changed.

Well, there's only so much effort you can spend on Continuous Integration 
systems. You can't possibly test all system configurations out there.

> In my opinion we are lying to ourself and to everybody who wants to use
> frameworks if we say "can be compiled with gcc 4.6" when we aren't even
> testing that.

KF5 also claims that it can be compiled with MSVC2012+ and Clang 3.1+ and we 
have no means to prove it via the CI system either. It's not in place.

We still make sure it may possibly work on them by defining a set of rules (in 
the wiki), which are hopefully enforced when someone reviews code. Irregular 
testing happens when e.g. /me compiles KF5 using Clang or VS2015.

There's only so much you can do.

> So please let's get the ordering right: ensure that it compiles with gcc
> 4.6, then say we support that. The only other option is to say we
> require whatever gcc version build.kde.org is using.

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). But not having it doesn't mean 
we can't claim 

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

[Sebastian Kügler]

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 Workboard for the Frameworks
> > project? Or is it planned that each framework be a Project with its
> > own workboard?
> 
> This is entirely up to each maintainer. I personally think that 80% of the
> modules in Frameworks don't need a separate project for each of them, but
> again, if someone needs a separate project (and workboard), sure, it can be
> created.

Note that tasks can be on more than one workboard at the same time (they even 
carry status per workboard). So we can have a frameworks board with all tasks 
and project-specific board with just the relevant tasks, for example.
-- 
sebas

Sebastian Kügler•http://vizZzion.org•http://www.kde.org

Re: To C++11 or not?

[Martin Gräßlin]

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 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 are probably the most apparent issues (since
> >compilers
> >started to warn about both), and *having* 'override' is actually super
> >useful
> >for preventing programmer faults.
> >
> >Let's just speak about allowing nullptr & override, allowing the full
> >set of C
> >++11 is *not* feasible. Reason: Lot's of C++11 feature are only
> >available only
> >in MSVC2015, so we'd just be able to support the latest VS. See [2].
> >
> >Looking at [1] I still see we list GCC 4.5 as minimum requirement.
> >That's
> >pretty ancient. 4.5.1 got released Jul 2010 [3]
> >
> >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use
> >
> >'nullptr' unconditionally. ktexteditor already did that in public
> >headers for
> >quite some time -- no-one complained.
> >
> >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use
> >
> >'override' unconditionally *.
> >
> >We already use MSVC2012 as min VS dep, this version has full nullptr &
> >override support. I don't see anyone using MSVC2010 for compiling KF5
> >to be
> >honest...
> >
> >Proposal for [1]:
> >- Raise min GCC version to 4.7
> >- Allow to use override unconditionally
> >- Allow to use nullptr unconditonally
> >
> >ACK?
> >
> >
> >PS: I can do the work, I can script the refactoring with clang-tidy.
> >
> >Let's move forward please.
>
> Hi, this is a really good analysis (also for future reference). In order
> to
> complete it, given that the original idea was "follow Qt's requirement",
> and that we increased in time the required version of Qt, what is the
> current status regarding compilers and Qt?

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") uses override rather than 
Q_DECL_OVERRIDE,

but we're far from requiring 5.9.

This leads to a different proposal:
- Raise min GCC version to 4.6
- Allow to use nullptr unconditionally
- Use Q_DECL_OVERRIDE.

I fully agree that "having 'override' is actually super useful for 
preventing
programmer faults", but that also works if it's spelled out 
Q_DECL_OVERRIDE
and only ineffective for people *using* frameworks on an older system 
with gcc
4.6. It's still effective for all of us who are working on frameworks, 
which

is where the benefit of "override" is.


What's the plan to enforce that? How is build.kde.org checking that we 
don't use override instead of Q_DECL_OVERRIDE?


This is the point I disagree with. We define nice rules and have no 
means at all to ensure that they are enforced. That's something I have 
brought to the attention of this mailing list several times over the 
last years. Unfortunately nothing has changed.


In my opinion we are lying to ourself and to everybody who wants to use 
frameworks if we say "can be compiled with gcc 4.6" when we aren't even 
testing that.


So please let's get the ordering right: ensure that it compiles with gcc 
4.6, then say we support that. The only other option is to say we 
require whatever gcc version build.kde.org is using.


Cheers
Martin

Re: To C++11 or not?

[Kevin Funk]

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:
> > > >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 are probably the most apparent issues (since
> > > >compilers
> > > >started to warn about both), and *having* 'override' is actually super
> > > >useful
> > > >for preventing programmer faults.
> > > >
> > > >Let's just speak about allowing nullptr & override, allowing the full
> > > >set of C
> > > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only
> > > >available only
> > > >in MSVC2015, so we'd just be able to support the latest VS. See [2].
> > > >
> > > >Looking at [1] I still see we list GCC 4.5 as minimum requirement.
> > > >That's
> > > >pretty ancient. 4.5.1 got released Jul 2010 [3]
> > > >
> > > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use
> > > >
> > > >'nullptr' unconditionally. ktexteditor already did that in public
> > > >headers for
> > > >quite some time -- no-one complained.
> > > >
> > > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use
> > > >
> > > >'override' unconditionally *.
> > > >
> > > >We already use MSVC2012 as min VS dep, this version has full nullptr &
> > > >override support. I don't see anyone using MSVC2010 for compiling KF5
> > > >to be
> > > >honest...
> > > >
> > > >Proposal for [1]:
> > > >- Raise min GCC version to 4.7
> > > >- Allow to use override unconditionally
> > > >- Allow to use nullptr unconditonally
> > > >
> > > >ACK?
> > > >
> > > >
> > > >PS: I can do the work, I can script the refactoring with clang-tidy.
> > > >
> > > >Let's move forward please.
> > > 
> > > Hi, this is a really good analysis (also for future reference). In order
> > > to
> > > complete it, given that the original idea was "follow Qt's requirement",
> > > and that we increased in time the required version of Qt, what is the
> > > current status regarding compilers and Qt?
> > 
> > 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") uses override rather than
> Q_DECL_OVERRIDE, but we're far from requiring 5.9.
> 
> This leads to a different proposal:
> - Raise min GCC version to 4.6
> - Allow to use nullptr unconditionally
> - Use Q_DECL_OVERRIDE.

+1 from my side. I didn't know that we wanted to follow the Qt version's 
minimum compiler requirements. Makes sense.

Thanks for chiming in!

I'll port KF5 (at least the (public) headers) to nullptr if this proposal is 
accepted.

Cheers,
Kevin

> I fully agree that "having 'override' is actually super useful for
> preventing programmer faults", but that also works if it's spelled out
> Q_DECL_OVERRIDE and only ineffective for people *using* frameworks on an
> older system with gcc 4.6. It's still effective for all of us who are
> working on frameworks, which is where the benefit of "override" is.
> 
> BTW just to get a taste of the real world, I'm working with a customer right
> now who is using Qt 5 and gcc 4.4 in order for their binaries to work on
> the largest possible number of Linux distros out there (glibc version).
> They are not using KDE Frameworks, obviously, but this is just to point out
> that there are companies using older gcc versions still, this is not just
> hypothetical.
> 
> Funny that I kept saying "MSVC is what's holding us back" when in fact it's
> GCC that is holding us back ;)
> 
> 
> PS: I disagree with the "nobody complained" approach. Many people will
> simply choose another library than complain about one library not being
> suited to their constraints (one of which being the supported compiler).


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.

Re: To C++11 or not?

[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 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 are probably the most apparent issues (since
> > >compilers
> > >started to warn about both), and *having* 'override' is actually super
> > >useful
> > >for preventing programmer faults.
> > >
> > >Let's just speak about allowing nullptr & override, allowing the full
> > >set of C
> > >++11 is *not* feasible. Reason: Lot's of C++11 feature are only
> > >available only
> > >in MSVC2015, so we'd just be able to support the latest VS. See [2].
> > >
> > >Looking at [1] I still see we list GCC 4.5 as minimum requirement.
> > >That's
> > >pretty ancient. 4.5.1 got released Jul 2010 [3]
> > >
> > >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use
> > >
> > >'nullptr' unconditionally. ktexteditor already did that in public
> > >headers for
> > >quite some time -- no-one complained.
> > >
> > >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use
> > >
> > >'override' unconditionally *.
> > >
> > >We already use MSVC2012 as min VS dep, this version has full nullptr &
> > >override support. I don't see anyone using MSVC2010 for compiling KF5
> > >to be
> > >honest...
> > >
> > >Proposal for [1]:
> > >- Raise min GCC version to 4.7
> > >- Allow to use override unconditionally
> > >- Allow to use nullptr unconditonally
> > >
> > >ACK?
> > >
> > >
> > >PS: I can do the work, I can script the refactoring with clang-tidy.
> > >
> > >Let's move forward please.
> > 
> > Hi, this is a really good analysis (also for future reference). In order
> > to
> > complete it, given that the original idea was "follow Qt's requirement",
> > and that we increased in time the required version of Qt, what is the
> > current status regarding compilers and Qt?
> 
> 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") uses override rather than Q_DECL_OVERRIDE, 
but we're far from requiring 5.9.

This leads to a different proposal:
- Raise min GCC version to 4.6
- Allow to use nullptr unconditionally
- Use Q_DECL_OVERRIDE. 

I fully agree that "having 'override' is actually super useful for preventing 
programmer faults", but that also works if it's spelled out Q_DECL_OVERRIDE
and only ineffective for people *using* frameworks on an older system with gcc 
4.6. It's still effective for all of us who are working on frameworks, which 
is where the benefit of "override" is.

BTW just to get a taste of the real world, I'm working with a customer right 
now who is using Qt 5 and gcc 4.4 in order for their binaries to work on the 
largest possible number of Linux distros out there (glibc version). They are 
not using KDE Frameworks, obviously, but this is just to point out that there 
are companies using older gcc versions still, this is not just hypothetical.

Funny that I kept saying "MSVC is what's holding us back" when in fact it's 
GCC that is holding us back ;)


PS: I disagree with the "nobody complained" approach. Many people will simply 
choose another library than complain about one library not being suited to 
their constraints (one of which being the supported compiler).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5

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

[no-reply]

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 4793e54b757ecdefe79f2ef013a58bebfdf2f760 by aleixpol: (The test 
assumes colorschemes.knsrc is available, but it#039;s not on the CI)
  change: edit src/kpackage-install-handlers/kns/CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 72/205 
(35%)CONDITIONAL 34/172 (20%)

By packages
  
autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 25/27 (93%)CONDITIONAL 
5/10 (50%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/178 (26%)CONDITIONAL 
29/162 (18%)

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

[no-reply]

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 4793e54b757ecdefe79f2ef013a58bebfdf2f760 by aleixpol: (The test 
assumes colorschemes.knsrc is available, but it#039;s not on the CI)
  change: edit src/kpackage-install-handlers/kns/CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 1 test(s), Passed: 1 test(s), Skipped: 0 test(s), Total: 2 
test(s)Failed: TestSuite.frameworkintegration-kstyle_unittest

COBERTURA RESULTS

Cobertura Coverage Report
  

By packages
  

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

[no-reply]

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 4793e54b757ecdefe79f2ef013a58bebfdf2f760 by aleixpol: (The test 
assumes colorschemes.knsrc is available, but it#039;s not on the CI)
  change: edit src/kpackage-install-handlers/kns/CMakeLists.txt


JUNIT RESULTS

Name: (root) Failed: 0 test(s), Passed: 2 test(s), Skipped: 0 test(s), Total: 2 
test(s)

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 2/2 (100%)FILES 2/2 (100%)CLASSES 2/2 (100%)LINE 72/205 
(35%)CONDITIONAL 34/172 (20%)

By packages
  
autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 25/27 (93%)CONDITIONAL 
5/10 (50%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/178 (26%)CONDITIONAL 
29/162 (18%)

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

[Albert Astals Cid]

---
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 marked as submitted.


Review request for KDE Frameworks.


Changes
---

Submitted with commit 2ae1ef1066c61f9552eea06248a4fda3dde071d5 by Albert Astals 
Cid to branch master.


Repository: kconfigwidgets


Description
---

Some applications have a "Show Menu Bar" action that is a bit silly on systems 
where the menubar is part of the shell (for example Unity 7).

This patch attempts to fix it by iterating all the main windows when they are 
shown and if all the menubars of all mainwindows are native, then hides the 
show menu bar action (basically erasing it from existence).

It's not the nicest of the codes and probably has some edge cases but works on 
the general case so i think it's worth the effort.


Diffs
-

  src/kstandardaction.cpp 89d011e 

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


Testing
---

Tried konsole, kate and dolphin under Unity 7 on Ubuntu 16.10

konsole and kate work fine (i.e. the action is gone from the menus and all is 
good)

dolphin is not 100% "perfectly behabed" (i.e. the "control" toolbar item is 
supposed to not be shown when menubars are shown and in this case it's shown) 
but it's not a regression and imho it's the dolphin code being a bit weird (i 
can propose a patch for it if this gets accepted)


Thanks,

Albert Astals Cid

Re: To C++11 or not?

[Albert Astals Cid]

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/
> >
> >Let's put this into some concrete actions, finally. I think we all
> >agree
> >nullptr & override are probably the most apparent issues (since
> >compilers
> >started to warn about both), and *having* 'override' is actually super
> >useful
> >for preventing programmer faults.
> >
> >Let's just speak about allowing nullptr & override, allowing the full
> >set of C
> >++11 is *not* feasible. Reason: Lot's of C++11 feature are only
> >available only
> >in MSVC2015, so we'd just be able to support the latest VS. See [2].
> >
> >Looking at [1] I still see we list GCC 4.5 as minimum requirement.
> >That's
> >pretty ancient. 4.5.1 got released Jul 2010 [3]
> >
> >If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use
> >
> >'nullptr' unconditionally. ktexteditor already did that in public
> >headers for
> >quite some time -- no-one complained.
> >
> >If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use
> >
> >'override' unconditionally *.
> >
> >We already use MSVC2012 as min VS dep, this version has full nullptr &
> >override support. I don't see anyone using MSVC2010 for compiling KF5
> >to be
> >honest...
> >
> >Proposal for [1]:
> >- Raise min GCC version to 4.7
> >- Allow to use override unconditionally
> >- Allow to use nullptr unconditonally
> >
> >ACK?
> >
> >
> >PS: I can do the work, I can script the refactoring with clang-tidy.
> >
> >Let's move forward please.
> 
> Hi, this is a really good analysis (also for future reference). In order to
> complete it, given that the original idea was "follow Qt's requirement",
> and that we increased in time the required version of Qt, what is the
> current status regarding compilers and Qt?

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)

Cheers,
  Albert

> 
> Ciao

Re: To C++11 or not?

[Luigi Toscano]

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 are probably the most apparent issues (since
>compilers 
>started to warn about both), and *having* 'override' is actually super
>useful 
>for preventing programmer faults.
>
>Let's just speak about allowing nullptr & override, allowing the full
>set of C
>++11 is *not* feasible. Reason: Lot's of C++11 feature are only
>available only 
>in MSVC2015, so we'd just be able to support the latest VS. See [2].
>
>Looking at [1] I still see we list GCC 4.5 as minimum requirement.
>That's 
>pretty ancient. 4.5.1 got released Jul 2010 [3]
>
>If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use
>
>'nullptr' unconditionally. ktexteditor already did that in public
>headers for 
>quite some time -- no-one complained.
>
>If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use
>
>'override' unconditionally *.
>
>We already use MSVC2012 as min VS dep, this version has full nullptr & 
>override support. I don't see anyone using MSVC2010 for compiling KF5
>to be 
>honest...
>
>Proposal for [1]:
>- Raise min GCC version to 4.7
>- Allow to use override unconditionally
>- Allow to use nullptr unconditonally
>
>ACK?
>
>
>PS: I can do the work, I can script the refactoring with clang-tidy.
>
>Let's move forward please.

Hi, this is a really good analysis (also for future reference). In order to 
complete it, given that the original idea was "follow Qt's requirement", and 
that we increased in time the required version of Qt, what is the current 
status regarding compilers and Qt?

Ciao

-- 
Luigi

Re: Minimum required cmake version

[Sune Vuorela]

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

[Elvis Angelaccio]

---
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, Ben Cooksley, Christoph Feck, and Martin 
Gräßlin.


Changes
---

Use the QScreen of the transientParent QWindow


Repository: kwidgetsaddons


Description
---

This new widget is based on the KToolTip code that is duplicated across 
multiple products: at least Dolphin, systemsettings, kinfocenter, 
ktp-contact-list.

Rationale: with a single class in frameworks, it will be possible to apply 
features/fixes only once. See for example the comments in 
https://phabricator.kde.org/D3112

A new feature that the old code doesn't have is the delayed hide: this makes it 
possible to actually use the widget shown in the tooltip.


Diffs (updated)
-

  autotests/CMakeLists.txt ffcce3a046ec98b07c4677578f6bc997de1ef16b 
  autotests/ktooltipwidgettest.h PRE-CREATION 
  autotests/ktooltipwidgettest.cpp PRE-CREATION 
  src/CMakeLists.txt de0a8d965f1541d5ffeec93d1aa06600b0b9c138 
  src/ktooltipwidget.h PRE-CREATION 
  src/ktooltipwidget.cpp PRE-CREATION 
  tests/CMakeLists.txt fcb348b1ae9d4270468c3f9003c5ba5f3903db84 
  tests/ktooltipwidget_test.h PRE-CREATION 
  tests/ktooltipwidget_test.cpp PRE-CREATION 

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


Testing
---

Manual test works both in X11 and Wayland. Unit tests pass.

Ported Dolphin locally to this new class, everything seems to work (and this 
will fix bug [#352276](https://bugs.kde.org/show_bug.cgi?id=352276) and 
[#371223](https://bugs.kde.org/show_bug.cgi?id=371223)).


Thanks,

Elvis Angelaccio

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

[Elvis Angelaccio]

> 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 what to use instead.
> `rect`? Or maybe `rect.topLeft()` is enough?
> 
> Martin Gräßlin wrote:
> Cant you just use the QScreen of the window you place the tooltip on?

The problem is that these size checks are done before the tooltip gets placed. 
Maybe I can try to use the transientParent's QScreen...


- Elvis


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


On Dec. 29, 2016, 10:11 a.m., Elvis Angelaccio wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129648/
> ---
> 
> (Updated Dec. 29, 2016, 10:11 a.m.)
> 
> 
> Review request for KDE Frameworks, Ben Cooksley, Christoph Feck, and Martin 
> Gräßlin.
> 
> 
> Repository: kwidgetsaddons
> 
> 
> Description
> ---
> 
> This new widget is based on the KToolTip code that is duplicated across 
> multiple products: at least Dolphin, systemsettings, kinfocenter, 
> ktp-contact-list.
> 
> Rationale: with a single class in frameworks, it will be possible to apply 
> features/fixes only once. See for example the comments in 
> https://phabricator.kde.org/D3112
> 
> A new feature that the old code doesn't have is the delayed hide: this makes 
> it possible to actually use the widget shown in the tooltip.
> 
> 
> Diffs
> -
> 
>   autotests/CMakeLists.txt ffcce3a046ec98b07c4677578f6bc997de1ef16b 
>   autotests/ktooltipwidgettest.h PRE-CREATION 
>   autotests/ktooltipwidgettest.cpp PRE-CREATION 
>   src/CMakeLists.txt de0a8d965f1541d5ffeec93d1aa06600b0b9c138 
>   src/ktooltipwidget.h PRE-CREATION 
>   src/ktooltipwidget.cpp PRE-CREATION 
>   tests/CMakeLists.txt fcb348b1ae9d4270468c3f9003c5ba5f3903db84 
>   tests/ktooltipwidget_test.h PRE-CREATION 
>   tests/ktooltipwidget_test.cpp PRE-CREATION 
> 
> Diff: https://git.reviewboard.kde.org/r/129648/diff/
> 
> 
> Testing
> ---
> 
> Manual test works both in X11 and Wayland. Unit tests pass.
> 
> Ported Dolphin locally to this new class, everything seems to work (and this 
> will fix bug [#352276](https://bugs.kde.org/show_bug.cgi?id=352276) and 
> [#371223](https://bugs.kde.org/show_bug.cgi?id=371223)).
> 
> 
> Thanks,
> 
> Elvis Angelaccio
> 
>

Re: To C++11 or not?

[Kevin Funk]

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 from the perspective of our C++ requirements. On
> the one side we say that we are not allowed to use these features to
> still support non-C++11 compilers on the other side we see that
> compilers already generate warnings if you don't use the C++11 features.
> 
> In that particular case I do not think that Q_DECL_OVERRIDE is a
> solution. It's an ugly hack and for the frameworks I maintain I gave a
> -2 on the review. I think this needs a general solution of either not
> adding or adding override, but not the Qt hack.
> 
> I think this is a sign that we need to move on. We cannot continue with
> the state we are in. It's too much a hassle for developers:
> * false-positive compile warnings
> * no way to check which features are allowed or not
> * no warnings if a not allowed feature is used
> * no CI system in place to ensure our rules
> 
> Given that I want to suggest that we remove all compiler restrictions
> and allow the full feature set of C++11. If someone still thinks we need
> to support the compilers not supporting C++11, I would like to see a
> plan on how we can improve the developer story, especially how to
> address the last two points in my list above.
> 
> Opinions?

Heya,

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 are probably the most apparent issues (since compilers 
started to warn about both), and *having* 'override' is actually super useful 
for preventing programmer faults.

Let's just speak about allowing nullptr & override, allowing the full set of C
++11 is *not* feasible. Reason: Lot's of C++11 feature are only available only 
in MSVC2015, so we'd just be able to support the latest VS. See [2].

Looking at [1] I still see we list GCC 4.5 as minimum requirement. That's 
pretty ancient. 4.5.1 got released Jul 2010 [3]

If we raise that to GCC 4.6 (4.6.0 being released Mar 2011), we can use 
'nullptr' unconditionally. ktexteditor already did that in public headers for 
quite some time -- no-one complained.

If we raise that to GCC 4.7 (4.7.0 being released Mar 2012), we can use 
'override' unconditionally *.

We already use MSVC2012 as min VS dep, this version has full nullptr & 
override support. I don't see anyone using MSVC2010 for compiling KF5 to be 
honest...

Proposal for [1]:
- Raise min GCC version to 4.7
- Allow to use override unconditionally
- Allow to use nullptr unconditonally

ACK?


PS: I can do the work, I can script the refactoring with clang-tidy.

Let's move forward please.

Cheers,
Kevin

[1] https://community.kde.org/Frameworks/
Policies#Frameworks_compiler_requirements_and_C.2B.2B11
[2] http://en.cppreference.com/w/cpp/compiler_support
[3] https://gcc.gnu.org/releases.html
[4] https://en.wikipedia.org/wiki/Microsoft_Visual_Studio#History
   
> Cheers
> Martin


-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.

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

[no-reply]

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

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.test_kns-kpackage

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/254 
(33%)CONDITIONAL 38/194 (20%)

By packages
  
autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 25/27 (93%)CONDITIONAL 
5/10 (50%)
src.kpackage-install-handlers.kns
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 12/49 (24%)CONDITIONAL 
4/22 (18%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/178 (26%)CONDITIONAL 
29/162 (18%)

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

[no-reply]

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

Name: (root) Failed: 1 test(s), Passed: 3 test(s), Skipped: 0 test(s), Total: 4 
test(s)Failed: TestSuite.test_kns-kpackage

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 3/3 (100%)FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 84/254 
(33%)CONDITIONAL 38/194 (20%)

By packages
  
autotests
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 25/27 (93%)CONDITIONAL 
5/10 (50%)
src.kpackage-install-handlers.kns
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 12/49 (24%)CONDITIONAL 
4/22 (18%)
src.kstyle
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 47/178 (26%)CONDITIONAL 
29/162 (18%)

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

[David Faure]

---
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 only an event filter on QMainWindows, not a qApp event filter, 
so it's fine.


src/kstandardaction.cpp (line 91)


trailing whitespace ;)


- David Faure


On Dec. 29, 2016, 11:01 p.m., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129261/
> ---
> 
> (Updated Dec. 29, 2016, 11:01 p.m.)
> 
> 
> Review request for KDE Frameworks.
> 
> 
> Repository: kconfigwidgets
> 
> 
> Description
> ---
> 
> Some applications have a "Show Menu Bar" action that is a bit silly on 
> systems where the menubar is part of the shell (for example Unity 7).
> 
> This patch attempts to fix it by iterating all the main windows when they are 
> shown and if all the menubars of all mainwindows are native, then hides the 
> show menu bar action (basically erasing it from existence).
> 
> It's not the nicest of the codes and probably has some edge cases but works 
> on the general case so i think it's worth the effort.
> 
> 
> Diffs
> -
> 
>   src/kstandardaction.cpp 89d011e 
> 
> Diff: https://git.reviewboard.kde.org/r/129261/diff/
> 
> 
> Testing
> ---
> 
> Tried konsole, kate and dolphin under Unity 7 on Ubuntu 16.10
> 
> konsole and kate work fine (i.e. the action is gone from the menus and all is 
> good)
> 
> dolphin is not 100% "perfectly behabed" (i.e. the "control" toolbar item is 
> supposed to not be shown when menubars are shown and in this case it's shown) 
> but it's not a regression and imho it's the dolphin code being a bit weird (i 
> can propose a patch for it if this gets accepted)
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>

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

[no-reply]

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

Name: (root) Failed: 1 test(s), Passed: 10 test(s), Skipped: 0 test(s), Total: 
11 test(s)Failed: TestSuite.kservicetest

COBERTURA RESULTS

Cobertura Coverage Report
  PACKAGES 6/7 (86%)FILES 75/84 (89%)CLASSES 75/84 (89%)LINE 5468/7987 
(68%)CONDITIONAL 2964/6144 (48%)

By packages
  
autotests
FILES 14/14 (100%)CLASSES 14/14 (100%)LINE 1442/1530 
(94%)CONDITIONAL 886/1768 (50%)
src.kbuildsycoca
FILES 1/1 (100%)CLASSES 1/1 (100%)LINE 61/67 (91%)CONDITIONAL 
15/20 (75%)
src.kdeinit
FILES 0/2 (0%)CLASSES 0/2 (0%)LINE 0/326 (0%)CONDITIONAL 0/262 
(0%)
src.plugin
FILES 2/3 (67%)CLASSES 2/3 (67%)LINE 47/100 (47%)CONDITIONAL 
36/96 (38%)
src.services
FILES 29/30 (97%)CLASSES 29/30 (97%)LINE 1765/3045 
(58%)CONDITIONAL 764/1892 (40%)
src.sycoca
FILES 26/31 (84%)CLASSES 26/31 (84%)LINE 2045/2799 
(73%)CONDITIONAL 1229/2056 (60%)
tests.pluginlocator
FILES 3/3 (100%)CLASSES 3/3 (100%)LINE 108/120 (90%)CONDITIONAL 
34/50 (68%)

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

[kfunk (Kevin Funk)]

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 [1]. I've also tested Clang, it's supported from at *least* Clang 
3.5 there. Intel compiler also supports it since at least 2005 [2]. I don't 
think we need a `check_cxx_compiler_flag` here.
  
  [1] https://gcc.gnu.org/ml/gcc-patches/2000-04/msg00333.html
  [2] https://software.intel.com/en-us/forums/intel-c-compiler/topic/308561

REPOSITORY
  R240 Extra CMake Modules

REVISION DETAIL
  https://phabricator.kde.org/D3850

EMAIL PREFERENCES
  https://phabricator.kde.org/settings/panel/emailpreferences/

To: kfunk, #frameworks, ivan, #buildsystem
Cc: rakuco, elvisangelaccio

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

[Martin Gräßlin]

> 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 
> > all projects I maintain to silence this warning again. And even less I want 
> > to spent days adding overrides to legacy code base.
> 
> Laurent Montel wrote:
> We can use Q_DECL_OVERRIDE which is replaced by override when your gcc 
> support it. So There is not a problem to use this flags no ?

I commented on that aspect in the past. We cannot have both: enforce C++11 and 
at the same time keep compatibility to no C++11.


We need to find a real line and not bullshit around with macros.


Either we say C++11 then enable all of it, or say no. But then no earnings 
please.


I'm seriously annoyed by the stupid dance we are doing.


- Martin


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


On Dez. 30, 2016, 12:48 vorm., Albert Astals Cid wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/129724/
> ---
> 
> (Updated Dez. 30, 2016, 12:48 vorm.)
> 
> 
> Review request for Build System and KDE Frameworks.
> 
> 
> Repository: extra-cmake-modules
> 
> 
> Description
> ---
> 
> Gives a nice warning about something that should be marked as override but 
> isn't
> 
> 
> Diffs
> -
> 
>   kde-modules/KDEFrameworkCompilerSettings.cmake 038ddc3 
> 
> Diff: https://git.reviewboard.kde.org/r/129724/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Albert Astals Cid
> 
>