Frameworks / Plasma/ Gear Release Schedule Plan
Following on from the last Akademy we checked where we were with our development progress in a meeting and settled on the following plan for all 3 major parts: - In KDE Gear master will be open for Qt6 code to land for those ready to move. Not all apps need to port. - The KDE Gear release will move by 2 months to allow for the extra time needed for testing initial Qt6 changes - An Alpha will be made in November (a soft freeze in Plasma terms) - Betas/RCs will be made throughout December and January (3 releases, 3 weeks apart) - Final release of all 3 major parts in sync in February Due to the delay of KDE Gear by an additional patch release of 23.08 will be made. David Edmundson
Re: Planning the final 6 release timeframes
As a reminder this meeting is tonight in 3 hours. David
Re: Planning the final 6 release timeframes
Video call at https://meet.kde.org/b/ada-mi8-aem
Re: Planning the final 6 release timeframes
A time has been chosen on the poll with a clear winner: 4th September 18:00 CEST See you all there David Edmundson
Planning the final 6 release timeframes
As discussed at Akademy we need to finalize the release of KF6 / Applications with 6 and Plasma 6. Applications can't release without Plasma (for Breeze + Plasma Integration) Plasma is weakened without kio-extras Both depend on Frameworks which needs a final release. We want to be fairly synced which means a release together. Multiple alternative options to releasing in sync are possible, but general consensus at Akademy was that it made things more complex. Plasma was targeting to be ready "at end of the year", but that doesn't quite line up with having betas in November. We need to come up with a plan that works for KDE Gear application authors, Plasma team and Frameworks dev. A doodle poll is available at: https://nuudel.digitalcourage.de/qqpRbUMFIQdLP1ZP At the end of the meeting there must be a decision made. If there's no consensus we'll have to have a vote with multiple rounds of elimination. Open discussion ahead of time is available at: https://invent.kde.org/teams/frameworks-devs/kf6-workboard/-/issues/55 David Edmundson
Re: Porting aid place for Plasma stuff?
For kwayland I would suggest to keep it in it's own repo kept being called kwayland Dialog is in Plasma-framework which is moving to workspace anyway. I'm not sure of the status of that move is. I would put suggest putting D&D stuff in plasma-framework (or whatever it ends up being called)
Re: Minutes from the porting BOF
Updates on this topic after the plasma BOF. There's some concerns (by me mostly) about Plasma being committed to a rigid schedule. As such the following was somewhat agreed upon. We can probably delay the .12 release of KDE Gear if it's needed. The Qt 6 transition is a special case. If we want to delay more than 2 months, then we may as well just wait for 24.04. At the start of September, we'll do a big online meeting with all stakeholders and make an executive decision. David
Minutes from the porting BOF
They're in a short format, ping if there's any questions. # Timelines KDE Gear 0.8 will be Qt5 ONLY KDE Gear .12 should be Qt5 and Qt6 Will REQUIRE plasma to be out (for themes and stuff). Plasma timing discussion is tomorrow, so that maybe throws things out. Apps should keep master as Qt5 and develop in a branch. Only make master Qt6 only when it's clear things are on target. This would mean a KF6 release in November. We should do betas and RCs working backwards. That put things very soon :/ We do not expect to keep dual-building libs and apps forever! As soon as they switch to master, go to them. If you do dual build, don't use QT_VERSIONLESS_TARGETS, instead use QT_MAJOR_VERSION everywhere. # Blockers No Qt blockers! We do depend on Qt5Compat but that's fine. # Flatpak We will get 2 flatpak runtimes, one for 6. We have a Qt6 runtime already, just without KF6. We could benefit from a beta runtime with nightlies /weeklies. # Thumbnailers We need Qt5 apps to read Qt6 thumbnailers, and vice-versa. General consensus is "lets port quickly and get things out all at once". But maybe it's an opportunity to fix more universally. BOF on Thursday # Specific issues: ## QML and ifdefs It's been an issue There won't be an ifdef in QML in future /maybe/ a constexpr logic might be allowed, but we need to think about tooling. ## QPaletes We can't access propreties for colours. The C++ implementation returns a brush not a colour. Changing QtBase so it has properties which return a colour would be horrible. Having a setter on controls which accepts a variant might be a land-able option. ## Shader tools: Action item: Arjen had some issues, to file bugs with the relevant Qt person.
Re: kf6 deconflictor progress
On Fri, Apr 28, 2023 at 5:59 PM Jonathan Riddell wrote: > > The deconflictor job we run in neon still has a bunch of files overlapping > between kf5 and kf6 > > https://build.neon.kde.org/job/test_kf6_deconflictor/ > > https://build.neon.kde.org/job/test_kf6_deconflictor/9/artifact/conflict-report.json/*view*/ > > Is there any progress being made in fixing this? Any, yes. Obviously it's not done yet. I'm not sure this report is up to date: "/usr/kf6/bin/kglobalaccel5", "/usr/bin/kglobalaccel5" I can't see us installing that. > We'd like to move the neon packages into /usr which would break our > deconflicting report job. You know how to make progress faster :) > Jonathan >
Re: kitemmodels kf6 build failure
Please ensure you are building with -DEXCLUDE_DEPRECATED_BEFORE_AND_AT=5.91.0
KF5 branches
There is now a "kf5" branch in all frameworks repos as discussed last frameworks meeting. Starting now any commits that are also wanted in the next KF5 should be cherry-picked after landing. This does *not* mean master is fully open for going into KF6 dev mode. Now the kf5 branches exist, we'll set up tooling and infrastructure and make sure that is all stable. Only after that is all sorted should master start getting any Qt6-exclusive dev work and version bumps. Regards David
Plasma 6 Planning sprint starts tomorrow!
I'm sure everyone is excited: Full schedule and joining instructions available at: https://invent.kde.org/plasma/plasma-workspace/-/issues/32 Looking forward to seeing your all David
Re: QML API docs for C++ wrapper types?
We have examples of where we have done this. Though I wouldn't necessarily use the word "properly". In Plasma-framework we have a manually made list where we can write the plugin name and list items by their exported QML type name. https://invent.kde.org/frameworks/plasma-framework/-/blob/master/src/declarativeimports/core/Mainpage.dox Which appears as: https://api.kde.org/frameworks/plasma-framework/html/core.html That links to the classic C++ generated docs, and we rely on users to know to only look at properties and signals.
Re: Gitlab CI - Inbound
Excellent news!! Thanks very much > Once the scripts have been proven successfully for Frameworks, we will look > at extending them to projects that depend only on Frameworks and repositories Does this mean we would like Plasma to wait a while before merging? Is it worth us creating the kde-cli files and not merging them so we have some test cases ready? David
Re: Moving plasma-frameworks & krunner to Plasma release set for *6? (was: Re: KF6 meeting notes 2021-04-17)
> It seems these days the only real user of plasma-frameworks & krunner > libraries is the Plasma shell itself, with other applications only providing > plugins/extensions and only targeting Plasma again. That is mostly in line with other discussions in plasma. There is a ticket splitting plasma-framework and all of the applet stuff we hope to move to workspace - with some parts having other homes elsewhere. KRunner we haven't discussed in as much detail.
Re: KF6 online sprint: March 27-28
I wanted to bump this thread, just so people remember that it is this weekend! There are many many slots still available. David
Re: KCGroups in KDEreview
> > (where 1000 is of course dynamic) > > Ditto, what enum names could we give to those? / -> All /system.slice -> System user.slice/user-1000.slice/user@1000.service -> User user.slice/user-1000.slice/user@1000.service/app.slice -> UserApps user.slice/user-1000.slice/user@1000.service/session.slice -> UserSession user.slice/user-1000.slice/user@1000.service/background.slice -> UserBackground > Yes, I know I roll with questions. :-) > Cheers. > -- > Kevin Ottens, http://ervin.ipsquad.net
Re: Plasma Framework and Kirigami unittests
One down: https://invent.kde.org/frameworks/kirigami/-/merge_requests/200
Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore
On Sun, 20 Dec 2020, 11:48 Friedrich W. H. Kossebau, wrote: > (Added Han Young as BCC: based on code email address, as the task is not > public, and not sure you are subscribed to the mailinglists) > > Am Sonntag, 20. Dezember 2020, 12:05:46 CET schrieb David Edmundson: > > Please see https://community.kde.org/Policies/Application_Lifecycle > about > > the process of adding things to frameworks. > > > > As for plasma, we have a weather library there, so the comment about it > > being easier for new plasmoids doesn't hold directly. Maybe you can > expand > > on what's different? > > David, any chance you misremembered there being a weather library? If you > refer to the stuff in plasma-workspace (which then e.g. drives the kde- > plasmaaddons weather applet), that is just a DataEngine. > That is what I was referring to, yes. It may be "just" a dataengine, but the end-result of plasmoids/apps being able to get weather data is the same. I also have no qualms about replacing it for the same reasons you outlined (except maybe that this has a very hardcoded single backend), but we want to make sure we don't end up with two things. David
Re: T13975: Move hanyoung/libkweather to frameworks/kweathercore
Please see https://community.kde.org/Policies/Application_Lifecycle about the process of adding things to frameworks. As for plasma, we have a weather library there, so the comment about it being easier for new plasmoids doesn't hold directly. Maybe you can expand on what's different? David
Re: KCGroups in KDEreview
On Thu, Dec 3, 2020 at 11:48 AM Kevin Ottens wrote: > > Hello, > > On Thursday, 3 December 2020 12:15:52 CET David Edmundson wrote: > > Ultimately this isn't really dealing with cgroups directly but with > > the manager to control them, systemd. > > > > That's correct usage, kernel docs of cgroups say to go via a > > controller for write operations. However that at point is it worth > > naming the library ksystemd? > > It might cause some contention due to people who get angsty at a name, > > but it's a lot more fitting. It would then give us a place to dump a > > lot of other wrappers (especially logind) that we're seeing duplicated > > in a bunch of places throughout KDE. > > Aren't you concerned this might lead to one of our infamous dumping grounds? > > There's always a tension between making it too focused and tiny or unfocused > and with blackhole mass... we'd need to find where it stands but "systemd > wrappers" looks too loosely defined to me. > > Do we have a list of the wrappers you got in mind and which piece of feature > they all provide? StartUnit, given this has a StopUnit Used by plasma-workspace and plasma-firewall Logind I have wrappers in: - kwin - libkworkspace - SDDM - powerdevil - kscreenlocker None wrapping all of it, only what they need, but there's still overlap. You're right that could be a separate framework if that's preferred. > > > I think we've artificially limited the usage of the library. > > The code is very generic for handling units, but all the names and one > > tiny line limit it to only managing a subset of units. > > > > If we make the "glob" static used in KApplicationScopeLister's have a > > public setter (or a protected virtual) we can rename this class and it > > becomes a much more generic library for others to use outside of any > > initial use-case. > > Good point. Got a similar question though, which other unit types would be > useful to control? Reason being that API wise I'd smell an enum for something > like this. Enum potentially works too. Describing things in terms of cgroup hierarchy, I think the key use cases are: / user.slice/user-1000.slice/user@1000.service user.slice/user-1000.slice/user@1000.service/app.slice user.slice/user-1000.slice/user@1000.service/session.slice user.slice/user-1000.slice/user@1000.service/background.slice (where 1000 is of course dynamic)
Re: KCGroups in KDEreview
Ultimately this isn't really dealing with cgroups directly but with the manager to control them, systemd. That's correct usage, kernel docs of cgroups say to go via a controller for write operations. However that at point is it worth naming the library ksystemd? It might cause some contention due to people who get angsty at a name, but it's a lot more fitting. It would then give us a place to dump a lot of other wrappers (especially logind) that we're seeing duplicated in a bunch of places throughout KDE. --- I think we've artificially limited the usage of the library. The code is very generic for handling units, but all the names and one tiny line limit it to only managing a subset of units. If we make the "glob" static used in KApplicationScopeLister's have a public setter (or a protected virtual) we can rename this class and it becomes a much more generic library for others to use outside of any initial use-case. David
Re: RSIBreak / KIdleTime on Wayland
change made: https://invent.kde.org/plasma/kwayland-server/-/merge_requests/133
Re: RSIBreak / KIdleTime on Wayland
>If the user was idle for a second (using a KIdleTime timeout), I start my own >idle time counter (counter++ every second). >Then I catch the next resume event (next user input) and reset my counter to 0. That sounds like what I had in mind. > 2) It works with XWayland, but only detects user activity if the user makes > an input to an XWayland window. Yeah, that's expected. We only send things to X when an X app has focus. Changing this behaviour is not an option. I don't think this is a viable setup option to support. >RSIBreak is started as an XWayland application by default. That shouldn't be the case. Are you on OpenSuse by any chance? > > 3) It works okay if RSIBreak is started as a native Wayland application > (QT_QPA_PLATFORM=wayland). >All input is detected, on native and XWayland windows. >But: It takes about 5-10 seconds of me not doing any inputs for the idle > timeout to be called, instead of the 1 second timeout I requested. >(the resume event is emitted immediately though, it is just the idle > timout that is slow) Indeed: // less than 5 sec is not idle by definition timer->setInterval(qMax(timeout, 5000u)); In kwayland-server/src/server/idle_interface.cpp I have no objections to changing this. David > > So I wonder if this can be fixed in KIdleTime, or if that's just how Wayland > works. > Thank you, > Dominik
Re: RSIBreak / KIdleTime on Wayland
> > Yes, I meant that progress bar. > I've had that 1s idle timer idea as well, unfortunately after writing this, > but thank you for confirming that this would indeed work. > I will give that a try and if I can get RSIBreak to a working state on > wayland submit a PR for it. Excellent, thank you very much. Please do please reach out if there are any questions with regards to the wayland side. David
Re: RSIBreak / KIdleTime on Wayland
> I agree, if we can't make the KIdleTime framework work in Wayland there > should be a way to query the framework if it's going to work or not. Just to make sure that's not misread by others; the framework works for the majority of methods used in the common case, just not this one polling method. > > So do you think it makes sense to have the function return some form or > > error instead of just returning 0, or is there a good reason it is not > > doing that already? I don't think it helps with a lot, you need to change clients to handle the error, at which point we've not really solved a lot. If you're going to use the addIdleTimeout API you may as well do it everywhere. It is considerably lighter on X11 too. Like Albert suggested, a capabilities flag could make sense. At a super bare minimum the documentation needs updating. At the other extreme we could even deprecate it. If after trying to port rsibreak to use the event driven API and it turns out there really is a use case for a polling API, we do still have the option to start a discussion about extending the relevant wayland protocol to have such a query mechanism. >RSIBreak is unable to count down in wayland, after 1 second it always resets >its timer. Just to make sure we're talking about the same thing: Is it when you have a shortbreak set after N minutes and you get a "please relax for 20seconds" with a progress bar? If so, simplest option is to start a 1s idletime timer. We don't need to know how long we've been idle via polling, just if/when we're interrupted during the 20s countdown. David
Re: KDE CI: Frameworks » kxmlgui » kf5-qt5 SUSEQt5.12 - Build # 190 - Still Unstable!
My fault. Fix on review. David
Re: kwayland's testRemoteAccess still flaky
Urgh, let me just remove that test. No-one will even use that protocol soon anyway.
D26503: [Dialog Shadows] Port to KWindowSystem shadows API
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R242 Plasma Framework (Library) BRANCH port-to-shadows-api REVISION DETAIL https://phabricator.kde.org/D26503 To: zzag, #plasma, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28355: Introduce function ecm_install_configured_file
davidedmundson added a comment. Moved to invent. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D28355 To: davidedmundson, #build_system Cc: apol, kossebau, pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D28355: Introduce function ecm_install_configured_file
This revision was not accepted when it landed; it landed in state "Needs Review". This revision was automatically updated to reflect the committed changes. Closed by commit R240:2976b27a6c0b: Introduce function ecm_install_configured_file (authored by davidedmundson). REPOSITORY R240 Extra CMake Modules CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28355?vs=79176&id=83249 REVISION DETAIL https://phabricator.kde.org/D28355 AFFECTED FILES docs/module/ECMConfiguredInstall.rst modules/ECMConfiguredInstall.cmake tests/CMakeLists.txt tests/ECMConfiguredInstallTest/CMakeLists.txt tests/ECMConfiguredInstallTest/check_tree.cmake.in tests/ECMConfiguredInstallTest/configured.txt tests/ECMConfiguredInstallTest/configured_atOnly.txt.in tests/ECMConfiguredInstallTest/expected/configured.txt tests/ECMConfiguredInstallTest/expected/configured_atOnly.txt tests/ECMConfiguredInstallTest/expected/multi1.txt tests/ECMConfiguredInstallTest/expected/multi2.txt tests/ECMConfiguredInstallTest/multi1.txt.in tests/ECMConfiguredInstallTest/multi2.txt.in To: davidedmundson, #build_system Cc: apol, kossebau, pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29050: KRunner fix prepare/teardown signals
davidedmundson added a comment. > the runner "backend" is used (from the QML side of things). Repo is called milou REPOSITORY R308 KRunner BRANCH krunner_signal_bugfix (branched from master) REVISION DETAIL https://phabricator.kde.org/D29050 To: alex, meven, ngraham, broulik Cc: davidedmundson, cfeck, kde-frameworks-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, michaelh, ZrenBot, ngraham, bruns, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29228: [KProcessRunner] Use only executable name for scope
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D29228 To: broulik, #frameworks, #plasma, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29811: t/simplify-sending-data-through-socket
davidedmundson added a comment. > that would probably mean recompiling most of KDE (Debian has packages for 5.69 only). I will check out your change and see what remains. This isn't a universal rule that always applies, but generally speaking you can just roll back the the frameworks version in the CMakeLists.txt and build this one framework. REPOSITORY R285 KCrash REVISION DETAIL https://phabricator.kde.org/D29811 To: jpalecek, #frameworks Cc: anthonyfieroni, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29811: t/simplify-sending-data-through-socket
davidedmundson added a comment. Your base kcrash is quite out of date - I simplified this method considerably a month ago, which gets rid of the two paths. Also can you check your commit messages, I don't know if it's phab being weird, but they all start with "t/" in the phab UI, REPOSITORY R285 KCrash REVISION DETAIL https://phabricator.kde.org/D29811 To: jpalecek, #frameworks Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29034: Add systemd user service file for kded
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R297 KDED REVISION DETAIL https://phabricator.kde.org/D29034 To: broulik, #plasma, #frameworks, davidedmundson Cc: bruns, davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham
Request for plasma framework patch release
We seem to have a common crasher newly introduced in plasma-framework. A dozen reports in a few days. Can I ask for a plasma-framework 5.70.1. with c215c54eced5bd0b195c208dd72bb580e65f8fe4 cherry-picked. Sorry. David
D29742: Avoid potential disconnect of all signals in IconItem
This revision was automatically updated to reflect the committed changes. Closed by commit R242:c215c54eced5: Avoid potential disconnect of all signals in IconItem (authored by davidedmundson). REPOSITORY R242 Plasma Framework (Library) CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29742?vs=82830&id=82833 REVISION DETAIL https://phabricator.kde.org/D29742 AFFECTED FILES src/declarativeimports/core/iconitem.cpp To: davidedmundson, #plasma, ahiemstra Cc: ahiemstra, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29742: Avoid potential disconnect of all signals in IconItem
davidedmundson created this revision. davidedmundson added a reviewer: Plasma. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REVISION SUMMARY m_svgIcon can be null. disconnect(q, nullptr, nullptr, nullptr); would have pretty catastrophic consequences as it disconnects everything. Anyone listening for QObject::destroyed of IconItem for cleanup would no longer get anything. That could lead to obscure conditions. ShaderEffectSource watches for the source being destroyed for cleanup and we have a newly introduced crash with ShaderEffectSource that seems to come from this patch. CCBUG: 421170 TEST PLAN Uploading for someone to reproduce to test REPOSITORY R242 Plasma Framework (Library) BRANCH master REVISION DETAIL https://phabricator.kde.org/D29742 AFFECTED FILES src/declarativeimports/core/iconitem.cpp To: davidedmundson, #plasma Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29680: Fix modified line marker in kate minimap
This revision was automatically updated to reflect the committed changes. Closed by commit R39:f2b0dcdefea7: Fix modified line marker in kate minimap (authored by davidedmundson). REPOSITORY R39 KTextEditor CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29680?vs=82663&id=82717 REVISION DETAIL https://phabricator.kde.org/D29680 AFFECTED FILES src/view/kateviewhelpers.cpp To: davidedmundson, #kate, sars Cc: sars, ngraham, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, michaelh, bruns, demsking, cullmann, dhaumann
D29680: Fix modified line marker in kate minimap
davidedmundson added a comment. What about ktexteditor? REPOSITORY R39 KTextEditor REVISION DETAIL https://phabricator.kde.org/D29680 To: davidedmundson, #kate Cc: ngraham, kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, michaelh, bruns, demsking, cullmann, sars, dhaumann
D29680: Fix modified line marker in kate minimap
davidedmundson created this revision. davidedmundson added a reviewer: Kate. Herald added projects: Kate, Frameworks. Herald added subscribers: kde-frameworks-devel, kwrite-devel. davidedmundson requested review of this revision. REVISION SUMMARY Our pixmap is the size of the number of lines in the document. When rendering the pixel for the modified marker we want to take a ratio of currentline to lines in the pixmap. The height of the groove isn't relevant. TEST PLAN Create a 1 line empty document Added some line in the middle New line and orange dot appeared in the same place REPOSITORY R39 KTextEditor BRANCH master REVISION DETAIL https://phabricator.kde.org/D29680 AFFECTED FILES src/view/kateviewhelpers.cpp To: davidedmundson, #kate Cc: kwrite-devel, kde-frameworks-devel, rrosch, LeGast00n, cblack, domson, michaelh, ngraham, bruns, demsking, cullmann, sars, dhaumann
D29409: Add documentation line on KCM translations
davidedmundson added inline comments. INLINE COMMENTS > cblack wrote in configmodule.h:98 > You probably want to use backticks instead of quotes as this is referring to > something codewise. I don't understand. REPOSITORY R296 KDeclarative REVISION DETAIL https://phabricator.kde.org/D29409 To: davidedmundson Cc: cblack, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
D29668: Do not reject icon theme dir with invalid context/type.
davidedmundson added a comment. Seems sensible, given it's valid to have an empty context. I don't know enough about icons to know all possible ill effects. If there's no other comments in a few days consider this a "ship it!" REPOSITORY R302 KIconThemes REVISION DETAIL https://phabricator.kde.org/D29668 To: xuetianweng, #frameworks, dfaure, apol Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29292: Port KKeySequenceItem to QQC2
This revision was automatically updated to reflect the committed changes. Closed by commit R296:c730edc8dce4: Port KKeySequenceItem to QQC2 (authored by davidedmundson). REPOSITORY R296 KDeclarative CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D29292?vs=81557&id=82604 REVISION DETAIL https://phabricator.kde.org/D29292 AFFECTED FILES src/qmlcontrols/kquickcontrols/KeySequenceItem.qml tests/keysequencetest.qml To: davidedmundson, #plasma, davidre, ngraham Cc: ngraham, cblack, broulik, kde-frameworks-devel, LeGast00n, michaelh, bruns
D29511: Label: Add ping-pong logic
davidedmundson requested changes to this revision. davidedmundson added a comment. Plasmacomponents is deprecated please see Plasmacomponents3 then see the readme within that and put this somewhere else. 1. Label is a super super super common element we don't want to add any overhead instantiating a label. A new special class would be best 2. It can all be done in one SequentialAnimation, you don't need states. 3. You don't need to get the width again, we know this already from the other text properties. 4. This is broken for any text that's wrapped or elided REPOSITORY R242 Plasma Framework (Library) REVISION DETAIL https://phabricator.kde.org/D29511 To: patrickelectric, #plasma, #vdg, ognarb, davidedmundson Cc: davidedmundson, ognarb, cblack, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
D29503: Pixel align children of GridViewInternal
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R296 KDeclarative BRANCH master REVISION DETAIL https://phabricator.kde.org/D29503 To: fvogt, #frameworks, broulik, mart, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D25814: [KColorScheme] Add SeparatorColor
davidedmundson added a comment. Relevant link on that last comment: https://bugreports.qt.io/browse/QTBUG-63331 They actively seeked our opinion on colour roles REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D25814 To: ndavis, #frameworks, #vdg Cc: ahiemstra, broulik, manueljlin, alexde, ngraham, davidedmundson, filipf, cfeck, hpereiradacosta, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns
D29397: KPreviewJob : Support for DeviceRatioPixel
davidedmundson added a comment. > Allow users of KPreviewJob to request a devicePixelRatio for generated thumbnails. At the risk of asking a stupid question, why? As opposed to just having a width and height always be in device pixels. We're always working with pixmaps is there a reason to do anything with logical sizes? That's how I thought the current design worked. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D29397 To: meven, dfaure, broulik, #frameworks Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29409: Add documentation line on KCM translations
davidedmundson created this revision. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REPOSITORY R296 KDeclarative BRANCH master REVISION DETAIL https://phabricator.kde.org/D29409 AFFECTED FILES src/quickaddons/configmodule.h To: davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29374: UK, Scotland: Fix syntax error by adding category of Early May Bank Holiday
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R175 KHolidays REVISION DETAIL https://phabricator.kde.org/D29374 To: weisi, winterz, davidedmundson Cc: jriddell, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29371: KMainWindow: remove doc paragraph about KGlobal::ref usage
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R263 KXmlGui BRANCH master REVISION DETAIL https://phabricator.kde.org/D29371 To: dvratil, dfaure, #frameworks, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28498: [xdgoutput] Explicitly set version of server interface
davidedmundson abandoned this revision. davidedmundson added a comment. All these problems go away with KWaylandServer \o/ REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28498 To: davidedmundson, #kwin Cc: zzag, anthonyfieroni, apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29278: Port KWin to KWaylandServer
davidedmundson added a comment. > Hmm, I can't build kwin Hit the same thing, we've since fixed that (patch in kwayland-server) REPOSITORY R108 KWin BRANCH master REVISION DETAIL https://phabricator.kde.org/D29278 To: apol, #kwin, #plasma, #frameworks, davidedmundson Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29278: Port KWin to KWaylandServer
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R108 KWin BRANCH master REVISION DETAIL https://phabricator.kde.org/D29278 To: apol, #kwin, #plasma, #frameworks, davidedmundson Cc: zzag, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29292: Port KKeySequenceItem to QQC2
davidedmundson added inline comments. INLINE COMMENTS > broulik wrote in KeySequenceItem.qml:57 > Why is it the worst? It keeps us from having to hardcode magic numbers. See task. REPOSITORY R296 KDeclarative REVISION DETAIL https://phabricator.kde.org/D29292 To: davidedmundson, #plasma, davidre Cc: cblack, broulik, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
D29292: Port KKeySequenceItem to QQC2
davidedmundson added inline comments. INLINE COMMENTS > cblack wrote in KeySequenceItem.qml:57 > Are we able to use some form of units? Hardcoding this seems wrong. > Can we use the non-attached version here please since it's not likely It's the worst! > Are we able to use some form of units? Hardcoding this seems wrong. It's come up before, this isn't ideal, but there's no other consistent alternative. It's the convention followed elsewhere. Let's follow that up on https://phabricator.kde.org/T10873 > broulik wrote in KeySequenceItem.qml:58 > Is this `_tr` thing we could also improve (separately o/c)? We need to specify the domain, but you're right i18nd would work just as well and save a QObject REPOSITORY R296 KDeclarative REVISION DETAIL https://phabricator.kde.org/D29292 To: davidedmundson, #plasma, davidre Cc: cblack, broulik, kde-frameworks-devel, LeGast00n, michaelh, ngraham, bruns
D29292: Port KKeySequenceItem to QQC2
davidedmundson created this revision. davidedmundson added a reviewer: Plasma. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REVISION SUMMARY This implicitly fixes a bug where space is used in the shortcut item. Previously as QQC1 button was made up of multiple objects the key handling would be handled by an internal object before our filters. In QQC2 it's all one item, so our Keys handler takes precendence. TEST PLAN Added a test file Set the button to control+space, alt+4 Set the button to alt+space (this correctly showed a warning about a conflict) Confirmed tooltip worked correctly Used space to activate the button when we weren't recording. This someone still worked.. REPOSITORY R296 KDeclarative BRANCH master REVISION DETAIL https://phabricator.kde.org/D29292 AFFECTED FILES src/qmlcontrols/kquickcontrols/KeySequenceItem.qml tests/keysequencetest.qml To: davidedmundson, #plasma Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29231: Add keyboard_shortcuts_inhibit protocol
davidedmundson added inline comments. INLINE COMMENTS > zzag wrote in keyboard_shortcuts_inhibit_interface.cpp:21 > You've probably meant Q_DECL_HIDDEN, right? > > On an unrelated note: there are valid arguments against nested private > classes so it would be really nice if we revisit this topic in the new repo. yeah, that one > there are valid arguments against nested private classes so it would be > really nice if we revisit this topic in the new repo. Sure REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D29231 To: bport, zzag, davidedmundson, apol Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29231: Add keyboard_shortcuts_inhibit protocol
davidedmundson added a comment.
Let's wait for the new kwaylandserver repo before pushing.
But ++, looks good.
INLINE COMMENTS
> keyboard_shortcuts_inhibit_interface.cpp:21
> +
> +class KeyboardShortcutsInhibitorInterface::Private : public
> QtWaylandServer::zwp_keyboard_shortcuts_inhibitor_v1
> +{
Q_DECL_PRIVATE
> keyboard_shortcuts_inhibit_interface.cpp:35
> +
> +KeyboardShortcutsInhibitorInterface::Private::Private(wl_resource *resource,
> int id, SurfaceInterface *surface,
> + SeatInterface *seat,
It's not clear what resource this argument is referring to.
I think from reading the code it's the resource of the manager? At which point
"parentResource" would be a better name.
Or separate client, id, version args.
REPOSITORY
R127 KWayland
REVISION DETAIL
https://phabricator.kde.org/D29231
To: bport, zzag, davidedmundson, apol
Cc: romangg, crossi, kde-frameworks-devel, LeGast00n, cblack, michaelh,
ngraham, bruns
Re: Splitting KWayland
That is what I imagined. The protocols section contains some things we can strip down. We shouldn't host anything that's in wayland-protocols like text-input. Also I think there's some dead things like plasma-effects. But we can do that sort of thing anytime before the first release. David
D29256: [server] Introduce mapped() signal
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R127 KWayland BRANCH introduce-mapped-signal REVISION DETAIL https://phabricator.kde.org/D29256 To: zzag, #kwin, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Re: Splitting KWayland
On Tue, 28 Apr 2020, 07:24 Vlad Zahorodnii, wrote: > On 4/27/20 4:12 PM, David Edmundson wrote: > > I don't think we want to remove client or server tests on this one. As > > the client tests covered the server side too > > Hmm, does this mean we are going to keep both the client and the server > side in KWaylandServer? > No. We said we would build them against KWayland::Client With the slow migration for the protocols to be against the new approach. David > > Cheers, > Vlad > > >
Re: Splitting KWayland
On Mon, Apr 27, 2020 at 2:12 PM David Edmundson wrote: > > > On Mon, Apr 27, 2020 at 1:58 PM Aleix Pol wrote: > >> Hi, >> As discussed in the meeting last week, I've been looking into the split. >> >> Here's what I was thinking of, please tell me if there's something >> massively important I'm missing. >> >> The idea would be to start working on it after kwayland and other kf5 >> have been tagged next week (?). >> >> Something I was wondering too is that I guess the new repos should end >> up in invent? Although neither plasma or kf5 are there. >> So maybe not? >> > > Given the recent gitlab status update from bshah, that'll be happening > soon. > >> >> There's a couple of questions below as well, thoughts would be welcome >> >> Aleix >> >> git clone kde:kwayland >> mv kwayland plasma-wayland-protocols >> cd plasma-wayland-protocols >> git rm -r autotests/ docs/ tests/ src/ >> # fix build >> # close https://phabricator.kde.org/T13024 > > > And changing it so we install the KDE specific protocol files > > >> git clone kde:kwayland >> mv kwayland/ kwayland-server >> > > git rm -r src/client/ >> # namespace KWayland::Server -> namespace KWaylandServer >> # fix build >> # remove server tests? >> > > I don't think we want to remove client or server tests on this one. As the > client tests covered the server side too > Even if it does mean some short-term duplication. > > >> # see to move things to KWin? >> > > I don't know which things you were referring to, but I'd suggest we keep > things simple. > >> >> # close https://phabricator.kde.org/T13025 > > > > >> git clone kde:kwayland >> > > git rm src/client/protocols and use the installed ones from the first repo > > >> # deprecate all KWayland::Server > > > We need a big README in the src/server. IMO it's not worth the hassle of > changing the header files. > > # remove server tests? >> > Yeah, can do. > > > > > >
Re: Splitting KWayland
On Mon, Apr 27, 2020 at 1:58 PM Aleix Pol wrote: > Hi, > As discussed in the meeting last week, I've been looking into the split. > > Here's what I was thinking of, please tell me if there's something > massively important I'm missing. > > The idea would be to start working on it after kwayland and other kf5 > have been tagged next week (?). > > Something I was wondering too is that I guess the new repos should end > up in invent? Although neither plasma or kf5 are there. > So maybe not? > Given the recent gitlab status update from bshah, that'll be happening soon. > > There's a couple of questions below as well, thoughts would be welcome > > Aleix > > git clone kde:kwayland > mv kwayland plasma-wayland-protocols > cd plasma-wayland-protocols > git rm -r autotests/ docs/ tests/ src/ > # fix build > # close https://phabricator.kde.org/T13024 And changing it so we install the KDE specific protocol files > git clone kde:kwayland > mv kwayland/ kwayland-server > git rm -r src/client/ > # namespace KWayland::Server -> namespace KWaylandServer > # fix build > # remove server tests? > I don't think we want to remove client or server tests on this one. As the client tests covered the server side too Even if it does mean some short-term duplication. > # see to move things to KWin? > I don't know which things you were referring to, but I'd suggest we keep things simple. > > # close https://phabricator.kde.org/T13025 > git clone kde:kwayland > git rm src/client/protocols and use the installed ones from the first repo > # deprecate all KWayland::Server We need a big README in the src/server. IMO it's not worth the hassle of changing the header files. # remove server tests? > Yeah, can do.
D28882: Create protocol to manage video feeds
davidedmundson added inline comments. INLINE COMMENTS > screencast.xml:46 > + > + > + add type = "destructor" so that clients calling this release the resource REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28882 To: apol, #kwin, jgrulich, davidedmundson Cc: davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28883: Add wrapper for wl_global_remove
This revision was automatically updated to reflect the committed changes. Closed by commit R127:c557cdba3a73: Add wrapper for wl_global_remove (authored by davidedmundson). REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28883?vs=80279&id=81103 REVISION DETAIL https://phabricator.kde.org/D28883 AFFECTED FILES autotests/client/test_wayland_blur.cpp src/server/global.cpp src/server/global.h To: davidedmundson, #plasma, apol Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28470: [PlasmaCore.IconItem] Refactor source handling for different types
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/D28470 To: kmaterka, #plasma, broulik, apol, davidedmundson, #frameworks Cc: mart, davidre, cblack, kde-frameworks-devel, #plasma, LeGast00n, michaelh, ngraham, bruns
Re: Problems in KWayland causes by API and ABI compatibility promises
We had a meeting. It resulted in some final action decisions. These will affect the kwayland folder in frameworks. The meeting was attended by: Kevin Ottens, Vlad Zahorodnii, Aleix Pol, Myself, Benjamin Port who all approved the plan. *Protocols:* We make a new repo. It will contain just protocol XML files. plasma-wayland-protocols - target is kdesupport. Existing protocols remain exactly the same, just moved New protocols follow upstream wayland-protocols naming scheme using the "zkde_" prefix *Client - short term:* We leave things unchanged. Kwin tests will continue to use KWayland::Client as is, the upcoming fork KWayalndServer (mentioned in a bit) will stil use it. If something comes up that requires an ABI break or new classes from client (XdgShell for example) we deal with it locally in the relevant repo as per the longer term plan. We slowly migrate to the long term plan. *Client - long term direction:* If something is used in N places - we should abstract things in a high level API like KWindowSystem. If it's used in 1 place, we go native with QtWayalndClientExtension and the generated classes. Autotests for the server should use generated low-level classes, see for example the currently merged tabletmanager autotest. If we need something in kwin and KWaylandServer, we just do it in both. Client will still have a KF6 library for doing super core stuff such as ConnectionThread, wl_surface, buffers etc. It won't contain all the extra protocols. At KF6 we rename namespace and repo to KWaylandClient. *Server - short term:* We make a new repo. It forks existing KWayland::server classes from framework's kwayland + the autotests. This goes into kwaylandserver - put in workspace - no ABI/API guarantees, but released in sync with kwin - .so bumps each time - new namespace (i.e KWaylandServer) - Institute a complete freeze of the server folder in KF5 *Server - long term direction:* - Unit tests migrate to testing against just generated code for the extra protocols - Drop Interface suffix in class names. - Drop from KF6 I'm very hopefully this will really help spur our kwin and wayland efforts as well as prepare us for KF6. Regards David
D28882: Create protocol to manage video feeds
davidedmundson requested changes to this revision. davidedmundson added a comment. This revision now requires changes to proceed. In future, it might be faster to put up just the interface xml for review first. -- In terms of wayland protocols this is non-standard. All clients get a list of available sources. On bind they get all all available sources via addSource. Additional sources are new events. That part's fine. The part with nodeID is unusual. It's convention (though not technically the law) that globals broadcast the same thing to all bound resources. ClientA requests create. All clients get a created event There's no way to tie a created or failed to the original request Client A and B can both connect to the same source, yet either can call close. If we're doing a waland protocol I would have expected: ScreenCastInterface - global event: source_added event: done request: get_stream (returns a ScreenStream object) ScreenStream - resource event: created event: failed event: closed (closed by external sources, clients should now release the stream resource) request: release (closes the stream if applicable, is also of type destructor) INLINE COMMENTS > screencast.xml:16 > + > + > + Typically events are like signals, so would be called "source_added" Convention is also lower_snake_case > screencast.xml:31 > + > + > + this is racey with create. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28882 To: apol, #kwin, jgrulich, davidedmundson Cc: davidedmundson, romangg, zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28355: Introduce function ecm_install_configured_file
davidedmundson added a dependent revision: D28305: Systemd Startup. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D28355 To: davidedmundson Cc: apol, kossebau, pino, kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29034: Add systemd user service file for kded
davidedmundson added a dependent revision: D28305: Systemd Startup. REPOSITORY R297 KDED REVISION DETAIL https://phabricator.kde.org/D29034 To: broulik, #plasma, #frameworks Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29035: Install service files for kwin
davidedmundson added a dependent revision: D28305: Systemd Startup. REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D29035 To: broulik, #plasma, #frameworks Cc: davidedmundson, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D29051: Add ecm_generate_dbus_service_file
davidedmundson added a dependent revision: D28305: Systemd Startup. REPOSITORY R240 Extra CMake Modules REVISION DETAIL https://phabricator.kde.org/D29051 To: broulik, #frameworks, davidedmundson, kossebau, kfunk, habacker Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
D29102: Prefer QIcon::pixmap(QWindow*, ...) overload
davidedmundson accepted this revision. davidedmundson added a comment. This revision is now accepted and ready to land. Yeah, size is in logical pixels. Multiplying doesn't make sense. I'm sure more high DPI bugs are caused by clients trying to be clever. REPOSITORY R242 Plasma Framework (Library) BRANCH master REVISION DETAIL https://phabricator.kde.org/D29102 To: apol, #plasma, #frameworks, davidedmundson Cc: davidedmundson, ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns
D29054: [Wayland] Add to PlasmaWindowManagement protocol windows stacking order
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D29054 To: bport, zzag, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29054: [Wayland] Add to PlasmaWindowManagement protocol windows stacking order
davidedmundson added inline comments.
INLINE COMMENTS
> plasma-window-management.xml:77
> +
> +This event will be sent when stacking order changed
> +
we also need to send it on bind
> plasma-window-management.xml:83
>
>
>
Can we change them all at once.
> plasmawindowmanagement_interface.cpp:167
> +{
> +wl_array wlIds;
> +
This needs a
wl_resource_get_version(resource) <
ORG_KDE_PLASMA_SEND_STACK_SOMETHING_SOMETHING_SINCE_VERSION
A user could be using a flatpak or something with a bundled kwayland that's out
of date with kwin. At that point we don't want the client to receive this event
or it will explode.
> plasmawindowmanagement_interface.cpp:234
> }
> }
>
We need to send the stacking order here, this way if a client connects and
nothing changes, they still have the right order.
REPOSITORY
R127 KWayland
REVISION DETAIL
https://phabricator.kde.org/D29054
To: bport, zzag, davidedmundson
Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D29035: Install service files for kwin
davidedmundson added a comment. I'm not sure why we set KillMode Though I'm favour of merging then tweaking some of this, the service files won't do anything till someone pulls them in. Don't push before relevant ECM and relevant p-w patch is in INLINE COMMENTS > plasma-kwin_x11.service.in:3 > +Description=KDE Window Manager > +Wants=plasma-kcminit.service > + This should be After= rather than Wants= REPOSITORY R108 KWin REVISION DETAIL https://phabricator.kde.org/D29035 To: broulik, #plasma, #frameworks Cc: davidedmundson, kwin, Orage, cacarry, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, mkulinski, ragreen, jackyalcine, iodelay, crozbo, bwowk, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, hardening, romangg, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D28499: [LauncherJobs] Emit description
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D28499 To: broulik, #frameworks, davidedmundson Cc: ngraham, kde-frameworks-devel, LeGast00n, cblack, michaelh, bruns
D29034: Add systemd user service file for kded
davidedmundson added a comment. We also need to change the installed DBus service file so that we link the two in the unlikely event that kded is called I need to either update the dbus generator macro, or we skip the macro and put the service file in here, the old way INLINE COMMENTS > broulik wrote in plasma-kded.service.in:5 > Didn't we have a `KDE_INSTALL_BIN_DIR` or something? @CMAKE_INSTALL_FULL_BINDIR@ > plasma-kded.service.in:6 > +ExecStart=@CMAKE_INSTALL_PREFIX@/bin/kded5 > +BusName=org.kde.kded5 Slice=session.slice REPOSITORY R297 KDED REVISION DETAIL https://phabricator.kde.org/D29034 To: broulik, #plasma, #frameworks Cc: davidedmundson, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
Re: Problems in KWayland causes by API and ABI compatibility promises
On Thu, Apr 16, 2020 at 10:26 PM David Edmundson wrote: > > > Given Doodle's take forever and everyone's probably quarantined > > anyway, I propose we do it just after the Monday Plasma meeting. If > > someone is eager to share an opinion and can't make that, message here > > and we'll choose something more formally. > > That didn't really work out. Doodle it is! > > https://doodle.com/poll/k8gzdvwhgibn7hma > > Then we'll meet in #kwin on IRC Decision made, lets have an IRC meeting Thursday 17.30 European Time (please adjust for your timezone, or see Doodle). Let's all agree on a decision (though I think there's some direction) by the end of that meeting with some action plans for both client and server both shortterm and long term. David
Re: Problems in KWayland causes by API and ABI compatibility promises
> > The slight twist on that which we need to be wary of is that client > > code will return shared objects if you request a > > KWaylandClient::PlasmaShellSurface::get(window()) > > for the same window from two places you'll get the same PlasmaShell > > instance returned - and therefore the same wl_resource. > > If we hypothetically had a kwayland2::client also have a > > plasmashellsurface::get() method we would have two plasma_shellsurface > > wl_resources's for the same wl_surface which is a protocol error and > > our client will get violently killed. > > Honestly you lost me here. :-) Mixing libs for different protocols within one client is ok. Mixing libs for the same protocol within one client is bad. Hopefully the other kwin people will understand what I meant. David
D27540: KCModule: Indicate when a setting has been changed from the default or previous value
davidedmundson accepted this revision. davidedmundson added a comment. This revision is now accepted and ready to land. Assuming VDG are happy, go for it. REPOSITORY R265 KConfigWidgets REVISION DETAIL https://phabricator.kde.org/D27540 To: ervin, ngraham, davidedmundson, meven, crossi, bport, #vdg, ndavis, broulik Cc: alexde, ndavis, iasensio, davidre, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D27840: Introduce SettingState* elements to ease KCM writing
davidedmundson accepted this revision. REPOSITORY R296 KDeclarative REVISION DETAIL https://phabricator.kde.org/D27840 To: ervin, crossi, hchain, meven, bport, davidedmundson, mart, ngraham, #frameworks, #plasma Cc: broulik, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D27841: Port desktoptheme, icons and workspace KCMs to SettingStateBinding
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R119 Plasma Desktop REVISION DETAIL https://phabricator.kde.org/D27841 To: ervin, crossi, hchain, meven, bport, davidedmundson, mart, ngraham, #frameworks, #plasma, #vdg Cc: plasma-devel, Orage, LeGast00n, The-Feren-OS-Dev, cblack, jraleigh, zachus, fbampaloukas, ragreen, ZrenBot, ngraham, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
D28892: [autotests] Optimistic attempt to fix RemoteAccessTest reilability
davidedmundson added a comment. > This seems super complicated. It is :D REPOSITORY R127 KWayland REVISION DETAIL https://phabricator.kde.org/D28892 To: davidedmundson, #kwin, zzag Cc: zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28892: [autotests] Optimistic attempt to fix RemoteAccessTest reilability
This revision was automatically updated to reflect the committed changes. Closed by commit R127:1b1412943b6b: [autotests] Optimistic attempt to fix RemoteAccessTest reilability (authored by davidedmundson). REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28892?vs=80312&id=80390 REVISION DETAIL https://phabricator.kde.org/D28892 AFFECTED FILES autotests/client/test_remote_access.cpp To: davidedmundson, #kwin, zzag Cc: zzag, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28919: Drop delayed second phase
davidedmundson added a comment. > @davidedmundson did some bootchart that showed startup is actually faster without this It was probably just noise as it wasn't a full average of N tests, just 2 clean boots. However ksplash removed 100ms earlier. I can attach if needed. As for the patch, +1 REPOSITORY R297 KDED REVISION DETAIL https://phabricator.kde.org/D28919 To: broulik, #plasma, dfaure, davidedmundson Cc: kde-frameworks-devel, davidedmundson, LeGast00n, cblack, michaelh, ngraham, bruns
D28900: Fix wayland scanner warnings
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R240 Extra CMake Modules BRANCH master REVISION DETAIL https://phabricator.kde.org/D28900 To: apol, #build_system, #kwin, #frameworks, davidedmundson Cc: kde-frameworks-devel, kde-buildsystem, LeGast00n, cblack, bencreasy, michaelh, ngraham, bruns
Re: Problems in KWayland causes by API and ABI compatibility promises
On Wed, Apr 8, 2020 at 5:10 PM Kevin Ottens wrote: > > Hello, > > On Wednesday, 1 April 2020 14:04:10 CEST David Edmundson wrote: > > Here is a list of active uses of the KWayland::Client API. > > > > frameworks > > plasma-framework (for window positioning) > > > > apps: > > spectacle (for window positioning) > > kdeconnect-kde (for fake input) > > yakuake (for window positioning) > > > > extragear > > latte-dock (for window positioning, custom shadow (which could be > > ported already) and windowmanagement) > > The part of the list above makes me wonder, shouldn't the window positioning > and windowmanager features be on KWindowSystem? Yeah, doing that will resolve 90% of the client cases. In general for things like blur and everything the slightly higher level abstraction is working out better as we can abstract X and wayland in one go, which really helps the client code. Also, it's worth really clarifying that in absolutely any proposal KWayland as-is can't go away, so clients using that will still function. The slight twist on that which we need to be wary of is that client code will return shared objects if you request a KWaylandClient::PlasmaShellSurface::get(window()) for the same window from two places you'll get the same PlasmaShell instance returned - and therefore the same wl_resource. If we hypothetically had a kwayland2::client also have a plasmashellsurface::get() method we would have two plasma_shellsurface wl_resources's for the same wl_surface which is a protocol error and our client will get violently killed. > > workspace: > > kwin unit tests > > libkscreen > > breeze (till Qt5.15) > > oxyen (till Qt5.15) > > xdg-desktop-portal > > kinfocenter > > plasma-workspace > > plasma-nano > > kscreenlocker > > powerdevil > > kwayland-integration (the backend for kwindowsystem) > > plasma-phone-components > > plasma-integration > > I think the above is less of an issue, right? Because workspace would have a > copy of KWayland which could be shared with whatever stability constraints > needed. It means it has to stay as an exported workspace lib, but yeah it wouldnt' be a problem.
Re: Problems in KWayland causes by API and ABI compatibility promises
> Given Doodle's take forever and everyone's probably quarantined > anyway, I propose we do it just after the Monday Plasma meeting. If > someone is eager to share an opinion and can't make that, message here > and we'll choose something more formally. That didn't really work out. Doodle it is! https://doodle.com/poll/k8gzdvwhgibn7hma Then we'll meet in #kwin on IRC David
D28892: [autotests] Optimistic attempt to fix RemoteAccessTest reilability
davidedmundson updated this revision to Diff 80312. davidedmundson added a comment. update REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28892?vs=80311&id=80312 BRANCH master REVISION DETAIL https://phabricator.kde.org/D28892 AFFECTED FILES autotests/client/test_remote_access.cpp To: davidedmundson, #kwin Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28892: [autotests] Optimistic attempt to fix RemoteAccessTest reilability
davidedmundson updated this revision to Diff 80311. davidedmundson added a comment. spelling REPOSITORY R127 KWayland CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28892?vs=80310&id=80311 BRANCH master REVISION DETAIL https://phabricator.kde.org/D28892 AFFECTED FILES autotests/client/test_remote_access.cpp To: davidedmundson, #kwin Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28892: [autotests] Optimistic attempt to fix RemoteAccessTest reilability
davidedmundson created this revision. davidedmundson added a reviewer: KWin. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REVISION SUMMARY In this test we are waiting on 4 events. 2 things via 2 threads. It was unstable. This patch avoids hardcoding a bunch of ifs() handling recieving different orders, by waiting for both events. We can't use QTRY_COMPARE as ConnectionThread does magic things with QCoreApplication::eventDispatcher which don't work quite the same. This is a bit of a shot in the dark. It passes 100% of the time locally, lets see what CI manages to do :) TEST PLAN Ran test :) REPOSITORY R127 KWayland BRANCH master REVISION DETAIL https://phabricator.kde.org/D28892 AFFECTED FILES autotests/client/test_remote_access.cpp To: davidedmundson, #kwin Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28883: Add wrapper for wl_global_remove
davidedmundson created this revision. davidedmundson added a reviewer: Plasma. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. davidedmundson requested review of this revision. REVISION SUMMARY Removes the Global from the registry, but does not delete the underlying wl_global Removal of a global is racey in wayland. A client could be trying to bind at that moment. Typically globals are static for the lifespan of the compositor, however there are exceptions For those cases this call will can remove the global from the registry, but still keep the wl_global instance alive and handling bind requests. The compositor can then remove the Global wrapper (this object) deleting the wl_global after an arbitrary delay or keep it around for re-use for the duration of the compositor. TEST PLAN Unit test Made blur global outlive BlurEffect - no longer disconnects plasma on config changes REPOSITORY R127 KWayland BRANCH master REVISION DETAIL https://phabricator.kde.org/D28883 AFFECTED FILES autotests/client/test_wayland_blur.cpp src/server/global.cpp src/server/global.h To: davidedmundson, #plasma Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D24956: Consider desktop files with NoDisplay attribute
davidedmundson accepted this revision. davidedmundson added a comment. This revision is now accepted and ready to land. > [14:12] DavidRedondo1: my understanding is that a system might ship "konsole opens with control+t". The UI allows you to remove that. This would remove the entry in kglobalshortcutsrc, but because it's still in the system defaults file as soon as you log in again it'll add it back [14:25] d_ed, fvogt Apparently the runtime writes the hidden thing when a component is cleanedUp https://cgit.kde.org/kglobalaccel.git/tree/src/runtime/kserviceactioncomponent.cpp#n135 [14:27] Does that fail or something when the file is not writeable? [14:31] I think it fails [14:31] I just tested it if it is indeed broken...then we may as well just merge this. REPOSITORY R268 KGlobalAccel BRANCH master REVISION DETAIL https://phabricator.kde.org/D24956 To: meven, mart, #plasma, fvogt, apol, davidedmundson Cc: davidedmundson, davidre, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D24956: Consider desktop files with NoDisplay attribute
davidedmundson added a comment. kglobalshortcutseditor.cpp needs updating to match I think you're right with your reasoning about NoDisplay, but we do want something to be able to mask system files. From the spec should we be checking Hidden= ? REPOSITORY R268 KGlobalAccel REVISION DETAIL https://phabricator.kde.org/D24956 To: meven, mart, #plasma, fvogt, apol Cc: davidedmundson, davidre, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D20655: Use generated DBus interface
davidedmundson requested changes to this revision. davidedmundson added a comment. This revision now requires changes to proceed. We copy udisks xml already. I don't think it ends up any better. Otherwise we have a compile time dep on a runtime plugin, which inevitably means we need to make it optional which only introduces more real-world bugs. It also means future devs know what we were compiled against. Marking as requesting changes for the extra include, but personally I think it's generally good to go. REPOSITORY R245 Solid REVISION DETAIL https://phabricator.kde.org/D20655 To: broulik, #frameworks, davidedmundson, bruns Cc: apol, kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns
D28470: [PlasmaCore.IconItem] Refactor source handling for different types
davidedmundson added a comment. Note there's a unit test for IconItem worth running if you haven't already. The refactor in general makes sense - it's a lot cleaner. Though I'm not sure what our super long term KF6 plan for IconItem is, it'll definitely be changing quite a bit. REPOSITORY R242 Plasma Framework (Library) REVISION DETAIL https://phabricator.kde.org/D28470 To: kmaterka, #plasma, broulik, apol, davidedmundson Cc: mart, davidre, cblack, kde-frameworks-devel, #plasma, LeGast00n, michaelh, ngraham, bruns
D28697: Also relase the window in the destructor
davidedmundson accepted this revision. This revision is now accepted and ready to land. REPOSITORY R296 KDeclarative BRANCH release (branched from master) REVISION DETAIL https://phabricator.kde.org/D28697 To: davidre, broulik, #frameworks, davidedmundson Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns
