New SMS client for KDE Connect (feedback welcome)
Steve Benz
s8878992 at hotmail.com
Tue Sep 22 03:55:18 BST 2026
Hi, no I did not see your previous email. Some responses inline, but
the TL;DR is:
* I'm glad you guys tried it out and found problems, that's what I was
hoping for at this stage. It doesn't meet my requirements for
shipping either. I'm just looking for some visibility and other
eyes on it at this point.
* I agree there's some stuff with the interface that need addressing,
but the real meat of the matter is the back-end. It's just not
reliable at all (at least on the Linux Mint Cinnamon version, which
is hopelessly out of date: 23.08.5).
* It's gonna be painful for me to work on the back-end, as I can't
compile the tip of master on Linux Mint Cinnamon and won't have a
shot at it until the next major release (which is slated for
December). Maybe I need to just get good at working in a VM. Maybe
I'm holding it wrong and it's not that hard?
On 9/16/26 2:04 AM, Albert Vaca Cintora wrote:
> 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.
>
Honestly, I don't remember the shenanigans I had to pull to make that
happen. For background, I'm a retired software engineer and I recently
decided to switch back to Linux after spending most of my professional
career in the Windows/.net/Javascript world. When it comes to these
build problems with shared libraries, all the advice appears to me to
largely guesswork and I just have to rely on what ChatGPT/Gemini think
'cause I can't see a pattern in any of this stuff yet.
> - 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.
>
Good catches there - I'll have a look at that.
>
> - 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).
>
I suspect you'll find it's a mixed bag. Search isn't done, but it has
features for recognizing 2fa codes, for example.
>
> - 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.
>
Yes. That's actually one of the reasons I think a rewrite is the way to
go. The service maintains a cache in-memory. It feels very much like
the original app was written with the goal of getting something working
out the door. That's a pretty reasonable goal, but it wasn't followed
up with a more complete answer.
The better answer to caching is always to let the clients do it -- the
client knows how much to cache and what retention policies to apply.
Further, if you look at the client's message list code, it's got some
really sophisticated stuff for only requesting more content if the user
scrolls up. That's well-intentioned, but ListView is already
virtualized and thus it's redundant. A better strategy for
conversations that have never been seen before would be to ask for the
whole conversation and cancel the request if the user clicks away. You
never know what the user's next move will be - they might scroll up, or
they might want to search, and in any case, sucking the conversation off
of the phone means it'll be available next time if you have a
/persistent/ cache, which is what my app does. It has a persistent
cache, meaning that you can pull up the app and have it be functional
even if the phone is unreachable.
> - I sent a message from my phone, but on the app the conversation
> didn't update until I clicked it.
>
I'd bet that the problem there was with the back-end, not the app
itself. I've seen things like that happen while I've been monitoring
dbus traffic. It seems like sometimes the SMS service just becomes
disconnected with the phone. For example, the other day I noticed that
things had gone awfully quiet. I started the stock SMS client and it
just hung there with a blank screen. Even though Device::isReachable
was returning true, calls to requestAllConversationThreads were
succeeding, but no traffic got generated.
What I found absolutely confounding in that circumstance was that thinks
like clipboard sharing were working splendidly. And making things even
stranger, was the fact that restarting kdeconnectd did not fix the
problem condition /and yet rebooting my PC did!/ I'd think that if
restarting the daemon didn't fix it that it must indicate some problem
in the phone agent, but if that's so, why did rebooting make it better?
Baffling.
> 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.
>
How do you feel about backwards compatibility? From what I understand,
even a change like changing 'sendWithoutConversation' from returning
void to returning an 'int' to give you an error code would break
existing apps. I think it'd be reasonable of you to ask me to create
either a new interface or extend the existing interface by adding new
methods.
I feel like just about every single method needs to be touched in some
way or another - particularly to make sure every method returns some
kind of success/failure indicator. Some, like 'requestConversation'
should return a token that can be used for cancellation or for
identifying when a message comes as a response to the query vs. simply
being a new arrival. I'd like to make sure that we're all happy with
the interface before embarking on implementing code. Likely I'll submit
a change request that's just the interface which we'll discard as soon
as we're happy with it and I'll follow up with an implementation.
> 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.
>
According to ChatGPT, PhoneLink is using push notifications, which
you're right to want to avoid. ChatGPT also said that some phones,
particularly Motorolas, have vendor-specific api's which do allow waking
the phone. Funny thing though, I've seen my phone listed as
"unreachable" when it's definitely "awake" (e.g. locked, but playing
music.) So maybe "awake" has some shades of meaning. Anyway, it's not
the top-priority.
> 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? :)
>
I can do that, but there's a third thing it needs: Me to feel good
about it, which right now I don't, largely because it doesn't achieve
the core objective I wanted to get to: A world where I can sit down at
my desk and immediately see all the text messages I've got. Right now,
that fails because of at least two back-end problems, foremost among
them that it looks like the back end doesn't know that it woke from sleep.
>
> 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/20260921/d23eb0c7/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/20260921/d23eb0c7/attachment-0001.png>
More information about the KDEConnect
mailing list