A KDE Gear Proposal - Splitting Core apps from Gear (KDE Core App Group)

I should start this off by saying I am just a user looking up at the current situation between KDE and distributions, namely in relation to release cycles. I don’t mean anything negative towards KDE Developers and Contributors (I also really want to become one in the future! though I don’t have the time as of now :[ ), I want this proposal to at least spark a discussion on the current structure of Gear, alongside possibly communicating more on what apps are included under it, and what it actually is.

This proposal came from the recent discussion surrounding the controversial Fedora Plasma Workstation proposal, though this isn’t happening in its current form, it seems likely (to me anyways) that Fedora KDE would be getting more promotion by Fedora regardless in the near future, and the recent release schedule stabilisation plan is one of the key factors to this even happening. One of the frequent criticisms against Plasma being a flagship desktop for Fedora alongside GNOME is the differing release cycles within the project itself (Plasma-Gear-Frameworks), so this proposal serves as a suggestion for a solution.

I also hope this would be the right place to make such a proposal! I’m not familiar with how KDE handles these lengthy suggestion / feedback posts, if this isn’t the right place to post, please do tell me!.

The Proposal / KDE "Core Apps Group"

KDE should split several core desktop apps away from Gear, and put them in their own group (KDE Core? Bolts?) that are strictly released alongside Plasma releases, rather than keeping them part of Gear. This group of core apps should ideally follow Plasma’s versioning (ie. Dolphin 6.x.x, instead of Dolphin 24.xx.x)

Certain apps are already part of Plasma itself and follow its versioning, namely System Monitor and Discover, these apps can become part of this group as well.

This proposal is very much inspired by GNOME’s approach to their apps. (Core and Circle apps)

For the rest of this proposal, I will be referring to this group as “KDE Core” even if the name might be a tad inaccurate (this is a proposal for core apps of the Plasma Desktop), perhaps a more KDE centric name like “KDE Bolts” could be explored? :stuck_out_tongue: (Plasma-Bolts-Gear-Frameworks)

KDE Apps I propose to become part of KDE Core :

Dragon Player
Kamoso (OR Plasma Camera, though this would require it be available to desktop users.)
KDE Partition Manager
KHelpCenter - Already part of Plasma / follows Plasma versioning
KInfoCenter - Already part of Plasma / follows Plasma versioning
KWrite (OR/And Kate, Kwrite being basically a frontend to Kate, maybe we could have KWrite just use a frozen Kate base that just gets updated every major Plasma version OR Kate also becomes part of this group)
Plasma System Monitor - Already part of Plasma / follows Plasma versioning
Plasma System Settings - Already part of Plasma / follows Plasma versioning
Plasma Welcome Centre - Already part of Plasma / follows Plasma versioning

Possible apps that could be included :

KWeather - great app, the reference list (GNOME Core) includes it, would it make sense to include as a core part of plasma that distros should ship for a complete Plasma experience? I’ll leave this up to discussion.
KWalletManager - this should probably be part of the wallet kcm in System Settings.
KRDP - very new program, may require some time to stablise, possibly Krfb instead? (X11 only though :l)
Merkuo Calendar (OR KOrganizer) - Akonadi dep & and questionable if it is “core app worthy” in the same regard as KWeather
Merkuro Contacts (OR Kontact) - Akonadi dep & ^^
Merkuro Mail (OR KMail) - Akonadi dep & ^^

Miscellaneous :

KDE Connect - Well integrated part of the Plasma desktop, but its cross platform presence (namely under GSConnect and KDE Connect for Windows moving aside the phone side of apps) might be harmed by strictly following a 2 per year release cycle.
Haruna - I really like Haruna, and prefer it to Dragon, but since it’s not part of Gear, it’s not included here.

Explaining these choices

A fellow Plasma using friend of mine and I have made this list to favour more Kirigami-based (so pretty!) and newer apps when possible, all of the main list is what I consider to be “core desktop functionality”, some are quite debatable (like all of Merkuro / any PIM apps and kweather). Also note, this list is also semi based off GNOME’s Core apps list, which covers most of what I’d consider “core desktop functionality”, though has things like a weather app and a maps app be part of GNOME’s core apps, which is debatable whether they are worth being part of a “Core Apps” group.

Why split Gear ? / Why should this group exist ?

Gear (as far as I’m aware) currently follows a different 3 month release schedule to Plasma, this alone isn’t an issue, but since Gear itself contains applications that are often considered core functionality of the Plasma Desktop (ie. Dolphin, Spectacle, Gwenview, etc), it often leads to an inconsistent experience across stable release distros. (see: Debian 12 KDE shipping with 5.27.5 having a completely different Spectacle experience compared to Fedora 39 KDE with 5.27.11 despite both on the surface level, shipping the same major version of Plasma) and generally, it makes things feel less “set in stone” for a stable release. (Core apps can change A LOT in between a Plasma cycle solely because of Gear containing core apps independent of Plasma’s release schedule, it was just more blatant with Plasma 6’s extended development cycle)

This would also streamline packaging a full KDE Plasma experience (or on the flip side, installing one on DIY distros!) alongside simplifying what distros should ship for one.

And though this may be meaningless in the grand scheme of things, having these apps be part of Plasma’s release cycle would make major Plasma releases be more meaningful, and in my opinion, more exciting for users as they’d get major improvements for the apps they use alongside their desktop.

A possible downside to consider

A larger time gap between releases of course means even less frequent developments making it to final releases, and a larger development gap between releases that may make the “Core / Stable” branch harder to maintain. (though this may be a non issue)

Other things to consider within this proposal

  • Should Plasma Mobile (and other Plasma related projects, like Bigscreen) be accounted for with these core apps? ie. including the necessary apps for a complete Plasma Mobile experience within the proposed group
  • Could something like this be able to expand KDE’s Plasma LTS effort? ie. offering an entire desktop experience under the “LTS” branch of Plasma rather than just plasma-shell.
  • Some of the proposed apps might be too new to be able to commit to a 2 per year release schedule, either due to not being complete / being very recent projects that haven’t stablized yet (Merkuro / KRDP). Either way, I leave this up to the KDE Developers and Contributors to decide what’s best.

Alternatives to this proposal

  • Releasing Gear as is on the same schedule as Plasma anyways:
    Making every Plasma release a Mega Release like 6 was would definitely be interesting, and would solve the issue of inconsistent schedules, but I feel like Gear covers way too many apps for 2 Mega Releases every year to be possible, and I still think having separation would be the better approach alongside following Plasma versioning.
  • Moving a few of the apps listed above under Plasma instead of being separate by themselves:
    I would mainly suggest apps like konsole and dolphin to become parts of Plasma, like Discover and System Monitor. Though this wouldn’t extend to all the apps listed, it could most certainly work, though this would be up to KDE Developers to determine if a separate group of apps following Plasma is worse/better than just making more apps part of Plasma itself

Closing notes

So a few points I wanted to make before sending off this proposal:

  • While researching to make this proposal, I was honestly very confused on what was part of KDE Gear and what wasn’t, the KDE apps site is excellent, but even it doesn’t let you sort by KDE App groups (ie. sort by gear, sort by extragear, etc), so I had to conclude what was part of gear and what wasn’t for this list by going through every app’s version numbers to conclude what was part of what. The only other source that wasn’t a source folder was Wikipedia’s article on KDE Gear though this is outdated in a lot of places, so I decided to do my own research alongside referring to Gear’s source download tars. Independent of this proposal, I think there needs to be a KDE Wiki page on what Gear and Extragear are (I might write a page for them later if I find the time to), and the KDE Apps site have a label for Gear/Extragear apps. If this proposal happens in any way, I think KDE Core apps should stand separate from the rest of the KDE apps on the page.
  • I really don’t want this to come off as a “forcing KDE to be more like GNOME” thing, this is absolutely more or less an attempt to follow what they do by organizing KDE apps into specific groups that follow the Desktop, but this isn’t just wanting to follow them, this is also an attempt to make things more clear to users, and distributions.

In the end, I leave this proposal to the lovely people who actually develop the software, and hold this wonderful community together to whether such a thing should happen, or if it’s even possible.
Much love to all the developers and contributors involved and to the great community I’ve been a part of for ages :] <3.
(Very much open to feedback btw! including what apps should and shouldn’t be included)


