@aronkvh, if there's anything else tracking the sidebar adhering to kcm_style's icon enablement preference:

Note that this mockup appears to, in its bottom-left, provide an example of what invent.kde.org/teams/vdg/issues/-/work_items/29 would look like, implemented.

This has been reached in large part with the first rollout of MyKDE

==== #278016 ====

Dolphin still doesn't look anything like this and even that cyan border is still there. While I understand the need to redesign a major app, all the other QT apps look just as bad or worse. A lot of this is down to the theme engine.

If of any use, this is labelled as "Needs review", but https://invent.kde.org/system/dolphin/-/merge_requests/895 seems to supersede it.

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

Yeah, only the very cheap ones have it nowadays. We are now in the era of giant screens, there's no space for an entire row of hardware buttons.

@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.

@vivekanandanks, having Neon be immutable wouldn't be a great idea, considering that its entire purpose is to evaluate changes. Immutability is useful for security and stability, which are of significantly less concern - or are an impediment - in development-oriented testbeds.

Thank you, @davidedmundson.

This is functionality that I thought only I wanted. I'm glad to see that there's interest. However, I dare say that I do, to an extent, agree with @redstrate - I wouldn't by default consider this to be the purview of the KDE organisation itself. After all, since:

I realize that I only know so much about this topic, but I believe that I agree with the point that @gcb has made (although I'm convinced that anything at the initialisation system or kernel level would actually be versatile enough to provide the permission model that we desire).

Since the last mention of this appears to be a while ago, I'll note that I've experienced this - specifically, https://phabricator.kde.org/settings/user/rokejulianlockhart/page/email/ is not synchronized to https://identity.kde.org/index.php?r=people/editEmailAddresses&uid=rokejulianlockhart, as I expected it to be.

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

I prefer actions always being in a sidebar, especially via mobile, so I believe that mimicking how desktop applications provide their actions is regressive.

My grandmother has a seriously difficult time trying to understand the colourful iconography unless it's very, very large, whereas she finds the simplistic icons comprehensible. However, having them solely become that at ≤ 16px renders them too small for her to discern.

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.

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.

My favourite of "http://phabricator.kde.org/file/data/6whyyim5gmlkquf4loar/PHID-FILE-wwndftrzby5fixz2nswm/export.png" is the top-right version, because the current presence of iconography is without necessity or benefit, and because removal of it is important for phone-screens because they are primarily vertical and small. Retainment of the title-bar is necsssary not merely because otherwise it may appear to be fake, but additionally because removal of it would be detrimental to consistency, which although is eternally important, is currently especially important: "http://phabricator.kde.org/T11093".

This question may appear to be silly to many developers, but why not invoke dolphin for utilisation as the file-picker, or allow configuration of the default chooser?

When not utilising shadows around window borders due to performance limitations on old machines, a 1px border is necessary. Windows 10 already provides this, and you can see the problems that removing it causes (via WinAero Tweaker) on that OS when you spawn multiple instances of explorer.exe. The same applies to Plasma.

The colouration of https://phabricator.kde.org/file/data/to7e46zbo7jhwg6mbwv4/PHID-FILE-7qs7usxqzpuvfwbsrgis/sheets_alt.png is the better design, because ascertaining which tabs are active or inactive is easier than in https://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.

I am liking the compartmentalisation of the viewers so that they are similar to what has been implemented by Dolphin, but I am confident that the background should adapt to the theme of the host by default, because that is more consistent, and because contrast has not been problematic for me during observation of files within Okualar, and may appear to be quite ugly to new users.

The sidebar should not utilise text below iconography, because that is significantly less consistent, and is additionally less sensibly adaptive if the constituents of the text that is beneath it are more than approximately 4 letters.

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.

"http://phabricator.kde.org/T11663#212651" is my favourite, because which path is for which tab is obvious. Having the bar dynamically adjust is not intuitive, and if many tabs are present, is able to inhibit productivity if the user is duplicating multiple paths to their clipboard.

I agree with all that has been stated by @itsjustarumour and @trapped-in-dreams. However, I also find the colourful icons a damn lot more difficult to parse.

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.