Every 2 to 3 years KDE selects 3 goals that the whole community can focus on for the coming years. For the past 2 years we have focused on improving the accessibility of our applications, worked to make our software more sustainable and automated and improved a lot of processes to make developing software in KDE smoother. To learn more about these goals check out the KDE Goals page. We will wrap up these goals at Akademy in Würzburg later this year.
It is now time to figure out what the next goals should be. We are starting this today by opening the floor for proposals. This means you (yes you!) can campaign for something you and others want to work on over the next 2 years and rally the KDE community behind it. To give you some inspiration you can have a look at the complete list of goals we’ve had in previous years.
How does it work?
You (and a small group of others) can submit a proposal by opening a ticket on this Phabricator board. Copy the template into a new ticket and explain your idea. The template gives you a few hints to help you create a meaningful proposal. This process is open until July 5th. (On July 5th we will start the refinement stage, where others can further help you improve the proposal.)
Some things to keep in mind
- The process is explicitly open to proposals from people who are not yet KDE contributors.
- The process is explicitly open to everyone, not just developers.
- We expect the champions of the goal to be the champions, not the only ones working on the goal. At the same time they will need to put in significant work to rally people around their goal.
What is different compared to previous editions?
We are tweaking the process a bit this time. If you’re familiar with the process from previous years here are the most important changes:
- We are moving from an individual champion to a small team of champions. Each goal should have someone who can carry the vision of the goal forward, someone who can technically steer it and someone to promote it. Other setups are possible where it makes sense for the particular goal but a goal needs a small team. Don’t have a team yet? That’s ok. Submit a proposal and say what you need. We will try to help find others to join.
- We are focusing the champion role more on driving the goal forward through others and less by doing all the work themselves.
- We will work with the goal champions on fundraising for specific projects that support their goal.
What’s the timeline?
- Starting today until July 5th: Propose goals and find team
- July 5th to August 15th: Refine proposals together with the community (identify issues, remove blockers, sharpen the proposal, …)
- August 15th to 31st: Voting on the proposed goals by active KDE contributors
- September 6/7th: Selected goals are announced at Akademy
Still got questions?
If you still have questions you can ask them in various places:
- In the office hour on June 14th at 7PM Berlin time. You can find the time in your timezone here. The meeting will happen on BigBlueButton.
- The KDE Goals matrix channel.
- The KDE Community mailing list.
- Reaching out to me directly.
One of the strengths of KDE is the full integration and polish. With that said I suggest a few different options:
1. AI integration. Think about having a safe LLM with voice interaction that is actually private integrated into KDE.
This could eliminate the need to update config files, as it could be done with a text entry or voice command.
2. KDE being updated swapped over to rust. This would allow KDE to be integrated into other operating systems such as Redox.
Please this:
https://bugs.kde.org/show_bug.cgi?id=422529
This can be done by a single developer in less than a week.
It would be great if you made KDE great, I mean LEAN, again.
E.g. KWin and Plasma (even with zero running plasmoids) have become resource hogs. The plasma process mustn’t be consuming over 600MB of RAM doing nothing. In fact, it would be great if you considered splitting plasma into KDesktop and Kicker, like it was in e.g. KDE 3. Not gonna happen, I know.
As a long-time user who is looking for greener pastures, here are my concerns:
1. Memory-safety and formal verification. There was some mention of using rust for various KDE libraries like solid, akonadi, etc.
And for the existing C++ code, the amount of static analysis should increase. Make use of every linter, sanitizer, fuzzer, and security-oriented compiler flag. This should be a top priority.
SQLite is a gold standard in this regard. You should have a page explaining KDE’s security and correctness guarantees, like they have. https://www.sqlite.org/testing.html
A similar site listing all the existing and planned safety nets should be made.
Going as far as formal verification for the low-level libraries makes sense.
2. Capability-based security. There should be a sandbox-first mentality for everything with only the minimal set of needed permissions enabled, and prompts for all other permissions requested. XDG Portals being an obvious choice. And the Portals implementation should follow all the security and memory-safety best practices.
3. SDDM and kscreenlocker seem to lag behind GNOME’s offerings. Things like fingerprint unlocking, U2F, and integration with TPM and encrypted filesystems should be as frictionless as possible. Entering passwords all the time is not fun.
4. KeePassXC is much nicer than KWallet and it would be nice to integrate it into KDE or merge the project with KWallet or something. This would ease the maintenance burden and be one less project to maintain, while providing a more featureful and user-friendly experience for users.
KeePassXC already begins with the letter K, and is based on Qt, and thus should allay your Not-Invented-Here Syndrome fears.
5. Konsole now feels lagging behind offerings elsewhere. For instance, additional profiles should be automatically suggested or added. If you have bash and zsh and nushell, then all of those should already show up as options. If you use toolbx, distrobox, or anything of the sort then those shells should show up without any configuration. Windows Terminal automatically does this.
And the UI needs a refresh. Selecting profiles should be easier, tabs should be always visible by default, and the other UI chrome should be more minimalistic and not take up any screen real estate.
Perhaps consider importing Alacritty as the backend.
6. Reconcile with the KWinFT/ship-of-theseus project. It is a shame that the talent being put in that direction isn’t helping the standard KDE user.
Vulkan, Explicit sync and Wayland, so to make Plasma free from Xorg and Opengl.
If KDE is to become the desktop standard, the common user must be in focus (Windows and Mac users). Nate Graham understands this and I think is doing a phenomenal job.
Obvious to get rid of critical driver issues and use with modern harwdare:
*) Wayland
*) Explicit Sync
*) Vulkan
*) Logarithmic display brightness (since lumens are increasing significantly with new displays)
Not critical, but important
*) Additional Sound Settings (noise cancellation, bit rates etc. important for meetings)
*) Tablet settings (seriously preventing artists to do the move)
*) GUI harmonization: E.g. File manager and Settings looks different and thus gives an old feeling for new users
*) Settings for Power Profiles: Enforce dGPU/GPU, performance/power save for networks etc.
Expand use-cases so that more users (like artists/scientists) can use their tablets/equipment in wayland
As a dedicated user of the KDE Plasma desktop environment, I would like to propose a few enhancements and new features that could significantly improve user experience and functionality. Here are some ideas that could be considered for future releases.
1. Enhance Discover
Discover, KDE’s software center has great potential but could be further refined to meet user expectations. One critical enhancement would be to display the total download size for apps, including all dependencies, especially for Flatpak installations. This would provide users with a clear understanding of the data requirements before downloading.
Additionally, the “Installed” section in Discover should separate applications and their dependencies/libraries into distinct categories. This would simplify software management, allowing users to better understand and control their installed programs.
2. Optimize Kdenlive
Kdenlive is an outstanding video editing software, often regarded as the best for Linux-based systems. However, certain tasks can be time-consuming compared to software like Adobe Premiere. For example, syncing a video with beats and adding an earthquake effect for each beat took 20 minutes in Premiere but an hour in Kdenlive. While Kdenlive is highly capable, there is room for efficiency improvements to make it more user-friendly for specific tasks.
A significant enhancement would be the implementation of hardware acceleration, a feature eagerly anticipated by many users. With such improvements, Kdenlive could become one of the leading video editors in the market.
3. Expand Login Options
As technology rapidly evolves, so do user expectations for convenience and security. While other operating systems offer fingerprint and facial recognition as standard login features, KDE is yet to fully integrate these options. Here are some specific improvements:
– Streamlined Fingerprint Setup: The system should automatically detect if the necessary library, libfprint, is installed. If not, users should be prompted to install it, making the setup process straightforward and user-friendly.
– Default Fingerprint Login Configuration: Currently, fingerprint login options are not included in the default settings for SDDM and Klockscreen. Users have to enable these features manually, which can be cumbersome, especially for beginners. These settings should be incorporated into the default configuration to eliminate manual intervention.
– Simultaneous Login Options: When fingerprint authentication is enabled, the system defaults to requesting a fingerprint and then switches to password login if it fails. This behavior should be improved to allow users to choose between fingerprint and password login simultaneously, providing a more seamless user experience.
– Facial Recognition Integration: With the increasing prevalence of digital security measures, typing passwords has become less appealing. KDE should consider implementing facial recognition login support. Although third-party solutions like Howdy exist, KDE lacks native integration with these programs. Furthermore, Howdy has faced maintenance and bug-fix issues, highlighting the need for a more reliable solution. KDE should develop its own facial recognition software, ensuring seamless integration and a superior user experience.
By addressing these areas, KDE Plasma can continue to enhance its user experience and stay ahead in the rapidly evolving tech landscape.
Touchscreen friendliness. A working Onscreen keyboard akin to Windows and touch handlers that avoid unexpected input, such as accidentally initiating Drag&Drop.
1. Thumbnails in taskbar, task switcher, windows thumbnails in workspaces views are all of them not nice. i.e. awful.
2. New kirigami based apps not able to display a menu items in menu widget, hmmm not pleasant experience.
3. Big indicators on desktop edit mode for placing my taskbar are too much.
Thx in advance
Hello.
I see that there is no link to register in this platform that you posted its URL: https ://phabricator.kde.org/project/board/323/
How can we post ideas if we can’t register?
Better Tilling Manager more likewith more zones, no limiting and applications can with shift+start set to more than 1 zone for more flexibility.
Not a C++ dev, so I can’t contribute directly, only say my wishlist as an user.
– Modernizing Breeze/Layouts and Icons: I personaly use “tablet mode” on my work pc just because by default it increases some paddings and make some elements more pleasing to the eye, despite the theme. It’s not perfect and there’s inconsistencies everywhere, and as a whole KDE’s interface is usually too “compact” and sometimes even with tablet mode. There’s 1px border lines making it look like a pre-2010 system freaking everywhere , when background colors could be used instead. The breeze icons also look like they came straight from the android 4.x era, it’s the reason I use Papirus.
– Group all config files on the same folder/structure: Makes it all easily accessible and customizable, allows easier tracking of changes, backup, even creation of third party extensions, etc…
– Seamless HDR, VRR and tablet config: Needs basically no explanation, all I wish is one day I finish installing KDE, enable “HDR” and “VRR” and then never worry about it again, I know this mostly depends on things outside of KDE, but still. Also the tablet config could use the re-introduction of features removed on 6.0.
– User friendly customizable mouse/trackpad gestures: this, so much this.
You need to register at https://identity.kde.org/ and then log in with that account.
KDE should focus on not changing the look and feel of plasma desktop at every single update.
Safety, safety, safety.
Store.kde.org is an accident waiting to happen. We already have global themes that have deleted userspace data, including mapped drives. Does this give me faith and trust in Plasma? Absolutely not. rather than “simple by default”, how about “secure by default.”
Consider enabling a settings profile for optimizing the cloud / virtual desktop infrstructure computing usecase (and thus make plasma a viable option against Windows® in the cloud), in which for example you recover the once available kwin option “hide window contents while moving (and/or dragging?) “; another nice option would be to reduce the framerate and BPP to 16 bits, of course disabling all the compositor 3D code paths that make no sense in a professional cloud/VDI setting; another nice option would be to add a kwin_wayland backend to serve plasma over either SPICE or FreeRDP, at least poor old VNC/RFB (like MacOS); optimize plasma under wayland for KVM. There is a lot of potential for Plasma is the cloud, being so professional, nice looking, natural and evocative to the untrained user, it blows my mind that plasma keeps sabotaging itself, reducing the exposure it deserves, that it is marginal in the enterprise and thus relegated to the personal home space of Linux/BSD experts. Less fancy frames and more users seeing a donate window.
1. Better face detection on digiKam using open AI model, Current ones are not good.
2. Better media info detection on all media files so sorting in dolphin will be easy, currently it fails to get those info and those columns are blank
Hi,
can you do something to KDE Partition Tool.
In KDE Partition Tool u can check the disk health and it shows also the
Operating hours, in KDE u just get the days and the hours.
In gnome u get hears hays hours.
It will be nice if this will be implanted in KDE
Thx.
in no particular order:
– HDR
– VRR
– 10 and 12bit colors
I’ve been using Plasma for a long while and it’s my favorite DE but I also think that UI/UX can be improved, there are plenty inconsistencies still in Plasma’s design, although Plasma 6 made the environment a little more consistent I feel like it’s still lacking. I’m not referring to Breeze (which I think that also needs a refresh but I don’t feel like it has to be a priority, theming exists), I’m talking about the design in KDE apps, I don’t know if KDE Project has some documentation about guidlines for UI design but if it exists, the apps aren’t using it or it’s as inconsistent as some apps inside the same DE.
Unattended remote access on Wayland has been a feature that has been requested many times. While regular remote access is already being worked on with KRdp it would be awesome for it to integrate with SDDM and to permit remote access without requiring confirmation from the user every time.
Customizable Touchpad, but especially touchscreen gestures (I’m talking about the three/four-finger swipes etc.) for tablets or other touchscreen devices. This should include an option for custom scripts for gestures.
The touchscreen gestures (+ the options to customize these) that allow the use to swipe from the edge of the screen are great, but would be more useful if an option was included to execute custom scripts with gestures.
Also, these gestures could be made to include only parts of the edges — a swipe up in the lower right corner could then expand the system tray, for example.
I have not discovered a way to consistently use right-click on a touchscreen device — this means I cannot edit panels and do various other actions.
Final point: The system try is difficult to use on tablets. Using gestures to open it, or enlarge it, or something like that would be very helpful. The tablet mode ultimately does not look nice and does not fundamentally address problems (slightly wider spacing is nice, but not that helpful in a gestures-oriented digital world).
Maintaining compatibility, especially with legacy(X11) software and hardware.
KDE UI looks outdated. I know Nathan recently worked on the Human Interface Guidelines, but still they reflect the current KDE look and feel. The starting point would admit the developers are in most cases not very good UI designers, and let a team of designers improve HID or even create a new design system. KDE is well known for its customization capabilities which may be great for creating a new an unique environment for KDE, at the same to accomplish a beautiful desktop KDE may need to compromise the customization (for end users) and be more opinionated about how the UI should be. If we compare some design system out there, we can see how spacing between elements has rigid rules, and even colors when you can change, you choose the accent colors only, and the rest is calculated to look good based on that. I’m sure how often people customize their desktop theme, but I never do; because most apps would work ok with Breeze Dark/Light, but some would look wierd with customized themes.
There are two major problems with KDE Plasma today:
1. The lifecycle: KDE Plasma does not have a homogeneous release cadence and life cycle like GNOME does. KDE Frameworks are released monthly, KDE Gear and KDE Plasma are released every 4 months, but at different times. There’s basically no harmony across these critical parts of the KDE Plasma stack. This is also compounded by the mess that is KDE Plasma LTS. KDE Plasma LTS only covers KDE Plasma. The Frameworks and Gear are not included. This is a nightmare to collect and release. Actually, Fedora doesn’t even ship Plasma LTS for RHEL/CentOS users anymore because it’s just not viable for a good long-term experience. We upgrade KDE Plasma for RHEL/CentOS users regularly now. For comparison, everything for GNOME is released together, and GNOME releases every six months. This consistency also makes it easier for Enterprise Linux distributions (Red Hat Enterprise Linux [RHEL] and SUSE Linux Enterprise [SLE]) to consider upgrading GNOME on a regular basis (SLE does it every two years, for example).
2. The sprawl: The KDE ecosystem is more than double the size of GNOME. A fully featured KDE Plasma setup is almost 600 components.
Source: https://www.reddit.com/r/linux/comments/x8m0bt/why_do_none_of_the_major_distros_have_kde_plasma/