Description

As it stands, the two dominating desktop environments (those being KDE and GNOME) have two distinct advantages; KDE is highly customizable, and GNOME is highy cohesive.

Regarding the latter, we have their incredible thorough HIG to thank. Exact specifications on how to use sliders, buttons, and tabs are provided - everything from icon metaphors to application design principles is covered in incredible detail, making what can be considered a "GNOME" app incredibly narrow. This is an incredibly good thing, as I see it - a mish-mash of disparate-looking applications, all ostensibly products born of the same desktop environment, is very confidence-uninspiring.

KDE takes the other approach. It's (seemingly*) very easy to go from the stock KDE "look" to one of a user's particular taste. You can make your KDE workspace emulate the style of MacOS, of Windows, or of something new entirely.

*Seemingly is important here. We recently had an event where a global theme on KDE broke a user's install of their distribution. The methods of changing UI styles are spread across various settings and software centers, and the way they intermingle can be difficult to get a hold on.

With KDE 6, it's clear that the KDE team is trying to move to a more "sustainable" UX style, even if it may "feel" a little more technical than the simple GNOME does. I feel that this needs to be even more strongly addressed in the next coming years:

• Development systems, such as API's, to very clearly and simply develop "themes" for KDE that do specific things should be developed and maintained (do you want to change the icons? Adjust what Kirigami applications look like? Add blur to certain application backgrounds? Modularity is huge here.)
• Settings to download and set different theme options should exist where they would immediately provide an effect; for example, if I'm downloading a theme that changes KDE apps such as Dolphin, Kate, etc, those applications should be *the exact location* where I can download and manage themes *for* those applications. Consider how the LibreOffice suite of software allows you to change the File/Home/Insert... options from a single setting, but prompts you to choose whether this will be a universal change, or a change exclusively for the app being used.
• Theme developers and the KDE team should collaborate to see if there are mature enough themes to consider as "official," and that might come with a stock install of KDE. This may take away some of the initial apprehension that comes from downloading things off the internet, and provide new users and easy way to get "into" the world of customizing their desktop experience.
• The HIG should be made more specific, and most importantly, easier to read. It's a nitpick, but things like the text not being vertically centered in their buttons on the homepage makes it look rather unprofessional, and the "Icons" section having its arrows be cut off by the main page - as well as being unreachable with the "next" and "previous" buttons - is really unsettling. Compared to the GNOME HIG, it is significantly harder to get a grasp on what makes a KDE app, a KDE app. Ambiguity in development styles is fine, but that ambiguity should be *explicit* (i.e. "where you place X element is up to you), and it shouldn't be so much that two developers following the HIG to the T end up creating completely different-looking applications. Cohesion, while perhaps not the star priority, should receive a decent level of review.

What it will take

I believe I've mostly laid out the answer to this question above.

How we know we succeeded

"KDE makes buggy software" is unfortunately still a sentiment expressed by many. I think this has just as much to do with the disparate nature of settings, development tools, and the sometimes "incomplete" looks of official websites as it does the actual stability of programs. We'll know we have succeeded if:

• The HIG is just as digestible as that of GNOME's for app developers/
• Customization is seen as a relatively painless endeavor, even for newcomers to KDE

Relevant links

Nothing yet, beyond just the GNOME HIG for reference on how I think it can be structured (the *content* is immaterial; I just mean the flow of finding information on certain topics.

Champions

Unfortunately, I'm not a part of the KDE contributor group, and so I'm unfamiliar with who exists to complete work in this goal, should it be accepted. This section is left for completion, but done so blankly, as I do not have an adequate response.

The team is:

• XXX
• XXX
• XXX

I am willing to put work into this

• add your name

I am interested

• add your name