New SMS client for KDE Connect (feedback welcome)

[Albert Vaca Cintora]

Hi Steve, did you see my previous email?

On Mon, Aug 24, 2026 at 1:13 AM Albert Vaca Cintora <albertvaka at gmail.com>
wrote:

> 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/20260916/7b6531a0/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/20260916/7b6531a0/attachment-0001.png>