D6754: [server] Send pointer leave if focused surface gets unbound
This revision was automatically updated to reflect the committed changes. Closed by commit R127:a00a5d5e1c97: [server] Send pointer leave if focused surface gets unbound (authored by graesslin). REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6754?vs=16829&id=16900 REVISION DETAIL https://phabricator.kde.org/D6754 AFFECTED FILES autotests/client/test_wayland_seat.cpp src/server/pointer_interface.cpp To: graesslin, #plasma, #frameworks, sebas Cc: plasma-devel, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, eliasp, sebas, apol, mart, hein, lukas
D6776: Don't perform wayland specific fixes when on X
graesslin added a comment.
Your commit message has a typo where X is written but Wayland is meant.
INLINE COMMENTS
> dialog.cpp:1160
>
> -if (ee->region().isNull()) {
> +if (ee->region().isNull() || KWindowSystem::isPlatformX11()) {
> return QQuickWindow::event(event);
Maybe better and with Wayland? There is also Windows which is officially
supported...
REPOSITORY
R242 Plasma Framework (Library)
REVISION DETAIL
https://phabricator.kde.org/D6776
To: davidedmundson, #plasma
Cc: graesslin, plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai,
ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas
D6776: Don't perform wayland specific fixes when on X
davidedmundson created this revision. Restricted Application added projects: Plasma, Frameworks. Restricted Application added subscribers: Frameworks, plasma-devel. REVISION SUMMARY https://phabricator.kde.org/R242:fd2e850156ac7aa9c9dc2cf46652b2a1f1fc3a07 introduces some behaviour changes that affect X even though they're only X related. CCBUG: 381130 REPOSITORY R242 Plasma Framework (Library) BRANCH master REVISION DETAIL https://phabricator.kde.org/D6776 AFFECTED FILES src/plasmaquick/dialog.cpp To: davidedmundson, #plasma Cc: plasma-devel, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas
D6687: Adding support to ipv*.route-metric
lvsouza accepted this revision. This revision is now accepted and ready to land. REPOSITORY R282 NetworkManagerQt REVISION DETAIL https://phabricator.kde.org/D6687 To: pvillani, jgrulich, lvsouza Cc: #frameworks
D6493: Add KF5WindowSystem to link interface
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R242 Plasma Framework (Library) BRANCH master REVISION DETAIL https://phabricator.kde.org/D6493 To: asturmlechner, #plasma, davidedmundson Cc: plasma-devel, davidedmundson, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas
D6493: Add KF5WindowSystem to link interface
asturmlechner updated this revision to Diff 16896. asturmlechner added a comment. Restricted Application added a project: Plasma. Restricted Application added a subscriber: plasma-devel. Changed according to review REPOSITORY R242 Plasma Framework (Library) CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6493?vs=16151&id=16896 BRANCH master REVISION DETAIL https://phabricator.kde.org/D6493 AFFECTED FILES KF5PlasmaConfig.cmake.in To: asturmlechner, #plasma Cc: plasma-devel, davidedmundson, #frameworks, ZrenBot, progwolff, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, mart, lukas
D6775: Fix labels of DeleteFile/RenameFile actions
elvisangelaccio created this revision. Restricted Application added a project: Frameworks. REVISION SUMMARY For consistency with https://phabricator.kde.org/D6774. TEST PLAN None as I can't figure out whether these strings are actually displayed somewhere. REPOSITORY R237 KConfig BRANCH master REVISION DETAIL https://phabricator.kde.org/D6775 AFFECTED FILES src/gui/kstandardshortcut.cpp To: elvisangelaccio, #frameworks
D6774: Fix labels of DeleteFile/RenameFile actions
elvisangelaccio created this revision. Restricted Application added a project: Frameworks. REVISION SUMMARY These actions can be applied also to folders, so their user-visible labels should not explicitly mention "File". BUG: 382450 REPOSITORY R265 KConfigWidgets BRANCH master REVISION DETAIL https://phabricator.kde.org/D6774 AFFECTED FILES src/kstandardaction_p.h To: elvisangelaccio, #frameworks
D6773: Add API dox for KDEInstallDirs' KDE_INSTALL_USE_QT_SYS_PATHS
apol accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules BRANCH adddoxforqtsyspaths REVISION DETAIL https://phabricator.kde.org/D6773 To: kossebau, #frameworks, apol Cc: #build_system
D6773: Add API dox for KDEInstallDirs' KDE_INSTALL_USE_QT_SYS_PATHS
kossebau added a comment. Given the slightly complicated history of what KDE_INSTALL_USE_QT_SYS_PATHS does, I omitted a "since" on purpose for now. Would you agree it makes sense to simplify things be just adding "Since 5.22" and ignore previous behaviour? See also https://phabricator.kde.org/D6772 for hardening/fixing the here documented behaviour. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D6773 To: kossebau, #frameworks Cc: #build_system
D6772: Fix usage of query_qmake: differ between calls expecting qmake or not
kossebau added a comment. See also https://phabricator.kde.org/D6773 for making the resulting behaviour documented. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D6772 To: kossebau, #frameworks, ltoscano, rdieter Cc: #build_system
D6773: Add API dox for KDEInstallDirs' KDE_INSTALL_USE_QT_SYS_PATHS
kossebau created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added a subscriber: Build System. REPOSITORY R240 Extra CMake Modules BRANCH adddoxforqtsyspaths REVISION DETAIL https://phabricator.kde.org/D6773 AFFECTED FILES kde-modules/KDEInstallDirs.cmake To: kossebau, #frameworks Cc: #build_system
D6772: Fix usage of query_qmake: differ between calls expecting qmake or not
kossebau created this revision. Restricted Application added projects: Frameworks, Build System. Restricted Application added a subscriber: Build System. REVISION SUMMARY when KDE_INSTALL_USE_QT_SYS_PATHS has been explicitely set, qmake can be considered a required dependency, otherwise the paths will not be known, which would be unexpected. Also does the code calling query_qmake, besides the one testing for the same install prefix, not handle the case of empty strings being returned and then results in bogus behaviour. Thus this patch makes code fail hard if query_qmake is expected to yield a result, but no qmake executable is found. REPOSITORY R240 Extra CMake Modules BRANCH handlenoqmakefound REVISION DETAIL https://phabricator.kde.org/D6772 AFFECTED FILES kde-modules/KDEInstallDirs.cmake modules/ECMAddQch.cmake modules/ECMGeneratePriFile.cmake modules/ECMQueryQmake.cmake To: kossebau, #frameworks, ltoscano, rdieter Cc: #build_system
D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin
winterz closed this revision. winterz added a comment. see https://phabricator.kde.org/R240:db46fb7c2fdcfbff5f8a0445e4d055cf4388ead8 REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D6762 To: winterz, skelly, #build_system, #windows, kfunk Cc: nalvarez, #frameworks, #build_system
KDE CI: Frameworks extra-cmake-modules kf5-qt5 FreeBSDQt5.7 - Build # 38 - Still Unstable!
BUILD UNSTABLE Build URL https://build.kde.org/job/Frameworks%20extra-cmake-modules%20kf5-qt5%20FreeBSDQt5.7/38/ Project: Frameworks extra-cmake-modules kf5-qt5 FreeBSDQt5.7 Date of build: Tue, 18 Jul 2017 12:30:24 + Build duration: 2 min 14 sec and counting JUnit Tests Name: (root) Failed: 1 test(s), Passed: 48 test(s), Skipped: 0 test(s), Total: 49 test(s)Failed: TestSuite.KDEInstallDirsTest.relative_or_absolute build.log Description: Binary data
D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin
winterz added a comment. In https://phabricator.kde.org/D6762#126463, @nalvarez wrote: > Looks reasonable – although I wonder why on earth you're building KDE stuff on Cygwin... fun. as an experiment. i'm curious. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D6762 To: winterz, skelly, #build_system, #windows, kfunk Cc: nalvarez, #frameworks, #build_system
D6767: simplify setContents by letting Qt do more of the work
sitter updated this revision to Diff 16865. sitter retitled this revision from "do not keep constructing new selectionmodels" to "simplify setContents by letting Qt do more of the work". sitter edited the summary of this revision. sitter added a comment. did some more digging with input from David. we can do away with the selectionModel management entirely. QAIV manages the selectionModel itself via setModel. it also connects our input model's `destroyed()` signal to the selection models deleteLater, so deleting our model will consistently clean up the selection as well. additionally the mode and behavior setting affect only the view itself and are persistent across model changes, so we can move this to the ctor (where interstingly behavior was already set) there's one more change we could do to this: right now we manually connect _k_slotSelectionChanged to the selection model, we need to do this every time we change model. alternatively we could also override the `protected virtual selectionChanged`. except IIRC this would be BIC with MSVC so we probably don't want this REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6767?vs=16861&id=16865 BRANCH master REVISION DETAIL https://phabricator.kde.org/D6767 AFFECTED FILES src/kcharselect.cpp To: sitter, cfeck, davidedmundson Cc: davidedmundson, #frameworks
D6767: do not keep constructing new selectionmodels
davidedmundson requested changes to this revision. davidedmundson added a comment. This revision now requires changes to proceed. QAIV creates a new selectionModel whenever we call setModel. (qabstractitemview.cpp:762) So you're right this is at best, a bit pointlesss, but the fix isn't right, as the code in the new if() will never get called and we won't setSelectionBehavior/setSelectionMode REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D6767 To: sitter, cfeck, davidedmundson Cc: davidedmundson, #frameworks
D6767: do not keep constructing new selectionmodels
sitter created this revision. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: Frameworks. REVISION SUMMARY simply change its underlying model after it has been initialized once. ideally I suppose instead of changing the model at all we should have a full model and put a qsortfilterproxymodel in front of it thus making setContents in its current form obsolete as we'd then only need to filter as necessary. I am not quite confident enough in my understanding of how the code presently works to make such an invasive change. TEST PLAN tests still passing REPOSITORY R236 KWidgetsAddons BRANCH master REVISION DETAIL https://phabricator.kde.org/D6767 AFFECTED FILES src/kcharselect.cpp To: sitter, cfeck Cc: #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
This revision was automatically updated to reflect the committed changes. Closed by commit R236:ca40063c4e49: do not crash qaccessible by causing a resize in a resize event (authored by sitter). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D6624?vs=16502&id=16860#toc REPOSITORY R236 KWidgetsAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6624?vs=16502&id=16860 REVISION DETAIL https://phabricator.kde.org/D6624 AFFECTED FILES src/kcharselect.cpp To: sitter, gladhorn, cfeck Cc: cfeck, anthonyfieroni, #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
cfeck accepted this revision. cfeck added a comment. This revision is now accepted and ready to land. Would be nice if you also commit the conditional in the KCharSelectItemModel ::setColumnCount. REPOSITORY R236 KWidgetsAddons BRANCH master REVISION DETAIL https://phabricator.kde.org/D6624 To: sitter, gladhorn, cfeck Cc: cfeck, anthonyfieroni, #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
sitter added a comment. In https://phabricator.kde.org/D6624#126506, @cfeck wrote: > Let's say someone fixes the referenced Qt bug, and we are at a point requiring that Qt version anyway. Are you going to remove the workaround? Anyone who happens to stumble upon it can. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D6624 To: sitter, gladhorn Cc: cfeck, anthonyfieroni, #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
cfeck added a comment. Let's say someone fixes the referenced Qt bug, and we are at a point requiring that Qt version anyway. Are you going to remove the workaround? REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D6624 To: sitter, gladhorn Cc: cfeck, anthonyfieroni, #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
sitter added a comment. In https://phabricator.kde.org/D6624#126503, @cfeck wrote: > If you are sure that your fix is "correct", then please remove the comment. From reading it, it looks like a workaround for a Qt bug. It is a workaround. It crashes because the life time of the qaccessible objects is managed rather badly and fixing that is less trivial than this workaround. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D6624 To: sitter, gladhorn Cc: cfeck, anthonyfieroni, #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
cfeck added a comment. Reading your comment it is also wrong. Resizing the model does not cause a resize of the widget. The widget size is controlled by the layout manager. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D6624 To: sitter, gladhorn Cc: cfeck, anthonyfieroni, #frameworks
D6672: add KAboutLicense::spdx and introduce orLater qualification
sitter updated this revision to Diff 16858. sitter added a comment. - do not use ctor delegation, can't use that in kf5 yet - eliminate the "partial" private ctor, instead call the full private ctor from the partial public ctors. this results in defaults being implemented in the public ctors' code rather than the private one, and makes it slightly harder to forget initalizing members as there's now only two ctors that have to deal with them directly. REPOSITORY R244 KCoreAddons CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D6672?vs=16814&id=16858 BRANCH spdx REVISION DETAIL https://phabricator.kde.org/D6672 AFFECTED FILES autotests/kaboutdatatest.cpp src/lib/kaboutdata.cpp src/lib/kaboutdata.h To: sitter, sebas, mpyne Cc: #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
cfeck added a comment. If you are sure that your fix is "correct", then please remove the comment. From readiong it, it looks like a workaround for a Qt bug. REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D6624 To: sitter, gladhorn Cc: cfeck, anthonyfieroni, #frameworks
D6624: do not crash qaccessible by causing a resize in a resize event
sitter added a comment. In https://phabricator.kde.org/D6624#126465, @cfeck wrote: > > It probably does. > > Were you able to test? I would prefer the simpler patch. I cannot test it, because my system does not have accessibility enabled. Yes, I did not manage to crash it that way. As I said though, I do not think making the smallest possible fix is prudent here. While that change would be simpler it would also be more fragile. In resizeEvent() we'd still call a function of which the intention is to change the size of cells, which is meant to result in a layout change and thus potentially causes a resize, bringing us back to the crashing call chain. Making the column update conditional does fix the immediate cause of this **right now**. Conceptually the issue would still be there: we call a method of which the intention is to change the layout from within a resizeEvent handler. Something that is not safe to do with the current qaccessible lifetime management. If someone goes ahead and changes the way the models are being used and/or //when// size calculation happens in the future we'll be crashing again. TLDR I don't find introducing the `if` a future-proof solution. It's only treating the symptom. We'd reinforce a bone with a metal plate whilst ignoring the fact that the patient has a disorder that makes her run in front of cars. (I do think that introducing that if would be handy eitherway, not as a measure of dealing with the crash though) REPOSITORY R236 KWidgetsAddons REVISION DETAIL https://phabricator.kde.org/D6624 To: sitter, gladhorn Cc: cfeck, anthonyfieroni, #frameworks
D6762: ECM: KDECompilerSettings LINKER_FLAGS on Cygwin
kfunk accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D6762 To: winterz, skelly, #build_system, #windows, kfunk Cc: nalvarez, #frameworks, #build_system
