In a recent informal meeting of KDE users in Seattle, Andrew Lake from the KDE Visual Design Group gave me some ideas he had for KDE Connect. Since I think that we all have a different vision and different ideas that are possible to implement on top of KDE Connect, I decided to write this post asking for your ideas, in some kind of community brainstorming.
Also, since the last time I made a post about possible features for KDE Connect, a lot of them have been implemented or are work in progress, so i hope this post achieves the same effect :)
Here is my personal list of possible features:
- Plugin for power management (sleep, shut down, etc).
- “Find my phone” plugin, that makes your phone ring even if it is silenced.
- Add media controls from the Android lock screen.
- Plugin to keep your computer unlocked while phone is reachable.
- Use the phone as a location provider for the desktop.
- Akonady resources sync with Android (contacts, calendar…).
- Plugin to print from your phone to your computer’s printer.
- Add support for drag’n drop for touchpad plugin.
- Port to other desktops and platforms: Gnome, Unity, MacOS, Windows…
- Publish and maintain the iOS port that Yang Qiao begun this GSOC (any iPhone user around?)
And here is some stuff is already being worked on:
- Answer SMS from the desktop (by David Edmunson).
- Pair with a specific IP address or hostname (by Achilleas Koutsou).
Now it’s your time to come up with more ideas in the comments! And of course feel free to give your opinion/enhance the ideas on my list.
Update: As Aleix Pol suggested, I created a todo.kde.org for KDE Connect that I will be updating with the ideas that come up in the comments.
Maybe you already know that the new version of the desktop by the KDE people, that will be called Plasma 5, is in the makings. I totally believe that this forthcoming release will be truly amazing, and that’s why Aleix Pol and myself have already started porting KDE Connect to this new Desktop Environment.
Porting every application in KDE, though, requires a huge amount of work. This is one of the reasons why some of the best hackers in KDE will meet this summer in Randa, Switzerland: to work hard in the next version of the best desktop environment ever!
If you, like me, also believe that Plasma 5 will be awesome and want to help its development, I encourage you to donate in the crowd-funding campaign they started to cover the expenses of the meeting. You can do it from the following link:
Thanks from all the KDE Community!
Today we are releasing a new version of KDE Connect for Android phones and the Plasma desktop. This shiny new release includes some nice features contributed by great people in the KDE Community (and outside it). You guys are awesome!
The first feature I want to show you was contributed by Ahmed Ibrahim, and allows you to use your phone screen as a touchpad for your computer. Do you have a mediacenter or another setup where you don’t want to have a mouse and a keyboard always attached? With KDE Connect we will make you able to use your phone as a wireless input device!
And by the way, do you guess how I sent this screenshot from my phone to my laptop? Of course, I used the “Share to” feature and I sent it over KDE Connect :) In this new release, we made Android able to receive files as well, sent from a computer or another Android phone. You requested this feature for long, and finally here it is! You will be able to send files from Dolphin or from the also new command line interface, all thanks to Aleix Pol!
This version also has several improvements under the hood, has a bunch of bugs fixed and can now run on FreeBSD systems, thanks to Raphael Kubo.
To end this post I just want to thank, once again, everybody who sent patches and specially the awesome translation team of KDE, who made KDE Connect already available in 25 languages (including Catalan, my native tongue :)!
KDE Connect 0.7.2 tarball
KDE Connect 0.7.2 Android app on Google Play
KDE Connect 0.7.2 Android app on F-Droid
Edit 29/06/14: Please note that it might take a while for some distributions to release the new version. If you don’t want to compile it yourself, please be patient (and/or poke your distribution packagers until they update it).
Edit 01/07/14: A new minor version of both Android and Plasma been released today, fixing some problems found in the previous 0.7. The links above have been updated.
This is a quick post to say that, the 21st of March, KDE Connect reached the awesome number of 10.000 downloads in the Play Store! Yay! \o/
I’m very happy of this, specially because I don’t have a lot of time to put into the project at this moment, and I’m happy to see that the users and contributors of KDE Connect are keeping it alive!
And for those that can not or don’t want to use the Google Play Store, remember that KDE Connect is also available in the free store F-Droid, thanks to Daniel Martí! Also note that Blackberry 10 users can install KDE Connect on their phones this way, taking advantage of the compatibility with Android apps :)
I’ve been busy (and will be for some months) with my degree final thesis, and KDE Connect is suffering it with a development slow-down. However, we have received emails from people willing to help and I think that your contributions can be a good way to re-activate KDE Connect’s development. So, this post is for all of you who want to help!
First of all I want to post our own to-do list for KDE Connect, ordered by difficulty from easy to hard. Most of those items can be programmed as plugins, so code will be pretty stand-alone . Of course, if you have your own awesome idea you can also contribute it.
- Input emulation: Use your phone as a touchpad/keyboard. [DONE]
- Answer SMS from the desktop: maybe integrating it with Telepathy. [WIP]
- Share from desktop: send files from Dolphin using a context menu service. [DONE]
- Reverse media controls: Add remote controls to the plasmoid.
- Sync stuff: Contacts, Wifi passwords (will need root acces), etc.
- File browsing: FUSE or KIO slave to access your phone filesystem. [DONE]
- Call answering: I have no idea if this is possible and will probably need root access.
- Port to other platforms: Windows (it already builds using KDE Windows!), iPhone, Blackberry, Jolla…
For now I think we can use this post comments to publicly discuss any issue and organize the development. If there is enough people involved I will set up a mailing list.
And finally I would like to explain to people not from KDE how to contribute to KDE Connect or any other KDE project. To get involved in KDE is easy: We use a tool called review board to submit patches to projects. This allows the project maintainer to review the code, ask for any modifications and finally integrate it into the development branch. After you submit a few patches and they are accepted, you can ask for a developer account so you can push your changes directly (even though you should always use the review board anyway). Remember that patches should be as atomic as possible, and not include more than one feature.
In the KDE Projects site you will find the URIs of the different GIT repositories to grab the sources and start coding. Non-stable projects, like KDE Connect, are in the “Playground” category. And also remember that KDE Connect has two different repositories: kdeconnect-kde and kdeconnect-android.
October 14th 2014: Updated post to reflect the things that have been implemented already!
This year’s GSOC is over. In the last 3 months KDE Connect has grown from a dream to reality. I will not take the money and run away from it now: I’m writting this post to announce that I will keep developing KDE Connect and that I hope other developers will join me to make it an awesome connectivity platfrom!
But that’s not all I want to announce, we have got new features too! The last merge to master included the promised file transfer plugin, renamed as “Share receiver plugin”. The new name makes more sense because it can not only receive files but also text and URLs from any Android app using the “Share to…” menu. For now this feature is only working from Android to KDE, but support for KDE to KDE and KDE to Android will come soon.
Here you can find a tarball for this version, tagged 0.3. We are not releasing a stable 1.0 version yet, because some things are still broken (like encryption, as you pointed me out in the comments of the last blogpost).
KDE Connect 0.3 tarball
KDE Connect Android app on Google Play
Android APK for people not using Google Play
The goal of this post is that the security experts out there find flaws in our design so we could improve the security of KDE Connect, which is an important point. Probably this will get too technical if you don’t know what RSA keys are, so proceed under your own responsibility ;).
The first thing we need in KDE Connect is the discovery of other devices. At the moment we provide a single backend that uses UDP broadcast to achieve this. When a device connects to a new network, it sends a broadcast message with its ID and name plus how to reach it (that is: IP and port). Other devices will react to that broadcast sending back their own contact information, so both devices know each other. (Note: We tried Avahi instead of a manual UDP broadcast, but finally we didn’t use it because the Android implementation is of extreme poor quality and also multicast is sometimes blocked by routers :( ).
At this point the devices can ‘talk’ between them, but they don’t trust each other until the intervention of the user, so they will discard any incoming package that is not a pairing request.
Each device has a unique pair of RSA public and private keys. When the user decides to start the pairing process from a device, that device sends its public key to the other device. If the other device accepts the pairing (it will show a message to the user with a timeout asking to do so), it will send back its own public key, so now both devices will be able to send encrypted packages (using their peer’s public key) to each other, that only the expected recipient will be able to read.
Note that the public key can easily be retrieved from a device, just by starting the pairing process with it. So only with that key and the device ID (also public) you would be able to fake a device and send encrypted packages to any other in its name (even though you would not be able to decrypt the answer, since you don’t have the private key of the device you are faking). To solve this issue, we will require a both-way encrypted handshaking (which is not implemented yet):
- Device 1 sends some random number encrypted with Device 2’s key
- Device 2 decrypts the number and encrypts it again with Device 1 public key
- Device 1 decrypts the number and checks it is the same it originally sent (so Device 2 have the correct private key to decrypt it).
- The same happens swapping Device 1 and Device 2
Do you think that the security this provides is enough or are we missing something? Would be better to have a different pair of public/private key for each device, instead of a single one?
Thank you all and happy hacking!