From s8878992 at hotmail.com  Sun Aug  9 23:18:31 2026
From: s8878992 at hotmail.com (Steve Benz)
Date: Sun, 9 Aug 2026 15:18:31 -0700
Subject: New SMS client for KDE Connect (feedback welcome)
Message-ID: <DS0PR08MB110388BC3907130171E255CE981DF2@DS0PR08MB11038.namprd08.prod.outlook.com>

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/20260809/49c79694/attachment.htm>

From simon at ergotech.com  Tue Aug 11 02:41:05 2026
From: simon at ergotech.com (Simon Redman)
Date: Mon, 10 Aug 2026 21:41:05 -0400
Subject: New SMS client for KDE Connect (feedback welcome)
In-Reply-To: <DS0PR08MB110388BC3907130171E255CE981DF2@DS0PR08MB11038.namprd08.prod.outlook.com>
References: <DS0PR08MB110388BC3907130171E255CE981DF2@DS0PR08MB11038.namprd08.prod.outlook.com>
Message-ID: <70b7b79e-056f-4685-bf78-7fcbca814f8a@ergotech.com>

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/20260810/e895db12/attachment.htm>

From s8878992 at hotmail.com  Wed Aug 12 19:11:45 2026
From: s8878992 at hotmail.com (Steve Benz)
Date: Wed, 12 Aug 2026 11:11:45 -0700
Subject: New SMS client for KDE Connect (feedback welcome)
In-Reply-To: <70b7b79e-056f-4685-bf78-7fcbca814f8a@ergotech.com>
References: <DS0PR08MB110388BC3907130171E255CE981DF2@DS0PR08MB11038.namprd08.prod.outlook.com>
 <70b7b79e-056f-4685-bf78-7fcbca814f8a@ergotech.com>
Message-ID: <LV0PR08MB110365C6B4F00337E8FBCA71481DC2@LV0PR08MB11036.namprd08.prod.outlook.com>

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/20260812/27250d8b/attachment.htm>

From albertvaka at gmail.com  Mon Aug 24 00:13:29 2026
From: albertvaka at gmail.com (Albert Vaca Cintora)
Date: Mon, 24 Aug 2026 01:13:29 +0200
Subject: New SMS client for KDE Connect (feedback welcome)
In-Reply-To: <LV0PR08MB110365C6B4F00337E8FBCA71481DC2@LV0PR08MB11036.namprd08.prod.outlook.com>
References: <DS0PR08MB110388BC3907130171E255CE981DF2@DS0PR08MB11038.namprd08.prod.outlook.com>
 <70b7b79e-056f-4685-bf78-7fcbca814f8a@ergotech.com>
 <LV0PR08MB110365C6B4F00337E8FBCA71481DC2@LV0PR08MB11036.namprd08.prod.outlook.com>
Message-ID: <CAAQViEuPPRanvFucyZb2sgBhe3LAX8Gq_AJhZSHvs1=HEE+Wvg@mail.gmail.com>

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>

From s8878992 at hotmail.com  Mon Aug 24 03:49:33 2026
From: s8878992 at hotmail.com (Steve Benz)
Date: Sun, 23 Aug 2026 19:49:33 -0700
Subject: New SMS client for KDE Connect (feedback welcome)
In-Reply-To: <LV0PR08MB110365C6B4F00337E8FBCA71481DC2@LV0PR08MB11036.namprd08.prod.outlook.com>
References: <DS0PR08MB110388BC3907130171E255CE981DF2@DS0PR08MB11038.namprd08.prod.outlook.com>
 <70b7b79e-056f-4685-bf78-7fcbca814f8a@ergotech.com>
 <LV0PR08MB110365C6B4F00337E8FBCA71481DC2@LV0PR08MB11036.namprd08.prod.outlook.com>
Message-ID: <DS0PR08MB1103895E5392DABD0E06946F281A02@DS0PR08MB11038.namprd08.prod.outlook.com>

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>

From acidrums4 at gmail.com  Mon Aug 31 01:31:32 2026
From: acidrums4 at gmail.com (acidrums4)
Date: Sun, 30 Aug 2026 19:31:32 -0500
Subject: About the home page redesign for KDEConnect's Android app
Message-ID: <CA+Yz-x2nJ8xHGfQDvYtHqs=+QoDMfmsWVS0Y499EXMeAxm_DAA@mail.gmail.com>

Greetings,

Just saw the redesign for KDEConnect's Android app:

https://tintotint.eu/programming/kde-connect2/

Everything looks nice, but I felt like the home screen is visually
cluttered and thus disconnected of what is being show for the other screens
of the app, where everything looks rather clean and much more akin to the
android visual guidelines.

I ignore how this kind of things should be managed or how are things going
on with the VDG, if they ever had a hand redesigning KDEConnect's android
app, but I did a quick mockup of some ideas - trying to remove redundant
things, using fewer icon sizes and styles and moving a bit closer of the
proposal for the other screens. Also it frees some vertical space.

Please ignore the icons and the typeface I'm using here, though, as I'm
doing this in a hurry. I can provide custom SVG icons specially made for
KDEConnect if needed - I happen to be a graphic designer.

I am doing this here as I couldn't find a way to reach the person doing the
aforementioned blog post via mail nor submit an issue at GitLab.

Best regards and thank you all for the good work on this
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20260830/315bfdef/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image1.jpg
Type: image/jpeg
Size: 726046 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20260830/315bfdef/attachment-0001.jpg>

