The first release of Plasma 5 is after years of active development finally just around the corner. But where is KDE Telepathy for Plasma 5 standing you ask? Well, a bit behind.
We have started with porting and have the basic applets moreless ready to be used, but that's just a small part of the whole suite. The contact list, the chat application, the system integration module and all other parts needs to be ported to offer a good IM experience with Plasma 5. And we want to offer that.
In just 31 days there will be a Port-to-Frameworks sprint in the middle of the Swiss Alps where lots of code will be ported to Frameworks and Qt5 and we would like to add KDE Telepathy on the list of the apps being ported and really push the port forward during that week. Why there? The core of our KTp team will be there, people with great knowledge of KF5/Qt5 will be there, people from Plasma team will be there, in fact, I don't think we could have a better, more focused opportunity than this one. Plus, the meeting being in the mountains makes for high productivity workplace with little to no distractions.
Please help make this legend meeting happen this year by donating and in turn getting more awesomeness. So far we have almost enough to get everyone there, but we could use couple more €s to give the developers also some food during the week (and obviously pay all the other needed expenses;). Head over to http://www.kde.org/fundraisers/randameetings2014/ to read all the details and to become a never forgotten hero on the list of donors. Oh and please do it right now as the fundraising ends tomorrow.
Thank you for every € you send.
Part of the KDE PIM group is meeting over this weekend in Barcelona in the spacious BlueSystems offices, hacking on all sorts of things. Me and David Edmundson took the oportunity to do some super huge changes to our KPeople library that are needed and as the library is in its dawn, it's better to do it sooner than later. These are all internal and boring changes, but one of the changes we've been working on here is really cool and worth mentioning.
One of the most requested features in KDE Telepathy is a way to rename a contact, especially a metacontact. Since we're now using KPeople to power our contact list, implementing this has become a lot easier. So we devised a plan, spend some time implementing it and voila, we now have a way to rename contacts in KPeople (and thus in KTp) but also a way to store any arbitrary data for a contact.
The boring stuff. Back in the days we were always using directly the contacts coming from Telepathy, so any change in the contact's name would have to be sent back to the server and then synced back, which obviously presents a problem for read-only networks. With KPeople we've created new data layer where the Telepathy contacts is just one of the backends. Thanks to this architecture we can modify the data locally in the KPeople layer and then just provide a way to prefer the local changes over the backend data when displaying things to the user. This data is all stored in Akonadi in a special resource with a special collection. You don't have to do anything for this to work, it's all set up behind the scenes the first time it's used.
This work layed the foundation for full local contacts editing which will come later as it's a bit more complex to get done properly in two days. But basically any custom data can now be stored with your contacts, including a timezone or gpg keys and then reused by any application using KPeople.
As all these changes add new APIs, we're aiming for KPeople 0.3 and KTp 0.9.
Good times ahead.
Sooooo after a brief period of testing the public beta we bring you the final stable release of KDE Telepathy 0.8.
During the 0.8 development cycle we focused on bug fixing rather than implementing lots of new features. The biggest changes from 0.7 are all under the hood. We rewrote the metacontacts library, KPeople, almost completely from scratch and made it independent from Nepomuk, which should bring more performance, reliability and stability to the contact list and (meta)contacts management.
Other than that, we've added support for SIPE project, which improves compatibility with some Microsoft products implementing the extended version of SIP, more info about SIPE at project's sourceforge page.
Full bugs changelog is below. The actual commit numbers are much higher than 23 fixed bugs (as we don't have a bug for every commit) so we thought it might be interesting to look at those numbers too, here's the list:
|total including KPeople||473|
As you can see, KPeople itself got about 45% of all the work. On the other end of the list we have our poor Call UI, which only receives "Version changed from X to Y" commits recently. However that is because we need to first port it to newer technologies, which is blocked by non-existing QtGStreamer 1.0. This will soon become history as the awesome Diane Trout of Los Angeles has finished almost all of QtGStreamer 1.0 and her work is now waiting to be merged. You can try the new Call UI out by following her blog post. We hope to have this all merged in 0.9, then we can finally start really improving the Call UI application.
We've also had quite a few new contributors, with both smaller and bigger patches, both longer staying and one-time-submit contributors. Together we received 72 patches (27%!) from 17 non-regular contributors. Which is really really amazing! So below the bugs list, there is a Thank you list of all these people. And what's even more amazing is that some of those occasional contributors are still around, working tirelessly and submitting patches.
If you would like to join us too, we're always happy to welcome new people around, just head over to our wiki and get started :)
But back to the release - you can get the sources for KDE Telepathy 0.8 from the usual KDE's download servers (grab KPeople library here). Some distros should already have packages available for you, if not, please write a mail to your distro packagers.
After some late night hackings, we bring you an update to your favorite IM client on KDE Desktop. This time we've redone the metacontacts solution a bit. It is still powered by KPeople, KDE's contacts aggregation library, but that part itself is no longer powered by Nepomuk. Basically we rewrote it from scratch and made it faster, more reliable, more robust and generally just better.
Now we collect data on the fly from all your sources, be it your Telepathy IM accounts, Akonadi contacts or anything else that installs a plugin (we might have Skype contacts plugin very soon too ;) When you merge two contacts, KPeople stores it in simple sqlite database, which is light and fast and also transferrable (eg. you can take your metacontacts easily with you).
This will all come in the upcoming 0.8 version of KDE Telepathy, which is planned around the end of February/first week of March. For those enthusiastic and cannot-wait users, we bring the beta right here, right now. Source code available here for KTp and here for KPeople. Nag your distros for packages. Super-important: thanks to a last-second change in KPeople, you might hit an empty contact list problem if you install KPeople 0.2.0. The only workaround is installing KPeople 0.2.1, so please anyone, install 0.2.1. Also note that KPeople 0.2 is in no way compatible with 0.1 version, meaning it won't work with KDE Telepathy 0.7 series. Please stay with KPeople 0.1 if you're using 0.7.
It's a beta and so we would really really appreciate if you could go over this checklist here, test things a bit for us and report anything that's broken from the checklist (or otherwise of course) at the usual bugs.kde.org.
We've just released a bugfix version of stable KDE Telepathy - 0.7.1. It doesn't bring too many exciting features as the team works on those for 0.8 version - there we have completely revamped the metacontacts system, it's now 140% faster, more reliable and with less no-contacts-visible problems (actually we haven't seen that one at all). The 0.8 will be coming out soon~ish.
Anyways, 0.7.1 has new config option for completely disabling the Nepomuk metacontact interface, so if you're having troubles with it and would like to just go to the goo'ol' version, put this line into Konsole:
kwriteconfig --file ktelepathyrc --group feeder --key enabled false
That will permanently disable the 0.7 metacontact system and will get you back to your old models, but with no metacontacts.
One other important issue we got reported a lot was about focus problems in the chat window. They should all be fixed now.
Tarballs can be find at the usual place - download.kde.org - please use mirrors (the "Details" link) for downloading.
The rest of fixed bugs follows.
Last year in the summer I've started a project to truly integrate social networks into our Plasma Workspaces. Truly integrating means having all the data available in our system and allowing any application to take advantage of these data, either just for custom displaying or acting on them somehow.
This solution has several parts - auth mechanism, communication with the service, data storage and data presentation.
The current auth mechanism is custom written for each social network, but fully separated and replacable. They are very simple in terms of UI and provide just that - authentication with the web service to fetch data from it. This will be eventuelly replaced by afiestas' WebAccounts thinggy. So any development effort on the auth mechanism should go there.
Data storage. Since Plasma Workspaces already ships with Akonadi by default, there's no need to reinvent the wheel and create a separate infrastructure just for the social media stuff. Akonadi is generic enough and performs reasonably well for our use case.
With that in mind, we can focus on the social networks integration itself, which is done in form of Akonadi resources/agents, which are very easy to write.
Currently there are 4 major social networks out there - Facebook, Google+, Identi.ca and Twitter. The resource for Facebook which lived in kde:akonadi-facebook was splitted into the library part, now named LibKFbAPI (it goes in the path of similar Google library, which is called LibKGAPI) and residing in extragear/libs (kde:libkfbapi) and the resource part itself, which was merged into kdepim-runtime recently and so it's going to be installed by default with 4.11 onwards. Using this resource one can download the Facebook stream (currently loads either last 400 posts or posts up to 3 days back). This includes corresponding likes and comments of the posts. It also syncs your friends, their birthdays, home address and whatnot. There is also code for syncing events and notes, however this not really tested (and the events don't really work at the moment). Furthermore your notifications are synced as well, but nothing is being done with them at the moment. I want these to show up as a regular notifications in your systray, this should be quite easy to do. The resource can also posts new posts with your account, but cannot "like" or comment on posts yet. Akonadi does allow for that, we just need the code in the resource.
Then we have the microblog resource for Twitter & Identi.ca (they have the same API), which I've started from scratch. It's using the same architecture as the Facebook resource - a library communicating with the network and the Akonadi resource sitting on top of that. Its code is completely based on the microblog dataengine from Plasma and currently allows for receiving 20 last posts from the stream as well as posting. Any other functionality is currently missing. This is in git at kde:scratch/mklapetek/akonadi-microblog-ng.
And we are left with Google+. There's not much to say really as there's no public API for G+, which means no data access. Dan Vrátil, the author of libkgapi and Google resources for Akonadi, will add this support once the API is available.
A resource can of course be written for any network with available public API. If the proper serialization is used in the resource, it will automatically work with the social feed. Furthermore, one can also write resource for anything, like upcoming calendar events or new mails and whatnot. By default anything serialized as SocialFeedItem will be displayed in the feed.
We have the data storage, we have interfaces to the networks, so what's missing? Data presentation aka the user inteface. Plasma currently ships with a qml microblog plasmoid, which is quite nice. So I decided to use that as the user interface and started porting it to the new infrastructure. That consists of a qml plugin communicating with Akonadi and providing the content to the qml plasmoid itself. The development is going on in two places - the qml plugin is at kde:scratch/mklapetek/socialfeed and the plasmoid is in a branch "mklapetek/akonadi_port" of kde:declarative-plasmoids.
Alright so here's a summary of tasks left to do. I think they are quite easy, just needs a bit of research on how Akonadi works and getting familiar with the code, which is all just basic Qt4. So if you're thinking about helping up, don't be scared that you'll be dealing with super-complex Akonadi code, you won't ;)
SocialFeed (the qml plugin)
I'd like to see this all in 4.11, but I can't do it all alone. So please step up to any of these single tasks if you have some time to spare, finishing even one task will be awesome and I'll guide you through it. You can either drop an email to kde-pim at kde.org or to me directly to mklapetek at kde.org. Looking forward for your emails.
Let's bring social integration in Plasma Workspaces ahead of its competitors again!
Thanks to our Google Code-In student, Peter Amidon, our little presence plasmoid in the-just-released v0.5.2 can now haz proper monochrome icons. The plasmoid is looking for icons in "icons/presence-applet" and names matching the oxygen scheme with "-plasma" suffix, here's the list:
So, Plasma theme creators, get at it!
I am on a train right now that provides free wi-fi. But you know how these networks work - one second you're chatting with your friend, next second you lose connection. Getting mad enough about not knowing if I have internet or not, I wrote a super simple Plasma applet to monitor the network connection. This is a bit different from the network manager icon, which shows you that you are connected to the wi-fi, but that does not mean the wi-fi router has access to the internet. So this monitors the internet availability directly by sending ping packets to kde.org google.com, one every 5 seconds. If the ping gets back, it shows green icon (user-online icon), if not, it turns into gray (user-offline) icon. Simple as that.
The code is at kde:scratch/mklapetek/pingz, feel free to improve it if you feel like, it's good enough for me for now :)
Update: One thing I didn't realized when running in plasmoidviewer is, that QProcess::execute(..) waits for the ping process to finish. This has the effect of completely hanging plasma every 5 seconds when added to panel or desktop. Fix will follow shortly (if I'll have internet).
KDE TeaTime (KTT) is a new video podcast ran by a bunch of KDE developers who at some point decided to make their private ramblings and discussions in the open just like the software they develop.
The content of KTT is going to be different each time but always related to KDE. Each time we set a main topic and we'll be discussing live about all things around it, so you can expect rants, personal feelings, ideas not published anywhere and general crapiness :) Please note that our expressed opinions are not always necessarily the opinions of the KDE community and/or KDE e.V. We're still learning how to do the stuff properly, but in the near future once we get the hang of it, we want to have some kind of live interaction with listeners, inviting guests for interviews, showing cool stuff from our desktop and so on.
Right now we're using Google Hangouts for KTT. We decided for that because Hangouts can be streamed live on YouTube, so everyone can watch it live without needing anything special (besides Flash, but hey, everyone watches YouTube) and right after the Hangout is finished, it is automatically uploaded to the YouTube channel. In other words - we can focus purely on the podcast and not be bothered with setting up our own (streaming) software, saving the stream, uploading to YouTube etc. Hangouts get us all this for free.
We chose the format to be around 25 minutes for one episode and we want to do one episode per week. We'll be announcing the streaming times on our social media plethora - Google+, Facebook page, Twitter, Identi.ca or YouTube. Like us, follow us, give us comments, ideas, constructive criticism and cookies. If there will be big enough desire, we might consider providing the podcast as mp3s as well.
The first episode was already recorded last week, the topic was 3rd party KDE apps and you can watch it on YouTube or down below.
Enjoy and spread the word :)