New SMS client for KDE Connect (feedback welcome)

[Albert Vaca Cintora]

I just gave it a try and it looks promising, thanks for sharing! Some
initial feedback (part of it overlaps with Simon's):
- I had to modify kpeople_lookup to build against Qt6/KF6, since the latest
version of KPeople is Qt6. Does your distro really ship a Qt5 version only?
I guess that's the reason for the separate kpeople_lookup binary... in
theory you should be able to simplify that to a single binary and be fine
on most distros.
- Visually it breaks a bit in dark mode (see screenshot below).
- There's no keyboard navigation: after clicking on a conversation on the
left side bar I was expecting the up/down keys from my keyboard to move
through conversations.
- I think functionality-wise is a bit behind kdeconnect-sms, for example it
doesn't have search (I wanted to text a specific person and I had to
manually look for them).
- It loads conversations and messages much faster than kdeconnect-sms! I
have a long list of conversations, and kdeconnect-sms struggles to fetch it
every time I open the app.
- I sent a message from my phone, but on the app the conversation didn't
update until I clicked it.

I saw in your TODO that there are some fields that you would like the KDE
Connect API to provide, like some extra IDs and indices. Feel free to
modify the code and send a merge request explaining why they are
needed: there should be no issue adding them if they enable a better user
interface.

As Simon said, waking up the phone is not possible, so instead we might
need some way to indicate a message is "pending" (not sent yet) until the
phone is reachable again. I'm not sure if there's a response back from the
phone saying "the sms is now sent", but if not that might be something that
we could add to help close the loop for that interaction. Windows Phone
Link might use push notifications to "wake up the phone" (or rather, ensure
it runs Phone Link the next time it wakes up to check for push
notifications), which we want to avoid because push notifications need to
go through Google servers, while KDE Connect is fully local.

About upstreaming the app, I think it would make sense if it can eventually
fully replace the current SMS app, which would require two things:
- This app should cover every use case that the current kdeconnect-sms app
does (ie: implementing missing features like search, dark mode, starting a
new conversation, etc).
- Your commitment to continue to maintain it in the future. This is
probably the most important part. Would you be willing to do that? :)

[image: Screenshot_20260824_000337.png]

Nice job and thanks for your email!

Albert

On Wed, Aug 12, 2026 at 8:42 PM Steve Benz <s8878992 at hotmail.com> wrote:

> Thanks for giving it a try and sorry it didn't go well.  I had a VM up a
> few months ago which could compile all of kde connect, but it was painful
> to work in the VM, so I abandoned it to go back to developing on my Mint
> desktop.  I'll see if I can get it up again.  What distro would you suggest
> for this?  Skynet thinks OpenSUSE Tumbleweed.
>
> The symptoms you're describing make me think that it somehow couldn't run
> requestAllConversationThreads but was able to process signals.  If you
> could supply me the console output, I'd know more.
>
> I'm returning to Linux&C++ after many years in the JavaScript and dotnet
> world, and I'm still struggling to navigate the world of distros and
> patches.  The KPeople thing was me just trying to get something/anything to
> work; I figured once I could get it into a testable state I could get some
> help figuring out the right path or perhaps updates would make a simple
> path obvious.
>
> You mention that waking the phone through the API was not possible.  I've
> seen that on other sources as well.  But...  The Windows Phone Link app
> seems to be able to do just that.  Although, maddeningly, the thing doesn't
> do it automatically.  You open the app, it gleefully tells you that the
> phone's not connected and gives you a button to press. You press the
> button, spinnies spin for a few seconds, and your conversations update.  I
> don't know how it does that, but that's what happens.
>
> As to the tray icon, Qt Creator created my initial version with a
> QGuiApplication and I figured that was a well-reasoned choice and stuck
> with it.  But apparently, it's not really all that great a choice and you
> can just switch it to a QApplication (and add a #include <QApplication>)
> and that seems to just work.  From what I understand, the QSystemTrayIcon
> will, on some desktops, fall back to using a QWidget if it can't use a "SNI
> backend".  Whatever that is.
>
> Anyway, I'll see about getting that VM up and reproduce the problems you
> describe.
>
>
> On 8/10/26 6:41 PM, Simon Redman wrote:
>
> Hi,
>
> Thank you for your interest and enthusiasm. I gave this app a try. It took
> a few patches to get it launched: The contact loader is targeting KF5
> KPeople, and the main app calls qFatal if the KF5 loader can't execute,
> effectively requiring both KF5 for this app and KF6 for the KDE Connect
> daemon.  It tries to construct a tray icon with a QGuiApplication, which
> crashes due to not being able to create a QWidget without QApplication (at
> least on Plasma desktop). After launching, I just had a box with a red ! in
> the top left. Once I used the main SMS app to download a conversation, that
> conversation showed in the new app, so potentially it is not compatible
> with the latest version of the daemon.
>
> Since you discuss the plugin API in the README, I'd be happy to help guide
> improvements there. Search, for example, would be cool to have. I'd
> recommend you start by writing down the API you envision and discussing it
> here or on Matrix. Some of the things you have highlighted in the new SMS
> README are not possible, so I don't know what else you might be thinking
> and I wouldn't want you to start down a path which is known to be blocked.
> For example, Android does not expose an API to wake the phone. As a
> side-note, I would advise that the Android SMS-fetching APIs are quite
> poorly documented and several are vendor-specific. I'd recommend not
> touching those, however I'd be open to a better way of presenting the data.
>
> In general, I would encourage people to contribute to the main app if they
> find it is not sufficient. I am not protective of the current version, I
> would be excited if someone with UI expertise rebuilt it. Recently a
> community member re-worked message loading, and now navigation/scrolling on
> the official app is drastically improved.
>
> Thanks,
> Simon
>
> On 8/9/26 18:18, Steve Benz wrote:
>
> I’ve been working on a new SMS client that integrates with KDE Connect,
> with the goal of addressing some long‑standing usability and reliability
> issues in the existing SMS app. It's at a point now where it's ready for
> more people to try it out. I hope you'll find that you much prefer it over
> the existing sms app.
>
> The code is here: https://github.com/NermNermNerm/smsapp.git
>
> And I’ve made a prebuilt release:
> https://github.com/NermNermNerm/smsapp/releases/tag/v0.0
>
> I’m looking for feedback from people familiar with KDE Connect’s SMS
> plugin. The biggest limitation right now is reliability — I’ve added
> defensive logic to work around some of the plugin’s quirks, but there are
> structural issues that can’t be solved on the client side alone. I wouldn't
> want to put this thing out into the world without addressing that.
>
> Before I go further, I’d like to hear what the community thinks: whether
> this direction makes sense, whether there’s interest in improving the SMS
> plugin itself, and whether this could eventually be something worth
> upstreaming.
>
> If you have a few minutes, I’d really appreciate you giving it a try and
> sharing your thoughts.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20260824/16159382/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot_20260824_000337.png
Type: image/png
Size: 136555 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20260824/16159382/attachment-0001.png>