I do believe there are benefits to that. Having the core plasma set of apps be updated at the same time as Plasma seems like a no-brainer to me.

I would also generally consider this a good move.
There are too many important and good KDE “Core” Applications that are not included in a default (extended) Plasma installation.
→ One way to “solve” this could also be to include these applications in the Distributions/Packaging Recommendations.

I would (significantly, but I failed…) reduce the number of KDE Applications considered as “Core” ones, though…

But this might exactly be one problem: nearly everyone prefers and uses different applications or considers some of them more “important” than others.

Well, this would be my list for “Core” and I try to explain later why some of the OP’s chosen applications are not on it:

  • Ark
  • Discover
  • Dolphin
  • Filelight → also because Dolphin uses it
  • Gwenview
  • KCalc
  • KCharSelect
  • KClock → or KTeaTime :wink: :smiley:
  • KFind → I added this one
  • KHelpCenter - Already part of Plasma / follows Plasma versioning
  • KInfoCenter - Already part of Plasma / follows Plasma versioning
  • Konsole
  • KSystemLog
  • KWrite (OR/And Kate, Kwrite being basically a frontend to Kate, maybe we could have KWrite just use a frozen Kate base that just gets updated every major Plasma version OR Kate also becomes part of this group)
  • Marble → I added this one
  • Okular
  • Plasma System Monitor - Already part of Plasma / follows Plasma versioning
  • Plasma System Settings - Already part of Plasma / follows Plasma versioning
  • Plasma Welcome Centre - Already part of Plasma / follows Plasma versioning
  • Spectacle

