D5821: KViewStateSerializer: Fix crash when view is destroyed before state serializer

2017-06-01 Thread Christoph Feck
cfeck added a comment. ping? REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D5821 To: cfeck, #frameworks Cc: mlaurent

D6054: Use explicit flag values or explicit constructor instead of nullptr

2017-06-01 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes. Closed by commit R278:ccbad906db1b: Use explicit flag values or explicit constructor instead of nullptr (authored by kossebau). REPOSITORY R278 KWindowSystem CHANGES SINCE LAST UPDATE

D6054: Use explicit flag values or explicit constructor instead of nullptr

2017-06-01 Thread Friedrich W. H. Kossebau
kossebau added a comment. Checking the diff another time I find it would be even nicer to extend `NET::Property`, `NET::Property2`, `NET::Action` & Co. to have an entry for `0` value, named `NoProperties`, `NoProperties2`, `NoActionFlags` etc. (cmp. e.g. `Qt::ItemFlags`), so those enum

D6047: WIP: Support XDG v6

2017-06-01 Thread Marco Martin
mart added inline comments. INLINE COMMENTS > davidedmundson wrote in xdgshell_interface.h:80 > We need the serial Ids here, otherwise it's not very usable; especially as > the pong doesn't have an elapsed time. > > A kjob like API wrapping this might be perfect for here? so storing all the

Mac(/bug?) Control + Tab shortcut doesn't do anything

2017-06-01 Thread René J . V . Bertin
Hello, I just discovered that the Control+Tab and Control+Shift+Tab shortcuts don't work in KF5 applications on Mac: - In a pure Qt application I can assign Control+Tab to an action (using Qt::Meta+Qt::Key_Tab, evidently) and pressing the key combination will trigger the action. - In KF5, I

KDE CI: Frameworks ktexteditor kf5-qt5 XenialQt5.7 - Build # 11 - Fixed!

2017-06-01 Thread no-reply
BUILD SUCCESS Build URL https://build-sandbox.kde.org/job/Frameworks%20ktexteditor%20kf5-qt5%20XenialQt5.7/11/ Project: Frameworks ktexteditor kf5-qt5 XenialQt5.7 Date of build: Thu, 01 Jun 2017 14:57:43 + Build duration: 7 min 24 sec and counting

KDE CI: Frameworks ktexteditor kf5-qt5 XenialQt5.7 - Build # 9 - Still Unstable!

2017-06-01 Thread no-reply
BUILD UNSTABLE Build URL https://build-sandbox.kde.org/job/Frameworks%20ktexteditor%20kf5-qt5%20XenialQt5.7/9/ Project: Frameworks ktexteditor kf5-qt5 XenialQt5.7 Date of build: Thu, 01 Jun 2017 14:04:22 + Build duration: 6 min 32 sec and counting

Re: Review Request 130138: Set QT_NO_EXCEPTIONS when building *.mm files

2017-06-01 Thread Harald Fernengel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/130138/ --- (Updated June 1, 2017, 1:27 p.m.) Status -- This change has been

Re: Review Request 130139: Set QT_NO_EXCEPTIONS for *.mm files

2017-06-01 Thread Harald Fernengel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/130139/ --- (Updated June 1, 2017, 1:27 p.m.) Status -- This change has been

Re: Review Request 130139: Set QT_NO_EXCEPTIONS for *.mm files

2017-06-01 Thread Harald Fernengel
> On May 25, 2017, 2:36 p.m., René J.V. Bertin wrote: > > See also https://phabricator.kde.org/D5972 agree that it should be fixed in ecm. Hope the fix can make it to the next release of kf5-ecm so I can remove my hack from homebrew - Harald

Re: Review Request 123075: do not require X11 on Mac OS X

2017-06-01 Thread Harald Fernengel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123075/ --- (Updated June 1, 2017, 1:20 p.m.) Status -- This change has been

KDE CI: Frameworks ktexteditor kf5-qt5 XenialQt5.7 - Build # 8 - Still Unstable!

2017-06-01 Thread no-reply
BUILD UNSTABLE Build URL https://build-sandbox.kde.org/job/Frameworks%20ktexteditor%20kf5-qt5%20XenialQt5.7/8/ Project: Frameworks ktexteditor kf5-qt5 XenialQt5.7 Date of build: Thu, 01 Jun 2017 12:53:43 + Build duration: 7 min 11 sec and counting

D6047: WIP: Support XDG v6

2017-06-01 Thread David Edmundson
davidedmundson added a comment. Comments for Marco: INLINE COMMENTS > xdgshell_interface.h:80 > > +void ping(); > + We need the serial Ids here, otherwise it's not very usable; especially as the pong doesn't have an elapsed time. A kjob like API wrapping this might be perfect for

D6053: Use explicit flag values or explicit constructor instead of nullptr

2017-06-01 Thread Friedrich W. H. Kossebau
This revision was automatically updated to reflect the committed changes. Closed by commit R236:ff2e1d8e22fe: Use explicit flag values or explicit constructor instead of nullptr (authored by kossebau). REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE

D6053: Use explicit flag values or explicit constructor instead of nullptr

2017-06-01 Thread Christoph Feck
cfeck accepted this revision. REPOSITORY R236 KWidgetsAddons BRANCH nonullptrforflagsplease REVISION DETAIL https://phabricator.kde.org/D6053 To: kossebau, #frameworks, cfeck, kfunk Cc: kfunk

D6054: Use explicit flag values or explicit constructor instead of nullptr

2017-06-01 Thread Kevin Funk
kfunk accepted this revision. This revision is now accepted and ready to land. REPOSITORY R278 KWindowSystem BRANCH nonullptrforflagsplease REVISION DETAIL https://phabricator.kde.org/D6054 To: kossebau, #plasma, graesslin, kfunk Cc: plasma-devel, #frameworks, ZrenBot, spstarr,

D6053: Use explicit flag values or explicit constructor instead of nullptr

2017-06-01 Thread Friedrich W. H. Kossebau
kossebau added inline comments. INLINE COMMENTS > cfeck wrote in kfontrequester.cpp:187 > Does removing the default value mean the flags would be now uninitialized? No, the constructor called would be (as before) `QFlags::QFlags(Zero zero = Q_NULLPTR)`, so still default to 0 internally, so

D6053: Use explicit flag values or explicit constructor instead of nullptr

2017-06-01 Thread Kevin Funk
kfunk accepted this revision. kfunk added inline comments. This revision is now accepted and ready to land. INLINE COMMENTS > cfeck wrote in kfontrequester.cpp:187 > Does removing the default value mean the flags would be now uninitialized? No, `QFontDialog::FontDialogOptions` is a `QFlags<>`