This sounds very similar to the KDE Apps Initiative started by @ognarb :
https://carlschwan.eu/2024/05/31/kde-apps-initiative/

Each goal needs Champions. If no-one is found it will unfortunately not be eligible for voting.

To me it doesn't matter that much whether applications are first-party or third-party. The important (and more actionable for us) thing would be to make sure our application development story is as good as possible. An uptick in third-party applications would be a sing of us doing something right there.

I'd rephrase the goal around that and then I'd be happy to support it

I would also like to see some kind of rating or tier system for KDE apps and a consolidation of efforts. There should be a clear stance which apps are part of the core KDE ecosystem (e.g. Konsole, Discover) and which ones are not. Currently the https://apps.kde.org/ site is very overwhelming and I am not sure which quality/maturity to expect from the apps found there.

Some examples:

• KMail vs Trojitá vs Merkuro Mail
  • Trojitá did not have a release since 2016-06-15
  • I think the Merkuro suite is supposed to supersede KMail etc at some point?
• Skanlite vs Skanpage
  • ideally these should be consolidation into one
• Kodaskanna vs Barcode Scanner (aka qrca)
• KAlgebra vs KAlgebra Mobile
  • ideally the app should just be responsive (and maybe offer manual switching between a mobile and desktop view)
• Calculator (aka kalk) vs KCalc
  • ideally these should be consolidation into one
• Plan vs Plan Work vs Plan Portfolio
• Kamoso vs Plasma Camera
• Filelight vs KDiskFree
  • these could reasonably be merged into one
• Akregator vs Alligator
• Clock (aka kclock) vs Kronometer vs KAlarm
• Discover vs Apper
• Marknote vs ghostwriter
• KSystemLog vs Journald Browser
• Angelfish vs Falkon

Some of them feel like weekend projects which are fine for the developers themselves but for the general user they would be best advised to use a more mature/featureful solution. Others like QMLKonsole seem to be first and foremost for mobile platforms. They should be tagges as those to filter them out easier.

GNOME has done this with at least two tiers, GNOME Core and GNOME Circle. Apart from that they also indicate with an icon if the app supports mobile platforms.

In T17396#307735, @nicolasfella wrote:

The important (and more actionable for us) thing would be to make sure our application development story is as good as possible. An uptick in third-party applications would be a sing of us doing something right there.

I'd rephrase the goal around that and then I'd be happy to support it

Agreed, same here.

I do think it's good to have more 3rd-party apps, though. Oftentimes we absorb 3rd-party apps so they become first-party apps, and the result is better integration — but I think this is not ideal. You shouldn't have to formally become a part of KDE to integrate properly within a Plasma environment.

I concur with Nicolas and Nate above - removing barriers to entry and making things as straight forward as possible will tend to create the best conditions for growth / new development.

I am also interested in this, lowering the barrier of entry to making apps would be very cool. For example, KAppTemplates helps a lot, but not many people know of it.

Just a few things to point out (not a negative against the proposal) since no one else did yet:

Start an incubator program for community apps (like Gnome incubator program for apps to become a part of the Gnome circle).

This already exists: https://develop.kde.org/docs/getting-started/add-project/

Establish a unified framework for creating apps and focus on streamlining building and publishing. Currently, there seem to be the KDE framework and Kirigami. Having a single framework would eliminate the overhead of having to pick between one.

Kirigami *is* a part of KDE Frameworks, but the technological split between QtQuick (Kirigami) and QtWidgets I don't think will ever be solved. For 99% of new applications though, Kirigami is suitable. Definitely most of what we see in GNOME circle, for example.

^ Note that these confusions are probably a good sign we aren't doing a good enough job at advertising these things :-)

In T17396#307765, @ngraham wrote:

...
I do think it's good to have more 3rd-party apps, though. Oftentimes we absorb 3rd-party apps so they become first-party apps, and the result is better integration — but I think this is not ideal. You shouldn't have to formally become a part of KDE to integrate properly within a Plasma environment.

As I laid out before there is a risk of confusion when there exist many apps which to the same thing. This is already the case with first party apps like Skanlite and Skanpage which share many features but also both have a few features which the other one does not have. Before KDE promotes any more 3rd party apps it should do a spring cleaning of its own projects, mark some as obsolete/unmaintained/archived, unify some others and get mess in a less confusing state

Hello,

Please note that the deadline is on Wednesday, just two days away, so you still have a bit of time to put the finishing touches on your proposal. Take a moment to polish, adjust, and refine your ideas to ensure they’re ready for voting.

If you need any help or have questions, don’t hesitate to reach out.

Here's my take on this goal:

Streamlined Application Development Experience

The All About the Apps goal recognized the importance of highl-quality applications in our ecosystem and resulted in many improvements in their delivery and presentation. However it didn't focus much on the application development itself. By improving and streamlining our application development story we will gain more and better applications for our users, both first-party and third-party.

To achieve this we need work in these areas:

Application Design

The Consistency goal, while having the right intentions, focussed overly on Plasma and didn't end up having a huge impact on application design. There are many cases where our application design is inconsistent, either because no unified idea has been established or older applications have not been updated to new design ideas. The introduction of convergent design as a goal introduced new complexity to this. We tried many ideas and approaches, but often didn't converge (pun intended) on a common design.

To address this we first need to establish a design vision we want to work towards. Once we have such a vision we need to work towards a library set that allows application developers to implement that vision with as little effort as possible while maintaining flexibility and future-proofness.

