New SMS client for KDE Connect (feedback welcome)

[Steve Benz]

I got a VM Running Opensuse Tumbleweed (which I believe is running a 
recent version of KDE Connect) and, after much warring with the network, 
got it up and reproduced the Red-Dot bug.  It actually turned out to be 
a bug that's really just specific to first-time-run, rather than any 
change to the dbus.  It also self-corrects, given enough time, which is 
why it came alive for you (had nothing to do with running the old app, 
it was just the poll-timer going off.)

You can pull the latest from my branch, but if I understand the bug 
correctly, you can run the code you have and it'll work.


On 8/12/26 11:11 AM, Steve Benz 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/20260823/6fe82b9e/attachment.htm>