The following ones I would not consider suitable to be “Core”:

  • Dragon Player → I would not install video/multimedia players by default, but I would leave that decision to the distribution. Dragon Player or Haruna, VLC or mpv or …???
  • Elisa → I would not install an audio player by default either (and would also leave that decision to the distribution). Elisa has become quite good, but not every user needs an audio player (some want to have VLC for both video and audio, for example), so I would leave this one out to reduce the number of “Gear” applications.
  • Kamoso (OR Plasma Camera, though this would require it be available to desktop users.) → not every computer has a camera and not every user needs one
  • KDE Partition Manager → this might be useful during or before an installation process, but I would not want to confront the less computer-savvy user with this in an installed system - there should be something like a simple “USB stick formatter” instead…
  • Skanpage/Skanlite → not every computer has a scanner and not every user needs one

I would also not include KRuler or KColorChooser (two applications my web designer friends and former customers love) or KRDP - they are for far too specific use cases.


Not discussing the merit of the proposal: another thing to think about is whether Core would be defined based on what KDE considers essential as opposed to what distros consider essential.

There’s also the fact that (IIRC) app developers choose for their program to be a part of KDE Gear. How would consent work in the case of Core?

This makes more sense to me.

This doesn’t work IMO. This would send the implicit message that the app isn’t DE agnostic (Konsole and Dolphin can and are used in other DEs just fine, while Discover and KWin for example aren’t expected to be used outside Plasma).

I don’t have much of an opinion on how best to split gear vs. extragear vs. anything else. I do think there is some value in having a “meant as distro default apps” group, vs. e.g. KGet or Kirigami Gallery which are kind of very niche. But I’m not familiar with distro processes much and my weak opinion won’t matter much here.

What I would like to push is to keep apps that are “part of the desktop experience itself” in Plasma itself, not moved to any larger app selection group. Plasma is useless without System Settings and no cross-distro app will replace it. So it’s less of an independent app and more like part of the desktop itself. The other apps that you labeled “Already part of Plasma / follows Plasma versioning” are also tightly coupled, although perhaps the degree of “useless without [app]” will differ.

However awesome Dolphin is as a file manager or Kate/KWrite as an editor, there are competitors that could conceivably do the same work. Heck, even Spectacle uses standard interfaces and has some competition, even though I would personally argue that screenshot functionality should indeed be considered part of the basic desktop experience.

So let’s not put System Settings in the same essential category as KSystemLog, which shamefully I’ve never even been aware of and hadn’t even questioned whether I need it in my life.

I’m in favor of syncing up the Gear and Plasma release schedules. I think that would solve most of the problems without making apps too tightly coupled to Plasma, which was a problem in the past.


as someone fairly new to KDE and plasma (year 1) here’s my thoughts on the topic…

if the goal of plasma is to enable cross platform development, then more and more apps are going to fall into the category of :

part of KDE but used elsewhere

so a line needs to be drawn that acknowledges this app is going to be used elsewhere (by design) but it is absolutely core to KDE.

dolphin fits this description for me.

discovery, if it ever melds with the capability of synaptic would also fit that bill

kate and spectacle feel like core KDE to me as well

qwenview… sigh, well every DE needs an image viewer, but i had to resort to other options for my needs.

1 Like