Re: Post-MegaRelease projects
I plan on working on libei integration into KWin and hooking it up in the portal David
Re: Post-MegaRelease projects
On 2024-02-22, Nate Graham wrote: > I've started pondering post-megarelease projects. We've spent so long on > porting and bugfixing that I think it might be useful to shift gears to > feature work, and I'd like to brainstorm potential large-scale projects > and gauge the level of interest in putting resources into them soon. A bit more from the devops end that I'd love to see people tackle: - Ensure frameworks and app unit tests interacting with windows can run on Windows. More details: The following fails on our windows CI https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp I find it weird that we are spending resources on putting things in the windows store and making apps available on windows, but we can't actually have passing tests in our CI. - Find a way to run unit tests on android CI. - Make autotests guarding on all our CI's. - Clazy and clang-tidy and cppcheck on all our repositories in CI /Sune
Re: Post-MegaRelease projects
El divendres, 23 de febrer de 2024, a les 11:12:16 (CET), Sune Vuorela va escriure: > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > > - Find a way to run unit tests on android CI. > > - Make autotests guarding on all our CI's. > > - Clazy and clang-tidy and cppcheck on all our repositories in CI And qmllint for the apps that use QML (dreaming is free, right?) Cheers, Albert > > /Sune
Re: Post-MegaRelease projects
On Thu, Feb 22, 2024 at 4:57 PM Nate Graham wrote: > > Hello everyone, > > Congrats to the entire KDE community on the impending launch of the KDE > 6 MegaRelease! I'm so impressed with how folks came together to make it > amazing. It's a very impressive release and I think people are gonna > love it. > > I've started pondering post-megarelease projects. We've spent so long on > porting and bugfixing that I think it might be useful to shift gears to > feature work, and I'd like to brainstorm potential large-scale projects > and gauge the level of interest in putting resources into them soon. > > Here are some ideas of mine to get the creative juices started: > > * David's input method playground stuff [1] is amazing and needs to be > developed and productized > * GNOME's Libadwaita app platform has been a runaway success for them; > evaluate our offerings in comparison and see what we can do better I think it really helps that they got their act together about their developer documentation and experience. It's coherent and easy to follow all from https://developer.gnome.org/. We've started building an equivalent at https://develop.kde.org/, but we're not quite there yet. Additionally, my last go-around with KDevelop didn't exactly get me "started" with making a KDE application like how GNOME Builder does with its templates. This problem is going to be much worse with KDE Platform 6, since KDevelop has not yet been updated for it. > * Unified theming infrastructure for KDE apps, GTK apps, and Plasma. > ** Relatedly: QML/JS in themes is dangerous; move away from it I've heard from people over the years that they'd love to have easy SVG/CSS style theming that has complete coverage (like Kvantum but actually works everywhere), do we have a task to track making this possible? > * Start adding release notes to our apps' AppStream metadata [2] > * Finish up and ship the new Breeze icons > * HIG is outdated and mostly ignored, and needs an overhaul to make it > useful Yes, I've noticed that it's somewhat inconsistent with what we do for KDE apps these days... -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Post-MegaRelease projects
Am Freitag, 23. Februar 2024, 12:05:13 CET schrieb Paul Brown: > On Friday, 23 February 2024 09:49:18 CET David Redondo wrote: > > libei > > What is this, David? > It is for emulated input https://libinput.pages.freedesktop.org/libei/ (negotiated via the portal) It would make thing like input-leap work on Wayland https://github.com/input-leap/input-leap David
[announcement] ATTENTION PLASMA THEME, WIDGET, & ADD-ON DEVELOPERS
Apologies for the all caps, but now that I have your attention :) With Plasma 6, various breaking changes affect existing Plasma look-and-feel themes, widgets, and ad-ons. We love all your stuff, but you need to port it for it to work in Plasma 6. We have created some handy, easy-to-follow guides: https://develop.kde.org/docs/plasma/widget/porting_kf6/ https://develop.kde.org/docs/plasma/theme/theme-porting-to-plasma6/ Porting is quite straightforward and should not take you long. Keep our users happy! Port your stuff! :) Cheers, Joseph (H/t Paul Brown and Nate Graham for the above announcement) -- Joseph P. De Veaugh-Geiss KDE Internal Communications & KDE Eco Community Manager OpenPGP: 8FC5 4178 DC44 AD55 08E7 DF57 453E 5746 59A6 C06F Matrix: @joseph:kde.org Generally available Monday-Thursday from 10-16h CET/CEST. Outside of these times it may take a little longer for me to respond. KDE Eco: Building Energy-Efficient Free Software! Website: https://eco.kde.org Mastodon: @be4foss@floss.social
Re: Post-MegaRelease projects
On Fri, Feb 23, 2024 at 8:06 AM Carl Schwan wrote: > > * Rework our online account integration > > An idea I have is to move away from KAccounts/signond/account-sso since it's a > standard that is used only by anyway and instead provide Qt Plugins that setup > Akonadi/NeoChat/Nextcloud/Tokodon/GDrive/ here>/... and are provided by the app themselves so that we don't have to > duplicate all the login logic in the app and in the online account KCM. > signond/accounts-sso is also used by Pantheon/elementary OS, so it's not just us. That said, GOA (GNOME's equivalent) is also in a bit of disarray too... https://andyholmes.ca/posts/goa-and-stf-part-1/ -- 真実はいつも一つ！/ Always, there's only one truth!
Re: Post-MegaRelease projects
I wouldn't mind working on the high-contrast accessibility mode toggle, since we have now unified all the contrast values for separators. - Akseli On Thursday 22 February 2024 23:57:07 EET Nate Graham wrote: > Hello everyone, > > Congrats to the entire KDE community on the impending launch of the KDE > 6 MegaRelease! I'm so impressed with how folks came together to make it > amazing. It's a very impressive release and I think people are gonna > love it. > > I've started pondering post-megarelease projects. We've spent so long on > porting and bugfixing that I think it might be useful to shift gears to > feature work, and I'd like to brainstorm potential large-scale projects > and gauge the level of interest in putting resources into them soon. > > Here are some ideas of mine to get the creative juices started: > > * David's input method playground stuff [1] is amazing and needs to be > developed and productized > * GNOME's Libadwaita app platform has been a runaway success for them; > evaluate our offerings in comparison and see what we can do better > * Unified theming infrastructure for KDE apps, GTK apps, and Plasma. > ** Relatedly: QML/JS in themes is dangerous; move away from it > * Start adding release notes to our apps' AppStream metadata [2] > * Finish up and ship the new Breeze icons > * HIG is outdated and mostly ignored, and needs an overhaul to make it > useful > * Telemetry system has not proved to be very useful and needs an overhaul > * store.kde.org is full of low-quality or broken content; make a push > for KDE people to take ownership of content moderation, QA, etc. Also > any relevant and needed tech improvements > * Our virtual keyboard situation is not great and needs focused work > * KWallet needs an overhaul > * Have KWin (optionally) remember window positions on Wayland > * Build a "System misconfiguration detection hub" app [3] > > Feel free to discuss, and propose your own! > > Nate > > > > [1] > https://blog.davidedmundson.co.uk/blog/new-ideas-using-wayland-input-methods > / [2] https://github.com/ximion/appstream/issues/354 > [3] https://invent.kde.org/plasma/plasma-workspace/-/issues/64
KF6 applet porting: declarative QML replacements for DataEngines?
Hi all, I recently ported an applet [1] from KF5 to KF6. As part of this, I changed a PlasmaCore.DataSource to Plasma5Support.DataSource. This data engine provides a source model for a KSortFilterProxyModel, which feeds a ScrollView. The README for the Plasma5Support project [2] says > Dataengine support is not in the kf6 version of plasma anymore. Dataengines should be migrated to QML imports... Additionally, [3] describes them as "a piece of tech from the KDE4 era", and says "we don't promise compatibility throughout Plasma 6". I'm wondering whether these statements are supposed to apply to applet developers (at least for new development), and if so, whether there is guidance on appropriate declarative replacements for the various engines. Is there a Phabricator task for exposing the models in the various engines to QML? Do applet developers need to worry about API breakage during the Plasma 6 era? To be specific, I'm using the "places" engine, which exposes data from KIO's KFilePlacesModel. [4] Looking at the various official Plasma applets that use this model, they appear to be bikeshedding their own C++ implementations, e.g. [5] for the folder applet, or [6] for Kickoff / Kicker. Best, Adam [1] https://github.com/dfaust/plasma-applet-places-widget [2] https://invent.kde.org/plasma/plasma5support [3] https://phabricator.kde.org/T13315 [4] https://api.kde.org/frameworks/kio/html/classKFilePlacesModel.html [5] https://invent.kde.org/plasma/plasma-desktop/-/blob/master/containments/desktop/plugins/folder/placesmodel.cpp [6] https://invent.kde.org/plasma/plasma-workspace/-/blob/master/applets/kicker/plugin/computermodel.cpp
Re: Post-MegaRelease projects
On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela wrote: > On 2024-02-22, Nate Graham wrote: > > I've started pondering post-megarelease projects. We've spent so long on > > porting and bugfixing that I think it might be useful to shift gears to > > feature work, and I'd like to brainstorm potential large-scale projects > > and gauge the level of interest in putting resources into them soon. > > A bit more from the devops end that I'd love to see people tackle: > > - Ensure frameworks and app unit tests interacting with windows can run >on Windows. >More details: The following fails on our windows CI >https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp >I find it weird that we are spending resources on putting things in >the windows store and making apps available on windows, but we can't >actually have passing tests in our CI. > This unfortunately will not be easy to solve. One of the key things that we've learned out of doing CI, as has been showcased by FreeBSD in particular, is that the builders need to be ephemeral - that is only around for the build in question that is being run. We're currently accomplishing this by using containers - via Podman (for Linux/Android/FreeBSD) and Docker (for Windows). Containers also offer us the advantage of allowing people to easily reproduce the CI environment on their local system without too much trouble. For Windows however, Microsoft has limited the container stack to not allow anything GUI related to work. The underlying libraries may be there, but the equivalent display server components are not operational. To complicate things further, on Windows certain permissions are restricted to the interactive console and are not possible to do as either a scheduled task or as a system service. Usage of existing Windows automation frameworks such as Powershell Remoting or SSH will therefore not work if we want things to perfectly replicate a end user environment - because those will run the command(s) as part of a non-interactive session (even if the user we connect as is the same one logged in on the desktop console). Resolving this will therefore not only require running full sized Windows VMs (on an ephemeral basis to avoid the recently resolved issues that used to plague FreeBSD), but would also need the VM to automatically login and spawn an agent as part of the interactive desktop session that we would connect to in order to run the CI tests. The spawning of a VM would require refactoring the setup of our poor CI workers (again - after they were only just recently completely rebuilt to allow the transition to Podman to fix flatpak-builder) to make use of something like: - https://forum.gitlab.com/t/custom-executor-into-windows-vm-using-linux-kvm-libvirt/72713/5 - https://docs.gitlab.com/runner/executors/custom_examples/libvirt.html We would still have to write the agent that receives our commands (something like https://gist.github.com/cschwede/3e2c025408ab4af531651098331cce45 maybe) We would still have to solve the issue of how to share disk images among our nodes so they were built (ideally would be able to use Gitlab's Container Registry for this, which is something Tart can do - Tart being a virtualisation management utility for ARM based Macs), as well as automating the installation of the various OSes we need to run this way. See https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/automate-windows-setup?view=windows-11 for some notes on that for Windows. The big downside to all of that of course is that the worker nodes would take longer to startup, and it would make sharing build artifacts much more difficult and/or less efficient. > > - Find a way to run unit tests on android CI. > Likewise, this is very non-trivial - from my understanding our tooling currently for building Android software is centered around it all being cross compiled rather than being built on the native architecture it will be run on. Naturally tests cannot be run (unless you emulate, which I guess we could consider...) if the CPU architectures are not compatible. Even if you emulate though, I imagine we would need to provide a full Android system setup (including all of it's relevant bits of system infrastructure, such as it's display server DisplayFlinger) in order for tests to truly be of use. The path of least resistance is probably by making use of Google's existing Android emulator - although i've no idea how you would tie that into CI. We would need to have our build chains ready to build on a native system before we could think about this I think. Building Android x86/x64 wouldn't cover things off properly due as it won't reflect the actual CPUs being used on end-user devices (and ARM processors can expose issues that don't happen on x86/x64 based systems) > > - Make autotests guarding on all our CI's. > > - Clazy and clang-tidy and cppcheck on all our repositories in CI > > /Sune > Hopefully
Re: Post-MegaRelease projects
Priority from high to low: - Push the test coverage in plasma-desktop and plasma-workspace to above 20%. Current: 19%/18% - Refactor the clipboard backend to use SQLite - Accessibility widget and refactored Accessibility KCM - Port the powermanagement dataengine - Time-based dynamic wallpapers
Re: Post-MegaRelease projects
On Sat, 2024-02-24 at 16:31 +1300, Ben Cooksley wrote: > On Fri, Feb 23, 2024 at 11:12 PM Sune Vuorela > wrote: > > On 2024-02-22, Nate Graham wrote: > > > I've started pondering post-megarelease projects. We've spent so > > long on > > > porting and bugfixing that I think it might be useful to shift > > gears to > > > feature work, and I'd like to brainstorm potential large-scale > > projects > > > and gauge the level of interest in putting resources into them > > soon. > > > > A bit more from the devops end that I'd love to see people tackle: > > > > - Ensure frameworks and app unit tests interacting with windows > > can run > > on Windows. > > More details: The following fails on our windows CI > > > > https://invent.kde.org/sune/windows-test-thingie/-/blob/master/main.cpp > > I find it weird that we are spending resources on putting things > > in > > the windows store and making apps available on windows, but we > > can't > > actually have passing tests in our CI. > > > > > This unfortunately will not be easy to solve. > > One of the key things that we've learned out of doing CI, as has been > showcased by FreeBSD in particular, is that the builders need to be > ephemeral - that is only around for the build in question that is > being run. > We're currently accomplishing this by using containers - via Podman > (for Linux/Android/FreeBSD) and Docker (for Windows). > > Containers also offer us the advantage of allowing people to easily > reproduce the CI environment on their local system without too much > trouble. > > For Windows however, Microsoft has limited the container stack to not > allow anything GUI related to work. The underlying libraries may be > there, but the equivalent display server components are not > operational. > > To complicate things further, on Windows certain permissions are > restricted to the interactive console and are not possible to do as > either a scheduled task or as a system service. > Usage of existing Windows automation frameworks such as Powershell > Remoting or SSH will therefore not work if we want things to > perfectly replicate a end user environment - because those will run > the command(s) as part of a non-interactive session (even if the user > we connect as is the same one logged in on the desktop console). Idk if it's a silly question, but… If Windows native containers have so many restrictions, why not just use Linux containers with WINE inside?