Our Human Interface Guidelines and other design documentation needs to be updated/extended accordingly.

Application Development

Currently we have an odd fragementation between QtWidgets- and QtQuick-based stacks (as well as hybrids). Neither are going away any time soon, so we need to plan with both for the forseeable future. The trend however is clearly biased in favor of QtQuick for many reasons. There are however some things QtWidgets does better. To address this we need to:

• Create and roll out QML equivalents for functionality found in QtWidgets apps (e.g. dock widgets, command bar, etc)
• Address issues currently found in QtQuick "desktop" support, e.g. lack of proper popup windows or menu bar support
• Modernize and improve tooling compatibility of our QML code

Furthermore, in terms of general application development we should:

• Avoid/reduce redundant APIs and API fragementation
• Fix issues with running KDE apps outside of Plasma/Linux
• Improve the integration with IDE tooling
• Enable building KDE apps with languages other than C++, e.g. Rust or Python

Development documentation

The tools, APIs, and processes for creating applications need to be documented well

• Do something about the bad state of API documentation for Kirigami and other QML modules
• Improve and extend tutorial documentation around creating new apps as well as specific functionality topics
• Establish quality guidelines for applications
• Improve, finalize, and document deployment processes for Windows, Android etc.

Community

Good apps need a whole community behind them.

• Establish a culture of continuous review and improvement, similar to KDE Review but not as a one-time-only thing
• Strengthen QA and bug triaging community

We also should look into how we can make it easier to develop KDE-aligned applications outside of the KDE umbrella and have good KDE integration for apps that don't primarily identify as KDE-aligned

• Make sure our libraries are available in popular dependency management solutions (vcpkg, conan, etc)
• Document how to achive KDE integration without tight dependencies on our libraries
• Work with collaborative upstreams like Wayland, Freedesktop, and xdg portals to improve shared building blocks

+100, That sounds fantastic. If that were the text, I would sign up to put work into this and could even be convinced to be a co-champion, perhaps on the communication side.

@oahshtsua What do you say? Right now it doesn't have a champion so would be disqualified from the vote. With Nico's changes it could be in but you will need to make that decision now.

I can help with this as I am already working on cxx-kde-frameworks - rust adapter for frameworks

Enable building KDE apps with languages other than C++, e.g. Rust or Python

I'd be happy to throw some infrastructure assistance in around areas where that is applicable. Based on what Nico has written.

Hi @oahshtsua, today is the last day to finish polishing the proposals. Would you consider joining forces with @nicolasfella and adapt your proposal?

No response from the original author, so I'm overriding the proposal

I strongly support the fact that other frameworks should be included in KDE. It'll attract a variety of people from different frameworks who would love to be part of the community.

Of course it might feel that the apps might not look the same as native KDE apps, but depending on the frameworks they might be better in a number of ways like UI, accessibility etc

The need of 3rd party frameworks is because of the need for people in community. Once into the community and people working on different framework apps, maybe some virtual events can be conducted regularly to cross collaborate people from different frameworks in a fun way. This might influence some people to start learning and contributing to other frameworks too.

Also college students and others might be looking for a project to improve their portfolio, so this multi frameworks inclusion will bring a lot of people into the community for an internship / virtual certificate. This will create more potential active contributors if they are interested in the project.

Of course a good environment and inclusion of variety of people will help KDE gain contributors, good apps, etc

@vivekanandanks, irrespective of the fact that your suggestion doesn't appear to relate directly to the post, what exactly are you referring to? I ask because frameworks are notoriously difficult to mix-and-match due to how much of the dependency tree of a codebase they generally encompass, in comparison to something written without them.

Are you recommending that even more than GTK and Qt be installed by default, like wxWidgets? If so, why? I ask because we have package managers that make installing such package selections for development trivial without the need to include them in every default OS image with the Plasma DE.

Also college students and others might be looking for a project to improve their portfolio, so this multi frameworks inclusion will bring a lot of people into the community for an internship / virtual certificate. This will create more potential active contributors if they are interested in the project.

That really doesn't make any sense. You recommend that KDE permit applications written in alternative GUI frameworks to Qt? That would allow anything to be branded as a KDE application.

KDE isn't Flathub - there's actually quite a lot that the KDE Frameworks does that allow applications written in it to be differentiated substantially from even pure Qt applications (like VLC and OBS). Providing the same functionality to GTK in its entirely (even the current GTKRC is difficult enough to maintain) would be fundamentally infeasible.

The voting process is over, the votes are being tallied and the chosen proposals will be announced at Akademy. In the meantime we would like to invite you all to join the KDE Goals matrix room to stay in the loop, get in touch with other people and team up on other proposals if yours doesn’t make it—or rally some support if it does.

Hey all, as you know, we are encouraging more than one champion per goal. If this task resonates with you and you feel inspired to contribute more closely, now is a great time to do so. Have a chat with @nicolasfella to see how you can join forces with him.

Hello all, just in case you missed the news, we have a matrix room to get in touch with the team and see how to join the effort.

There is a mention in this task of increasing the quality and amount of bindings for languages other than C++:

Enable building KDE apps with languages other than C++, e.g. Rust or Python

At the GitHub repository for Qt's official Qt6-DotNet bindings, there's been a discussion about whether and how it should be maintained, in which someone proposed that KDE do so. This would be the difference between me using Qt or not, as I imagine it is for others (at least, those participating in the aforementioned issue thread).