Welcome to a new issue of "This Week in KDE Apps"! Every week we cover as much as possible of what's happening in the world of KDE apps.
As with most very visible changes, the response to this was mixed. We are currently working on options that will hopefully make everyone happy.
How about keeping the old one with “(legacy)” added to its name so if someone feels really strongly about it they can just replace the new one with the old one on their system. And just keep it in there as long as it works, with the maintainance burden placed on the reddit bullies, etc., and if they don’t keep it working, get rid of it.
@eeeeeeeeee, the implementation that replaces the vertical-lined one shall, in effect, merely be the old one. Its sole noticeable differentiator should be that it’s now evidently a QLineEdit, or an imitator thereof. Certainly, the commonly expressed criticisms shall be remediated, including chevron replacement.
Would it not be easier, in terms of chat app development, if instead of duplicated effort (implementing the same chat features over and over), KDE’s various chat apps (NeoChat, Kaidan, etc) would be united on the surface (including releases, documentation, webpage, UI and API), and have different backend modules for each protocol (like Pidgin used to do), selected upon account login?
This way the user would not have to know which app is for which protocol, and just open the “Messages” app, select the account in the sidebar, and start typing.
So an unified UI would be created, with a standardized backend API, and the NeoChat backend code would become a Matrix module, the Kaidan backend code would become an XMPP/Jabber module, then there could be an SMS/RCS module for phones, a KDEconnect module for handling SMS/RCS through KDEconnect from another device, a Fediverse module, a Nextcloud module, a Google Chat/Hangouts/Allo/etc module, an IIRC module, a Telegram module, Viber module, etc…
If this is not feasible, why?
@koma111, I’ve wanted to know, too. That’s one of the reasons that I used to use Pidgin, back when it was more viable. Considering they do this for Discover, it’s not unprecedented.
With regard to location path in Dolphin, after spending half of day with latest change and half of day with Plasma 5.27, I dislike the new one enough to ask for revert (I know it’s just one voice out of many, so this is not a demand, just +1 for old looks), I don’t see anything improved about the new one. It takes more space, it’s visually more intrusive, the icons per every folder make little sense to me, and old one worked as I expected so much that I never really even paid attention to how exactly it looks and how it works.
Not a developer myself, but I would assume the challenge is in creating abstractions out of each chat protocol’s parts, and then presenting them in an integrated interface that would make more sense for the user than if they were separate applications. The interface you’d need to work with individual or group “direct messaging”, like SMS/RCS, seems like it would need to contain different mechanisms than those designed for social media “posting” like Fediverse, which would have different mechanisms than those designed for real-time “chat rooms” like Matrix.
Maybe possible, but it doesn’t seem trivial on the face of it, given how different the intent of each platform seems to be - ex. I can’t send an invite to an existing group SMS chain like I can on Matrix, I can’t logically “repost”/“boost”/whatever on Matrix like is possible on the Fediverse, etc.
Related to Discover @rokejulianlockhart - I feel like one major way in which that’s different is that it’s consumption, but not publication. Folks aren’t also using Discover to publish applications to each of those repositories - the fact that these communication protocols are bidirectional by their nature seems like a big step up in complexity. An application in a distribution repository also seems more similar to an application in Flathub, in terms of the data constructs needed to interact with it, than a SMS message is to a Fediverse post.
But someone much smarter than I am probably has some practical idea on how to tackle all that 
@johnandmegh, any consolidator would need to choose to support either synchronous or asynchronous communication methods. Consequently, I presume their question referred solely to SMS, MMS, RCS, XMPP, and Matrix, rather than ActivityPub and ATProto, etcetera.
Indeed. It’s undeniably possible, but whether it’s feasible would be quite a matter of how well the supported protocols lend themselves to sensical abstractions. Fedilab merely supports AP-integrated solutions that adhere to Mastodon’s superset thereof, and Pidgin’s support for anything but XMPP is poor.