Re: Post-MegaRelease projects
On 2/22/24 22:57, 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 Hi, some ideas for strategically useful things: - finalize the move away from Qt5/KF5 by porting remaining projects - Update our QML code to make use of modern practices/tools (qmllint, qmlformat, qmlcachegen, qmltc, qmlls etc) - Invest in making it possible to write KDE-aligned apps in other languages (IMO the most relevant contenders would be Python and Rust since these are popular and there's prior art for using them with Qt) - Work towards bringing features from our widgets-based frameworks (configurable toolbars/shortcuts, KHamburgerMenu, KCommandBar etc) to QML apps Don't take this as a "I am going to work on this" list, but I'd be happy to assist with any of the listed topics. Cheers Nico
Re: Post-MegaRelease projects
Nate Graham ha scritto: > 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: * remeber that the porting is not finished. Gear for example still has 51 modules which are KF5-only, including several edu modules and kdevelop. It would be nice to solve at least the cases when a library need to support both KF5 and KF6 due to dependencies. Ciao -- Luigu
Re: Post-MegaRelease projects
On Friday, 23 February 2024 03:27:00 CET Jin Liu wrote: > Another thing I'd like to explore is to have some universal way to > programmatically change KDE settings. This is a thing that I'd really like to have -- but probably cannot contribute to -- also for Calamares (a Linux distro installer). It runs the plasmalnf tool (if configured to set up KDE Plasma) but that's something of a hack. I also get regular feature requests "configure in Plasma" which I can't do, since the configuration is opaque to me. [ade]
Re: Post-MegaRelease projects
On Friday, February 23, 2024 11:12:16 AM CET 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. > > - 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 To motivate everyone who wants to get into KDE CI, I can report something helpful which I just found: At least since October 2023, there is extensive documentation on the CI system made for KDE projects. If you felt lost before, like me, it is now a good chance to try it again. https://community.kde.org/Infrastructure/Continuous_Integration_System README.md files have also been added to the ci-utilities repository. Thank you for writing this documentation! Cheers, David
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 11:35 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > 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? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > > > Fair point, no sw is bugless. Although, from my shallow experience WINE > seems to have an excellent test suite. I remember reporting a regression > once, which turned out to be due to some obscure surfaces manipulation by > an old Heroes Ⅲ game. WINE devs not only quickly fixed that, but they also > added tests for that case, so I'd presume such regression is just not gonna > happen anymore. > > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > > > No idea, I saw their commentary on debugging issues they were having in > their unit tests in #kde-devel. > Those issues were due to a lack of permissions, specifically around the > interactive console - that is how I know some of our tests need those > additional permissions and why running as a scheduled task / system service > will not be sufficient for "fully working" CI tests on Windows. > > > Sorry, it seems there's some misunderstanding… Judging by what you say you > seem to be referring to the restrictions that Windows containers have on > Windows. But that was the point that started this thread, to which I > replied that running Linux containers with WINE might be a solution > What i'm referring to here is that KDE Connect interacts with various components of the system in order to do what it does. See for instance the ability to share Notifications between devices, or ability to act as a presenter device. That requires accessing various system level APIs which WINE very well may not support - and we wouldn't support a scenario of using it under WINE because there is a native Linux version already. > > Plus, we have to have native Windows to compile things anyway as we need > to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be > built with MingW) > > > But I presume it can be built with Clang? In particular, Google Chrome on > Windows is being built with Clang — and Web Engine is basically a fork of > Chromium. > > > Qt 6 as a whole does not
Re: Post-MegaRelease projects
On Sat, 2024-02-24 at 23:07 +1300, Ben Cooksley wrote: > On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov > wrote: > > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > > > wrote: > > > > 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? > > > > > > > > > > > > > Because Wine is not Windows either, and there could be subtle > > > differences in how things run / interact with the system. Fair point, no sw is bugless. Although, from my shallow experience WINE seems to have an excellent test suite. I remember reporting a regression once, which turned out to be due to some obscure surfaces manipulation by an old Heroes Ⅲ game. WINE devs not only quickly fixed that, but they also added tests for that case, so I'd presume such regression is just not gonna happen anymore. > > > Plus some of our software would like to test certain system level > > > infrastructure (like say KDE Connect). > > > > > > Out of curiosity, what does this infrastructure include? I thought > > KDE connect only uses network sockets and system tray. > > > > > No idea, I saw their commentary on debugging issues they were having > in their unit tests in #kde-devel. > Those issues were due to a lack of permissions, specifically around > the interactive console - that is how I know some of our tests need > those additional permissions and why running as a scheduled task / > system service will not be sufficient for "fully working" CI tests on > Windows. Sorry, it seems there's some misunderstanding… Judging by what you say you seem to be referring to the restrictions that Windows containers have on Windows. But that was the point that started this thread, to which I replied that running Linux containers with WINE might be a solution > > > Plus, we have to have native Windows to compile things anyway as > > > we need to use MSVC (otherwise you have no Qt Web Engine support, > > > as that cannot be built with MingW) > > > > > > But I presume it can be built with Clang? In
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 10:27 PM Konstantin Kharlamov wrote: > On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > 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? > > > Because Wine is not Windows either, and there could be subtle differences > in how things run / interact with the system. > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). > > > Out of curiosity, what does this infrastructure include? I thought KDE > connect only uses network sockets and system tray. > No idea, I saw their commentary on debugging issues they were having in their unit tests in #kde-devel. Those issues were due to a lack of permissions, specifically around the interactive console - that is how I know some of our tests need those additional permissions and why running as a scheduled task / system service will not be sufficient for "fully working" CI tests on Windows. > > Plus, we have to have native Windows to compile things anyway as we need > to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be > built with MingW) > > > But I presume it can be built with Clang? In particular, Google Chrome on > Windows is being built with Clang — and Web Engine is basically a fork of > Chromium. > Qt 6 as a whole does not list Clang as a supported compiler - see https://doc.qt.io/qt-6/supported-platforms.html Given Windows is a bit strange in the first place, i'd be quite reluctant to step outside of what they list as supported. > > (and you cannot really mix MingW / MSVC binaries due to incompatible > compiler ABIs for C++ code) > > > Well, if for testing purposes Qt was pre-built with Clang, I guess there > won't be any ABI issues. > Would require that everything else we have is rebuilt, and that all downstream users of our Craft cache also switch to Clang. Note that like most open source projects, we don't know the full extent to which Craft is used outside of our own project. Historically we have seen through Microsoft provided data that dependencies which we built and signed have shown up in surprising places (such as Snoretoast - which was used by something Node.js based at one point or another I believe) Cheers, Ben
Re: Post-MegaRelease projects
On Sat, 2024-02-24 at 22:16 +1300, Ben Cooksley wrote: > On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov > wrote: > > 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? > > > > > Because Wine is not Windows either, and there could be subtle > differences in how things run / interact with the system. > Plus some of our software would like to test certain system level > infrastructure (like say KDE Connect). Out of curiosity, what does this infrastructure include? I thought KDE connect only uses network sockets and system tray. > Plus, we have to have native Windows to compile things anyway as we > need to use MSVC (otherwise you have no Qt Web Engine support, as > that cannot be built with MingW) But I presume it can be built with Clang? In particular, Google Chrome on Windows is being built with Clang — and Web Engine is basically a fork of Chromium. > (and you cannot really mix MingW / MSVC binaries due to incompatible > compiler ABIs for C++ code) Well, if for testing purposes Qt was pre-built with Clang, I guess there won't be any ABI issues.
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 9:21 PM Volker Krause wrote: > On Saturday, 24 February 2024 04:31:49 CET 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. > > And that's fine, we are in dreaming territory here anyway :) > > > 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-l > > ibvirt/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/autom > > ate-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 > >
Re: Post-MegaRelease projects
On Sat, Feb 24, 2024 at 8:37 PM Konstantin Kharlamov wrote: > 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? > Because Wine is not Windows either, and there could be subtle differences in how things run / interact with the system. Plus some of our software would like to test certain system level infrastructure (like say KDE Connect). Plus, we have to have native Windows to compile things anyway as we need to use MSVC (otherwise you have no Qt Web Engine support, as that cannot be built with MingW) (and you cannot really mix MingW / MSVC binaries due to incompatible compiler ABIs for C++ code) Cheers, Ben
Re: Post-MegaRelease projects
On Saturday, 24 February 2024 04:31:49 CET 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. And that's fine, we are in dreaming territory here anyway :) > 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-l > ibvirt/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/autom > ate-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. Right, the Android emulator is probably the first thing to look at for this. That alone isn't enough though, we can't just copy over a unit test executable and run it there,
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?
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 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
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
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
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
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
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 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
I plan on working on libei integration into KWin and hooking it up in the portal David
Re: Post-MegaRelease projects
Notifications could use some enhancements, like grouping by sending application. Yifan [0]: https://bugs.kde.org/show_bug.cgi?id=440837 [1]: https://bugs.kde.org/show_bug.cgi?id=441906
Re: Post-MegaRelease projects
On 23/2/24 08:27, 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 Agreed, this will make themes uploaded the KDE Store less likely to contain malicious code * Start adding release notes to our apps' AppStream metadata [2] Regarding this we could add (or improve any existing) linting job to include appdata checks. * 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 Please feel free to CC/invite me on anything related to the store as I manage the servers and have direct contact with the Web team that manages the software. I am always looking for new ways to remove spam, keep the platform secure and any ways to make sure the content is well curated. * Our virtual keyboard situation is not great and needs focused work On this I think it might be worth looking into working with Dobey who works on Maliit. It's used by the Plasma Mobile stack and I think Dobey is the only major contributor to it. It could either be brought under the KDE umbrella or forked to be a KDE specific OSK * 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
Re: Post-MegaRelease projects
> Another thing I'd like to explore is to have some universal way to > programmatically change KDE settings. [...] Perhaps we can gather all KConfig > files into a CLI tool that has _some_ documentation and can do the config > file editing / reconfigure. This would be incredibly useful for making a KDE environment portable. Maybe one mega-sized TOML or YAML file that records all changes from defaults? It could certainly start simple...
Re: Post-MegaRelease projects
Another thing I'd like to explore is to have some universal way to programmatically change KDE settings. Currently, I either change settings in KCMs, or manually edit a config file then make a dbus "reconfigure" call. But the latter is mostly undocumented. Perhaps we can gather all KConfig files into a CLI tool that has _some_ documentation and can do the config file editing / reconfigure. Scenarios I'm targeting with this: 1. A "quick setting" widget that allows the user to toggle some setting directly on the panel, even if it's hidden deeply in systemsettings. 2. A "ChatGPT" or "Windows Copilot" like app that allows the user to toggle settings via natural language, typed or speech. The major difficulties I see: some combination of settings might be invalid, and the logic to prevent invalid combos might be in the KCM code. So this tool has the risk of breaking KDE softwares.
Re: Post-MegaRelease projects
I think telemetry could help in a lot of discussions around UI/UX. Questions: 1. In which project should we create an issue about telemetry? 2. Where can I see current telemetry data? 3. How many users enabled telemetry, at what level? Concerns: 4. Storing more data might raise concerns among users. 5. Storing more data is more privacy-sensitive, so it might require more effort on server side or legal things. Nate Graham 于2024年2月23日周五 05:57写道： > 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 >
Re: Post-MegaRelease projects
On 2/22/24 23:57, 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 Speaking for kwin, there are a few things that I would like us to complete or spend more time on - Fractional scaling - Output layers - Scene: port as much as possible stuff to the Item. It would be nice to add support for animating Items in order to start phasing out AnimationEffect. Also, as we discussed in #kwin, it's worth looking into splitting item and render node trees - Input: input grabs & redirection of input through the scene - Split kwin_wayland and kwin_x11 + further design cleanups and code shuffling - Explicit sync - Triple buffering - Proper output mirror and tiled output support - Try enabling color management by default The list is quite ambitious for 6.1 as it requires a lot of work.
