As a happy user of many KDE based programs (konsole, kate, dolphin, etc) it's great to see another KDE piece evangelized.
But can someone state conclusively if Bluetooth-base connectivty in KDE Connect actually works in 2025? I looked into this a few weeks ago and it seemed liked from mailing list posts until Bluetooth functionality in KDE Connect equals WiFi connectivity the feature is not enabled?
When traveling it's much easier to do "point to point" between laptop and phone and in theory Bluetooth can support this easier than WiFi via third-party access-point or having to mess with WiFi direct.
At least in my use case (as link between Android devices and both Linux/Win PCs) KDE Connect is a real killer app. It enabled seamless integration and saved me lots of hassle and time. It really should get more exposure.
I see reports that it doesn't work. These are mostly for distros where Plasma is either rather old or taking a backseat after other environment (usually Gnome). I'm having great results with the latest Plasma 6 on Slackware-current and also in a standard Windows 11 environment.
I had a use case that isn't the primary function of KDE Connect, but where KDE Connect worked well: file sharing from a Mac to an Android phone. I had no idea apps like KDE Connect existed and now I'm hooked.
That said, for my specific use case, Blip is a FAR superior option, and much lighter weight.
Look at Fedora (if you like RPM distros) if you’re after something pretty nicely put together that stays reasonably well up to date. Very well maintained. Influenced by Red Hat (or “led by” or even “owned by”), which works for some, not for others.
CachyOS is trendy these days. EndeavourOS is basically Arch with an installer.
There are a few distros targeted at Windows refugees. ZorinOS is well regarded. AnduinOS is a newer entry. But if you’re willing to walk away from a Windows-like UI, skip these.
Arch has an installer these days. It works pretty well and you can have a system up and running in about 20 minutes if you have a fast internet connection.
For people that want a Windows like UI, I would probably suggest Cinnamon. It works pretty much like Windows 7/10 without all the visual nonsense that KDE typically has.
My experience is that KDE 6 has very little visual nonsense right out of the box. 4 and 5 did have a lot more, but most/all of it could be disabled. Most other Linux DEs don't really let you customize them to your own personal level of nonsense at any rate.
This is a screenshot from their site. Just in this screenshot I see the following:
1) there is an horrendous text shadow effect on the text under the "Home" desktop icon in the top left.
2) Clock text is too large compared to the rest of the interface, especially the icons next to it.
3) Trash Icon looks like out of place compared to the other icons.
4) Drop shadow effect on the window and the start menu thing. It kinda too dark really.
5) Every single gap between interface elements seems different and off. The icon sizes seem a bit all over the place.
6) There is a gradient on the window title bar and rounded corners. Cinnamon does this as well. I dunno it is very Window XP Luna (which I never liked).
7) The window control icons look off to me and don't fit in with the rest of the interface IMO.
A lot of this I appreciate can be probably be changed. But that is how it comes OOTB if it is an official screenshot. It feels like a Windows Vista ripoff.
Generally I find KDE lacks "taste". None of the Linux GUIs are that great tbh. People put up fancy screenshots, but I guarantee the moment the windows are arranged in any other way it looks not so great.
I agree with your assessment of KDE lacking "taste". Imo, it looks like a system designed by engineers, not designers.
GNOME has the opposite problem imo. I feel like it has "taste", but it feels like a system fully designed by designers, with no engineers giving practical pushback. It's the same issue macOS has, but amplified: Designers have some grand idea about their vision being the one true way of using the system and made it hard to impossible to customize.
I currently use KDE, but am not happy with it for the reasons you described. I used to use GNOME, but wasn't happy with it for the reasons above.
I have high hopes for Cosmic [0]. It seems like that one might get the balance right.
> I agree with your assessment of KDE lacking "taste". Imo, it looks like a system designed by engineers, not designers.
TBF, I was linked their more up to date screenshots in a sibling thread and it does look more consistent but it still seems off.
> I currently use KDE, but am not happy with it for the reasons you described. I used to use GNOME, but wasn't happy with it for the reasons above.
I don't like any of the Linux DEs tbh. They all have issues.
I might give KDE a go. But I think Debian does a poor job at packaging it and I don't really want to change distros.
> I have high hopes for Cosmic [0]. It seems like that one might get the balance right.
I tried compiling Cosmic on source on Debian 12. I ran out of memory on the VM I was doing it on. I also found out that on Debian 12 their rustc was broken!
Do you think GNOME has similar UI issues? In my view, it's "pretty", but just doesn't let me configure it the way I want it to without hacking around way too much.
I ended up installing Dash To Dock and Ubuntu App Indicator Icons when I was using it and I ended up with something decent. I also usually have to faff around in the gnome tweaks tool to get the old "legacy" apps and the new apps looking consistent.
Stock Konsole on the left, stock Ghostty on the right. Note that both terminals have multiple tabs open. The amount of wasted space and visual noise in Konsole is baffling. Not to mention Ghostty is able to display 4 more lines of actual console output (you know, the whole point of a console).
In my experience, many KDE apps follow the same UX. Great for configuration and being able to use primarily the mouse, bad if you are more interested in a keyboard centric flow with a focus on the content.
KDE actually was built around the Windows paradigm; Gnome is a Mac clone. Cinnamon is a fork of Gnome maintained as a side project from a distro with a bad security and management track record. Really the only thing it adds is a launcher; KDE optionally provides the same style if the user wants it.
Go find a thread where your pet software is on topic. This thread is about KDE Connect. Does Cinnamon support that? Does Cinnamon offer anything like it?
> Cinnamon? Really? In a KDE Connect thread?
> Go find a thread where your pet software is on topic.
> This thread is about KDE Connect. Does Cinnamon support that?
In this particular part of thread, people were talking about Windows UI replacements. Like it or not conversations do diverge from the original intended purpose.
Secondly, Cinnamon isn't my "pet software". Cinnamon IMO is more similar to the Windows 7/10/11 UI than KDE and has none of the fluff that KDE normally has in it. I actually don't really like any of the Linux UIs. I think they all suffer from significant issues.
> KDE actually was built around the Windows paradigm; Gnome is a Mac clone. Cinnamon is a fork of Gnome maintained as a side project from a distro with a bad security and management track record. Really the only thing it adds is a launcher; KDE optionally provides the same style if the user wants it.
It seems that you really don't like cinnamon and thus why you are being so aggressive. I don't really appreciate the unwarranted hostility.
I don't personally use Linux Mint (I use Debian). I don't like derivative distros for the reason that you highlighted. However Cinnamon seems works reasonably well and tends to be quite a bit lighter than KDE IME.
> This thread is about KDE Connect. Does Cinnamon support that? Does Cinnamon offer anything like it?
You are aware that you can use KDE software in other Desktop Environments? It took me a few seconds to do a web search and it seems that you can use KDE connect and Cinnamon at the same time.
It's doing very well. The Slackware 15.0 release is now a few years old, though the packages are still being updated. Slackware-current has latest everything.
Why Slackware specifically? You can install any distribution. I use Gentoo btw - not really a distribution so much as a distribution construction kit. There are other popular distros, notably Arch.
I liked Slackware a lot way back when. No deeper reason.
Currently leaning towards Debian Testing, but that might depend on my testing of Slackware now. I use Arch daily in WSL, but I've have had enough breakages that I don't want it as my primary OS.
I use Debian 13 (stable). It is very solid. I was using Debian Trixie when it was testing and there was breakage twice.
I would make the /boot partition twice the size the installer suggests though as on my laptop I can't upgrade the kernel because the /boot runs out of space. The laptop is used to view old manuals in PDFs while working on my car so I don't really care.
TBH any of the major Linux distros that have been around for a while are fine. I don't like Fedora or Ubuntu because they are a bit corporate.
I personally wouldn't bother with any of the derivative distros. Typically there isn't a lot different other than they've pre-configured some packages. IME that causes more headaches long term.
Yeh. I'm used to using old version of RHEL at work so I ended up learning how to deal with slow moving distros.
I use the OS as a base system and most of the stuff that needs to be newer versions can be done by installing the binary to to ~/bin as it is added to your path by ~/.profile if the directory exists on Debian.
Stuff like Discord, Slack, Kdenlive, OBS etc. I install using flatpak.
Other stuff. Go, Vim (I compile vim from source) and nvim can stuff can be compiled or dropped into /usr/local
That covers most stuff IME. However I appreciate this won't work for everyone.
Wireguard is purely point-to-point. You have to manually specify any configuration involving routing more than just the local IP addresses you add.
Not sure if it's the best solution, but there's no reason to take over your entire network.
Even with my old OpenVPN setup I had a config where only my local 10.2.0.0/16 got routed over the VPN, everything else went straight to the outside world. Set up IPv6 ULA and you don't need to worry about IP addressing conflicts.
Not really? I mean, it's easy to set and forget which subnets get tunnelled with wireguard (and others, it's just that wg forces you to be explicit about it)
Tailscale doesn't support mDNS / multicast at all, making working with KDE Connect more nebulous. I attempted to add a static peer via the Tailscale hostname, but both ends report not reachable, and the Tailscale daemon is constantly dropping multicast packets. So I'm not sure how this helps, but I also don't have a use case - if I'm on my laptop, my phone is on the same Wifi network 99% of the time.
This is a killer app. There have been times when I asked someone "why can't you just send me a screenshot on signal" or "Oh, can't you copy the URL to your desktop?"... only to realize that the poor fellow didn't have KDE connect (yet).
It's not perfect, but it does things I haven't found anywhere else, makes your phone and laptop and pc.
It might help that I'm actually running KDE everywhere, of course.
I've always run GNOME and KDE Connect port called gsconnect [1] works very well. I run it on several Ubuntus and on Debian 11. I run the KDE Connect app on my Android devices. That plus syncthing are exceptionally good tools to link all my devices together.
Silly use case but I watch TV on my laptop in bed and the cat likes to watch with me. I use some ancient X11 app to freeze the keyboard and mouse and then control vlc, etc. from KDE-connect. That way when my cat attacks Jedis he doesn't reboot my laptop.
It is less about messengers per se, itnis about interacting between devices.
I can share clipboard contentents, can send files, send web page urls from phone to desktop to open a browser there, can control media playback between devices (switch to next track/pause desktop from phone and vice versa) etc also I get phone notifications on desktop
I can share links to myself with a messenger but it's much faster to share them to a given device and see its browser open a tab to that link. It works inside apps too: I can share a video from phone to tablet (NewPipe, probably YouTube too, it's the Android builtin sharing system.)
I can also stop, resume, control volume of media playing on another device.
I can share the clipboard, send files, use a remote keyboard (I think I disabled it) and ping a device.
It can do a lot more but I'm not using much else, I think.
A 5 second keepalive seems unnecessary, but does that actually impact battery life? How long does the device take to move in and out of powersave states? I'd think you'd be looking at maybe 20-40 microseconds of CPU time to handle the packet, so 0.0008% of the time awake due to this. Are other parts of the device just super slow at moving in and out of powersave states?
Wi-Fi in lower power state, when it has nothing to respond to, disables power amplifier and only listens to incoming data. Some functions which are usually performed by the OS are offloaded on smartphones to the Wi-Fi chip, such as ARP/NDP replies, so it doesn't need to wake up a CPU to perform simple answers.
However with the constant keep-alive it has to both enable power amplifier and to wake up the CPU to send the reply that the socket is still alive.
I have a single-board computer with and old Mediatek chip (10 years old), and there Wi-Fi PA increases power consumption by 200mW.
Another reporter in the ticket told that his smartphone works basically 1/2 of its common battery life with KDE Connect enabled.
Keep-alives (not necessary TCP keep alives, but any of this kind of packets) are the _MAIN_ reason for internet battery drain while idle, and are tricky to debug if you don't know where to look (Android lists it as "Android System" or "Phone Idle")
For example, Golang applications had 15 second keep alive until recently: https://github.com/golang/go/issues/48622. Imagine you've opened the website which uses golang web server/proxy and enabled notifications from it in the browser, which use WebSocket from the website itself. Now every time your CPU is woke up every 15 seconds until you close the page and notification channel is offloaded to google/mozilla servers. And remember: every TCP connection has its own 15-second Keep-Alive in different intervals, so it's more like 5-7 second CPU wakeup interval.
The same applies for VPN. When anybody say that anways-on VPN connection drains battery, that is 90% if the time is due to frequent keep-alive packets from the VPN server.
Everything above applies to cellular connection as well, it's the same principle.
It improved the battery life but made the connection activity detection worse (the disconnected phone won't be detected for up to 2 hours), but I didn't complain anymore.
The branding does a major disservice to this application - it works like a charm on my windows and i3wm setups, having no trouble sharing a clipboard and files. There are very few features if any that only work on KDE.
Sometimes on windows it needs a click of the refresh button to get going after connecting to a network. The discovery is wonky on some platforms.
Legacy KDE apps used to follow this naming convention until the late 2000s, early 2010s.
You had apps like Konqueror (web browser, file manager), KMail (email client), Kompose (music score editor), KImages (later rebranded to Krita), and KDevelop (software dev IDE).
Modern KDE apps dropped the 'K' prefix and moved to a more recognizable scheme, like: Falkon (web browser), Dolphin (file manager), and Okular (document viewer).
As you can see, its now a mix of whether the app keeps the 'K' in the name. Some do not.
Its been plasma since 2009, a year after KDE 4 came out and they rebranded a bunch of their projects. Whether 16 years amounts to "ages" ig is up to interpretation.
when it works it's amazing. but very often both my phone and laptop are connected to the same WiFi, yet kde connect can't see them. I can't figure out how to diagnose and solve that when it happens
It should work on any network where mDNS works and where TCP connections can be established. There's not much going on that's more complicated than that when it comes to device discovery.
Many VPN configurations break mDNS and other broadcasts (i.e. Chromecast, file shares, that kind of thing), though. A lot of "how to get started with WireGuard/OpenVPN/etc." guides stop the moment HTTP(S) connections work, but there's more to a functional network than that.
I found that I could get KDE Connect working on my buggy VPN profile by manually specifying remote IP addresses for devices on the other end of the VPN in the settings.
Your desktop probably already has mDNS set up, most user-friendly distros do it out of the box.
But it doesn't really matter, because KDE Connect implements its own sort-of mDNS system by itself, in the form of JSON broadcast across the local network on a standard port offering hostnames, services, and other metadata. Actual, real mDNS would require integration into the host's networking setup and that's too much to ask for clients like Android or iOS and you'd need to implement it manually in many other cases, so they kind of made their own mDNS. It also means you don't need root access to run KDE Connect on your device, which makes it viable on platforms like the Steam Deck.
To get KDE Connect working reliably, you need to make multicast traffic work reliably. Every network has its own restrictions when it comes to multicast so it's hard to know what specific tweaks your workstation needs. Having KDE Connect open on your phone, you should see packets coming in on your desktop on 255.255.255.255 on 1716/udp.
Same, I haven't used it in years because it was so disappointing when it would randomly stop working.
In the last year I have even given up on KDE in favor of Cinnamon on Mint.I loved KDE but there would always be some issue coming up. LTS Mint with Cinnamon has been rock solid.
Speculating here based solely on general networking knowledge. You may have "AP Isolation" enabled and/or multicast blocking on your network may be causing problems.
If I was working on KDE Connect I would add a microphone and speaker based pairing system using OFDM modulation lifted from Rattlegram. Each device would share all IP addresses associated with themselves using sound to broadcast the information.
Often desktop client just cannot connect to mobile.
At first I noticed that this happens when desktop client starts to output in logs these (reported [1]):
kdeconnect.core: Too many remembered identities, ignoring "<id of KDE Connect on my android device>" received via UDP
Restarting desktop client helped, so I wrote watcher that monitors logs for such lines and restarts kdeconnect. But it turned out to be insufficient. Now I have this script running in background to restart kdeconnectd whenever connection is missing, and finally can use KDE Connect reliably:
#!/bin/dash -x
while sleep 1m; do
nmcli connection show --active | grep wifi || continue
kdeconnect-cli -l | grep reachable && continue
# notify-send 'No reachable devices via kdeconnect. Restarting'
systemctl --no-pager --user status app-org.kde.kdeconnect.daemon@autostart.service
systemctl --no-pager --user stop app-org.kde.kdeconnect.daemon@autostart.service
killall kdeconnectd
systemctl --no-pager --user start app-org.kde.kdeconnect.daemon@autostart.service
done
...then why use iOS? Get a de-Googled Android and relish in the power a pocket personal computer can provide when the vendor takes its thumb off the scales.
I don't need software freedom preached to me, thanks. And I'm not going to waste time trying to prove my free software bona fides to you.
Suffice it to say: at the time I bought this iPhone 12 mini, there weren't really good options when prioritizing {small form factor,good privacy posture,good security posture,software freedom}.
I have the same issue, very frustrating. I thought it was a firewall issue, or Android's blocking LAN connections without a VPN, but at this point I'm pretty sure it's just some KDE Connect bug.
Maybe local DNS/DHCP resolution issue? I have this on my LAN with with other services and hosts: the Dnsmasq drops the ball every now and then and does not update the lease database, which results in hosts seemingly being offline.
I would try fixed IPs to see if this solves the issue for you.
I used to recommend KDE-Connect left and right but stopped doing so because it went from rock solid and dependable to a complete disaster in a couple of years.
Linux, Android, iOS, macOS all worked in harmony. Now not even two Android phones using the same software version can see each other, file transfers keep failing after a brief while. And all with the same devices that worked before, across various networks.
Not to say anything about connectivity between Linux and Android or iOS.
Agreed. I've read a lot of apologetics for KDE Connect but there's definitely something wrong with discovery. Often it will fail to discover other devices unless I click "refresh" in both devices. I've gone as far as writing a script to force-refresh at 1 minute intervals. Sometimes it can't be persuaded to work at all. Blame my network maybe, but LocalSend works every time.
Yeah eveey time I want to use it I generally need to unpair and pair it again.
Weird stuff like trying to send my clipboard from my phone and it goes the other way.
Very typical for my KDE experience. Things break and it's impossible to figure out what's gone wrong b/c there is no additional information/logs/diagnostics exposed to the user. Everything to do with Networking and Bluetooth is plagued by this (though to be fair things break a lot less than ~5 years ago)
KDE Connect has been my answer to Apple's Airdrop for the last couple of years. It's an excellent program; I even use it on my Mac for file transferring with my Steam Deck
Same use case, its also been very useful for copying and pasting text from my Mac to the Steam Deck, similar to Universal Copy and Paste between Apple devices.
implements a secure communication protocol over the network, and allows any developer to create plugins on top of it.
Has a component that you install on your desktop.
Has a KDE Connect client app you run on your phone.
Looking further it is only for the local network (with ways to extend it e.g. VPNs).
> Has a component that you install on your desktop.
This is only if you use Windows (or MacOS, as there's also a KDE Connect compatible Mac app out there somewhere IIRC). If you're on KDE Desktop Linux, you're already good-to-go, as it's a pre-installed component of a typical KDE environment. :)
it also talks about using a VPN and what ports to open in a firewall.
I don't know how it handles the harder part, the "device on internet" talks to "device in my house"
most phones and apps use this "harder part" to interpose their corporate server for more than TURN/STUN and continue to "collect all the data" or "insert a subscription"
As long as my phone is connected to wireguard KDEConnect does NOT see any other computer, apparently because it wont forward ICMP broadcast according to the internet.
I would really like to have a solution to this issue but since its baked in WG i don't think this is possible
>As long as my phone is connected to wireguard KDEConnect does NOT see any other computer, apparently because it wont forward ICMP broadcast according to the internet.
WireGuard doesn't do any forwarding out of the box, you need to set up your iptables/nftables to get all of that working. If you follow the WG quick-start guides, they often work by masquerading traffic, making VPN clients act the same way a bunch of computers behind a NAT router would.
You'll need to set up all other kinds of routing as well for cross-network discovery to work. WireGuard doesn't do broadcasting in general (it's a point-to-point protocol after all) so you'll need to wrap broadcasting protocols manually.
Other VPNs go more low-level (at least in TAP mode), mirroring an ethernet network with all the broadcasting and low-level protocols you can think of. In theory you could do that in WireGuard (running L2TP over a WireGuard link) but many phones won't support that, and it'd probably be just as easy to set up an OpenVPN/IPSec+L2TP VPN in that case.
I'm not sure if it's a good idea, though. I imagine most people wouldn't want a printer publishing its mDNS hostname to wake the 5G radio on their phone, or the battery level of their laptop in the case of KDE connect.
KDE Connect leverages mDNS on the network (non-Bluetooth) side, which relies on broadcasts. That means it'll break across networks without a VPN of some kind. For some VPNs (Wireguard, OpenVPN in TUN mode) that also means connectivity is impossible.
You can, if you want, open ports and configure KDE connect to reach out across the internet (practically only feasible with one device behind your router on IPv4, any on IPv6), but because it doesn't use "real" DNS, you can't just enter a DDNS hostname, you have to specify the full IP address.
mdns is a really awful protocol. it was already bad in the era it was born, being just an evolution of Microsoft NetBIOS out something. today in the age of wifi and overlay networks, i just consider it information leak with zero benefits.
so, the rfc have a section on how the mdns server have to evolve to handle multiple interfaces and own that. but in reality nobody gives a damn because the maintainer (redhat ibm) is it in the context it was invented (work networks on the 00s), so everyone (like many comments below) just work around in all the wrong ways making other things more complicated.
"just do these hundreds changed on wireguard, your firewall, install this reverse proxy... now your service that only exists to route things automatically can look like it works" heh.
> the "device on internet" talks to "device in my house"
It doesn't handle it well other than with bluetooth or awkward port forwarding and manual entering of IPs.
I don't see it as a problem though, I don't think I have needed a single time over my many years of use to share my clipboard with, or control the media player or mouse and keyboard, of a device that was not in the same room or on the same network as me.
KDE Connects works amazingly for me. I get, once in a bluee moon, the random "Can't see the other device" bug. I have solved it with the basic dis/connect to the wifi both on my phone and computer. Also, check your Firewall on your computer. Some distros will not "Auto add" KDE Connect to the exception list of your Firewall. Some routers also put LAN and WLAN devices on different VLANS.
I remember getting excited about KDE Connect but then being completely disappointed that it basically non-functional on iOS...
As I remember it (tried it last year I think), the application needs to be in the foreground in order to do anything at all, because of Apple's (purposeful) limitations of doing things in the background.
So if you were hoping to be able to install this and sync stuff without effort and having to leave the app open all the time, Apple seems to be vehemently against anything like that, probably because they have their own solutions for this...
Edit: The GitHub repository actually goes through the Apple-induced problem:
> iOS is very much designed around foreground interactions. Therefore, background “daemon-style” applications don’t really exist under conventional means, so the behavior where KDE Connect iOS is unresponsive in the background is more or less intended. There are technically some special categories and "hacky" methods to try to get it to run in the background, but in general, there is no intended/by-design method of keeping a "daemon-style" app running forever in the background. For more information, see this post on the Apple Dev Forums
Maybe I'm missing something, but what "daemon-style" app tasks are you doing, or expecting, with KDE Connect? Its core functions seem to be quick tasks; sending files, clipboard, remote control, etc.
Perhaps my usage is basic in this way - I've never had an issue with using the iOS app as it is.
I don't think those work between iOS and KDE Connect. I would love to be able to type iMessages on my Linux desktop's computer. If I'm wrong about this not working, someone please let me know, but I've never been able to make messages work.
I love KDE connect. After install I turn off things I don't want, but I have options. Works better than any similar app. Connects essentially and system. I pair it with tail scale or zero-tier depending on needs. Multiboot, all major os's mobile. PC, Mac all have ports. It's under rated
I can't say I'm experienced with Android development, but is there something about this issue that makes it hard for a volunteer to submit a PR? Seems like it should be just an OS API call or something.
Android doesn't really have such a thing as quitting an app. You're meant to just stop doing stuff when off screen, and let your app be evicted in LRU order (or whatever order is actually used). If your app does background stuff you should have a settings toggle to do the background stuff or not, and when it's on and the phone is on, you do the background stuff.
This closes an activity - the user interface of an app - not an app. In Windows terms, this is DestroyWindow, not ExitProcess.
You can also exit an Android process, of course. It's probably what you're looking for, but it's weirdly inconsistent with the overall user experience and you should try to make something consistent instead. Even closing a top-level activity is weird.
This doesn't seem needed to me, I've never seen an android app have a way to close it. Or any kind of battery life impact from KDE Connect for that matter.
I also quite like Localsend to quickly share files on the same network. Used to send photos/files to myself on Whatsapp/Telegram before but after discovering Localsend, stopped!
I've had trouble getting KDE connect to work as a shared clipboard between Android and my Mac. Has anyone ever done that successfully? I couldn't find any documentation to indicate people have which is a real bummer.
I was exasperated when I found out that I can't send files from my Android to my MacBook via Bluetooth. This is a standard protocol. Also (of course, how could I supect otherwise) the file transfer does not work too. These all work flawlessly under Linux / Gnome + KDE.
For file transfer I used LocalSend, but it was still annoying.
How well does this work for sending a lot of files without re-sending the same file?
I have a desktop + laptop + phone.
When I want to sync a directory with a lot of files I wrote a little shell script that uses rsync to do it. This does require running SSH on my laptop but I can invoke the shell script from my desktop.
Likewise with my phone I want to backup my camera photos, using rsync is nice here to avoid sending thousands of them over every time. I run SSH on my phone with Termux, it was really painless to set up and is only on when I run it. Likewise, I invoke the shell script from my desktop to do the transfer.
I thought about SyncThing in the past but was reluctant because I don't have a centralized server and I don't always want 1 device to be the definitive source of truth.
For example:
- On desktop, wrote a blog post
- On desktop, pushed my blog post folder to my laptop
- On laptop, publish the blog post 3 days later
- On laptop, fix a typo and publish the post
- On desktop, pull in the changes from the laptop
The same type of situations happen with KeePassXC's database file. Sometimes I make an update on my phone or laptop and want it sent to my desktop, other times I make the update on my desktop and want it sent to the other 2 devices.
With SyncThing, would this overwrite files on the wrong device as soon as I "sync"?
I use SyncThing on my phone to back up photos/videos on my phone to my NAS. The UX is not great, but it does sync things correctly 100% of the time. For years on end, I never have to worry about it.
It works in one direction: sending files from my Pixel (GOS) phone to Linux.
But the UX could be better. When I send a file, no notification is shown on my phone. But when I look in my Downloads/ folder, the file is there, so that's good.
Now, when I open the kdeconnect-app on Linux, it cannot connect to my phone. Even if the app is open on my phone. I see the phone, but it says "disconnected".
So, as it stands, I put this in the "barely works, needs more love from developers" category.
There's official support for Windows. No support for macOS yet, but there is a working implementation for it. I had no idea I'd be able to use KDE Connect with those operating systems.
I love KDE Connect, it is insanely useful and pairs nicely with KDE Plasma.
But I think it has some major usability issues. The two things I struggle with the most:
1. Sometimes (not always, but often!) the phone is not connected to the computer at all. In order to send something from the computer to the phone, I have to unlock the phone, find KDE connect in the apps, run it, and connect to the computer. I understand that this could very well be just The Way of Android, but it's still obnoxious.
2. The text/SMS sub-app in KDE connect is terrible. It doesn't sync text messages in the background, so it tries to sync when you start it. But it's very slow and takes a good 5-10 minutes for all of your text messages to sync. And apparently it does contacts last because in the beginning you only see phone numbers. And it doesn't show pictures. And (this is normally not a complaint I make), it is very ugly. GS Connect looks way better, but I have no idea if it _works_ any better.
I second this, especially the second point. I love KDE Connect + GSConnect setup between my Android phone and Ubuntu machine, but the texting app is so laggy it makes the experience unpleasant.
It blew my mind when I discovered it, and I use it regularly since. I dual-boot, and it's installed on both my Linux and Windows systems. I mostly use the shared clipboard functionality (especially great to "send" complex messages and passwords from PC to phone), and send files from the phone to the PC.
I wish KDE Connect supported a self hosted relay server configuration. I often use mobile internet and would love for KDE Connect to still work, without having to start Tailscale on my phone + manually configure IPs
I've been using this and recently had a very unpleasant experience: it couldn't mount my new Chinese android phone (worked with the old one!) and the "send file" feature subtly renamed my files (from .tif to .tiff).
It cost me four hours (QField atrocious error messages) and I'm still angry about it.
I discovered this when I needed an easy way to get stuff to and from a Steam Deck. I now use it on my Windows and Linux PCs, Macbook, Android phone, Meta Quest and the Steam Deck!
KDE Connect is great, but it sometimes doesn't work well enough on Apple Devices. I've been using LocalSend with better success when sharing to Android or Windows. But for Android to Linux/Windows and Vice versa, it's pretty much perfect.
Slightly tangential, I find the lack of a "proper" way of organizing data across multiple devices frankly terrible. KDE connect is nice, but it's a bandaid patch. Airdrop between your devices is the same. Apple wants you to store everything on iCloud... which isn't terrible, as long as everything syncs fast enough, you can pay, and you're not without internet (an issue even in urban areas like for eg on the subway).
Modern devices have just "grown", your phone with its 2FA app is also a source of identity, yet the boundaries between a tool to be used, a computer to "work on" (even an SMS to your boss counts as work for me!), and a "fundamental part of your life" - whether by you or by a megacorp (see: notifications! Mindless scrolling on the social media of your choice!) - are all blurred.
Used to use this all the time, but about six months ago an update broke the ability for two computers I have to interact. Instead the daemon crashes repeatedly until I nuke it.
E.g. that it works over the local network or bluetooth only, no remote connectivity without a VPN which the marketing page with fancy graphics (https://kdeconnect.kde.org/) doesn't even tell you because it's so dumbed down to the point of being useless.
Also, why the fuck does KDE have two separate wikis.
> enables all your devices to communicate with each other
I've tried using KDE connect on two desktops (my laptop running Fedora KDE and my desktop running Nobara, also Fedora KDE) and this statement appears false. It was extremely buggy connecting them, and when they did "see" each other, none of the functionality I expected worked. Wanted to use the shared clipboard feature but it didn't work, nor did anything else.
This was early this year, maybe it's gotten better since?
KDE Connect is really for mobile (Android) devices and a computer, not computer to computer, IME
It works fine for me, and has been for at least 2 years, between any subset of 2 laptops (KDE, WiFi), one desktop (KDE, LAN), and two Androids (WiFi). They're all on the same subnet though.
Also tried KDE connect a few years back, but didn't like the idea of giving a buggy phone access to shoulder-surf root accounts. Transferring stuff out of a VM with a local samba instance also works, but samba should also be containerized.
I always appreciate posts like this even though it’s clear a lot of people already know about KDE connect. I only took the plunge into a Linux daily driver for my machine a couple of months ago, so I’m still learning a lot. Just tested it and this is really useful! I depend a lot on LocalSend which is fine but this is so far looking like a better option overall.
Gets a little funky talking to my iPhone but I’m surprised how easily things like the remote control work right out the box
In general, some wifi routers will offer to isolate cross-forwarding between WLAN hosts. Depending on the model, one may not be able to modify this setting.
I can't specifically speak to systemd, but it'd surprise me if there was a dependency there; it's not running that deep in the system. Also there's a guix package and they don't use systemd, so that's another mark in favor.
As a happy user of many KDE based programs (konsole, kate, dolphin, etc) it's great to see another KDE piece evangelized.
But can someone state conclusively if Bluetooth-base connectivty in KDE Connect actually works in 2025? I looked into this a few weeks ago and it seemed liked from mailing list posts until Bluetooth functionality in KDE Connect equals WiFi connectivity the feature is not enabled?
When traveling it's much easier to do "point to point" between laptop and phone and in theory Bluetooth can support this easier than WiFi via third-party access-point or having to mess with WiFi direct.
At least in my use case (as link between Android devices and both Linux/Win PCs) KDE Connect is a real killer app. It enabled seamless integration and saved me lots of hassle and time. It really should get more exposure.
I see reports that it doesn't work. These are mostly for distros where Plasma is either rather old or taking a backseat after other environment (usually Gnome). I'm having great results with the latest Plasma 6 on Slackware-current and also in a standard Windows 11 environment.
I had a use case that isn't the primary function of KDE Connect, but where KDE Connect worked well: file sharing from a Mac to an Android phone. I had no idea apps like KDE Connect existed and now I'm hooked.
That said, for my specific use case, Blip is a FAR superior option, and much lighter weight.
I've been using KDE Connect without a hassle for years on Debian stable as well :).
How is Slackware doing nowadays? Last release was several years ago, but I need a replacement for Win 10 on my PC.
Slackware’s last release was 2.5 years ago.
Look at Fedora (if you like RPM distros) if you’re after something pretty nicely put together that stays reasonably well up to date. Very well maintained. Influenced by Red Hat (or “led by” or even “owned by”), which works for some, not for others.
CachyOS is trendy these days. EndeavourOS is basically Arch with an installer.
There are a few distros targeted at Windows refugees. ZorinOS is well regarded. AnduinOS is a newer entry. But if you’re willing to walk away from a Windows-like UI, skip these.
Arch has an installer these days. It works pretty well and you can have a system up and running in about 20 minutes if you have a fast internet connection.
For people that want a Windows like UI, I would probably suggest Cinnamon. It works pretty much like Windows 7/10 without all the visual nonsense that KDE typically has.
My experience is that KDE 6 has very little visual nonsense right out of the box. 4 and 5 did have a lot more, but most/all of it could be disabled. Most other Linux DEs don't really let you customize them to your own personal level of nonsense at any rate.
I probably see a lot more than other people since I spent a good few years doing pixel perfect web dev.
I am not being hyperbolic when I say that I can see a pixel out of place on a webpage on the other side of the room.
https://kde.org/content/home/main.jpg
This is a screenshot from their site. Just in this screenshot I see the following:
1) there is an horrendous text shadow effect on the text under the "Home" desktop icon in the top left.
2) Clock text is too large compared to the rest of the interface, especially the icons next to it.
3) Trash Icon looks like out of place compared to the other icons.
4) Drop shadow effect on the window and the start menu thing. It kinda too dark really.
5) Every single gap between interface elements seems different and off. The icon sizes seem a bit all over the place.
6) There is a gradient on the window title bar and rounded corners. Cinnamon does this as well. I dunno it is very Window XP Luna (which I never liked).
7) The window control icons look off to me and don't fit in with the rest of the interface IMO.
A lot of this I appreciate can be probably be changed. But that is how it comes OOTB if it is an official screenshot. It feels like a Windows Vista ripoff.
Generally I find KDE lacks "taste". None of the Linux GUIs are that great tbh. People put up fancy screenshots, but I guarantee the moment the windows are arranged in any other way it looks not so great.
That screenshot is very old, for an actual screenshot. For an actual screenshot, you can find one on today's announcement: https://kde.org/announcements/plasma/6/6.5.0/
Btw as one the web developer behind KDE's website, do you mind telling me where you found that screenshot?
> That screenshot is very old, for an actual screenshot. For an actual screenshot, you can find one on today's announcement: https://kde.org/announcements/plasma/6/6.5.0/
Those do look better admittedly. I still think it looks a bit "Fischer Price" but that is personal taste.
> Btw as one the web developer behind KDE's website, do you mind telling me where you found that screenshot?
Of course. It was on your screenshots page that I found via DDG
https://duckduckgo.com/?q=KDE+screenshots
The first result I go was:
https://kde.org/screenshots/
I agree with your assessment of KDE lacking "taste". Imo, it looks like a system designed by engineers, not designers.
GNOME has the opposite problem imo. I feel like it has "taste", but it feels like a system fully designed by designers, with no engineers giving practical pushback. It's the same issue macOS has, but amplified: Designers have some grand idea about their vision being the one true way of using the system and made it hard to impossible to customize.
I currently use KDE, but am not happy with it for the reasons you described. I used to use GNOME, but wasn't happy with it for the reasons above.
I have high hopes for Cosmic [0]. It seems like that one might get the balance right.
[0] https://system76.com/cosmic
> I agree with your assessment of KDE lacking "taste". Imo, it looks like a system designed by engineers, not designers.
TBF, I was linked their more up to date screenshots in a sibling thread and it does look more consistent but it still seems off.
> I currently use KDE, but am not happy with it for the reasons you described. I used to use GNOME, but wasn't happy with it for the reasons above.
I don't like any of the Linux DEs tbh. They all have issues.
I might give KDE a go. But I think Debian does a poor job at packaging it and I don't really want to change distros.
> I have high hopes for Cosmic [0]. It seems like that one might get the balance right.
I tried compiling Cosmic on source on Debian 12. I ran out of memory on the VM I was doing it on. I also found out that on Debian 12 their rustc was broken!
Do you think GNOME has similar UI issues? In my view, it's "pretty", but just doesn't let me configure it the way I want it to without hacking around way too much.
Yes. I agree. Gnome is kinda weird OOTB.
I ended up installing Dash To Dock and Ubuntu App Indicator Icons when I was using it and I ended up with something decent. I also usually have to faff around in the gnome tweaks tool to get the old "legacy" apps and the new apps looking consistent.
The clutter is real though, take a look at this screenshot: https://imgur.com/a/nkedVYq
Stock Konsole on the left, stock Ghostty on the right. Note that both terminals have multiple tabs open. The amount of wasted space and visual noise in Konsole is baffling. Not to mention Ghostty is able to display 4 more lines of actual console output (you know, the whole point of a console).
In my experience, many KDE apps follow the same UX. Great for configuration and being able to use primarily the mouse, bad if you are more interested in a keyboard centric flow with a focus on the content.
Cinnamon? Really? In a KDE Connect thread?
KDE actually was built around the Windows paradigm; Gnome is a Mac clone. Cinnamon is a fork of Gnome maintained as a side project from a distro with a bad security and management track record. Really the only thing it adds is a launcher; KDE optionally provides the same style if the user wants it.
Go find a thread where your pet software is on topic. This thread is about KDE Connect. Does Cinnamon support that? Does Cinnamon offer anything like it?
> Cinnamon? Really? In a KDE Connect thread? > Go find a thread where your pet software is on topic. > This thread is about KDE Connect. Does Cinnamon support that?
In this particular part of thread, people were talking about Windows UI replacements. Like it or not conversations do diverge from the original intended purpose.
Secondly, Cinnamon isn't my "pet software". Cinnamon IMO is more similar to the Windows 7/10/11 UI than KDE and has none of the fluff that KDE normally has in it. I actually don't really like any of the Linux UIs. I think they all suffer from significant issues.
> KDE actually was built around the Windows paradigm; Gnome is a Mac clone. Cinnamon is a fork of Gnome maintained as a side project from a distro with a bad security and management track record. Really the only thing it adds is a launcher; KDE optionally provides the same style if the user wants it.
It seems that you really don't like cinnamon and thus why you are being so aggressive. I don't really appreciate the unwarranted hostility.
I don't personally use Linux Mint (I use Debian). I don't like derivative distros for the reason that you highlighted. However Cinnamon seems works reasonably well and tends to be quite a bit lighter than KDE IME.
> This thread is about KDE Connect. Does Cinnamon support that? Does Cinnamon offer anything like it?
You are aware that you can use KDE software in other Desktop Environments? It took me a few seconds to do a web search and it seems that you can use KDE connect and Cinnamon at the same time.
> Does Cinnamon support that? Does Cinnamon offer anything like it?
KDE Connect can be used with Cinnamon via GSConnect.
It's doing very well. The Slackware 15.0 release is now a few years old, though the packages are still being updated. Slackware-current has latest everything.
Why Slackware specifically? You can install any distribution. I use Gentoo btw - not really a distribution so much as a distribution construction kit. There are other popular distros, notably Arch.
I liked Slackware a lot way back when. No deeper reason.
Currently leaning towards Debian Testing, but that might depend on my testing of Slackware now. I use Arch daily in WSL, but I've have had enough breakages that I don't want it as my primary OS.
I use Debian 13 (stable). It is very solid. I was using Debian Trixie when it was testing and there was breakage twice.
I would make the /boot partition twice the size the installer suggests though as on my laptop I can't upgrade the kernel because the /boot runs out of space. The laptop is used to view old manuals in PDFs while working on my car so I don't really care.
TBH any of the major Linux distros that have been around for a while are fine. I don't like Fedora or Ubuntu because they are a bit corporate.
I personally wouldn't bother with any of the derivative distros. Typically there isn't a lot different other than they've pre-configured some packages. IME that causes more headaches long term.
Debian is a very solid, stable, but slow-moving distribution.
Yeh. I'm used to using old version of RHEL at work so I ended up learning how to deal with slow moving distros.
I use the OS as a base system and most of the stuff that needs to be newer versions can be done by installing the binary to to ~/bin as it is added to your path by ~/.profile if the directory exists on Debian.
Stuff like Discord, Slack, Kdenlive, OBS etc. I install using flatpak.
Other stuff. Go, Vim (I compile vim from source) and nvim can stuff can be compiled or dropped into /usr/local
That covers most stuff IME. However I appreciate this won't work for everyone.
> Why Slackware specifically?
To me, coming from Unix, it's mostly sane.
I definitely have a need for this, but I can't stomach same-network requirement.
Maybe they need self-hostable coordination server so that devices can connect to each other through it.
For now it's still 'send to telegram saved messages' for me.
> self-hostable coordination server
What a long way to spell VPN :-) (been using it for a decade or so through wireguard)
No, vpn takes over your network and you have to fight weird issues on different platforms. This seems like a square peg for a round hole.
Wireguard is purely point-to-point. You have to manually specify any configuration involving routing more than just the local IP addresses you add.
Not sure if it's the best solution, but there's no reason to take over your entire network.
Even with my old OpenVPN setup I had a config where only my local 10.2.0.0/16 got routed over the VPN, everything else went straight to the outside world. Set up IPv6 ULA and you don't need to worry about IP addressing conflicts.
Not really? I mean, it's easy to set and forget which subnets get tunnelled with wireguard (and others, it's just that wg forces you to be explicit about it)
Have you considered using Tailscale to get around the same-network requirement?
Tailscale doesn't support mDNS / multicast at all, making working with KDE Connect more nebulous. I attempted to add a static peer via the Tailscale hostname, but both ends report not reachable, and the Tailscale daemon is constantly dropping multicast packets. So I'm not sure how this helps, but I also don't have a use case - if I'm on my laptop, my phone is on the same Wifi network 99% of the time.
I am a heavy user of it. I don't want to stay connected to it 24/7.
This is a killer app. There have been times when I asked someone "why can't you just send me a screenshot on signal" or "Oh, can't you copy the URL to your desktop?"... only to realize that the poor fellow didn't have KDE connect (yet).
It's not perfect, but it does things I haven't found anywhere else, makes your phone and laptop and pc.
It might help that I'm actually running KDE everywhere, of course.
I've always run GNOME and KDE Connect port called gsconnect [1] works very well. I run it on several Ubuntus and on Debian 11. I run the KDE Connect app on my Android devices. That plus syncthing are exceptionally good tools to link all my devices together.
[1] https://extensions.gnome.org/extension/1319/gsconnect/
I have a all my messengers running on my desktop as well, so I don't really have those problems. How's KDE Connect superior?
I'm seriously interested, since I read it's a killer feature but I cannot really imagine how it would help me.
Silly use case but I watch TV on my laptop in bed and the cat likes to watch with me. I use some ancient X11 app to freeze the keyboard and mouse and then control vlc, etc. from KDE-connect. That way when my cat attacks Jedis he doesn't reboot my laptop.
It is less about messengers per se, itnis about interacting between devices.
I can share clipboard contentents, can send files, send web page urls from phone to desktop to open a browser there, can control media playback between devices (switch to next track/pause desktop from phone and vice versa) etc also I get phone notifications on desktop
(All optional)
I can share links to myself with a messenger but it's much faster to share them to a given device and see its browser open a tab to that link. It works inside apps too: I can share a video from phone to tablet (NewPipe, probably YouTube too, it's the Android builtin sharing system.)
I can also stop, resume, control volume of media playing on another device.
I can share the clipboard, send files, use a remote keyboard (I think I disabled it) and ping a device.
It can do a lot more but I'm not using much else, I think.
Those of us who live in the US where SMS is the default messenger can't have all of their messengers running on their desktop.
Sure you can. Just use KDE Connect.
Even just copying your clipboard is very useful.
Also (more so at home) large transfers are pretty fast, regularly send movies from and to my phone, at pretty much connection speed.
You can also mount your phone storage over the network, control your mouse with your phone and much more.
> KDE everywhere
Not to be confused with Qt Everywhere
The feature set commenters here want is insane:
* fast as possible
* LAN, but also WAN when necessary
* in fact how about multi-protocol, and use the fastest protocol that's available on both devices, it's 2025 people!
* work for sending a gargantuan amount of files with possible interruptions (essentially, be rsync)
* be battery efficient, it's 2025 people!
* don't rely on a centralized cloud server, just connect the damned devices to each other
If you think you can hack this together, you should write it for Gnu Hurd because they'll release that well before you're finished
>* be battery efficient, it's 2025 people!
It took a long time for me to prove that what KDE does negatively impact the battery life.
https://bugs.kde.org/show_bug.cgi?id=441830
The other user even wrote a LD_PRELOAD hijacking library to not recompile the application every time
https://github.com/max0x7ba/kdeconnect-powersave-keepalive
A 5 second keepalive seems unnecessary, but does that actually impact battery life? How long does the device take to move in and out of powersave states? I'd think you'd be looking at maybe 20-40 microseconds of CPU time to handle the packet, so 0.0008% of the time awake due to this. Are other parts of the device just super slow at moving in and out of powersave states?
Yes, it has dramatic impact on the battery life.
Wi-Fi in lower power state, when it has nothing to respond to, disables power amplifier and only listens to incoming data. Some functions which are usually performed by the OS are offloaded on smartphones to the Wi-Fi chip, such as ARP/NDP replies, so it doesn't need to wake up a CPU to perform simple answers.
However with the constant keep-alive it has to both enable power amplifier and to wake up the CPU to send the reply that the socket is still alive.
I have a single-board computer with and old Mediatek chip (10 years old), and there Wi-Fi PA increases power consumption by 200mW. Another reporter in the ticket told that his smartphone works basically 1/2 of its common battery life with KDE Connect enabled.
Keep-alives (not necessary TCP keep alives, but any of this kind of packets) are the _MAIN_ reason for internet battery drain while idle, and are tricky to debug if you don't know where to look (Android lists it as "Android System" or "Phone Idle")
For example, Golang applications had 15 second keep alive until recently: https://github.com/golang/go/issues/48622. Imagine you've opened the website which uses golang web server/proxy and enabled notifications from it in the browser, which use WebSocket from the website itself. Now every time your CPU is woke up every 15 seconds until you close the page and notification channel is offloaded to google/mozilla servers. And remember: every TCP connection has its own 15-second Keep-Alive in different intervals, so it's more like 5-7 second CPU wakeup interval.
The same applies for VPN. When anybody say that anways-on VPN connection drains battery, that is 90% if the time is due to frequent keep-alive packets from the VPN server.
Everything above applies to cellular connection as well, it's the same principle.
Fixed in "Remove custom keepalive intervals" merged 12 Aug 2024
https://invent.kde.org/network/kdeconnect-kde/-/merge_reques...
It improved the battery life but made the connection activity detection worse (the disconnected phone won't be detected for up to 2 hours), but I didn't complain anymore.
I initially set it to 5 minutes.
The branding does a major disservice to this application - it works like a charm on my windows and i3wm setups, having no trouble sharing a clipboard and files. There are very few features if any that only work on KDE.
Sometimes on windows it needs a click of the refresh button to get going after connecting to a network. The discovery is wonky on some platforms.
KDE is simply the 'community' that maintains it, makes sense why that's the branding used despite the inevitable confusion
(the DE has been called Plasma for ages, and almost everything KDE works outside of it)
they should rebrand it as Konnekt.
Legacy KDE apps used to follow this naming convention until the late 2000s, early 2010s.
You had apps like Konqueror (web browser, file manager), KMail (email client), Kompose (music score editor), KImages (later rebranded to Krita), and KDevelop (software dev IDE).
Modern KDE apps dropped the 'K' prefix and moved to a more recognizable scheme, like: Falkon (web browser), Dolphin (file manager), and Okular (document viewer).
As you can see, its now a mix of whether the app keeps the 'K' in the name. Some do not.
> Legacy KDE apps used to follow this naming convention until the late 2000s, early 2010s.
Wow, what a coincident that parent just happened to suggest the identical naming convention. What are the chances?
> the DE has been called Plasma for ages
I disagree.
Its been plasma since 2009, a year after KDE 4 came out and they rebranded a bunch of their projects. Whether 16 years amounts to "ages" ig is up to interpretation.
I’ve been running KDE (as in the desktop) for more than 20 years and I had no idea that Connect worked without Plasma.
Thanks for sharing
when it works it's amazing. but very often both my phone and laptop are connected to the same WiFi, yet kde connect can't see them. I can't figure out how to diagnose and solve that when it happens
It should work on any network where mDNS works and where TCP connections can be established. There's not much going on that's more complicated than that when it comes to device discovery.
Many VPN configurations break mDNS and other broadcasts (i.e. Chromecast, file shares, that kind of thing), though. A lot of "how to get started with WireGuard/OpenVPN/etc." guides stop the moment HTTP(S) connections work, but there's more to a functional network than that.
I found that I could get KDE Connect working on my buggy VPN profile by manually specifying remote IP addresses for devices on the other end of the VPN in the settings.
Oh, so if I setup mDNS on my workstation KDE Connect will be more reliable? Kind of annoying since I DNS already works to resolve names.
Your desktop probably already has mDNS set up, most user-friendly distros do it out of the box.
But it doesn't really matter, because KDE Connect implements its own sort-of mDNS system by itself, in the form of JSON broadcast across the local network on a standard port offering hostnames, services, and other metadata. Actual, real mDNS would require integration into the host's networking setup and that's too much to ask for clients like Android or iOS and you'd need to implement it manually in many other cases, so they kind of made their own mDNS. It also means you don't need root access to run KDE Connect on your device, which makes it viable on platforms like the Steam Deck.
To get KDE Connect working reliably, you need to make multicast traffic work reliably. Every network has its own restrictions when it comes to multicast so it's hard to know what specific tweaks your workstation needs. Having KDE Connect open on your phone, you should see packets coming in on your desktop on 255.255.255.255 on 1716/udp.
1. I don't use a user-friendly distro
2. Thanks for that info; next time it fails to connect I'll take a look in wireshark.
Same, it's just too unreliable to be a tool for me. Which feels like the experience with everything that relies on automatic network discovery.
Mirrors my experience with AirDrop.
Same, I haven't used it in years because it was so disappointing when it would randomly stop working.
In the last year I have even given up on KDE in favor of Cinnamon on Mint.I loved KDE but there would always be some issue coming up. LTS Mint with Cinnamon has been rock solid.
The majority of desktop Wi-Fi cards/chipsets have buggy drivers that break mDNS discovery in one way or another.
To the point that I'd say that Wi-Fi drivers are the most offender in printer discovery problems, which also rely on mDNS.
Another issue that many mDNS applications, including KDE Connect, don't account on multi-interface setups and send respond to mDNS request using incorrect network interface: https://bugs.kde.org/show_bug.cgi?id=507972 / https://bugs.kde.org/show_bug.cgi?id=507954
Speculating here based solely on general networking knowledge. You may have "AP Isolation" enabled and/or multicast blocking on your network may be causing problems.
If I was working on KDE Connect I would add a microphone and speaker based pairing system using OFDM modulation lifted from Rattlegram. Each device would share all IP addresses associated with themselves using sound to broadcast the information.
Just use Bluetooth. These days it's very uncommon for a PC to not have Bluetooth. More of my PCs have Bluetooth than have microphones.
Maybe the Bluetooth connection can be used for IP and port discovery.
It has really got unreliable in my experience.
Often desktop client just cannot connect to mobile. At first I noticed that this happens when desktop client starts to output in logs these (reported [1]):
Restarting desktop client helped, so I wrote watcher that monitors logs for such lines and restarts kdeconnect. But it turned out to be insufficient. Now I have this script running in background to restart kdeconnectd whenever connection is missing, and finally can use KDE Connect reliably: [1] https://bugs.kde.org/show_bug.cgi?id=506563It’s pretty dreadful on iOS, presumably due to OS constraints. I miss how amazing it was on Android.
...then why use iOS? Get a de-Googled Android and relish in the power a pocket personal computer can provide when the vendor takes its thumb off the scales.
I don't need software freedom preached to me, thanks. And I'm not going to waste time trying to prove my free software bona fides to you.
Suffice it to say: at the time I bought this iPhone 12 mini, there weren't really good options when prioritizing {small form factor,good privacy posture,good security posture,software freedom}.
I have the same issue, very frustrating. I thought it was a firewall issue, or Android's blocking LAN connections without a VPN, but at this point I'm pretty sure it's just some KDE Connect bug.
Maybe local DNS/DHCP resolution issue? I have this on my LAN with with other services and hosts: the Dnsmasq drops the ball every now and then and does not update the lease database, which results in hosts seemingly being offline.
I would try fixed IPs to see if this solves the issue for you.
At least for Windows, marking a WiFi connection from Public to Private solved a lot of connection issues for me.
I used to recommend KDE-Connect left and right but stopped doing so because it went from rock solid and dependable to a complete disaster in a couple of years.
Linux, Android, iOS, macOS all worked in harmony. Now not even two Android phones using the same software version can see each other, file transfers keep failing after a brief while. And all with the same devices that worked before, across various networks.
Not to say anything about connectivity between Linux and Android or iOS.
Some wifi APs block client to client traffic by default these days.
Mine does not. Same AP.
Agreed. I've read a lot of apologetics for KDE Connect but there's definitely something wrong with discovery. Often it will fail to discover other devices unless I click "refresh" in both devices. I've gone as far as writing a script to force-refresh at 1 minute intervals. Sometimes it can't be persuaded to work at all. Blame my network maybe, but LocalSend works every time.
Same here, Fedora and iOS. I've mostly stopped using it because I couldn't rely on the app working when I needed it.
The computer doesn't even change addresses, there is no need for mDNS or anything fancy, setting up devices manually once would be just fine.
Yeah eveey time I want to use it I generally need to unpair and pair it again. Weird stuff like trying to send my clipboard from my phone and it goes the other way.
It's handy, but needs work.
That's weird, especially with the exhaustive details you provided there.
I've rarely had any connection issues with Google Pixel (7 currently) and Debian with Plasma 5 or 6 on x86 / 64 platforms.
vpn sometimes
Very typical for my KDE experience. Things break and it's impossible to figure out what's gone wrong b/c there is no additional information/logs/diagnostics exposed to the user. Everything to do with Networking and Bluetooth is plagued by this (though to be fair things break a lot less than ~5 years ago)
KDE Connect has been my answer to Apple's Airdrop for the last couple of years. It's an excellent program; I even use it on my Mac for file transferring with my Steam Deck
Same use case, its also been very useful for copying and pasting text from my Mac to the Steam Deck, similar to Universal Copy and Paste between Apple devices.
Another good one for this is Localsend.
https://localsend.org/
I was wondering what "the network" here means:
> To achieve this, KDE Connect:
Looking further it is only for the local network (with ways to extend it e.g. VPNs).> Has a component that you install on your desktop.
This is only if you use Windows (or MacOS, as there's also a KDE Connect compatible Mac app out there somewhere IIRC). If you're on KDE Desktop Linux, you're already good-to-go, as it's a pre-installed component of a typical KDE environment. :)
not true for all distros. and this kind of thinking is really bad imo for network services.
It has bluetooth support now as well
it also talks about using a VPN and what ports to open in a firewall.
I don't know how it handles the harder part, the "device on internet" talks to "device in my house"
most phones and apps use this "harder part" to interpose their corporate server for more than TURN/STUN and continue to "collect all the data" or "insert a subscription"
Did you get this to work with wireguard though?
As long as my phone is connected to wireguard KDEConnect does NOT see any other computer, apparently because it wont forward ICMP broadcast according to the internet.
I would really like to have a solution to this issue but since its baked in WG i don't think this is possible
>As long as my phone is connected to wireguard KDEConnect does NOT see any other computer, apparently because it wont forward ICMP broadcast according to the internet.
It's a bug in the application.
https://bugs.kde.org/show_bug.cgi?id=507954 / https://bugs.kde.org/show_bug.cgi?id=507972
WireGuard doesn't do any forwarding out of the box, you need to set up your iptables/nftables to get all of that working. If you follow the WG quick-start guides, they often work by masquerading traffic, making VPN clients act the same way a bunch of computers behind a NAT router would.
You'll need to set up all other kinds of routing as well for cross-network discovery to work. WireGuard doesn't do broadcasting in general (it's a point-to-point protocol after all) so you'll need to wrap broadcasting protocols manually.
Other VPNs go more low-level (at least in TAP mode), mirroring an ethernet network with all the broadcasting and low-level protocols you can think of. In theory you could do that in WireGuard (running L2TP over a WireGuard link) but many phones won't support that, and it'd probably be just as easy to set up an OpenVPN/IPSec+L2TP VPN in that case.
I'm not sure if it's a good idea, though. I imagine most people wouldn't want a printer publishing its mDNS hostname to wake the 5G radio on their phone, or the battery level of their laptop in the case of KDE connect.
Actually, I mean the whole "find and talk to my home server over the internet"
Generally it does this by having a DNS record for your home server, or having some other well-known server give out its address or relay the packets.
KDE Connect leverages mDNS on the network (non-Bluetooth) side, which relies on broadcasts. That means it'll break across networks without a VPN of some kind. For some VPNs (Wireguard, OpenVPN in TUN mode) that also means connectivity is impossible.
You can, if you want, open ports and configure KDE connect to reach out across the internet (practically only feasible with one device behind your router on IPv4, any on IPv6), but because it doesn't use "real" DNS, you can't just enter a DDNS hostname, you have to specify the full IP address.
mdns is a really awful protocol. it was already bad in the era it was born, being just an evolution of Microsoft NetBIOS out something. today in the age of wifi and overlay networks, i just consider it information leak with zero benefits.
so, the rfc have a section on how the mdns server have to evolve to handle multiple interfaces and own that. but in reality nobody gives a damn because the maintainer (redhat ibm) is it in the context it was invented (work networks on the 00s), so everyone (like many comments below) just work around in all the wrong ways making other things more complicated.
"just do these hundreds changed on wireguard, your firewall, install this reverse proxy... now your service that only exists to route things automatically can look like it works" heh.
> the "device on internet" talks to "device in my house"
It doesn't handle it well other than with bluetooth or awkward port forwarding and manual entering of IPs.
I don't see it as a problem though, I don't think I have needed a single time over my many years of use to share my clipboard with, or control the media player or mouse and keyboard, of a device that was not in the same room or on the same network as me.
KDE Connects works amazingly for me. I get, once in a bluee moon, the random "Can't see the other device" bug. I have solved it with the basic dis/connect to the wifi both on my phone and computer. Also, check your Firewall on your computer. Some distros will not "Auto add" KDE Connect to the exception list of your Firewall. Some routers also put LAN and WLAN devices on different VLANS.
Is there any update on whether Apple had already opened their iOS API in EU, which would allow to match the KDE Connect's Android functionality?
I remember getting excited about KDE Connect but then being completely disappointed that it basically non-functional on iOS...
As I remember it (tried it last year I think), the application needs to be in the foreground in order to do anything at all, because of Apple's (purposeful) limitations of doing things in the background.
So if you were hoping to be able to install this and sync stuff without effort and having to leave the app open all the time, Apple seems to be vehemently against anything like that, probably because they have their own solutions for this...
Edit: The GitHub repository actually goes through the Apple-induced problem:
> iOS is very much designed around foreground interactions. Therefore, background “daemon-style” applications don’t really exist under conventional means, so the behavior where KDE Connect iOS is unresponsive in the background is more or less intended. There are technically some special categories and "hacky" methods to try to get it to run in the background, but in general, there is no intended/by-design method of keeping a "daemon-style" app running forever in the background. For more information, see this post on the Apple Dev Forums
https://github.com/KDE/kdeconnect-ios
Maybe I'm missing something, but what "daemon-style" app tasks are you doing, or expecting, with KDE Connect? Its core functions seem to be quick tasks; sending files, clipboard, remote control, etc.
Perhaps my usage is basic in this way - I've never had an issue with using the iOS app as it is.
From the feature list, how do I actually accomplish these things without having the app open on iOS, or at all?
- Receive your phone notifications on your desktop computer
- Reply to text messages (or even read?)
I don't think those work between iOS and KDE Connect. I would love to be able to type iMessages on my Linux desktop's computer. If I'm wrong about this not working, someone please let me know, but I've never been able to make messages work.
> I remember getting excited about KDE Connect but then being completely disappointed that it basically non-functional on iOS...
I remember this too. It happened to me about 90 seconds ago.
It's probably not so easy, https://news.ycombinator.com/item?id=44557348
I love KDE connect. After install I turn off things I don't want, but I have options. Works better than any similar app. Connects essentially and system. I pair it with tail scale or zero-tier depending on needs. Multiboot, all major os's mobile. PC, Mac all have ports. It's under rated
The one thing I dislike, is the trouble to finish the application in a sane way:
https://bugs.kde.org/show_bug.cgi?id=423497
I can't say I'm experienced with Android development, but is there something about this issue that makes it hard for a volunteer to submit a PR? Seems like it should be just an OS API call or something.
Android doesn't really have such a thing as quitting an app. You're meant to just stop doing stuff when off screen, and let your app be evicted in LRU order (or whatever order is actually used). If your app does background stuff you should have a settings toggle to do the background stuff or not, and when it's on and the phone is on, you do the background stuff.
This is not true: https://stackoverflow.com/a/40231289
This closes an activity - the user interface of an app - not an app. In Windows terms, this is DestroyWindow, not ExitProcess.
You can also exit an Android process, of course. It's probably what you're looking for, but it's weirdly inconsistent with the overall user experience and you should try to make something consistent instead. Even closing a top-level activity is weird.
This doesn't seem needed to me, I've never seen an android app have a way to close it. Or any kind of battery life impact from KDE Connect for that matter.
Note that you can use it on GNOME with GSConnect. One of my favorite apps
If GSConnect doesn't work for you, it's also worth trying Valent: https://valent.andyholmes.ca/
I also quite like Localsend to quickly share files on the same network. Used to send photos/files to myself on Whatsapp/Telegram before but after discovering Localsend, stopped!
https://localsend.org/
Also PairDrop, which doesn’t require installing anything.
I've had trouble getting KDE connect to work as a shared clipboard between Android and my Mac. Has anyone ever done that successfully? I couldn't find any documentation to indicate people have which is a real bummer.
I was exasperated when I found out that I can't send files from my Android to my MacBook via Bluetooth. This is a standard protocol. Also (of course, how could I supect otherwise) the file transfer does not work too. These all work flawlessly under Linux / Gnome + KDE.
For file transfer I used LocalSend, but it was still annoying.
How well does this work for sending a lot of files without re-sending the same file?
I have a desktop + laptop + phone.
When I want to sync a directory with a lot of files I wrote a little shell script that uses rsync to do it. This does require running SSH on my laptop but I can invoke the shell script from my desktop.
Likewise with my phone I want to backup my camera photos, using rsync is nice here to avoid sending thousands of them over every time. I run SSH on my phone with Termux, it was really painless to set up and is only on when I run it. Likewise, I invoke the shell script from my desktop to do the transfer.
For this purpose, I would not suggest KDE Connect.
What you're looking for is something more like SyncThing: https://syncthing.net
I thought about SyncThing in the past but was reluctant because I don't have a centralized server and I don't always want 1 device to be the definitive source of truth.
For example:
The same type of situations happen with KeePassXC's database file. Sometimes I make an update on my phone or laptop and want it sent to my desktop, other times I make the update on my desktop and want it sent to the other 2 devices.With SyncThing, would this overwrite files on the wrong device as soon as I "sync"?
I use SyncThing on my phone to back up photos/videos on my phone to my NAS. The UX is not great, but it does sync things correctly 100% of the time. For years on end, I never have to worry about it.
I use this between my Arch/KDE desktop + Samsung Galaxy S21, and it works beautifully.
Same, but a Sony Xperia XZ2 Compact (the tiniest phone I could buy with decent LineageOS support). Just a shame it isn't supported on Ubuntu Touch.
It works in one direction: sending files from my Pixel (GOS) phone to Linux.
But the UX could be better. When I send a file, no notification is shown on my phone. But when I look in my Downloads/ folder, the file is there, so that's good.
Now, when I open the kdeconnect-app on Linux, it cannot connect to my phone. Even if the app is open on my phone. I see the phone, but it says "disconnected".
So, as it stands, I put this in the "barely works, needs more love from developers" category.
There's official support for Windows. No support for macOS yet, but there is a working implementation for it. I had no idea I'd be able to use KDE Connect with those operating systems.
The protocol is open so you can build software for other systems that uses it, whether it's GNOME or macOS
There is a Windows build for it. I don't know if it's official or not, but there is a Windows build and it does work well.
I love KDE Connect, it is insanely useful and pairs nicely with KDE Plasma.
But I think it has some major usability issues. The two things I struggle with the most:
1. Sometimes (not always, but often!) the phone is not connected to the computer at all. In order to send something from the computer to the phone, I have to unlock the phone, find KDE connect in the apps, run it, and connect to the computer. I understand that this could very well be just The Way of Android, but it's still obnoxious.
2. The text/SMS sub-app in KDE connect is terrible. It doesn't sync text messages in the background, so it tries to sync when you start it. But it's very slow and takes a good 5-10 minutes for all of your text messages to sync. And apparently it does contacts last because in the beginning you only see phone numbers. And it doesn't show pictures. And (this is normally not a complaint I make), it is very ugly. GS Connect looks way better, but I have no idea if it _works_ any better.
I second this, especially the second point. I love KDE Connect + GSConnect setup between my Android phone and Ubuntu machine, but the texting app is so laggy it makes the experience unpleasant.
It blew my mind when I discovered it, and I use it regularly since. I dual-boot, and it's installed on both my Linux and Windows systems. I mostly use the shared clipboard functionality (especially great to "send" complex messages and passwords from PC to phone), and send files from the phone to the PC.
I wish KDE Connect supported a self hosted relay server configuration. I often use mobile internet and would love for KDE Connect to still work, without having to start Tailscale on my phone + manually configure IPs
I've been using this and recently had a very unpleasant experience: it couldn't mount my new Chinese android phone (worked with the old one!) and the "send file" feature subtly renamed my files (from .tif to .tiff).
It cost me four hours (QField atrocious error messages) and I'm still angry about it.
This looks neat, from what it looks like it's essentially an Open Source version of Apple's continuity/airdrop/airplay stuff?
Seems like it even does the universal clipboard as well, I use that all the time with Apple devices, really cool to see an OSS alternative.
Been using this application for years now. Love / Support it
I discovered this when I needed an easy way to get stuff to and from a Steam Deck. I now use it on my Windows and Linux PCs, Macbook, Android phone, Meta Quest and the Steam Deck!
KDE Connect is great, but it sometimes doesn't work well enough on Apple Devices. I've been using LocalSend with better success when sharing to Android or Windows. But for Android to Linux/Windows and Vice versa, it's pretty much perfect.
Slightly tangential, I find the lack of a "proper" way of organizing data across multiple devices frankly terrible. KDE connect is nice, but it's a bandaid patch. Airdrop between your devices is the same. Apple wants you to store everything on iCloud... which isn't terrible, as long as everything syncs fast enough, you can pay, and you're not without internet (an issue even in urban areas like for eg on the subway).
Modern devices have just "grown", your phone with its 2FA app is also a source of identity, yet the boundaries between a tool to be used, a computer to "work on" (even an SMS to your boss counts as work for me!), and a "fundamental part of your life" - whether by you or by a megacorp (see: notifications! Mindless scrolling on the social media of your choice!) - are all blurred.
I like this with Linux but it's so inconsistent on windows that I just don't bother with it much anymore. I'm on windows most of the time.
The gyro mouse is a fantastic implementation! Used it to control a large television from far away and it works very well.
Used to use this all the time, but about six months ago an update broke the ability for two computers I have to interact. Instead the daemon crashes repeatedly until I nuke it.
This seems to have more technical info: https://userbase.kde.org/KDEConnect
E.g. that it works over the local network or bluetooth only, no remote connectivity without a VPN which the marketing page with fancy graphics (https://kdeconnect.kde.org/) doesn't even tell you because it's so dumbed down to the point of being useless.
Also, why the fuck does KDE have two separate wikis.
KDE Connect is amazing. It's convenient.
> enables all your devices to communicate with each other
I've tried using KDE connect on two desktops (my laptop running Fedora KDE and my desktop running Nobara, also Fedora KDE) and this statement appears false. It was extremely buggy connecting them, and when they did "see" each other, none of the functionality I expected worked. Wanted to use the shared clipboard feature but it didn't work, nor did anything else.
This was early this year, maybe it's gotten better since?
KDE Connect is really for mobile (Android) devices and a computer, not computer to computer, IME
It works fine for me, and has been for at least 2 years, between any subset of 2 laptops (KDE, WiFi), one desktop (KDE, LAN), and two Androids (WiFi). They're all on the same subnet though.
Works well for sending things between my laptop (Kubuntu) and Steam Deck.
SSH File sync applications are reliable...
Android: "Transfer Files To Computer, PC" ( Michal Bukáček includes GPL git URI, YMMV as we still need to audit it for traffic)
https://play.google.com/store/apps/details?id=cz.bukacek.fil...
iPhone: PhotoSync is free to transfer movies and low-resolution images
https://apps.apple.com/us/app/photosync-transfer-photos/id41...
MacOS:
https://github.com/macfuse/macfuse/releases
Windows 11: sshfs is slow, but allows user account constrained access to remote shares
winget install -h -e --id "WinFsp.WinFsp"
winget install -h -e --id "SSHFS-Win.SSHFS-Win"
https://github.com/winfsp/sshfs-win
Windows 11 system tray sshfs link manager:
https://github.com/evsar3/sshfs-win-manager
Windows 11: Local OpenSSH service setup
https://learn.microsoft.com/en-us/windows-server/administrat...
If your home router is dynamic DNS only, the ISP will usually still support ports >1000:
https://www.noip.com/
Or DIY with your own DNS solution with cloudflare:
https://linuxconfig.org/automate-dynamic-ip-updates-for-your...
Also tried KDE connect a few years back, but didn't like the idea of giving a buggy phone access to shoulder-surf root accounts. Transferring stuff out of a VM with a local samba instance also works, but samba should also be containerized.
Best regards, =3
I always appreciate posts like this even though it’s clear a lot of people already know about KDE connect. I only took the plunge into a Linux daily driver for my machine a couple of months ago, so I’m still learning a lot. Just tested it and this is really useful! I depend a lot on LocalSend which is fine but this is so far looking like a better option overall.
Gets a little funky talking to my iPhone but I’m surprised how easily things like the remote control work right out the box
I can't get this to work across subnets/wifi networks in my home network. My phone can see my workstation (KDE) but not the other way around.
In general, some wifi routers will offer to isolate cross-forwarding between WLAN hosts. Depending on the model, one may not be able to modify this setting.
Best of luck =3
Can this be used without KDE, on another desktop environment? Without systemd, even?
It definitely works on other DEs. As an extreme case, there's even a GNOME extension implementation: https://extensions.gnome.org/extension/1319/gsconnect/
I can't specifically speak to systemd, but it'd surprise me if there was a dependency there; it's not running that deep in the system. Also there's a guix package and they don't use systemd, so that's another mark in favor.