Moved to https://invent.kde.org/teams/vdg/issues/-/issues/43, where I've summarized the rough conclusion here, and we can work on turning it into something actionable quickly.

Is there a reason for the wontfix designation? I've read this thread a few times and don't see one.

This is largely done in Plasma 6 now!

With https://invent.kde.org/frameworks/kirigami/-/merge_requests/1235, we have a path forward here, at least for QML apps.

I am confident that instead of this, the more simple iconography should be utilized. My grandmother has a seriously difficult time trying to understand the colourful iconography, whereas the doesn't when it is at 16 pixels (but then it is unpleasantly small) and the colourful iconography is able to adhere to the currently utilized .colors file, whereas colourful iconography is not.

This is obviously desirable, but I doubt that this is actually possible unless all of KDE's software switches to tree-views. I would love this, because it would provide one consistent method of navigation and would mean that all of KDE's software would reuse the same module for this important ability.

Whatever we decide we would need an implementation for KEditListWidget https://api.kde.org/frameworks/kwidgetsaddons/html/classKEditListWidget.html

In lots of KCMs we show this on-hover, do we have any consensus regarding that?

Update: all, except the archiving step, are done for games.k.o:

• "How to play" sections are shown for games having the data. These sections can also be translated;
• Accessing games.k.o pages will redirect to corresponding parts on apps.k.o, except games.k.o/old and its subpages which are left untouched.

In T10827#271310, @felixernst wrote:

I haven't done a lot of webpage work but from what I can tell this seems like a solid plan.

How do you think?

So as I can see, the 3 websites that are equivalent to categories of our apps, edu.k.o, multimedia.k.o, and utils.k.o, are still alive and really outdated, even though we already have some other plans for them. The other category-equivalent one, games.k.o, although has been ported to Jekyll, I think can still be improved.

This is done now in Dolphin 22.04! See https://invent.kde.org/system/dolphin/-/merge_requests/309

Of the current suggestions, the last one certainly is ideal – although not mutually exclusive of the previous suggestions – because the more that is automatic, the superior that the toolkit is. Obviously this is not inferent advocation for removal of the ability to override, but merely that it should not be necessary unless designing custom appearance of software. Consistency is the ultimate goal.

I am believing that the colouration of "http://phabricator.kde.org/file/data/to7e46zbo7jhwg6mbwv4/PHID-FILE-7qs7usxqzpuvfwbsrgis/sheets_alt.png" is superior, because ascertainment of which tabs are active and inactive is significantly more easy than within "http://phabricator.kde.org/file/data/4mp4omhmpt3j7mxtin42/PHID-FILE-md7fdorexja3vakdh5to/sheets.png".

The first proposal that is similar to the interface of Microsoft's Word, and the interface that is present for Gemini are utterly unsuitable for Calligra, because they are not adherent to any of the appearances of current Qt software that has been created by KDE, and are consequently more inconsistent.

Why not utilise the tree-view that is present within the "Folders" panel of Dolphin? That would mean that retainment of the current organisation is possible, without ascertaining how to improve the current weird implementation of multiple side-bars. Additionally, because addition of KConfig Modules to systemsettings5 by many distributions shall continue, organisation would be more easy, because the tree-view would adapt properly.

Why have so many people proposed static sizes if iconographic configuration is available within "kcm_icons"? Adherence to what has been specified by the user is certainly more consistent behaviour. This is important to me, because I have never desired utilisation of anything but 16-pixels for iconography, because the resolutions of my screens has been minor enough that iconography of more great resolution has been detrimental. Additionally, quick ascertainment of what the colourative/colourful iconography that has been proposed is intending to communicate is not as easy for me as the current iconography.

If you mean a video player, there's Haruna, which is QML and works quite nicely, but it does need a bit of UI polish IMO.

Yes, there's Elisa. It's playing music for me right now. :)

In T12667#220236, @ngraham wrote:

Konqueror and Amarok are unmaintained.

DragonPlayer and KMPlayer seem to be on life support, nearly unmaintained.

Apper, Muon, and Dolphin are each used for different things.

Dolphin and Krusader target different users (normal user/expert user).

It's the same with KWrite.

It seems like the issue here, if any, is that these apps don't make their intended audience and features obvious enough on https://kde.org/applications

@resdex there are no updates. In last KDE Sprint it was decided that such an effort it eould require man power and commitment and there was noone that step in and say, I want this and I will lead the effort.

I guess something I am missing is the "WHY?" part of the argument. Why should Plasma integrate at a default level with Latte?

@mvourlakos Do you have any updates on the current state of this topic?
What I would like to see, when using latte dock, is that it gets rendered before the Desktop is ready.
Right now after the Splash Screen I see my Wallpaper, and it takes 2-3 seconds for latte to start and render the dock.
You can make some beautiful Desktops with latte-dock. It would give plasma a boost if people could generate Global Themes with a latte-configuration that is a 1 click install.

These post makes some mention of inconsistencies in some KCMs:

In T11227#261226, @felixernst wrote:

Is this meant to only be used as launch feedback?

Yes, I just replaced the current spinner icon we have in the task manager now. It shows up when the window didn't appear yet.

In T11227#261191, @GB_2 wrote:

Indeterminate Progress Bar
Used when the progress is unknown at first, but can be determined after some time.

Here is my proposal for this topic.

Yeah, enforcing wasn't a good word in this context.

In T12435#260970, @fhek wrote:

Personally I think this would be a good layout to enforce onto our applications

Sure but I think we should make it easier to follow the HIG, creating common components, good defaults, etc...

https://develop.kde.org/hig/ < let's not reinvent the wheel. Whatever is there can be addressed if it doesn't fit. If an application doesn't fit the HIG it can definitely be addressed.

Personally I think this would be a good layout to enforce onto our applications:

Kontact is just a shell around kmail, korganizer etc. Some note-taking / todo apps seem to be duplicated though, but whatever surivves needs to integrate into kontact, imho.

There is also the new KDE media player https://invent.kde.org/multimedia/haruna, which is quite good IMO.

Whatever we decide we would need an implementation for KEditListWidget https://api.kde.org/frameworks/kwidgetsaddons/html/classKEditListWidget.html

FWIW we already have a red X we could use for permanent deletion, but now lists use red trash cans instead...
Right now the only thing distinguishing permanent and reversible deletion is the trash can color. Not good for accessibility.
Having only black trash can icons for reversible deletion and the red X for permanent deletion like I proposed would fix this.