New SMS client for KDE Connect (feedback welcome)

[Albert Vaca Cintora]

Hi Steve,

When you say backend, you mean the Android side, or the desktop/Qt side (or
both)? Some of the issues you described might be fixed in newer versions of
KDE Connect, but I'm sure there are still bugs.

About the dev environment to work on the desktop app: What I do when
developing KDE Connect is building locally and installing system-wide as
root, instead of using kdeconnect from the package manager. The command I
use to build, install and run is: make -j20 && sudo cmake --install . &&
kdeconnectd --replace. That's to be triggered from the cmake build
directory.

To build from the master branch, however, you will need some newer
dependencies than what Linux Mint ships, which is 3 years old. I would
recommend getting a distro that updates software more often. Both Fedora
and openSUSE Tumbleweed ship the latest kdeconnect 26.08.1, which means
they will also ship every dependency you need to build from master. You can
of course use a VM if you don't want to replace your Linux Mint, but it's a
bit less convenient.

About backwards compatibility across components, depending on the boundary
there are different considerations:

- Between the Android and desktop apps, adding new fields to the packets
won't break anything, but we can't remove old stuff. We can also assume
that people will most likely update the Android side faster than the
desktop (because of distros like Ubuntu and Linux Mint, which ship old
stuff), so it's more important that newer versions of the Android app work
with old versions of the desktop app than the other way around.

- Between the desktop daemon and clients talking about DBus, while some
DBus implementations might care if we change the return type, many won't.
Also, our main DBus clients are our own QML apps, and since we ship them
together they will always match the daemon. So if it's very easy to do we
can keep the old methods and add new ones, but if it's complicated it's
okay to just replace them.

The changes you suggested, like adding error status as return values or a
cancellation token, make sense to me. We can discuss them more in depth in
MR comments.

Albert

On Tue, 22 Sept 2026, 04:55 Steve Benz, <s8878992 at hotmail.com> wrote:

> 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.
>
>
>
>> [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.
>>>
>>>
>>>
On Tue, 22 Sept 2026, 04:55 Steve Benz, <s8878992 at hotmail.com> wrote:

> 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.
>
>
>
>> [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/20260923/7c43d96c/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/20260923/7c43d96c/attachment-0001.png>