Which evolution?

Dear Kate Development Team,
I am sending you this email to ask you a question: where is KDE going? 
Let me explain. A long time ago a certain college student named Matthias 
Ettrich posted an e-mail announcing the birth of KDE. In it he stated 
his intent to give life to a desktop under Linux and one of the 
objectives was that of the consistency of programs following common 
guidelines.

About two decades have passed since that day and KDE has matured as well 
as the Qt libraries that are its foundation. Now KDE applications can 
work, obviously recompiled, both under Microsoft Windows and Apple Mac 
OS X but something has been lost: the much desired consistency of 
applications in their UI!

The problem of UI consistency is a problem that arose at the dawn of the 
birth of graphic environments. Who remembers Smalltalk? Or the Xerox 
Alto? I believe very few. Then Apple arrived and with the Lisa took the 
concepts developed by Xerox and put its own. We know how it ended but 
its failure generated the Macintosh, the original one, where the 
concepts of the Lisa were taken and refined, especially by simplifying 
them due to little memory!

Time passes and so did the Macintosh change and what did Microsoft do? 
He took a little bit here and a little bit there and created Microsoft 
WIndows. I bet some of you like me have known about Windows 3.0 or 3.1. 
The PC became cheaper and GUIs became the norm. Then one day, over there 
in Finland, a rather thin baby was born, without great pretensions, the 
result of the work of a certain Linus Torvalds. The baby quickly grew 
and finally received KDE as a gift in 1996. Now we come to our days and 
here begins the reason for my emails.

Remember what one of KDE's goals was? Consistency in applications or 
never reinvent the wheel. One of the objectives of the UI is to 
simplify, better organize, intuitively the user's activity. What is the 
purpose of the menu bar? Logically organize user operations. According 
to the KDE guidelines, the File menu must manage everything related to 
the creation, loading, saving, printing and closing of the application 
while the Edit menu must manage all the operations related to the 
selection of the text or other within the work area inside the main 
window, the View menu for managing what is presented in the main window, 
the Settings menu the program settings and finally in the Help menu 
which provides aids on the program such as access to help on that 
program in addition to accessing information about that program.

Obviously the guidelines for graphical interfaces exist in abundance but 
we are obviously interested in those of KDE, those of today's Mac OS X 
and Microsoft Windows. I added the last two because KDE also operates 
under these two environments. These are the respective links 
(https://develop.kde.org/hig/introduction/; 
https://developer.apple.com/design/human-interface-guidelines/platforms/designing-for-macos/; 
https: / 
/download.microsoft.com/download/2/4/A/24A81A29-77CF-4AA5-967E-64E42554F21B/UWP%20app%20design%20guidelines%20v1509.pdf). 
On the guidelines of Microsoft Windows we draw a painful veil since in 
the course of its life it has been turned over several times not to 
facilitate the user but to make money! You have to force the user to 
have to relearn the use of an application from scratch, otherwise what's 
the point?

Now you can explain to me the rationale of creating two new menus such 
as Select and Go when logically in the first there are items that fall 
under the Edit menu while in the second there are also items that, 
logically and in the style of the UI, appear here. also under the Edit 
menu? Then there is an API problem. Under KDE KStandardAction covers 
some of the actions and it doesn't seem to me that KStandardAction :: 
selectAll () or KStandardAction :: deselect () have been moved from that 
menu. Yes, there is a problem with the Go menu under KDE but usually the 
Goto Line ... or Goto Page ... command in editors ends up under the Edit 
menu. But the last treat was putting the Bookmarks menu inside the Go 
menu! And here too this clashes with the KDE API, again with 
KStandardAction! The addBookmark() and editBookmark() functions ...

I understand that Kate is no longer the application born in origin, just 
look at the source code of the distant KDevelop 1.0 with which it has 
been linked since its origins, I understand that many functions have 
been added but that consistency of the graphical interfaces that was the 
goal of does 1996 still exist nowadays? I'll give you some examples that 
have left me dumbfounded: Kate, these latest versions; KDevelop starting 
from version 4.0; Kexi and the Calligra suite. I'm discussing Kate with 
you but KDevelop is, pardon the term, on the edge of decency. If KDE was 
to be based on application consistency, KDevelop almost reaches its 
limits. With Kexi sia reaches the highest levels, we are at "I wish I 
was a Microsoft product"! About two years ago I happened to have to use 
one of the latest versions of Microsoft Word, you know the ones with the 
Ribbon interface. Do you know what my feeling was trying to figure out 
where the print command was which he later found to be in the system 
menu? Choking Bill Gates after forcing him to eat banknotes in profusion.

Consider what I wrote as a complaint or complaint from an old computer 
enthusiast who started using Linux on a now forgotten Slackware 1.2. To 
make a comparison, how would you drive a car where you suddenly 
discovered that the steering wheel acts as an accelerator, the left 
pedal steers the car to the right and the right the reverse and the 
gearbox is reversed. A nice car to drive, don't you think? I end this 
email with a memory from the past 
(https://kde.org/announcements/1-2-3/1.0/).

Yours sincerely,
Giovanni Corriga.