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.

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.

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 because performance is important, window-borders are important, but the current options are weird: why provide presets of sizes rather than merely allow input for how many pixels the border should occupy for the sake of customisability, or configure it to be 1 pixel for the sake of consistency? Winaero Tweaker for Windows is able to provide this, and it is very important because during utilisation of multiple instances of "file://%systemdrive%/Windows/explorer.exe", ascertainment of where the edge of each window is is not easy. This is problematic for accessibility and general utilisation of slow computers.

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.

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 am loving the line-art iconography because my opinion of the colourful iconography is that it is significantly ugly. The ugliness has forced me to configure "kcm_icons" to utilise 16-pixel iconography for all that it is able to control, which is not ideal, but adequate, so please do not modify them more. Colourful iconography is not ideal for any resolution, but this is solely, and significantly, obvious during utilisation of it for small resolutions. Additionally, I am agreeing with all that has been stated by @itsjustarumour and @trapped-in-dreams.

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.